Black Hats are actively weaponizing unpatched servers affected by the newly identified “Log4Shell” vulnerability in Log4j to install cryptocurrency miners, Cobalt Strike, and recruit the devices into a botnet, even as telemetry signs point to exploitation of the flaw nine days before it even came to light.

Netlab, the networking security division of Chinese tech giant Qihoo 360, disclosed threats such as Mirai and Muhstik (aka Tsunami) are setting their sights on vulnerable systems to spread the infection and grow its computing power to orchestrate distributed denial-of-service (DDoS) attacks with the goal of overwhelming a target and rendering it unusable. Muhstik was previously spotted exploiting a critical security flaw in Atlassian Confluence (CVE-2021-26084, CVSS score: 9.8) earlier this September.

Recommendations

  • Get an overview of systems and software using log4j in your environment (this can be a time-consuming task, so better start early).
  • Apply the corresponding security patches for internet facing software / devices immediately
  • Apply the corresponding security patches for internal software / devices at your earliest convenience**
  • If patching is not possible for whatever reason, we strongly recommend isolating the system from the Internet and/or to apply the following mitigation measures:
    • For version >=2.10: set log4j2.formatMsgNoLookups to true
    • For releases from 2.0 to 2.10.0: you may want to remove the LDAP class from log4j completely by issuing the following command: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
    • For certain JVM Versions, it is possible to set com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase to false to mitigate the vulnerability. Some JVM versions already have this as default setting
  • You may check for exploitation attempts — no matter whether they were successful or not — in your web server logs using the following Linux/Unix command: sudo egrep -i -r ‘\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+’ /var/log/
  • Check your network perimeter logs for the presence of the list of indicators of compromise (IOCs) mentioned below:

nazi.uy # Mirai botnet C2

log.exposedbotnets.ru # Tsunami botnet C2

194.59.165.21:8080 # Tsunami botnet C2

195.133.40.15:25565 # Mirai botnet C2

185.154.53.140:80 # Kinsing botnet C2

138.197.206.223:80 # Kinsing payload delivery server

18.228.7.109:80 # Kinsing payload delivery server

82.118.18.201:80 # Kinsing payload delivery server

92.242.40.21:80 # Kinsing payload delivery server

185.191.32.198:80 # Kinsing payload delivery server

80.71.158.12:80 # Kinsing payload delivery server

185.191.32.198:80 # Kinsing payload delivery server

45.137.155.55:80 # Kinsing payload delivery server

185.191.32.198:80 # Kinsing payload delivery server

45.137.155.55:80 # Kinsing payload delivery server

62.210.130.250:80 # Mirai payload delivery server

http://210.141.105.67/wp-content/themes/twentythirteen/m8 # Kinsing payload URL

http://159.89.182.117/wp-content/themes/twentyseventeen/ldm # Kinsing payload URL

45.130.229.168:1389 # Rogue LDAP server

82.118.18.201:1534 # Rogue LDAP server

45.130.229.168:1389 # Rogue LDAP server

185.250.148.157:1389 # Rogue LDAP server

92.242.40.21:5557 # Rogue LDAP server

205.185.115.217:47324 # Rogue LDAP server

163.172.157.143:1389 # Rogue LDAP server

45.155.205.233:12344 # Rogue LDAP server

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.