Exploit validation: separating real risks from false alarms
Automated scanners flag possible weaknesses, but many of those alerts turn out to be harmless. When every alert is labeled “critical,” engineers stop trusting the list and the dangerous items get lost in the noise. A telecommunications company asked us to find out which of its alerts were real.
Scanner claims
Reachable
Verified exploitable
Controlled, scoped and rollback-ready. Staging first, production only with written approval.
The situation
The telco ran more than 3,000 network and IT assets, watched by four scanners and two shifts of its security operations center (SOC), the team that monitors alerts around the clock. Engineers had started ignoring “critical” tickets, because most of the ones they picked up could not be reproduced. Meanwhile the board had begun to question what the security budget was buying.
What the client needed
The client wanted to know which weaknesses an attacker could actually use. That meant proving each one through controlled validation, done safely, with written permission and with evidence, so that repair work went to real risks first.
How we checked each finding
- A first filter for reachability: could an attacker even get to the system, given its exposure, login requirements and configuration?
- Controlled validation steps that favor read-only proof, such as reading a harmless file or showing a session could be taken over. We changed no data in production.
- All testing followed recognized rules of engagement (PTES and NIST SP 800-115), with written authorization for every target.
- Each confirmed item came with the steps to replay it, supporting logs, a CVSS severity score and an exploitability rating. Anything we could not confirm stayed clearly labeled as unconfirmed.
- The result was a register of findings verified as exploitable.
What held up under testing
Of the 540 findings the scanners had marked critical, 58 could be exploited. The rest were out of an attacker’s reach, already covered by other controls, or false alarms based only on a software version number.
The confirmed issues included a chain of flaws in the VPN (the remote access gateway) that allowed remote code execution before login, which we proved on a lab copy rather than on the live system. They also included a way to replay single sign-on tokens and cloud storage that outsiders could write to, which opened a path to tamper with software the company distributed. Three issues rated only “medium” became critical once we showed they could be chained together. Twelve rated “critical” were downgraded after we confirmed the web firewall and network isolation really stopped them.
What it meant for the team
Engineers could now put their time into the 58 confirmed items first, working to agreed repair deadlines. The regulator and the company’s insurer accepted the validation evidence as proof that risk had been reduced. The validation steps now run automatically whenever a new critical finding appears.
Teams that rank their repair work by severity score alone, and never test whether an attacker could actually use the weakness, are likely carrying the same hidden backlog.