Skip to content
Block-Continue
Go back

The Midnight Beachhead: A Real-World RCE Incident on a University Network

Shortly after midnight on April 29th, an attacker exploited a known vulnerability in a web-facing server at one of our international campus locations. What followed was a textbook post-exploitation sequence: foothold, C2 establishment, internal reconnaissance. The attacker had a stable beachhead before most of campus was awake.

The Initial Breach

The exploit used was CVE-2025-55182, a React2Shell vulnerability targeting misconfigured or unpatched React-based applications. It allows an attacker to achieve remote code execution (full control of the server process) through a crafted request.

What gave it away was SSL decryption. Because TLS inspection was enabled on that segment, the IDS console caught something that would have been invisible otherwise: the attacker sending a classic RCE verification command, echo $((41*271)), to confirm the exploit had landed. It is the digital equivalent of knocking on a door to see if anyone answers. Someone answered.

The attacker was operating from 45.135.193.131, a known malicious drop-site with a documented history in public threat intelligence.

Establishing Command and Control

Within 30 minutes of the initial breach, the server was already phoning home. The attacker’s first move was to bypass internal DNS infrastructure entirely, reaching out to Cloudflare’s resolvers directly. This is a deliberate evasion technique designed to avoid DNS-based logging and detection.

A steady heartbeat connection was established to 135.232.92.137, checking in on a regular interval. By mid-morning a second persistent C2 channel had been established to 45.146.81.216, a server hosted in Russia. The network analysis tool flagged this connection as anomalous. The traffic pattern did not match standard web browsing or anything else that belonged there. Dual C2 channels running simultaneously is not an accident. It is redundancy.

Internal Probing

Once the attacker had a stable foothold, they shifted focus inward. Starting in the early morning hours, the compromised server began probing a second internal host on port 38881, exactly every 30 minutes. That kind of regularity does not happen by accident. A scheduled task, installed by the attacker, running on a fixed interval for either lateral movement or data staging.

The secondary target was 172.16.10.250. It was being probed from inside the network, from a server that had its own legitimate role on the campus, which is what makes lateral movement from a compromised internal host more dangerous than an inbound scan from outside. It already had trust.

Why This Matters

Two things worth pulling out of this incident.

SSL decryption is what made this visible. The RCE verification command, the C2 traffic, the internal probing. All of it was inside encrypted sessions. Without TLS inspection on that segment, the behavioral indicators would still have been present, but the confirming detail (the actual command the attacker ran) would not have been. Decryption has operational costs and privacy tradeoffs worth thinking through. In this case it paid off.

Behavioral detection caught what signatures missed. The 30-minute internal probe interval, the direct DNS bypass, the anomaly flag on the Russian C2 connection. None of these are signature matches. They are behavioral anomalies. Without network flow analysis and anomaly-based detection, this attacker had a long runway.

IOCs

IndicatorTypeRole
45.135.193.131IPAttacker origin / exploit source
135.232.92.137IPC2 heartbeat
45.146.81.216IPPersistent C2 (Russia)
CVE-2025-55182CVEReact2Shell RCE exploit
Port 38881PortInternal probe target

Internal infrastructure details have been omitted. IOCs are published to support the broader security community.


Share this post on:

Previous Post
The Canvas Breach and What It Tells Us About Vendor Risk in Education
Next Post
Sinkhole, Bursts, and a 142-Minute Retry Timer: Reading C2 Behavior in the Logs