locked
Simulating suspicious actions in a lab environment RRS feed

  • Question

  • Very excited to see what came out of Microsoft's acquisitions of Aroato last year. Now I'm already deploying ATA in my lab environment and have got it working.

    I want to simulate attacks and other suspicious actions or misconfigurations (clear-text pwds etc) in order to show our Management what this tool can help us with. I want to do this in my lab environment before we deploy the preview in our production environment at this time.

    I have already simulated the "Reconnaissance Using DNS" activity that was posted in an earlier thread in this forum, which showed up nicely in the ATA management console. I have also tried the Honeypot scenario. Any other interesting activities you can share online that will activate the attack-timeline? Not looking for advanced PtH or things like that, just a scenario or two that will show up as an alert and which can be followed on the attack-timeline.

    I don't have a SIEM in my lab, so I guess I can't simulate brute-force (or guess the password) scenarios? Or shoulnd't that be picked up in the DCs mirrored port traffic? I've tried brute-forcing accounts (manually) without being able to activate the alert.

    Thanks!
    Sunday, May 10, 2015 5:00 PM

Answers

  • Hello Mr. Beany,

    Here are two more emulations you can try in addition to the Honeytoken and the DNS Reconnaissance:

    Sensitive Account Credentials Exposed

    1. Add a test user to the "Domain Admins" group

    2. From a server that have TCP connection to your DC, run ldp.exe

    3. Choose: Connection --> Connect  - and type the DC's address

    4. Choose: Connection --> Bind - and select the "Simple bind" option

    5. Provide the credentials of the test user with the format: domain\username

    After few seconds, you should see a suspicious activity similar to the follow:

    Sensitive Account Credentials Exposed

    ** Make sure to remove the user from the "Domain Admin" group after you done testing ;-)

    Broken Trust Relationship

    1. Find a client machine you can play with ...

    2. Run DSA and reset the client's machine account twice

    3. Try to login using that machine, or lock/unlock if already logged in

    After few seconds, you should see a suspicious activity similar to the follow:

    Computers' Broken Trust Relationship

    *** To fix the client machine, run the following command on the client:

    netdom resetpwd /s:DC_ADDR /ud:domain\AdminUser  /pd:*

    For example:


    C:\Users\Administrator>netdom resetpwd /s:dc.ophirp.local /ud:ophirp\administrator /pd:*
    Type the password associated with the domain user:

    The machine account password for the local machine has been successfully reset.

    The command completed successfully.

    Thank you again for testing our product. Feel free to send us more feedback.

    The ATA Team.


    Sunday, May 10, 2015 10:08 PM

All replies

  • Hello Mr. Beany,

    Here are two more emulations you can try in addition to the Honeytoken and the DNS Reconnaissance:

    Sensitive Account Credentials Exposed

    1. Add a test user to the "Domain Admins" group

    2. From a server that have TCP connection to your DC, run ldp.exe

    3. Choose: Connection --> Connect  - and type the DC's address

    4. Choose: Connection --> Bind - and select the "Simple bind" option

    5. Provide the credentials of the test user with the format: domain\username

    After few seconds, you should see a suspicious activity similar to the follow:

    Sensitive Account Credentials Exposed

    ** Make sure to remove the user from the "Domain Admin" group after you done testing ;-)

    Broken Trust Relationship

    1. Find a client machine you can play with ...

    2. Run DSA and reset the client's machine account twice

    3. Try to login using that machine, or lock/unlock if already logged in

    After few seconds, you should see a suspicious activity similar to the follow:

    Computers' Broken Trust Relationship

    *** To fix the client machine, run the following command on the client:

    netdom resetpwd /s:DC_ADDR /ud:domain\AdminUser  /pd:*

    For example:


    C:\Users\Administrator>netdom resetpwd /s:dc.ophirp.local /ud:ophirp\administrator /pd:*
    Type the password associated with the domain user:

    The machine account password for the local machine has been successfully reset.

    The command completed successfully.

    Thank you again for testing our product. Feel free to send us more feedback.

    The ATA Team.


    Sunday, May 10, 2015 10:08 PM
  • Thank you very much, that is perfect. I will make sure to get back to you with feedback and suggestions. ATA is a break-through in AD security, especially the simplicity for organizations for implementing and making use of this software, without the need of lots of knowledge of complex setup and best-practise configuration. I do however hope that ATA will allow us to make a few more custom behavior-based alarms, like: - Alarm event based on credential theft if a spesific user is logged into, or from a non-approved computer/server (like the silo features in AD 2012 will help prevent). Saw the same suggestion in another forum post here. I would also like to be able to connect one or more AD accounts to a spesific person, I think it would be good for the behavior-based machine learning in ATA. As all admins should do, we have two or more AD accounts for privileged persons (e.g. normal account, server admin account, domain admin account). Also, gateways reporting from DCs in different domains/forests to the same central would be good for us! :) Thanks again!
    • Edited by Stian__S Sunday, May 10, 2015 10:38 PM Typo
    Sunday, May 10, 2015 10:37 PM
  • Hi

    There are also some tools available if you are interesting in the kerberos ticket and golden ticket and passing-the-hash alerts

     //Mattias

    Monday, May 11, 2015 10:56 AM
  • I can't seem to find the method for simulating the Reconnaissance using DNS activity in the forum..  would you mind sharing the procedure or link to it?

    thanks!

    Friday, May 15, 2015 5:36 AM
  • A most simple "attack" would be issuing AXFR DNS request from a non-DNS machine, this can be easily done as follow:

    From a machine that is not DNS server (like client machine) which have access to the DC you set port mirroring to the gateway, run the following command-line:

    C:\> nslookup - your.dc.address

    The in the > prompt type:

    > ls your.domain.fqdn

    For example:

    C:\>nslookup - 192.168.222.1
    Default Server:  UnKnown
    Address:  192.168.222.1

    > ls ophirp.local
    [UnKnown]
    *** Can't list domain ophirp.local: Query refused
    The DNS server refused to transfer the zone ophirp.local to your computer. If this
    is incorrect, check the zone transfer security settings for ophirp.local on the DNS
    server at IP address 192.168.222.1.

    After few seconds, you should see an "Reconnaissance Using DNS" suspicions activity, similar to the following:

    Reconnaissance using DNS

    If you do not see it, it is possible that the port mirroring is not set correctly. In this case, we recommend to install netmon 3.4 on the gateway machine and see if you can "sniff" the network data coming to your DC.

    If you do see it - it mean the system is working, so at this point you can sit back and relax and wait for it to identify other suspicious activities in your environment.  

    Friday, May 15, 2015 2:43 PM
  • Try this:

    1. Launch cmd
    2. write, Nslookup
    3. write, Set type=any
    4. write Ls –d itcall.com (itcall.com is a fake name, try a few names for test)

    Sunday, December 25, 2016 2:51 AM
  • Try this:

    1. Launch cmd
    2. write, Nslookup
    3. write, Set type=any
    4. write, Ls –d itcall.com (itcall.com is a fake name, try a few names for test)


    Sunday, December 25, 2016 2:54 AM
  • You can generate some reconnaissance events like account enumeration or brute force attack using LDAP simple bind.

    From a command prompt for account enumeration:

    net user %username% /domain
    net group "domain admins" /domain

    LDAP simple bind:
    User ldp.exe to make a simple bind to your domain and try multiple times to connect with a high priv account.

    Brute Force Attack using LPAP simple bind

    Tuesday, January 3, 2017 11:29 AM