From Zero to Lateral Movement in 36 Minutes

An attacker logged into the RDP Honeypot a few weeks ago and was able to dump credentials and move laterally in 36 minutes. I’ve been seeing more and more ProcDump and less and less mimikatz lately. The attacker attempted to run a couple executables to maintain persistence but these attempts failed. These attempts failed because the destination IP address was blocked by the IPS because the IP is known to deliver malware.

Here is the timeline from the attack:

10:46 – Attacker logs on from 193.188.22[.]29.

10:47 – Advanced_Scanner.exe is copied to the system. I wasn’t able to grab the binary but it was Advanced Port Scanner from here. VT link here.

10:51 – procdump64.exe is coped to the system and then run.

10:52 – lssass.exe is copied to the system but failed to run due to a windows fault. lssass attempts to connect to 193.188.22[.]29 but fails. Notice the slight difference between the Microsoft signed binary lsass.exe and the dropped binary lssass.exe.

10:54 – winlogo.exe is copied to the system but failed to run due to a windows fault. Winlogo attempts to connect to 193.188.22[.]29 but fails.

10:55 – procdump64 is run to dump lsass.

10:56 – The attacker zipped lsass.dmp into

11:03 – mysqld is copied to the system but failed to run due to a windows fault. Mysqld attempts to connect to 193.188.22[.]29 but fails.

11:16 – Advanced_Scanner is run with the portable switch.

11:21 – ps64.exe is copied to the system.

11:22 – ps64.exe (PsExec) is run using Domain Administrator (DA) credentials to log in to a Domain Controller.

Activity stops here as the attacker logs off. I’m quite surprised the attacker logged off at this stage in the game but it was quite interesting to see this type of activity occur so quickly.


The attacker was able to go from having zero access, to having local admin access, to moving laterally with a Domain Administrator credential, in 36 minutes. Are you prepared for this in your environment? Where would you detect the attacker? Could you stop them before they move laterally? What if it happens in the middle of the night?

As always, do not put RDP directly on the internet. Make sure you have coverage for abnormal processes accessing lsass.exe, such as procdump.exe or procdump64.exe. Most EDRs will have some level of coverage for this but you should test it in your own environment to validate coverage. Another thing to note, the renaming of PsExec to ps64.exe. If your rule is looking for psexec.exe, and not ps64.exe, your detection may fail. Instead of focusing on the process name, look for the command parameters and the parent/child process association.

Another helpful tool to use would be application white-listing. This would have stopped the C2 exectuables from running and could have prevented ProcDump and PsExec, if you don’t use them in your environment. IP blocking was also helpful in this case because the C2 was not able to talk back to Russia to maintain persistence.


C2 IP – 193.188.22[.]29

Advanced_Scanner.exe 4FDABE571B66CEEC3448939BFB3FFCD1

winlogo.exe f32170f2521244a03e0565874cea9bb9

lssass.exe a9ca5c795f1a6d720e064bc910e30242

mysqld.exe 15f2f581d747e91e07ba2c69770f3ef2

ps64.exe 9321C107D1F7E336CDA550A2BF049108

procdump64.exe a92669ec8852230a10256ac23bbf4489

lsass dump rule – command line parameters ” -ma ” + “.dmp”

Leave a Reply