Two in a row - You mitigated wrong (Kentico CMS RCE)

What it is

A two-part DFIR case study from dfir.ch on a Kentico CMS server compromised via a deserialization RCE at /CMSPages/Staging/SyncServer.asmx. Beyond the summary, the value here is the concrete mitigation that was applied and why it did not hold: the customer added an IIS rewrite rule blocking .asmx files to external source ranges, yet a second intrusion followed five months later on the same server.

How it works

The exploit POSTs a serialized payload to /ProcessSynchronizationTaskData under SyncServer.asmx, using .NET SoapFormatter with the WindowsIdentity gadget chain (stagingTaskData POST var). Post-compromise, the attacker made SEO poisoning stealthy: they added an IIS global rewrite rule and injected code into the legitimate PortalTemplate.aspx so that any request for an {anything}.html file loaded xoso.aspx, which pulled HTML from a remote server — but only served it when the user agent contained the string "oogle" (Googlebot). Privilege escalation used PrintNotifyPotato.exe (PrintNotify COM service) dropped in C:\ProgramData.

What to do

Detection anchors the page. Chainsaw (or DetectRaptor) over Event Logs and MFT flagged PrintNotifyPotato.exe. For webshells, run a Velociraptor YARA hunt with the Thor Webshell rules, and add a trivial custom rule for the site-specific IOC string xoso. Version-check Kentico via CMS.DataEngine.dll.

The attacker's persistence rewrite rule to hunt for:

appcmd.exe set config /section:system.webServer/rewrite/globalRules /[name='xoso'] action.type:"Rewrite" /[name='xoso'] action.url:"/CMSWebParts/Viewers/Effects/Carousel_files/xoso.aspx?id={R:1}" /commit:apphost

Caveats

The customer could not patch Kentico at the time, so they mitigated by blocking .asmx externally. The page states this rule "came a few days too late" — the server was already compromised before it was applied, so restoring from backup and even migrating to a new server did not clear the infection (crashes and re-compromise recurred). Blocking the endpoint does not remediate an existing foothold.

flowchart TD
    A[SyncServer.asmx RCE] --> B[Foothold: webshell + PrintNotifyPotato]
    B --> C[Restore backup / new server]
    C -->|foothold persists| B
    B --> D[Block .asmx externally]
    D -->|applied too late| E[Second intrusion, 5 months later]

The second-intrusion entry vector is only partially shown — the page reveals a hidden encoded PowerShell command fetching dll.bat from http://216.83.45.170:90/dll/ but the excerpt cuts off before the root cause is confirmed.