Is it possible there exists malware capable of infecting the deepest parts of a computer? That knows exactly when you’re looking for it and communicates over high-frequency speaker sounds?
To the average person, this may seem a little far-fetched. However, if you ask a man named Dragos Ruiu, you’ll likely be met with a confident “yes.”
Dubbed “badBIOS,” Ruiu discovered the malware three years ago when he noticed a strange behavior on his Macbook Air. Since then, it’s been an ongoing battle. Continue reading
If you’ve performed malware research, you’ve likely observed samples that are very similar in functionality, yet have different hashes, file sizes, etc.
When looking at the same malware at the assembly level, you might have noticed the “differing” malware may have functions and strings that are exactly the same.
Given enough analysis time, researchers can attribute samples to certain malware families. However, in-depth analysis methods (such as reverse engineering) can be a lengthy process, and that’s why tools are developed to streamline the analysis process and assist researchers in rapid identification when possible.
Even still, many of these tools have their own flaws; for example, some malware can bypass a sandbox altogether.
Fortunately, there are other tools we can fine tune to assist researchers in quick and easy identification of malware. One of these tools is known as YARA.
Just last month, antivirus companies discovered a new ransomware known as Cryptolocker.
This ransomware is particularly nasty because infected users are in danger of losing their personal files forever.
Debuggers—a tool traditionally used to find errors (called “bugs”) in code—are also used by security experts. In the field of malware analysis, debuggers are a vital tool used to reverse-engineer malware binaries, helping analysts to understand the purpose and functionality of malware when dynamic analysis isn’t enough.
Because they’re such a valuable tool, sometimes malware authors try to prevent analysts from using them. By employing various techniques in the code (known as “anti-debugging”), malware can successfully thwart junior analysts.
Recently I found an interesting anti-debugging technique I haven’t seen before. I discovered this technique while reversing a ZeroAccess Trojan (seems it’s always ZeroAccess lately, right?).
The technique employs various native Win32 APIs used for debugging a process. By using these APIs, the analyst cannot use their own debugger, since only one debugger can be attached to a process at a time.
To connect to the debugger at the API level, the Trojan uses DbgUIConnectToDbg. This API along with others used to communicate with the Windows Debugger all seem to be undocumented by Microsoft.
When analyzing malware, what you see on disk is oftentimes not an accurate representation of what’s actually happening in memory.
Today’s malware has a unique way of hiding and likes to bend the rules that most computer programs follow. No matter what it is, there is always something special that makes a malicious program unique and sets it apart from a normal program.
As a Malware reverse engineer, it’s not only my job to discover what that special “thing” is, but to attempt to understand what the malicious program is really doing, and do my best to explain how and why.
The purpose of this article is to provide our readers with an understanding of how malware operates within memory. Since you need to know some basic memory terms before trying to understand how they relate to malware, we’re going to explain some concepts first.