Red team assessment
Red team assessment, towards an agreed goal.
A goal-based attack within agreed rules, chaining small weaknesses into one path and recording what your defenders saw.
What a tester checks on the way in.
We agree one goal with you, such as reaching customer records, then work towards it the way an outside attacker would.
Initial access
How an attacker gets a first foothold, from the outside in.
For example, VPN, reused passwordSocial engineering
Only in scope if you agree it with us in the rules of engagement.
Credential access
How a foothold becomes a valid login, through tokens and reused secrets.
For example, wiki runbook tokenSee the sample findingPrivilege escalation
How a low-privilege account turns into an administrator.
For example, prod-deploy roleLateral movement
How one host opens the next, across accounts, systems and trust.
For example, jump host, SSH keyDetection and response
Whether your alerts fire, and whether anyone acts in time.
For example, SIEM, on-callObjective and exfiltration
How far the agreed goal can be reached, and what leaves with it.
For example, customer export
What we need from you
- The objective to pursue
- Systems in and out of scope
- Whether social engineering is agreed
On live systems
Live systems by default, inside agreed windows, with a named contact and no destructive actions.
How we test it, step by step.
Before anything starts we write the objective, the scope and the rules of engagement, so the exercise stays inside limits you set.
A tester leads every step. AI speeds up recon, triage and reporting, and a person reviews every finding before it reaches you.
Agree the objective
What the tester does
We write the goal, the scope and the rules of engagement with you.
What you learn
A written record of what is in play and what stays off limits.
Find a way in
What the tester does
We study the exposed surface and look for a realistic first foothold.
What you learn
Where an outside attacker would start, and how exposed that is.
Reach the objective
What the tester does
We escalate, take credentials and move host to host towards the goal.
What you learn
How far one foothold spreads before it meets a real control.
Measure what you saw
What the tester does
We record each step against your alerts and your team's response.
What you learn
Which moves your defenders caught, and which passed unseen.
Three attack paths from a single foothold.
Three samples of how a single foothold becomes a path to the objective. Each begins with one ordinary weakness.
- Sample
A reused password opens the door
A support password from an old breach still opens the VPN. The attacker now holds a trusted session.
- Sample
One secret opens the rest
An admin token left in an internal wiki still works. One copied string reaches the deployment pipeline.
- Sample
Quiet steps to the goal
Keys left in config files lead from one server to the next. No alert fires before the customer database.
One sample finding, in full.
This sample shows how one stolen support login reaches the customer database, and which steps your team would have seen on the way.
Acme Corp is a fictional client. Every sample on this page is illustrative, never client data.
From one support login to the customer database
WhereGET /admin/customers/export
Token found in a wiki page
GET /wiki/support/runbookadmin_token: [redacted]
Token used on the admin API
GET /admin/customers/exportHost: admin.acme-corp.com200 OK, customer records
- Business risk
- An attacker with one support login could reach customer records before anyone noticed.
- Fix
- Require MFA on support sign-in and scope admin tokens.
Removed: support_signin: password
Added: support_signin: password + mfa
Checked by a tester before it reached the report.
What lands on your desk.
The path we took to the objective, step by step, each step set against whether your team saw it, and the change that would have stopped it.
Report
Findings, proof and fixes
Fix guidance
A fix for each step on the path
Executive briefing
The path, and what was seen
One retest within 30 days of the report
Path now blocked
Who it suits, and when to book it.
Teams with a security function already in place, who want their detection and response measured against a real attack path.
Mature security teams
Teams with alerts and a response plan they want tested for real.
High-value targets
Firms where a determined attacker would aim at one clear prize.
Boards and risk owners
Leaders who want a plain account of what an attacker could reach.
When to book it
- After a penetration testYou have fixed the findings and want to test detection next.
- Before a board reviewLeadership wants to know what a real attacker could reach.
- For a customer assurance reviewA major customer asks how you would withstand a real attack.
- After a major changeA new platform or a merger widens what an attacker could target.
- To test your blue teamYour detection and response team wants a live exercise to measure against.
Aligned with MITRE and NIST for adversary emulation.
Testing follows these standards, so your defenders can read what was tried against references they already use.
MITRE ATT&CK
MITRE ATT&CK knowledge base
Adversary tactics and techniques, catalogued from attacks seen in the wild.
NIST SP 800-115
National Institute of Standards and Technology (NIST) Special Publication 800-115
The technical guide to information security testing and assessment.
OWASP Top 10
Open Worldwide Application Security Project (OWASP) Top 10
The most critical risks to web applications, ranked.
Aligned with, never certified by. Names belong to their owners; no endorsement implied.
Questions before scoping.
We reply to every quote request within one business day, from info@greysurface.com.
Is social engineering part of the test?
Only if you agree it with us. It goes into the written rules of engagement before the exercise starts, or it stays out of scope.
When is a red team the better choice?
When you want detection and response measured. A penetration test covers an agreed set of systems in full; a red team pursues one objective and records whether your team notices.
Will the exercise disrupt our live systems?
We work in your live environment by default, inside agreed windows, with a named contact and no destructive actions.
Who leads the red team?
A tester leads every exercise. AI speeds up recon, triage and reporting, and a person reviews each step and every finding before it reaches you.
What access do you need to start?
The objective to pursue, the systems in and out of scope, and whether social engineering is agreed. We start from an outside position unless you ask otherwise.
Is a retest included?
Yes. One retest checks the reported findings, within 30 days of the report, so you can confirm the path we took is now closed.
How should we prepare for a red team?
Name a single point of contact who knows the exercise is live, agree the window, and decide whether your blue team is told in advance or tested blind.