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
Creating Quick and Effective Yara Rules: Working with Strings
This is a quick post to outline a few ways to extract and identify useful strings for creating quality Yara rules. This post focuses on Windows executable files, but can be adapted to other files types. Let’s start with an overview of the types of strings we are interested in when developing Yara rules.
tl;dr
In this post, you will learn:
How to extract ASCII and Encoded strings from malware samples.
How to analyse strings from a malware sample set and choose strings for your Yara rule.
Tips and other tools to assist in Yara rule creation.
ASCII vs. Encoded Strings
Windows executables normally contain both ASCII and encoded strings. A “string” typically refers to a sequence of alphanumeric and special characters arranged in a specific order. Strings are used to represent various types of data, including file names, paths, URL’s, and other content within files. ASCII and encoded strings refer to different concepts in the context of character representation.
An ASCII string is a character encoding standard that uses numeric codes to represent characters. ASCII is a straightforward encoding, but it has limitations when it comes to representing characters from other languages or special symbols. Encoded strings generally refer to representing text using a specific character encoding scheme, such as Unicode (16-bit Unicode Transformation Format, or UTF-16, and sometimes referred to as “wide” strings) which is standard in Windows executable files. When writing Yara rules for Windows executables, we normally want to focus on both ASCII and Unicode strings. So, how do we extract these strings from an executable file? Glad you asked.
Extracting Strings
The simplest way to extract ASCII strings is using the strings tool in Linux/Unix (also available in Windows and MacOS). Execute the command on your malware executable target, and save the output to a text file like so:
strings -n 4 -e l malware.exe > malware-encoded-strings.txt
Once we have our strings, let’s dump them into a Yara rule, shall we? Heh… Not so fast, cowboy. We have some strings analysis work to do first.
Analyzing Strings
One of the challenges with using strings for detecting malware is that there are so.. many.. strings. A single executable file could have thousands. How do we know the good strings, from the bad strings, from the ugly strings? How can we know which to include in our Yara rule?
If you have a single malware executable, you’ll have lots of strings to dig through (depending on the size of the executable file, of course). The trick is to identify the strings that are likely related to the malware itself, while disregarding and filtering out the strings that are not directly related to the malware that we may not be interested in (such as compiler data and code, common strings that also reside in benign files, etc.). It takes experience to know what to look for and what to ignore.
If you have a number of files of the same malware family, this process can be a bit more efficient. What we need to do is gather our malware sample set, extract all strings from these samples, and compare these strings to identify the strings we should zero in on for our Yara rule.
This malware sample set must meet the following requirements:
The malware samples should be part from the same malware family. For example, if you are developing a Yara rule for Ryuk ransomware, all samples should be Ryuk ransomware, otherwise bad samples/strings will taint your Yara rule.
The malware samples should be unpacked/deobfuscated. If the samples are packed, encrypted, obfuscated, etc., you are no longer writing a Yara rule for the malware itself, but rather for the packer/obfuscator. If this is your intention, that’s perfectly fine, as there are valid use cases for this as well!
The malware samples should be of the same file type. It’s not a good idea to mix Windows executables with MS Office documents, for example.
The more malware samples you have in your set, the more accurate your Yara rule could be.
We can extract and analyse all strings in a malware sample set with a one-liner command. First, make sure you have your malware samples together in one directory called “samples”. (I am assuming you are on a *Nix system here, but the following command can be adapted for Windows as well with a bit of work):
for file in $(ls ./samples/*); do strings -n 4 $file | sort | uniq; done | sort | uniq -c | sort -rn > count_malware_strings.txt
In the above command, we create a for loop that iterates over all files in our samples directory (“samples”). Each file’s strings are extracted and sorted, and finally we append a “count” value to each string and save this to a text file “count_malware_strings.txt”. Here is a screenshot of the result:
You may be able to spot some interesting strings. The number “9″ next to each line denotes the number of samples this string resides in. My sample set consists of 9 samples, so each string with a 9 next to it means that this string resides in all my malware samples!
We should also run this same command, but for encoded strings:
for file in $(ls ./samples/*); do strings -n 4 -e l $file | sort | uniq; done | sort | uniq -c | sort -rn > count_malware_strings_encoded.txt
Here is the result:
See any interesting strings here? Perhaps the references to WMI (SELECT * …), the sandbox-related strings (“sandbox”), and strings such as “Running Processes.txt”?
Selecting Strings for the Yara Rule
So, now we have a much better idea of what strings to use in our Yara file. Ideally, we’ll want to select strings that are in all or most of the sample set. Selecting strings that are in only one file may result in lots of false-positives (depending on what type of rule you are creating and what your objectives are, of course). However, selecting only strings that appear in all files may result in your Yara rule being too specific. Again, this will depend on your objectives for the rule.
Consider also that even though you are dealing with malware, there will be “benign” strings (sometimes called “goodware strings”) in these files that are not part of the malware’s code or functionalities. You’ll likely want to weed these out. Optionally, you could create a goodware strings database or list that simply contains strings you wish to exclude from your Yara rules. But this is a topic for another day.
Creating our Yara Rule
Based on the strings I observed in the strings text files I created previously, I chose the following strings and created my basic Yara rule:
Notice how I added the “wide” attribute to some of the strings. This tells Yara that these are encoded strings. For the conditions at the bottom, I am specifically looking for samples that have the header bytes 0x5A4D (meaning a Windows PE file), and the sample must have 15 or more of these strings residing in them. Lowering this number will result in more of a “hunting” rule, where you may catch additional malware (with a wider net) but have more false positives. Increasing this number will create a higher-fidelity rule, but may be too specific.
Other Tools and Tips
Here are a few other random tips/tricks for dealing with strings in Yara rules:
PE Studio– PE Studio is a great PE executable file analysis tool that also has a nice “goodware” and “malware” strings database built-in. You can open an executable file in PE Studio and the tool will provide you with some hints on which strings may be interesting.
Strings-Sifter – A tool created by Mandiant, it can “sift” through strings and sort them based on how unique or “malicious” they are. This is very useful for quickly identifying the interesting strings.
Yargen – A full-on cheatmode for Yara rules. Yargen is a tool from Florian Roth that takes an input sample set and automatically generates Yara rules based on interesting strings or code in the files. This is a great tool if you are pressed for time or if you have lots of rules to create. However, nothing beats a well-tuned, manually-written rule (in my humble, old-school, boomer opinion). Also, if you are new to Yara and/or malware analysis, stay away from the automatic tools and just do it manually, please 🙂
Conclusion
I hope this short post helps you create better Yara rules! If you have further suggestions or ideas, send them to me and I may include them in this post or in future posts!
I recently was investigating a memory dump from a host infected with BlackEnergy3. BlackEnergy3, which is a modified version of the original BlackEnergy malware families, was used in the attacks on the Ukrainian power grid in 2015. BlackEnergy3 is similar to its version 2 counterpart, but has been modified with additional modules that serve multiple purposes such as extraction of credentials, keystroke logging, and destruction capabilities.
This post is a sort of a step-by-step methodology for investigating BlackEnergy3 infections, and more generally, rootkit behavior in memory. I will be using Volatility as my primary tool for this investigation.
Edit: One reader asked which sample I used for this investigation. This write-up is from a memory image provided by SANS and was included with the Advanced Memory Forensics and Threat Detection course. (This course is highly recommended if you are interested in memory forensics and hunting advanced malware!). I don’t know exactly which sample was used on the infected system, but I found a possible similar sample on VirusTotal here.
Investigating Userland
I always start a memory forensics investigation by inspecting the processes that were running on the system before the memory was extracted. The Volatility “Pstree” command provides an output of processes in a nice tree-based form:
vol.py -f memdump.img --profile=Win7SP1x64 pstree
What we should be looking for here are strange process parent/child relationships, orphaned processes (processes with no parent), and processes that seem out of place, such as strange or misspelled process names. We see no clear evidence of any of this type of activity:
Output from pstree command.
Let’s dig a bit deeper. One of my goto Volatility modules for quick wins is “malfind”. “Malfind” will enumerate the Virtual Address Descriptors (VADs) tables for each process running on the system, and attempts to find anomalies and possible evidence of code injection.
After running “malfind”, we can see an anomaly right off the bat – possible code injection into “svchost.exe” (PID 1468) process:
Output of malfind command.
We can see above that the memory permission for this region is “PAGE_EXECUTE_READWRITE”, which means that this area of memory possibly contains executable code. We can also see the “MZ” header synonymous with Windows PE files, so this is highly likely malicious code injection. For closer inspection, let’s dump out this region of memory into a file using “vaddump”:
We can now inspect this area of memory by simply running the “strings” command on the dumped memory region we are interested in (“0x1a0000”):
strings -n8 svchost.exe.7e4aa060.0x00000000001a0000-0x00000000001affff.dmp | less
Output of strings command.
There are several interesting strings here. There is a reference to “aPLib”, which is a library for compressing and packing executable files. This means that the injected malicious code was likely packed, which is definitely a red flag and out of place in a process such as “svchost.exe”. Also, there are references to a user agent string, references to DLL files and a DAT file, and several references to possible API function calls.
A quick Google search shows that many of these strings are actually part of the Command & Control functionality of BlackEnergy3:
DownloadFile – Retrieves a file from the Internet.
RkLoadKernelImage – Used to load code into kernel memory address space.
RkLoadKernelObject – Used to load a new driver module into kernel memory from userland memory.
SrvAddRequestBinaryData – Used to append binary data to the C2 HTTP POST data (for C2 communication and payload download).
Srv* – These commands are used for C2 communication.
“main.dll” – The internal name of BlackEnergy’s primary DLL file.
The presence of these kernel-related functions signal that we are dealing with a rootkit.
Hunting for Rootkits
After our brief analysis of the injected code into svchost.exe, we know we are dealing with some sort of rootkit behavior. Rootkits typically will load a kernel module or driver into kernel memory space. Let’s hunt for this.
“Modscan” is able to scan kernel memory for loaded drivers and modules, and is the perfect command to use here:
There are a few potentially suspicious modules listed here, but one in particular stands out: “adp94xx.sys”. I was able to determine that this module is out of place by Googlng the other good, benign modules. The only way to know what is not normal is to know what is normal – so it’s good to do some Googling or have a list of normal drivers handy 😉 Let’s dump this kernel driver from memory, using the base address listed above:
Once again, I use the strings command to run a quick inspection of this file:
strings driver.fffff88003fbf000.sys | less
Output of strings command.
We can see several kernel function calls here. Running the same strings command but for Wide strings (16-bit little-endian) encoding, we can see a bit more:
strings -e l driver.fffff88003fbf000.sys | less
Output of encoded strings.
A few items stick out to here. The most obvious is that this driver file appears to be published by Microsoft and is called the “AMD IDE driver”. In addition, we can see several Windows API functions. One example is “SeImpersonaltePrivilege”, which is a Windows API function that can be used to impersonate privileges and access tokens, and is used in some rootkits and privilege escalation exploits. This function is just a clue into the functionality of this driver. Finally, we see a reference to “svchost.exe”, which is what we saw earlier in malscan!
A quick Google search for “AMD IDE driver” and “adp94xx.sys” reveal a few discrepancies. First, “AMD IDE driver” is a real driver name, but does not seem to relate to the file name “adp94xx.sys”. Second, the “adp94xx.sys” could be a legitimate driver, but is related to Adaptec, and not to AMD IDE drivers. This discrepancy proves that hunting for kernel rootkits is a lot about knowing what is and what is not normal, and knowing how to Google 😉
There are a few imports we should focus on here. One function of interest is “KeStackAttach”. According to Microsoft, KeStackAttachProcess attaches a specified process thread to the address space of another process. This functionality can be used to run code from the kernel module rootkit in the context of a userland process, which essentially serves as a very stealthy way to run code.
As a quick tip, we can also extract the imports in a format that can be imported into IDA for later analysis:
Later, we can look at this module in IDA or another disassembler in order to better understand it. This is out of the scope of this post, but this is something that should be done during an investigation.
Wrapping Up
From the investigation above, we can make several inferences (or at least, educated guesses) from this data.
Malicious code was injected into the “svchost.exe” process. Once executed, this code likely downloads an additional module from the Internet (using the DownloadFile function).
The malware may have executed its rootkit behavior be leveraging its “RkLoadKernelObject” function, which allows code execution in the context of the kernel.
Once in kernel memory, the rootkit is able to hide on the system, and inject additional malicious code into other userland processes, further embedding itself in the system in stealthy way.
This of course is not a complete investigation of BlackEnergy3, but shows what can be done to quickly triage rootkit behaviors. You can likely see that hunting rootkits, and memory hunting in general, takes a combined approach of cross-referencing the output of multiple tools, Googling things, and understanding what is and what is not normal Windows behavior.
Bonus: For sticking with me this long, you may have noticed 2 “iexplore” processes in the “pstree” output:
Internet Explorer processes from pslist output.
These are actually the product of a special module that BlackEnergy3 is able to deploy called the “Ibank” module. This module injects itself into Internet Explorer processes and is able to steal banking credentials from its victims 🙂
