Fayad K. HassanContact

A $10K OSINT Red-Team Against a Simulated Intelligence Network

A tabletop red-team against a fictional joint-intelligence network, run on open-source material and a small budget. Notes on how much of the exposure came from ordinary public traces rather than intrusion, and what a simulation like this honestly can and cannot show.

Procurement metadata and open satellite imagery converging on a supplier facility, with a fitness-app heatmap marker beside it
Contents 7 sections
  1. The premise
  2. Reconnaissance: what the open sources hand you
  3. Three ways public exposure gets used against a network
  4. What defends against this
  5. The vulnerabilities that made the exercise work
  6. What a simulation like this can and cannot tell you
  7. Sources

A note on what this is, before anything else. This was a tabletop exercise. The target was fictional, no real people or organisations were touched, and every figure below is a design assumption I chose, not a measurement I took. I built the scenario, so I could make it come out however I liked. That means it proves nothing on its own. What it is good for is building intuition about where an intelligence network’s exposure actually sits, and turning that into a checklist a defender can use. Read it as a structured argument, not as a result.

The argument is this. When people picture an intelligence network being taken apart, they picture intrusion: someone breaking in, stealing files, planting code. In the exercise, almost none of the useful access came from breaking into anything. It came from material that was already public, sitting in the open, put there by the network’s own people and its own suppliers. The real surface was hygiene, not security.

The premise

One operating hypothesis, held for the whole exercise: people leak patterns and infrastructure broadcasts signatures, and both do it in public, for free. If that is true, then most of an adversary’s early work is not hacking. It is correlation.

The budget was small on purpose, on the order of ten thousand dollars of notional spend, because the point was to see how far ordinary open sources and cheap tooling go before you ever need anything exotic. The answer is: much further than is comfortable.

Reconnaissance: what the open sources hand you

Reconnaissance was the whole game, and it cost almost nothing. The method was to take one public fact, use it to reach the next, and keep pulling the thread.

A supplier’s public product listings and delivery metadata point at a facility. A satellite layer geolocates the facility. A public fitness-tracking heatmap over that location shows a cluster of devices moving on a regular pre-dawn schedule, which is what a shift looks like from above. None of that requires access to a single protected system. It requires patience and the willingness to treat scattered public traces as one connected object.

The correlation logic, stripped to its shape, looked like this. Treat it as illustrative pseudocode, not a working tool:

# Illustrative only: the logic, not an implementation.
def find_pattern(supplier_name):
    facility   = public_procurement.lookup(supplier_name)   # unredacted delivery address
    location   = satellite.geocode(facility.address)        # open imagery
    activity   = fitness_heatmap.query(location, radius_m=2000)
    # a "shift" is a device cluster that repeats on a schedule
    return activity.recurring_clusters(min_devices=5, window="05:00-07:00")

Two public sources did most of the work in the exercise. Recurring fitness-app clusters before dawn behave like a duty roster you did not have to steal. And gaps in professional profiles, promotions that quietly stop, roles that go vague at the same moment, line up with people moving into work they cannot talk about. Cross-referenced against ordinary ride-history and delivery spikes, a large share of the fictional personnel became identifiable. Again: I set the difficulty. The lesson is not the hit rate. It is that every input was something the network chose to publish or let a supplier publish.

Three ways public exposure gets used against a network

The exercise modelled three lines of attack. I have dropped the code-name theatrics the first draft dressed them in, because the names made it sound like a film and the mechanics are the only part that matters.

Desynchronising the calendar

The first line targets time. If you can quietly corrupt a command structure’s shared sense of schedule, you degrade it without touching a weapon. In the model this meant impersonation built from public material, public interview audio is enough to clone a voice convincingly now, combined with a phishing foothold in a scheduling system, then small, deniable edits to meetings. The interesting part is not the intrusion. It is that calendar systems are built to auto-resolve invitations helpfully and silently, so a manipulation that a suspicious human would catch slides through the machinery unremarked.

Saturating the response

The second line targets attention and capacity: flood the network with credible false alarms so that its real signals drown. The credibility here leans on a genuinely documented weakness, the SS7 signalling system that older telecom trust still rests on, which has been shown publicly for years to allow message and location trust to be abused. I am deliberately not writing an operational recipe. The point for a defender is the structure: a message that appears to come from command, arriving through a channel the recipient has no easy way to authenticate, will move people. Trust that cannot be verified is the vulnerability, and it is a design property of the legacy layer, not a bug someone forgot to patch.

Manufacturing mistrust

The third line is the cheapest and the ugliest: fabricate just enough plausible evidence to make an organisation turn on itself. Generative tools make convincing internal-looking documents and a convincing voice for the price of a subscription. Placed well, a forged memo suggesting one ally has betrayed another does not need to be believed outright. It only needs to raise the cost of trust inside a group that runs entirely on trust. Relationships are far more expensive to repair than to poison, which is what makes this the most damaging and lowest-budget line of the three.

What defends against this

The defensive half was the useful half, and it inverts the attacker’s advantages rather than trying to out-spend them.

Against reconnaissance, poison your own patterns. If your exposure is that public traces are reliable, make them unreliable on purpose: seed plausible false patterns, break the regularity of the real ones, and treat your own people’s public footprint as an operational surface you manage, not a private matter you ignore.

Against time manipulation, remove silent auto-trust from scheduling. Require signed meeting invitations so that an edit without a valid signature is visible rather than absorbed. The fix is not more encryption in the abstract. It is refusing to let a machine resolve a change no human verified.

Against saturation, build channels whose authenticity a recipient can actually check, so that a message claiming to be from command can be confirmed out of band before anyone acts on it. An alert you cannot verify should move no one.

Against manufactured mistrust, the defence is cultural and it is the hardest to install: a shared, practised expectation that damaging claims get verified before they get acted on, especially when they arrive conveniently and inflame. The organisations that survive this are the ones that made “slow down and check” a reflex before they needed it.

The vulnerabilities that made the exercise work

Every line above traces back to a small number of root causes, and none of them is glamorous:

Class Vector Root cause
Physical Facility sensors and IoT Default credentials, broadcasting openly
Telecom Legacy signalling trust Authenticity that cannot be verified end to end
Process Calendar auto-resolution Machines resolving changes no human checked
Supply chain Procurement metadata Unredacted delivery and product detail, public
Human Public lifestyle patterns Regular, published routines treated as private

Notice what is missing from that list: a clever exploit, a zero-day, a break-in. The exposure was built out of defaults left on, trust that could not be checked, and routines published in the open.

What a simulation like this can and cannot tell you

I want to end where the honest version has to end, because the first draft of this piece overreached badly and a security reader would have stopped at the first sweeping claim, correctly.

A simulation you design yourself cannot prove anything about real networks. I chose the target, the assumptions, and the outcomes, so any “result” is circular. The precise-looking percentages the first version reported, downtime, accuracy, confidence drops, were never measurements. They were set dressing, and presenting them as findings was the mistake. I have removed them, because a number I invented and then reported back to you is worse than no number.

What the exercise is honestly good for is narrower and still worth something. It is a forcing function for intuition. Walking each line end to end made one thing concrete in a way that reading about it does not: the exposure was almost entirely a function of ordinary public hygiene, not of anyone’s ability to break in. The defensive checklist that falls out of it, manage your public footprint, verify the authenticity of what moves your people, refuse silent machine trust, make verification a reflex, does not depend on any of my invented figures to be worth doing.

That is the whole claim, and it is a small one. Not that a lone actor can topple an intelligence service for pocket change. Only that if you want to understand where such a network is actually exposed, you should spend far less time picturing the break-in, and far more time looking at what it and its suppliers and its people are quietly publishing every day.

This was a simulation. No real entities were targeted. The techniques are reconstructed at a conceptual level from long-public research on telecom signalling trust, supply-chain metadata exposure, and fitness-tracking heatmap leaks, and are described here to inform defence, not to enable an operation.

Sources

  • The 2018 disclosure that put military sites on a public map: Strava’s global heatmap.
  • Background on the legacy telecom weakness referenced above: SS7.