Version v.002

lecture: Predictive CVE Hunting


Small teams of researchers don’t always have the resources to find, tag, and bag new zero-day malware. However, there are numerous Antivirus companies out there performing this same activity day in and day out. In this talk, you will learn a technique and a process for piggy-backing on the wide net that AV companies cast. This is not a method for finding zero-day samples, but it is a method for finding one-day samples very near to the moment they appear in the wild.

Hunting for new and unique malware can be a difficult process for a small team of threat intelligence researchers. At the SANS CTI Summit 2016, Rich Barger and I presented a process that can be used to make a team’s YARA hunting process more efficient and fruitful. Building off the concepts that we presented then, in this talk you will learn how to apply that process to predictively hunt for one-day malware.

1. Introduction
1. Who are we?
1. Malware Utkonos and the new intern!
1. What is predictive CVE hunting?
1. Using our YARA hunting process to watch for files that match signatures deployed before a CVE has been exploited in the wild
2. Basically sitting and waiting in advance with signatures ready to catch files that don’t exist yet
3. Who is NVD (NIST)?
4. What is the CVE system?
5. What role does US-CERT play in this process?
1. What is the YARA hunting process?
1. Hunting process can be applied to any signature management system, but our model organism was YARA at VirusTotal.
2. Key concepts
1. Signature prioritization
2. Signature revision control
3. Automation of
1. Notifications
2. File collection/download
3. Sandboxing
4. Notification and Sandbox output parsing
1. YARA Hunting Process
1. Components
1. Signature mgmt
1. Revision control
1. What benefits does this have over not using it.
1. Visibility into who made changes and when
1. This allows a team to scale
1. Automate building of signature lists based on purpose
1. This removes the human error factor - people will always make mistakes and typos
1. VTMIS Notification mgmt
1. All notifications are recorded in one place
2. No email needed
1. Notification prioritization
1. Signatures used to generate notifications given weights
1. Priority
1. Based on business need (stage of sales process, is there an active evaluation, is the non-customer focused sig currently valuable)
1. Confidence
1. Based on signature author’s (analyst) knowledge (is the sig noisy, how many false positives)
1. Sandbox integration
1. Sandbox sessions are a limited resource
2. Leverage sandbox API
3. Maximize available resources
1. Sandbox analysis results automation
1. Data points from structured output uploaded to TIP automatically
1. Goal
1. Analyst spending time on analysis
1. Our model analyst recovered 300 hours that
1. Increased intel production
1. he was able to reclaim to increase weekly intelligence output by two incidents
1. Predictive CVE Hunting Process
1. Building on the YARA hunting process
1. Each week NVD (NIST) and US-CERT publish newly disclosed vulnerabilities and descriptions
2. Each week we create a new set of YARA rules based on the CVE numbers with names and descriptions to match up with what US-CERT publishes
1. The YARA rules are looking for CVE numbers in two locations
1. AV scanner results
2. VirusTotal tags
1. Not all vulnerabilities are important to us. We’re targeting the vulnerabilities that are most likely to be exploited and therefore weaponized in malware.
1. Vulnerabilities we’re looking for
1. Browser vulns
2. OS vulns
1. Privilege escalation
2. Arbitrary code execution (especially remote)
1. Java
2. Flash
3. PDF
4. Office Document
5. Mobile (Android and iOS only)
1. According to the YARA hunting process, we assign each signature a priority and confidence.
1. Once a rule begins to hit, we adjust the confidence, but initially we set it to High
1. Triage process when a hit arrives
1. All new hits have automatically been sent to the sandbox for analysis
2. Before adding the sample to the reverse engineer’s queue, do a sanity check to see if it’s a false positive
3. If it’s not an obvious false positive
1. Immediately share any network indicators gleaned from dynamic analysis and static analysis
2. Begin the reverse engineering process
3. Write an analysis of the indicators, malware, and any other interesting intel discovered during this process
1. Predictive CVE Hunting in Action
1. Near misses
1. CVE-2015-0336
1. Arbitrary code execution in Adobe Flash
2. This vuln began being exploited in the wild by Nuclear EK on 3/19/2015
3. Why did we miss it?
1. At that time, the YARA rule template was only looking for CVE numbers in AV scanner results.
2. A researcher, Kaffeine, found the first samples, uploaded them, and tagged them as CVE-2015-0336 thus bypassing our rules.
3. This helped us correct the way that we were hunting
1. CVE-2016-1019
1. Arbitrary code execution in Adobe Flash
2. This vuln began being exploited in the wild around April 2nd and was used to spread Cerber ransomware.
3. Why did we miss it?
1. New intern was only just getting trained up.
2. We went backwards in time and deployed all the missing YARA signatures
3. This one hit immediately, but it had been in the wild for about a week already.
1. Hits and their production
1. We have had a set of hits:
1. CVE-2015-1641
2. CVE-2015-5122
3. CVE-2015-5119
1. What do you do after you have a hit?
1. Bump down the priority
2. Adjust the confidence
3. Begin building a more robust YARA rule
4. Deploy rule to regular hunting process
5. Build a repository of samples categorized by CVE
1. Conclusion
1. The YARA hunting process can be used to make a threat hunting group more efficient.
2. It allows the analysts to spend the most time on the part of the process that is the most important: the analysis
3. We have taken the established hunting process and used it to target one-day malware that is newly being found in the wild.
4. The exhaust from this process is a set of malware samples categorized by CVE which can then be matched up with a risk profile and appropriate security controls can be implemented to combat these known samples and potential future weaponization of an exploit targeting the same vulnerability.


Day: 2016-09-09
Start time: 18:30
Duration: 01:00
Room: Tesla



Click here to let us know how you liked this event.

Concurrent events