IcedID continues to evolve but yet not a lot of attention is given it, Joshua Platt, Vitali Kremez and myself recently released a report detailing how they have been targeting and continue to target tax season in the midst of the Covid-19 pandemic which has extended tax season in the US to July.
In light of this they are also continuing to innovate on their malware tools including their PhotoLoader which was detailed by MalwareBytes previously. The loader has recently had a number of additions added to it which appear to be designed towards protecting the payloads and also evading network detection.
The loader comes with an onboard configuration which will be decoded:
Decoding this config shows some hex data and a number of domains:
Some of these domains are legit and one of them stands out as suspect, the loader enumerates these domains and makes requests to them in a loop.
After retrieving the content it will look for the first occurrence of ‘url(“‘ or ‘src=”’.
It will then build another request for this resource from the same domain but depending on the flag value before the domain will determine whether or not the second request will have a callback function set on the request for the retrieved resource.
The callback will add cookie values to the request headers.
The cookie values built are based on various information from the infected system.
An example of the request can be seen from this sandbox detonation:
The _u cookie value holds the username and computername hexlified.
Inspecting the data from the sandbox detonation:
>>> binascii.unhexlify('4445534B544F502D4A474C4C4A4C44') 'DESKTOP-JGLLJLD' >>> binascii.unhexlify('61646D696E') 'admin'
A breakdown of what the cookie values are:
|_gid||Based on physical address of NIC|
|_io||Domain identifier from SID|
|_u||Username and Computername|
|_gat||Windows version info|
|_ga||Processor info via CPUID including hypervisor brand if available|
|_gads||First DWORD from decoded config data, flag from inspecting server certificate, a random DWORD or number passed as parameter with -id=, number of processes|
After pulling down the fake image file it will look for ‘IDAT’.
Uses a byte value to determine the size of the RC4 key before RC4 decrypting the data:
Then will perform a hash check on the decoded data to determine if it was correct.
If the hash check fails it will just continue performing this enumeration through the domain list, effectively turning this process into a checkin loop with fake traffic mixed in.
Many of these added features to their photo loader appear to be designed for evading researchers and detections, this gives us insights into their operations as what their customers are asking for dictates what their development team will prioritize. With the previous photo loader being blogged about and signatures being released, it was only a few months before a new updated system was created to replace it.
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"IcedID PhotoLoader Ver2"; flow:established,to_server; content:".png"; http_uri; content:"__gads="; http_cookie; content:"gat="; http_cookie; content:"_ga="; http_cookie; content:"_u="; http_cookie; content:"__io="; http_cookie; content:"_gid="; http_cookie; classtype:trojan-activity; sid:9000030; rev:1; metadata:author Jason Reaves;)