# IcedID gziploader analysis (Part1)

**eln0ty.github.io/malware analysis/IcedID/**

5 minute read

## Introduction


March 17, 2022


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](https://www.unpac.me/)
**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,0x
#data[64:96]
key =
[0x16,0x68,0x29,0x53,0xe2,0x5a,0xfd,0x02,0x33,0x88,0x78,0xa0,0x3a,0x94,0x7e,0x97,0x47,0x50,0x
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.](https://tria.ge/211215-qrtm9ahef3/behavioral1)

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


-----