#NSBCS.133 - Who Did It? The Cost of Getting Ransomware Attribution Wrong

 

Whodunit is the wrong first question

Your window gets smashed and your stuff's gone. The first thing you want isn't the list of what's missing, it's who did it. That's a strange thing to want first, because the name doesn't get your telly back.

And you don't have the name. You've got a smashed window and a rough idea of when. Your neighbour's already settled on "gotta be that dodgy group from three streets over," the insurance form wants a name in a box, and standing there saying "no idea, could be anyone" feels stupid. So a name gets written down. It might be the right one, or it might just be the one that was going round.

Most ransomware attribution works like that.

The price of the correct answer

Start with a case someone got right, because it shows the price of right. Last week Symantec published a teardown of GodDamn, a ransomware strain that turned up in late May looking like a new face. It isn't. It's the same developer's third go: Monster in 2022, Beast in 2024, GodDamn now, one operator Symantec tracks as Hyadina, each launched clean enough to pass as a newcomer.

What let them say so wasn't a confession or a note reading "same as before." It was habits. The same NirSoft credential-stealing kit turned up across all three. The same remote-access tool, AnyDesk, was staged in the same odd folders. The same network scanner appeared each time. Put that on top of overlapping code and the attribution holds.

Notice how much had to line up. GodDamn is the good outcome, with matching code, a repeated toolkit, and years of old samples to check against. Most of what crosses the desk arrives with none of it: a ransom note, a leak site, and a lot less to go on.

Thinner than it reads

"Who did this" usually rests on a ransom note phrased like the last one and a leak site with a familiar layout. Groups copy each other's playbooks, they rebrand the week after a takedown, and they get rebuilt from the ex-members of an outfit that supposedly folded last spring. Strip out the code overlap and the repeat toolkit that made the GodDamn call defensible, and telling "same crew" from "crew that read the same forum post" is hard even for people who do nothing else.

The name goes in the report anyway because someone needed one.. for the board, the organisation, or whoever's writing the press line. "We can't say for certain" doesn't fit neatly within the commercial pressures of Incident Response; it reads like unfinished homework, even when it's the honest answer and the most defensible one.

Everything downstream runs on it

Above the room, everything acts on the name as if it's solid.

Whether you can pay is one of the sharpest version of this. If the group is under sanctions, paying them can put you on the wrong side of the law regardless of intent, so "who is this" decides whether paying is even legal. And if you do pay, the whole bet rests on the crew's track record: some groups don't publish the data and hand over a working key, others may take the money and leak anyway. That reputation is attached to a specific name. Get the name wrong and you've paid on someone else's record. Disclosure runs on it too, since what you're obligated to report, and to whom, can turn on who the actor is.

There's a catch that cuts the other way. The name is also something the group is trying to build, not just something you consume. Ransomware is a business, and the reputation is the asset it runs on: "pay us and we actually delete" only works if victims can look up who "us" is. Every confident public naming feeds that. The rebrand cycle you saw with GodDamn is the same asset being managed, a name shed when it draws too much heat and a fresh one minted to reset. Broadcasting attribution has a cost, then, even when you need the name to make those calls.

The cleanup is the one layer that has to absorb a wrong guess, because it's where the actual work of undoing the mess happens. Everything stacked above it just acts on the name and builds on top.

Saying the gap out aloud

The honest answer isn't "we don't know." It's a fuller sentence: here's what we've got, here's what's missing & why, and here's where that leaves your options.

You lay out what actually holds and you're straight about the gap: no code overlap yet, nothing that separates this crew from one that read the same forum post. Then you carry it into the decisions that are actually live. If the ID is right, paying may be off the table on sanctions grounds; if it's this other crew, the track record says data usually doesn't get published for X days, but you can't tell them which yet. Here's what would settle it: a matching sample, infrastructure reuse, a linked wallet or software. Until anything like that turns up, the organisation is choosing under uncertainty, and the job is to make sure they know that rather than to hide it behind a name.

That reads as more rigorous than a confident name, not less, because it shows the work and tells the organisation what the work does and doesn't let them decide. The confident name is where the unfinished homework actually hides: it looks finished, and it quietly makes a choice for someone who never got told it was a guess.

Some cases don't close clean, and the job is not to fake one that does. Showing the organisation exactly what holds, what's missing, and what it leaves them free to decide is the harder call than handing over a confident name, but it's the one that keeps them moving forward with their eyes open, ensuring there are #NoStepsBackward.


Article Reference


What we read this week

  • Global CMS exploitation campaign hits Australian SMBs. The Australian Signals Directorate's Cyber Security Centre has issued an alert over a large-scale exploitation campaign targeting vulnerable content management systems and plugins worldwide, warning that many small and medium-sized Australian businesses have already been affected. Attackers are scanning for known CMS vulnerabilities and deploying webshells to gain persistent access, allowing them to steal credentials, disrupt services and move deeper into compromised networks. Organisations running self-hosted CMS platforms should prioritise patching and review server logs for signs of webshell activity.

  • Lifeline Australia confirms staff data breach. The crisis support charity has confirmed it was the victim of a data breach after threat actor "2019" posted a claim to a dark web forum on 11 July, alleging more than 10,600 records were taken, including staff and volunteer names, dates of birth, workplace email addresses and phone numbers. Lifeline says no help-seeker or financial data was compromised, and that some of the leaked data appears to have been doctored with falsified information. The same actor has been linked to around 40 targets since January, at least 25 of them Australian, underscoring that not-for-profits remain firmly in scope for opportunistic threat actors.

  • DragonForce claims breach of WA equipment hire firm. The prolific DragonForce ransomware-as-a-service gang has listed Access Group International, a Canning Vale-based provider of material handling, access and construction equipment, on its dark web leak site, claiming to have exfiltrated 42.12 gigabytes of data. Shared samples reportedly include credit applications, tax invoices and account and contract details. It's the latest in a long run of Australian DragonForce victims, with the group now claiming close to 600 targets globally.

  • Microsoft's July Patch Tuesday breaks records. Local commentary has flagged this month's Microsoft security release as its largest yet, covering 622 CVEs - more than triple June's total. Two flaws are already being exploited in the wild: a SharePoint Server privilege escalation bug and one affecting Active Directory Federation Services, both allowing attackers to escalate privileges within identity and document infrastructure widely used by Australian organisations.


Next
Next

#NSBCS.132 - The Password's Long Goodbye: Why 1 July Quietly Changed Authentication in Australia