On August 14, I came across an interesting piece of research published by Gen Digital. The researchers had found a custom Windows backdoor of roughly 12 KB on a single corporate workstation. It was a small implant with a limited command set, but what caught my attention was not what the backdoor could do. It was the way it stored information it needed to operate.
##Where Is the C2 Address?
When the backdoor starts, it reads a desktop.ini file under PROGRAMDATA. Open that file normally and it looks almost empty. The important data is not stored as a visible string.
Instead, the C2 address is represented by the amount of whitespace at the end of each line. The malware counts those spaces and interprets the resulting values as characters. In the sample analyzed by the researchers, this process reconstructs the domain diagrtrack.com.
There is no conventional decryption step involved. The researchers found no encrypted data blob, packer, import hashing, or anti-debug mechanism in the binary. The config itself is represented by something we would normally be tempted to ignore: spaces.
The fact that the technique is simple is part of what makes it interesting.
##Changing the Question During Analysis
When looking for C2 information in a malware sample, strings are an obvious place to start. If no domain or IP appears there, we may begin looking for encryption, encoding, or some other form of obfuscation. Asking “Where is the C2 address stored inside the binary?” can keep us looking in the wrong place.
Where does the malware obtain the C2 address from?
That question can move the analysis in a different direction. The difference sounds small, but it can completely change the direction of an analysis. Configuration data does not have to live inside the binary. It may come from another file, the registry, a resource, the network, or be reconstructed at runtime.
Not finding a value in the strings therefore does not mean the value does not exist.
Imagine that we locate the code responsible for making the network connection. Instead of continuing to search the entire binary for a domain, we can trace the value passed into that function. Where does it come from? Which function builds it? Is it read from a file?
In this case, following those questions eventually leads to desktop.ini.
##When an “Empty” File Is Not Empty
This is the part of the research I find especially useful from an analyst's perspective.
If we quickly open a desktop.ini file, trailing spaces are unlikely to look meaningful. In most contexts, whitespace is simply formatting. For this backdoor, however, those spaces are the C2 configuration.
I made a similar point in my earlier article about encryption. The first question for an analyst should not always be “Which encryption algorithm is being used?” It is often more useful to understand what data is being hidden, where it comes from, and how the malware recovers it.
This case takes the same idea in a simpler direction. There is no encryption algorithm to reverse at all. The malware simply takes advantage of something we may not consider data in the first place. Something that looks meaningless to us does not have to be meaningless to the program. Sometimes the most useful question is not what the data looks like, but what the code does with it.
##Why One Machine Matters
Another interesting detail is that the researchers observed the implant on only one system. Low prevalence can easily make a sample look unimportant at first glance, but that interpretation does not always hold.
The researchers describe the implant as custom-built, note that the configuration format did not appear elsewhere in their corpus, and found no convincing related samples. They therefore consider selective or targeted deployment plausible, while explicitly stopping short of attributing the activity to a specific actor or campaign.
Low prevalence does not necessarily mean low priority.
Commodity malware seen across thousands of systems and a custom implant seen on one endpoint should not automatically be treated the same way.
##Conclusion
What interested me about this research was not a sophisticated exploit or a new cryptographic technique. It was the fact that something as ordinary as whitespace could become meaningful configuration data.
When a piece of information seems to be missing during analysis, focusing only on where it might be hidden can limit us. Sometimes it is more useful to follow how the malware obtains that information in the first place.
Because in malware analysis, the most valuable clue is not always in the place that looks suspicious. Sometimes it is sitting inside something that looks completely empty.
Stay with Malrev0x...