Key Takeaways
- A vulnerability’s individual severity doesn’t tell you everything about the attack path it can create when combined with another weakness.
- Across this month’s cases, one weakness created the conditions needed to exploit the next, turning individual vulnerabilities and behaviours into much more significant outcomes.
- Finding vulnerabilities and proving attack paths are different things. Identifying individual weaknesses doesn’t necessarily show what an attacker could achieve by combining them.
- Attackers don’t stop at the first weakness. They keep looking for the next one that turns access into something more valuable.
- WRAITH tests attack paths, not just individual findings, showing what becomes possible when weaknesses are combined in a real attack.
On this page
The Chain Is The Vulnerability: What This Month’s Attacks Reveal
Your last vulnerability report probably contained findings assessed individually, each with its own severity, remediation priority and place in the queue.
But attackers often don’t treat vulnerabilities individually.
This month’s three cases show what happens when one weakness creates the conditions needed to exploit another. Authentication bypass becomes remote code execution. Unauthorised access becomes full administrative control. Trusted system functionality becomes part of a route to SYSTEM privileges, one of the highest levels of access in Windows.
The important question isn’t only how severe each vulnerability is on its own. It’s what becomes possible when an attacker starts connecting them.
Case 1: SharePoint’s JWT & BCS Chain
Source: BleepingComputer
- A flaw in the way SharePoint checked users’ digital credentials could allow an attacker to impersonate a legitimate user or administrator without logging in.
- On its own, this gave the attacker unauthorised access but didn’t allow them to run code on the SharePoint server.
- A second vulnerability in SharePoint’s Business Connectivity Services could then be chained with the first, allowing the attacker to achieve remote code execution (RCE), meaning they could run their own code on the server.
- The authentication bypass was weaponised within a day of its proof-of-concept being published, and attackers were later observed probing the combined RCE chain shortly after the second proof-of-concept became public.
Implication: The authentication bypass opened the door. The second vulnerability changed what an attacker could do once they were through it. Looking at either weakness alone didn’t tell the whole story. The attack path did.
Case 2: MikroTrick
Source: CERT Polska
- Researchers at CERT Polska identified vulnerabilities in MikroTik RouterOS that attackers were actively chaining against devices with SSH (Secure Shell), a service used to remotely access and manage devices, exposed to the internet.
- The first vulnerability affected how RouterOS authenticated users connecting through SSH, allowing an attacker with information about a valid user account to bypass the normal authentication process without knowing the user’s password or possessing their private security key.
- A second vulnerability could then be chained with the first, turning that unauthorised access into full administrative control of the router.
- At the time of disclosure, approximately 122,500 RouterOS devices had SSH exposed to the internet.
Implication: An internet-facing management service can turn a vulnerability chain into a direct route to critical infrastructure. In this case, attackers didn’t need to steal a password to take control of the router, they needed the right weaknesses in the right order.
Case 3: ShieldBreak
Source: SecurityWeek
- A researcher demonstrated an exploit that abused interactions between Microsoft Defender, Cloud Files functionality and other Windows system components to achieve privilege escalation.
- The attack began with an EICAR test file, a harmless file commonly used to test whether antivirus software is working, which triggered Microsoft Defender.
- The technique then manipulated where Defender believed it was scanning, ultimately allowing attacker-controlled code to be placed in a protected Windows system location.
- A legitimate Windows scheduled task then caused the attacker’s code to run with SYSTEM privileges, one of the highest levels of access in Windows.
Implication: The tools designed to protect an environment can become part of the attack path. ShieldBreak showed how trusted software and legitimate Windows functionality could be manipulated as part of a route to higher-level access.
Key Patterns Across This Month’s Attacks
Three cases. Three different products. One recurring lesson: understanding individual vulnerabilities isn’t always enough to understand the attack path they create together.
- Individual severity doesn’t describe the whole attack path.
A severity score assesses a vulnerability, not every outcome that becomes possible when it is combined with another weakness. - Each step enabled the next.
Across all three cases, the significance of one weakness became clearer when attackers could use it to reach the next stage of the attack. - Weaponisation can happen quickly.
In the SharePoint case, the authentication-bypass proof-of-concept was being used in attacks within a day of publication. - Finding vulnerabilities and proving attack paths are different things.
Identifying individual weaknesses doesn’t necessarily demonstrate how they could be combined in a real intrusion. - Trusted tools can become part of the attack path.
ShieldBreak demonstrated how legitimate Windows security and system functionality could be manipulated as part of a privilege-escalation technique.
Why This Matters for Enterprise Security Leaders
Severity scores remain an important part of vulnerability prioritisation. A critical vulnerability will naturally demand attention ahead of many lower-severity issues.
But severity alone cannot describe every attack path that exists across an environment.
A vulnerability is assessed according to what it can do under a defined set of conditions. An attacker is interested in something different: what that weakness enables them to do next.
The cases above show that distinction clearly.
- In SharePoint, an authentication bypass could be combined with a separate vulnerability to create a route to remote code execution.
- In MikroTrick, unauthorised remote access could be chained with privilege escalation to produce full administrative control of the device.
- In ShieldBreak, multiple Windows behaviours and trusted system components could be manipulated as part of a sequence that ultimately achieved SYSTEM privileges.
The individual vulnerabilities and behaviours explain the weaknesses. The chain explains the outcome.
That creates a challenge for vulnerability management. Vulnerability scanning can help identify and prioritise weaknesses across an environment, while penetration testing can validate whether those weaknesses can be exploited. But neither should be viewed in isolation from the wider attack paths those weaknesses might create.
Understanding real-world risk requires looking beyond the individual finding and asking what an attacker could do next.
How WRAITH Addresses This
The answer isn’t simply a stricter severity scale. It’s testing the attack path, not just the individual finding.
WRAITH‘s operators don’t stop at identifying a weakness and moving on. Once a foothold or vulnerability is identified, they ask the same question a real attacker would: what does this actually enable?
Can this access expose another weakness? Can that weakness provide greater privileges? Can those privileges create a route towards a critical system or objective?
Campaigns are built around following those opportunities and testing whether individual weaknesses can be connected into a genuine attack path, rather than treating every issue as a standalone item on a list.
That distinction matters because identifying a vulnerability and understanding its real-world impact are different things.
A scanner asks whether a vulnerability exists.
WRAITH asks what an attacker could build from what’s there.
An environment can contain vulnerabilities that appear manageable when reviewed individually but create a very different level of risk when an attacker finds a viable path between them.
A vulnerability report tells you what was found. WRAITH tells you what an attacker could do with it.
Jennifer Goulbourne
Jennifer is a Digital Marketing Executive at OmniCyber Security, where she's responsible for engaging the company's existing customer base across digital channels and creating helpful resources on threat intelligence and security operations for cybersecurity professionals and business leaders.
