Sometimes the best measure of how you perform a given task is less about what you do, and more about what you decide not to do. This extends to data-oriented cyber security analysis, and how to manage the infinite-sized volumes of threat intelligence that are now available for SOC hunt teams. The ability to properly select what is needed, and to avoid what is not relevant, is an essential skill for modern threat hunters.
Solutions from ReversingLabs were created to assist the hunter with the correct types of intelligence to locate advanced malware with focus on undetected malware. To enable these threat hunters, ReversingLabs provides a rich tools and services that include automated file decomposition and static analysis, integrated YARA rules for hunting, contextual pivoting, retro-search, high volume file classification, and integrated file reputation services.
We recently asked Mario Vuksan, CEO of ReversingLabs to share with us how his company is developing a platform based on these next-generation methods. We also wanted to learn how ReversingLabs customers, who work in enterprise security operational settings, performing threat hunting tasks and dealing with intelligence, are putting these capabilities to use in their day-to-day work dealing with advanced adversaries.
EA: Mario, I know you have strong opinions about how threat intelligence should be implemented and shared. Can you share?
Mario: Let's start with the sharing portion of the question. We advocate that organizations should not be pushing as much intelligence data as possible to their internal security teams, as well as friends and partners. We also do not believe that organizations should be trying to grab as much intelligence data as possible from all commercial and free partner sources, because that generates unnecessary work. We advocate instead a pull-method where the incident response teams look at investigations to make sense of them and convert them into rules – something like Yara rules. Specifically-defined threat intelligence converted to actionable data like Yara rules can then be shared across security teams and with partners who then can look through their repositories to find the matches and activate responses. Partners can run the results through their legal teams and then share them back.
EA: ReversingLabs talks about the difference between global and local threat intelligence, can you expand on this theme?
Mario: We want to make sure people focus on the data that they really have. We see many organizations using outside vendors to collect as much intelligence data as possible, much of which is not relevant to their local environment. Today, everyone is focused on SIEM and pushing more log-based data into solutions like Splunk, Elastic Search, or Hadoop. That's all interesting, but it's not complete, because most producers of logs tend to filter out relevant data. Examples include sandboxing solutions that filter things they cannot process, and endpoint solutions that focus on things running in the memory. They do not look at all the other data that is available to them. ReversingLabs’ believes that local threat intelligence is absolutely necessary if you are going to look for things unknown, like zero-day artifacts. Local threat intelligence is important if you are going to successfully find threats that are in the early stages of the kill chain.
EA: You emphasize file intelligence as a subset of threat intelligence when talking about threat context. Can you explain?
Mario: Absolutely. We see too little focus on files, objects, and transactions. That is not surprising, because it is hard to process millions of objects a day to derive context. So, it is normally not done. However, as we move into the cloud, network context becomes muddy. Knowledge about what really flows through network sessions, what's packed into emails, or what’s shared through endpoint sessions, becomes more important, and also more difficult to see. We advocate a single infrastructure for pretty much everything an organization sees from Windows, Linux, MAC OS, and mobile, to anything that can be emailed or found on an endpoint. This file-level visibility is the only way that security teams are going to truly understand what threats are entering or are inside their network. This also becomes an important stepping-stone toward inspecting commercial applications and understanding transaction-based payloads, which these days are more like self-contained operating systems. This includes SAP and Swift, as well as Union Pay, Allpay, and Wepay.
EA: Would this type of defense have prevented the damage NotPetya achieved?
Mario: What is interesting about NotPetya is the initial vector. It was emailed with a trusted updater for Ukrainian auditing software which it could control. It wasn’t something that could be dynamically detonated. Using static file analysis technology developed by ReversingLabs, we can analyze any type of object to determine whether it is good or bad. We also provide rich static behavior reports on that object without detonation. This information would have allowed security analysts to determine the identity of the attack (NotPetya versus Petya) and to provide the information so that they could have taken much faster action to contain the attack. This illustrates the need for an effective local intelligence repository, where you store all possible evidence. You can then down-sample with the help of global intelligence. Our research team could quickly down-sample to the actual attacker components that were part of the NotPetya. In the early days of the attack, organizations were subject to a large deception campaign. They were dealing with about half a million decoy components. We found and shared the 18 real components of the attack that were essential to be able to produce appropriate protective measures.
EA: Did your team do analysis on the recent Shadowhammer attack?
Mario: Yes, we investigated the that attack in great detail. As you know, Operation Shadowhammer was discovered by Kaspersky researchers. It worked by distributing malware using the ASUS live update utility, which is pre-installed on most of their computers for software driver and BIOS/UEFI code updates. We did our research using the infected installation package that Kaspersky made available. The main executable, Setup.exe, carried the malware payload, but we wanted to see if additional samples might be worth examining. So, we used our functional similarity algorithm to find ten additional pieces of code worth reviewing. We then performed file decomposition using our TitaniumCore engine and we found a variant of Shadowhammer in the extracted files. We did more analysis of file path and determined that this was the original code the adversaries had intended to use for the attack.
EA: How does your platform integrate into existing SOC environments and with third-party security tools?
Mario: Our integration includes network forensics, email, EDR, and storage (like S3) whether local or cloud-based, or whether a commercial application is emitting transactions that need to be inspected. These are the starting points for scalable, in-depth file inspection. The primary benefit of ReversingLabs is to give organizations tens of thousands of indicators organized around a unified database schema that enables advanced search and hunting. On the other hand, ReversingLabs can integrate with a slew of security technologies like Sandbox for additional context, SOAR for orchestration, SIEM for alerting, and analytics solutions for hunting.
EA: What are some hunt-related trends you’re seeing in your customer base?
Mario: One trend involves analyzing components that cannot be detonated such as third-party updaters. As we already discussed, NotPetya's initial vector was not a document lure or an exploit, but a trusted third party software updater. Similarly, detonation was not helpful when analyzing proof-of-concept Spectre and Meltdown samples. Our customers are increasingly crafting complex rules, as can be expressed with YARA, to look for zero-day malware, activities of various APT groups, and to search for exfiltrated or sensitive data. For most global organizations, text search is really a binary problem as they operate in areas that do not run on western alphabets. Finally, only with binary search of richly extracted indicators, can one start discovering new document malformation techniques that are still a quintessential part of all phishing campaigns.