MalOps - Simda Botnet Writeup

Scenario

A workstation in your network has been flagged for suspicious outbound traffic to multiple foreign IP addresses linked to the Simda botnet. Forensic triage reveals a malicious file (svchost32.exe) in C:\Users\Public\Libraries\ and DNS queries to random-looking domains resolving via fast-flux hosting. Simda is known as a loader, capable of downloading other malware. Your task is to investigate the provided PCAP, event logs, and filesystem artifacts to identify the initial infection vector, C2 infrastructure, and any additional payloads delivered, and to recommend containment steps.

Analysis Process

This is a real malware, and there have been many analyses of it. Sample Hash (SHA-256):

b2e5f58e46da212ca0346b3973db515803b94140b297d5b2125c48394945c400

Analysis Challenge: https://malops.io/challenges/simda

Task 1. What is the first windows API used by the malware to allocate memory?

In the Imports tab of IDA, we see that it imports two API functions: LoadLibraryA and GetProcAddress.

• LoadLibraryA : Load a DLL into the process and return an HMODULE handle.
• GetProcAddress : Get the “function address” (function pointer) from a loaded DLL.

When examining the references to GetProcAddress, we see that it is called in the function sub_44016B0().

1
LPVOID __cdecl sub_4016B0(SIZE_T a1)
2
{
3
  HMODULE LibraryA; // eax
4
  LPVOID (__stdcall *VirtualAllocEx)(HANDLE, LPVOID, SIZE_T, DWORD, DWORD); // [esp+0h] [ebp-10h]
5
  SIZE_T v4; // [esp+4h] [ebp-Ch]
6

7
  v4 = a1;
8
  LibraryA = LoadLibraryA(LibFileName);
9
  VirtualAllocEx = (LPVOID (__stdcall *)(HANDLE, LPVOID, SIZE_T, DWORD, DWORD))GetProcAddress(LibraryA, ProcName);
10
  if ( a1 == 2 )
11
    v4 = 634880;
12
  return VirtualAllocEx((HANDLE)-1, 0, v4, dword_4CA00C, 64);
13
}

This function uses LoadLibraryA and GetProcAddress to get the address of VirtualAllocEx, then calls VirtualAllocEx to allocate memory with a size depending on the parameter a1. This technique is called Dynamic Loading or Dynamic API Resolution.

This technique allows malware to hide API names in files, bypass static parsing or signatures, and ensures compatibility across multiple Windows versions.

Task 2. What does the second parameter given to RegOpenKeyA call point to?

In the pseudocode of the sub_401170() function:

1
LSTATUS (__stdcall *sub_40  1170())(HKEY hKey, LPCSTR lpSubKey, PHKEY phkResult)
2
{
3
  LSTATUS (__stdcall *result)(HKEY, LPCSTR, PHKEY); // eax
4

5
  result = RegOpenKeyA;
6
  dword_4CA0DC = (int)RegOpenKeyA;
7
  return result;
8
}

This is a function used to initialize a function pointer. It assigns the RegOpenKeyA API to a global variable (dword_4CA0DC) so that it can be called indirectly elsewhere.

In the start function, we see that it calls the function pointer dword_4CA0DC as follows:

This code modifies the registry string CLSID to the correct format. Then it pushes the parameters in the following order:

• dword_4CA22C: This is the third parameter - PHKEY phkResult.
• off_4CA040: This is the second parameter - LPCSTR lpSubKey.
• dword_4CA000 - 1: This is first parameter - HKEY hKey (root).

So its function is to open HKCR\clsid\{d66d6f99-cdaa-11d0-b822-00c04fc9b31f}.

Task 3. The malware dynamically resolves Windows API function names in memory, and decrypts a large blob of data, which function is responsible for grabbing the encrypted blobs? Provide address in hex

As we analyzed in Task 1, the malware uses Dynamic API Resolution to allocate memory using the function sub_4016B0 (allocate_memory). The return value of VirtualAllocEx is the base address of the allocated memory. Using the reference function, we see that this function is used in the start function.

1
int __cdecl start(int a1)
2
{
3
  int v1; // ecx
4
  int v3; // ecx
5
  unsigned int v4; // [esp+4h] [ebp-14h]
6
  int v5; // [esp+10h] [ebp-8h]
7
  int savedregs; // [esp+18h] [ebp+0h] BYREF
8

9
  if ( LoadCursorA(0, (LPCSTR)0x142D) )
10
    sub_401130(v1);
11
  v5 = ((int (__cdecl *)(WCHAR *, int, int, _DWORD, int, int, _DWORD))CreateFileW)(word_4CA044, 1, 3, 0, 3, 128, 0);
12
  if ( v5 != -1 && v5 )
13
    return 66;
14
  CreateFileW(word_4CA044, 1u, 3u, 0, 3u, 0x80u, 0);
15
  GetDriveTypeW(&RootPathName);
16
  if ( LoadCursorA(0, (LPCSTR)0x142D) )
17
    sub_401130(v3);
18
  dword_4CA0BC = a1;
19
  dword_4CA09C = (int)&savedregs;
20
  dword_4CA080 = 131100;
21
  sub_401170();
22
  v4 = 0;
23
  off_4CA040[5] = 92;
24
  off_4CA040[6] = 123;
25
  if ( dword_4CA0DC(dword_4CA000 - 1, off_4CA040, &dword_4CA22C) )
26
  {
27
    while ( v4 <= 0xE && dword_4CA0DC(dword_4CA000 - 1, off_4CA040, &dword_4CA22C) )
28
      ++v4;
29
  }
30
  dword_4CA0C4 = (int)sub_4014F0(); // grab encrypted data
31
  dword_4CA084 = sub_401180(dword_4CA0C4);  // size of payload
32
  dword_4CA0C8 = (int)allocate_memory(dword_4CA084); // allocate buffer to save payload
33
  dword_4CA088 = dword_4CA084;
34
  dword_4CA0AC = 0;
35
  dword_4CA0B0 = 0;
36
  while ( 1 )
37
  {
38
    sub_401100(dword_4CA0A4, dword_4CA088);
39
    sub_401100(dword_4CA0A4, dword_4CA088);
40
    if ( dword_4CA0AC >= (unsigned int)dword_4CA084 )
41
      break;
42
    sub_401100(dword_4CA0A4, dword_4CA088);
43
    dword_4CA0A4 = 68;
44
    dword_4CA0A8 = 31;
45
    dword_4CA08C = sub_401100(68, dword_4CA088);
46
    dword_4CA0C0 = dword_4CA0AC + dword_4CA0C8;
47
    sub_4011B0(dword_4CA0AC + dword_4CA0C8, dword_4CA0B0 + dword_4CA0C4, dword_4CA08C);
48
    dword_4CA0B0 += dword_4CA0A4 + dword_4CA0A8;
49
    dword_4CA0AC += dword_4CA0A4;
50
    dword_4CA088 -= dword_4CA08C;
51
  }
52
  sub_401000(dword_4CA0C8, dword_4CA084);
53
  dword_4CA094 = dword_4CA0C8 + 552656;
54
  return sub_401130(dword_4CA0C8 + 552656);
55
}

Look at the pseudocode of the sub_4011B0 function.

1
int __cdecl sub_4011B0(int a1, int a2, unsigned int a3)
2
{
3
  int result; // eax
4
  unsigned int i; // [esp+4h] [ebp-4h]
5

6
  for ( i = 0; ; ++i )
7
  {
8
    result = 523;
9
    if ( i >= a3 )
10
      break;
11
    *(_BYTE *)(i + a1) = *(_BYTE *)(i + a2);
12
  }
13
  return result;
14
}

The sub_4011B0 function essentially copies byte-by-byte from the source memory area to the destination memory area, up to a maximum of 3 bytes, and always returns 523 (0x20B). So the function responsible for grabbing the encrypted blobs is located at address 0x4011B0.

Task 4. The malware uses a dynamic key for decryption, What is the initial decryption key used to decrypt the encrypted blobs (word size)?

At the end of the start function, we see it calls the sub_401000 function with two parameters: a buffer containing the payload and the payload length. This is most likely the payload decoding function.

1
int __cdecl sub_401000(int a1, unsigned int a2)
2
{
3
  int result; // eax
4

5
  result = 0;
6
  for ( offset = 0; offset < a2; offset += 4 )
7
  {
8
    dword_4CA230 = offset + a1;
9
    *(_DWORD *)(offset + a1) += offset;
10
    result = sub_401650(3, offset + 45238);
11
  }
12
  return result;
13
}
14

15
int __cdecl sub_401650(int a1, int a2)
16
{
17
  int result; // eax
18

19
  dword_4CA0D8 = a2;
20
  result = a2 ^ *(_DWORD *)dword_4CA230;
21
  *(_DWORD *)dword_4CA230 = result;
22
  return result;
23
}

It iterates through the buffer in 4-byte increments, and for each DWORD at a1+offset, it adds the offset and then XOR it with (offset+45238) to transform the data.

1
*(DWORD *)(a1 + offset) = ( *(DWORD *)(a1 + offset) + offset ) ^ (offset + 0xB0B6);

Task 5. What is the name of the first Windows API function decrypted

According to the functions we have analyzed, the sub_401650 function will perform the main encryption function and overwrite the data at dword_4CA230, which is dword_4CA0C8 + offset.

Using x32Dbg, jump to function sub_401650 at address 0x00401650.

1
push ebp
2
mov ebp,esp
3
sub esp,D8
4
mov eax,dword ptr ds:[4CA230]
5
mov dword ptr ss:[ebp-8],eax
6
mov ecx,dword ptr ss:[ebp-A8]
7
add ecx,4
8
mov dword ptr ss:[ebp-A8],ecx
9
mov edx,dword ptr ss:[ebp-A8]
10
add edx,4
11
mov dword ptr ss:[ebp-A8],edx
12
mov eax,dword ptr ss:[ebp-A8]
13
add eax,4
14
mov dword ptr ss:[ebp-A8],eax
15
mov ecx,dword ptr ss:[ebp+C]
16
mov dword ptr ds:[4CA0D8],ecx
17
mov edx,dword ptr ss:[ebp-8]
18
mov eax,dword ptr ds:[edx]
19
xor eax,dword ptr ds:[4CA0D8]
20
mov ecx,dword ptr ss:[ebp-8]
21
mov dword ptr ds:[ecx],eax

Set the breakpoint at address 0x004016A5, which is the command “mov dword ptr [ecx], eax”. The ECX register is a pointer to the DWORD in the buffer (the destination address).

Ultimately, we discovered that the first decoded value was a Windows API corresponding to GetProcAddress.

Task 6. What is the address of the ret instruction responsible for jumping to decrypted shellcode?

Looking at the function sub_401130, we can see the following code logic:

We see the following suspicious assembly instruction:

1
mov     esp, dword_4CA09C
2
mov     edx, edx
3
pop     ebp
4
mov     edx, edx
5
push    dword_4CA0B8
6
mov     edx, edx
7
push    dword_4CA090
8
mov     edx, edx
9
mov     ecx, dword_4CA094
10
jmp     short loc_401164

Instead of using the current stack, it takes the value at global dword_4CA09C and assigns it to ESP, after which the stack is moved to a different memory location.

Next, in the start function, instead of terminating the program as usual, the address of sub_401130 is placed in the eax register, then pushed onto the stack and the ret instruction is executed.

1
mov     eax, offset sub_401130
2
mov     edi, edi
3
mov     ecx, ecx
4
mov     edi, edi
5
push    eax
6
mov     edi, edi
7
mov     ecx, ecx
8
mov     edi, edi
9
retn

Because on the x86 architecture, the ret instruction takes the value at the top of the stack as the jump address (i.e., assigns that value to EIP), this action is equivalent to redirecting the execution thread to sub_401130.

This means the EIP will be assigned using the shellcode address stored in dword_4CA094. So the address of the ret instruction responsible for jumping to decrypted shellcode is 0x401167.

Task 7: Based on the memory allocated by the malware, what is the offset of the first instruction executed after decryption? in hex

From question 6, we identified that the address pointing to the start of the decrypted shellcode blob was stored in dword_4CA094. Looking at the start function, we see that it is formed by adding dword_4CA0C8 to 0x86ED0.

1
loc_4014A0:
2
mov     edx, dword_4CA084
3
push    edx
4
mov     eax, dword_4CA0C8
5
push    eax
6
call    sub_401000
7
add     esp, 8
8
mov     ecx, dword_4CA0C8
9
add     ecx, 86ED0h
10
mov     dword_4CA094, ecx
11
mov     edi, edi
12
mov     eax, offset sub_401130
13
mov     edi, edi
14
mov     ecx, ecx
15
mov     edi, edi
16
push    eax
17
mov     edi, edi
18
mov     ecx, ecx
19
mov     edi, edi
20
retn

Updates are ongoing…