CHAPTER
4
Protective Mechanisms
Deploying malware is a risky business. The deployment technology or malware infection vector can be intercepted, opening up the malware it is carrying to exposure. Once a malware is deployed, it always carries with it the risk of being captured. And once the malware is captured, it can then be analyzed, which is not a good thing for the attackers because this leads to the malware’s behavior being understood and the malware technologies being discovered. With all this knowledge, researchers then have the ability to stop the spread of the malware by blocking whatever infection vector it is using and can create a solution for the malware to prevent it from achieving its purpose. To avoid ratting itself out and revealing everything to researchers, the malware must have the ability to protect itself when captured.
Malware employs different mechanisms to protect itself from the prying eyes of researchers and analysts. The protective mechanisms used by malware are designed to evade analysis and detection or at least buy some time long enough for it to achieve its directive. This is of paramount importance, especially if the malware is utilizing a new malware technology or a zero-day exploit. Discovery of this new technology and exploit by researchers and analyst can lead to the development of solutions not only against the current malware but also against future malware creations that will utilize these same malware technologies.
Protective mechanisms are therefore designed to make it difficult for security products to detect the delivery, installation, and presence of malware and for researchers to analyze and uncover malware behavior and new malware technologies. In the case of researchers, the real goal of malware is to make unraveling the protective mechanisms so challenging and time-consuming that it is next to impossible.
In this chapter, I will discuss the different protective mechanisms employed by malware and how malware applies these evasion techniques while it is being deployed and while it is running in a target system. Understanding how a malware protects itself and familiarizing yourself with the different technologies a malware uses to protect itself is key to removing these protective mechanisms so malware analysis can proceed.
The Two States of Malware
As mentioned in Chapter 1, malware exists in two states.
Static
Dynamic
Static malware is malware at rest, which means that the malware is not running or active in the system it is in. Dynamic malware is malware in motion, which means that the malware is running or currently being executed in the system it is in.
NOTE
These two states are not exclusive to malware. These two states apply to all executables, benign or malicious.
Malware must be able to protect itself regardless of what state it is in. Attackers know this to be true. A malware before it is executed will always be in a static state first. For it to be able to achieve dynamic state, it must be able to survive in a static state. Survival here means it is not detected by any security products and not easily analyzed by malware analysts and researchers. Once it reaches the dynamic state, the malware can then utilize other protective mechanisms that it is endowed with so it has enough time to achieve its directives.
Static Malware
A malware that is being transported by a deployment technology such as a physical drive or e-mail is a malware at rest. This is usually a good time to capture malware because it is powerless in this state. It cannot do anything to prevent anyone from copying it from the deployment technology and distributing it to other analysts and researchers for further analysis. Whatever protective mechanisms it has that are activated by its malware code are rendered useless. But this does not mean the malware is easy to crack. The attackers have taken this into consideration, which is why static malware or malware at rest also has protective mechanisms built in.
Dynamic Malware
Dynamic malware, or malware in motion, is malware that is currently active or running in a system. Unlike static malware, dynamic malware has all the encoded protective mechanisms available to it; therefore, it can actively defend itself from scanning by security products, from the invasive system-monitoring tools that record the malware’s every move, and from the prying eyes of researchers.
A running malware can actively protect itself. It has full access to its codes and features that the attackers built into the malware. It has the ability to react to whatever changes there are in the target system it is running on and to guard against any tools that are used for the purpose of extracting and analyzing it.
Protective Mechanisms
The attackers understand the risk of malware being captured through interception of the malware infection vector used or through extraction from the compromised system. This is why highly funded attackers invest heavily in different evasion technologies to protect their malware. A malware’s main goal is to impede detection and analysis. The more time it takes for researchers and analysts to understand malware, the more time the attackers have to achieve their directive. It is therefore essential that malware researchers and analysts understand the different protective mechanisms employed by malware. The ability to recognize and mitigate these protective mechanisms is important so malware analysis can proceed.
LINGO
Malware protective mechanisms are also known as evasion technologies.
The attackers choose or create malware for their attack campaign with the goal and expectation that it will be successful. They do everything that is technically possible within their capability to protect their malware creation. A well-funded attacker group might have access to more malware protective mechanisms and technologies, while those that form a rag-tag group might have limited options. Regardless of the funding, the main idea is that the attackers will do everything in their power to protect their malware to achieve success in their attack campaign.
A successful malware is one that has the ability to evade detection and analysis for it to function as intended by the attacker. Evading detection enables it to reach its target and execute unimpeded. Evading analysis enables it to conceal its real purpose when subjected to malware analysis and reversing. To achieve this, the malware must employ protective mechanisms for it to survive long enough to accomplish its directive.
For a malware to be successful, the malware writers must be able to deal with what their creation is up against. The malware faces these two foes:
The security product
The security analysts and researchers
A collection of security products, consisting of both software and hardware, is what stands between the attackers and the individual or organization they are attacking. As much as possible, they want their malware to be able to evade whatever detection technology these security products are employing. To do this, attackers familiarize themselves with the different technologies used by security products so they can come up with ways to circumvent those technologies. If the malware can evade these technologies, it has a better chance of executing and maintaining a foothold in the target system.
Of course, if there is an infection or system compromise, the system will be scrutinized by incident responders or security professionals within the company or from a third party. A captured malware must have the capability to protect itself from analysis. The main idea here is to buy more time. The more time it takes for analysts to break a malware, the more time the attackers have to do whatever they need to do on the compromised system or network. Malware that requires continuous access will need a strong protective mechanism, while other malware might not need any protection at all such as malware used in a hit-and-run attack that usually lasts minutes or hours. A malware used in these types of attacks usually does not need protective mechanisms.
LINGO
A hit-and-run attack is an attack that happens in a short period of time, usually in less time than it takes for the company to deploy a solution to stop the malware.
No matter how many protective mechanisms are used, they can be broken. It just takes time, and it depends on the difficulty level of the protective mechanism being used. The more layers there are, the more time it takes. And if each layer proves to be more difficult than expected, then it becomes more time-consuming.
LINGO
Breaking a malware is a phrase used to describe removing all protective mechanisms employed by malware.
As mentioned, attackers want to defeat the security product and the security analysts and researchers. Almost all protective mechanisms are designed with these goals in mind, which means a malware writer has to consider how to protect the malware whether it is at rest or in motion against security products designed to stop malware and from analysts and researchers eager to dissect the malware to uncover each bit and byte of its functionality.
Static Malware Protective Mechanisms
A static malware is always at the mercy of the analysts. No matter how sophisticated the protective mechanisms its code employs, it is rendered useless because the malware is not executing. The analyst can dissect it and expose its functionality through its extracted malware code.
A malware’s source code is a gold mine. It is the key to understanding all of the malware’s functionalities and all the technologies it is using. It is so important that competing malware writer groups kill their competition by leaking a copy of the competition’s malware source code. If source code is leaked, the malware loses value in the underground market.
The malware’s most important asset is its source code. A malware that is at rest is susceptible to having its code disassembled and reversed. It is therefore imperative for the malware writers to protect the malware code. It is the key to everything. With it, analysts will be able to understand how the malware works and how to stop it. This is why static malware protective mechanisms are all about protecting the malware code. The following are the most common static protective mechanisms employed by malware:
Entry-point obscuring
Basic malware encryption
Polymorphism
Metamorphism
Anti-reversing
LINGO
Malcode is short for malware code.
Entry-Point Obscuring
An entry point is a pointer to the location of an executable’s first instruction. It points to the location where the execution formally starts. For a malware, the entry point almost always points to the start of the malware code. This is especially true for infected host files. Therefore, hiding it is advantageous for the malware because of the following:
Antivirus (AV) scanners use the entry point to find the malware code and match the malware signatures the scanners have in their databases.
With the entry point, reversers are able to disassemble and trace the code through the use of disassemblers and debuggers.
Hiding the malware code’s entry point protects the malware from both analysis and scanning. The protective mechanism that hides a malware code’s entry point is known as entry-point obscuring (EPO). The EPO technique is popular with file-infecting malware. This is because an infected file will always have two sets of code: the malware code and the original host file code. The trick is to hide the malware code by pointing to some benign code. To see how this works, you need to understand how a typical infected host file executes, as shown in Figure 4-1.
Figure 4-1 Typical infected host execution flow.
When an infected host file is executed, the malware code gets executed first. This is because during infection, the malware modifies the target host file’s entry point to point to the attached malware code. The main reason for this is to get initial control of the execution flow of the program. After the malware finishes execution, the control is passed back to the original host file code. This gives the impression that there is nothing wrong because the host file is still executed. This behavior of file-infecting malware makes it easy for analysts to locate the malware code because it is always the first code being pointed to by the infected host file’s entry point.
But EPO malware does things differently. The entry point does not point directly to the malware code; instead, it points to something different. A good illustration of this is an EPO technique that uses code patching, as shown in Figure 4-2.
Figure 4-2 Entry-point obscuring via code patching.
Instead of passing control immediately to the malware, the EPO malware lets the host program execute some of its code, and then a few instructions later, a patched instruction passes control to the malware code. And once the malware finishes executing, it lets the host program continue with its remaining code. This technique is especially effective against AV scanners because the scanner is taken to a set of instructions that are not malicious instead of the real malicious code.
Basic Malware Encryption
Encryption is a good way to hide code. It is used in legitimate software to prevent software piracy and cracking. If it works for legitimate software, it will surely work for malware. With EPO, you saw how malware tries to hide the location of its malicious code, but in malware encryption, the malware is actually protecting the whole malicious program.
An encrypted malware has three components:
The encryption/decryption engine
The encryption/decryption key
The malware code
NOTE
An encrypted program does not mean it is malicious. Encryption is a technology used by software publishers to protect their intellectual property, which includes software code. Malware writers and attackers use it for the same purpose. They do not discriminate between technologies; if they can use it to their advantage, they will use it.
When an encrypted malware is executed, as shown in Figure 4-3, the encryption/decryption engine gets loaded into memory and decrypts the encrypted malware code using the encryption/decryption key. Once the malware code has been decrypted, it then executes its directive. After that, control is passed back to the host program. This is the simplest form of malware encryption.
Figure 4-3 Basic malware encryption during execution.
Basic malware encryption was first used by file infectors to make their infections look different in form and structure from one another. During infection, as shown in Figure 4-4, the decrypted malware code is encrypted by the encryption/decryption engine using a different encryption/decryption key. The new key is usually taken from a series of bytes found in a fixed location of the host file being infected. The location is constant, but the series of bytes found in that location differs for each file. Since the key is different, the newly encrypted malware code looks different from other infections. No two infections are exactly alike. Once malware code encryption is complete, the newly encrypted malware code attaches itself to the host file. The main reason for malware encryption is to avoid detection using a single signature. Instead of AV companies pushing a single signature to detect all infections, it will be forced to push a 1:1 ratio, which does not scale and is a totally ineffective way of solving this problem.
Figure 4-4 Basic malware encryption during infection.
Although this protective mechanism seemed cutting edge at that time, the security companies were able to catch up pretty quickly because one of the three components remained constant. The encryption/decryption key was always different per infection, resulting in the encrypted malware code being different as well from previous infections. But the encryption/decryption engine remained constant. Using the encryption/decryption engine codes, security products were able to create a single signature to catch this basic form of malware encryption.
Polymorphism
Attackers recognized that an improvement had to be made from the basic malware encryption that they were using, so they introduced a new malware technology known as the mutation engine. The mutation engine, which is part of the malware code, basically alters the code of another application without changing the application’s functions. With the introduction of the mutation engine, it is now possible to alter the encryption/decryption engine code without changing its functionality. The three components are now different in every infection. This new form of malware encryption is known as polymorphism. As defined by Merriam-Webster, polymorphism is “the quality or state of existing in or assuming different forms.” This is exactly what polymorphic malware is.
Still, polymorphic malware has a weakness, as shown in Figure 4-5. A polymorphic malware still needs to decrypt the encrypted malware code in memory, and every time the malware code is decrypted, it is constant. It shows its original form. This makes it possible for a signature to be created to detect the malware code in memory or through antivirus emulation techniques. Polymorphic malware is highly effective in defeating static scanning but not the more advanced dynamic scanning.
Figure 4-5 Different generations of polymorphic infections look the same in memory when decrypted.
Metamorphism
The attackers had to come up with a way to counteract the AV technologies used to detect encrypted and polymorphic malware. And so they did. They introduced a new form of encrypted malware known as metamorphic malware, as shown in Figure 4-6.
Figure 4-6 Metamorphic malware infections differ on disk and in memory.
Recognizing that a paradigm shift was needed, the attackers approached the problem differently. They realized that they had a powerful technology on their side in the form of the mutation engine. Instead of working with the three components of malware encryption, they realized that the mutation engine could simply mutate the whole malware code itself. This freed them from the inherent weaknesses of the basic malware encryption and polymorphic techniques. With metamorphism, each malware infection is totally different, both on disk and in memory. Although almost perfect, metamorphic malware still has a weakness because for it to morph, it needs to analyze its own code and reassemble it to its new form. If the mutation engine can do this, the reversers can do it as well, but it takes a lot of time, and the formulated solution might be complicated for existing AV technologies.
Anti-reversing
A sure way to understand malware is through reversing. No matter the protective mechanism, reversing can shed light on how to beat it. The only enemies are time and effort. Depending on the malware’s difficulty level, a reversing session can range from minutes to months. For example, when Ultimate Packer for Executables (UPX) was first used to pack and encrypt malware, it was pretty awesome. It enabled attackers to easily distribute malware with far lesser resistance from security products and the prying eyes of analysts and reversers. Almost all malware used it. But once the packing routine was reversed, unpacking a malware packed with UPX using OllyDbg takes only minutes. Plus, there are a lot of tools available for download that can unpack UPX in seconds.
As a rule of thumb, a malware is deemed successful in implementing anti-reversing techniques when it takes a reverser longer to understand the malware than the malware needs to survive. If an attack campaign uses a malware that needs only a couple of days and it takes a reverser three days to solve that malware, the malware has already won.
The main idea of anti-reversing is to make the reversing process as difficult as possible to the point that it seems impossible to reverse the malware. The most common anti-reversing techniques used to protect static malware are the following:
Anti-decompilers
Anti-disassemblers
If a reverser or the tools he uses cannot decompile or disassemble a malware, the reverser is denied access to the malware source code, and without the source code, reversing cannot proceed. But there is a drawback in this protective mechanism. It works only for decompilers and disassemblers supported by the malware. This is because decompilers and disassemblers, like other software products, have their own proprietary design, algorithm, and implementation. For example, a malware with anti-disassembler capability can support only the IDA disassembler but not others such as Win32DASM. So if a reverser uses IDA, it might not work as planned, but using Win32DASM might yield the output the reverser desires since the anti-disassembler technology used by the malware does not support Win32DASM. Usually, malware that uses anti-decompiler or anti-disassembler protective mechanisms supports the most popular tool that reversers use. Again, the main point is to make life difficult for reversers. It takes the reversers more time and effort to reverse the malware. And if the malware is able to achieve this, that is, buy more time for the malware to finish its directive, then the anti-reversing protective mechanism has done its job.
NOTE
Entry-point obfuscation, code obfuscation through encryption, polymorphism, and metamorphism also slow down reversing. So, in effect, these protective mechanisms can also be viewed as anti-reversing technologies.
Dynamic Malware Protective Mechanisms
When a malware is in motion, i.e., running in the system, it has the full capabilities of its code. This means, when executing, the malware has available to it whatever protective mechanism it is endowed with by its writer.
The following are the most common protective mechanisms employed by dynamic malware:
Anti-debugging
Anti-sandboxing
Environment lock
Anti-AV scanning
Network behavior protection
Anti-debugging
One of the most effective ways of tracing malware is to use a debugger. This enables a reverser to follow the malware as it executes per line of code, look at the contents of memory and the system’s registers, and examine the changes done to the system by the malware. Debugging is an important part of reversing. Without it, it is extremely hard to do a reversing session. This is why an anti-debugging protective mechanism is attractive to attackers.
The main goal of anti-debugging is to fool the debugger into following a deadend execution flow, making it difficult for the reverser. The more difficult it is, the more time and effort that are needed. Sometimes, this is more than enough for the malware to be successful.
TIP
It is always good to have disassembled code available while doing a debugging session. This is a good way to check for inconsistencies between the disassembled code and the actual execution path the debugger is taking.
Anti-sandboxing
In rare cases, static analysis is enough to extract information from malware that reveals its directive, but in most cases dynamic analysis is needed. As defined in Chapter 1, dynamic analysis is the process of extracting information from malware through the use of system monitoring tools and technologies. Usually, dynamic analysis is done by using a sandbox. A sandbox can be manually driven, or it can be automated. The following are the two most important components of a sandbox:
Sandbox environment
System monitoring tools
The sandbox environment is the system where the malware is executed. During execution, the malware is supposed to do what it was designed to do. The system monitoring tools make sure that everything the malware does on the system is captured and logged for analysis purposes. If the malware does not execute in the sandbox, no information is extracted, and the whole process fails. This is the key to beating a sandbox. The malware must be intelligent enough to know whether it is running in a target system or in a controlled sandbox.
Anti-sandboxing techniques usually cover two things.
Detection of sandbox environment
Detection of system monitoring tools
See Figure 4-7 for an illustration of anti-sandboxing technology in action.
Figure 4-7 Anti-sandboxing technology in action.
Detection of Sandbox Environment If a malware knows that it is running in a sandbox or a malware test environment, it does not need to execute, so no information can be captured during dynamic analysis. Most sandbox implementations are virtual because of the many advantages this offers such as portability and easy restoration. So, for malware to know whether it is running in a sandbox, it needs to know only whether it is running in a virtualized environment. This led to the most popular anti-sandboxing technology: the anti-virtualization technique. This technique simply detects telltale signs common to virtual machines. If the malware senses any indication of it running in a virtualized environment, it will simply exit and do nothing.
Malware programs with only anti-virtualization techniques are often used for opportunistic attacks, which result in more home users being infected because most of them are not using virtualized systems.
Detection of System Monitoring Tools Not all sandboxes are implemented in a virtualized environment. Bare-metal sandbox implementations are available as well. This solves the anti-virtualization technique employed by most malware, but it costs more to implement, and restoring images takes longer compared to the virtualized counterpart.
As previously mentioned, a sandbox has two important components: the sandbox environment and the system monitoring tools. Without the system monitoring tools, no information can be extracted from the running malware. In bare-metal implementations, a malware relies on detecting the presence of system monitoring tools. This is the opening the malware writers have to beat bare-metal sandbox implementations.
As with other software, system monitoring tools leave telltale signs or footprints in the system whether they are running or not. The malware writers simply familiarize themselves with these tools and the footprints they leave in the system and arm their malware with the ability to detect the presence of these footprints. If a malware detects the presence of any of these telltale signs, it exits and does nothing.
NOTE
Some instances of malware, especially malware used in targeted attacks, will stop execution only if they detect system monitoring tools running, because most enterprise production systems are virtualized.
Environment Lock
Malware is designed primarily to execute to do its job. If it does not execute in the target system, then it has failed. But it must be intelligent enough to know whether it is running in a target system or in a malware test environment.
Most of the time, malware is captured from a compromised system. It is then subjected to static and dynamic analysis to extract information from it. The environment lock feature protects the malware from dynamic analysis. The main idea of this protective mechanism is to have the malware execute only in the environment it initially compromised. Getting that malware out of that environment and have it execute in any other system, be it a sandbox or just another system, will not work. This is because during its first execution on its target system, the malware takes environment-specific markers—such as the hardware ID, media access control (MAC) address, or anything that is unique to the system—as variables or encryption keys and mutates itself by using these keys, which then become the conditions for its execution. The resulting mutated malware will run only in the first compromised system and nowhere else. If the malware is moved to another system and the system-specific markers do not match, it will not be able to decrypt its code in memory and execute. Capturing a malware with an environment lock feature and subjecting it to a sandbox for dynamic analysis will not yield any result. This virtually defeats dynamic analysis.
Anti-AV Scanning
The malware’s foremost nemesis has always been the AV product, and malware writers know that their creations can be beaten if AV is able to scan and detect them. Detection depends on the signatures the AV product has. It can specifically detect and identify a malware if there is a signature that matches the malware’s characteristics. For malware that is totally new and not covered by any specific detection, the AV product uses heuristic detection. Depending on how the heuristic signature is written and the number of malware samples that a heuristic signature is based upon, it can be effective or not. And to ensure that the system is always protected, real-time scanning is always enabled. This is an AV feature that lets it reside in memory, keeping a watchful eye on the file system on disk and the programs loaded and executed in memory.
A malware can arrive in a target system in different ways; it depends on the deployment technology used. The malware can be downloaded from the Internet or can arrive as an attachment in e-mail. If this is the case, the malware typically undergoes static scanning. Obviously, static scanning is easy to defeat given the available static malware protective mechanisms the attackers use. So, almost all the time, malware gets into the system undetected. Once the malware is executed in the target system, the AV product uses dynamic scanning to inspect the malware during runtime. Depending on the current signature database of the AV product, the malware might get detected using specific or heuristic detection. But before any signature matching takes place, the AV scanner must be able to find the malware code. It does not matter whether it’s static or dynamic scanning; the scanning flow is the same, which is to find the right entry point to the malware code. The only difference is that in dynamic scanning, the memory image of the malware is the one that is being scanned. Given that the scanning flow is the same, some code obfuscation techniques that worked in protecting static malware also work in protecting dynamic malware. The most effective protective mechanism techniques that usually work for both states of malware are entry-point obscuring and metamorphism.
Another anti-AV scanning technology used by malware to protect itself from scanning is to simply turn off the AV product altogether and deny access to AV vendors’ websites. The same concept as the one used in detecting the presence of system monitoring tools is applied, but this time, the presence of AV products is the one being detected. Once detected, the malware turns off the AV product. This works only if the malware is totally new and not detected by the installed AV product. Given the protective mechanisms available to attackers, this is not hard to do.
An easier anti-AV scanning alternative is to use a security product’s “Do Not Scan List.” The malware simply adds itself to that list so every time a scan is performed, the security product will skip the malware. Again, this works only if the malware is new and not detected when it first compromises the target system.
Network Behavior Protection
With the rise of botnets and the agility it offers to attackers, most malware used in attack campaigns must have the capability to communicate to the attacker. Communication can be one-way or two-way. One-way communication means the malware can accept commands or directives only from the attackers, while two-way communication means the malware not only has the capability to accept commands but also can post status updates or any other information that the attacker needs.
When a malware is running in a compromised system, the most common way it communicates to its command-and-control (C&C) is through the use of domains.
Command-and-control is also known as CnC, C&C, or C2.
Every time a malware communicates, it leaves network traces. Network logs can see what domains it connects to, and network sniffers can tell what data it is sending and receiving. Because of this, domains that are used as C&C are collected and can be added to a blacklist to be used to detect the presence of malware in the network. An endpoint that attempts to communicate to any of these known malicious domains will be flagged and disconnected from the network for analysis purposes. This effectively kills what the malware is trying to do. No matter how good the malware is at hiding or protecting itself in the endpoint, its network behavior is enough to betray it and shout to the whole world of its existence.
Because of this, attackers have devised ways of protecting their malware’s network behavior from detection and analysis. The following technologies are commonly used to accomplish this:
Domain fluxing
Internet Protocol (IP) fluxing
Abusing legitimate services
Domain Fluxing When the first botnets came out, most malware used in these botnets had hard-coded domains; therefore, once these domains were discovered, all instances of that malware could easily be detected using a domain blacklist technology. There was no need to invest time in doing forensics in a suspected infected host or endpoint. The domains decided the endpoint’s guilt. And most of the time, this was enough. If the endpoint was not critical, some organizations would simply restore it to an original clean state. This saved them effort and time in restoration.
Attackers understood that this was a major weakness even for the most sophisticated malware, so they came out with domain fluxing. Domain fluxing is the ability of malware to generate unique domain names on regular intervals, usually a day. This is made possible by a domain generation algorithm (DGA) that is coded into the malware. With this protective mechanism, the domain blacklist is rendered useless because whatever is added on a certain day becomes obsolete the next day.
The most infamous malware that utilizes DGA is Conficker. Conficker.A and Conficker.B can generate 500 unique domain names in a day, while Conficker.C can generate 50,000 unique domain names in a day.
It is important to note that not all of these domains are active. Out of the large number of domain names produced, only a handful or even a single one will be active. The rest are NXDOMAINS. This is one flaw of this technique because an endpoint that attempts to connect to massive amounts of NXDOMAINS can trigger a network rule and thus be flagged for suspicious activity.
LINGO
NXDOMAINS is short for non-existent domains.
IP Fluxing IP fluxing refers to having a single domain name resolve to a frequently changing IP address. This protective mechanism, when combined with domain fluxing, can be a powerful anti-detection and anti-takedown protection. With a rotating IP address, identifying (and taking down) the C&C server is challenging.
LINGO
IP fluxing is also known as fast fluxing.
This protective mechanism beats IP blacklists but not domain blacklists, especially if the malware does not use this capability together with domain fluxing. This is because this protective mechanism is geared toward hiding the C&C and not the malware itself.
Abusing Legitimate Services Another way for malware to hide its network communications is by using known and legitimate services within the network. For example, if a network allows peer-to-peer communication within the organization, a peer-to-peer (P2P) malware might be used, so its communication with other peers will not raise any flags. A malware can use social media posts or updates as its command and control; for example, tweets that the malware monitors can appear to be normal musings of the account owner but in fact are commands that the malware can understand and act upon. This is also true for wall postings and updates on other social media networks. A malware can even utilize free hosting services to get updates or commands from attackers. Network rules and policies may not raise an alert to any of these network communications because they are known to be legitimate, and the domains the malware are connecting to are popular domains that are known to be benign. The only way to stop malware that abuse these services is by blocking the services.
When it comes to hiding network activity, malware cannot hide everything. There will be network footprints, and they can easily be identified. The attackers understand this; therefore, malware used for attacks with the directive of hiding and maintaining a foothold on the system will seldom connect to any network resource. These types of malware might connect once a week or even less frequently. This makes a malware’s network footprint a drop in the bucket in the daunting world of network logs.
Recap
In this chapter, I discussed protective mechanisms employed by malware. These protective mechanisms are designed to protect malware against its two foes. They are as follows:
The security product
The security analysts and researchers
I enumerated the two states of malware that the attackers concern themselves with when protecting malware against security products and security researchers. They are as follows:
Static
Dynamic
I then discussed the different protective mechanisms used to protect malware at each of these states.
The following are the common protective mechanisms employed by static malware:
Entry-point obscuring
Basic malware encryption
Polymorphism
Metamorphism
Anti-reversing
The following list are the common protective mechanisms employed by dynamic malware:
Anti-debugging
Anti-sandboxing
Environment lock
Anti-AV scanning
Network behavior protection
Familiarizing yourself with these protective mechanisms regardless of which malware state they are employed in enables you to make adjustments to the analysis process so that analysis can proceed.