So, just when you think hypes don’t affect you, a new hype gets your attention. Lately Java has hit the news as one of the latest risks and it’s pretty well abused for exploitation. Luckily we all know that exploiting “bugs” is not the only way to abuse Java. You can also abuse the trust Java places in digitally signed code, I’ve blogged about this issue before. Nowadays metasploit/SET even has a ready to use module for it. If you are wondering what all this has to do, with in-memory class loading…well sometimes when executing a java attack you want to make it harder for someone to detect your payload and you also want to leave less traces behind. In terms of Java I think that class loading is the thing that comes the closest to traditional in-memory execution. So let’s get started on making it harder for an investigator to investigate.
Here is the lay-out of what we will be doing:
1. Create a digitally signed Java class loader;
2. Create the Java payload we want to load in-memory and obfuscate it;
3. Test it.
4. Conclusion and References
The fun part about all this, is the fact, that is has been around as long as digitally signing code for Java has been around. A lot of Java software out there uses class loading as a means of extending itself (plugins and such) and/or adding dynamic code functionality.
You can find the article over here: