Re: Bypassing AV for Java payloads

["HD Moore" <x () hdm io>]

Thanks Michael!

It looks like framework uses the metasploit-javapayload repository, which has support for Android, but may be missing 
some of the code written between 10-12 months ago in your repository.

The obfuscator approach looks reasonable (and definitely effective) and there really is no reason we shouldn't try to 
build them into the Java exploit modules through a mixin that falls back to static files when java is not present.

The lack of a JDK dependency also makes things much easier (asm.jar, etc).

Overall, it looks like this would add +3Mb or so to the final distribution, which is pretty minor all things considered.

It looks like between yourself, @timwr, and @todb, we should get a handle on where metasploit-javapayload is relative 
to your repository, scope out the work to implement this, and find some volunteers (count me if needed) to actually go 
make the changes.

-HD

> -----Original Message-----
> From: framework [mailto:framework-bounces () spool metasploit com] On
> Behalf Of Michael Schierl
> Sent: Saturday, August 2, 2014 1:08 PM
> To: framework () spool metasploit com
> Subject: Re: [framework] Bypassing AV for Java payloads
>
> 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/3ae5dbc2568e2705b57252213f83dc73ea36
> d8f4debba38767ac141857258f7b/analysis/1406990249/
> [2]
> https://www.virustotal.com/de/file/331b1bb0d9f43dd126b233cb8e0c75329a68
> 676238df085727bd459ac05fe58d/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

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