TL;DR
- What started as simple exploitation of a vulnerability from 2019…
- …went from RCE to persistence to tunnelling to clean up.
- With a diversionary (or celebratory?) visit to Pornhub along the way.
- What you can learn to improve your detection, logging, and hardening strategy.
Introduction
We investigated a ransomware incident on a Windows Server 2012 host running in an SFTP-only role. The attacker delivered an attack that combined remote code execution, persistence, tunnelling, and a diversionary visit to Pornhub, before launching a ransomware payload.
Background & scope
- Environment: Windows Server 2012, SFTP only, SSH open, RDP closed by network policy.
- Protection Baseline: Default Windows Defender and default event log sizes.
- Objective: Identify how the attacker got in and what occurred whilst they were in.
An easy way in
The compromised server was running a Telerik UI for ASP.NET AJAX version 2016.1.225.45, which is vulnerable to CVE-2019-18935, a critical remote code execution vulnerability.
Figure 1: Telerik Version
This version lacks mitigations introduced in later releases, including proper request validation and handler protections. This allows unauthenticated attackers to upload and execute arbitrary files via the AsyncUploadHandler.
Separated by around 12 days, InvalidCastException was observed in the application logs, the culprit was a request from the same external IP, which was flagged as malicious, targeting Telerik’s AsyncUploadHandler, which allowed the attacker to gain access.
The attacker dropped a file named ‘wondershare.tmp.tmp’ into the temp folder. The file threw an error, requesting a missing DLL. Almost immediately PowerShell logs showed this DLL was fetched using PowerShell, and Defender exclusions were put in place. vcruntime140.dll was grabbed from a malicious domain controlled by the attacker using a quick DownloadFile() call.
Figure 2: DownloadFile call
These exclusions meant anything that matched the above would be undetected by Defender; any temp files, any executables and anything stored in the temp folder. With remote code execution and AV detection out of the way, the adversary had full file system access, with no credentials required.
Establishing foothold
With tools, access, and exclusions in place, it was then time for the attacker to get comfortable. They quickly created a new local admin account under the name: Depeloyadmin. Notice the spelling mistake?
Now they have their backdoor account, how did they establish persistence? The Winlogon Userinit key was modified to run a rogue userinit.exe from the temp folder, and a firewall rule for “Remote Desktop – User Mode (TCPIn)” appeared, and port 3389 started listening soon after.
Reconnaissance & reentry
After ten days of ‘sil3nce’, the attacker struck again. The same Telerik RCE exploit was triggered, this time the attacker brought some tools with them.
The threat actor dropped a tunnelling client, Ngrok.exe. This was loaded in memory, with an .ngrok2 config folder, with registry edits made for the proxy setup.
Remember the firewall rule for Remote Desktop – User Mode (TCPIn)?, this was put in place for their return, specifically for RDP over loopback. They initiated an RDP session from ::1 under the Depeloyadmin account, confirming remote hands-on access.
Network graphs showed a 90MB outbound spike over two hours, consistent with expected RDP bandwidth while they were active.
Ransom notes, pornography, and encryption
Once the attacker had full interactive access via RDP, things moved quickly.
They kicked things off by dropping a file called sil3ncer.json into the temp folder. This held everything the ransomware needed to get going, including command and control endpoints, file paths to target and unique identifiers for the victim.
Almost immediately the encryption began. Thousands of files across the system were renamed with a .sil3ncer extension, it was quick and deliberate. There was no sign of exfiltration, just chaos, in the hope that the end user would pay the ransom to have their files decrypted.
To round things off, they dropped ransom notes called SORRY-FOR-FILES.txt into folders like the root drive and Program Files. The message was blunt, instructing the user to get in touch via Telegram if they wanted to see their files again. No websites, no portals, just a direct line to the attacker.
Browser forensics also revealed some interesting findings seconds after the in-memory sil3ncer.json config file was dropped and seconds before the ransomware began encrypting files and dropping ransom notes. We pulled cache entries, cookies, favicons and session tabs to confirm a quick visit to Pornhub, which likely served to mask the tunnel traffic, or maybe the threat actor had a moment of excitement that their ransomware deployment was underway.
Figure 3: Pornhub Favicon
Figure 4: Chrome Web Session
Cleanup & exit
To erase footprints, the attacker executed a cleanup script named clear.bat from the Desktop, which was evidenced by ShimCache and UserAssist artefacts.
The attacker also deleted the rogue Depeloyadmin account via Control Panel, ShellBag artefacts showed the threat actor traversing to this location before the account was then deleted.
Once that was done, they logged off RDP, leaving minimal on-disk‑ logs due to default size caps and cleanup. Below shows an image of the desktop post encryption, displaying the cleanup script and the ransom note mentioned earlier.
Figure 5: Affected Desktop
Lessons learned & recommendations
What could have been done to avoid this incident?
Patch third-party components: Attackers love old, forgotten software. Vulnerabilities like the Telerik one used in this case have been public for years, yet they still get results. Regularly patching third-party components is one of the easiest ways to protect yourself from these types of attacks. If you’re running something like Telerik UI, check what version you’re on and update it. Don’t just patch the OS and assume you’re safe.
Harden your logging: In this case, key events were overwritten before they could even be reviewed. Increase the size of your Windows event logs and look at forwarding logs off the host. If logs are the first thing to disappear during an attack, make them harder to wipe.
Detect suspicious commands: The attacker used a handful of known commands to disable antivirus and open firewall rules. Keep an eye out for PowerShell commands like Add-MpPreference, and anything that tampers with the firewall using netsh.exe. Even basic alerting on these can catch early stages of an attack.
Block tunnelling services: Ngrok was used here to bypass network restrictions and open RDP access. If you’re not using tunnelling services internally, there’s no reason they should be allowed. Block domains like *.ngrok.io at your DNS or firewall layer.
Lock down RDP properly: In this case, RDP was disabled by network policy, but that didn’t stop the attacker. They found a way around it using something called RDP loopback. Once they had local admin access, they enabled RDP on the host itself, then set up a tunnelling tool (Ngrok) that forwarded a local port to the outside world. When they connected back in, it looked like the RDP session was coming from the local machine (::1), so it bypassed any network-level restrictions.
Blocking RDP at the perimeter isn’t enough if attackers can re-enable it from the inside. If remote access is needed, route it through a hardened jump host with strong access controls and MFA. And if it’s not needed, disable it at the service level, not just the network.
And while we’re on the topic of remote access hygiene, yes, the attacker really did visit Pornhub from the compromised SFTP server. Was it to camouflage tunnel traffic, or was it just because they could? Either way, if your ransomware incident comes with a side order of porn, you’ve got bigger problems.
Conclusion
This case shows how an old ASP.NET flaw can still provide a foothold for handsonkeyboard attackers. By combining exploitation, Defender exclusions, covert tunnelling and encryption, the threat actor caused chaos. With proper patch management, logging, and network controls, organisations can tighten security before they experience fullscale breaches.
One final takeaway, if your forensic timeline includes Pornhub on a server that was supposed to just handle SFTP, it might be time to review your outbound rules, because your SFTP server shouldn’t be working overtime as a streaming client.
Patch early, log often, and never underestimate an attacker’s creativity… or their browser history.
