skip to content

Two intrusions at a bank share one exploited VPN appliance foothold - do you keep them in one activity cluster?

level: seniorimportance: should knowfreq 41%

answer

  1. where in the intrusion does the overlap sit?
  2. who else could buy this foothold?
  3. all the similarity is at the front door
  4. post-access behaviour diverges completely
  5. split, but record the relationship

basics

~10 s

No. Access to an internet-facing appliance is a commodity that gets sold and resold, so overlap confined to the front door links a supplier, not an operator. Split on the divergent post-access tradecraft.

solid answer

~50 s

The whole overlap here sits at the access stage: the same appliance exploit, the same account the exploit created, a reseller's hosting space and a default TLS fingerprint. Every one of those is available to anyone who buys the foothold, and initial-access brokers sell the same foothold more than once. After access the cases diverge completely - one drops a coin miner on build servers and never touches credentials, the other requests Kerberos tickets and archives loan-origination shares. Different objectives, different tooling, no shared hands-on tradecraft. I split them into two clusters, keep a documented non-identity relationship ("both entered through access created by the same broker activity"), and consider tracking the broker's access-creation behaviour as a third cluster in its own right. The split gets written up with the evidence that originally justified the merge, so the reasoning survives.

code

json · 14 lines
json
[
  { "case": "IR-2411", "first_activity": "2026-01-09",
    "initial_access": "exploit of internet-facing VPN appliance; local account 'svc-mon' added",
    "c2_hosting": "low-cost VPS reseller, same address space as IR-2508",
    "c2_ja3": "matches IR-2508 (fingerprint of an unmodified Go TLS client)",
    "post_access": "XMRig miner on 3 build servers; no credential access observed",
    "objective": "compute" },
  { "case": "IR-2508", "first_activity": "2026-02-27",
    "initial_access": "interactive logon as 'svc-mon' on the same appliance; no exploit attempt observed",
    "c2_hosting": "low-cost VPS reseller, same address space as IR-2411",
    "c2_ja3": "matches IR-2411 (fingerprint of an unmodified Go TLS client)",
    "post_access": "Kerberos ticket requests; loan-origination file shares archived",
    "objective": "data theft" }
]

go deeper

for a junior

Know that criminals buy and sell access to already-compromised networks, so two intrusions entering the same way are not automatically the same people.

for a middle

Be able to walk the overlap stage by stage and say which shared elements are purchasable - the exploit, the account, the hosting, the library fingerprint - and which would be exclusive.

for a senior

Show the whole split: two clusters, a documented non-identity relationship, a possible third cluster for the broker, the preserved merge record, and a re-check of everything derived from the merged picture.

for a principal

Own the consequence for the consumers of your reporting: composite clusters transfer the intent of the worst intrusion onto the least serious one, and executives make risk decisions on that story.

## Read the overlap by stage The first move is to ask *where in the intrusion the shared evidence sits*. Overlap at the initial-access stage is the weakest place to merge, because access to an internet-facing appliance is a product. Initial-access brokers exploit a vulnerable edge device (exploitation of a public-facing application is catalogued as `T1190`), create or steal an account, and then sell that foothold - sometimes more than once, sometimes to buyers with nothing else in common. So in this case the shared elements decompose into: - **The appliance exploit** - a widely deployed model, and in a sector where the same appliance is the front door for everybody. - **The account the exploit created** - created once by the broker, used later by whoever bought it. The second intrusion never even attempted the exploit; it simply logged in. - **The hosting address space** - a low-cost VPS reseller, shared by thousands of unrelated tenants. - **The TLS client fingerprint** - a hash over ClientHello fields, identical for anything built on the same unmodified TLS library. Not one of those is exclusive to a single operator. Together they describe a *supply relationship*, not a crew. ## What the divergence tells you After access, the two cases share nothing: | | First case | Second case | |---|---|---| | Post-access activity | miner deployed on build servers | Kerberos ticket requests, share enumeration | | Credential access | none observed | central to the intrusion | | Data movement | none | loan-origination files archived | | Objective | compute | data theft | Hands-on-keyboard behaviour is where operator identity actually shows, because it is the part an operator cannot buy off the shelf. Complete divergence there, with all the similarity at the front door, is the signature of resold access. ## How to split properly Splitting is not deleting. Do it as bookkeeping that a future analyst can follow: 1. **Create two clusters, not one plus a remainder.** Each gets the cases whose post-access evidence hangs together, and each records the observables that hold it together. 2. **Record the relationship without asserting identity.** "Both used access created by the same broker activity" is an accurate, defensible statement; "related to" with no basis is not. 3. **Consider a third cluster for the broker.** The exploitation and account-creation behaviour is itself consistent activity worth tracking - and it is the part that predicts the *next* victim, because the same appliance model is everyone's front door. 4. **Preserve the original merge record.** Keep what evidence justified the merge, when and by whom. That record is the reason the split can be defended rather than looking like a change of mind. 5. **Re-check anything derived from the merged view.** Hunts, blocklists and briefings built on "one crew doing both" need revisiting; the individual indicators usually survive, the story does not. ## What would have kept them merged A single post-access overlap that others could not have would flip the decision: the same private loader with the same embedded key in both, an identical unusual staging path, the same operator typo in a command, a certificate reused on second-stage infrastructure. One exclusive artefact after access outweighs four commodity ones at the door. ## The generalisation worth stating Shared *services* - brokered access, bulletproof hosting, a crimeware panel, an affiliate programme, a public exploit - create overlap between unrelated operators by design. The modern criminal ecosystem is specialised, so several parties routinely touch one victim. A clustering method that does not account for that will keep manufacturing composite crews that never existed, and will attach the intent of the worst intrusion to the operators of the least serious one. ## And the claim you still do not make Even the split clusters are activity, not people. The right output is two internally named clusters, a documented supply relationship, and no assertion about who anyone is.

  • What single piece of evidence would have kept the two cases merged?
    One exclusive artefact after the access stage: the same non-public loader with an identical embedded key, a certificate reused on second-stage infrastructure, or an unmistakable operator habit such as the same staging path and archive naming in both. Exclusivity after access outweighs any amount of similarity at the front door, because that is the part an operator cannot buy.
  • Is the broker's own activity worth tracking as a cluster?
    Yes, and it is often the most operationally useful of the three. Access creation is consistent, repeated behaviour - the same appliance model, the same account-naming habit, the same timing - and it predicts the next victim rather than explaining the last one. It also gives you a clean way to describe the relationship between the downstream clusters without implying they are the same people.
  • How do you avoid this class of error in the first place?
    Weight overlap by stage and exclusivity: require at least one non-commodity overlap in post-access behaviour before merging, and treat access-stage similarity as a lead only. Ask explicitly of every candidate merge whether the shared element is something purchasable. In an ecosystem where access, hosting and tooling are all sold as services, that question catches most composite clusters before they form.

saying these in an interview costs you the question

  • Merges because the same vulnerability was exploited twice
  • Ignores that footholds are sold more than once
  • Deletes the merged cluster with no record of why it existed
  • Assumes divergent objectives just mean a change of goals
  • Attaches the data-theft intent to the miner intrusion

context

resolving links…