Build1 publisher2 min readPublished
Seven hundred client fingerprints cover React2Shell's 8,163 source addresses
GreyNoise's January tally of React2Shell traffic shows payload text mutating freely while the client tooling behind it stays nearly fixed. That decides what a perimeter rule should match on.
The Engineer · Build desk
What happened
- GreyNoise says its Observation Grid has recorded more than 8.1 million React2Shell attack sessions since disclosure, and each of those sessions delivered an exploit payload.
- Daily volume has settled into a band of 300,000 to 400,000 sessions after peaking above 430,000 in late December.
- The traffic now comes from 8,163 unique source addresses spread across 1,071 autonomous systems in 101 countries.
- A month earlier, on 8 December, GreyNoise counted 362 exploitation addresses, and only 152 of them sent payload data complete enough to analyse.
- GreyNoise tells organisations that have not yet patched to treat React2Shell as an active, ongoing campaign with no signs of abatement.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Most of the attacking addresses were unknown to GreyNoise before July 2025, so a blocklist compiled by hand goes stale between the pull request and the deploy.
- cost Anyone matching on request text is now maintaining rules against more than 70,000 payload variants, and every new variant is another rule someone has to write and keep.
- exposure More than a third of the exploitation traffic comes from AWS, so an ASN-level drop is unavailable to any service that also receives its legitimate traffic from those ranges.
- contradiction GreyNoise's early-December read called the attacking IP count steady and inconsistent with early Log4j exploitation; that comparison no longer sets the expectation for how this campaign scales.
Divide the sessions by the unique payloads and you get about 116 deliveries per variant [18]. Divide the source addresses by the HTTP client fingerprints and you get about twelve addresses per hash [19]. GreyNoise counts fingerprints in two layers: JA4H hashes the HTTP client and JA4T hashes the TCP stack, and it reports 700 of the first and 340 of the second [7]. Randomising payload strings is cheap. Swapping the HTTP client that carries them is a tooling change, and the hash counts say few operators have made one.
GreyNoise's 8 December accounting is worth reading next to the January numbers. Of the addresses it saw then, 210 connected with no payload data at all, sent malformed or empty payloads, or produced empty payload files [12]. Observed source infrastructure has since grown roughly 22-fold [20]. Exploitation of CVE-2025-55182 began rapidly after disclosure [16][17].
The technique catalogue is the actionable part. From 97 samples with live payloads, GreyNoise recorded arithmetic used to test command execution, `uname -a`, `whoami` and `hostname` for system details, reverse shells and downloaders, SSH key installation for persistence, remote script execution often PowerShell-encoded, `pwd` for directory reconnaissance, and both `sh` and `powershell` command forms [13]. Two of those leave durable traces on a host: an installed SSH key and an outbound fetch of a remote script. That analysis came from the 8 December sample.
The counts come from GreyNoise's own production and research sensors [22]. There is no victim count in the published data, no figure for successful execution, and no measure of how much of the routable address space those 8,163 addresses have swept. What the volume supports is narrow: an internet-facing endpoint running this software is being reached by indiscriminate traffic, and whether a particular host was reached is a question only that host's logs answer.
GreyNoise's own prescription is dynamic blocking from its continuously updated feeds, which the post calls the most effective perimeter control [8]. That is a vendor grading its own feed. The part that costs nothing is the supplemental data: complete ASN, JA4T and JA4H lists are published in GreyNoise's research repository on GitHub [10]. Matching on those hashes does not require the subscription.
What to watch
- Whether daily session volume breaks out of the 300,000 to 400,000 band or the source IP count keeps compounding at December's rate.
- A GreyNoise update pairing sensor sessions with confirmed compromises, which would settle whether unpatched hosts are actually being taken.
- New JA4H hashes appearing in the supplemental repository, which would mean operators are rotating client tooling and not just payload text.