Offensive Security

Red Team & Code Review

Objective-driven red team engagements that start from assumed breach, with source-code review when reading the code is the faster way to the objective.

A red team engagement starts with an objective, not a checklist: reach the payment flow, read another tenant's data, get a foothold in production. We work toward it the way an intrusion would, with evasion in play and the defenders unaware, because the question is not only whether a path exists but whether anyone would notice it being used.

Source-code review runs alongside, or on its own, when reading the code is faster than probing the running system for the same answer. We read the parts an attacker reads first: authentication, authorisation, trust boundaries, deserialisation and anything that handles untrusted input. The two feed each other, a hunch from the code confirmed against the live system and back again.

Usually, one of these is true

You have had penetration tests for years and want to know whether your team would actually detect and respond to a real intrusion, not just whether bugs exist.
A board or a regulator wants evidence that a determined attacker cannot reach a specific business-critical asset.
You have the source and want it read for the flaws a black-box test would take far longer to reach, if it reached them at all.
A new detection and response capability has gone in, and you want it exercised against realistic attacker behaviour before you trust it.

What we cover

One engagement can run as a red team exercise, a source-code review, or both together, with the objectives, rules of engagement and any exclusions written down before we start.

Objectives and rules of engagement. A named goal agreed up front, with the trusted contacts, deconfliction process, exclusions and an emergency stop written into the rules before anything begins.
Assumed breach. Engagements that begin from a foothold rather than spending the budget on the front door, so the time goes to what happens after an attacker is already inside.
Initial access. External and social-engineering routes in, where the objective is to test them: phishing, exposed services and the paths a real intrusion would try first.
Source-code review. A read of the code an attacker studies first: authentication and session handling, access-control checks, trust boundaries, deserialisation and input handling.
Attack chains. Individually minor findings chained into a full path to the objective, rated on where the chain ends rather than where it starts.
Detection hand-off. Which actions raised an alert and which did not, and a purple-team walk-through of the path with your defenders once the covert phase is over.

How the engagement runs

One named engineer on the keyboard and on your channel. The covert phase stays quiet; everything opens up in the hand-off afterwards.

Objectives and rules. We agree the objective, the scope, the trusted agents and the rules of engagement in writing, including deconfliction and the conditions for an emergency stop.
Reconnaissance. We map the reachable surface and, where the source is in scope, read it for the routes worth trying, building the picture before we act on it.
Execution. We work toward the objective with evasion in play: initial access or an agreed foothold, then privilege escalation and lateral movement, recording each step.
Live reporting. Findings reach your channel as they are confirmed, with a reproduction, a CWE mapping and a CVSS v4.0 rating. Anything critical is reported within the hour.
Hand-off and retest. We walk the whole path with your team, note what fired and what did not, and retest once fixes land, with a letter of attestation covering the result.

What you get

The route to the objective. Every step from the starting point to the goal, with proof at each step and the order in which it was done.
An account of what was seen. A clear record of which actions raised an alert and which passed unnoticed, and the telemetry that would have caught the difference.
Findings ordered by what closes the path. Remediation prioritised by what breaks the chain, mapped to CWE and rated with CVSS v4.0, written by the engineer who found it.
A purple-team walk-through. A session with your defenders that replays the path openly, so detection and response can be improved against it.
A retest and a letter of attestation. Once fixes land we retest the path and issue an attestation covering what was tested and what now holds.

What we need from you

A defined objective and the rules of engagement: what is in scope, what is off limits, and the conditions under which we pause or stop.
One or two trusted contacts on your side who know the engagement is happening and can deconflict with a live incident.
For the code review, read access to the repositories in scope and enough to build and run the application locally.
For an assumed-breach start, an agreed foothold: a standard user account or a workstation image of the kind an attacker would land on.
A point of contact who can authorise access and answer architecture questions without exposing the engagement to the wider team.

What we can show you

Research, not only testing. 70+ CVEs published by our researchers, and research acknowledged by Apple, Microsoft, Google OSS VRP, Facebook, Twitter, Adobe, Intel and the U.S. Department of Defense. We find the flaw and we can explain the root cause.
The person on the keyboard writes the report. No account-manager layer and no junior bench. The engineer who reached the objective writes it up and walks your team through the path.
Quiet, then open. The covert phase stays covert. Findings reach your channel as they are confirmed, criticals within the hour, and the whole path is replayed with your defenders in the hand-off.
Handled under NDA. Mutual NDA and PGP before anything is shared. Evidence stays encrypted, least-privilege and limited to the engineers on the engagement, and is destroyed after the retest on request.

Standards we work to

We map the engagement to the frameworks your defenders and reviewers already use, so the findings translate into detection and code fixes without rework.

MITRE ATT&CK
OWASP Code Review Guide
OWASP ASVS
NIST SP 800-115
CWE
CVSS v4.0

Common questions

How is a red team different from a penetration test?

A penetration test drops evasion to find as many exploitable issues as possible in the scope. A red team keeps evasion in and works toward a single objective, so it answers a different question: would you detect and respond to a real intrusion. If you want coverage of a whole application, a penetration test is usually the better fit.

Do you need our source code?

Only if the code review is part of the engagement, and it does not have to be. Source-code review is faster and deeper for logic and authorisation flaws; a pure red team works black-box toward the objective. Many engagements do both, using the code to guide the live testing and the live system to confirm what the code suggests.

Will our security team know it is happening?

That is the point of agreeing trusted contacts. A small number of people know, so they can deconflict a real incident, while the wider security team does not, so their detection and response is tested honestly. Everything opens up in the hand-off afterwards.

What if you find something critical during the engagement?

It goes to your channel as soon as it is confirmed, and anything critical is reported within the hour. We do not sit on a serious issue until the report. If it looks like it is already being exploited by someone else, we tell you straight away.

What do we get at the end?

The route to the objective with proof at each step, a record of what your defences did and did not catch, remediation ordered by what closes the path, and a purple-team walk-through with your team. A retest and a letter of attestation are included once fixes land.

Related services

Tell us about the system in the chat or on the contact page. Yaali, our AI agent, answers first and brings in an engineer.