One of my favorite features in Cobalt Strike is the system profiler. This web application digs deep into your browser to discover the client-side applications that I, as the attacker, can touch. To go along with the system profiler, I maintain a database that maps these applications to exploits in the Metasploit Framework. The system profiler uses this mapping to report client-side vulnerabilities. Are you with me so far? Good.
Mapping the information reported by the browser to exploits isn’t always trivial. Take the case of Internet Explorer. Internet Explorer reports the base installed version. This reported information does not change, even as you apply patches. I could simply punt and report any instance of Internet Explorer as vulnerable to everything, but this is part of the reason hackers hate automated tools. Instead, I try to be a little more intelligent about it. I painstakingly created a database to track the release dates of Windows Media Player and the JavaScript Engine that’s installed. I use these two hints to better map Internet Explorer to a ballpark date, that I then use to best estimate which vulnerabilities a visitor’s Internet Explorer is open to.
That’s a lot of intelligence in a simple system profiler. Now, on with the story:
In last week’s Cobalt Strike update, I opted to implement Cobalt Strike versions of the popular Java applet attacks. The open source versions of these attacks are burned by anti-virus, with no evasion options on the Java side. Reimplementing them is required to use them during a penetration test.
The dropper for Cobalt Strike’s Java Applets is pretty novel. I’m taking advantage of some JNI action to inject shellcode directly into memory.
Anyways, these new Java attacks led me to a neglected Cobalt Strike feature–the web drive-by exploit server. The original implementation was decent, but hard to maintain and update as more reliable exploits with broad coverage appeared.
I finally had the epiphany–wouldn’t it be cool if I could merge the intelligence of Cobalt Strike’s system profiler with the web drive-by exploit server?
So, I set into a marathon coding session to do just that. I now have the scariest weaponized browser fingerprinting kit on this side of the legal line.
A user visits the Cobalt Strike hosted web drive-by exploit server. The code at this point is the same as the system profiler. Cobalt Strike receives a profile and does all of its version heuristics and exploit mapping.
At this point, the web drive-by exploit server is able to cross-reference running exploits and the list of exploits that the system profiler believes are valid.
The last matter is to choose the best exploit from the resulting list.
Because I have a system profile, I’m able to do some very smart things. For example, two recent Metasploit Framework IE exploits depend on Java 1.6 to execute code on Windows 7 and Windows Vista. I’m able to use the information from the system profiler to eliminate these exploits from the running when necessary.
Once I apply several sanity checks, I arrive at a smaller list of exploits. I simply choose the exploit that has the highest reliability score I’ve assigned and that’s what Cobalt Strike serves.
Here’s a video of the web drive-by exploit server in action:
Pure pwnage.