<aside> 🎯
Command and Control (C2) [Definition] → Server is the main tool cyber threat actors use to launch and control cyber attacks. Attackers use C2’s to send commands to their malware and distribute malicious programs to victims.
</aside>
<aside>
</aside>
The goal of this section is to identify the command-and-control (C2) domain used by BRBBot malware to receive remote instructions. Through memory analysis, API tracing and decryption of the configuration file, the C2 Domain was identified.
<aside> ✏️
</aside>
Breakpoint → specific address or location in the code where you want the debugger to pause the execution at
API → Application programming interface, which is a set of functions and procedures allowing the creation of applications that access the features or data of an operating system or service
x64 DBug
pestudio
CyberChef
Microsoft Learn Documentation
<aside>
</aside>
| Tool: | Description: |
|---|---|
| PEStudio | Tool for analyzing PE (Portable Executable Files) can examine suspicious artifacts |
| Cyberchef | Web source tool that allows encoding, encryption and creating binaries and hexdumps |
| x64 DBug | An open-source binary debugger for Windows, aimed at malware analysis and reverse engineering of executables you do not have the source code for. |
| Microsoft Learn Documentation | Allows us to understand the API’s and functions called. Along with their syntaxes, and functionality. |
<aside> ⚒️
</aside>
When conducting dynamic analysis, we set a breakpoint on the “ReadFile” function to observe when and how the malware accessed the notable configuration file, “brbconfig.tmp.” The ReadFile API monitors the loading of the file brbconfig.tmp, which is the main focus of data, as it contains encrypted configuration data.
Upon examination, the file was loaded into memory, but its contents were encrypted. Through stepping through the execution in x64dbg and analyzing decompiled code in Ghidra, we were able to trace decryption with CryptoAPI functions such as:
This portion of x64dbg also shows the various calls to API’s like GetProcessHeap and GetTickCount, which signify the runtime checks and indicating active decryption.
Figure #2: Confirming the configuration file was being decrypted dynamically in memory.
<aside>
</aside>
This breakpoint shows the malwares entry breakpoint or original entry point (OEP), as shown in the information of “INT3 breakpoint "entry breakpoint" at a8321b29724435698fe66c5dd05bc03502186038cc7478f004aec12a89684706” on the searchbar.
Figure #3: Breakpoint set on HeapCreate, showing the entry breakpoint and original start of the malware
<aside>
</aside>
The, [rsp+30] points to: L"C:\Users\ITP\Desktop;C:\Windows\SYSTEM32;C:\Windows\system;...;C:\ProgramData\chocolatey\bin;C:\Python310\Scripts" which indicates a string that reflects the system’s PATH enviornment variable, reading the variable into memory which is likely to find the locations of the binaries. This is considered a pre-execution step where it gathers context before continuing to unpack payloads. We see the malware checking the computer’s environment, including folders like C:\Windows\SYSTEM32 and C:\Python310, potentially indicating the malware checking the system running onto proceeding to next stages of enumeration.