Re: Bypassing AV for Java payloads

[Michael Schierl <schierlm () gmx de>]

Am 02.08.2014 um 07:12 schrieb HD Moore:
> There is no reason it cant - We even ship the JRE with the official
> installer, but so far nobody has built obfuscators for the java
> payloads. 

More precisely, nobody has tried to integrate obfuscators/crypters for
Java payloads into Metasploit. My JavaPayload repository contains (quite
simplistic) crypters for Jar and War files (both those generated by
Metasploit and by JavaPayload) for more than two years now, and despite
the fact that I never changed them in the last two years, obfuscating a
stock Metasploit JAR file [1] creates quite decent results [2].

[1]
https://www.virustotal.com/de/file/3ae5dbc2568e2705b57252213f83dc73ea36d8f4debba38767ac141857258f7b/analysis/1406990249/
[2]
https://www.virustotal.com/de/file/331b1bb0d9f43dd126b233cb8e0c75329a68676238df085727bd459ac05fe58d/analysis/1406993281/

And in fact, Kaspersky's heuristic detected the exploit only because
while I renamed the entry point servlet (metasploit.PayloadServlet) to a
random name, that random servlet contained the name of the original
servlet in a String constant which I forgot to obfuscate.


In other words: Metasploit (at least the free Framework) never tried to
obfuscate Java payloads, and therefore it is still quite easy to
obfuscate them manually. Even very simple file and class renaming
techniques (and encryption of metasploit.dat) are sufficient right now.
Of course, if you add these to Metasploit, the bad guys will pick them
up (according to HD Moore's law, at least) and they will quickly be
ineffective.

So while having obfuscators inside Metasploit Framework would of course
be nice, I think the better long-term investment (in case anyone wants
to) is a way to provide custom War and Jar files for all exploits (like
it is today possible with EXE::Custom) and/or provide a hook to call
external tools on the generated Jar/War files before using them. That
way, everybody can easily plug in his pre-generated War files or
obfuscators while still keeping the obfuscators themselves "out of
sight" (and in case Pro wants to ship extra obfuscators, they can do so
easily).

> If you do so without needing the JDK installed to rebuild
> each time, even better.

Hmm, are there any good Java bytecode parsing/generating libraries for
Ruby? If yes, somebody could port my crypters over to Ruby :)

And by the way, the standalone JavaPayload does not need the full JDK
(neither for payload generation nor for obfuscation), since it uses
ObjectWeb ASM library to dynamically rewrite the bytecode - and most
other obfuscators - like Proguard - follow a similar approach. So you
don't need the JDK anyway.

On the other hand, most MSD development environments don't include a JRE
at the moment (at least as far as I know) which was the main reason I
rewrote my Java payloads a few years ago for Metasploit to be "static"
and not requiring any JRE to be generated.


Just my 2 cents,

Michael
_______________________________________________
https://dev.metasploit.com/mailman/listinfo/framework