You’ve identified malware in your network. Now what? To effectively contain, investigate, or remediate your incident thoroughly ultimately depends on what specifically you’re dealing with. Perhaps it is a variant of a widely publicized banking trojan, a novel new worm that’s running rife, POS malware targeting credit card data or a stealthy piece of custom malware positioned by an advanced adversary.
In all cases, specific information regarding the functionality, configuration or characteristics of the malware is going to help you detect and understand any compromise and help thwart the attacker’s efforts.
Establishing the required information about a given malware sample in sufficient detail in a fast and efficient way is often not trivial. You can use a variety of analysis techniques and approaches to help here. Some can be reasonably fast, while others can be time consuming and often require complicated analysis. Under the pressure of an incident, it is important to recognize that there are potentially costly mistakes that could undermine the response by not having sufficient insight into the capabilities or characteristics of the malware involved. Remediation efforts could be incomplete, the scope of the breach and particulars of compromised assets may be under estimated or undetected The adage “If it looks like a duck, walks like a duck, swims like a duck and quacks like a duck…” can apply, but at what point can a malware analysis allow for conclusions to be made in that regard? In an iterative and ongoing hand-off of information, when is there enough information for an incident handler to decide to act? Can jumping to conclusions in the heat of the moment undermine the response effort?
Static analysis performed on the sample without executing the code will often yield the best information but can be time consuming. Generally a quick first step in a basic static analysis might be to extract all the readable strings from a sample. Assuming the malware sample isn’t packed or encrypted, seeing a list of strings extracted from within might seem illuminating: recognizable filenames, folder paths, registry keys, URLs, IP addresses, API references, etc. At this point there may be a temptation to draw on experience and use inferences and theories based on the recognizable strings in lieu of an actual understanding of what the malware does. To apply the “duck test” analogy, these strings represent seeing a slightly duck-shaped bird on the horizon, standing still.
Suppose some of these strings are debugging information left in the sample by the author, and the real configuration information specified for this attack is obfuscated in some way. For example, maybe the author is deliberately attempting to subvert the analysis with easily obtainable misinformation. Perhaps a proportion of these strings are used as expected, but there are failover CnC servers that are determined through the use of a time-dependent domain name algorithm. Maybe this apparently full suite malware is, in this case, only being used as a loader for another randomly named piece of malware. What if there is a condition within the malware that means it only runs on a specific operating system at a given patch level? There are a myriad of possibilities, and without knowing more information or having a level of certainty it remains difficult for an incident handler to make informed decisions or take the most appropriate course of action in their response.
Anti-virus, endpoint monitoring solutions, and wider threat intelligence research can all help in identifying what the sample might be based on similarities to other known malware. In the “duck test: analogy, this equates to: The bird looks a lot like another bird that is known to be a duck. This information can be helpful, but it will not take into account any variance, customization, or the specific details relevant to the incident at hand. Depending on the nature of the incident, the handler may decide whether or not on balance, there is sufficient information.
Both automated sandbox analysis and behavioral or dynamic testing can help reveal further information concerning the malware sample being executed under certain conditions. However, these efforts can easily be hampered by nefarious protections employed by the malware, including the ability to detect itself running in a virtual machine or sleeping for so long that an automated environment times out before anything happens. Any behavioral or dynamic analysis performed is often only going to result in a small proportion of the code being explored and will be limited to a small number of very specific code path possibilities. Applying the “duck test,” this type of analysis might suggest how the bird might walk or swim, but only some of the time.
Investigative findings from host or network forensics may correlate with any of the aforementioned analyses undertaken lending weight to support some conclusions–e.g.,the bird on the horizon may start to look more duck-shaped, or you may see the tracks left by its waddling. However, the same caveats around not knowing the full context should still apply. In some incidents this is still a less than ideal position for an incident handler to be in: to not-know-what-they-don’t-yet-know about a piece of malware. It is at this point that a targeted and proportionate reverse engineering of the sample might help to reveal much of the required information.
Using clues such as those provided from basic static and dynamic analysis, alongside forensic findings and threat intelligence research, a malware analyst can start a targeted dissection of the sample and understand its true nature through reverse engineering. This specialized skill will often involve diving into the “disassembled” low level assembly language representation of the malware’s code. While a complete reverse engineering of every part of the sample might be time consuming and akin to a medical examiner performing a full autopsy, that may only be required when dealing with particularly sophisticated, well-protected and custom malware. Other times a targeted reverse engineering will suffice and can reveal vital functionality, configuration or characteristics that might otherwise have been missed, arming the incident handler with the most amount of information: Can the bird swim like a duck, quack, how often, and how loud.
Effective incident response often goes hand in hand with effective and proportionate malware analysis. Don’t get caught out trying to handle an incident without sufficient insight into malware, or jump to conclusions about what malware may or may not be doing. Make sure it truly does look like a duck, walk like a duck and quack like a duck.