Detection is no substitute for Mitigation
Detection is no substitute for Mitigation
A walled garden may not be the solution - but it sure does help.
Preface:
I’ve been asked on multiple occasions if we could write a custom detection as a “compensating control” to mitigate the risk of a vulnerability being exploited, in order to buy system admins more time or better yet to altogether negate the need to take a critical business service offline for patching. This article will explain why the answer has never been “yes”, due to the inherent limitations of Threat Detection and Detection Engineering.
We reported last week on the widespread exploitation of a critical vulnerability in the PaperCut print management software, perpetrated by CL0P and LockBit ransomware affiliates and helped along by a public PoC exploit released by researchers at Horizon3.
On the flip side of that were defenders, creating and sharing detection rules to assist those who couldn’t/hadn’t yet patched the vulnerability, or who wanted to monitor for possible exploitation as a precaution.
While a variety were fielded utilising Sysmon logs, device-generated logs, and even network telemetry - the team at Vulncheck last week proved why detections can’t truly compensate for a lack of patching, by bypassing all of them in a revised PoC.
Now you see me, now you don’t
The Sysmon detections largely hinged on alerting where the PaperCut application process (pc-app.exe) spawned an unexpected child process like cmd.exe or powershell.exe.
This can be - and indeed already is - circumvented by spawning a reverse shell in a way that requires an intermediary process, for example when dropping a Java instance of the Meterpreter shell:
While Horizon3 researchers were right to point to native log entries indicative of the exploits targeting of the software’s print scripting interfaces - this, again, was bypassed by Vulncheck who instead found they could abuse the User/Group Sync “custom programs” to achieve the same effect while also avoiding triggering those alerts altogether.
The Suricata IDS rule proposed by Proofpoint also proved brittle - because the rule searched for the specific string "/app?service=page/SetupCompleted" as an indication of attempted exploitation, it can also be bypassed by inserting junk values that wouldn’t impact the request, such as page//SetupCompleted or random=1&page/SetupCompleted.
It’s an Art, not a Science
Naturally, the original rules could be modified to alert on a child process of java.exe or to search for a string consistent across variations such as “SetupCompleted” - but that would introduce a high risk of generating false positive alerts.
This brings me to the point of this post - Detection Engineering is a constant battle to maintain a (heavily subjective) balance between being specific enough to generate as few false positive alerts as possible, while also being broad enough to account for attacker permutations and alternate components that can be inserted into the exploit chain to evade our detections.
The PaperCut vulnerability is the perfect example of why detections are not a substitute for mitigation - the quality of your detection hinges entirely on how well you’ve accounted for all possible implementations or variations of a technique or procedure.
Should the authors of the first round of detections have been expected to know that User/Group Sync “custom programs” could also be targeted to exploit the vulnerability? Probably not, but the confidence in those detections - which many security teams would be relying on - would have still been moderate to high, in the absence of evidence that they had in fact missed another attack path for the vulnerability.
In other words - you can’t know what you don’t know, and that’s a problem when an organisation is reliant on detections for mitigation.
The saga continues…
While I’ve got you - if two ransomware groups and a publicly available exploit PoC weren’t enough to get you patching - Microsoft have also reported spotting Iranian actors getting in on the action, with Mint Sandstorm (formerly PHOSPHORUS) and Mango Sandstorm (formerly MERCURY) observed opportunistically exploiting the vulnerability across a range of industries and geographies.