It has been quite a while since we have done an update on published exploit code tracked in Cyentia’s Exploit Intelligence Service. The primary purpose of the feed is to identify and monitor exploit code being published, though as we will see in part 2 of this post, there are other interesting data points in the feed.
There are three primary (and recent) sources for exploit code: Metasploit, Exploit DB and GitHub. But the three sources are not created equal and each source has strengths and challenges. First of which is the amount of exploit code being published there. Over the last three and a half years, GitHub has been the place to quickly publish exploit code. Anyone can post, there are no quality checks (which is a strength according to the author and a challenge for any consumer), and sharing is instantaneous. This first figure shows the cumulative growth over the last few years.
Notice the plateau and bump in Exploit DB? I am not quite sure what was happening internally, but they had a slow down which appears to have created a backlog of exploits to publish and they eventually pushed a large batch over a few days in early April of this year. We also see some bumps in Metasploit publishing but I don’t have any theories as to why. Overall though, GitHub generally appears to be the place for exploit authors to push exploits.
How unique are the exploits in each of the sources? The next figure attempts to answer this question by showing the overlap between the three sources. There is obvious overlap between metasploit modules and GitHub, since every single CVE with a metasploit module also has exploit code on GitHub (it may be the module itself or a stand alone exploit – we are only correlating by CVE here). But don’t be fooled, the activity observed in recent EPSS research suggests that vulnerabilities with a metasploit module are far more likely to see exploitation activity in the wild than Exploit DB (the research did not compare against Github directly).
There are several reasons you may want to know about exploits being published. If you are prioritizing a list of vulnerabilities you may just want to know if any exploits have been published. Research we did with Kenna (P2P Vol1) found that vulnerabilities with published exploit code was 7 times more likely to have exploitation activity in the wild. Later research (P2P Vol7) found that vulnerabilities with published exploit code before the patch experienced a 15-fold increase in the amount of exploitation activity compared to other exploited vulnerabilities.
As a defender, perhaps knowing where to find exploit code could help you in any number of ways:
- Use the exploit code to detect and prove vulnerable instances exist in your environment
- Use the exploit code to write and test detection signatures
- Get the details on how the exploit works to develop work arounds and other defenses in case a patch isn’t available or cannot be applied yet
- Validate that a work around or applying a patch did in fact remediate the vulnerability
And I’m sure there are more reasons, but those are some of the front runners which with we are helping customers.
This is the first part of a two-part blog post, so stay tuned for the second half!
Leave a Reply
Want to join the discussion?Feel free to contribute!