What a red team actually does on day one
People picture the first day of a red team the way films shoot it — someone in a dark room, a wall of green text, a progress bar that says ACCESS GRANTED. I have been doing this for a while now and I have never once seen that day. The real first day is quiet, it is mostly reading, and it is where the whole engagement is decided.
We do not start by attacking anything. We start by learning your company well enough to attack it — which, it turns out, is a thing you can do almost entirely from the outside, using information you published on purpose.
We read your job ads first
This surprises clients every time. Before we touch a single one of your systems, we read your open engineering roles. They are extraordinary.
"Experience with Okta, AWS, and Snowflake required." Now I know your identity provider, your cloud, and where your data lives. "Maintain our Jenkins pipelines" — you have a CI server, probably reachable, historically a soft target. "Familiarity with our legacy PHP monolith a plus." Thank you; I will be spending my afternoon there.
You cannot hire without describing your stack, and every description is a map. This is not a criticism — you have to recruit. It is just worth knowing that the map exists and that we read it on day one.
Then the boring, powerful stuff
From there it is methodical, and honestly a little dull to watch:
DNS and certificates. Certificate transparency logs are public and permanent. Every TLS cert you have ever issued is written down somewhere I can read, which means staging., vpn., internal-tools. and that dev subdomain someone spun up in 2023 and forgot are all sitting in a list. Subdomains are where the soft targets live, because nobody threat-models the thing they meant to delete.
The edges of your IP space. What answers on the public internet, on which ports, running which versions. Not to exploit yet — just to inventory. Attack surface is the first deliverable, and most companies have never actually seen theirs written down in one place. Handing that over is sometimes worth the whole engagement on its own.
Your people, carefully. Public LinkedIn, conference talks, GitHub commits, the meetup your platform lead spoke at. Not to be creepy — to understand who has access to what, and who an attacker would impersonate. The finance approver and the person who owns the AWS root account are the two most valuable identities in most companies, and both are usually findable in an afternoon.
None of this touches your systems. All of it is you, quoted back to yourself. That is the uncomfortable part and also the useful one.
Why the reading decides everything
By the end of day one we have not "hacked" anything. What we have is a model: your likely identity provider, your cloud, a list of exposed edges, your CI, a handful of forgotten subdomains, and the two or three humans whose accounts unlock the most.
Every later choice falls out of that model. The phishing pretext writes itself once you know who reports to whom. The subdomain nobody remembered is where we get our first foothold four days later. The whole engagement is downstream of how carefully we read.
Which is exactly why the film version is wrong. The dramatic bit — the foothold, the pivot, the moment we are standing in your cloud console — is real, but it is the consequence. The work that made it possible was a day of reading things you handed to the world for perfectly good reasons.
What you can do with the same information
Here is the turn, because I do not want this to just be unsettling. Everything we do on day one, you can do to yourself, and you should, because attackers already are.
Read your own job ads as an inventory. Pull your own certificate transparency logs and go find the subdomains you forgot. Scan your own edges and write down what answers. Ask, honestly, which two identities in your company would end the game if someone had them — and then go and check how well those two are protected.
You do not need a red team to start seeing yourself the way one does. You just need to spend an afternoon reading, the way we do on day one. Most of what we find, you could have found first.