0x1 - brbbot.md

Triage

Hashes

Hash Type	File Hash
MD5	1c7243c8f3586b799a5f9a2e4200aa92
SHA1	4db5a8e237937b6d7b435a8506b8584121a7e9e3
SHA-256	f47060d0f7de5ee651878eb18dd2d24b5003bdb03ef4f49879f448f05034a21e

OSINT & Sandboxes

VirusTotal

• The file sample is recognized as a 64-bit executable with persistence capabilities, which achieves persistence via a registry ASEP key.

• The sample appears to have been written in C++.
• The sample contains common capabilities such as:
  • Registry modifications (likely for persistence via ASEP key)
  • Interacts with the Winsock 2 API (basic TCP/IP networking capabilities)
  • Communications over HTTP (likely used for C2)
  • At least one persistence mechanism

• At this point in the analysis, we can conclude this is likely a simple sample that includes limited C2 functionalities. However, I see no indications of dropper capabilities, for example.

• A high degree of entropy in the .text section (6.35/8) might suggest packing. This possibility will be further investigated.

VirusTotal | Imports

ADVAPI32.dll

• CryptAcquireContextW
• CryptCreateHash
• CryptDecrypt
• CryptDeriveKey
• CryptDestroyHash
• CryptDestroyKey
• CryptEncrypt
• CryptHashData
• CryptReleaseContext
• RegCloseKey
• RegDeleteValueA
• RegFlushKey
• RegOpenKeyExA
• RegSetValueExA

WININET.dll

• HttpOpenRequestA
• HttpQueryInfoA
• HttpSendRequestA
• InternetCloseHandle
• InternetConnectA
• InternetOpenA
• InternetQueryDataAvailable
• InternetReadFile
• InternetSetOptionA

WS2_32.dll

• gethostbyname
• gethostname
• inet_ntoa
• WSACleanup
• WSAStartup

KERNEL32.dll

• CloseHandle
• CopyFileA
• CreateEventW
• CreateFileA
• CreateFileW
• CreateProcessA
• DecodePointer
• DeleteCriticalSection
• DeleteFileA
• EncodePointer
• EnterCriticalSection
• ExitProcess
• FindResourceA
• FlsAlloc
• FlsFree
• FlsGetValue
• FlsSetValue
• FlushFileBuffers
• FreeEnvironmentStringsW
• GetACP
• GetCommandLineW
• GetComputerNameA
• GetConsoleCP
• GetConsoleMode
• GetCPInfo
• GetCurrentProcess
• GetCurrentProcessId
• GetCurrentThreadId
• GetEnvironmentStringsW
• GetEnvironmentVariableA
• GetFileSize
• GetFileType
• GetLastError
• GetModuleFileNameA
• GetModuleFileNameW
• GetModuleHandleA
• GetModuleHandleW
• GetOEMCP
• GetProcAddress
• GetProcessHeap
• GetStartupInfoW
• GetStdHandle
• GetStringTypeW
• GetSystemDirectoryA
• GetSystemTimeAsFileTime
• GetSystemWow64DirectoryA
• GetTempFileNameA
• GetTempPathA
• GetTickCount
• GetVersion
• HeapAlloc
• HeapCreate
• HeapFree
• HeapReAlloc
• HeapSetInformation
• HeapSize
• InitializeCriticalSectionAndSpinCount
• IsDebuggerPresent
• IsValidCodePage
• LCMapStringW
• LeaveCriticalSection
• LoadLibraryW
• LoadResource
• LockResource
• MoveFileExA
• MultiByteToWideChar
• QueryPerformanceCounter
• ReadFile
• RtlCaptureContext
• RtlLookupFunctionEntry
• RtlUnwindEx
• RtlVirtualUnwind
• SetEvent
• SetFilePointer
• SetHandleCount
• SetLastError
• SetStdHandle
• SetUnhandledExceptionFilter
• SizeofResource
• Sleep
• TerminateProcess
• UnhandledExceptionFilter
• WaitForSingleObject
• WideCharToMultiByte
• WriteConsoleW
• WriteFile

USER32.dll

• GetDC

VirusTotal | Analysis of Imports

Based on the imports from the malware sample, it appears to possess a variety of functionalities, indicating a sophisticated threat.

ADVAPI32.dll

• The usage of ADVAPI32.dll functions, such as CryptAcquireContextW, CryptEncrypt, and CryptDecrypt, suggests the malware can perform cryptographic operations, likely for encrypting data or securing communication.

• Registry manipulation capabilities (RegOpenKeyExA, RegSetValueExA, RegDeleteValueA) imply it can alter system settings, possibly for persistence or to disable security features.

WININET.dll

• The WININET.dll imports like HttpOpenRequestA and InternetReadFile indicate the malware can perform internet-based operations, potentially for data exfiltration or command and control communication.

WS2_32.dll

• Functions from WS2_32.dll such as gethostbyname and InternetConnectA further support network communication abilities.

KERNEL32.dll & USER32.dll

• Finally, the KERNEL32.dll and USER32.dll imports show that the malware can perform basic file operations, process manipulation, and potentially interact with the user interface, suggesting it could execute a range of actions on the infected system.

VirusTotal | Relations

• There seems to be one major common indicator for C2 traffic: brb.3dtuts.by/ads.php.

• The URL appears to take various arguments:

  • i= - Possible stands for "IP" - Denotes the local IP address of the infected machine
  • c= - Possibly stands for "computer" - Denotes the hostname of the infected machine
  • p= - Possibly stands for "Payload" - Encoded/encrypted data - appears to be the outputs of commands sent over the C2 channel.

• A sample of encoded data was submitted to a Malware Analysis GPT and it was discovered to be encrypted with XOR key 0x5B or 91.

• Sample decrypted output: Idle;System;smss.exe;csrss.exe;csrss.exe;wininit.exe;winlogon.exe;services.exe;lsass.exe;lsm.exe;...

• This appears to be a list of running processes. This may be confirmed with further analysis.

• The IPv6 address 1::2 is unroutable and at first glance, its purpose is not clear.

• The presence of the /wsman endpoint suggests the malware may be leveraging the WS-Man protocol to manage or control remote systems.

• This protocol is often used for tasks like executing commands, managing system settings, or querying system information remotely.

Cape Sandbox | Dropped File(s) & Mutexes

• Cape Sandbox results reference a dropped .tmp file and 4 mutexes.

Cape Sandbox | File Interactions

• From the Cape Sandbox results, we also see interactions with two files (both of which are also potentially deleted):

  • C:\Users\<user>\AppData\Local\Temp\software.exe
  • C:\Users\<user>\AppData\Local\Temp\brbconfig.tmp

• There are interactions with multiple DLLs and .mui files that will require further investigation:

• winnsi.dll - This DLL is used by various network-related components and applications to retrieve and manage network information such as network interfaces, IP addresses, and connection statuses.

• urlmon.dll - This DLL facilitates the downloading of web content, handling MIME types, and managing security zones in Internet Explorer. It also supports ActiveX and OLE (Object Linking and Embedding) components.

• srvcli.dll - This DLL provides APIs for network file and print services, allowing clients to access shared resources on a network server. It's essential for network operations and resource sharing in a Windows network environment.

• netutils.dll - This DLL includes helper functions for network operations, such as network configuration, authentication, and domain-related tasks. It is often used in conjunction with other networking DLLs to perform these tasks.

• mswsock.dll.mui - This DLL is responsible for implementing Windows Sockets (Winsock) service providers. This includes support for network communication protocols and functionalities. The MUI file allows the mswsock.dll to support multiple languages.

• wshqos.dll - This DLL helps manage network traffic by prioritizing certain types of traffic over others. It is used to ensure that high-priority network packets (like those used for video conferencing or VoIP) are delivered with minimal delay and jitter.

• wshqos.dll.mui - This file contains language-specific resources and support for the wshqos.dll. It allows the main DLL to provide QoS functionalities in various languages, improving the user experience for non-English speakers.

Cape Sandbox | ASEP Key(s)

• The sample presumably achieves persistence with a simple Run registry key:

Static Analysis

• I began by using my custom tool Pointman to confirm that the file sample I had was a 64-bit PE file.

• Emulating execution with capa, we can see the following:

• As suspected, the sample appears to contain basic C2 and encryption/decryption capabilities.
• Given that the brbconfig.tmp file is not human-readable, and we found XOR-encoded C2 URI parameters, I suspect XOR is involved.

Evidence of Packing

• ExeInfo PE reports that this sample is not packed.

• To further confirm that this sample was not packed, we can take a look at PE Studio > Sections (File). If it was packed, we should expect to see sections such as NPX0 or UPX0.
• In this case, we see no such sections, which makes me feel certain that this sample is not packed.

Strings

• Extracting strings with Floss reveals the Registry run key along with a Mozilla user-agent and some network indicators.

Anti-Debugging Capabilities

• There are two API calls to IsDebuggerPresent as shown below.

1st Call: 00007FF7A4564098

2nd Call: 00007FF7A45642B5

Analyzing the First Call to IsDebuggerPresent

• The above execution flow stores the return value of IsDebuggerPresent in eax (1 if Debugger = True, 0 if Debugger = False)

• If the program is running in a Debugger, it jumps to address 00007FF7A4568A48, after which it exits the function (ret), jumping to 00007FFEE80B1FE4.

• It then calls RtlExitUserThread to end the current thread, after which it calls RtlGetSuiteMask, which is used to determine which Windows product suites are installed on the system.

• The result is a dw (double word). Some example return values are shown below:

Analyzing the Second Call to IsDebuggerPresent

• The second call to IsDebuggerPresent (00007FF7A45642B5) triggers an unhandled exception if a debugger is found.

• The above code snippet sets up an exception handler, performs several conditional checks, calls various subroutines based on these conditions, manipulates the stack and registers, and finally, it prepares to terminate the process.

Dynamic Analysis

• brbbot.exe was placed in C:\Users\AppData\Roaming\ and its process was spawned from explorer.exe as a result of double-clicking it in File Explorer.

• It did not spawn any child processes.

• The brbconfig.tmp file discovered earlier was found under C:\Users\<user>\AppData\Roaming as expected.

Analysis of Execution Sequence

• Upon launching, the brbbot.exe process loaded the required DLLs and initiated C2.

• Of particular interest (as an indication of C2 activity), wininet.dll was heavily referenced.

Analysis of brbconfig.tmp Configuration File

• To analyze the brbconfig.tmp file, we have to first transfer the file from the Windows VM to the Remnux VM.

• I transferred the brbconfig.tmp file using WinSCP.

• TrID could not identify the file type.

• The next step in understanding brbconfig.tmp will be to manually debug brbbot.exe and set a breakpoint at the corresponding API call that is used to decrypt and read the file.

• We start by setting a breakpoint at the ReadFile API call.

• MSDN shows that the ReadFile API call requires a handle to an open file.

• At the breakpoint, the rcx register will hold this handle (100 in this case)

• We can validate this by visiting the Handles tab, right-clicking, and hitting "Refresh".

• We then proceed to Run to User Code and look for the call to the CryptDecrypt API.

• We set a breakpoint right after this call, and review the results stored in the rsp register:

Experimenting with C2 Functionality

• Running FakeDNS and INetSim, we can create an ads.php file which stores arbitrary data that matches the C2 pattern of the brbbot.exe sample.

• We confirm connectivity by manually retrieving the C2 URL.

• We can double-check that the sample is communicating over the C2 channel as expected.

In-Depth Reversing

• The specimen begins by retrieving a handle to itself and identifying its own file name.

• After gathering basic host, user, and file system information, it proceeds to extract the CONFIG resource from its own .rsrc section and copy its contents to a new brbconfig.tmp file under the temp folder and create a registry run key for persistence.

• It proceeds to use CryptDecrypt to read the contents of the XOR-encrypted config file.

• Lastly, it proceeds to kick off the C2 process by sending out an HTTP GET request over port 80 with HttpSendRequestA.

Summary

• This brbbot sample contains basic C2 and anti-debugging functionalities.

• The sample first performs a simple check for the presence of debuggers > if brbbot.exe is found to be running in the context of a debugger, it will terminate the process.

• Otherwise, the sample will write an XOR-encrypted config file to disk named brbconfig.tmp and establish persistence via a registry Run key.

• It will then proceed to check in with the C2 server at 3d.tuts.by to receive commands hosted in the contents of /ads.php.

• It will match the contents of the ads.php file to its own config file on disk to execute basic commands, including exec, file, conf, & exit.