In 2018 Crowdstrike began tracking a metric they refer to as breakout time in their yearly global threat report. Essentially what it boils down to is after a threat actor establishes a foothold in your network how long until they begin moving laterally from that first infected endpoint. In the most recent report they track an average breakout taking around 9 hours, up from 4.5 hours from the prior year. What it illustrates is that your response to a security incident requires reaction quicker than the breakout time to prevent major damage or loss of critical data to a threat actor.
This past week we came across a Trickbot sample that brilliantly illustrates this point.
Like most successful malware this sample arrived via email. In the email was a link to a google docs site.
Upon downloading the user would receive a word document that is in reality the malware loader. Upon opening the document like many others the user is enticed to enabling macros.
Update: Was previously stated to be Guloader, that is not the case just a straight Trickbot loader from the word doc.
Behind the scene encrypted content is extracted and a complex execution chain is pulled off.
IOC’s latent in encrypted OLE objects.
Execution chain of GuLoader invoice.doc.
After this we witnesses 2 different paths for lateral movement by 3 different trickbot actors, tracked as Gtag QWE, Gtag lib693, and Gtag tt0002.
Here’s the pattern of 2 separate executions of the invoice document:
Lateral movement paths during executions
In the first execution that was solely Gtag QWE we saw the trickbot actors try to use Cobalt Strike beacon’s to move laterally:
This appeared to be using the WMI features to try and push CS Beacons that were caught by Windows Defender and AMSI on the lab active directory controller.
In the second execution, the victim machine had a broken trust relationship so while the QWE actor did initially exploit the endpoint they were unable to see the rest of the domain and so no further action was taken. The machine was left infected and trust was re-established to the domain and within minutes of that happening we saw lateral movement to the domain controller.
In this case the lateral movement was performed directly by the Trickbot malware itself. Shortly before this activity took place the following network signature fired tied to the original infected endpoint. Based on log data appears that trickbot used legit creds to drop malware via SMB.
The key take away I see here is keep AV running on your domain controllers! Windows Defender again shines for basic threat prevention. In our executions here we manually disabled Windows Defender ourselves because we wanted to see more indicators and behaviors from lateral movement. If you see any AV signatures fire on your Active Directory controllers, take immediate action to isolate the network from command and control and exfiltration possibilities.
Speaking of network activity let take a look at some data points from one of the executions. In this case we’ll be looking at the activity related to the lib693/ttt0002 activity.
Geolocation of all Command and Control activity.
Ports seen specific to Trickbot executables (not including Cobaltstrike or Powershell Empire)
Size of communication to Trickbot C2.
Decoded Trickbot Settings.ini using https://github.com/hasherezade/malware_analysis/tree/master/trickbot
./trick_settings_decoder.py --brute --file ~/Downloads/settings.ini Searching the charset... [+] Decoded with matching charset: HJIA/CB+FGKLNOP3RSlUVWXYZfbcdeaghi5kmn0pqrstuvwx89o1246jMQDz7ETy <mcconf> <ver>1000503</ver> <gtag>tt0002</gtag> <servs> <srv>184.108.40.206:443</srv> <srv>220.127.116.11:443</srv> <srv>18.104.22.168:443</srv> <srv>22.214.171.124:443</srv> <srv>126.96.36.199:443</srv> <srv>188.8.131.52:443</srv> <srv>184.108.40.206:443</srv> <srv>220.127.116.11:443</srv> <srv>18.104.22.168:443</srv> <srv>22.214.171.124:443</srv> <srv>126.96.36.199:443</srv> <srv>188.8.131.52:443</srv> <srv>184.108.40.206:443</srv> <srv>220.127.116.11:443</srv> <srv>18.104.22.168:443</srv> <srv>22.214.171.124:443</srv> <srv>126.96.36.199:443</srv> <srv>188.8.131.52:443</srv> <srv>184.108.40.206:449</srv> <srv>220.127.116.11:449</srv> <srv>18.104.22.168:449</srv> <srv>22.214.171.124:449</srv> <srv>126.96.36.199:449</srv> <srv>188.8.131.52:449</srv> <srv>184.108.40.206:449</srv> <srv>220.127.116.11:449</srv> <srv>18.104.22.168:449</srv> <srv>22.214.171.124:449</srv> <srv>126.96.36.199:449</srv> <srv>188.8.131.52:449</srv> <srv>184.108.40.206:449</srv> <srv>220.127.116.11:449</srv> <srv>18.104.22.168:449</srv> <srv>22.214.171.124:449</srv> <srv>126.96.36.199:449</srv> <srv>188.8.131.52:449</srv> <srv>184.108.40.206:449</srv> <srv>220.127.116.11:449</srv> <srv>18.104.22.168:449</srv> </servs> <autorun> <module name="pwgrab"/> </autorun> </mcconf> 5242EC05463E0FCC41D71BB00EDA068D6836A2369B30B83627472701AE13B952 1895248442 8 12 17
Full IOCs in MISPpriv and here: