I was recently analyzing a malware sample that abuses the Beep function as an interesting evasion tactic. The Beep function basically plays an audible tone notification for the user. The Beep function accepts a parameter DelayInterval, which is the number of milliseconds to play the beep sound. The calling program’s thread that executed the function will “pause” execution for the duration of the beep. This can be an interesting anti-sandbox and anti-debugging technique. Let’s take a deeper look at the Beep function.
How Beep Works
When a program invokes the Beep function, it ultimately calls into a function called NtDelayExecution, which does exactly as it is titled: It delays execution of the calling program’s running thread. The below image illustrates how this essentially works:
The calling program (in this case, the malware), calls Beep, which further calls into NtDelayExecution. Once the beep duration has been met, control flow is passed back to the malware.
Here is a function trace from API Monitor, showing the same thing. Notice how Beep invokes several other lower level functions, including DeviceIOControl (to play the audible beep sound via hardware) and the call to NtDelayExecution:
As a side note, as the Beep function was originally intended to play an audible “beeeep!” when executed, it accepts a parameter called dwFreq which denotes a frequency of the beep sound, in hertz. This means that the calling program can decide the type of the tone that is played when Beep executes. This particular malware doesn’t play a tone when calling beep, but I think this would be a funny technique for malware to use; annoy the victim (or malware analyst). You may also wonder why the malware can’t just call NtDelayExecution directly. This would also work, but may appear more obvious to malware analysts and researchers. Anyway, it’s much more fun to use Beep than to call NtDelayExecution directly.
The Malware
The malware I was investigating calls the Beep function with a DelayInterval parameter of 65000 milliseconds (which will stall analysis for about 1 minute). It also calls this Beep function multiple times for added delay. This will cause the sandbox to stall for potentially log periods of time. If the malware is being debugged, the analyst will temporarily lose control of the malware as the thread is “paused”. Here is an excerpt of this code in IDA Pro:
Sandbox and Debugger Mitigations
To mitigate this technique, the sandbox should hook the NtDelayExecution function and modify the DelayInterval parameter to artificially decrease any delay. In a debugger, the malware analyst can set a breakpoint on NtDelayExecution or the Beep function and modify the DelayInterval parameter in the same way.
Other References
While researching this malware, I ran across an article from researcher Natalie Zargarov from Minerva Labs who wrote about this same technique in 2023 used in a different malware family.
I was digging into a new version of StrelaStealer the other day and I figured it may help someone if I wrote a quick blog post about it. This post is not an in-depth analysis of the packer. It’s just one method of quickly getting to the Strela payload.
A quick assessment of the executable in PEStudio reveals a few interesting things that I’ve highlighted. Note the TLS storage (callbacks). When the sample first executes, it makes two TLS callbacks as we’ll see in a bit.
Viewing the strings in PEStudio reveals several large strings with high-entropy data. These strings are part of the packed payload.
Let’s open the file in a disassembler to investigate further. I’ll be using IDA Pro for this analysis. If we inspect the “histogram” at the top of the IDA Pro window, we can see a large olive green segment which indicates data or code that IDA can’t make sense of. IDA Pro calls this data blob unk_14012A010:
As we saw in the strings earlier, this is likely the packed payload. I’ll rename this blob in IDA Pro to obfuscated_payload_blob. If we view the cross-references to this blob (ctrl+x in IDA), we can see several references:
Double-click one of these (I’ll select the 2nd one from the bottom), and you’ll see the following:
It seems our blob is being loaded into register rdx (lea rdx, obfuscated_payload_blob), and a few instructions later there is a call instruction to the function sub_140096BA0. Inspecting the code of this function and you may notice there are quite a few mathematical instructions (such as add and sub), as well as lots of mov instructions and a loop. This all indicates that this is highly likely a deobfuscation routine. Let’s rename this function deobfuscate_data. We won’t be analysing the unpacking code in depth, but if you wished to do so, you should rename the functions you analyse in a similar manner to better help you make sense of the code.
If we then get the cross-references to the deobfuscate_data function, we’ll see similar output to the cross-references for the obfuscated payload blob:
Inspect these more closely and you’ll see that the obfuscated blob is almost always being loaded into a register followed by a call to the deobfuscate_data function. This malware is unpacking its payload in multiple stages.
If we walk backwards to identify the “parent” function of all this decryption code, we should eventually spot a call to a qword address (0x14008978D) followed by a return instruction. This call looks like a good place to put a breakpoint as this is likely the end of the deobfuscation routine (given that there is also a return instruction that will take us back to the main code):
Let’s test this theory by launching the malware in a debugger (I’ll be using x64dbg). When you run the malware, you’ll hit two TLS callbacks (remember I mentioned those earlier?), like the below:
Just run past these. TLS callbacks are normally worth investigating in malware but in this case, we are just trying to unpack the payload here and will not investigate these further. You’ll eventually get to the PE entry point:
Put a breakpoint on the call instruction at 0x14008978D (using the command bp 14008978D) and run the malware. You should break on that call instruction:
If we step into this call instruction, we’ll get to the OEP (original entry point) of the payload! Inspect the Memory Map and you’ll see a new region of memory with protection class ERW (Execute-Read-Write):
This new memory segment (highlighted in gray in the image above) contains our payload. Don’t believe me? Dump it from memory (right-click -> Dump to file) and take a look at the strings. You should see something like the following:
You’ll spot some interesting data like an IP address, a user agent string, registry keys, and so on. If you don’t see any cleartext strings, you likely dumped the payload too early (before the malware deobfuscated all the data in this memory region), or too late, after the malware cleared its memory. Start reading this blog post again and try again ☺
Let’s open this dump file in IDA. After opening the file in IDA, be sure to rebase it (Edit -> Segments -> Rebase Program) to match it to the memory address in x64dbg:
After opening this dumped payload in IDA, you’ll see some inconsistencies, however:
See the problem? Some call instructions are not resolved to function names. However, in x64dbg, these functions are labeled properly:
This is because in x64dbg, these function names are being resolved to addresses in memory. In our IDA dump, they are not mapped properly.
Normally, what I would do next is try get my IDA database as close as possible to the code in x64dbg. We could spend more time analysing the unpacking code to identify where the malware is resolving its imports and this may help us get a better dump of the payload. Or, we could automate this by writing a python script to export all function names from x64dbg and import them into IDA. But why spend 1 hour automating something when we can spend 2 hours doing it manually? 🙂
We can manually fix this up IDA by cross-referencing each unknown function with the function name in x64dbg. For example, at address 0x1B1042 there is a call to InternetOpenA (according to our x64dbg output) and address at 0x1B107B is a call to InternetConnectA.
And now, we have something a lot more readable in IDA:
After you spend a bit of time manually renaming the unknown functions in your IDA database file, you should have some fairly readable code. Congrats! You unpacked Strela’s payload. Spend some time analysing the payload and see what you can learn about this sample.
Happy reversing! 🙂
— d4rksystem
Analysis of the NATO Summit 2023 Lure: A Step-by-Step Approach
It has been a while since I’ve touched a malicious RTF document and I’ve been itching to refresh my knowledge in this area. The tricky part was finding a maldoc worth investigation. Well, my luck recently changed – along came a maldoc lure that targeted guests of the 2023 NATO Summit in Lithuania in July. I found a maldoc worthy of my time.
BlackBerry wrote a great post of the analysis of the entire attack chain, but glossed over the analysis of the first-stage lure, which is what prompted me to analyze this further. Note that I’ll only be covering the 1st-stage lure in this post. The filename of the file I am investigating in this post is “Overview_of_UWCs_UkraineInNATO_campaign.docx”. The document is available on VirusTotal:
Upon initial inspection, this MS Word document does indeed appear to be quite targeted:
To begin my analysis, I first executed the document in a Windows 10 VM while capturing network traffic in Fiddler. The screenshot below shows connections to two IP addresses:
The first connection seems to be an HTTP OPTIONS request to 104.234.239.26.
Edit 1: I was informed from a reader (@k0ck4) that the malware is also making SMB connections to the remote server. This is true – the malware attempts to connect to the remote server via SMB, and following this makes an HTTP OPTIONS request. I was not able to get the malware to connect to the server (likely, the server is offline) but according to the strings in the RTF document objects, it attempts to download a file (more on this later!). The following screenshot from Wireshark shows the SMB connections:
The second connection is for another IP, 74.50.94.156. The second IP appears to be downloading a file (start.xml). For fun, I queried these IP’s in Shodan to see if there is anything interesting. Fun fact: The 74.50.94.156 IP is using WinRM and other services and has some interesting data exposed. (I blurred the data out, but you can check it out on Shodan if interested):
Lets dig deeper into this Document file. I switched over to Remnux VM, and used the tool zipdump to get an idea of what this file’s contents are.
There is definitely something in this document. An embedded RTF file (index 13) which seems to be titled “afchunk.rtf”! Let’s extract it:
(Since this command is a bit hard to read, here it is in text):
Let’s switch over to the rtfdump tool to see what is inside this RTF file:
It looks like we have three potential embedded objects. The first object (index 147) has a size of 0 bytes… interesting. The second object (index 152) appears to be an “OLE2LINK” object. And the third object (index 161) has the designation “SAXXMLReader”.
While rtfdump, rtfobj, and similar tools are extremely valuable, they are reliant on malware authors behaving properly. Some RTF malware may be able to hide objects from these tools or otherwise obfuscate the data inside. For this reason, I almost always look into the raw data of the file to make sure my findings align. To start, I ran the strings tool on the afchunk.rtf file (command: strings afchunk.rtf). A few things pop out:
There are what appears to be two objects embedded in this RTF file, denoted by the highlighted “objdata” tags. The first objdata tag is succeeded by a blob of hex data. If we copy this hex and transform it to ASCII, we would see some interesting things – but we’ll extract the object in a moment. This objdata tag is preceded by the string “Word.Document.8” which informs us that this may be an embedded Word document.. However, the standard DOC magic bytes (“D0CF11E”) are missing from the hex data. This object seems to be potentially malformed – this could be purposefully done, so as to mislead analysts and automated tools.
The second objdata tag contains another hex blob, but this time we see the “D0CF11E” magic bytes, which denotes an embedded document file or OLE (Object Linking & Embedding) object.
OLE is a way for different programs to exchange data between them. Imagine you have a document in MS Word, and you want to include a chart or a spreadsheet from MS Excel. OLE enables this. The chart or spreadsheet becomes an OLE object. You can learn more about OLE here. In the case of maldocs, malware authors often link or embed malicious objects into otherwise benign RTF documents as a way to hide them and stealthily execute evil activity.
Let’s dump the objects we discovered to disk. The rtfobj tool can help with this:
This command displays the objects inside this RTF file, and dumps them to separate files so we can analyze them. As we suspected, the first object (ID 0 in this output) states that the object is “Not a well-formed OLE object”. The second object (ID 1) has a class name of “OLE2LINK”, a type of OLE object. As a fun homework assignment, Google “OLE2LINK” – the first thing you’ll see is a list of vulnerabilities affecting this object type.
So, let’s take a look at the embedded objects we just extracted.
Analysis of Embedded Object 1
Viewed in a hex editor, Object 1 contains some interesting strings, notably: The IP “104.234.239.26” and the URI path “\share1\MSHTML_C7\file001.url”. When the afchunk.rtf file executes, this embedded object also executes, forcing MS Word to send an HTTP request to this remote server. We’ll discuss this more in a moment.
Edit 2: As a described in Edit 1, this document makes an SMB connection as well as the HTTP request. You can tell this is SMB by the reversed Windows SMB slashes (“\\” and “\”).
Analysis of Embedded Object 2
Similarly to Object 1, Object 2 can be viewed in a hex editor:
Viewing the second object in hex editor reveals another interesting string: “74.50.94.156”, as well as a URI path “/MSHTML_C7/start.xml”. This is the other IP we saw in our Fiddler traffic. As with the first embedded object, this second embedded OLE object also executes upon afchunk.rtf executing, and similarly tricks MS Word into contacting a remote web server. How does this work? I am glad you asked.
These embedded objects seem to be taking advantage of a known older vulnerability called (CVE-2017-0199). According to Microsoft, this vulnerability “exists in the way that Microsoft Office and WordPad parse specially crafted files. An attacker who successfully exploited this vulnerability could take control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.” Sounds quite dangerous… and very generic.
Digging deeper, I found publicly available exploit code for this vulnerability. If you compare the exploit’s payload code to the strings in the RTF document, you can see some similarities. The malware authors perhaps even re-used some of this exploit code for their own maldoc. For example, the following strings from the original RTF exploit code were existent in this document:
The Next Stages
During the time of my analysis, I could not contact the IP’s directly, so I could not obtain the files as they were supposed to be downloaded (via exploitation of the RTF document and MS Word). However, I was able to obtain them from VirusTotal.
The file hosted on 104.234.239.26 is another MS Word file that renders an iframe in preparation for the next stage of the attack. The file hosted on 74.50.94.156 is an XML file containing a weaponized iframe that is then loaded into MS Word. This malicious iframe is part of the CVE-2022-30190 vulnerability, and sets the stage for the later stages of this attack.
Since the goal of this blog post was simply to show one methodology for analyzing an RTF file, I won’t go into detail on the later stages of this attack. You can read it on the BlackBerry blog post.
For further reading, I found a good older article from the researchers at Nviso. Additionally, McAfee researchers posted a great article on malicious RTF documents and how they work.
I hope you enjoyed! If you see any inconsistencies or errors in this post, please let me know! Also, if you have additional techniques, I am always happy to learn new ways of malware analysis! 🙂
I was investigating a malware sample that uses an interesting trick to circumvent sandboxes and endpoint defenses by simply deleting its zone identifier attribute. This led me on a tangent where I began to research more about zone identifiers (which, embarrassingly enough, I had little knowledge of prior). Here are the results of my research.
The Zone.Identifier is a file metadata attribute in Windows that indicates the security zone where a file originated. It is used to indicate a level of trustworthiness for a file when it is accessed, and helps Windows determine the security restrictions that may apply to the file. For example, if a file was downloaded from the Internet, the zone identifier will indicate this, and extra security restrictions will be applied to this file in comparison to a file that originated locally on the host.
The zone identifier is stored as an alternate data stream (ADS) file, which resides in the file’s metadata. There are five possible zone identifier values that can be applied to a file, represented as numerical values of 0 to 4:
Zone identifier “0”: Indicates that the file originates on the local machine. This file will have the least security restrictions.
Zone identifier “1”: Indicates that the file originated on the local Intranet (local network). Both zone identifier 0 and 1 indicate a high level of trust.
Zone identifier “2”: Indicates that the file was downloaded from a trusted site, such as an organization’s internal website.
Zone identifier “3”: Indicates that the file was downloaded from the Internet and that the file is generally untrusted.
Zone identifier “4” – Indicates that the file came from a likely unsafe source. This zone is reserved for files that must be treated with extra caution as they may contain malicious content or pose a security risk.
You can use the following PowerShell command to check if a file has a zone identifier ADS:
Get-Item <file_path> -Stream zone*
An example of this output can be seen below. Notice the highlighted area that denotes the ADS stream (“Zone.Identifier”) and its length. Also note that if no data is returned after running this command, the file likely does not have a zone identifier stream.
To view this file’s zone identifier stream, you can use the following PowerShell one-liner:
Get-Content <file_path> -Stream Zone.Identifier
An example of this can be seen below:
A zone identifier file will look like something like this:
In this example, this Zone.Identifier indicates that the associated file originates from “zone 3”, which typically corresponds to the Internet zone. The ReferrerUrl denotes the domain of the webpage where the file was downloaded from or potentially the referrer domain, and the HostUrl specifies the precise location where the file was downloaded from.
These zones are also referred to as the Mark of the Web (MoTW). Any file that originates from Zone 3 or Zone 4, for example, are said to have the mark of the web.
Malware can abuse the zone identifier in a few different ways, with a couple different goals:
Defense Evasion
Malware can manipulate the zone identifier value to spoof the trust level of a file. By assigning a lower security zone to a malicious file, the malware can trick Windows and defense controls into treating the file as if it came from a trusted source.
To accomplish this, malware can simply modify its files’ zone identifiers. Here is how this can be accomplished via PowerShell:
This PowerShell one-liner modifies a file’s zone identifier to be a certain value (in this case, setting the zone ID to “1”). This may help the malware slip past certain defensive controls like anti-malware and EDR, and may make the malware look less suspicious to an end user.
Or, the zone identifier stream can simply be deleted, which may trick some defense controls. In order to attempt to bypass defenses, a variant of the malware family SmokeLoader does exactly this. SmokeLoader calls the Windows API function DeleteFile (see code below) to delete its file’s zone identifier stream. You can investigate this for yourself in a SmokeLoader analysis report from JoeSandbox (SHA256: 86533589ed7705b7bb28f85f19e45d9519023bcc53422f33d13b6023bab7ab21).
Alternatively, malware authors can wrap their malware in a container such as a IMG or ISO file, which do not typically have zone identifier attributes. Red Canary has a great example in this report.
Anti-Analysis and Sandbox Evasion
Malware may inspect the zone identifier of a file to circumvent analysis. Malicious files that are submitted to an analysis sandbox or are being analysed by a reverse engineer may have a different zone identifier than the original identifier the malware author intended. When the malware file is submitted to a sandbox, the zone identifier may be erroneously set to 0, when the original value is 3. If malware detects an anomalous zone identifier, it may cease to execute correctly in the sandbox or lab environment.
The pseudo-code below demonstrates the logic of how malware may check its file’s zone identifier:
zone_identifier_path = current_file_path + ":Zone.Identifier"
with open(zone_identifier_path, 'r') as f:
zone_info = f.read()
# Check if the zone is Internet zone (zone ID 3 or higher)
if "ZoneId > 2" in zone_info:
# File is from the Internet zone (as expected), continue running
return()
else:
# File may be running in a sandbox or analysis lab!
TerminateProcess()
If you are craving more information on this topic, other good resources are here and here.
— Kyle Cucci (d4rksystem)
Book Summary – “Evasive Malware: Understanding Deceptive and Self-Defending Threats”
Since my new book “Evasive Malware: Understanding Deceptive and Self-Defending Threats” pre-order just launched, I wanted to write up a quick summary of the book, including what you’ll learn, the book’s target audience, and a breakdown of each section in the book. Let’s get started!
What is this book about?
“Evasive Malware: Understanding Deceptive and Self-Defending Threats” is a book about the fascinating and terrifying world of malicious software designed to avoid detection. The book is full of practical information, real-world examples, and cutting-edge techniques for discovering, reverse-engineering, and analyzing state-of-the-art malware, specifically malware that uses evasion techniques.
Beginning with foundational knowledge about malware analysis in the context of the Windows OS, you’ll learn about the evasive maneuvers that malware uses to determine whether its being analyzed and the tricks they employ to avoid detection. You’ll explore the ways malware circumvents security controls, such as network or endpoint defense bypasses, anti-forensics techniques, and malware that deploys data and code obfuscation. At the end of the book, you’ll learn some methods and tools to tune your own analysis lab and make it resistant to malware’s evasive techniques.
What will you learn?
Modern malware threats and the ways they avoid detection
Anti-analysis techniques used in malware
How malware bypasses and circumvents security controls
How malware uses victim targeting and profiling techniques
How malware uses anti-forensics and file-less techniques
How to perform malware analysis and reverse engineering on evasive programs
Who is this book for?
This book primarily targets readers who already have at least a basic understanding and skill-set in analyzing malware and reverse-engineering malicious code. This book is not a beginner course in malware analysis, and some prior knowledge in this topic is assumed. But have no fear – the first three chapters of this book consist of a crash-course in malware analysis and code analysis techniques.
Here are some of the practical applications of this book:
Malware Analysts and Researchers – Learn how modern and advanced malware uses evasion techniques to circumvent your malware lab and analysis tools.
Incident Responders and Forensicators – Learn how advanced malware uses techniques like anti-forensics to hide its artifacts on a host. Understanding these techniques will help improve incident response and forensics skills.
Threat Intellgience Analysts– Learn how bespoke, targeted, and cybercrime malware uses evasion techniques to hide and blend into its target environment.
Security Engineers / Security Architects – Learn how malware evades the host and network defenses that you design, engineer, and implement.
Students and Hobbyists – Learn how modern, advanced malware operates. If you read and actually enjoy this book, then you now know that you should pursue a job in malware research 😉
This book consists of five sections (parts), each consisting of three or more chapters. Let’s take a brief look at each of these.
Part 1: The Fundamentals
Part 1 contains the foundational concepts you’ll need to know before digging into the rest of the book. The topics include the fundamentals of how the Windows operating system works, and the basics of malware analysis, covering sandbox and behavioral analysis to static and dynamic code analysis.
Chapters in Part 1:
Chapter 1: Windows Foundational Concepts
Chapter 2: A Crash Course in Malware Triage and Behavioral Analysis
Chapter 3: A Crash Course in Static and Dynamic Code Analysis
What you’ll learn:
What evasive malware is and why malware authors use evasion techniques in their malware.
The fundamentals of Windows OS internals.
A crash course in malware analysis and reverse engineering, covering the basics of malware sandbox analysis and behavioral analysis, and static and dynamic code analysis.
Part 2: Context-Awareness and Sandbox Evasion
Part 2 starts getting into the good stuff; How malware is able to detect sandboxes, virtual machines, and hypervisors, and circumvent and disrupt analysis.
Chapters in Part 2:
Chapter 4: Enumerating Operating System Artifacts
Chapter 5: User Environment and Interaction Detection
Chapter 6: Enumerating Hardware and Network Configurations
Chapter 7: Runtime Environment and Virtual Processor Anomalies
Chapter 8: Evading Sandboxes and Disrupting Analysis
What you’ll learn:
How malware detects hypervisors by inspecting operating system artifacts.
How malware detects virtual machines by looking for runtime anomalies.
How malware tries to detect a real end user in order to identify if it’s running in a sandbox.
How malware actively circumvents analysis by exploiting weaknesses in sandboxes or directly interfering or tampering with the analyst’s tooling.
Part 3: Anti-Reversing
Part 3 covers the many techniques malware may use to prevent or impede reverse-engineering of its code, such as complicating code analysis, disrupting debuggers, and causing confusion and misdirection.
Chapters in Part 3:
Chapter 9: Anti-disassembly
Chapter 10: Anti-debugging
Chapter 11: Covert Code Execution and Misdirection
What you’ll learn:
How malware authors implement anti-disassembly techniques and how you can overcome them.
How anti-debugging techniques work, and how to identify these techniques while analyzing malware.
How malware utilizes covert code execution and misdirect techniques to confuse malware analysts and slow down the reversing process.
Part 4: Defense Evasion
Chapters in Part 4:
Chapter 12: Process Injection, Manipulation, and Hooking
Chapter 13: Evading Network and Endpoint Defenses
Chapter 14: An Introduction to Rootkits
Chapter 15: Fileless Malware and Anti-forensics
What you’ll learn:
How malware implements modern process injection and manipulation techniques to circumvent defenses.
How malware actively and passively circumvents and bypasses modern endpoint and network defenses like EDR/XDR.
The basics of rootkits and how they evade defenses.
How always uses living-off-the -and techniques to remain undetected and blend into the environment.
Anti-forensics techniques and how advanced malware hides from forensics tooling and investigators .
Part 5: Other Topics
Finally, Part 5 covers additional techniques and topis that did not fit in well with the other chapters. This section covers topics like obfuscating malware and malicious behaviors via encoding and encryption, how packers work and how to unpack malware, and how to make your malware analysis lab a bit more resilient to evasive malware.
Chapters in Part 5:
Chapter 16: Encoding and Encryption
Chapter 17: Packers and Unpacking Malware
Chapter 18: Tips for Building an Anti-evasion Analysis Lab
What you’ll learn:
How malware implements obfuscation and encryption to complicate analysis and hide malicious activity, and how to analyze obfuscated code.
How malware uses packers and crypters, and how to analyze packed malware.
How to configure and tune your analysis lab to help streamline analysis of malware that may be detecting your lab environment.
Pre-Order the Book!
If you decide to legally purchase my book (instead of pirating it), it would be much appreciated. I need to buy beer, a new gaming PC, feed my family, you know, important stuff.
How to pre-order:
You can order the book directly from the No Starch Press publisher website. If you order from No Starch, you also can get access to an Early Access version of the book, as well as the finished book!
You can order on Amazon. Sometimes Amazon has deals and this may be cheaper, but you do not get access to the Early Access version. Amazon ships to many places in the world, so this is an advantage.
There are other sites you can order from as well, such as local bookstores. Just Google “Evasive Malware book”.
If you decide to pre-order the Early Access version of my book, I would love your feedback! If you spot technical errors, spelling and grammar errors, or even if you just want to tell me “It’s amazing!” or “It sucks!”, I want to hear your feedback 🙂 Feel free to contact me via Twitter or LinkedIn.
A lot of love for the infosec community went into this book, so I hope you enjoy it! 🙂
Malware Analysis in 5 Minutes: Identifying Evasion and Guardrail Techniques with CAPA
Modern malware has gotten better and better at detecting sandbox and analysis environments, and at evading these environments. Malware can circumvent defenses, sandboxes, and analysts by using various techniques such as VM detection, process injection, and guardrails.
In particular, guardrails are one or more artifacts that malware looks for on the host before executing its payload. These artifacts may be specific registry keys, files, directories, network configurations, etc. If these specific artifacts do not exist on the host, the malware may assume it is running in an analysis lab, or is otherwise not the right target for infection.
One of the most tedious processes when investigating malware that is evading your sandboxes or tooling is figuring out what techniques the malware is using for this, and where in the code this occurs. CAPA can help automate this process.
CAPA is a tool written by the FireEye/Mandiant FLARE team that can be used to quickly triage and assess capabilities of a malware sample.
For this example, I have a sample that will not run in my sandboxes or in my analysis VM’s and I am trying to figure out why. Let’s throw this sample into CAPA:
capa path/to/sample.exe
CAPA provides a nice summary of the potential ATT&CK techniques the malware is using, along with its identified capabilities. This assessment can help in many malware analysis situations, but here the focus is on evasion techniques.
Based on this initial analysis, we can see several possible techniques being used, such as:
Executing anti-VM instructions
Hashing and data encoding (could be used to hide strings)
Checking if a certain file exists (could be used for creating guardrails)
Getting the hostname (could also be used for guardrails)
Multiple process injection techniques
We can get additional information from CAPA by using the verbose mode:
capa path/to/sample.exe -vvv
Now we can focus on a few of these techniques and where they reside in code:
CAPA identified two uses of the CPUID instruction, which can be used to identify a virtual machine environment. We can now throw this sample into a disassembler and locate this code by jumping to the addresses listed in CAPA:
If we wanted to bypass this detection technique, we could NOP out (remove) the CPUID instructions, or modify their return values. More about the CPUID instruction can be seen here and here.
Additionally, CAPA identified the addresses in the binary where process injection behaviors may be occurring:
With this information, along with the offset addresses provided, we can set breakpoints on these addresses or instructions for analysis in a debugger. For more info on these process injection techniques, this write-up is old but still very relevant.
Finally, I suspect this sample is using some sort of guardrails. Guardrails are a technique used by malware to prevent sandbox analysis, hamper manual analysis, evade host defenses, and prevent unnecessary “spreading” of the malware.
As previously identified by CAPA, this sample may be using the system hostname and files/directories as guardrails. It also likely that it has hardcoded hashes of those guardrails in order to make it difficult for analysts to spot what the malware is specifically looking for:
CAPA identified that this sample is checking for a specific file at function offset 0x1400012C1, and the hostname at 0x140001020. Let’s inspect the hostname query in the sample in a dissembler. Once Ghidra disassembles this function, this is what is displayed:
In Ghidra, we can see that the sample is calling GetComputerNameA in order to get the domain hostname of the victim. It then hashes this hostname (CryptCreateHash, CryptHashData) and compares it to a hardcoded hash using memcmp (memory compare).
This instruction is comparing the DAT_target_hash (the hash of the hostname that the malware is expecting) to hashed_domain_name (the actual hostname of the victim). If these hashes do not match, the sample will terminate itself.
Since the target hash is hardcoded in the binary and will not be “un-hashed” in memory, we don’t really know what this malware sample is looking for. Our best option here is to bruteforce the hash using a rainbow table or wordlist.
Or… we can simply bypass this hash checking functionality altogether. With this information from CAPA, we can now patch the binary (in a disassembler or in a debugger) in order to completely bypass these VM detection and guardrail techniques, and allow our sample to run in our VM. We can do this by NOP’ing out instructions, modifying the function return values, or skipping the code altogether by jumping over the suspect code.
Many malware families still use simple evasion techniques for detection of virtual machine environments and malware analysis sandboxes. These simple checks are enumerating things on the host such as processes, certain files and directories, specific drivers and hardware configurations, and registry keys that may give away the presence of a hypervisor. If a virtual machine is detected, the malware may kill itself or perform other evasive actions.
Did you know that many of these simple checks can be completely bypassed by slightly modifying the analysis environment before running the malware? I wrote a quick Powershell script to make these modifications quickly and automagically. Note: This script only supports VirtualBox so far, but will support VMWare in the near future.
The script is very simple. Give it one of several parameters and it will get to work cleaning up your Windows VirtualBox VM and priming it for malware analysis. The changes it makes are as follows:
Renames several registry keys that malware typically used for VirtualBox detection.
Kills VirtualBox processes (VBoxService and VBoxTray).
Deletes VirtualBox driver files.
Deletes or renames VirtualBox supporting files in System32 directory.
One popular question I get a lot is: “Won’t making these types of changes, especially to driver files and processes, break or crash my VM?”
Answer: No! The file modifications the script makes are only on the disk. VirtualBox loads these files into memory anyway, so we can freely modify file and directory names without affecting the VM too much. I say “too much” because your VM will likely slow down a bit after these changes are made (especially after terminating VBox processes) and it won’t be as user friendly. The script, for example, will break drag/drop, clipboard, and shared folder settings, but this is a side affect of making your VM more difficult to detect. If you really want to be hardcore reversing evasive malware, you wouldn’t want these features enabled anyway 😉
To run, just invoke the PowerShell script like this:
“Vboxcloak.ps1 -all”
This command will make all configuration changes to the virtual guest system. We can see this in the screenshot below:
VBoxCloak in action.
I tested this script with a few evasive malware samples and it seems to work well, on many occasions. Obviously, it’s not perfect and will not evade all malware anti-analysis checks, but it is a good start when analyzing an evasive sample.
Once again, the script can be downloaded from: https://github.com/d4rksystem/VBoxCloak
Enjoy! Feel free to yell at me when you inevitably find bugs in the script 🙂
Lokibot is a family of “infostealers” designed to steal sensitive data such as credentials, cryptocurrency wallets, and other juicy things. Once a victim system is infected, this data is typically sent to a Command & Control server via HTTP POST.
I decided to dig deeper into this infostealer out of curiosity, as well as its prevalence in the cybercrime communities.
Here is the sha256 hash of the sample I used during this analysis:
A quick static file analysis of the sample does not reveal much. Below, we can see some of the properties and headers of the file, such as that it is an executable. We can also see that the sample is likely written and compiled in Delphi. The import table is also lacking, leading me to believe that the sample is packed and will later unpack itself in memory.
Lokibot sample properties – packed
Let’s run the sample in our sandbox and see how it behaves.
Behavioral Analysis
When starting the Lokibot executable in a virtual machine, the sample basically copies itself to the users “AppData\Roaming” directory as “ever.exe”. It then executes the “ever.exe” executable, unpacks itself into a new instance of “ever.exe“, and kills the original “ever.exe” process.
Below, we can see the unpacked sample running as “ever.exe”.
Lokibot sample running on Windows 7.
Capturing traffic in Wireshark, we can see some interesting behavior:
Wireshark traffic.
The sample seems to make an HTTP POST to the domain “smallthingstress.sytes.net”. Inside the POST data is my Windows hostname, username, and a string at the end. At the beginning, there is a reference to “ckav.ru”. This is actually referencing a domain, “fuckav.ru”, which we will see again later in this sample’s code.
Unfortunately, I was unable to do more analysis of the complete C&C traffic flow because the domain appears to be offline now. Good thing for the victims, bad thing for us malware analysts 🙁
Unpacking Lokibot
The goal of this analysis is to understand the detailed functionalities of the malware. One of the ways in which to do this is to let the sample unpack itself in memory, and then extract it from memory as an executable and finally rebuilding the PE headers and IAT (Import Address Table). This way, we will be able to open up the sample in IDA or another disassembler and view its functionalities to start analyzing it.
For unpacking, I decided to use a tool called “hollows_hunter“. I wrote in detail about hollows_hunter here if you are interested.
In summary, hollows_hunter is a tool that scans all processes in your virtual Windows environment and attempts to locate malicious activity such as hooking, code injection, shellcode, etc. Once the malicious activity is recognized, hollows_hunter automatically dumps the associated executables, and attempts to rebuild the PE file and IAT. It worked really well in past samples I have ran it on, and it is a good idea to run this tool before attempting manual unpacking to save some time.
HollowsHunter in action.
I ran the Lokibot sample and started hollows_hunter, which can be seen in the above screenshot. Luckily, hollows_hunter was able to dump the malicious process. To my surprise, it also rebuilt the PE and (some of) the IAT successfully, allowing me to inspect interesting imports and strings.
Static Analysis of Unpacked Lokibot
After dumping the unpacked executable, we can now see several interesting strings and functionalities:
Suspicious strings…
For example, there are strings that reference SQL statements, the URL we saw earlier (“smallthingstress.sytes.net”), the “fuckav.ru” domain reference, and some strings referencing various browsers.
Based on the above findings, we can be mostly sure that this sample is designed to enumerate and extract system information such as browser and SQL data. Let’s import the sample into IDA for a deeper analysis.
To start revering this sample, I chose a few of the interesting strings and imports in the strings list. Some of the items that caught my attention were the browser-related strings, and the connection-related imports (socket, connect, send, etc.)
Below, we can see a list of the functionalities of this sample. This Lokibot sample is attempting to read data from the following applications:
Lokibot – interesting functionalities.
Lokibot queries the filesystem and registry in order to enumerate system information, credentials, cookies, and other juicy data. Below, we can see some of the function code that is responsible for stealing Safari browser and keychain data:
Lokibot – stealing Safari data.
And here we can see the code responsible for enumerating SSH-related Putty data:
Finally, after gathering the juicy data, Lokibot sends this data to a remote web server (in my case: “smallthingstress.sytes.net”), which is what we saw in the Wireshark data earlier. We can see that in the below code, where the C2 URL and socket information is referenced:
That concludes this brief analysis of Lokibot. There are a lot of areas of code that I did not go deeply into during the static analyses, so I’m sure that this sample has additional functionalities that I overlooked. However, in malware analysis, its easy to get stuck in a rabbit hole of code. Sometimes it is best to simply understand the main functionalities of the code in order to quickly build detentions for them and respond to them in the future, rather than get lost in kilobytes worth of code that may or may not prove to be interesting.
As always, thanks for reading! If you enjoyed this post, follow me on Twitter (@d4rksystem).
In an earlier post, I wrote a technical analysis of the Ryuk ransomware and its behaviors. This post is a follow-up to that, for whoever is interested in learning one method of unpacking a Ryuk sample.
As explained in my previous post, Ryuk will typically try to inject itself into several processes running on the victim system. It does this be leveraging a common injection technique using OpenProcess, VirtualAllocEx, WriteProcessMemory, and finally, CreateRemoteThread .
Ryuk can be extracted from memory by running it in a debugger (x64dbg is my choice for this) and setting a breakpoint on CreateRemoteThread (this can be done with the command setBPX CreateRemoteThread in x64dbg).
Breakpoint hit on CreateRemoteThread.
Once the breakpoint is hit and program execution is paused, we can expect to see a handle to a process (the process in which Ryuk wishes to inject code into) by inspecting the call stack window. In my case, the handle is 0x148, located in rcx:
Call stack for CreateRemoteThread.
Next, we need to cross-reference this handle with its process name in order to find out the target process. We could use x64dbg for this, but I will use ProcessHacker because I feel it is a bit easier to use in this case. To do this, simply launch ProcessHacker, right-click the running Ryuk process, select Properties, and then the Handles tab.
We can see below that the handle (0x148) is associated with the taskhost.exe process. It looks like Ryuk injected code into taskhost.exe and is now attempting to run this code. Note: This process may be different for you!Ryuk often injects into dwm.exe, virtual machine processes, and others.
Handle to taskhost.exe in Ryuk process.
Now we must inspect this taskhost.exe process and try to find the location where Ryuk injected code. We can do this with ProcessHacker or any number of memory inspection tools. I have chosen instead to attach the process again to x64dbg and inspect the memory there. This is just a matter of personal preference, however.
What we are looking for in the taskhost.exe process address space is a suspicious memory region where Ryuk’s code has likely been injected. This can be accomplished using the Memory tab in x64dbg (or the Memory tab in ProcessHacker, if you choose to do it with this tool). In x64dbg, underneath the taskhost.exe memory region, we can see a memory region has been created with ERW (Execute-Read-Write) permissions, which is suspicious. The memory region has a significant size (163 kb), which is definitely enough space to store an executable:
Injected executable in taskhost.exe.
This is likely our injected code. We can dump this memory region from x64dbg (or from ProcessHacker) by right-clicking the memory region and selecting the Dump or Save option.
Now you should be able to inspect this file in a PE viewer, or a disassembler (such as IDA), and should be able to see readable strings:
Ryuk strings – before unpacking executable.
Ryuk strings – after unpacking executable.
After dumping the memory region, if we try to start analyzing this file in a disassembler (such as IDA), we would see that this file is not a valid PE file, or is otherwise corrupted. To fix this, you can the use PE_Unmapper tool. This tool will “unmap” the executable from memory and fix up our dumped executable, including rebuilding the Import Address Table. Note: Other tools may work for this as well, including Scylla or OllyDump, but I found that PE_Unmapper worked the best for my case.
With PE_Unmapper, we can unmap this dumped executable using the following command syntax:
You should now have imports listed in a PE viewer tool or in a disassembler. One important thing to note is that Ryuk dynamically builds a second imports table using the GetProcAddress function. This means that there are actually more imports than what is listed in the Imports section of any PE viewer tool. Because of this, you will likely experience issues analyzing this file in a disassembler.
These functions seem to be labeled as cs:qword_<address>. To fix this issue, you will have to manually rename these functions, like so:
Ryuk imports table – before fixing.
Ryuk imports table – after fixing.
You could probably script this part as well, if you felt motivated enough. If you do, please share it with me 😉
Here is the sha256 hash of the sample I used in my analysis:
feafc5f8e77a3982a47158384e20dffee4753c20
This sample can be found on VirusTotal. If you don’t have access to VirusTotal, just Google the hash and you may be able to find it elsewhere online. Otherwise, any new-ish Ryuk sample will likely work for this analysis.
Well, that’s about it. As always, thanks for reading! If you enjoyed this post, follow me on Twitter (@d4rksystem).
Extracting Malware from Memory with Hollows_Hunter
Sometimes I come across a tool that makes me stop and think what I have been doing all my life life without it. This is how I feel about hollows_hunter. Hollows_hunter is essentially a tool for automatic extraction of evil objects and malicious code from memory. The tool is able to hunt for things such as process injection and replacement, process hollowing, DLL injection, malicious shellcode, and has a host of other uses. Hollows_hunter is based on pe-sieve, written by the same author, hasherezade.
Once a malicious object is found in memory (for example, malicious code in a running process), the tool will auto-magically extract the process from memory, and attempt to rebuild the headers and Import Address Table (IAT). In many cases, the tool is able to completely fix up the dumped file and rebuild the IAT so I could load it into IDA for further analysis. This is great because some of the malware samples I attempt to unpack and extract end up as warped shells of their once-glorious selves, un-analyzable in IDA. Hollows_hunter has saved me a lot of time recently, and seems to not get as much attention as it deserves. This drove me to write a quick tutorial post for it.
Let’s dive into hollows_hunter to see why it is so useful. Hollows_hunter gives a wealth of options that we can enable to help us better extract the data we are looking for:
For the following post, I’ll be using the sample with the SHA256 hash:
You can find this file on VirusTotal or elsewhere online, in case you want to follow along.
First, I’m going to run the sample in a Windows 7 VM sandbox. Immediately after executing the sample, I run hollows_hunter:
The command line options I used above are “hooks”, “shellc”, “data”, and “imp”.
“hooks” essentially tells hollows_hunter to look for malicious hooks and patches in memory.
“shellc” instructs the tool to look for shellcode (this sometimes produces false-positives, so handle with care.)
“data” tells hollows_hunter to inspect non-executable memory segments. This is sometimes important because malware may write data to non-executable areas of memory. This data may be useful strings, or it may be code that the malware will later try to execute.
Finally, “imp 1” instructs hollows_hunter to attempt an automated rebuild of the Import Address Table (IAT). This is super helpful, as we will see in a minute.
I ran hollows_hunter as Administrator so that it can scan system processes. I could have also ran the sample with the parameter “loop”. This parameter instructs hollows_hunter to continually run on repeat, constantly looking for malicious activity.
After running hollows_hunter, we can see that it scanned all running processes, found some malicious activity in memory, and dumped those memory regions:
PID 2892 and 2944 are, in my case, false positives. I know that because hollows_hunter seems to always detect malicious activity in svchost.exe and wmpnetwk.exe when running as an Administration. Powershell.exe (PID 2520) is the PowerShell process I am running hollows_hunter in, so this is also a false positive.
EDIT: After messing around with the latest version of HollowsHunter (HollowsHunter Portable 0.2.4), I have confirmed that the issues with most of these false positives have been fixed . Obviously, there will always be false positives with any tool, but @hasherezade did a great job at identifying the common FP’s.
We can see that the malware sample has spawned two strange processes (WhatsAppWeb.exe, PID 2480/2088), and hollows_hunter was able to dump those processes from memory.
If we navigate to the hollows_hunter directory that we ran the tool from, we can see new directories that match the name of the PID that was dumped. In my case, the directories I am interested in are “process_2480” and “process_2088”. Let’s see what hollows_hunter dumped for us in the “process_2480” directory:
Here we can see the dumped executable from memory, the list of imports that the sample is likely utilizing, and a report of the findings in JSON format. Now let’s inspect the “WhatsAppWeb.exe” here. I will open this file in IDA, my disassembler of choice.
Looking at the strings, we can immediately see some of the capabilities of this malware sample. This sample seems to be utilizing keylogging functionalities, and possibly attempting to disable anti-virus software.
If we look at the Imports section, we can see all of the imports are listed here. This means that the IAT was successfully rebuilt! Rebuilding the IAT is always a huge pain in my %@$, so hollows_hunter really helped here!
Because the sample has been unpacked, the IAT and PE structure have been rebuilt, and the strings appear readable, this malware should be easy to analyze further in IDA. Whoot.
Well, that’s all for now. I hope you learned a bit about the usefulness of hollows_hunter. Thanks to hasherezade for putting in the work to create such a useful tool!
If you enjoyed this post, follow me on Twitter (@d4rksystem) 🙂
