• Analysis of a Real JBOSS Hack

    by  • November 5, 2011 • Uncategorized

    Summary

    This is an analysis of a recent attack observed on a on a large enterprise network. The attackers  compromised multiple servers via JBOSS JMX console vulnerabilities. With this access they were able to install tools for remote access and transmit data from the enterprise network to their C&C systems. The attack, while not sophisticated, demonstrates some of the techniques used by the hackers and burns their IP addresses that were used. We will discuss the attack and our methodology for the detection and response.


    From this timeline it can be seen that the attackers went after the load balancer virtual IP address and not the service directly. This meant that they would be sent to one of the two servers depending on the server load and algorithm used. Because server two was never fully compromised, we suspect that the attacker didn’t know they were dealing with two different servers and not just one.
     
    In any case, the attackers were able to get server one, deploy a rogue URL, push a remote shell and then drop Zmeu. Server two had its URL configuration updated, but because of complications getting files/executing commands, it appeared to keep trying to get the WAR/JAR from the remote server with no luck.

    Conclusions

    This attack was not sophisticated by any means and seemed to be more of a lucky strike than anything else, but as someone who looks at malware, I felt this was an important story to share. Often times we hear of attackers gaining access into networks, but we never see the write-ups of how it was done, what they took and what potentially motivated them. While we can’t be certain of what the attackers took, we do know how they got in which enabled us to fix the issue. 
    Using the write-up on JBOSS hacking mentioned earlier and our summary of this incident, changes were pushed on the servers to force authentication on all aspects of the JBOSS/Sun Server installation. This event also sparked administrators to pay closer attention to what sensitive data, if any, were left on the systems.

    Lastly, below are our thoughts on each of the used IP addresses used in the attack based on the information we saw:

    • 86.121.110.96 (Romania) – Main attacker address
    • 212.79.239.51 (Netherlands) – Attacker callback
    • 130.237.188.216 (Sweden) – Public IRC
    • 94.125.182.255 (Hungary) – Public IRC
    • 208.83.20.130 (Florida) – Public IRC
    • 212.170.156.148 (Spain) – Compromised server used to hold WAR/JAR files?
    • 212.170.149.56 (Spain) – Backup compromised server?
    • rocarp.com – Compromised server used to hold remote shell script