So you found a vuln in that botnet code. Now what?

The awesome @SteveD3 on Twitter (you should be following this guy) asked a great question recently.

Question: If a botnet has vulns in its code, such as overflows or path manipulation... what could the good guys do w/ these flaws?

This is really thought provoking, and although I can probably answer this in 140 characters, the answer really does deserve a little more attention than that.

The short answer is "not much, at least not legally."  If you work for a government agency with special authorities, you are special.  Stop reading here as this doesn't apply to you.

If you don't work for a government agency, you could disclose this vulnerability (e.g. sell it) to a government agency and profit from your hard work (assuming they are willing to pay or haven't already found it themselves).  This might be of some use for the government agency obtaining data.  After all, there's no reason to exploit targets yourself if someone else already did the hard part for you (and then installed vulnerable malware).

If the vulnerability is on the command and control server, that likely belongs to a third party.  If you exploit it (even in the name of doing good) you're breaking the law.  If you find a DoS vulnerability in the C2 software and exploit it, you're still breaking the law.  This is true whether the attacker directly leased a VPS or compromised some poor website running Drupal (yeah, I'm kicking the slow kid here, but I can't help it).  In any case, you are exceeding your authorized access on the C2 server and that's a CFAA violation.

A SANS student posed a similar question to me a while back.  The question assumed that he found a vulnerability in botnet client code that would allow him to take control of infected nodes.  He hypothesized that even if taking control of the compromised machines was de facto illegal, nobody would care if he did it just to patch the machine itself and remove the malware.  But this brings up several important questions of its own, such as:

1. What if the system you patch is a honeypot that is being used to track commands sent from the C2 server? In this case, you've exceeded your authority and interfered with the collection operations of an organization, potentially causing material harm.
2. What if the system should not be patched due to third party software running on the machine? What if this is an industrial systems controller and patching causes physical harm?
3. What if everything should have worked, but something goes awry due to unforeseen circumstances (you know, because Windows).  What then?

There are just too many unknowns to really do anything meaningful with a vulnerability like this (at least while wearing a white hat and carrying liability insurance).  As we tell our clients at Rendition Infosec, the easiest way to avoid unforeseen consequences of hacking back is just not to engage in it in the first place.