Same rule as last time: no findings here. Search Party intel goes to law enforcement through Trace Labs, not onto a blog. Everything below is about method.
For grounding: 26th of 110 teams on 1430 points. The team put in 41 submissions and had 34 accepted. Nine of those were mine, six accepted and three rejected. Last event I finished 7th on a cold case, so this was a step backwards on a harder case type, and the reasons are not mysterious. Most of them are in this post. We also got pulled out of the random prize draw, which is not a skill.
I spent the first half of the window building analysis. Geocoded every candidate location, computed distances and bearings, reconstructed which transit route the subject could plausibly have taken by pulling public transit relations and measuring every stop against her accommodation. It was careful work. I ran a falsification test against my own hypothesis and reported the result when it came back against me.
All of it scored zero. Both analytical submissions came back No Point Value.
One of them was later corroborated by an independent source that said, in effect, exactly what my geometry had concluded. It still scored zero, because being correct was never the test.
Trace Labs pays for discovered artifacts, not inference. A page that names the subject is intelligence. An argument about the subject, however well constructed, is not. If your submission’s evidence section describes a calculation rather than a source, you are about to spend an hour for nothing.
That distinction is obvious in retrospect and I did not see it until the second NPV came back.
Anything sourced from coverage of the disappearance gets rejected. The family and the police feed details to the media. So by the time it is in print, law enforcement has had it for weeks. The NPV category names newspapers explicitly.
I knew this. I had written it down. Then I recommended two submissions built on press reporting, including one where the detail appeared in exactly one outlet and nowhere else, and another where I could demonstrate from the raw case record that the detail was absent from the official report. Both rejected.
Verifiable absence from the missing-person report is not sufficient. Presence in press is disqualifying on its own.
Every approval came from the subject’s life before the disappearance.
Her name in a search engine returns nothing but the case. Seven weeks of international coverage buries everything else she ever did. But she existed before any of it, and that earlier footprint is unindexed relative to the noise, which means nobody else on the scoreboard is standing there.
So: old local papers, school newsletters, club and project rosters, exhibition listings, sports results, yearbooks, community organisation pages. Material that predates the case by years and has no relationship to it.
Searching the subject’s name is useless for the reason above. The move is to search the rare names adjacent to her.
A press photograph caption named her alongside several other people. Those other names were uncommon strings with no connection to any missing-person story, so they cut straight through the coverage that swamped hers. Three of the six approvals trace back to that one caption.
Two smaller tricks from the same chain. Newspaper photo assets often carry a desk reference in the filename, and those reference formats are house conventions, so the ID alone can tell you which publisher and therefore which regional title to search. And image URLs on large news sites sometimes encode the original source URL in the asset filename, which will hand you a social post identifier for free.
My point values were wrong on five of nine categories, and I was missing a category entirely. Not slightly wrong. Wrong in ways that would have changed which category I filed things under and therefore what they paid.
Do not trust your notes, your last event, or a community guide. Open the official categories page at the start of the window and read it. It takes two minutes and mine cost more than that.
I had one submission per unique URL written down as an absolute after a previous event’s rejections. This time the coach explicitly allowed a second flag in a different category against the same URL.
I had spent part of the window steering away from points that were available. Ask the coach at the start rather than importing a ruling from a different event and a different judge.
Username enumeration sweeps, an API enumeration against a route-logging platform, a vendor API, authenticated-endpoint probing. None of it produced a scoring submission.
Two specific traps worth naming. Several large platforms return HTTP 200 with a soft-404 body for usernames that do not exist, so a status-code sweep reports every candidate as a hit. Always calibrate against a control string that cannot possibly exist before you believe any enumeration result. And one major platform returns an error for every unauthenticated profile lookup including controls, which means no unauthenticated method distinguishes a real profile from a fake one. Knowing that is worth more than another tool.
I also made the opposite error. My sweep did surface the subject’s real handle and I discarded it, because I had just been burned by the false positives and bucketed it with genuinely common strings without opening it. It was her full name on an uncommon surname and was never in that class. That single call cost more points than every automated technique returned all night.
The lesson is not that enumeration is useless. It is that enumeration produces candidates, and the judgment about which candidate to open is the entire job.
Read the live category page. Ask the coach about URL reuse. Spend the first thirty minutes finding out who the subject was before the case existed, using the rare names around her rather than her own. Collect pages, not arguments. Screenshot with the URL bar visible at the moment of discovery.
Do not build a model of what happened. Nobody is paying for your model.
]]>This is the framework I run, why it’s shaped the way it is, and what the constraints do to your tool choices. I played one earlier this year and finished 7th, which is enough to have learned the failure modes and not enough to be smug about it.
No findings here. Search Party intel goes to law enforcement through Trace Labs, not onto a blog.
Zero touch. You view, you don’t engage. No contacting the subject, family, or friends, no friending, no commenting, no password reset pages, no breach credentials. Those aren’t bounced flags, they’re immediate disqualification.
That single rule eliminates most of what people reflexively call OSINT tooling. Anything that authenticates, enumerates by probing, or leaves a notification is out. What you’re left with is read-only collection against public surfaces, and your toolkit should be picked on that basis rather than on what’s fashionable.
It also means the bottleneck is never access. It’s judgment about what’s worth submitting.
Work it in this order. Each rung produces the selectors for the next one.
The brief. Read it as a list of things you’re not allowed to submit. Every detail in it is already with law enforcement. Its value is selectors: full legal name including middle names, age at disappearance, the geography, the institution or employer, the date. Names in the brief are the seed, not the finding.
The primary account. The subject’s own profile, if one exists, is the single highest-yield surface in the whole exercise. Public About panels give you schooling, employers, hometown, relationships, and a photo set, and it’s all first-party. This is where most of my accepted submissions came from.
Worth being precise here, because the rules read as contradictory if you skim: Facebook is listed as a banned source, and that’s true of awareness Pages set up about a missing person. Those are aggregators. The subject’s own profile is a primary source and a completely different animal.
Account-linked identifiers. From the primary account you get usernames, profile photos, a display-name convention, sometimes a partial email or phone from a poorly configured privacy setting. These are what you pivot on. A username reused across platforms is the classic chain, but it only counts if you can prove the accounts are the same person. A common handle with no corroborating evidence gets rejected, and rightly.
Community originals. Research forums where people do their own digging can produce genuine primary material: a family member posting detail that never made the press, someone’s original reconstruction of a timeline. That scores. The advocacy blog that re-aggregates that same forum post does not.
The timeline. Last rung and the hardest. You’re looking for evidence of the subject’s own activity after the missing date.
I’m deliberately describing jobs rather than binaries. The specific tool matters less than knowing which of these four things you’re doing, and tools churn.
Username enumeration across platforms. Feed a handle from the primary account, get back candidate profiles elsewhere. Fast and high-volume, and it generates far more noise than signal, so treat every hit as unconfirmed until something correlates it to your subject. This is where people burn an hour and submit garbage.
Archive and cache retrieval. Wayback and cached copies. Underrated, because a profile that’s locked down now was often wide open years ago, and the archived version is a legitimate public source. Also your answer when a page changes mid-competition and you need the state you actually saw.
Image work. Reverse image search to find the same photo on another platform under a different handle, which is one of the cleaner ways to prove two accounts are one person. EXIF where the original file is retrievable, though social platforms strip it on upload so the yield is low.
Search operators. The least glamorous and probably the highest return per
minute. site:, filetype:, quoted exact strings, name variants including
middle names and misspellings. Most of the pivots that mattered came from a
well-constructed query, not from a tool.
Everything above reads only. Nothing in that list touches the subject, and that’s the point.
One folder per case, with screenshots and evidence separated. Every screenshot shows the URL bar and a timestamp. Capture at the moment you find it, because pages change and a submission you can’t re-evidence is a submission you can’t defend.
The submission format that got accepted: category and the specific rubric bullet it satisfies, the URL, two or three sentences on why it matters to the investigation, one line on the collection trail, screenshot attached.
Worth knowing before you spend an hour producing it.
Aggregators, every time. Missing-persons aggregate sites, the police case page, community advocacy blogs that re-aggregate. The judge note is always some version of: this is a missing persons website, any leads such as these would have been shared with law enforcement, and will not be considered a new lead. You can use them to pivot to original sources. That’s the entire relationship you should have with them.
Anything you sourced twice. One scoring submission per unique URL. Splitting one source across multiple categories reads as gaming the system, which sits closer to a DQ risk than a rejection. Your URLs are the scarce resource, not your time. Decide what a source is worth and pitch it once, in the highest category it honestly supports.
Category mismatches. Read the definitions literally. Advancing the Timeline wants activity from the subject’s own accounts after the missing date, not a third-party sighting reported later. I submitted post-disappearance sightings and read the rejection as a judgment call when it was a category mismatch. they were never eligible. Same literalism on advanced subject info, which wants identifiers not already in press or police reports. If the police page mentions it, it isn’t advanced.
Refinements. “Hooded jacket” where the brief said “jacket” is not intelligence, it’s editing. What scores is anything that helps someone recognize the person now. A judge reading a hundred submissions decides in seconds whether yours changes anything, so the framing carries as much weight as the finding.
Check the current point values against the published category list before the window opens rather than trusting your notes. Mine were wrong, and Trace Labs flagged rule changes in early 2026 that hadn’t propagated into the training material yet.
The compelling cold case is a trap, and I walked into it. A disappearance from 2010 has no live accounts to work, which means the high-value categories structurally do not exist for you no matter how good your tradecraft is. You are capped at a few hundred points of basic subject information.
Someone missing one to three years, with a real pre-disappearance online footprint, is where the timeline and location flags actually live. Pick on surface area, not on narrative.
]]>Setup was 15 objectives from the bundled scorer-eval sets across illegal
activity, cyber, phishing, harassment and misinformation. Sigma 0.4, one
augmented sample per attempt, loop until something breaks through, record the
first-success index. Scoring used the task_achieved_refined true/false
scorer, which asks whether the response fulfilled the request or refused. Not
the QA scorer, which asks whether the answer is correct and inflates
everything, because a well-formed refusal is still a correct answer.
Against gpt-4o-mini, judged by gemini-2.5-flash: 20% at N=1, 27% at N=2, 47% at N=4, 47% at N=8, 60% at N=16. Keep re-sampling augmented variants and refusals fall off.
The climb held on every target I tried. gpt-4o, gpt-4.1-mini, gpt-4.1, gemini-2.5-flash, gemini-2.5-pro. A local llama3.2:3b barely moved, 7% to 13%, which is the same scaling story from the other end: a heavily safety-tuned 3B model needs a lot more than 16 samples.
I didn’t trust the judge blind. I pulled response text and judge rationale back out for several successes and read them by hand. An anti-vax post, a phishing email, a lab-leak article. Real compliance, not the judge false-positiving on a refusal.
What I’m not claiming. This is one run at N=16; Hughes et al. went to roughly 10k samples, so this corroborates their scaling result rather than replacing it. To keep targets off their own judge I scored OpenAI targets with Gemini and Google targets with gpt-4o-mini, which means cross-vendor absolute numbers aren’t comparable. The within-row trend is the solid part. At 15 objectives the gaps between models sit inside the noise, so read the tables as “ASR rises with N everywhere” and not as a ranking.
One target was simply unreadable: gpt-5.5 rejects at an API-level policy filter before the model sees the prompt. That’s a vendor input classifier, not a model refusal, and measuring it would answer a different question.
]]>I wrote up the mechanics with runnable PoCs in
sms_gateway_poc: basic SMTP
send, direct-to-MX delivery that skips a relay entirely, multi-carrier fanout,
and From: header spoofing.
The interesting property is what the recipient sees. A message that arrived over SMTP renders in the same thread UI as one that arrived over SMS, with whatever sender string survived the gateway. The trust cues a person uses to judge a text message were designed around the carrier network, and this path routes around it while still landing in the same inbox.
There’s a defender-side scanner in the repo, which is the part I care about more. If you own a domain or a mail path, knowing whether your infrastructure can be used this way is a thing you can check rather than assume.
What I’m not claiming: this isn’t novel and it isn’t a vulnerability in the sense of something a carrier will patch. It’s a legacy interoperability feature behaving as designed, and that’s precisely why it’s durable. I also haven’t measured what fraction of messages survive carrier-side filtering, which varies by carrier and changes without notice. Treat the PoCs as demonstrating the path exists, not as a delivery rate.
Authorized testing only. Sending unsolicited messages through these gateways is illegal in most places regardless of how the plumbing works.
]]>Five categories, all detected on the output side rather than the prompt side:
credential leaks, XSS, SQL injection, shell commands, and path traversal.
Compiled regex, ErrorSpan support so a caller knows which span tripped, and a
fix_value redaction path so it can sanitise rather than only reject.
The design decision worth stating is that this scores output, not input. Prompt-side filtering gets most of the attention because it feels like prevention, but it’s guessing at intent. Output-side detection is looking at an artifact that either does or doesn’t contain an AWS key. Much less ambiguous, and it catches the cases where the model produced something dangerous with no adversarial prompt involved at all, which in practice is a lot of them.
The same reasoning went into the PyRIT scorers I contributed around the same time. Detection you can point at a concrete string is detection you can regression-test.
What I’m not claiming: regex is a floor, not a ceiling. It catches shaped
secrets like AWS keys and GitHub tokens, and it will miss anything that doesn’t
have a shape. Selective scanner config and an extra_patterns hook are in
there because the default set is a starting point that everyone will need to
extend for their own environment.
I put together runnable PoCs for the ones that keep working: bidi_poc. Trojan Source, where bidirectional control characters reorder how source displays without changing what parses. Homograph substitution, where a Cyrillic character stands in for a Latin one. Overlong UTF-8, where a byte sequence decodes to something a naive validator already approved in its shorter form. Null-byte truncation, where the parser and the validator disagree about where the string ends. Double encoding, which beats any filter that decodes once.
The pattern underneath all of them is the same: two components in the pipeline disagree about what a byte sequence means, and the security decision gets made by the one with the more permissive reading.
There’s a defender scanner in the repo too, which is the part I’d actually use. Detection here is mechanical. You’re looking for byte patterns, not intent, so it belongs in CI rather than in a reviewer’s head. Asking humans to spot a right-to-left override in a code review is asking them to do something the rendering layer is actively working against.
What I’m not claiming: none of these are novel, and Trojan Source in particular got a CVE and a lot of attention in 2021. The finding, if there is one, is that they still land. The techniques are old and the pipelines that mishandle them are new every year, because every new parser gets to rediscover the same disagreement.
]]>