Overview

On September 28, 2026, AhnLab's Security Intelligence Center published two incident cases that share one entry point: an Internet-facing Microsoft IIS server running an unpatched copy of Telerik UI for ASP.NET AJAX. In both, the attacker exploited CVE-2019-18935, a .NET deserialization vulnerability in the RadAsyncUpload file-upload control, to get code running inside the IIS worker process w3wp.exe.

From that identical foothold the two cases diverge in a way worth paying attention to, because it says something about who is buying access to this class of target.

In the first case the operator went for persistence and depth: a raw socket reverse shell to 206.82.6.22 on port 80, system reconnaissance, privilege escalation from the application-pool identity to SYSTEM using Potato-family token theft, and finally a Godzilla-style in-memory web shell loaded from godmemshell.dll directly into the ASP.NET runtime. No .aspx file was written. There is nothing in the web root to find.

In the second case the operator went for breadth and did something almost banal with a SYSTEM-level foothold on a corporate web server: dropped a Rust-compiled scanner, pulled a target list over cleartext HTTP from port 31337, and went hunting for half-installed WordPress sites -- specifically for /wp-admin/setup-config.php and /wp-admin/install.php, the two paths that are reachable when a WordPress installation has been unpacked but never finished. Results went out to a Telegram bot as an attachment named red.txt.

The second case is the more instructive one. A compromised enterprise IIS server was used as nothing more than scanning infrastructure to find other people's unfinished WordPress installs. That is the economics of this vulnerability class in 2026: the access is cheap enough, and plentiful enough, to spend on low-value work.

Background: Two Generations of the Same Control

RadAsyncUpload has now produced two distinct, independently exploitable vulnerability generations. Getting these straight is the first triage step on any hit, because the patch levels that fix them are six years apart.

Generation 1: CVE-2019-18935 (the one being exploited now)

RadAsyncUpload accepts an encrypted configuration object from the client describing where an upload should land. The control deserializes that object without restricting the types it will instantiate. An attacker who can produce a validly encrypted Telerik.Web.UI.AsyncUploadConfiguration blob can therefore write a file to a directory of their choosing and then trigger deserialization of Telerik.Web.UI.AsyncUploadResult such that the uploaded mixed-mode assembly is loaded into the worker process.

The historical gate was the encryption key. It was hardcoded in older builds, and where it was not, it was frequently recoverable through CVE-2017-11317 or CVE-2017-11357. CISA and the FBI documented exactly this chain being used against a U.S. federal civilian agency's IIS server in advisory AA23-074A, published March 2023, where two separate actors -- one of them tracked as XE Group -- exploited the same unpatched instance months apart.

Fixed in 2020.1.114 and later. Still unpatched in the wild, six and a half years after the fix shipped, which is the entire reason AhnLab had two cases to write up.

Generation 2: the July 2026 chain (probably not what you are seeing)

Independently, TantoSec researchers Marcio Almeida and Justin Steven reported a new cluster on May 22, 2026, with a separate RadPersistenceManager / RadDockLayout chain credited to CODE WHITE's Markus Wulftange working with Progress Software. Progress fixed them on July 8, 2026 and the CVEs published July 22:

• CVE-2026-13181 -- unguarded type resolution (CVSS 8.1), the deserialization sink
• CVE-2026-13182 -- padding oracle
• CVE-2026-13183 -- timing-based oracle variant
• CVE-2026-13184 -- predictable default key
• CVE-2026-13185, -13186, -13190 -- the separate RadPersistenceManager / RadDockLayout chains
• CVE-2026-6023 -- deserialization of untrusted data, per Progress's own bulletin

The interesting property of this generation is that it removes the key requirement entirely. RadAsyncUpload encrypts its configuration with AES-CBC and performs no integrity check, so the server's differing responses to valid and invalid padding form an oracle. An attacker iterates, forges a valid encrypted configuration without ever knowing the key, and reaches the same unguarded type-resolution sink. Affected versions run from 2010.1.309 through 2026.2.519; the fix is 2026.2.708 (2026 Q2 SP1).

A public exploit was released on September 7, 2026. As of that date there were no confirmed reports of in-the-wild exploitation of the 2026 flaws, though at least one vendor reported tracking scanning activity against the endpoint.

Why this distinction changes your detection posture: Generation 1 is a small number of precisely crafted requests. Generation 2 is a brute force -- hundreds to thousands of requests to the same endpoint differing only in ciphertext, each provoking an error response. One is a signature problem; the other is a volumetric problem. A rule built for either one alone will miss the other.

Threat Actor Profile

AhnLab attributes neither case to a named actor, and neither do we. The available signal is thin but not uninformative.

No attribution, by design or by absence. ASEC's write-up is an incident-response artifact, not an attribution paper. There is no tradecraft overlap claimed with XE Group or the second actor from AA23-074A, despite the shared CVE.

Tooling is commodity. Godzilla is a publicly available Chinese-language web shell framework. SweetPotato, PrintSpoofer and the wider Potato family are public offensive-security tools. Telegram bot exfiltration is the default choice for operators who do not want to run infrastructure. Nothing in the toolkit requires development capability.

One custom component. The WordPress scanner is Rust-compiled and purpose-built, with an embedded list of 53 candidate paths and a config-driven target queue. Somebody wrote that, which puts this a notch above pure script-kiddie work and suggests a repeatable operation rather than a one-off.

The objective argues for commodity crime. Hunting mid-setup WordPress installs is a site-takeover play: an attacker who reaches setup-config.php on an unfinished install can point it at a database they control and own the resulting site outright. It is a volume business. Layered against a SYSTEM-level foothold on an enterprise IIS server, the mismatch is stark -- and the most economical reading is that the Telerik access and the WordPress hunting are separate lines of business for the same operator, or that the access was resold.

Attack Chain: Stage by Stage

Stage 1 -- Initial Access: RadAsyncUpload Deserialization

The attacker POSTs to Telerik.Web.UI.WebResource.axd?type=rau, supplying rauPostData containing an encrypted AsyncUploadConfiguration with attacker-chosen TargetFolder and TempTargetFolder values, plus the payload assembly as multipart content. A second request triggers deserialization of the upload result, and the mixed-mode DLL is loaded by w3wp.exe.

The consequence that shapes everything downstream: execution begins inside the IIS worker process. Every child process inherits the application-pool identity (IIS APPPOOL\<poolname>, or a service account where the pool was configured with one). There is no interactive logon, no explorer.exe ancestry, no user session. Detection logic keyed to user-context anomalies sees nothing here.

Stage 2 -- Case 1: Socket Reverse Shell

The loaded assembly creates a Windows socket and opens a TCP connection to 206.82.6.22:80. Port 80 is not incidental; outbound HTTP is the one egress path a web server almost always has. The channel is raw TCP rather than HTTP, so an inline proxy expecting well-formed HTTP on port 80 may log the session as malformed or not log it usefully at all.

Through that channel the operator spawns cmd.exe and runs reconnaissance.

Stage 3 -- Case 1: Privilege Escalation via Token Theft

The application-pool identity is deliberately low-privileged, so the operator escalates with Potato-family tooling. ASEC specifically names SweetPotato, "modified for use in a web shell environment," and PrintSpoofer.

The family works by abusing the SeImpersonatePrivilege that service accounts -- including IIS application pools -- hold by default. The tool coerces a privileged system component into authenticating to a local listener the attacker controls, captures the resulting token, and impersonates it. PrintSpoofer does this through the Print Spooler's named pipe (\pipe\spoolss); other family members use DCOM or the EFS RPC interface. The result is SYSTEM.

The "modified for use in a web shell environment" detail is the part worth flagging: the operator adapted a public tool to run inside a constrained web-shell execution context rather than as a standalone binary. That is a small piece of real work, and it is the kind of modification that defeats hash-based detection while leaving behavioral detection fully intact.

Stage 4 -- Case 1: Godzilla In-Memory Web Shell

Persistence is the part defenders should study. The loader loads an embedded godmemshell.dll into the ASP.NET runtime's memory and registers it as a request handler. From then on the shell receives and executes .NET payloads delivered through ordinary-looking HTTP requests to the application.

There is no file. A web-root integrity sweep finds nothing. A file-based AV scan finds nothing. An .aspx hunt finds nothing. The shell exists only in w3wp.exe's address space, and it dies on application-pool recycle -- which is also why an attacker who has gone to this trouble usually keeps a disk-based fallback, and why an IIS reset is a diagnostic step as well as a containment one: if the anomalous behavior stops dead on recycle and resumes on next exploitation, that is your confirmation.

Detecting this requires module-load telemetry against w3wp.exe. Sysmon Event ID 7, or an EDR module-load stream, showing an unsigned DLL loaded into the IIS worker from a non-standard path is the signal. Windows Security event logs do not produce module-load records at all, so a Security-log-only pipeline is structurally blind to this stage.

Stage 5 -- Case 2: Rust Scanner Deployment and Tasking

The operator stages the scanner and its configuration under C:\Users\Public\Documents\ and C:\Users\Public\. That choice is not laziness. Those directories are world-writable and reachable by a low-privileged application-pool identity without escalation, which means the scanner path works even if the Potato escalation in Stage 3 fails.

The scanner retrieves its work queue over cleartext HTTP from a bare IP on a high port. ASEC documents hxxp://65.98.5.158:31337/Ins.Txt  and hxxp://2.59.133.147:31338/ins.txt, hxxp://2.59.133.147:31338/sm.json, hxxp://45.138.16.187:31337/bb.json and hxxp://45.138.16.187:31337/cofuz.json.

Port 31337 is a thirty-year-old attacker convention with essentially no legitimate enterprise use. An IIS server making an outbound cleartext HTTP request to one is not explicable by normal operation, and this is the single easiest detection in the entire chain.

Stage 6 -- Case 2: WordPress Discovery

For each target the scanner probes 53 candidate web paths, looking for /wp-admin/setup-config.php or /wp-admin/install.php. Both are reachable on a WordPress installation that has been unpacked but never completed -- a state that is more common than it should be on forgotten staging subdomains, abandoned migrations and half-finished agency handoffs.

A reachable setup-config.php is not an information leak. It is an invitation to complete the installation against a database the attacker controls, which yields administrative control of the resulting site.

Stage 7 -- Case 2: Telegram Exfiltration

Hits, together with the compromised host's public IP, are sent to the Telegram Bot API as an attachment named red.txt, via the bot token bot8930981923:AAGatbhK2_eiLMNtnWHkq33E6u7clhMPj5Q.

Telegram is TLS-only, so proxy-layer detection needs SNI or CONNECT logging at minimum, and full URL visibility (the bot token lives in the path) requires TLS inspection. Sending the compromised host's own public IP alongside the results is a small operational tell: the operator is tracking which of their footholds produced which findings, which is bookkeeping consistent with an operation running at some scale.

Timeline

Detection Guidance

Broken out by telemetry layer, because no single layer covers this chain. The web-request layer catches the attack; the process layer catches the consequence; the network layer catches the objective.

Web Request Layer (WAF / IIS logs)

This is the only layer that sees the attack before there is a foothold.

• POST to Telerik.Web.UI.WebResource.axd with type=rau carrying rauPostData. Combined with Telerik.Web.UI.AsyncUploadConfiguration, Telerik.Web.UI.AsyncUploadResult, TempTargetFolder or System.Configuration.Install.AssemblyInstaller anywhere in the request body, this is high confidence and worth alerting on hard. Requires the WAF to log request bodies -- on a headers-only configuration these markers are invisible.
• Request body size against baseline. Generation 1 must carry a mixed-mode assembly, typically tens to hundreds of kilobytes, where legitimate RadAsyncUpload traffic for a given application is small and consistent. This is the strongest single discriminator available and it requires nothing but a size threshold and a week of baseline.
• Volumetric error responses on the rau endpoint. The Generation 2 padding oracle is brute force: many requests from one source, differing only in ciphertext, each provoking a 500 / 400 / 406. No single probe is distinguishable from a malformed client request, so this must be expressed as a threshold per source address, not a signature. Start at roughly 50 requests in 15 minutes from one source and tune against the endpoint's real non-200 rate.
• Upload followed by execution. A POST that writes a path, then a GET or POST to that same path within seconds, is the definitive confirmation. It needs two-event correlation, not a single rule.
• First triage step on any hit: pull the Telerik.Web.UI.dll assembly version off the host. A hit against a host on 2026.2.708+ is far more likely to be scanning than compromise. A hit against anything below 2020.1.114 should be treated as a confirmed incident until disproven.

Process Layer (Windows Security 4688 / Sysmon / EDR)

• w3wp.exe as parent of cmd.exe, powershell.exe, whoami.exe or net.exe. On a healthy IIS server the set of application pools that legitimately spawn child processes is usually empty. This is the cheapest high-value rule in this section and it should already be in place.
• Potato-family binaries by name: sweetpotato, juicypotato, roguepotato, godpotato, printspoofer, efspotato, spoolsample. No legitimate presence on a production web server. Note that the "modified for web shell use" build may not match published hashes -- key on names and behavior, not hashes.
• \pipe\spoolss access, or the -c "C:\Windows\System32\cmd.exe" argument pattern, from a service-context process.
• Process creation under C:\Users\Public\ or C:\Users\Public\Documents\ with w3wp.exe ancestry. The parent context is what makes this meaningful; C:\Users\Public alone is far too common.
• Command lines referencing ins.txt, sm.json, cofuz.json, bb.json, red.txt, or :31337 / :31338. Requires command-line auditing to be enabled (ProcessCreationIncludeCmdLine_Enabled); without it these selectors are dead and only process-name coverage remains. Verify this is on before relying on it.
• Module load of godmemshell.dll, or any unsigned DLL, into w3wp.exe from a non-standard path. This is Sysmon EID 7 or EDR module-load territory. Windows Security logs will not give it to you.

Network Layer (Proxy / NGFW / DNS)

• Outbound cleartext HTTP from a server subnet to port 31337 or 31338. On a server subnet this deserves an alert with no further qualification. On user subnets, qualify with the .txt / .json config paths to avoid CTF and lab noise.
• Outbound raw TCP to 206.82.6.22:80 that does not parse as HTTP. Malformed-protocol-on-standard-port is itself the signal.
• A server-class host reaching api.telegram.org. Legitimate ChatOps and alerting bots exist; web servers are rarely among them. Inventory which hosts are supposed to talk to Telegram and alert on the rest. Requires SNI or CONNECT logging; full URL matching on the bot token requires TLS inspection.
• High-fanout outbound probing for /wp-admin/setup-config.php and /wp-admin/install.php. This is the most durable detection in the entire chain -- it survives every IOC rotation, because it is the objective rather than the infrastructure. Express it as distinct destination count per source within a short window, filtered to those paths, with the threshold set against this estate's normal outbound crawl baseline.

Identity Layer

• Application-pool identity acquiring SYSTEM. The Potato escalation produces a token-impersonation event chain in which a service account's process suddenly operates with SeDebugPrivilege / SYSTEM-equivalent rights. Alerts will group under IIS APPPOOL\<poolname> rather than a person, so group on hostname instead -- grouping on account collapses every affected server onto a handful of identical identities.
• New local accounts or service installations following any of the above on the same host. Neither is documented in these two cases, but both are the standard next move once SYSTEM is in hand.

Indicators of Compromise

Network

File Hashes (MD5)

AhnLab published five MD5 values without mapping each to a specific artifact. Candidates are the loader assembly, the Rust scanner, the modified SweetPotato build and godmemshell.dll. No SHA-256 values were published, which matters for any pipeline that populates only SHA-256.

Host Artifacts

MITRE ATT&CK Mapping

Key Takeaways

A KEV entry from 2023 is still producing SYSTEM in 2026. CVE-2019-18935 was fixed in January 2020. CISA published a full advisory on its exploitation against a federal agency in March 2023. AhnLab found two fresh cases in September 2026. Nothing about this chain is novel; the vulnerability management gap is the whole story, and it is a gap that has now survived a patch, a federal advisory and six and a half years.

The new CVE is not always the one hitting you. The 2026 Telerik padding-oracle chain got the coverage. The 2019 deserialization bug got the compromises. When a brief says "linked to a Telerik UI vulnerability" without naming a CVE, resolving which generation you are looking at is the first triage step, not a detail -- the fix versions are 2020.1.114 and 2026.2.708, and treating them as interchangeable will leave hosts exposed either way.

In-memory web shells defeat the file-based playbook completely. No .aspx, no web-root artifact, nothing for AV to scan. If your web shell detection is a file sweep, godmemshell.dll is invisible to it. Module-load telemetry against w3wp.exe is not optional coverage for IIS estates; it is the only coverage for this technique.

SeImpersonatePrivilege on application pools remains the shortest path from RCE to SYSTEM on IIS. The Potato family has worked for years, works here, and works against a "modified for web shell environment" build that may not match any published hash. Behavioral detection on token theft holds; hash-based detection does not.

Watch outbound, not just inbound. The loudest signal in this entire chain is an IIS server making a cleartext HTTP request to port 31337. That is one proxy rule, it requires no threat intelligence feed, and it would have caught Case 2 before a single WordPress site was probed.

A high-value foothold spent on low-value work says the access is cheap. SYSTEM on an enterprise IIS server, used to hunt for half-finished WordPress installs. That is not a resource-constrained actor making a hard choice; that is an actor for whom this class of access is abundant enough to spend casually. Which is, ultimately, the same finding as the first takeaway from a different angle.

References

1. AhnLab Security Intelligence Center. (2026, September 28). Vulnerability Attack Case: Installation of a Web Shell and Execution of a Scanner by Exploiting a Telerik UI Vulnerability. ASEC Blog. https://asec.ahnlab.com/en/95561/

2. Cybersecurity and Infrastructure Security Agency, Federal Bureau of Investigation, and MS-ISAC. (2023, March 15). Alert AA23-074A: Threat Actors Exploit Progress Telerik Vulnerability in U.S. Government IIS Server. CISA. https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-074a

3. Rapid7 / AttackerKB. CVE-2019-18935: Telerik UI for ASP.NET AJAX RadAsyncUpload Deserialization. https://attackerkb.com/topics/ZA24eUeDg5/cve-2019-18935

4. Almeida, M., and Steven, J. (2026, September). From Padding Oracle to Shell: Unauthenticated RCE in Telerik UI for ASP.NET AJAX. TantoSec. https://tantosec.com/blog/2026/09/telerik-padding-oracle-to-shell/

5. The Hacker News. (2026, September). Telerik UI Padding Oracle Bug Chained to Unauthenticated RCE. https://thehackernews.com/2026/09/telerik-ui-padding-oracle-bug-chained.html

6. Progress Software. (2026, July). Telerik Web Forms Critical Security Bulletin -- Multiple Vulnerabilities RCE Chain, July 2026. https://www.telerik.com/products/aspnet-ajax/documentation/knowledge-base/kb-security-critical-rce-chain-bulletin-july-2026

7. Progress Software. (2026, July). Telerik Web Forms Deserialization of Untrusted Data Vulnerability (CVE-2026-6023). https://www.telerik.com/products/aspnet-ajax/documentation/knowledge-base/kb-security-deserialization-of-untrusted-data-cve-2026-6023

8. Fortinet FortiGuard Labs. Threat Signal Report: Multiple Progress Telerik UI Vulnerabilities Exploited in the Wild. https://fortiguard.fortinet.com/threat-signal-report/5062

9. MITRE ATT&CK. Exploit Public-Facing Application (T1190). https://attack.mitre.org/techniques/T1190/

10. MITRE ATT&CK. Access Token Manipulation: Token Impersonation/Theft (T1134/001). https://attack.mitre.org/techniques/T1134/001/

11. MITRE ATT&CK. Server Software Component: Web Shell (T1505/003). https://attack.mitre.org/techniques/T1505/003/

12. MITRE ATT&CK. Reflective Code Loading (T1620). https://attack.mitre.org/techniques/T1620/

13. MITRE ATT&CK. Active Scanning: Wordlist Scanning (T1595/003). https://attack.mitre.org/techniques/T1595/003/

14. Telegram. Telegram Bot API. https://core.telegram.org/bots/api