https://exploitreversing.

com

Malware Analysis Series (MAS):

Article 5
author: Alexandre Borges
date: September/14/2022 | rev: A

0. Quote
“Things go wrong. The odds catch up. Probability is like gravity: you cannot negotiate with gravity”.
(Det. James 'Sonny' Crockett | Miami Vice movie - 2006)

1. Introduction
Welcome to the fifth article of Malware Analysis Series (MAS). If readers haven’t read the first four
articles yet, all of them are available on the following links:
▪ MAS_1: https://exploitreversing.com/2021/12/03/malware-analysis-series-mas-article-1/
▪ MAS_2: https://exploitreversing.com/2022/02/03/malware-analysis-series-mas-article-2/
▪ MAS_3: https://exploitreversing.com/2022/05/05/malware-analysis-series-mas-article-3/
▪ MAS_4: https://exploitreversing.com/2022/05/12/malware-analysis-series-mas-article-4/
We have covered many different topics so far and, in a general way, the main goal continues being to
present fundamental concepts, and applied and practical approaches on malware analysis to help readers
to build up all necessary skills and move forward on their own analysis and learning path. As many readers
know, it isn’t my intention to propose hard samples because it’d be completely useless for an effective
learning and daily work, and in my opinion, would also be an unnecessary showing off behavior.
In the first four articles we presented, explained, applied, and learned techniques related to:
▪ malware profiling and main tools used to get fundamental information on malware samples.
▪ basic obfuscation (Control Flow Flattening) and anti-forensics concepts.
▪ main evidence’s items used to recognize a packed code and their associated challenges.
▪ usual and well-known unpacking tricks and how to fix IAT (Import Address Table) of extracted
binaries from memory.
▪ code injection review and managing DLL / API hashing resolution cases.
▪ unpacking methods and APIs to setup breakpoint over the unpacking procedure.
▪ how to write C2 data configuration extractors using Python, IDC, and IDA Python.
▪ how to write string de-deobfuscating scripts.
▪ relevant IDA Pro plugins commonly used over the analysis.
▪ .NET reflection concepts, internals unpacking and de-obfuscation.
▪ parsing and recognizing PE structures using IDA Pro.
▪ handling C++ structures through enumeration, local types, and structures.
1|Page
https://exploitreversing.com

Therefore, we’re ready to move forward and, in this article, we’ll be analyzing few features of Bumblebee
malware. As I’ve already mentioned previously, we don’t have any intention to dissecting it, but only some
interesting aspects of it.

2. Acknowledgments
I’d like to publicly thank Ilfak Guilfanov (@ilfak) and Hex-Rays (@HexRaysSA) for supporting this project
by providing me with a personal license of the IDA Pro.
My gratitude is endless because certainly I couldn’t keep writing this series without a personal license
(without depending on corporate licenses).
Honestly, I don’t have enough words to say how happy, thankful, and fortunate I feel myself in receiving
their help. Although it’s already much more than I would be able to dream in receiving, last June/2022 Ilfak
and Hex-Rays once again kindly agreed in helping me by providing new licenses of IDA Pro for other
platforms due to new series I’ve just started writing and planned to release as soon as possible. Personally,
all words from Ilfak expressing his trust and praise about this series of articles until now are the most
important for me.
Once again: thank you for everything, Ilfak.

3. Environment Setup
This article has a lab setup using the following environment:
▪ Windows 11 running in a virtual machine. You’re able to download a virtual machine for VMware,
Hyper-V, VirtualBox or Parallels from Microsoft on: https://developer.microsoft.com/en-
us/windows/downloads/virtual-machines/. If you already have a valid license for Windows 11, so
you can download the ISO file from: https://www.microsoft.com/software-download/windows11

▪ IDA Pro or IDA Home version (@HexRaysSA): https://hex-rays.com/ida-pro/ . I’ll be using IDA Pro
version 8.x and, mainly, the Hex-Rays Decompiler in this article.
▪ x64dbg(@x64dbg): https://x64dbg.com/
▪ PEBear (@hasherezade): https://github.com/hasherezade/pe-bear-releases
▪ DiE (from @horsicq): https://github.com/horsicq/DIE-engine/releases
▪ CFF Explorer: https://ntcore.com/?page_id=388
▪ HxD editor: https://mh-nexus.de/en/hxd/
▪ Resource Hacker: http://www.angusj.com/resourcehacker/
▪ Malwoverview: https://github.com/alexandreborges/malwoverview
▪ Floss: pip install -U flare-floss | https://github.com/mandiant/flare-floss/releases/tag/v2.0.0
▪ Capa: pip install -U flare-capa | https://github.com/mandiant/capa/releases
To get further information about lab configuration, I recommend readers to reserve some time to review
the first and second articles of this series. Both articles present concepts about the unpacking topic and
other details that, eventually, could be useful.
2|Page
https://exploitreversing.com

4. References
I could find several articles analyzing Bumblebee and, although I haven’t had the opportunity to read them
(my time is incredibly short), I recommend readers to do it because they were written by excellent security
researchers and companies, which covered and analyzed several aspects of the same family, and readers
can learn what’s more appropriate for their work. The list below doesn’t have any preferred order:
▪ https://blog.google/threat-analysis-group/exposing-initial-access-broker-ties-conti/
▪ https://blog.sekoia.io/bumblebee-a-new-trendy-loader-for-initial-access-brokers/
▪ https://blog.cyble.com/2022/06/07/bumblebee-loader-on-the-rise/
▪ https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/bumblebee-loader-
cybercrime
▪ https://research.nccgroup.com/2022/04/29/adventures-in-the-land-of-bumblebee-a-new-
malicious-loader/
▪ https://www.cynet.com/blog/orion-threat-alert-flight-of-the-bumblebee/
▪ https://www.proofpoint.com/us/blog/threat-insight/bumblebee-is-still-transforming

5. Recommended Blogs and Websites

There’re many excellent cyber security researchers keeping blogs and writing amazing articles related to
reverse might be interested in reading and following their contents. I tried googling to make a quick and
sorted list in alphabetical order as follow below:

▪ https://hasherezade.github.io/articles.html (by Aleksandra Doniec: @hasherezade)

▪ https://malwareunicorn.org/#/workshops (by Amanda Rousseau: @malwareunicorn)
▪ https://captmeelo.com/ (by Capt. Meelo: @CaptMeelo)
▪ https://csandker.io/ (by Carsten Sandker: @0xcsandker)
▪ https://chuongdong.com/ (by Chuong Dong: @cPeterr)
▪ https://elis531989.medium.com/ (by Eli Salem: @elisalem9)
▪ http://0xeb.net/ (by Elias Bachaalany: @0xeb)
▪ https://cyb3rops.medium.com/ (by Florian Roth: @cyb3rops)
▪ https://hex-rays.com/blog/ (by Hex-Rays: @HexRaysSA)
▪ https://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering (by Jiří Vinopal:
@vinopaljiri)
▪ https://kienmanowar.wordpress.com/ (by Kien Tran Trung: @kienbigmummy)
▪ https://www.inversecos.com/ (by Lina Lau: @inversecos)
▪ https://maldroid.github.io/ (by Łukasz Siewierski: @maldr0id)
▪ https://voidsec.com/member/voidsec/ (by Paolo Stagno: @Void_Sec)
▪ https://www.ragingrock.com/AndroidAppRE/ (by Maddie Stone: @maddiestone)
▪ https://azeria-labs.com/writing-arm-assembly-part-1/ (by Maria Markstedter: @Fox0x01)
▪ https://github.com/mnrkbys (by Minoru Kobayashi: @unkn0wnbit)
▪ https://repnz.github.io/ (by Ori Damari: @0xrepnz)
▪ https://windows-internals.com/author/yarden/ (by Yarden Shafir: @yarden_shafir)

3|Page
https://exploitreversing.com

Certainly, there’re several other excellent blogs explaining concepts and applied techniques about
mentioned topics. I’ll include these references as soon as I learn about them in next articles.

6. Gathering Information
We’ll be examining the following sample:
57c4bdf0a644df4fd39f3d73d4570e6c88d8b7239ab4a395dba441ab15a5024f.

As usual, we should acquire initial information about our sample, which is available to download from
Malware Bazaar:

[Figure 1] Check and download the binary from Malware Bazaar

Readers can unzip (using 7z e <zip file>) the malware sample and there will be a file with .img extension.
Afterwards, it’s quite easy to use the 7z command to “unpack” this .img file and we’re going to find the
following files:

[Figure 2] Unzipped files from .img file

Likely, the best approach is to examine them in the following order: the .bat file, the link file and, finally,
the DLL binary.

4|Page
https://exploitreversing.com

[Figure 3] Checking the inf.bat content and decoding the .lnk file

[Figure 4] Decoding the .lnk file – truncated output for saving space
In few words, we learned from figures above that:
a. the order of execution is: ScannedDocuments-0622.lnk → inf.bat → information.dll
b. the DLL is a 64-bit binary and one of its exported functions named hKOgtkmCis is executed.
Thus, it’s clear for us that we must analyze the DLL (this time is 64-bit) to understand what the threat does.
However, before proceeding, let’s collect further information that could, eventually, help us:

5|Page
https://exploitreversing.com

[Figure 5] Verifying the extracted DLL against Virus Total

6|Page
https://exploitreversing.com

[Figure 6] Checking the extracted DLL against Triage

We’ve learned new information:
▪ The malware seems to be, in fact, Bumblebee.
▪ The malware has anti-virtual machine techniques to detect VirtualBox and uses BIOS information
probably to detect virtual machines.
▪ It enumerates processes, but it could have different goals like anti-debugging technique and code
injection, for example.
▪ There’re many C2 servers which are likely store in encrypted format within the malware.
▪ The botnet’s name is: 146l
From this point, we have possible tasks to accomplish like:
▪ Collecting further information about the binary itself.
▪ Checking whether the malware is packed or not.
▪ If it’s packed, so we need to unpack it.
▪ Writing a script to extract C2 information.
▪ Collecting additional information about malware’s features.
Using PEBear, we have:
7|Page
https://exploitreversing.com

[Figure 7] Checking Imported and Exported Functions

As expected, the binary has few imports (only one DLL: kernel32.dll), so it’s likely packed, and exports
one function/routine (the same present in the .bat file), which is the “real entry point” in this case.
To unpack this DLL, we can use x64dbg and try to setup the breakpoint on few functions like to investigate
unpacked PE file in the memory (self-injection or remote injection). However, pay attention to one detail:
it’s recommended to configure these breakpoints after debugger having hit the binary’s entry point:
▪ VirtualAlloc( )
▪ ResumeThread( )
Before starting the unpacking procedure, there’s a simple step that always helps during analysis (not
necessarily in this binary), mainly when readers are analyzing a sample dynamically using debuggers:

8|Page
https://exploitreversing.com

disabling system or binary’s memory randomization (also known as dynamic rebasing) to prevent the
executable of being allocated in different memory addresses each time it’s executed.
To accomplish this task readers could take three approaches:
▪ Disabling memory randomization globally on the system:

▪ Creates a Registry’s entry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory
Management → MoveImages=dword:00000000

▪ Reboot the system.

▪ Disabling binary’s memory randomization (possibility of executable in being allocated in different

memory regions each time is called) using CFF Explorer:

[Figure 8] Disabling DLL moving in the memory

▪ Disabling binary’s memory randomization feature (dynamic rebasing) using command line:

▪ Download and extract setdllcharacteristics tool (from Didier Stevens -- @DidierStevens):

https://blog.didierstevens.com/my-software/#setdllcharacteristics

▪ setdllcharacteristics.exe -d <binary>
Usually, people prefer acting on the binary instead of the system, but it a personal decision of each one.
Remember from previous articles of this series, the recommended approach to debug a DLL is to use the
rundll32.exe (C:\Windows\System32) and pass the DLL and the respective exported function (or ordinal
9|Page
https://exploitreversing.com

number) as argument. Thus, launch the x64dbg, open the rundll32.exe into debugger and go to File |
Change Command Line and alter its content as shown below:
▪ "C:\Windows\System32\rundll32.exe"
C:\Users\Administrator\Desktop\ARTICLES\MAS_5\mas_5_dll.bin,hKOgtkmCis

Restart/reload the x64dbg session (CTRL+F2) and the debugger will stop at System Breakpoint. Run once
(F9) and debugger will hit the Entry BreakPoint. Now you can configure breakpoints on the functions
mentioned previously. If you want, after hitting the first break point, you can setup a breakpoint at
beginning of exported function (hKOgtkmCis) by following the standard procedure: CTRL+G and enter
mas_5_dll.bin.hKOgtkmCis.
Readers will realize that they’re not able to get anything by following the dump of data pointed by
VirtualAlloc’s returned address (RAX). Nonetheless, you’re able to see a ERW region as shown below:

[Figure 9] x64dbg – unpacking the malware

In the figure above, I only visualized the Memory Map view, searched for ERW sections and quicky found
the unpacked binary.
However, as explained in previous articles, there’re multiples ways to find a PE executable on memory, and
one of them is by searching for a given string over all memory regions.
To execute this operation, we can try the “Find Pattern…” option (CTRL+B) and enter a string that help us
to find the PE executable. In this case I’ve tried using “This program” string.
Take care: some malware threats wipe the PE header, so looking for this string might not work!

10 | P a g e
https://exploitreversing.com

[Figure 10] x64dbg – searching strings

[Figure 11] x64dbg – results of our search

Many addresses have been found, but only the first three ones are not loaded DLLs.

11 | P a g e
https://exploitreversing.com

We have to right-click each one of the found addresses and then choosing Following in Dump:

[Figure 12] x64dbg – unpacked PE binary

Once you’re there, right click on Dump area → Follow in Memory Map → right click → Dump Memory to
File:

[Figure 13] x64dbg – saving unpacked PE binary

12 | P a g e
https://exploitreversing.com

Open the extracted binary onto PEBear and readers will see a binary with IAT destroyed, but it isn’t any
problem. As the unpacked malware has been dumped from memory, so it’s in “mapped format” and its
respective addresses represent the memory addresses and not the raw (on disk) addresses:

[Figure 14] PE Bear: extracted binary presenting issues with Imports

To fix it, readers must go to “Section Hrds” tab and perform the following operations for each section: 1.
Make Raw Addr. equal to its respective Virtual Address; 2. Calculates the Raw Size of each section (next
section address minus current section address) and copy the resulting value to Virtual Size:

[Figure 15] PE Bear: aligned sections

13 | P a g e
https://exploitreversing.com

[Figure 16] PE Bear: fixed Imports

Save the fixed file (right-click “mas_5_unpacked” and pick-up “Save the executable as” option) and keep it
together with original malware sample and extracted one (before fixing). It’s always recommended to save
all artifacts within an only folder.
There’re good indicators this binary is the final unpacked version because there’re many DLLs (not only
one), a suggestion of networking communication (WS2_32.dll – WinSock2) , strings related to virtual
machine detection (we’ll see them while analyzing the sample using IDA Pro later) and other clues.
Before proceeding to the analysis section, I’d like to quickly review some concepts about Assembly x64
because this sample is our first binary written for 64-bit systems.

7. Reviewing x64 assembly concepts

Likely readers already know about calling conventions and I wouldn’t touch on this topic, but eventually I
could prevent problems to new reverse engineers, so I’d like to leave some few words here.
While most malware samples continue being released for x86 architecture (32-bit), we have seen an
increasing number of threats written for x64 architecture like the Bumblebee sample being analyzed in this
article and clearly all attackers will be migrating to 64-bit in next years.
In x86 (32-bit) architecture, which 32-bit values are returned into EAX register, 64-bit values are returned
through EDX:EAX and registers such EBP, ESI, EDI and EBX are restored at the end of function, we have:
▪ __stdcall
o The callee is responsible for cleaning the stack.
o All arguments are passed onto the stack by value.
o All Win32 APIs use this standard.
o Functions using this calling convention requires a function prototype.
o The _stdcall is used by Microsoft compilers.

14 | P a g e
https://exploitreversing.com

▪ __cdecl
o The caller is responsible for cleaning the stack.
o At same way of __stdcall, arguments are passed onto the stack.
o This calling convention is the default one for C and C++ programs.
o The __cdecl is used in Microsoft compilers.
o Variadic functions use this convention because the callee don’t know how many arguments
were passed.

▪ __fastcall
o This convention is only applied to x86 architecture.
o In Microsoft compilers, first two arguments are passed by register (ECX and EDX,
respectively). All remaining arguments are passed via stack. Other compilers use different
scheme.
o The callee is responsible for cleaning the stack.

▪ __thiscall
o It’s the convention used for C++ class member functions on x86 architecture.
o The callee is responsible for cleaning the stack.
o The “this” pointer is passed through ECX register.
o “this” pointers are available for non-static C++ member functions.

▪ __clrcall
o This determines that a function can only be called from a managed code.
o It must be used for virtual functions called from managed mode.
o This convention can’t be used for functions being called from native code.

▪ __vectorcall
o Arguments are passed through registers (when possible).
o This convention used more registers than __fastcall .
o Only supported in x86/x64 native processors with SSE2 support.
o Three types of arguments can be passed by register in vectorcall: integer, vector, and
homogenous vector aggregate types.
o The _vectorcall is used in Microsoft compilers.
In x64-bit architecture, things a bit different because there’s only one calling convention (x64 __fastcall)
and many other details:
▪ All parameters and values are 64-bit (QWORD).
▪ The returned value goes to RAX.
▪ The concept of shadow home (as well known as home space) comes up. In few words, the shadow
home (allocated by the caller) aims to reserve a space (0x20 bytes) for callees to save the first 4
parameters that are being passed even that there isn’t any parameter being passed!
▪ If the callee has any local variable, so it’ll allocate an additional space for them in addition to the
0x20 bytes (32 bytes).

15 | P a g e
https://exploitreversing.com

▪ If the shadow home is not used for storing function’s parameters (because there isn’t any), so the
compiler uses this space to save non-volatile registers.
▪ The first four parameters are passed to RCX, RDX, R8 and R9 registers, respectively. All remaining
parameters are passed on the stack.
▪ The caller (non-leaf function) usually saves volatile registers such as RAX, RCX, R8, R9, R10 and
R11 because they can be changed by callee. Other register like XMM4 and XMM5 are also saved.
▪ The callee saves R12, R13, R14, R15, RSI, RDI, RSP, RBX (non-volatile) and restores them later.
▪ The caller (non-leaf function) is responsible for allocating space for parameters being passed to
callee, which makes the usage of variadic functions easier.
▪ The stack must be aligned in 16 bytes. Usually, it’s not an issue, but functions such as malloc( ) and
alloca( ) might broken this alignment.

A possible picture to illustrate a non-leaf function being called follows (we aren’t considering alloca()
function neither a frame pointer being used):

Return Address

Local Variables and Saved

Non-Volatile Registers

Stack Parameters

R9 home space

R8 home space

RDX home space

RCX home space

[Figure 17] Possible x64 stack organization

There’re many other quite relevant details about x64 assembly:

▪ x64 executable follows the PE32+ format.
▪ RxD (R8D, R9D,...): 32-bit
▪ RxW (R8W, R9W,...): 16-bit
▪ RxL (R8L, R9L,..): 8-bit

16 | P a g e
https://exploitreversing.com

▪ The x64 code supports instruction pointer-relative data addressing (RIP relative addressing). In
other words, it’s possible to access data at location that’s away by an offset from the current
pointer.
▪ In binaries containing PIC (Position Independent Code), the address is not stored “in the
instruction”, but only an offset from the current instruction pointer (RIP).
▪ Functions can’t allocate space at the middle of the code like may occur in x86, but only at their
beginning. Therefore, there aren’t pop and push instructions at the middle of the function.
Because of this rule, the stack size keeps constant over the function’s life.
▪ Most of the time, RSP register acts as stack pointer and frame points, but there’s an exception:
alloca( ).
▪ PE32+ binaries have an additional section named .pdata (as known as Exception Directory), which
holds information used for handling exceptions.
▪ The GS register is used to access the TEB (Thread Environment Block) from the user mode, but it is
also used to access the KPCR (Kernel Processor Control Region) when the code is executing from
kernel mode.
▪ If readers don’t know about KPCR, there’s one for each logical processor and it represents a
structure that contains general information about the processor and its status. Use the WinDbg (or,
in some case, SysInternals’ livekd) and try: a. dt nt!_KPCR ; b. dt!_KPRCB; c. !pcr commands.
If readers have spare time to examine the Windows system, there’re many examples about details
mentioned above. For example, in the function below, non-volatile registers are being saved before
function continuing:

[Figure 18] Disassembling a kernel function: saving non-volatile registers

A DPC (Deferred Procedure Call) is queued from ISR (Interrupt Service Routine), which must be executed
very quickly, to accomplish the “most part of the task” not done by the ISR.
In other words, DPCs (through DpcForIsr or CustomDpc routines) are responsible for finishing tasks
initiated by ISR (for example, an I/O operation) and are called from an arbitrary DPC context at
DISPATCH_LEVEL (IRQL).
Returning to our theme, readers can clearly notice that KiExecuteAllDpc( ) (figure above) is a callee saving
all non-volatile registers before continuing for restoring them later.
Of course, over this long function, there’re many pieces of code that offer other demonstrations related to
we’re talking about. For example, the next piece of code shows a function being called
(EtwTraceLongDpcMitigationEvent( )) and six arguments being passed to it: first four arguments through
registers (RCX, RDX, R8D, R9D) and other two through the stack ([RSP+20h] and [RSP+28]). Pay attention
to a detail: all arguments are passed using mov instruction (and variants), and not push instructions:
17 | P a g e
https://exploitreversing.com

[Figure 19] Disassembling a kernel function: passing arguments through register and stack
Finally, that’s a good example of non-volatile parameters being restored in a late point:

[Figure 20] Disassembling a kernel function: restoring non-volatile registers

Of course, readers don’t need to use this specific function and, eventually, could try any function called by
nt!KiExecuteAllDpc( ) whether don’t want to “change” to another scope. For example, to list functions
being called by nt!KiExecuteAllDpc( ), execute:

[Figure 21] Listing functions called by a given function

18 | P a g e
https://exploitreversing.com

Click on any called function and try to perform a similar and very quick analysis. Additionally, if reader want
to examine and learn a bit more about structures related to the function table entry for the given function
and even exceptions, it’s recommended to execute:

[Figure 22] Examining the function table structures and fields related to exception
I’m not sure whether readers already touched this stuff previous, but some few notes could be useful:
▪ BeginAddress: offset to the start point of the function. By adding this offset to the base of the
module, we get the address of the function.

▪ EndAddress: offset to the end point of the function.

▪ UnwindInfoAddress: it is a pointer to the unrolling information structure, which describes the

correct way that stack should be unrolled whether an exception occurred.

▪ All three fields (BeginAddress, EndAddress and UnwindInfoAddress) make part of the
_RUNTIME_FUNCTION structure, which is located inside .pdata section.

▪ When an exception occurs, the first step is to use the RIP to search for an entry from this structure
that describes the current function.

▪ We should note that several registers are listed as non-volatile, so they must be saved before the
function overwriting them and, later, they will be recovered when it’s appropriated. Furthermore,
the remaining flags tell use a bit more about the context:

▪ UWOP_ALLOC_LARGE: Allocates a large area on the stack. If the operation info is equal to 1, so
part of the allocation (512K up to 4GB – 8 bytes) is recorded in the next two slots. If the
operation info is zero, then the size of the allocation (136 to 512K – 8 bytes) would be recorded
in the next slot.

19 | P a g e
https://exploitreversing.com

▪ UWOP_ALLOC_SMALL (not shown): it represents the size of the allocation (allocations between
8 and 128 bytes).
▪ UWOP_PUSH_NONVOL: this unwind operation code means a push of a non-volatile, which
decrements RSP by 8.
▪ UWOP_PUSH_NONVOL: this unwind operation code indicates that function saves a nonvolatile
integer register on the stack using a MOV instead of a PUSH.
Picking up a function from stack we have:

3f0 = 3c0 + (4 * 8) + 8 + 8 , where:

▪ 3c0: ALLOC_LARGE
▪ (4 * 8): five registers pushed.
▪ 8: return address’s size
▪ 8: UWOP_ALLOC_SMALL

UWOP_ALLOC_SMALL = (op info) * 8

+8=0*8+8=8

[Figure 23] Correlating details

20 | P a g e
https://exploitreversing.com

There’re other quite relevant details that, sometimes, are very useful for the daily job in reverse
engineering and programming. For example, functions can be declared with naked attribute and, as a side
effect, these functions don’t have prolog and neither epilog. We can use naked function in a trampoline
function, which is responsible for restoring the overwritten instructions, while writing a hooking
program.
As probably readers already know, hooking is a legal mechanism used for monitoring, instrumentation,
and extension of a target function. In the malware world, it’s also a technique used by the malicious
binary to modify the system aiming to hide multiple artifacts and activities.
Hooking can be performed inline or at the IAT (Import Address Table), for example. At the end, the general
idea is having the following execution flow:
▪ Original function is called.
▪ The inline hooking at its beginning takes effect and redirects the execution to the malicious
function.
▪ At end of the malicious function, the execution flow is redirected to the trampoline function.
▪ The trampoline function restores the overwritten instructions.
▪ The trampoline function jumps to the original (hooked) function to executing the remaining
instructions.
Anyway, I don’t have intention to enter in detail about hooking in this article and, probably, I will return to
this topic in future texts.

8. Reversing: first part

Let’s proceed to the reversing phase. Of course, I don’t have any plan or intention to be very detailed in
this analysis because it isn’t necessary and because we’ll have several opportunities to do it over this long
series of articles. Furthermore, based on my experience, the best approach to teach something for
professionals is by exposing topics gradually without a big changing of the difficult level to allow readers to
get used to the terms and techniques and, intuitively, learn all necessary concepts.
I’ll be using IDA Pro 8.x and, mainly, the Hex-Rays Decompiler to get further understand of each explained
details and then from this point onward is done assuming readers are using the same tools. Just in case
you aren’t, so try to adapt explanations to your scenario and context.
I’ll be analyzing the mas_5_unpacked.bin file that’s resultant from our unpacking procedure. As usual, it’s
recommended to accomplish few steps before proceeding the analysis:
▪ Decompile the entire binary: File | Produce File | Create C File. Save the C file in the same directory
of the unpacked binary.

▪ Load important libraries (remember: the sample is 64-bit) for analysis: View | Open Subviews |
Type Libraries (SHIFT+F11 hotkey) and insert libraries (INS hotkey) such as:

▪ ntapi64_win7
▪ ntddk64_win7 (it’s usually necessary while analyzing kernel drivers)
21 | P a g e
https://exploitreversing.com

▪ mssdk64_win7 (usually inserted automatically).

It’s also advisable to add some signatures (once again, remember: the sample is 64-bit), which will help us
in most of reversing cases. Thus, go to View | Open Subview | Signatures (SHIFT+F5 hotkey) and insert
(INS key) the following library modules:
▪ vc64rtf
▪ vc64ucrt
▪ vc64seh
Once reader already have the decompiled binary and loaded the main libraries and signatures, so open a
Pseudo Code window and configure it side-by-side with the Assembly View window and synchronize it
with the IDA View (right click → Synchronize with). Additionally, it’s interesting to check strings
(SHIFT+F12) to help us as an extra guidance for our reversing work.
Readers will see several functions involving C++ over the code, so it’s also recommended to demangle C++
names by going to Options | Demangled Names and mark Names.
There’re so many interesting aspects over the code that’s hard to choose a point to starting the analysis.
For example, by visualizing strings (SHIFT+F12 hotkey), we find several clues about what could being done
by the code. Thus, part of these strings follows below:

▪ powershell ▪ CreateProcessA ▪ ZwWriteVirtualMemory ▪ procexp.exe

▪ VirtualBox ▪ CreateProcessW ▪ EnumProcessModulesEx ▪ dumpcap.exe
▪ LogonUserA ▪ qemu-ga ▪ CreateRemoteThreadEx ▪ PETools.exe
▪ LogonUserW ▪ CreateMailslotA ▪ \\Windows ▪ Fiddler.exe
▪ cmd.exe /c ▪ CreateSemaphoreW Mail\\wab.exe ▪ VBoxVideoW8
▪ User name: ▪ OpenProcessToken ▪ ROOT\\CIMV2 ▪ vdagent.exe
▪ In-Reply-To ▪ SeDebugPrivilege ▪ ShowWindow ▪ NtAdjustPrivilegesToken
▪ FindWindowW ▪ NtQueueApcThread ▪ regmon.exe ▪ NtAllocateVirtualMemory
▪ QueueUserAPC ▪ CreateNamedPipeA ▪ idaq64.exe ▪ wscript.exe /E:vbscript
▪ tasks ▪ NtCreateThreadEx ▪ LordPE.exe ▪ NtQueryInformationThread
▪ BOCHS ▪ NtQueueApcThread ▪ windbg.exe ▪ CreateToolhelp32Snapshot
▪ Domain ▪ idaq.exe ▪ x32dbg.exe ▪ ZwQueryInformationProcess
▪ WinExec ▪ VBoxWddm ▪ x64dbg.exe ▪ autoruns.exe
▪ beast.http ▪ FileName ▪ Identifier ▪ vboxtray.exe
▪ LdrUnloadDll ▪ DeviceId ▪ VIRTUALBOX ▪ PostQueuedCompletionStat
▪ VcFFI2Rj6t15 ▪ VEN_VBOX ▪ MACAddress us
▪ VMWare ▪ NtCreateProcessEx ▪ VirtualBox ▪ Win32_Process
▪ MapViewOfFile ▪ IsDebuggerPresent ▪ prl_cc.exe ▪ autorunsc.exe
▪ FindNextFileA ▪ WriteProcessMemory ▪ VMSrvc.exe ▪ Wireshark.exe
▪ Injection-Date ▪ LdrHotPatchRoutine ▪ mscoree.dll ▪ ImportREC.exe
▪ IsWow64Process ▪ vboxvideo ▪ wscript.exe ▪ \\\\.\\VBoxGuest
▪ GetProductInfo ▪ ZwReadVirtualMemory ▪ ollydbg.exe ▪ ACPIBus_BUS_0
▪ CryptImportKey ▪ GetNativeSystemInfo ▪ tcpview.exe ▪ vdservice.exe
▪ FindFirstFileA ▪ NtCreateDebugObject ▪ procmon.exe ▪ SOFTWARE\\Wine
▪ FindFirstFileW ▪ RtlDecompressBuffer ▪ filemon.exe ▪ procexp64.exe
▪ procexp.exe
[Figure 24] Main strings ▪found in the unpacked sample
dumpcap.exe
▪ PETools.exe 22 | P a g e
▪ Fiddler.exe
▪ VBoxVideoW8
▪ PNPDeviceID
https://exploitreversing.com

▪ prl_tools.exe ▪ HARDWARE\\ACPI\\DSDT\\VBOX__ ▪ SELECT * FROM

▪ HookExplorer.exe ▪ HARDWARE\\ACPI\\RSDT\\VBOX__ Win32_NTEventlogFiles
▪ SysInspector.exe ▪ HARDWARE\\ACPI\\FADT\\VBOX__ ▪ SYSTEM\\ControlSet001\\Ser
▪ joeboxserver.exe ▪ VirtualBox Shared Folders vices\\VBoxSF
▪ httpdebugger.exe ▪ System32\\vboxoglcrutil.dll ▪ SYSTEM\\ControlSet001\\Ser
▪ VideoBiosVersion ▪ System32\\drivers\\viofs.sys vices\\netkvm
▪ SELECT * FROM ▪ D:\\Sources\\boost_1_78_0\\boost/ ▪ Copyright (c) by P.J. Plauger,
Win32_ComputerSystem beast/http/impl/verb.ipp licensed by Dinkumware, Ltd.
▪ Win32_ProcessStartup ▪ D:\\Sources\\boost_1_78_0\\boost/ ALL RIGHTS RESERVED.
▪ SELECT * FROM beast/http/impl/read.hpp ▪ SELECT * FROM
Win32_ComputerSystemPro ▪ D:\\Sources\\boost_1_78_0\\boost/ Win32_NetworkAdapterConf
duct beast/http/impl/write.hpp iguration
▪ ImmunityDebugger.exe ▪ System32\\drivers\\VBoxSF.sys ▪ void __cdecl
▪ Checking reg key %s ▪ System32\\vboxoglpackspu.dll boost::beast::http::message<
▪ System32\\vboxogl.dll ▪ System32\\drivers\\balloon.sys 1,struct
▪ \\\\.\\pipe\\VBoxTrayIPC ▪ System32\\drivers\\pvpanic.sys boost::beast::http::basic_stri
▪ VBoxTrayToolWndClass ▪ System32\\drivers\\vioscsi.sys ng_body<char,struct
▪ System32\\vboxdisp.dll ▪ System32\\drivers\\viostor.sys std::char_traits<char>,class
▪ System32\\vboxhook.dll ▪ %WINDIR%\\System32\\wscript.exe std::allocator<char> >,class
▪ System32\\vboxtray.exe ▪ SELECT * FROM Win32_PnPEntity boost::beast::http::basic_fiel
▪ System32\\vboxmrxnp.dll ▪ SELECT * FROM Win32_BaseBoard ds<class std::allocator<char>
▪ SELECT * FROM Win32_Bus ▪ SELECT * FROM Win32_PnPDevice > >::prepare_payload(struct
▪ Z:\\hooker2\\Common\\md ▪ System32\\drivers\\VBoxMouse.sys std::integral_constant<bool,1
5.cpp ▪ System32\\drivers\\VBoxGuest.sys >)
▪ ProcessStartupInformation ▪ System32\\drivers\\VBoxVideo.sys

[Figure 25] Main strings found in the unpacked sample (second part)
Based on the list from Figure 24 and 25, few considerations follow below:
▪ Clearly the malware threat detects a series of debuggers and tools like Ollydbg, IDA Pro (idaq.exe),
Immunity Debugger, WinDbg, x64/x32dbg, Process Hacker, Process Monitor, Bochs and so on.
The array containing all tool’s names was renamed to searched_tools[ ].

▪ The sub_18004D60 subroutine (renamed to ab_DetectRunningTools()), which is used to detect

these tools above, is called three times (check cross references through X hotkey). In addition, it’s a
called within a loop (with a Sleep( ) call) and if a process named with any one of these strings is
found, so the malware execution is terminated (TerminateProcess( ))

▪ The sub_18004D60( ) itself calls sub_180050380( ), which contains a typical sequence of calls such
as CreateToolhelp32Snapshot( ) + Process32FirstW( ) + Process32NextW( ). In few words, these
last two calls are used to parse the snapshot result.

▪ A relevant point as this routine sub_180050380( ) (we renamed it to ab_SearchProcesses) that

searches for processes is well-used by the malware and is called six times from other parts of the
code, so maybe is a good point to do follow-up.
23 | P a g e
https://exploitreversing.com

[Figure 27] Common subroutine searching for specific

running processes

[Figure 26] Debuggers and Tools verified by

malware

▪ The malware threat also detects through sub_18004FAB0 (renamed to ab_DetectVirtualMachines)

whether the malware is running on virtual machines like VMWare, VirtualBox or Xen. Additionally,
it also uses VMI queries (WQL) to detect the virtual environment.

▪ Indeed, WMI will be used several times to help on detecting virtual environments artifacts and, as
readers are going to notice, COM (Component Object Model) will be involved in this context. In
few pages we’ll return to this subject.

▪ Another anti-analysis approach used by the sample is detecting sandboxes and testing virtual
machines artifacts and, in special, common usernames used by test/sandboxes environments. The
subroutine sub_18004F860 (renamed to ab_CheckUserNames) is responsible for it and readers can
see that there’s a list of them shown in Figure 28 (next page).

24 | P a g e
https://exploitreversing.com

[Figure 29] Checking if the system’s memory has

less than 4GB.

[Figure 28] Usernames verified by the malware

threat

▪ The malware, through sub_18004FA40( ) (renamed to ab_CheckMemory), uses a well-known trick

for testing whether the system has 4GB at least because it’s usual public sandboxes or even virtual
environments using less than it. To get the task done, the GlobalMemoryStatusEx( ) API is used,
which returns both physical and virtual memory.

▪ An interesting subroutine is sub_180050270 (renamed to ab_checkMACAddress) that is

responsible for retrieving the MAC address from the network adapter using GetAdaptersInfo( ),
which gets adapter information (only for IPv4) for the local system. In general, its behavior is like
other cases on Windows system programming, where an API is called twice: the first one to get the
correct size of the necessary structure and the second one to allocate and use it. Readers notice
that the sub_180050270 is parsing all retrieved MAC addresses and verifying whether any of them
matches to the given argument. The function GetAdaptersInfo( ) has the following signature:

o IPHLPAPI_DLL_LINKAGE ULONG GetAdaptersInfo(PIP_ADAPTER_INFO AdapterInfo,

PULONG SizePointer)

25 | P a g e
https://exploitreversing.com

▪
[Figure 30] Checking MAC Addresses

26 | P a g e
https://exploitreversing.com

[Figure 31] _IP_ADAPTER_INFO structure used by GetAdaptersInfo( )

▪ The subroutine sub_18004F280( ) (renamed to ab_checkWineRegistryEntry) checks for Wine

Registry’s entry:

[Figure 32] Checking for Wine within Registry

▪ The subroutine sub_18004D280( ) (renamed to ab_CheckVBoxHW) searches for several different
VirtualBox hardware artifacts. Please, check the whole subroutine on Figure 33 (next page).

▪ The string "Checking reg key HARDWARE\\Description\\System - %s is set to %s" refers directly to
the code of a well-known project to detect virtual machines, which readers can easily search for on
the Internet.

▪ There’re other similar subroutines such as sub_18004D3D0 (checks for VirtualBox Services),
sub_18004D520 (checks for VirtualBox processes), sub_18004D520 (checks for VirtualBox
executables, DLLs, and drivers), sub_18004D790 (checks for VirtualBox Guest Additions),
sub_18004D8C0 (checks for VirtualBox devices and pipes used for IPC and debugging) and
sub_18004D9E0( ) that checks for VirtualBox shared folders.

27 | P a g e
https://exploitreversing.com

▪ Additionally, there’re two calls for FindWindowW( ) to check for windows related to VirtualBox:

[Figure 33] Subroutine used to check for the VirtualBox hardware artifacts.

▪ There’re other many functions checking VirtualBox, VirtualPC, BOCHS, QEMU and other artifacts:

▪ sub_18004DA80( ): checks for running VirtualBox processes.

▪ sub_18004DB30( ): checks for VirtualBox MAC addresses through WMI and COM APIs.
▪ sub_18004DD10( ): checks for VirtualBox Video Adapter using COM + WMI.
▪ sub_180004E3F0( ): checks for VirtualBox Device.
▪ sub_18004EAB0( ): checks for VirtualBox Device.
▪ sub_18004E820( ): checks for VirtualBox manufacturer (Oracle).
▪ sub_18004E610( ): checks for VirtualBox buses.
▪ sub_18004FF10( ): checks for VirtualPC processes.
▪ sub_18004ED40( ): checks for Qemu Registry’s entries.
▪ sub_18004EE30( ): checks for Qemu Processes.
▪ sub_18004EEF0( ): checks for Qemu and SPICE Guest Tools.
▪ sub_18004F160( ): checks for BOCHS.
▪ sub_18004F340( ): checks for VirtIO services.

28 | P a g e
https://exploitreversing.com

▪ sub_18004F680( ): checks for VirtIO directory.

▪ sub_18004F460( ): checks for VirtIO drivers.
▪ sub_18004FE60( ): checks for Parallels processes.
Finally, an overview of sub_18004CD50 (renamed ab_checkVirtualMachinesAndTools), which invokes all
anti-analysis routines mentioned above, follows:

29 | P a g e
https://exploitreversing.com

[Figure 34] Subroutine invoking different virtual machines checks.

Other few details I haven’t commented about:
▪ Process Explorer 64-bit process (procexp64.exe -- from SysInternals) is checked whether it is
running or not on line 8.

▪ wine_get_unix_file_name’s address is retrieved on line 15 to be used with Wine detection function

(ab_checkWineRegistryEntry( )).
As we’ve mentioned on pages 24 and 28, there’s the usage of COM and WMI functions over several anti-
analysis routines that are responsible for detecting tools and different hypervisor frameworks. Therefore,
eventually it would be interesting to analyze one of these pieces of code involving such COM APIs.
At beginning of the ab_DetectVirtualMachine subroutine (sub_18004FAB0), the subroutine
sub_180050460 is called and, if readers step into the subroutine, they will find several APIs related to
COM such as:
▪ CoInitializeEx
▪ CoInitializeSecurity
▪ CoCreateInstance
▪ CoUninitialize
30 | P a g e
https://exploitreversing.com

▪ CoSetProxyBlanket
The respective code is shown below:

[Figure 35] Subroutine including many calls using COM APIs.

We already mentioned and managed code involving COM in previous articles, but it might be useful to
remember about few concepts related to the technology.

9. Few words about COM

In general words, COM (Component Object Model) was designed to work in a distributed computing
model (Client/Server, RPC, distributed objects) and one of its goals was extending the communication
concepts at that time, by offering advantages to developers for making easier to write COM objects in any
language and exporting their respective functionalities to be consumed by programs in general.

31 | P a g e
https://exploitreversing.com

A COM object exposes its interfaces (well-defined interfaces) to make easy and possible any client to use
its services. In this case, it isn’t important whether the client is or not at the same machine/system. Indeed,
an interface is only a set of functions, and objects and clients can communicate to each other through
them.
However, let’s make it clear: a client interacts with pointers to interfaces and don’t have access to
anything else inside the interface. A COM object (an instance of a class) can implement multiple
interfaces, but it’s also important to highlight that the class must implement all functions defined by an
interface (even doing nothing).
Server and clients can communicate to each other through a pair of proxy and stub objects, which the
proxy works as a server representation of a remote server running in the client address space and the
stub is a sort of listener running on the server side and waiting for client requests. In other words, a
possible scheme to illustrate it is the following one:
▪ invoke method -> interface -> local proxy -> remote stub -> interface -> remote method
Once again, clients consume services through interfaces offered by COM object, but don’t have any idea of
services’ implementation, which is a well-known encapsulation example (as already mentioned earlier).
A COM object is an instance of a COM class (classes can be instantiated, but interfaces can’t). It
represents an object definition and implements the IUnknown interface, which is the base interface of all
interfaces in COM and that, at least, supports QueryInterface method (used for service discovering). In
other words, the QueryInterface( ) returns a pointer to the requested interface back to the client.
A COM component, which is a binary module represented by an executable (the server is implemented as
a standalone executable module ) or DLL (the server is implemented as a module to be loaded and
executed within the address space of the client), also supports concepts of inheritance and
polymorphism besides other security features, offered by interfaces, such as access control and
impersonation. The COM’s lifetime is managed by the usage of reference count through
IUnknown::AddRef and IUnknown::Release methods.
The general idea on how a COM binary is built up is shown below:

[Figure 36] Representation of part of a COM object (adapted, but based on COM Specification and
“Learning DCOM” book by L. Thai Thuan, which was released in 1999)
Few points of the image above:
▪ vtbl: virtual table (table of function pointers).
▪ vptr: virtual table pointer to the vtbl.

32 | P a g e
https://exploitreversing.com

▪ IUnknown interface: as explained, it’s the parent of all COM interfaces and it’s used, through the
IUnknown::QueryInterface method, to find dynamically other interfaces and perform lifetime
management through IUnknown::AddRef and IUnknown::Release methods.
Therefore, each instantiated object has an own associated vptr, although there’s only one vtbl per class.
To recap:
▪ An interface is composed by one or more functions.
▪ A class is the implementation of one or more interfaces.
▪ An object is the instance of a COM class.
▪ A binary is composed by one or more COM classes.
▪ Classes can be instantiated, but interfaces can’t be instantiated.
▪ Each instantiated object has an own vptr.
▪ There’s only one vtbl per class.
▪ A COM component can be represented by an executable (standalone process) or DLL (loaded into
the client’s process).
▪ Proxy runs in the client side and stub runs on the server side as a listener.
There’s a different kind of COM object named Factory that is responsible for creating and/or instantiating
other COM objects associated with a determined COM class. In this case, standard factories are
represented by IClassFactory interface, which is derived from IUnknown interface. Requests received by
IClassFactory to instantiate a COM object triggers IClassFactory::CreateInstance, which is responsible for
accomplishing the task. Thus, we have that: COM Factory -> COM Object.
Class factories and COM objects can be packed into either an executable or DLL file. If they are packed as
an executable, so they can run as a service or local/remote server in a different execution context from
COM client. Furthermore, executable COM classes can be registered using CoRegisterClassObject( ). If they
are packed as a DLL, so it’s an in-process server and are usually loaded by the client.
In the COM world, a function can be invoked using two different approaches:
▪ Static Invocation:

▪ That’s the invocation of a method (and respective signature) in compile-time.

▪ All methods are called through a vtbl: interface pointer -> vptr --> vtbl
▪ There’s an alternative technique to invoke methods through type libraries (from an interface
repository) and dispatch interface as well known as IDispatch.
▪ All methods from a dispatch interface are called through a dispatch identifier (dispid).

▪ Dynamic Invocation:

▪ This method is also known as late binding.

▪ It’s supported by IDispatch interface, which can be used to discover and invoke methods.
However, to use this method demands a lookup operation for the dispid.
In other words, an application interface is derived from IUnknown interface and, of course, inherits pure
virtual functions that need to be implemented.

33 | P a g e
https://exploitreversing.com

There’re many COM functions and, among them, we have CoCreateInstance( ), which creates a COM
object, is one of most important, for sure:

[Figure 37] CoCreateInstance function

Its parameters, as described on MSDN, are:
▪ rclsid: The CLSID associated with the data and code that will be used to create the object.

▪ pUnkOuter: If NULL, indicates that the object is not being created as part of an aggregate. If non-
NULL, pointer to the aggregate object's IUnknown interface (the controlling IUnknown).

▪ dwClsContext: Context in which the code that manages the newly created object will run.

▪ riid: A reference to the identifier of the interface to be used to communicate with the object.

▪ ppv: Address of pointer variable that receives the interface pointer requested in riid.

We have strict interest on three these parameters: rclsid, riid and ppv. The clsid and riid are referenced by
a respective GUID (128-bit hexadecimal), which each one of them are unique (eliminates any chance of
name collision), and that classes and interfaces can be referred . One key aspect of interfaces is that they
are immutable then they are not versioned.
COM classes are registered into the operating system and identified by these GUIDs, which are used as a
representation of the class within Registry:
▪ HKLM\Software\Classes\CLSID
▪ HKCU\Software\Classes\CLSID
As readers likely already learned from other articles, during a COM hijacking attack, malware and
adversaries could establish persistence by replacing a legit COM entry in the Registry or even enumerating
CLSID subkeys such as LocalServer32 and InProcServer32 to discover abandoned binary references, which
is not so rare due to failed uninstallation processes.
In terms of nomenclature associated to Registry:
▪ Server: it’s a binary that’s referred by the CLSID inside of Registry.
▪ LocalServer32 key: it’s the path to an executable (.exe) implementation.
▪ InProcServer32 key: it’s the path to a dynamic linked library (.dll) implementation.
The fundamental COM APIs used to write COM clients are:
▪ CoInitialize( )/CoInitializeEx( )

34 | P a g e
https://exploitreversing.com

▪ CoCreateInstance( )
▪ CoUninitialize( )
The CoCreateInstance( ) calls internally the CoGetClassObject( ) to get a class factory that through
IClassFactory::CreateInstance to create the requested COM object. Moreover, CoGetClassObject( ) is
commonly used to create multiple objects for a given class object .

10. Reversing: second part

Now we can resume from where we stopped (the subroutine sub_180050460 and, more precisely, in the
code referred by Figure 35), and handle details related to COM functions.
Right before the calling for CoCreateInstance( ), there’re five arguments passed to the function, which riid,
rclsid and ppv are the most important ones:

[Figure 38] Arguments passed to CoCreateInstance function

Examining rclsid and riid we have the following:

[Figure 39] Content of arguments passed to CoCreateInstance function

Both rclsid and riid are represented by a GUID struct, which has the following composition:

[Figure 40] GUID structure

35 | P a g e
https://exploitreversing.com

To decode GUIDs (as known as UUID – Universally Unique Identifier) we can use a simple script written in
IDC as shown below:

[Figure 41] IDC script to decode GUID Structure

Once the script has been executed then we can use the GUID( ) function. To decode the CLSID and IID we
must pass the address of the start of their structures as shown below:
▪ GUID(<rclsid address>) = GUID(0x00000001800B1418): 4590F811-1D3A-11D0-891F-
00AA004B2E24
▪ GUID(<riid address>) = GUID(0x00000001800C4670): DC12A687-737F-11CF-884D-00AA004B2E24
There’re many ways to get the appropriate information and meaning of found CLSID and IID, and one of
them is using the OleView .NET (https://github.com/tyranid/oleviewdotnet) or COMView
(https://www.japheth.de/COMView.html). For example, searching for the CLSID on OleView .NET we have:

[Figure 42] OleView .NET: searching for Class ID details

36 | P a g e
https://exploitreversing.com

Of course, we always have the option (and, in many times, it’s an easier way) to google it on the Internet
and soon we can find some important and related information:
▪ https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-wmi/46710c5c-d7ab-
4e4c-b4a5-ebff311fdcd1.
Personally, I like to search about COM information and definitions on the following Microsoft website:
▪ https://referencesource.microsoft.com
Querying by the interface ID (DC12A687-737F-11CF-884D-00AA004B2E24) we got:
[InterfaceTypeAttribute(0x0001)]
[TypeLibTypeAttribute(0x0200)]
[GuidAttribute("DC12A687-737F-11CF-884D-00AA004B2E24")]
[ComImport]
interface IWbemLocator
{
[PreserveSig] int ConnectServer_([In][MarshalAs(UnmanagedType.BStr)] string strNetworkResource,
[In][MarshalAs(UnmanagedType.BStr)] string strUser, [In]IntPtr strPassword,
[In][MarshalAs(UnmanagedType.BStr)] string strLocale, [In] Int32 lSecurityFlags,
[In][MarshalAs(UnmanagedType.BStr)] string strAuthority, [In][MarshalAs(UnmanagedType.Interface)]
IWbemContext pCtx, [Out][MarshalAs(UnmanagedType.Interface)] out IWbemServices ppNamespace);
}

As a summary, we have:
▪ Class: WbemLocator
▪ InProcServer32: C:\Windows\system32\wbem\wbemprox.dll
▪ Interface: IWbemLocator
▪ Explanation: IWbemLocator interface is used to get a namespace pointer to IWbemServices
interface for WMI and, getting this pointer, we can access Windows Management by calling
IWbemLocator::ConnectServer.
Next step is to use this information to make the reversed code by IDA Pro easier to understand. There’re
two paths to proceed and the composition them can help us a lot:
a. The first method consists in changing the type (“Y” hotkey) of ppv parameter. It’s used as the
return of CoCreateInstance function and contains the requested interface point, and as its type is
LPVOID, so it’s necessary to make a cast. Thus, change it from from “LPVOID” to “IWbemLocator*”
as well any variable receiving its value. No doubts, performing this task on pseudo code produced
by the IDA Decompiler is always recommended, but it isn’t enough. Why? Because new functions
will come up and their arguments will need to be adjusted too.

b. The second path that could help us to get a better result is done by executing the following steps:

a. If the structure isn’t already added, so insert it (SHIFT+F9 and then INS) using the following
nomenclature: <interface name>.vbtl

37 | P a g e
https://exploitreversing.com

b. use the “T” hotkey to apply the structure over the disassembled code (mainly for calls).
Before applying changes, it’s relevant to show the pseudo code from IDA Decompiler:

[Figure 43] Decompiled sub_180050460 before applying any change

According to the previous page (based on query from https://resourcesource.microsoft.com website),
IWbemLocator interface has only one method: IWbemLocator::ConnectServer. This method creates a
connection to a WMI namespace that is named strNetworkResource. The returned value is only a
HRESULT value that indicates the status of the method call. The prototype of
IWbemLocator::ConnectServer method follows below:

[Figure 44] IWbemLocator::ConnectServer

38 | P a g e
https://exploitreversing.com

After applying a list of changes, which are explained in the next paragraphs, we get the following result:

[Figure 45] sub180050460: parameters renamed and re-typed

I’ve changed both pseudo and assembly code. On pseudo-code, the most important changes have done by:
▪ Renaming (“N” hotkey) a2 to ppv because the names of CoCreateInstance( ) on MSDN.
▪ Changing ppv’s type (“Y” hotkey) to IWbemLocator ** (check the interface type that we found and
described on page 37).
▪ Editing the CoCreateInstance( ) signature (“Y” hotkey) for changing the type of ppv to
IWbemLocator **.
▪ Renaming (“N” hotkey) a1 to ppNamespace (following the same name of the last argument for
IWbemLocator::ConnectServer( ) from MSDN).
39 | P a g e
https://exploitreversing.com

▪ Changing the type (“Y” hotkey) of ppNamespace argument to IWbemServices ** according to the
expected name of the function IWbemLocator::ConnectServer described on MSDN.

▪ Editing the signature (“Y” hotkey) of the IWbemLocator::ConnectServer and changing type of the
ppNamespace argument to IWbemServices ** according to the expected name of the function
described on MSDN.
On the assembly side, I’ve used the T hotkey to apply the correct type for any call instruction using
indirection within this subroutine (sub_180050460) and according to the pseudo code.
If readers compare Figures 43 and 45, so you’ll notice a better result and, this time, it’s possible to
interpreter the code, although it would be possible to improve it.
There’re some necessary explanations about what’s happening so far:
▪ CoCreateInstance( ) creates one object that is an instance of a given class (WbemLocator , given by
the CLSID) on the local system .
▪ The class is the implementation of one or more COM interfaces and the interface is given by the
iid parameter (IWbemLocator).
▪ Remember that an interface is really a class containing functions defined as pure virtual, which
must be implemented by an implementation class.
▪ The clients access the virtual pointer (vptr) that is a reference to the virtual table containing
functions’ pointers to real functions.
▪ The final COM binary (DLL / exe) can be composed by one or more classes.
▪ Clients don’t communicate with the class directly, but through interfaces. At same way, clients
don’t need to know where a COM object is located nor its respective implementation because, as
stated, the interface is the main point of contact.
▪ All interfaces inherit from the IUnknow interface, which has three methods: AddRef( ), Release( )
and QueryInterface( ).
▪ The QueryInterface( ) aims to query an object for a given interface.
▪ The CoCreateInstance( ) returns, as output in the ppv parameter, an interface pointer to the
IWbemLocator.
▪ The IWbemLocator interface has only one method that’s ConnectServer( ), which is responsible for
creating a connection to a WMI namespace using its first parameter (strNetworkResource).
▪ The output from IWbemLocator::ConnectServer( ) is its seventh parameter (Figure 44), which
receives a pointer to an IWbemServices object. That’s the reason by which we changed its type.
▪ So far, the malware code can connect to WMI and, in specific, to ROOT\CIMv2 namespace and get
a pointer to IWbemServices interface and make next calls.
▪ The CoSetProxyBlanket( ) function is used to set the authentication information that will be used
to make calls through a proxy. Its fourth and fifth parameters with value 3 are saying that it’s
authenticating only at beginning of each RPC when the server receives the request, and the server
process can impersonate the client's security context while acting on behalf of the client.
As readers can realize, a simple piece of code can contain many subtle information and concepts that
might help us to have a better understanding of the what’s happening. Of course, analyzing each piece of
code in details might be time-consuming, but in several opportunities there isn’t other alternative.

40 | P a g e
https://exploitreversing.com

Continuing our analysis, go up and return to ab_DetectVirtualMachines( ) subroutine (sub_18004FAB0)

and realize that there’re other many functions related to COM. The key starting point is on the line 9,
where the subroutine sub_180050460, which just analyzed, is called. As we learned, the sub_180050460’s
parameters were a pointer to IWbemService interface and a pointer to IWbemLocator interface. Thus, we
can use them and perform the same job we did previously using MSDN to learn about associated types and
outputs, and we obtained the following result:

[Figure 46] sub_18004FAB0 (ab_DetectVirtualMachines): after re-typing and renaming operations

41 | P a g e
https://exploitreversing.com

Please, readers should observe I used a feature of IDA Pro named “Collapsing Local Declarations” before
taking a snapshot, so readers should do the same to match the same lines which I’m referring to.
Afterwards, few comments follow:
▪ On line 9, the type declaration of the first parameter of the call for sub_180050460 is
IWbemServices *ptr_IWbemServices.
▪ On line 9, the type declaration of the second parameter of the for sub_180050460 is
IWbemLocator *ptr_IWbemLocator.
▪ On line 12, string containing the WQL query is formed (“SELECT * FROM
Win32_ComputerSystem”). The Win32_ComputerSystem class holds a series of members
(properties) representing information from the local system.
▪ The IWbemServices::ExecQuery( ) on line 17 executes the given query above to retrieve possible
objects. The output of this method in stored into the fifth (and last) parameter (ppEnum), with has
the following type’s declaration: IEnumWbemClassObject *ppEnum. In general words, this last
parameter (ppEnum) holds an enumerator that will be used to access query results. Readers should
notice that this parameter is copied to a variable on line 30.
▪ Using the obtained enumerator through ExecQuery( ), the code parses each available property by
using IWbemClassObject::Next( ) on line 34.
▪ On line 38, it’s possible to get properties values using IWbemClassObject::Get method. In this case,
the code is checking “Model” property and looking for strings such as “VirtualBox”, “HVM domU”
and “VMware”.
▪ After having all checking’s, the code releases all objects by using the inherited Release( ) method
from IUnknown interface and closes the COM library on the current thread by calling
CoUninitialize( ).
Readers will find COM code over several different malware code, and I hope it can help you to get a better
understanding about how to analyze COM functions. If the reader to check other parts of the code that are
using CoCreateInstance( ), so you will be able apply a similar approach:

[Figure 47] Finding new subroutines calling CoCreateInstance

Let’s proceed with our analysis and continuing our investigation. The ab_DetectVirtualMachines( )
subroutine (sub_18004FAB0 -- check Figure 43) is being called (list cross-references to the function using
X hotkey) by ab_checkVirtualMachinesAndTools( ) (sub_18004CD50 --- check Figure 31).
42 | P a g e
https://exploitreversing.com

According to the experience, this kind of checking for virtual environments is usually performed at the
beginning of the malware execution and, most of times, right before something useful being done by the
malicious code. Therefore, by listing which subroutines are calling sub_18004CD50, we reach the
subroutine sub_18000A120 and, apparently, new findings are possible:

[Figure 48] A piece of sub_18000A120 subroutine

43 | P a g e
https://exploitreversing.com

11. Reversing: difficulties during the analysis

Soon at the beginning of sub_18000A120 subroutine, we have a call for the sub_180006F80 subroutine
and, for this specific function, there’re four arguments. Once we move inside it, we find the following:

[Figure 49] First pseudo instructions of sub_180006F80 subroutine

As readers notice, there’s a repeated call for subroutine sub_180050974 with the string “invalid string
position” as argument, but IDA Pro didn’t identify the correct function for us. Additionally, there’re other
functions within sub_180006F80 subroutine that accepts strings arguments and also hasn’t been
identified.
If the malware’s author had used standard libraries from Microsoft / Visual C++, almost certainly IDA Pro
would have identified successfully. Therefore, we can make a hypothesis that external libraries were used
to generate the final malicious code.
In next few pages I’m going to scratch the surface of this topic and, certainly, there’re much more to be
explained and demonstrated, but I’ll restrict the focus on few approaches in this article.
One good resource to help us is the usage of Lumina, from IDA Pro, to populate and enrich the database
with further information. In few words, Lumina server provides function name, prototypes, comments,
operand types and other information about functions shared by Hex-Rays and other researchers. No
doubts, it’s possible alternative for us and it can always test it.
44 | P a g e
https://exploitreversing.com

Using Lumina is quite easy and simple. To apply Lumina definitions, go to Lumina menu and pick up pull all
metadata option (F12 hotkey) and Lumina’s metadata will enrich the idb database (most of them marked
in green). For example, at first lines of sub_18000A120 we have as result:

[Figure 50] First lines of sub_18000A120 including Lumina changes

I’ve highlighted the line 12 because it’s exactly one of additions provided by Lumina. Examining
std::string::assign function (sub_18000A120 subroutine) we have:

[Figure 51] First lines of std::string::assign function

45 | P a g e
https://exploitreversing.com

If metadata fetched my Lumina is correct (never believe it blindly), our first finding is that the malware
have used the Catch unit testing framework for C++. If readers don’t know about Catch, there’re good
references to it:
▪ https://catch2.docsforge.com/
▪ https://github.com/catchorg/Catch2
Initially, examining all functions from database, it seems that there’s only one Catch routine. Of course,
Lumina brought much more metadata for many functions and all of them can help us during our analysis:

[Figure 52] Functions populated by Lumina server

46 | P a g e
https://exploitreversing.com

As readers can realize, Lumina is able help us with C++ Template Libraries a lot and general C++ functions ,
for example.
Before proceeding, we have a very simple modifications in our database through the addition of new
library modules to Signatures tab (SHIFT+F5 hot key and INSERT key):
▪ vs64mfc
▪ msmfc64
The contribution of these modules is over 200 recognized functions. Fair enough.
The next important clue is that the sample has lots of strings associated to the Boost C++ library, as shown
below:

[Figure 53] Several strings indicating the presence of Boost C++ Library
There’s important information from the image above such as:
a. The malware is using boost C++ library: https://www.boost.org/
b. The author is using boost version 1.78 that’s available here:
https://boostorg.jfrog.io/artifactory/main/release/1.78.0/source/
c. There are clues that beast, which is a header-only library that serves as foundation to write
network interoperable libraries supporting HTTP, WebSocket and other networking skills, is also
present: https://github.com/boostorg/beast
Identify libraries used over the malware program is only the first step to try to tackle reversing problems
as, for example, unknown functions. As readers can realize, C++ functions and templates represents a
serious issue during the reversing tasks and managing this problem demands having further details in our
hands such as:
47 | P a g e
https://exploitreversing.com

▪ Identifying potential libraries and respective versions (strings command help in this task).
▪ Identifying the compiler and its version used to compile the malware code (DiE might helps us).
▪ Identifying the operating system and version used to compile the malware.
As I mentioned above, using DiE is useful for identifying the compiler and its version, as shown below:

[Figure 54] DiE helps us to identify the compiler and respective version.
As the figure above shows us, it seems the malware author used Microsoft Visual C++ 2015, what’s
awesome information. However, what version of Windows was used? It isn’t an easy task and, eventually,
we could try to find some evidence on the code using strings command.
I’ll be using Windows 8.1 and 11, and Visual Studio 2015 to simulating a possible environment and
compile the boost library. At the end, several individual libraries will be generated and, luckily, we could
help IDA Pro to recognize few functions. Of course, there’s a catch here: the malware author also used the
beast header-only library, so we should try something about it, but let’s move a step at time.
To compile the boost C++ library:
▪ Download and unpack the boost C++ version 1.78:
https://boostorg.jfrog.io/artifactory/main/release/1.78.0/source/
▪ Download the Visual Studio 2015 and install it and its respective SDK:
o (web installer) https://go.microsoft.com/fwlink/?LinkId=532606&clcid=0x409
o (iso image) https://go.microsoft.com/fwlink/?LinkId=615448&clcid=0x409

▪ Compile the boost library by going into its unpacked directory and executing the following:
o bootstrap.bat
o .\b2 --toolset=msvc-14.0

48 | P a g e
https://exploitreversing.com

[Figure 55] Generating Boost Libraries

The resulting libraries are saved into stage/lib folder, and we’re interested in the x64 version:

[Figure 56] Few x64 Boost libraries

Now we have all x64 libraries, readers can try to generate a signature file from each one of these libraries
using commands as pcf.exe and sigmake.exe, which comes from an IDA Pro version 8.0 package named
“flair80.zip” and needs to be downloaded from Hex-Rays website.

49 | P a g e
https://exploitreversing.com

The process to generate a signature file has the following steps:

▪ pcf libboost_filesystem-vc140-mt-x64-1_78.lib
▪ sigmake libboost_filesystem-vc140-mt-x64-1_78.pat libboost_filesystem-vc140-mt-x64-1_78.sig
Likely, an exclusion file would be generated and it’s your decision to decide which signatures will be kept.
The exclusion file has the following appearance:

[Figure 57] List of some x64 Boost libraries

In this specific case, there’re only 20 collisions and that’s our call to decide what signatures must or not be
kept. There’re some rules here (I remember that I learned them from Hex-Rays’ website and “The IDA Pro
Book” from Chris Eagle) :
▪ We must remove the first four lines to proceed. However, if we only remove these four lines and
save the file, so all respective signatures will be excluded from the final signature file (.sig file).
▪ Functions are organized by groups, so we must decide for one function from each group by
prefixing the chosen one with a ‘+’ (plus) signal or minus ‘-‘ (minus) to show a commentary in the
database always that a match happens.
▪ Never insert a plus (‘+’) or minus (‘-‘) to more than one function of a specific group.
▪ If the group has only one function, so don’t do nothing.
To generate the signature file, repeat the command:
▪ sigmake libboost_filesystem-vc140-mt-x64-1_78.pat libboost_filesystem-vc140-mt-x64-1_78.sig
Once the signature is generated, copy the file (libboost_filesystem-vc140-mt-x64-1_78.sig) to <IDA Pro
installation directory>/sig/pc folder (for example: C:\Program Files\IDA Pro 8.0\sig\pc). Once you’ve
done it, you can open the IDA Pro, go to Signatures view (SHIFT+F5 hotkey ) and insert the new library
module (INS key).

50 | P a g e
https://exploitreversing.com

For example, in this case, 175 functions were identified including only this library module:

[Figure 58] Listing library modules and, in specific, our library.

[Figure 59] Applied 175 signatures from our library module

[Figure 60] Some lines of the list of recognized

boost functions (this image also contains boost
functions populated by Lumina in light green)

51 | P a g e
https://exploitreversing.com

Of course, we should repeat the same process for each static library that we believed having been used in
the code. As readers can notice, it’s a time-consuming task.
There’re many other procedures that, eventually, might help you, but I suggest you try them using a
separated database. The success rate varies, but such procedures already helped in some cases.
Another scenario is that most of external libraries introduces many structure types that we don’t know
anything about them and, worse, we don’t have enough time to learn about them.
One of possible alternatives (actually, it’s a hack) to manage the lack of applied external structure data
types given by this sort of library follows below (there’re many ways to do the same steps here):
a. Write a program using the same library that you want to extract the structures’ definitions. Include
headers from this library to force them to be included in the final executable. It could seem hard,
but it isn’t because all these external libraries provide tutorial pages including many examples, so
you don’t need to learn everything about the library itself. Indeed, the program might be very
simple or even blank with a single main function since you include all headers you want to extract
definitions.

b. Configure the environment to use same compiler version that binary has been compiled. For
example, in this case, I’m using Visual Studio 2015 because we’ve identified it through the DiE
(Detect It Easy), and the same architecture (for example x64).

c. Don’t forget to include the headers to compile the program. In Visual Studio 2015: Properties |
VC++ Directories | Include Directories. For example:
C:\Users\Administrador\Desktop\MAS\MAS_5\boost_1_78_0\boost_1_78_0.

d. Don’t forget to include the compiled libraries to link the program. In Visual Studio 2015:
Properties | VC++ Directories | Library Directories. For example:
C:\Users\Administrador\Desktop\MAS\MAS_5\boost_1_78_0\boost_1_78_0\stage\lib

e. Disable any optimization. On Visual Studio 2015: Project Properties | C/C++ | Optimization |
Optimization: Disabled. At the same window, set “Whole Optimization” to No.

f. Don’t forget to setup to generate a Debug version (and not Release version). We need this setting
because the Visual Studio is going to generate a static library (or executable) and a respective pdb
file automatically.

g. This step is not valid for this VS 2015, but it’s recommended to Visual Studio 2022: Project
Properties | Configuration Properties | C/C++ | General and change “Scan Sources for Modules
Dependencies” to “Yes” and “Translate Includes to Imports” to “Yes (/translateInclude)”. This
setting will force the compiler to scan the code for dependencies to be included into header units.

h. Visual Studio allows you produce an executable (.exe), a DLL and a static library (.lib). My best
results were using static library because it forces everything to be included into a single file. You
can configure it going to Project Properties | Configuration Type | Static Library (.lib).

52 | P a g e
https://exploitreversing.com

i. Navigate to Project Properties | Configuration Properties | C/C++ | Precompiled Headers |

Precompiled Header and alter the setting to “Not Using Precompiled Headers”.

j. Compile the program. On Visual Studio: Build | Build Solution (CTRL+SHIFT+B). In the Output
window it’s going to be shown the folder where the static library file and its respective .pdb file
are saved.

k. After the program having been compiled, open the resulting .lib file onto the IDA Pro.

l. Now we want to generate an IDC file containing all structure type-definitions. Go to File | Produce
file | Dump typeinfo to IDC File. The recommendation is to use an output name following the
syntax: <program name>.idc. Avoid using something like <program name>.exe.idc on Windows.

m. Now comes the final part. Using the IDA Pro, apply this script into the malware’s idb you’re
analyzing. Go to File | Script File and execute the generated IDC script.

n. Many structure’s types will be created, and you can check for them on the Structure Tab
(SHIFT+F9).

o. Go to the the Decompiler tab (pseudo code tab) and press F5. Likely several structure type
definitions, created from the external library (headers), will be applied automatically.
Note: it is impossible to claim this trick (a hack) will work for you, but it helped previously. Of course, this
procedure might mess up your idb file (again: do a copy first), but trying doesn’t cost anything for you and,
if you’re lucky, you can get a reasonable result. Additionally, it presents a good advantage: it’s appliable to
any library used by malware authors and, in case you already know which libraries were used, so it’s worth
to try it once. Let’s me to provide a simple and concrete example about what I described here:
1. Create a new C++ project (Console Application), give it a name, and choose directory to save all
files from solution. Usually, I create an apart folder to each project. I could have added more
headers, but this example is only a demonstration. Note: the code below is NOT mine and, usually,
you won’t have enough time to learn about the library, but you should remember: the code could
be very short, only including headers because we are concerned with headers and nothing more.

2. Enter the following code from:

https://www.boost.org/doc/libs/1_80_0/libs/filesystem/example/tut2.cpp. I added few headers to
increase the number of structure types in my final library, but it should have much more headers:

53 | P a g e
https://exploitreversing.com

[Figure 61] Test code for type library extraction

3. Change the configuration type to “Static Library (lib)”:

[Figure 62] VS 2015: Configuration type

54 | P a g e
https://exploitreversing.com

4. Change “Include Directories” and “Reference Directories” settings as explained previous and as
shown below:

[Figure 63] VS 2015: VC++ Directories settings: Includes and Libraries Directories
5. Turn off any kind of optimization:

[Figure 64] VS 2015: Turning off optimizations

55 | P a g e
https://exploitreversing.com

6. Disable Precompiled headers:

[Figure 65] VS 2015: Turn off precompiled headers

7. Compile the project: Build | Build Solution (CTRL+SHIFT+B). Two main files will be generated:

a. <program name>.lib
b. <program name>.pdb

8. Open up the <programname>. lib on IDA Pro and choose <application name>.obj:

[Figure 66] IDA Pro: opening the .lib file

56 | P a g e
https://exploitreversing.com

9. Choose COFF (Windows AMD64) and, after this screen, choose loading the debugging symbols:

[Figure 67] IDA Pro: opening the .lib file

10. Confirm that there’re many functions coming from Boost C++ Library:

[Figure 68] IDA Pro: listing many Boost C++ functions

57 | P a g e
https://exploitreversing.com

11. Go to File | Produce file | Dump typeinfo to IDC File.

12. Open the target idb database on IDA Pro, go to File | Script File and load the saved IDC.
13. Go to the Structure types (SHIFT+F9) and verify that several new types have been created.
14. Go the pseudo code and press F5. All new type definitions will be applied to the code.
Check the instructions from line 146 to line 195 before the script being executed:

[Figure 69] IDA Pro: pseudo code before executing the IDC file
58 | P a g e
https://exploitreversing.com

Now readers should check the same instructions from line 146 to line 195 after the script has being
executed (it’s pretty different, isn’t?!):

[Figure 70] IDA Pro: pseudo code AFTER executing the IDC file
If you need to know any new type definition, double click on it:

59 | P a g e
https://exploitreversing.com

[Figure 71] New type definitions created by IDC

There’s a very important point here: my result might be completely sub-optimal. Why? Because I only
added few header files and Boost C++ Library has many header files. Therefore, if the readers have spare
time, so I invite you to add other header files (strings command can help you and provide a guideline of
headers to be included), and maybe your results will be a bit better than mine, which was shown on Figure
70. Virtually, many of these additional headers wouldn’t be necessary because Visual Studio brings them
into the compiled the program because dependencies, but it’s valid to make a test.
Anyway, my central idea here is explaining the technique and, afterwards, according to your case, you can
evaluate whether it’s worths or not.
If you’re looking for possible and available Boost C++ headers (version 1.78, according to our malware
sample), one starting point could be this one: https://www.boost.org/doc/libs/1_78_0/libs/libraries.htm .
If readers want to do a test including new headers, so the own Visual Studio can help you to add them
because while you’re typing includes it opens a list of header possible options, so it’s much easy to add
new ones. A suggestion of additional headers follows bellow just in case you want to try it:
▪ #include <boost/beast.hpp>
▪ #include <boost/beast/http.hpp>
▪ #include <boost/beast/core/basic_stream.hpp>
▪ #include <boost/beast/core/static_string.hpp>
▪ #include <boost/beast/core/basic_stream.hpp>
▪ #include <boost/beast/core/buffer_traits.hpp>
▪ #include <boost/beast/core/error.hpp>
▪ #include <boost/beast/core/file.hpp>
▪ #include <boost/beast/core/buffers_range.hpp>
▪ #include <boost/beast/core/buffers_range.hpp>
60 | P a g e
https://exploitreversing.com

▪ #include <boost/beast/core/stream_traits.hpp>
▪ #include <boost/beast/core/ostream.hpp>
▪ #include <boost/beast/core/buffers_to_string.hpp>
▪ #include <boost/beast/core/file_win32.hpp>
▪ #include <boost/beast/http/fields.hpp>
▪ #include <boost/beast/http/type_traits.hpp>
▪ #include <boost/beast/http/type_traits.hpp>
▪ #include <boost/beast/http/message.hpp>
▪ #include <boost/beast/http/status.hpp>
▪ #include <boost/beast/http/basic_parser.hpp>
▪ #include <boost/beast/http/impl/basic_parser.hpp>
▪ #include <boost/beast/http/impl/error.hpp>
▪ #include <boost/static_string.hpp>
There’re many other hacks that, eventually, could be helpful. One of these approaches to add external
type definitions to another idb database (in our case, the malware idb database) that I learned through a
comment from Igor Skochinsky (Hex-Rays’s developer -- @IgorSkochinsky ) on Stack Exchange | Reverse
Engineering website is the following one:
a. Using IDA Pro, open the ConsoleApplication1.idb, which is the same application that we’ve created
using Visual Studio and included all headers from Boost C++ Library.

b. Keeping the .idb file open, copy <program name>.til to another folder (I’ve copied it into the same
folder of IDA Pro because there I have the help’s support).

c. Using tilib64.exe (available from https://hex-rays.com/download-center/), execute: tilib64 -#-

ConsoleApplication1.til

d. Copy the resulting .til file to /til/pc folder (C:\Program Files\IDA Pro 8.0\til\pc).

e. Open the second .idb (in this case, the idb database of the malware we’re executing) and add this
new type library in the list (SHIFT + F11 and then INS).

f. Although the new type definitions won’t be shown in the Local Types tab, fortunately they will be
available through Structures tab (SHIFT+F9) by inserting a new structure (INS) and choosing “Add
standard structure”. Additionally, these structures are available for decompiler too.
According to Igor, this procedure is not officially supported and, as any other hacks, it could cause many
issues and conflicts in the idb file, so the same recommendation is valid: make a backup of the .idb file
before testing this approach.
Once again: these last two approaches are experimental and they can work or not. However, when you’re
analyzing a malware that include libraries and new types, so you could spend a considerable amount of
time to understand the existing new types and, eventually (maybe...maybe....), it could be useful for your
analysis. According to my experience, I never (ever) disregard any approach, suggestion or trick while
reversing code because they always can be useful at some moment, so any new knowledge is always
valuable and welcome.
61 | P a g e
https://exploitreversing.com

12. Reversing: third part

Let’s return to our normal path and continue analyzing the code. In special, we’re analying the subroutine
sub_1800A120. To education purposes, I’ll be using the idb version with Lumina functions applied (that’s
the best approach here), but without including results from last two procedures used to apply new
definition types from external C++ libraries because I’m not sure whether readers will have time to test
them. Anyway, this decision doesn’t change our analysis over this section.
We have the following code from sub_1800A120:

[Figure 72] sub_1800A120 function

There’re three interesting details on this figure:
▪ An explicit usage of a string “Vcffi2rj6t15” as argument of a function.
▪ The repeated appearance (four times) of two subroutines: sub_1800012D0 and sub_180001670.
▪ There’re fours references to different data-related addresses: asc_1800FF830, byte_1800FF790,
byte_1800FF7E0 and byte_1800FF340.

62 | P a g e
https://exploitreversing.com

As the string “Vcffi2rj6t15”, which could be a possible key, is being assigned to v120 local variable and,
afterwards, this v120 variable is being assigned to v4, v5, v6 and v7 local variables. Therefore, I renamed:
▪ v120 to var_key
▪ v4 to var_key_1
▪ v5 to var_key_2
▪ v6 to var_key_3
▪ v7 to var_key_4
If readers closely pay attention, the same string (Vcffi2rj6t15) is being passed to sub_1800012D0 over the
four times it’s called:

[Figure 73] sub_1800A120 function including few renamed variables

Entering into sub_1800012D0 we have:

[Figure 74] sub_180012D0 routine

63 | P a g e
https://exploitreversing.com

Examining the content of sub_180001360 routine we have:

[Figure 75] sub_18001360 routine

Although it can be a bit difficult to recognize at first view, it’s the initialization code of RC4 algorithm. The
“modulo 256” operation, which is present in usual RC4 initialization, has been replaced by the arithmetic
composed by code between lines 16 to 29.
As readers could remember, all line of code from this subroutine make part of the KSA (Key-Scheduling
Algorithm), which is used to initialize the permutation of starting array.
Every time you’re analyzing a potential encrypted data, once you determined the algorithm used, usually
they have requested inputs (given through local variables), which varies according to the algorithm. For
example, while analyzing RC4, we must determine:
a. Three arguments for KSA phase (RC4):
i. context
ii. key buffer
iii. key length

b. Three arguments for Encrypt/Decrypt phase (RC4):

i. context
ii. data buffer
iii. data length

64 | P a g e
https://exploitreversing.com

Of course, this “scheme” might change or having variants, but most of the time it happens this way.
Therefore, it seems that on Figure 75 the sub_180001360 has the following parameters’ meanings:
▪ a1 is the context
▪ a2 is the key
▪ a3 is the key length
Proceeding with the analysis, let’s examine the sub_180001670 -> sub1800014E0:

[Figure 76] sub_1800014E0 routine

Although the figure is a bit small, the line 20 is the following one:
▪ *(_BYTE *)(a2 + i) = (a1[(unsigned __int8)(v5 + v6) + 2] & 0x71 | ~a1[(unsigned __int8)(v5 + v6)
+ 2] & 0x8E) ^ (*(_BYTE *)(a2 + i) & 0x71 | ~*(_BYTE *)(a2 + i) & 0x8E);
Once again, it could not be so like the well-known RC4 encrypt algorithm representation, but it’s actually a
variation its form.
At the same way, in this decryption subroutine (sub_1800014E0) we have:
▪ a1 is the context
▪ a2 is the data buffer
▪ a3 is the data length
Therefore, I renamed the following subroutines to better names:
▪ sub_1800012D0 -> ab_w_RC4_INIT
▪ sub_180001360 -> ab_RC4_INIT
▪ sub_1800014E0 -> ab_RC4_DECRYPTION
▪ sub_180001670 -> ab_w_RC4_DECRYPTION
Thus, we’re already know the likely key and it’s time to follow the encrypted data, which show us the
following scenario:
▪ asc_1800FF830: db '127.0.0.1',0 renamed to: enc_data_1
▪ byte_1800FF790: char byte_1800FF790[80] renamed to: enc_data_2
▪ byte_1800FF7E0: char byte_1800FF7E0[80] renamed to: enc_data_3
▪ byte_1800FF340: char byte_1800FF340[1024] renamed to: enc_data_4
65 | P a g e
https://exploitreversing.com

After all renaming actions, we have:

[Figure 77] Part of sub_1800A120 subroutine after renaming

There’re three encrypted data because the first one is a plain text string. About the remaining three blobs,
one of them has a size of 1024 bytes and the other two ones have size of 80 bytes each, and all of them are
using the same decryption key.
We must write a script to extract and decrypt the data. As readers will see, enc_data_4 holds C2
IP’s/domains list, enc_data_3 holds the botnet and enc_data_2 apparently holds the campaign ID.
The initial information is about our target:
▪ key: VcFFI2Rj6t15
▪ section: .data
▪ name: enc_data_2 size: 80 start: 0x1800FF790
▪ name: enc_data_3 size: 80 start: 0x1800FF7E0
▪ name: enc_data_4 size: 1024 start: 0x1800FF340
The Python script will be written and tested using Jupyter Notebook (https://jupyter.org/) because it’s
much easier to debug the script. The final version follows below:

66 | P a g e
https://exploitreversing.com

[Figure 78] First part of script to extract and decrypt C2 List and botnet

67 | P a g e
https://exploitreversing.com

[Figure 79] Second part of script to extract

and decrypt C2 List and botnet

[Figure 80] Extracted and

decrypted C2 List

68 | P a g e
https://exploitreversing.com

If readers compare the output above against the list offered by Triage given by malwoverview tool or even
through the online report (https://tria.ge/220616-tng2tsfhfl), so you will notice that there’re a perfect
match for each IP address and botnet.
Actually, many quite interesting aspects are present in this binary and, undoubtedly, we could extend this
analysis over many pages. Anyway, there’s nothing special and, at end of the day, it’s only a work of
reading code, renaming variable and functions, re-typing, and interpreting APIs along the analysis.
Some functions that could be interesting:
▪ sub_180039CC0: read files
▪ sub_18004A32C: read files
▪ sub_180039B90: write file
▪ sub_18004AA18: write file
▪ sub_18003DF44: create process
▪ sub_180050380: enumerate processes
▪ sub_1800124B0: socket (receive data)
▪ sub_180012AA0: socket (send data)
▪ sub_180012030: socket configuration
▪ sub_180015360: socket configuration
▪ .data section: there’s two other PE executables embedded.

About the last statement, it’s quite easy to check it by running a simple strings.exe command:

[Figure 81] Confirming that there’re two other two executable within extracted payload
One of many way to extract PE file and other types of objects from a given binary is by using Binary
Refinery (https://github.com/binref/refinery), which is a sort of command line version of CyberChef.
To install Binary Refinery:
▪ pip install -U binary-refinery
or
▪ python -m venv test
▪ . ./test/bin/activate
▪ (test) $ pip install -U git+git://github.com/binref/refinery.git
To extract both embedded executable, we’re going to extract them into a file (payload_1) and, afterwards,
the second one to another file (payload_2), as shown below:
▪ emit mas_5_unpacked.bin | carve-pe -r | dump payload_1
▪ emit payload_1 | carve-pe | dump payload_2
Using the Binary Refinery, we’re able to visualize the necessary information about both files:
69 | P a g e
https://exploitreversing.com

[Figure 82] First DLL extracted using Binary Refinery

[Figure 83] Second DLL extracted using Binary Refinery

70 | P a g e
https://exploitreversing.com

As readers were able to notice, we extracted a 32-DLL and a 64-DLL payload. Don’t worry about payload_1
(32-bit DLL) having the second DLL inside it because, during an execution, only the first PE is regarded.
Do readers want to extract and decrypt the C2 List? It’s trivial because we already have the virtual
address, respective size and, most important, we also have the RC4 key (read page 66). Therefore, execute:

[Figure 84] C2 List extracted and decrypted by Binary Refinery

13. Conclusion
In this article, I presented the first 64-bit sample of the MAS Series as well as concepts related to x64
Assembly, COM (Component Object Model), managed difficulties in reversing code that use external
libraries, and extracted and decode the C2 List and its respective botnet.
Recently a professional (Twitter: @bushuo12) translated the three first articles of this series to Chinese
and, just in case you’re able to understand the language, Chinese versions follow below:
▪ (MAS): Article 1 -- https://www.yuque.com/docs/share/619f03dc-1bc9-42f7-828e-fc17d82786e7
▪ (MAS) : Article 2 -- https://www.yuque.com/docs/share/d16efbd6-e2e6-4325-9b9e-23c613bd2280
▪ (MAS) : Article 3 -- https://www.yuque.com/docs/share/7dca2583-8456-4ca5-8862-0524fc6faaf9
Just in case you want to keep in touch:
▪ Twitter: @ale_sp_brazil
▪ Blog: https://exploitreversing.com
Keep reversing and I see you at next time!
Alexandre Borges
71 | P a g e