IcedID gziploader analysis (Part1)

Introduction

IcedID , also known as BokBot, was among one of the most active malware families and has been known for loading different types of payloads such as Cobalt Strike.

In this report, I’m going to walk through an analysis of a malicious document that distributes and executes an IcedID DLL payload then, the malicious payload itself.

Our process divided to 3 stages (Entry stage + 1st stage + 2nd stage) but unfortunately, I can’t get to the second stage because the C2 server is down. Here I will review some of the characteristics of our different stages:

• Entry stage: Malicious document executes VBA macro to download IcedID on the disk.
• First stage: Loader is executed and download the the real malware (C2 is down in this step)
• The Second: The malware for which this process was being performed is being executed and this is something that is determined by the server administrator (Cobalt Strike for example).

Entry Stage

sha256: f604ca55de802f334064610d65e23890ab81906cdac3f8a5c7c25126176289c8

I used olevba to extract the embedded script from the .doc file.

I just want to point out that I used Exiftool to extract some meta data to understand the script:

-> Exiftool <filename.doc>

When I opened the document, I found obfuscated content with white color and too small size. So, I griped it and removed all %1 instances. This is some of code after beautifying:

The main function for the whole script is decoding the 2 strings in the top of HTML code then creates a connection with the server to download IcedID dll Loader. I cyberchef to get these strings.

Final results:

First Stage

The main purpose of this stage is to drop the payload and it could be a real malware or another dropper. This process depends on the malware developer and what he wants.

Let’s start the analysis with our dropped DLL payload. Dropped file is packed. I tried to upload it to automatic unpacker umpac.me but it doesn’t support x64 binaries. Let’s unpack in manually with x64dbg.

The unpacking process is really simple. It allocates memory for the unpacked code using VirtualAlloc(). So we just set a breakpoint at VirtualAlloc() and run the debugger twice, then dump the file from memory.

Decrypt Config

The first function that malware performs, it decrypts C2 server and campaign number.

Malware uses a pretty simple decryption algorithm. It retrieves the encrypted data from .data section then -> data[0:32] ^ data[64:96] .

I wrote a python script to decrypt the config.

import struct

#data[0:32]
data = [0x55,0x00,0x29,0x36,0x84,0x33,0x8f,0x67,0x5d,0xe1,0x1b,0xc1,0x4e,0xe6,0x17,0xf5,0x2b,0x35,0xd7,0xed,0x15,0xf4,0x2a,0x30,0x21,0x70,0xbc,0x03,0x37,0xb7,0xe8,0x66]
#data[64:96]
key = [0x16,0x68,0x29,0x53,0xe2,0x5a,0xfd,0x02,0x33,0x88,0x78,0xa0,0x3a,0x94,0x7e,0x97,0x47,0x50,0xf9,0x8e,0x7a,0x99,0x2a,0x54,0xee,0x10,0x9c,0x64,0x2c,0x69,0xae,0x5c]
res = bytearray()

for i in range(32):
	res.append(data[i] ^ key[i])

print("CampaignID:", struct.unpack("<I", res[:4])[0])
print("C2:", res[4:].split(b'\x00')[0].decode())

'''
Results
	CampaignID: 1694525507
	C2: firenicatrible.com
'''

The first 4 bytes refer to Campaign number that shows the purpose of the attack. Second, C2 decryption.

Misleading traffic

The mawlare sends traffic to aws.amazon.com to mislead, and between the lines it sends a request to the C2 to drop the malicious file.

Playing with cookies

This is first impression when you look to the function which manipulating the request cookies.

IcedID sends 6 parameters in cookies after manipulating them numerically. I will give you a summary of them and why they are important then explain in details.

Name	Value
_gads	First DWORD from decoded config data(Campaign number), flag from inspecting server certificate, number of milliseconds, sys info
_gat	Windows version info
_ga	Processor info via CPUID including hypervisor brand if available
_u	Computername, Username and VM detection
_io	Domain identifier from SID
_gid	Based on physical address of NIC

_gads

• Campaign number

  I already explained it in the code above (Campaign number = 1694525507)

• flag

  The value most of time = 1 because amazon server is always available

• VM detection

  GetTickCount64 retrieves the number of milliseconds that have elapsed since the system was started.

• System information

  Retrieves the specified system information.

  

_gat

Check version:

_ga

Check cpu:

_u

• Computername

  

• Username

  

• VM detection

  The last parameter is a bit tricky. I crossed reference the values then I found that:

  

  Its common to use RDTSC to get fine-grained timing information, where the overhead of a virtualization trap would be quite significant. Most common use is to have two RDTSC instructions with a small amount of code between them, taking the difference of the times as the elapsed time (number of cycles) for the code sequence.

  But in our case, this malware sleeps 4 times instead of calling it twice.

_io

Check SID:

_gid

The GetAdaptersInfo function retrieves adapter information for the local computer.

The view from sandbox traffic.

Now, the attacker knows almost all the information about the victim’s machine, and he is ready to drop a suitable malware to start Stage2 depending on the campaign number that determines the attack behavior.

Connect C2 server

In this step, malware connect to C2 server.

Then it drops the malicious file in c:\\ProgramData\\.

Unfortunately, This is the end of analysis because the server is down. My next report will be about the second stage of the loader and an example of malware that can be downloaded from it. stay tuned for more. “إن شاء الله”

Conclusion

1. Phishing mails drops malicious document
2. Malicious document runs VBS script
3. The script executes JavaScript code to drop dll file
4. dll file connects to C2 server

There are several steps you can take to protect against phishing:

• Do not reply, even if you recognize the sender as a well-known business or financial institution. If you have an account with this institution, contact them directly and ask them to verify the information included in the email.
• Do not click any links provided in these emails.
• Do not open any attachments. If you receive an attachment you are not expecting, confirm with the senders that they did indeed send the message and meant to send an attachment.
• Do not enter your personal information or passwords on an untrusted Web site or form referenced in this email.
• Delete the message.

IOCs

Hash

• doc -> f604ca55de802f334064610d65e23890ab81906cdac3f8a5c7c25126176289c8
• Packed dll -> CFE2CAF566857C05A6A686CA296387C5E1BFDDA6915FF0ED984C1C53CD5192A3
• Unpacked dll -> 1A2A8F604B8E4917A7E5A2A8994F748B59CA435C8AABC6D3ED211C696B883BC4

URLs

• maldonadoposts.com
• firenicatrible.com

Files

• c:\users\public\youYou.jpg
• c:\users\%username%\documents\karolYouYou.hta