2Atomic / Services / Threat research

// engagement · pointed at an adversary, not an incident

Does the way they get in reach what you ship?

We take the adversary's artifact apart ourselves, then prove whether its technique lands on your product. No product subscription required.

Scope a threat research engagement → How an engagement runs
First-party, reversed by us
Reach proven against your own artifact
Stated confidence, per claim
Standalone, no platform license
Reach verdict: each technique the adversary uses, held against the product you ship A document page listing the techniques recovered from an adversary's artifact. Each row names the technique, what in the customer's product it would have to reach, and the verdict: reproduced, not reproduced, or not reachable. One row is marked as unreachable with the reason, and one is marked as not covered rather than being folded into the clean rows. THREAT RESEARCH Their technique, against your product TECHNIQUE RECOVERED WHAT IT HAS TO REACH VERDICT Unsigned payload accepted at update your update verifier REPRODUCED Length taken from the attacker's header your image parser REPRODUCED Persistence through a recovery path your recovery image NOT REPRODUCED Credential replayed to a cloud endpoint your enrollment flow NOT REACHABLE Code delivered through a peripheral a bus we were not given NOT COVERED HANDED BACK Reproductions you can re-run 2 Indicators and behavioral rules 9 Mitigations, by the class they close 3
Sample Reach verdict: each technique recovered from the adversary, held against the product you ship The shape of the hand-back, redacted. Yours carries your own findings.

The question this answers

Three engagements, three different questions. This one is the only one that runs before anything has happened to you.

  • Incident response answers what got in and what it did. It starts after the fact, from your evidence.
  • Firmware and secure-boot review answers what is wrong with the image you hand us. It starts from your artifact and a checklist of trust decisions.
  • Threat research answers who would come for this, how, and whether the path they would use exists in what you ship. It starts from an adversary and ends at your product.

If an incident is live, start with incident response. This engagement is the one you buy when nothing has happened yet and you want to know what would.

What we need from you

Two things: an adversary to point at, and the product you are protecting. We need both before we can scope the work.

A named threat
A group, a campaign, or a capability class
Or a sample
With no incident attached to it
Your artifact
The image, build, or device under question
Your deployment
Update channel, fleet, supplier set
The date
When the answer has to be true by
Authorization
That the target is yours to test

You do not need a sample to start. A named threat and your own artifact is enough to scope.

What we do

Five steps, in this order. Every one of them is tested against your product rather than described in general.

  • Reverse the adversary's artifact ourselves. What it does, how it hides, where it reaches, and what the operator has to already have for it to work. A family name does not tell you any of that.
  • Recover the technique, not the indicator. A hash expires the next time they build. The decision their code abuses is the durable part, and it is the part your product either makes or does not.
  • Hold each technique against what you ship. They abuse an update that trusts its own payload: does yours? They reach a parser before authentication: do you have one there? This is where most of the engagement goes.
  • Prove or disprove reach. Where the path exists we reproduce it and hand you the reproduction. Where it does not, you get the reason it does not, which is the sentence that lets you stop spending on it.
  • Ask whether there is a bug here nobody has reported. Once we are inside your artifact with an adversary's model of it, the next question is free to ask and worth asking. A finding here is yours, found before anyone else was looking.

What you get back

Reach verdict
Per technique, with the reason
Reproductions
Re-runnable by your engineers
Indicators and rules
Against behavior, not the hash
Mitigations
By the class they close
Adversary analysis
Competing hypotheses, stated confidence
What we could not reach
Named, not omitted

Findings land as we get them. A confirmed one arrives with its reproduction, so you can fix before the report exists, and the hand-back ends in a walkthrough with your engineers rather than a PDF over the wall.

First-party, and checkable

Why our research is different from a feed.

We take real firmware apart ourselves. A finding comes from bytes we reversed ourselves, not a list licensed from someone else, and it arrives with the evidence under it, so your analysts can disagree with the reasoning rather than with a score.

Checkable means the evidence travels with the claim. If a finding rests on third-party data, it says so and says which part, and an analysis bundle is sealed under a MANIFEST.sha256, so a download verifies with shasum -a 256 -c and no 2Atomic software in the trust path.

When the research finds a vulnerability

The maintainer hears first. You hear when they have had a fair chance to fix it.

Reversing real software finds real bugs in products we did not write. We report each one to whoever maintains the component, under our own name, and publish on a deadline fixed in advance rather than argued case by case. A vulnerability found in a customer's own product is never published. The whole rule is the research disclosure policy; to report a vulnerability in something we ship, see coordinated disclosure.

Why first-party matters more than it used to

Generated malware is cheap now, which makes a resold feed noisier and first-party ground truth the scarce input.

Our findings come from the artifact itself, taken apart by the engineers who hand it back to you, and each one arrives with the evidence under it. Your analysts can check the reasoning instead of taking a score on trust. Where a finding rests on third-party data, the deliverable says so and says which part.

Related

The engagement next to this one, and what our own researchers publish.

Available

Incident response and forensics

If it already happened, this is the engagement that scopes it, contains it, and hands back a timeline and a root cause.

Incident response →