Log4j Scanning and Detection

Lately, everyone has been talking about Log4Shell (CVE-2021-44228) and likely, if you’re reading this, you’re looking for info for what to do. Most people attempted to utilize Huntress’s Log4Shell tool (https://log4shell.huntress.com/) to show connections to a LDAP server they were hosting. Some people had issues with this as it was overburdened with requests (rightfully so) or didn’t want to, or aren’t allowed to send outbound traffic to a server they didn’t own. At our organziation, we were part of the latter group. In order to comply with our rules, we needed to find a reliable way to scan our devices for the vulnerability and look for requests to a domain that we owned.

In order to know what to look for, you have to understand what happens with this vulnerability.

When the vulnerability is executed, the log4j module navigates to the address provided in the payload.

${jndi:ldap://log4shelltest.company.pvt:1389/somerndmstr}

In the above payload, the targeted host that recieves the data will attempt to resolve “log4shelltest.company.pvt” to make a connection. If you own the domain/subdomain you can track for DNS query logs for that domain.

In order to achieve this, we setup 2 DNS servers (internally and externally) and utilized nmap scripts found here. Scanning each host and sending the payload for our domain with a unique subdomain address, we were able to isolate the calling host to the query made to the server and could easily track down the offending host.

To prove the initial concept, we used a vulnerable application provided by the community. There are many like it but the one we used can be found here: https://github.com/kozmer/log4j-shell-poc

Good luck to all of you out there and hope this could be helpful to some.