Spotting Service Token Reconnaissance

What it stops

This control hits attackers during the discovery phase of a breach; they get a service token some way or another, maybe through a leaked CI/CD secret or an exposed environment file. At first, they don't actually know what permissions that identity has, and to figure it out, they run scripts to probe API endpoints and check which paths give them a success code instead of an error. This is called enumeration.

How do you stop it? You flag any access to endpoints that fall outside the historical baseline for that specific token; if a token normally only reads from /v1/metrics, it's a problem when it suddenly calls /v1/iam/policies. That's where the alert triggers. It turns a silent reconnaissance phase into a loud event.

What it does not stop

People love calling this thing a security boundary in slide decks. It isn't. This doesn't replace least privilege or scope minimization (which are still the point), and the fundamental problem remains: it does nothing to stop the initial token theft. If an attacker already knows the target endpoint and skips the exploration phase, you're done for, and a single, precise hit on `/v1/vault/secrets` won't trip any rare access alerts if that's all they send.

Patient attackers will break this too. They can just space out their requests over several weeks to stay under volume thresholds or avoid detection entirely. One new endpoint per day looks like background noise to a baseline model, which it is. It's like a smoke detector. That isn't the same as having fireproof walls.

What it looks like when it is working

A working system pushes a high-fidelity alert right into the security operations centre queue. It gives the analyst the token ID, the source IP, and the exact endpoints that got hit. You can see the sequence in the logs. It starts with several HTTP 403 Forbidden responses while the attacker guesses paths or tests boundaries. Then comes an HTTP 200 OK on an endpoint the token has never touched.

Is this just a developer error? I don't think so. A developer makes one mistake and stops there. Attackers probe until they find a gap; the logs show ten or twenty different API paths accessed in a narrow window of time, often paired with an unusual User-Agent string.

How to prove it

Get a production-grade integration token, and it needs broad permissions but limited daily usage. Use a machine with an IP address outside the service's normal workload to keep things clean. Why? This stops your test traffic from mixing with the real stuff.

Now, send requests to twelve different API endpoints, and the token needs to be authorized for these, but they should be paths it doesn't actually touch in its day-to-day life; think of valid paths like /v1/audit/logs, /v1/org/members, or /v1/billing/invoice. Keep a tight log of the exact timestamp for every single request and the HTTP response code you get back.

Does the system catch you? The test is a success if a security alert hits the analyst's desk within 20 minutes of that first request, and when it happens, write down exactly when the alert arrived and which specific detection logic flagged your activity.