Assumed Breach is a cybersecurity consultancy that attacks your network, applications, cloud and people the way a real adversary would, then hands you the findings, the proof, and the fix, in plain language your board and your engineers can both act on. Assumed breach is the model we work from: we start from the position that an attacker is already inside.
We assess the systems you actually run, in the way an adversary would actually approach them. Every engagement is scoped around your environment and delivered with proof of what we found and a route to fixing it.
All of it runs on one assumption: that a breach is already assumed, and the question worth answering is what happens next.
Engagement reports are confidential, so what follows is written rather than lifted. Each case study is a composite: the shape of the work and the class of finding, with no real client, system, date or figure in it.
Asking a customer for their password to another service is common, quietly catastrophic, and almost always avoidable. What goes wrong, why it survives internal review, and what to do instead.
For Product owners, operations teams, and anyone who has ever built a form to make an internal process easier.
Most breach investigations begin with a theory. The ones that go wrong are the ones that set out to prove it. How to structure an investigation so the premise can fail, and why that is when the useful findings appear.
For Founders, operations leads and technical teams responding to something that looks like a compromise.
Technical write-ups from real engagements and research: what we found, how it was exploited, and what closes it.
web securityYou escaped the shell metacharacters and the command still ran. Argument injection is the bug that survives shell-safe APIs, here is the mechanism, the PHP-CGI case that got mass-exploited, and the one-character fix.
insecure deserializationtorch.load(weights_only=True) was the recommended safe path, and it was bypassable. A practical look at Python deserialization, pickle, PyYAML and jsonpickle, how one gadget works, and what actually stops it.
web securityMost SSTI write-ups teach one Jinja2 payload and stop. Here is the actual bug class, the per-engine probe table, a lab you can build in ten minutes, and the code-review rule that removes it entirely.
Engagements are scoped to your estate and your risk, not to a package tier. Every one of these ends in a report you can hand to an engineer and a summary you can hand to your board.
Find the paths into your network, and the paths across it once someone is in.
Manual, business-logic-aware testing of the applications your customers touch.
Full-estate discovery, triaged by real exploitability rather than raw CVSS.
A goal-driven, full-scope simulation of a determined adversary against live defences.
Security testing mapped to the control frameworks your auditors are asking about.
Purpose-built CTFs that train your engineers on the systems they actually defend.
Not sure which of these you need? Tell us what you are worried about and we will scope it with you.
No packaged tiers, no scan-and-send. Here is what you can expect from an engagement, before you ever get on a call with us.
From discovery and exploitation through to remediation guidance and re-testing.
Network, applications, cloud, APIs and people assessed by the same team, against one threat model.
Testing is hands-on and manual. Automated tooling supports the work; it never substitutes for it.
We stay available through remediation and re-test the fixes rather than closing the engagement at delivery.
Techniques tracked against how intrusions are actually carried out today, not a static checklist.
Findings are reproducible, prioritised by real exploitability, and written to be read by both engineers and executives.
Perimeter-first thinking asks whether someone can get in. We ask what happens once they have. That reframing is what surfaces the flat networks, the over-privileged service accounts and the unmonitored lateral paths that a pass/fail scan will never report.
Every issue we raise is demonstrated, rated by real exploitability in your environment, and paired with the change that closes it. You get a technical report your engineers can work from and a summary that answers the only question leadership is asking: how exposed are we.
Incident response work focuses on containment and eviction first, then a clear account of how the intrusion happened and what has to change so it does not happen the same way twice.
The people running your engagement hold recognised offensive security certifications. These are the ones we hold.
PNPT
TCM Security
CRTO
Zero-Point Security
Security+
CompTIA
Google IT Support Certificate
Drawn from recommendations written by the people we have worked with and from completed contracts. Summarised here rather than quoted, because the originals are theirs to have written; both sources are public and linked below.
The people we have worked with describe scope being extended rather than defended: work taken on without being asked for, and value added beyond what was agreed.
Alongside assessment work we have designed live capture-the-flag environments and proof-of-concept ranges for security products, built to be attacked rather than demonstrated.
Engagements have run against real product deadlines, including getting a platform ready for red team testing, at a pace the teams involved called out specifically.
The point most consistently raised is communication: technical depth that survives being explained, and collaboration that people wanted to repeat.
Contact
Describe the environment and the concern. We will come back by email with the questions we would need answered to scope it properly.
New technical write-ups and notable breach analysis, sent when we publish. No drip sequences, no sales cadence, unsubscribe any time.
