OFFENSIVE THINKING. PRACTICAL SECURITY.
Assume nothing.
Test everything.
We challenge the assumptions behind your security. Find the weaknesses that matter. And turn evidence into a stronger defence.
SIGNALS / SYSTEMS / ATTACK SURFACES
Look closer. There is always another layer.
01 / CHALLENGE THE ASSUMPTION
02 / FOLLOW THE EVIDENCE
03 / STRENGTHEN THE SYSTEM
THE DIALECTIC
Security is a dialogue.
Evidence moves it forward.
Good security starts with better questions. What can an attacker reach? Which controls actually hold? What needs to change? We connect hands-on testing with decisions your team can act on.
01 / CAPABILITIES
Find the weakness.
Make the fix count.
TECHNICAL DEPTH.
CLEAR DECISIONS.
01
Offensive security
The focus
Find the path an attacker would take. Test the weakness, understand the impact, and prioritise the fix.
Inside the scope
Applications, infrastructure and agreed attack paths. Evidence-led findings with remediation priorities and retesting defined in the engagement scope.
02
Threat & exposure intelligence
The focus
Separate credible exposure from background noise. Put external threats and data leaks into context.
Inside the scope
A focused view of threats relevant to your organisation, with source context and practical investigation or remediation steps.
03
Detection engineering
The focus
Make the signals worth watching visible. Strengthen monitoring around the activity that matters.
Inside the scope
Review telemetry coverage, detection logic and alert handling. Agree the monitoring model and operational responsibilities before implementation.
04
Incident response
The focus
Move from uncertainty to an informed response. Investigate the event and support containment and recovery.
Inside the scope
An agreed response scope, evidence-handling approach and communication plan. Availability and response terms are confirmed directly, not assumed.
05
Connected & physical systems
The focus
Look beyond the browser. Review the devices, access systems and integrations your operations depend on.
Inside the scope
Connected-device platforms, fleet management, access-control and surveillance integrations. Specialist hardware or communications testing requires a separately agreed scope.
06
Governance & readiness
The focus
Translate technical risk into decisions. Build governance that supports the way your organisation actually works.
Inside the scope
Risk assessment, security priorities and evidence-backed readiness work. Applicable obligations and deliverables are established for each engagement; no blanket compliance guarantees.
02 / OUR APPROACH
Challenge.
Test. Resolve.
Not a scanner export. Not a stack of generic recommendations. A focused engagement built around your systems, your risk and the decisions you need to make.
THE ENGAGEMENT PROTOCOL
SCOPE
Agreed boundaries
TEST
Authorised activity
OUTPUT
Documented evidence
VERIFY
Retest the finding
Written scope. Actionable findings.
01
Define the boundaries.
Agree the assets, objectives, authorisation and rules of engagement before any testing begins.
02
Test the assumption.
Investigate how the system behaves in practice. Validate findings and trace the meaningful attack paths.
03
Make the evidence usable.
Explain what happened, why it matters and what to fix. Give technical teams detail and leadership a clear decision.
04
Verify the change.
Agree remediation support and retesting. Check the fixes against the original finding, not just the checklist.
02 / INSIDE A FINDING
Evidence. Not just a score.
Explore a fictional finding from impact through to a verified correction.
SAMPLE DELIVERABLE / FICTIONAL
Cross-tenant invoice access
Object-level authorisation
Impact
One account should not expose another.
In this example, a signed-in customer can read an invoice belonging to another customer. That creates a confidentiality failure across accounts. The sample does not establish access to all invoices or prove that any real customer was affected.
The illustrative read endpoint authenticates the session but omits object-level authorisation. A tenant A principal receives a tenant B record for an action that policy should deny. Only the shown read path is demonstrated; write access and bulk enumeration are not established.
DS-LAB-001 / 01
Scope demonstrated: one cross-tenant read
Data: synthetic invoice
Not established: write access or full dataset exposureEvidence
Keep the proof precise.
A controlled test uses two isolated customer accounts and a synthetic invoice. The expected outcome is an access denial. The vulnerable example instead returns the other account’s invoice.
Authenticate as the tenant A test principal and request the known tenant B fixture INV-2049. Compare the expected authorisation decision with the response and record the actor, action, object and relevant policy. The HTTP excerpts are illustrative, not captured production traffic.
DS-LAB-001 / 02
Actor: tenant-a test principal
Object: INV-2049 / tenant-b
Action: read
Expected: DENY
Observed in the lab: 200 OK + recordRemediation
Fix the decision, not the identifier.
Require the system to confirm that the user is permitted to access the specific record before returning it. Test this consistently across customer boundaries and user roles.
Enforce authorisation server-side for every relevant action and object. Use a policy-aware lookup or a central policy check before serialisation. Changing record IDs to UUIDs or hiding the button is not a substitute. Review related read, list, export and write paths rather than assuming one patch covers them.
DS-LAB-001 / 03
request → authenticate → authorise(actor, action, object)
→ deny on policy failure
→ return permitted data onlyVerification
Prove the denial. Preserve the legitimate path.
Retest both sides: a different customer must be blocked, and the permitted customer must still be able to read the invoice. Review related paths separately before expanding the assurance claim.
Add cross-tenant negative tests and authorised positive controls. Check role boundaries, unauthenticated requests and related endpoints within the agreed scope. In this fictional retest, the cross-tenant read returns 403 and the authorised read returns 200; a design may instead return 404 to avoid disclosing existence.
DS-LAB-001 / 04
Cross-tenant read: 403 / denied
Authorised read: 200 / allowed
Related endpoints: separate test coverage required03 / FIELD NOTES
From the workbench.
Investigations, engineering
and lessons from the field.
Dalail.ai Security Assessment
Read the field note: Dalail.ai Security AssessmentWhat happens when an AI application works as intended, but its backend trusts the public a little too much? We recently performed an external…
Blue-Steel Incident
Read the field note: Blue-Steel IncidentBlue-Steel: from business email compromise to containment. We were brought into Blue-Steel following a series of targeted attacks against multiple corporate mailboxes. Our investigation…
03 / START WITH THE RIGHT QUESTIONS
Shape the assessment.
A clearer scope makes a better first conversation. Build a short brief, then keep it or send it yourself.
To scope an assessment, note the system type, objective, environment, approximate size and timing. Share those details through the site’s contact page.
04 / START A CONVERSATION
What are you
working on?
A new application. A difficult security question. A system that needs a closer look. Let’s define the right engagement.
DIRECT CHANNEL
Jeddah, Saudi Arabia
Start with your objectives, the systems in scope and your preferred timing. Please do not send credentials, sensitive datasets or exploit details in an initial email.
Send a brief. Agree the scope.
Keep sensitive details off email.