React2Shell payloads: what the scan noise says about attacker tradecraft

TL;DR: The React2Shell campaign has driven more than 50,000 unique payloads over roughly 1.5 weeks, according to GreyNoise, with most probes clustered in 200 to 500 bytes and a smaller set of heavier scripts aimed at monetization, persistence and concealment. The pattern points to industrialized exploitation with automated scanners doing most of the work and only a few outliers showing more complex tradecraft.

Editorial analysis by NHI Mgmt Group, based on content published by GreyNoise: “There's Payloads, And Then There's pAIloads: A Look At Selected Opportunistic (And Possibly AI-"Enhanced") React2Shell Probes and Attacks”.

Key questions

Q: What breaks when exploit traffic becomes mostly automated noise?

A: Triage breaks first, because analysts cannot treat every request as a distinct case when payloads are templated and repeated at scale.

Q: Why do repeated exploit attempts create more risk than a single flashy payload?

A: Repeated attempts expand the chance of a timing mismatch between exposure and patching, especially when defenders are still validating scope or building a fix.

Q: How can security teams tell scanning noise from a real post-exploitation attempt?

A: Look for behavioural differences after delivery.

Practitioner guidance

• Cluster exploit telemetry by payload shape Group React2Shell attempts by byte size, command structure and repeated strings so automated noise can be separated from outlier payloads that merit deeper analysis.
• Block known malicious sources at the edge Use network and WAF controls to stop repeat exploitation attempts before they reach application runtimes, and refresh the blocklist as the campaign evolves.
• Map exposed runtimes to their secret and identity dependencies Inventory which internet-facing services can touch service accounts, tokens, certificates or deployment credentials so a web exploit does not become a privilege bridge.

Bottom line: React2Shell is a scale problem as much as a vulnerability problem, because the campaign is dominated by repeated automated probes rather than bespoke operator activity.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →