Sensor Intel Series

Huge Increase in Scanning for CVE-2017-9841 With Large Variability in Scanning Infrastructure

The rather old CVE-2017-9841, an RCE in PHPUnit, suddenly jumps to the top of our list, with an increase of nearly 400% since last month. We dig into the scanning infrastructure.
July 25, 2024
7 min. read
Previous article in this series
Next article in this series

The Sensor Intel Series is created in partnership with Efflux, who maintains a globally distributed network of sensors from which we derive attack telemetry.

Additional insights and contributions provided by the F5 Threat Campaigns team.

Introduction

Welcome to the June 2024 installment of the Sensor Intelligence Series, our monthly summary of vulnerability intelligence based on distributed passive sensor data.

We observed a massive increase in scanning for CVE-2017-9841, continued increases in scanning for CVE-2023-1389, and scanning for a newly discovered PHP vulnerability – CVE-2024-4577.

CVE-2023-1389, an RCE vulnerability in TP-Link Archer AX21 consumer routers, continues to rise (up 33% from last month). This has been our top scanned vulnerability since March and would be on top again this month if CVE-2017-9841 figure had not suddenly leapt to the top spot.

CVE-2024-4577 is a newly discovered vulnerability in PHP when running on Windows using Apache and PHP-CGI.

CVE-2017-9841 is a very old vulnerability in PHPUnit, which we’ll look at in detail next.

CVE-2017-9841 Scanning Source Analysis

The massive increase in scanning this month for CVE-2017-9841 strikes us as very odd. Why would scanning for this 7-year-old vulnerability suddenly spike? It seems unlikely that there are a lot of vulnerable, unpatched instances of PHPUnit at this point, at least ones that haven’t already been compromised. It could be that someone has noticed a new product or piece of software includes a vulnerable version of this code, but we have found no evidence of this.

It is also possible, indeed even likely, that unpatched versions of PHP with this vulnerability can be compromised many times. The specifics of this vulnerability are quite simple – vulnerable versions will execute data provided to them in a POST requests so long as the data starts with ‘<?php’. Nothing about this would prevent multiple compromises, and this may, depending on the attacker’s agenda, be more than enough reason to target this vulnerability.

We dug into the sources of these scans and looked at what else they are targeting and found some interesting information.

First off all, scanning for this vulnerability has been present in our dataset from the very beginning of this project, all the way back in 2020. The following table shows the number of scans detected across our entire data set, by year.
 

Year n
2020 40609
2021 149650
2022 58500
2023 30382
Table 1: CVE-2017-9841 scanning by year, which peaked in 2021.

Scanning peaked in 2021 and decreased in 2022, but in just the first six months of 2024, this situation changed, with 100,607 events observed. Breaking this out by month shows very clearly the massive increase, and adding additional fields reveals some interesting patterns.

Month Unique Source IPs Unique Source ASNs Unique Source Countries Unique Headers Countries Targeted Total Events
January 2024 224 62 39 1 35 2148
February 2024 327 82 43 1 34 2555
March 2024 637 101 49 1 34 2397
April 2024 219 68 43 1 34 2320
May 2024 324 98 41 1 33 15254
June 2024 814 233 54 1 33 75933
Table 2: Breakdown of scanning sources for CVE-2017-9841, by source IP, source ASN, source country, unique headers observed, and countries targeted

Note the large increase in the number of unique source IPs and source ASNs. Between May and June, 38 different source ASNs dropped from the scanning activity, and 179 were added. This is unusual. While scanners will abandon infrastructure as takedowns happen, or access is revoked, they typically do not make such massive changes without need. We suspect that this is may be a case where the directors of this scanning activity have decided that they require far more resources and infrastructure than they have had before, and have further decided to diversify their sources. Why they would do this remains a mystery, but perhaps they are building in resiliency against actions against them.

It is interesting to note that most of the scanning infrastructure is in just a handful of countries – specifically the US (35 ASNs), China (20 ASNs), Russia (18 ASNs), Hong Kong (17 ASNs), Germany (14 ASNs), Vietnam (12 ASNs) and Singapore (11 ASNs). Of the remaining countries, 23 had ASN counts greater than one, and the rest of the countries, 19 in all, had just one ASN involved.

Nevertheless, the breadth of source ASNs is somewhat astonishing – many of the scanners we track have just a handful of ASNs in use, but this group has a large geographic distribution, with infrastructure in ASNs in Kazakhstan, Moldova, the Seychelles, and Cyprus, among others.

It is difficult to ascertain if this is all the activity of one actor or a group of unrelated ones. We surmise that given the consistency of the targeting (hitting only about half of the sensors we have deployed from a country-by-country basis), as well as the unusual consistency of only one set of headers that this is likely just one actor, but we can’t be 100% certain.

Looking at what this set of scanners is looking for, we find an emphasis on variations of the PHPUnit vulnerability. However, these scanners are also doing some other types of scans, specifically “credential finding” type scans, looking for unsecured “.env” files, git configuration directories, and exposed log files, although at drastically lower levels.
 

Targeted URL n
/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php 3078
/vendor/phpunit/phpunit/Util/PHP/eval-stdin.php 2182
/vendor/phpunit/src/Util/PHP/eval-stdin.php 2156
/vendor/phpunit/Util/PHP/eval-stdin.php 2131
/vendor/phpunit/phpunit/LICENSE/eval-stdin.php 2106
/vendor/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php 2104
/phpunit/phpunit/src/Util/PHP/eval-stdin.php 2084
/phpunit/phpunit/Util/PHP/eval-stdin.php 2072
/phpunit/src/Util/PHP/eval-stdin.php 2059
/phpunit/Util/PHP/eval-stdin.php 2056
/lib/phpunit/phpunit/src/Util/PHP/eval-stdin.php 2045
/lib/phpunit/phpunit/Util/PHP/eval-stdin.php 2038
/lib/phpunit/src/Util/PHP/eval-stdin.php 2030
/lib/phpunit/Util/PHP/eval-stdin.php 2019
/laravel/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php 2013
/lib/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php 2011
/www/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php 2003
Table 3: Top targeted URLs for scanners associated with CVE-2017-9841, primarily PHPUnit related.

We don’t currently understand the reasons behind the intensity of the scanning for this vulnerability, nor the dramatic increase in scanner infrastructure but clearly something is going on. We’ll keep digging into this and see what we can find for next month.

June Vulnerabilities by the Numbers

Figure 1 shows June attack traffic for the top ten CVEs that we track. Note the continued presence of CVE-2023-1389, but also the enormous amount of scanning for CVE-2017-9841, continuing a rise that’s been increasing, albeit slowly, since March 2024.

Top 10 CVEs for Ports 80/443, June 2024
Figure 1. Top ten vulnerabilities by traffic volume in June 2024. CVE-2017-9841 is obviously dominant, but CVE-2023-1389 continues to be heavily present. Note also the new top entry of CVE-2022-47945, and the introduction of CVE-2024-4577.

We also note the appearance of a very recent PHP vulnerability, CVE-2024-4577. This is a vulnerability that allows both disclosure of source code and remote code execution on vulnerable versions of PHP running on Windows operating systems using Apache and PHP-CGI. This was announced by Orange Tsai on Friday, June 7th, 2024,1 and we first saw it show up in our scanning logs on the very same day, at 20:10:35 GMT.

Other changes to the top ten include the decline in scanning for CVE-2019-9082, as well as the appearance of CVE-2022-47945 in our top ten. This vulnerability, a ThinkPHP Framework local file inclusion bug, has been in our logs for a long time, but has experienced significant growth in the last month.

Figure 2 is a bump plot showing the change in traffic volume and position over the last twelve months. This shows very clearly the massive increase in scanning for CVE-2017-9841. Also notable is the continued increase in scanning for CVE-2023-1389, with its total volume (seen in the width of the colored area) indicating that more scanning for this occurred last month than at any time in the previous eleven months.

Figure 2. Evolution of vulnerability targeting in the last twelve months. Note the huge increase in scanning for CVE-2017-9841.

Figure 2. Evolution of vulnerability targeting in the last twelve months. Note the huge increase in scanning for CVE-2017-9841.

Figure 3 shows traffic for the top 19 CVEs by all-time traffic, followed by a monthly average of the remaining CVEs. This once again shows the dramatic increase in CVE-2017-9841, as well as the movement of CVE-2023-1389, along with modest increases in CVE-2019-9082, and CVE-2022-47945.

Figure 3. Traffic volume by vulnerability. This view accentuates the recent changes in both CVE-2023-1389 and CVE-2017-9841.

Figure 3. Traffic volume by vulnerability. This view accentuates the recent changes in both CVE-2023-1389 and CVE-2017-9841.

Conclusions

Despite the oddities of this month, we continue to see an intense focus on the compromise of IoT devices, with the goal of assembling massive global botnets. As we have said many times before, IoT is a favorite target of attackers, as they are frequently forgotten, unpatched, and easily accessible. They provide deniable infrastructure for further activities, and frequently (especially in the case of consumer routers) on residential networks, a boon when operating against companies or government organizations which must provide access to their customers.

We’ll also suggest that the presence of CVE-2024-4577 reminds us that a serious vulnerability in any software package can be found at any time, and monitoring, patching, and mitigating such vulnerabilities is a continuous process.

We hope you enjoyed this deep dive into a single instance of scanning activity, and we’ll see you next month!

Previous article in this series
Next article in this series

Recommendations

Technical
Preventative
  • Scan your environment for vulnerabilities aggressively.
  • Patch high-priority vulnerabilities (defined however suits you) as soon as feasible.
  • Engage a DDoS mitigation service to prevent the impact of DDoS on your organization.
Technical
Detective
  • Use a WAF or similar tool to detect and stop web exploits.
  • Monitor anomalous outbound traffic to detect devices in your environment that are participating in DDoS attacks.
Authors & Contributors
Malcolm Heath (Author)
Principal Threat Researcher
Footnotes

1https://blog.orange.tw/2024/06/cve-2024-4577-yet-another-php-rce.html

Read More from F5 Labs

2024 DDoS Attack Trends
2024 DDoS Attack Trends
07/16/2024 report 30 min. read
Scanning For Credentials, and BotPoke Changes IPs Again
Scanning For Credentials, and BotPoke Changes IPs Again
12/09/2024 article 4 min. read
2025 Cybersecurity Predictions
2025 Cybersecurity Predictions
12/17/2024 article 14 min. read