Lateral movement stops at Domain Controller

[forensic65x]

i'm using the environment provided by the DeceptionLab Github project. The network is a Windows 10 workstation, Windows 2016 Server and Windows 2016 Domain Controller.

hxxps://github.com/clong/DetectionLab

Each operation I have attempted has compromised the starting host, and then the domain controller, but stops there.

I have a domain admin account logged in to each system during the operation. I made sure the UseLogonCredential reg value is set to 1 to ensure both hashes and clear text passwords are available in memory.

I have tried setting starting user to both System and Active User.

My Adversary includes the 7 steps outlined in the Caldera Youtube video which shows all systems in the network getting compromised - hxxps://www.youtube.com/watch?v=xjDrWStR68E

• copy_files
• get_creds
• get_admin
• get-computers
• get-domain
• net-use
• remote-process

It's not clear why it can jump from the Win10 or Win2016 system to the DC but not the DC to the other system.

[dm-mitre]

@forensic65x I'm not familiar with the DeceptionLab environment, but it sounds like things should be working in your setup. If CALDERA is doing at least one lateral movement, you've got a working set of Steps. This is likely a problem with CALDERA either not getting all of the necessary credentials or not detecting the administrators.

You said you have a domain admin logged in on all computers, are you using different domain admin accounts on each computer, or the same account? Easy way to identify if credentials are the problem is to use only one account. If you are using one account and things still fail, we can check if this is a problem with admin detection. If you expand the green box in the operation view for the get_admin step of one of the computers that it is failing to move to (It should say something like "Enumerating the Administrators group of \<failed hostname>") in the expanded view you should see a bunch of text like this: https://github.com/mitre/caldera/blob/master/caldera/tests/parser_tests_data/powerview_GetNetLocalGroupMember.output

If the text is empty, or there is some kinda of error message there, that would indicate a problem.

As an aside, recent versions of Windows 10 made a change that prevents get_admin from working when run as the System user so I would expect that to fail, however starting as the active user (domain admin in your case) should work properly.

[forensic65x]

are you using different domain admin accounts on each computer, or the same account?

Same account.

we can check if this is a problem with admin detection

I viewed the output of the enumeration, and the domain admin account is listed.

Given the systems in the Lab are Win10 and 2016 I've set the uselogoncredential value to 1 and confirmed that both hashes and clear text versions of the domain admin account password are in memory and can be captured via mimikatz.

Do you know what setting recent versions of Win10 prevents get_admin to fail? I can make changes to the GPO and/or registry.

I am rebuilding the environment from scratch to test again. I will provide the output to any of the commands needed to help troubleshoot - just let me know which tests to run and I'll run them and provide results.

Thanks.

[Lonelywave]

I have the same problem that do "only one step" from win7-1 to DC. I set up the testing environment with 3 VM (win7-1, win7-2, win 2012 r2 (DC)).

Not sure is there anything i miss to do to make post-exploitation from win7-1 -> win7-2 -> DC or win7-1 -> DC -> win7-2 ?

thanks.

[dm-mitre]

@forensic65x Did the rebuild get things working?

@Lonelywave did you follow the steps in this guide to ensure a user is logged in? http://caldera.readthedocs.io/en/latest/environment_setup.html

[Lonelywave]

I looked this guide carefully to do my lab, but not sure if i did it correctly. This is what I did.

---

Domain Name - DDD

I've PC-A (with account DDD\A), PC-B (with account DDD\B), and AD (DDD\admin).

1. Login into PC-A with DDD\A and login DDD\admin, then switch user to DDD\A.
2. Login into PC-B with DDD\B and login DDD\admin.
3. Login into AD with DDD\admin.
4. Starting LM adversary from PC-A with SYSTEM privilege.

---

The Operation steps are...

1. Enumerating all computers in the domain.
2. Mimikatz to dump credential. (Will get DDD\admin Credential)
3. Do more enumerate
4. PC-A LM to AD correctly with dumped DDD\admin credential.
5. But No more steps that from AD to PC-B.

---

btw, there are two steps written in the guide

1. Create a domain user account (different from a local user account)
2. Make that user an administrator on both Windows 10 computers in your domain (the account doesn’t have to be an administrator on the Domain Controller, but it can be)

Is that mean I have to create another user account which is not DDD\admin in my AD? (e.g. DDD\C) Then DDD\C has right to login into PC-A and PC-B ?

Thanks.

[Lonelywave]

@dm-mitre

Seems there are no plans for planner to do next? after first Lateral Movement from PC-A to AD.

---

According to the demo video, after LM to next pc.

1. win7x01 to win7x02 by using WMI. (This worked fine in my situation)
2. Get credentials at win7x02. (This worked fine in my situation)
3. Mounting win7x03 C$ by net use. ( "net use" plan not added)

[dm-mitre]

I was doing some testing and I believe this is a problem with caldera not recognizing that the domain admin account is an administrator on all computers.

To get around this for now you can create a domain account and set that account individually to be an administrator on each computer (as opposed to a domain administrator).

[Lonelywave]

@dm-mitre it work fine for me!!! Thanks a lot.

[adamsh25]

Just encountered this issue in my lab. Normal environments don't include all members of domain admins as a direct member of the "Administrators" local group. It doesn't make sense and won't be effective during testing of sec products efficiency.

Can you add a new task - "Domain Groups Enumeration" and their members, and correlate the data?

[ArtificialErmine]

adamsh25, although we don't currently have any plans to directly increase the collection of steps available to Adversary mode, if you want such functionality, feel free to create a pull request and we'll get it into the repository. In the mean time, this issue is being closed due to the original problem being resolved.