01 Service
Adversary simulation and manual testing to find the paths an attacker would actually take to compromise your environment.
01 Overview
The question is whether a determined attacker can reach something that matters, and how. The answer is a route, reproduced and evidenced, that your engineers can follow and close.
Scanners find the classes of issue they were written to find; the findings that end up mattering are usually the chain, three unremarkable weaknesses that combine into access nobody intended. Establishing that takes a person.
02 Engagements
Most organizations start with one and add others as they learn where they are weakest.
Applications and infrastructure
Manual, scoped testing of a defined target: a web or mobile application, an API, an internal network, a workstation build. We work through the target the way an attacker would, chaining smaller weaknesses into the ones that actually matter.
Objective-driven, full scope
Rather than testing one system, we test the whole organization. We are given an objective: reaching a particular dataset, obtaining administrator privileges, reaching a production environment. Then we are left to find a route to it. Because the scope is the organization, the result tells you whether the whole chain of controls holds.
Run alongside your defenders
The same techniques, executed openly and in the same room as your security team. We run an attack, you watch what your tooling shows, and we adjust together until it is detected. It yields more improvement per day than a red team, which makes it the better first exercise for most organizations.
People and process
Controlled phishing, pretexting, and where in scope, physical access attempts. Measured to inform training and process. Results are never used to single out individuals.
Detection and response coverage
We execute known techniques against your endpoint tooling and record what is blocked, what is logged, and what passes unnoticed. Detection products are usually bought on a vendor's claims; this establishes what yours does in your environment, and where the gaps sit against MITRE ATT&CK.
What you expose to the internet
Discovery and review of everything reachable from outside: hosts, services, certificates, forgotten subdomains, exposed panels, credentials in public repositories. Most organizations are running more than they think, and the first finding of an engagement is often an asset nobody remembered owning.
03 Access level
This is the decision that most changes what the engagement can find, and it is worth making deliberately.
No prior knowledge
Mirrors an external attacker who has been told nothing. Realistic, and the most expensive per finding, because a significant share of the days goes on reconnaissance that an attacker would also have to do but is not paying you for.
Credentials and some documentation
What most engagements use. It assumes the attacker has already achieved what a phishing email achieves, which is a reasonable assumption, and spends the time on depth.
Source and architecture
Finds the most per day, because nothing is spent on discovery. It tests the code itself, so it answers a different question and is usually the right choice alongside a review.
04 Process
The same shape every time, whatever the scope. Nothing starts without written authorization.
We agree the targets, the objective, and the access level before anything begins. The access level is set out in the section above, and is agreed here.
Written authorization, tested windows, systems that are out of bounds, and named contacts for both sides. This is also where we agree what happens if we find something critical mid-engagement, or evidence that someone else got there first.
Testing runs to the agreed window. Anything critical is reported the day it is confirmed, so you can begin remediating while the engagement is still running.
An executive summary written for the people who approve the budget, and a technical body written for the people who will fix it. Severity reflects the impact a finding has in your environment.
A walkthrough with the engineers who own the systems.
Once fixes are in, we verify them and reissue the report showing what has been closed.
05 Deliverable
Everything below is included within the engagement.
06 Questions
It depends entirely on scope. A single web application is usually days; a red team engagement runs over weeks because it includes reconnaissance and patience. We give a window with the scope, before you commit.
A description of the systems, roughly how big they are, and what worries you about them. That is enough to come back with a defined scope.
Testing is designed not to. Denial of service is out of scope unless you explicitly ask for it, destructive actions are agreed in advance, and we work to your windows. Anything carrying real risk is discussed with you before it happens.
Findings, evidence, and any tooling written during the engagement are delivered encrypted and held only as long as agreed. We sign your NDA.
Annually is the usual baseline, and after any significant architectural change. Testing once and treating the result as permanent is the common mistake: the report describes the system on the day it was tested.
If you are unsure, a purple team exercise or an external attack surface assessment tends to produce more value than a red team. A red team measures whether your defenses hold; if you already suspect they will not, there are better ways to confirm it.
07 Contact
TowerVector will assist you in taking your security strategy to the next level. Please feel free to contact us: