Malware reverse engineering in a SOC
Before we dive deep into malware reverse engineering (MRE), it’s worth talking a little about the steps that precede it. There are a multitude of technologies that were designed to help detect malicious codes, such as antivirus tools, EDR systems, and various kinds of sandboxes. These all utilize static and dynamic analysis techniques to reveal what a certain code does, which helps decide if it is malware or it means no threat. These steps are repeated for each potential malicious incident with no exception, and are usually sufficient to detect and analyze malicious codes, understand what they do, and use the extracted information to plan the appropriate response activities.
However, sometimes the available and routinely used techniques and tools aren’t enough to make a verdict, at which point there’s a need for a more in-depth malware analysis. And this is when malware reverse engineering comes into the picture.
Malware analysis versus malware reverse engineering
Since malware analysis is usually done by malware reverse engineers, you might be tempted to think that malware analysis and malware reverse engineering are the same thing. But you would be wrong.
Malware analysis is usually meant to denote the process of running a suspicious code in a safe and isolated environment, such as a sandbox, and monitoring the behavior and outputs of the code. This is also known as ‘detonation’. In contrast, malware reverse engineering is the process of reviewing a code at the assembly level, then reading and analyzing it based on the performed assembly instructions. As you can see, the two techniques are quite similar in that they’re both aimed at analyzing a code to determine its intent, but there are significant differences in how they’re performed.
When automated processes just don’t cut it
In a security operation center, sometimes you have to understand and even override a verdict made by an automated malware analysis tool. An EDR system might report a piece of perfectly legitimate software, an e-mail might be marked as suspicious even thought it was sent by a trusted party, and a sandbox report might suggest that a certain file is malware, but provides no sufficient information on the infected endpoints or what to do as part of the remediation effort.
When automated processes turn out to be insufficient, malware reverse engineers can investigate the code to understand what it does, which helps properly estimate the risk associated with the given cybersecurity incident, or in other words, to determine the causality chain or infection chain. This is the kind of information that automated analysis tools cannot provide, even though it’s crucial to define the accurate incident response steps.
How can malware outsmart analysis tools?
With cybersecurity measures as sophisticated as antivirus tools or EDR systems at hand, you would be right to ask how some malicious software can deceive today’s state-of-the-art cybersecurity systems. Unfortunately, as we’ve said many times before, with the evolution of technology comes the evolution of cybercrime as well. A significant amount of new malware operates with evasive techniques, meaning there’s a new generation of malware that was designed to bypass automated analysis tools. Malware creators nowadays can even test the evasive techniques of their samples within the most popular publicly available automated sandbox tools.
Because of these increasingly-sophisticated malicious codes, it’s becoming increasingly important to properly investigate malware incidents rather than just block the malicious code, or to reveal why an automated tool made a decision before simply overriding it. There might be potentially inaccurate verdicts, and even legitimate programs might start acting suspiciously, so understanding what the code does is the only surefire way to identify which assets are infected and how to properly respond to the incident. Automated tools will always be a great first line of defense in a SOC, but there’s no doubt we can expect an increasing demand for malware reverse engineers going forward.
Malware reverse engineering as a service
Based on the above, it may seem like a no-brainer that organizations can easily solve their malware detection and analysis problems by building a malware engineering capability in their SOC. However, as do most things, recruiting an MRE poses some challenges. The most obvious obstacle is the general shortage of talented and skilled professionals in the area of cybersecurity, which is even more severe when it comes to a skill set as niche as malware reverse engineering. And even if you manage to find an available resource, there is such a small amount of truly skilled people in this field that recruiting and retaining these professionals feels like participating in an expensive, never-ending competition.
Luckily, a number of cybersecurity organizations have recognized this issue and come up with a solution: offering it as a service. In an MRE as a service model, the service should ideally be available at a high capacity, in an on-demand manner, even for ad-hoc cases. This would give the average SOC the possibility to ‘borrow’ resources when they encounter a tricky incident in the course of their business. However, if you look around the market, you can see that not many MRE as a service offerings possess these desired characteristics.
For this reason, and since we already had the required skill set within our organization, it made perfect sense to build this service within SOCWISE and offer it to our fellow SOCs and incident response teams. Let us give you a little peek behind the curtain and tell you about some of the features that let our customers truly benefit from our MRE as a service offering, such as scalability and on-demand accessibility.
MRE in SOCWISE
First, with the help of the Subscuto team, we built on our existing MRE capability to form the service. To ensure high capacity, we designed and developed a purpose-built malware analysis lab that incorporates our own hardware and even software components. Since the lab is deployed on SOCWISE premises, the samples that are analyzed are not shared with any additional third parties. When we receive a malware sample from our customers – which can be shared with us via any method that the customer prefers – it first lands in a so-called ‘malware triaging pipeline’, which performs several types of preprocessing activities to ensure optimal utilization of our resources. After that, it’s picked up by one of our experts who performs the reverse engineering analysis.
When the analysis is done, the outcome is a customizable report that’s optimized for incident management by default. It’s important to note that the report isn’t intended to be an in-depth, academic research type of analysis – its purpose is to give incident response teams clear information on the sample code so they can take speedy response measures such as containment, remediation, or even threat hunting. Nevertheless, our team can also support digital forensics, but that function belongs to a separate service umbrella.
Due to the nature of this service design, it can be easily integrated with existing SOC technologies and procedures, which even makes the proof of value processes simple. What we usually recommend is selecting a sample that you know very well, so when you receive the report, you can easily compare it with your expectations. Alternatively, you can also send us a sample that’s caused you trouble, because if we can find and give you the solution, that’s also a pretty good proof of value, isn’t it?
How to leverage MRE as a service in a SOC?
As we’ve already discussed, malware reverse engineering isn’t the same as malware analysis – it’s a separate process that should complement it. SOCs by all means should keep using their existing sandboxes, EDR systems, and local processes for static and dynamic analysis as a first line of defense. MRE only comes into the picture when a sample goes through all your automated processes and tools, but you still have doubts as to what the code does or what you should do to remediate the consequences of a malware incident. In addition, it can also help make sure that a decision made by a cybersecurity tool is in fact the right decision (aka verdict validation).
So, how does malware reverse engineering fit into the daily life of a security operation center? Let’s think back to the three layers of SOCs: people, process, and technology. Since the primary goal of MRE is to support incident detection and response, and it has a strong connection with threat intelligence and vulnerability management, it will mainly benefit those processes within a SOC. But of course there can be differences from service to service. For example, the report that we create as part of our MRE as a service focuses on supporting the response part, where you have to perform automated and manual containment, analysis, eradication, and remediation activities – all of which can be enhanced by malware reverse engineering.
Conclusion
First of all, there can be times when automated processes and common technologies such as EDR systems and antivirus tools just don’t cut it anymore. Sometimes they can let cybersecurity threats go undetected, or – on the contrary – mark trusted and legitimated resources as suspicious. As malicious codes become increasingly sophisticated, there’s an increasing need for cybersecurity professionals who can investigate codes on an assembly level.
However, no matter how badly SOCs need malware reverse engineering capabilities, implementing them in-house is difficult for several reasons. A great solution for this conundrum is getting malware reverse engineering as a service, where you can leverage the scalability and on-demand nature of the offering. And lastly and most importantly, malware reverse engineering should never replace traditional SOC processes, it should complete them. Your organization is still the safest when it’s guarded by proven, automated cybersecurity processes, expert systems, and machine learning capabilities. It’s only when there’s still uncertainty regarding a code even after the analysis was completed that malware reverse engineering should be applied. But in those cases, you shouldn’t hesitate for a second.
