Security researchers have uncovered new malware that is using the Windows event log to store to store malicious codes. The researchers note that this is the first time the technique has been observed in the wild as part of a malware campaign.
The trojan that is used in the attack is hidden on the system, as it is not linked to a specific file on the system. Instead, it is planted by the attacker in the Windows event log for future executions.
The threat actor has not been identified or linked to any of the active malware groups, according to Kaspersky.
Kaspersky researchers describe how the malicious actor used various evasive methods and techniques to avoid detection on the attacked computer systems. Dropper modules were used in the attack to “patch Windows native API functions” that are related to event tracking and anti-malware scan interfaces.
The sophisticated attack started in September 2021, when Kaspersky noticed the initial phase of the attack. The attackers used the Cobalt Strike framework in the attack, but the very first step began at the user level. The target downloaded a RAR archive file from the file hosting site file.io and ran it afterwards. Different attack scenarios and techniques were used for other targets according to Kaspersky, but all attacks appear to have included initial recon of the targets and preparations for additional attacks.
The described method gave the attackers the ability to inject code into processes, and this was used to inject additional modules into Windows and trusted applications. Cobalt Strike was not the only toolset the attackers used. Kaspersky identified traces of the SilentBreak framework and several trojans, ThrowbackDLL.dll and SlingshotDLL.dll, were named after the Throwback and Slingshot tools of the SilentBreak framework.
The filename of the one of the droppers, sb.dll, could also be a reference to the framework, according to the researchers. Some of the tools appear to be custom made, and some function names have been obfuscated to reduce the likelihood of detection and identification.
One of the analyzed attacks started with the injection of code into Windows processes after the initial infection took place. The dropper removed traces of previous stages of the attack from the system as part of the detection avoidance mechanisms the attackers implemented.
It then copied the legitimate error handler of the operating system, WerFault.exe to C:\Windows\Tasks and planted an encrypted binary resource called wer.dll in the same directory for DLL search order hijacking. DLL search order hijacking, often also referred to as DLL preloading, is a common attack form that attempts to prioritize a malicious DLL file over the legitimate one.
Applications need to import functions from library files for use. Importing is done either implicitly or explicitly, and since Windows XP, a list of priority locations is used to determine the first DLL candidate. The first priority of the search order is the executable’s application folder; it is followed by the system directory, the 16-bit system directory, the Windows directory and several other directories.
All that an attacker needs to achieve is to place the malicious DLL in a location that has a higher priority than the legitimate DLL.
It then added the newly created WerFault.exe to the operating system’s autorun by adding it to Software\Microsoft\Windows\CurrentVersion\Run to make access persistent.
The wer.dll dropper is harmless on its own, as it requires the shellcode in the Windows event log for execution.
Planting attack code in the Windows event log
via Securelist / KasperskyOne of the unique aspects of the malware campaign was the use of the Windows event log for payload storage. The main advantage of this is that the fileless approach makes the payload harder to detect.
The dropper attempts to load the code in the Windows event log; if it does not exist, it is written as 8KB chunks using the ReportEvent() Windwos API function. The data, if it exists, is loaded and then combined by a separate threat, and then run on the target system.
The launcher “transmits control to the very first byte of the” shellcode according to Kaspersky’s research. It submits data that is used to execute the next stage of the attack:
- The address of the next trojan used in the attack is revealed.
- A standard ROR13 hash of an exported function.
- Addresses of two strings, which become the “arguments of the exported function”.
Here again, evasion techniques were used to reduce the visibility of the attack.
The last stage trojan communications with a C&C (command and control) server using either HTTP with RC4 encryption or unencrypted communication with named pipes. It sends an empty but encrypted string at first to test the connection.
The target system is fingerprinted by the late stage trojan, gathering information such as the computer name, local IP address, architecture, operating system version, values of the MachineGUID found under SOFTWARE\Microsoft\Cryptography, and whether the process has SeDebugPrivilege.
The command and control server replies with a code of its own, which designates the next action that should be taken by the trojan. Among the options are the execution of custom commands, downloading files from a specified URL and saving it to a specified path on the system, get a list of all processes and information, or inject and run shellcode into the target process’ address space.
The named pipes-based trojan is located in C:\Windows\apds.dll, mimicking the legitimate Microsoft Help Data Services Module library of the same name, which is located in C:\Windows\System32.
Anti-Detection techniques the attackers used
The attackers used a wide range of anti-detection techniques to fly under the radar:
- Use of several different compilers-
- Whitelisted launchers.
- Use of digital certificates. 15 files were signed with “Fast Invest” certificates.
- Patch logging exports of ntdll.dll.
- Shellcode placing in the Windows event log.
- C2 web domain mimicking.
Kaspersky considers the use of the Windows event log for storage of the payload the “most innovative part” of the malware campaign. The entire campaign is sophisticated, as it uses at least two commercial frameworks and several “types of last-stage RAT and anti-detection wrappers”.
Additional information about the attack is available on Securelist.
Thank you for being a Ghacks reader. The post New malware attack stores payloads in the Windows event log appeared first on gHacks Technology News.