One Compromised Executive, Two Companies at Risk

It starts as one line in a feed

Our Threat Intel KB pulls ransomware leak-site postings around the clock. This one came through RansomLook, which mirrors what double-extortion groups publish on their own dark web sites. A group calling itself play had listed a company with four days left on its publication deadline. The posting carried the group's own screenshot: victim name, country, how much data they claimed to have taken, and a countdown.

The screenshot does a lot of work. Anyone can argue that a leak-site listing is fake or years out of date. It is much harder to argue with an image of the post itself, captured and timestamped the moment we saw it, in the attackers' own words.

From a name to a person, without touching anything

A leak-site listing gives you a company name. No domain, no infrastructure, no people. For most quick checks that is where the trail goes cold. It is where we start.

We ran passive OSINT against the name alone. No port scans, no probes, nothing aimed at the target's infrastructure.

Underneath it is a layered search pipeline. DuckDuckGo and Startpage by default, Bing as a fallback, and Gemini's search grounding for the queries that need site: or filetype: honored, since the free engines mostly answer those with a CAPTCHA. On top of plain name searches we run targeted dork templates: executive titles, filetype:pdf resumes and CVs, interview and podcast mentions, and LinkedIn patterns like site:linkedin.com/in "name" and "name" linkedin experience.

That last group earns its place. LinkedIn's indexed snippet, the line that shows up in search results as "Name - Title at Company - Location | LinkedIn", is about the most structured description of a working person you can read without ever opening their profile.

The first pass came back with a rough org chart: a handful of named executives, their likely titles, and enough snippet text to place one of them as the company's CTO.

Each card carries a confidence score. This one came back medium, which is the right answer for a profile assembled from a few public snippets rather than a verified document. We would rather publish a number you can argue with.

The detail that turned one victim into two

Opening that CTO's individual profile is where it got interesting.

People-level enrichment does not stop at name, title and social handles. In deep-profile mode it runs a second wave of searches aimed at employment history, hunting the phrasing that profiles and press mentions really use: "joined ... as", "previously at", "formerly of", current-position language. A job title tells you where someone works today. It says nothing about where else they have been, and that second half is where a lot of exposure hides.

What came back was not a clean structured field. It was raw indexed text, as the search engine returned it, with its sources listed beside it so you can check it yourself.

That is on purpose. We could push the snippet through a language model and hand you a tidy sentence instead, but a model asked where somebody works will always produce an answer, and it is never short of confidence.

A second employer sitting in that text is the sort of thing a company-by-company lookup will never show you. It only appears when you correlate people across every company you have profiled, rather than the one you happened to type in.

We pulled the second company name out of the snippet and ran the same passive pass against it.

The second company was already compromised too

It came back with an active compromise indicator of its own. Different evidence, found independently, weeks apart from the leak-site posting: employee credentials and session data for its domain, sitting in infostealer malware logs.

That check runs against Hudson Rock's infostealer data, which indexes the credential and session logs harvested by malware families like RedLine, Raccoon and Vidar before they are traded on criminal markets. Different attack, different feed, separate confirmation. And it landed on a company that had never once appeared beside the first one in any dashboard, report or previous scan.

One executive. Two companies. Two unrelated compromises, surfaced through two unrelated feeds, connected by one thing: the same person sits on both org charts. You do not find that by looking up companies one at a time.

So why does the same person appear twice?

We do not know, and from the outside we cannot know. Nothing in the public evidence explains the connection, and guessing at somebody's motives from two feed entries would be the sort of story we spend most of our time telling people not to believe.

What can be said is structural, and none of it requires knowing anything about the man himself.

Infostealer logs come off a device, not a company. What leaves is whatever the browser on that machine was holding, and a browser does not separate the job somebody left from the job they have now. Access has the same problem in the other direction: credentials granted at one company rarely get reviewed when the person moves on to the next one.

So an executive who sits on two org charts is reachable through both, and one compromised machine can put both in range. Whether that is what happened here, nobody outside those two companies can say.

What is certain is that nobody was in a position to ask. The connection was not visible from either side. Companies get audited, scored and certified. The people inside them move between companies carrying access, devices and habits, and no part of that process checks whether the executive being hired, or the contractor being handed credentials, is already the connecting thread in somebody else's incident.

How we decide a match is real

Correlation is worthless if it only means two names look alike. So, the mechanics behind what you saw above.

• Exact matches first. Anything we act on, flagging a company, marking it covered, sending it toward a scan, runs on exact domain and source_misp_uuid matches. Similarity scoring, the kind that decides "Corrigan Freight LLC" and "Corrigan Freight Inc." are one company, runs only where a human reviews the result first. Trust it blindly at scale and it will cheerfully report that half your vendor list is on fire.
• Evidence grouped by source. A person's security signals, a GitHub handle, a confirmed LinkedIn, a leak-site mention, each keep their own confidence, so you can see which piece of evidence is carrying the argument instead of one averaged number that means very little.
• Every match carries its age. A listing from three years ago reads very differently from one posted last week. Anything older than 30 days says so on its face, with a note to verify before treating it as active. We added that after a client's partner pushed back on a finding of ours, correctly, because the listing turned out to be years old.
• Sources have to agree independently. Leak sites, breach reporting and infostealer feeds arrive through separate pipelines. A finding reads as confirmed when a specific source made a specific claim, never when several vague signals have been stacked until they look convincing.

What happens once we have found it

A finding nobody acts on is trivia. The same record opens into the response path.

• Notify the right people, with evidence. Once we have a verified LinkedIn profile and a confirmed or high-confidence email for the executive, and for the other staff we profiled at both companies, outreach goes out on real contact data instead of a scraped address that bounces.
• Recheck against the KB on demand. Feeds move. Yesterday's unconfirmed listing can be today's confirmed one. A single click re-runs the correlation without waiting for the next scheduled pass.
• A technical report somebody can forward. The leak-site screenshot, the infostealer record count, the OSINT path that joined the two companies, compiled into one document with a narrative, instead of a pile of alerts the recipient has to reassemble into a story.
• Compliance evidence where it counts. For companies under NIS2 and similar frameworks, an active compromise indicator maps into the relevant control catalogue on its own, so the finding arrives as something you can point to.

What happens when you tell someone

There is one way to narrow those explanations down. Tell him, and watch what happens.

That part is harder than the finding, and it has very little to do with how good the evidence is. Stand on the receiving end for a second. A stranger writes to say your credentials are sitting in a criminal dataset. You cannot tell at a glance whether it is real. If it is real, it costs you a week you do not have and a conversation with your board that you would rather not open.

So the instinct is fear, then denial, then damage control, usually in that order and usually fast. Chats get cleared. It is probably nothing, probably old, probably somebody else. Companies hope the listing gets buried under newer news before a customer or a journalist reaches it.

None of that is stupid. It is what people do with bad news that doubles as a judgment on them. But hoping nobody noticed has never been a remediation plan, and the distance between those two things is where the second incident grows.

There is a more practical reason a cold notification gets ignored: people have been trained to ignore them. Security inboxes fill up with unsolicited "your systems are vulnerable" messages from script kiddies who ran an automated scanner once, half of them describing vulnerabilities that do not exist or were patched years ago. From the subject line, a real warning and that noise look identical. A message claiming you have been breached, with nothing behind it, should look suspicious.

So ours carries the receipt. The leak site's own screenshot, the record count and the feed it came from, a source link that resolves to something real. Something the recipient can check in two minutes without ever replying to us. That is the only version of this message with a chance of being read differently from the noise around it.

The reply, when there is one, is the only part of this that anyone can observe from outside. Somebody who asks for the evidence and starts rotating credentials has closed the exposure. Somebody who clears the thread has not, and it stays open, travelling with them to whatever they work on next.

And then there is the part that is not a matter of temperament. Depending on where a company operates and what data it holds, staying quiet stops being an option once an incident is confirmed.

• GDPR gives you 72 hours from becoming aware of a personal-data breach to notify the supervisory authority, and requires telling affected individuals directly where the risk to them is high. Deciding not to mention it is a separate violation from the breach itself.
• NIS2, in force across the EU for essential and important entities, is tighter: early warning within 24 hours, full notification within 72, a final report within a month, all to the national CSIRT or competent authority. The clock starts when somebody becomes aware, not when they feel ready to talk about it.
• US state breach-notification laws, all fifty of them, with different thresholds and deadlines, can require notifying affected residents and sometimes the state attorney general. The variation between states is wide enough that putting it off becomes a legal problem before it becomes a public relations one.
• Public companies in the US also face the SEC's cybersecurity disclosure rule: a material incident goes into an 8-K filing within four business days of the materiality determination. That is a judgment call, and the person currently hoping the problem disappears is the wrong one to be making it.
• Before any regulator is involved, there is what an executive who has just learned his own credentials leaked owes his own board. That conversation only gets harder with age. Finding out in September and mentioning it in December is a second problem on top of the first.

A notification landing on a CTO who is three steps into deciding this never happened is a different conversation when it arrives with a clock that is already running. Which is the practical argument for evidence. It gives somebody standing at that fork something solid enough to walk into legal with today, rather than something vague enough to file away and hope about.

Before it happens again

After the fact is the floor. The same platform that surfaced all this answers the harder question next: given what we now know about this executive and these two companies, what else is exposed, and how bad could it get?

• Vulnerability management and web pentest across both companies' external surface turn "they were compromised" into a ranked list of what is exploitable today: the CVEs, the misconfigurations, the services that should not be listening.

• Ransomware / Threat Attack Simulation takes that vulnerability data and answers the next question. If an attacker used this ransomware family's known techniques, starting from this host, how far would it spread? Pick a scope, pick a variant from Conti, Cl0p, Qilin, LockBit and dozens more, each mapped to its own known CVEs, then pick a patient zero:

  

  Nothing is exploited and nothing is attacked. It is a propagation model computed from CVEs our own scanning already found on that network, which is what keeps it honest: it can only show you a blast radius you were genuinely vulnerable to. Host by host, with a predicted infection path and an impact summary covering affected hosts, scope coverage and critical assets at risk, so that "medium risk" means something more specific than a colour.

• Phishing simulation tests the human half of the same story. If a targeted executive is how the first compromise began, the honest follow-up is whether the same approach would work on your own people this afternoon. A simulated campaign answers that without waiting for a real one to answer it for you.

• Continuous monitoring rather than a one-time check. Every company we have profiled stays under the same standing watch: leak sites, breach reporting, infostealer feeds, botnet and C2 infrastructure, malicious certificates, refreshed on a schedule. The next targeted executive should not get months of head start before anyone notices the second company on his résumé.

Why this matters to you

One name on a leak site is rarely the whole story. The exposure here ran through a person, and people work at more than one company over a career.

Seeing that requires a platform that was already watching before you thought to ask, already correlating names across every company it has profiled, and already holding the evidence by the time the question comes up. Then it requires somewhere to take it: a way to warn the people affected now, credibly enough that the warning does not get filed beside the scanner spam, and a way to find out what else that exposure could reach before it does.

Finding all this took no scanning, no access and nobody's permission. Finding yours would not either.