It does this using a HTTP GET request, which is entirely constructed from information statically stored inside the DLL. Next, beacon.dll enters a polling loop, where it attempts to connect to this IP. More importantly, an IP address appears: 88.218.92.19. Figure 4: IP address and query path revealedįigure 4 shows that the beacon reveals fragments of HTTP request information.
However, as the parser is moving to the data sections of the DLL and beyond, strings and clear text begin to appear that were unreadable before. Without further context, at this point the meaning of these settings is difficult to extrapolate. Instead, it parses additional configuration settings that had been hidden in the DLL.
Initially, for a significant number of instructions the beacon does not appear to interact with the host machine. Specifically, we are looking for network signatures and other potentially damaging functionalities that may not have been associated with the attack. We are looking for the beacon inside beacon.dll and with it any information about the origin of the attacks. The payload itself is finally called at in Figure 2. This gives an initial hint as to what kind of tool the attackers are using. Metasploit defines custom notifications to execute payloads delivered via injected DLLs.
This is similar to the behaviour of another well-known penetration testing tool: Figure 3: Metasploit example of customly defined notification codes used in DLL injection (Github).
#Cobalt strike malware code#
Figure 2: DllMain function of beacon.dll (Ghidra).įrom in Figure 2, a notification code of 4 is shown, which is not recognized by Windows.
#Cobalt strike malware windows#
The second time it is called with a notification that is not part of the ordinary Windows API. The reflective loader calls DllMain twice: Once, to notify the DLL that the library has successfully loaded and that it can now perform its own internal initializations. Although, DllMain was not intended to be used like this, it allows a DLL to implement a program in the same way that a main function does for executables. It serves to notify the library that it is attached to a process, and to give it an opportunity to initialize any resources that it requires.Ī malware author could choose not to cooperate by not yielding control back to the owning main executable. In the case of DLLs, this function is aptly called DllMain. But if it is not exporting any other functions, then where is the payload to be found? A DLL, like any other Portable-Executable (PE) file, has an entry point - a function called by the operating system, after the PE file has been successfully loaded. Following the Path of Executionįunctrl32.dat, or beacon.dll - as we are going to call it from here onwards - exports only one function, which has precisely one task: Deliver the payload. The article left off where the DLL has been covertly loaded into functrl64.exe’s process and where we got to execute the payload. Instead, the DLL uses a technique called Reflective Loading that we described in depth in another article. The way this malware seeks to avoid detection is by loading it from inside process memory without the help of the Windows image loader that would normally be required to load executable modules.
#Cobalt strike malware install#
We removed each layer and revealed the payload that the malware attempted to install and execute on the machine: Figure 1: Export table of functrl32.dat with the original filename and the only entry in the export list (Ghidra).Īfter deployment on a victim machine, the DLL connects to a C2 server and begins polling for further instructions.
A compromised domain controller attempted to plant functrl64.exe, a maliciously modified version of the popular Notepad++ editor, followed by functrl32.dat, at first an unidentified data file, in the system directory of a victim machine.ĭuring our analysis, we identified functrl32.dat to be a Dynamic-Link Library (DLL), hidden behind two layers of encryption. The attack consisted of two components: A text editor repurposed as a launcher for the actual payload, identified as Cobalt Strike’s Beacon. In a previous article, we introduced a piece of malware that ThreatSpike detected in December 2020, moving laterally between hosts.
0 kommentar(er)
