On a recent customer visit, I asked the company’s Director of Security Operations how ReversingLabs came to be deployed as a part of their SOC tool set. The answer was quite interesting and one that I wanted to share with our blog readers.
The company (we’ll call them NA Bank for confidentiality) had Carbon Black deployed on their endpoints and by all measures the deployment was a great success. They had even utilized Carbon Black to uncover and thwart a recent series of targeted malware attacks on the company.
“Why do you think this was a targeted attack?”, I asked.
She responded that the files related to the attacks were never flagged by AV as malware, and that their file intelligence feeds showed no IOCs that matched what they were tracking. In her view, this was truly unknown malware.
My next logical question was how did Carbon Black detect the attack?
The Director explained that the Carbon Black Predictive Security Cloud and unfiltered approach to machine learning was the key. This technology had surfaced the anomalous behaviors (the behavioral IOCs) of the attack in its early stages even when traditional signatures had failed.
My next question was about the malware samples - if they had any idea what they were or had done any manual analysis.
The answer - she did not know at the time and found that it was very difficult to figure it out. “We isolated 5 files related to the attack”, she explained, “but none of the files were executables so we could not use our sandbox. That is when you folks (ReversingLabs) came into the picture.”
The security director explained to me that they had recently lost their two most experienced security analysts to a larger company and they were the only two who understood the process to reverse engineer the files (including the process of static analysis). Her next step was to reach out to a consulting firm and have them analyze the files.
That raised another question; since Carbon Black had picked up the IOCs and could stop the attack, why was it so important to identify the malware?
The answer was simple, “So that my team can make sure other payloads from these recent attacks or other future attacks that utilized the same or similar malware could be quickly identified. We don’t want to spend time investigating something we should already know”, the director explained. “Instead, when we identify the same or a similar attack in the future, we want to quickly execute a response playbook that stops the attack quickly and with minimal business disruption. That requirement also led us to ReversingLabs.”
“That makes sense”, I said. “So, what were the requirements that made ReversingLabs a good fit for this problem?”
She pulled out her requirements document and it had the following list:
- Analyze all types of files and not just executables
- Identify malware, malware families, malware techniques and malware code hidden in files
- Ease of use, a level 1 analyst must be able to operate the software and understand the output
- Integrate with Carbon Black
- Support YARA rule creation
YARA rules - that was refreshing to hear. “What was so important about YARA rules?”
The director explained that Carbon Black supports YARA rules and that if she can get a rule that defines the malware uncovered in the analysis, she can feed it back into Carbon Black and it will act like a signature, identify and alert on this malware if it is found again.
A quick note on YARA rules if you are not familiar with the standard. YARA rules are a way of identifying malware (actually any file) by defining certain characteristics of the file in the rule. It is a more flexible alternative to signatures and has the ability to describe patterns that identify not just a specific piece of malware but even detect entire malware families.
I then asked the SOC Director, “Can you walk me through the process of how Carbon Black and ReversingLabs work together in the NA Bank SOC?”
“Simple”, she replied. “Carbon Black detects a threat on the endpoint. For all the files related to the attack, hashes are sent from the CB Agent to the CB Response Server. Those hashes are passed on to ReversingLabs for evaluation. The first analysis is done in the CB Response UI using information from the ReversingLabs File Reputation Cloud. If the hash evaluation comes back as known malware, we kickoff the alert from CB Response and execute the appropriate playbook.”
“If the hash comes back as high-risk unknown or known and not detected by our AV, then our security analysts get the files involved and uploads them into the ReversingLabs A1000. The A1000 automates the reverse engineering and static analysis process so our analysts can quickly see what the malware is and how it operates. We use the YARA rules engine in the A1000 to write a YARA rule that defines the unknown malware, test the efficacy of the rule and then pass it into Carbon Black. Next time that malware shows up, Carbon Black will quickly identify it and we can contain it.”
“Pretty cool”, I said.
“Yeah, pretty cool indeed.” she agreed.
Learn more about ReversingLabs and Carbon Black integrations.
