Skip to content
English
Contact us
  • There are no suggestions because the search field is empty.

Ransomware Family Detected [CHK-3030]

This ticket is opened when Microsoft Defender identifies a known ransomware family in your environment. Attic MDR treats this as one of the most urgent findings we raise. The affected device, the family named by Defender and the actions Attic has already taken are written into the ticket by the MDR pipeline.

Rationale

Ransomware is the end of an intrusion, not the beginning of one. By the time an encryptor is deployed, an attacker has usually been inside the environment for days or weeks: gaining access, stealing credentials, mapping the network, identifying backups, and exfiltrating data to use as leverage. The encryption is the last step, executed once everything else is in place.

That sequence is what makes this detection so time-critical. If the encryptor has been caught before it ran everywhere, you are somewhere in the middle of an operation that is still ongoing, and there is a window to stop it. Attackers deploy across the estate deliberately and often out of hours, so the difference between responding in minutes and responding in the morning is frequently the difference between one device and all of them.

It also means that removing the file is nowhere near sufficient. The access that delivered it still exists. Most modern ransomware operations steal data before encrypting, so a successful cleanup of the encryptor does not resolve the data theft that preceded it: that part is already done and carries its own notification obligations.

Follow-up

Treat this as an active incident. Follow these steps immediately:

  1. Isolate the affected device or devices in Microsoft Defender. Do not power them off: isolation preserves memory and forensic evidence that a shutdown destroys, and encryption keys are occasionally recoverable from memory.
  2. Escalate to IR now. Contact Attic for incident response support before beginning cleanup. Ransomware response involves decisions (about scope, containment, notification and recovery) that are much harder to make well under time pressure and alone. This is the single most important step on this list.
  3. Establish the scope before it grows:
    1. Check whether other devices show the same family or related activity.
    2. Identify the account used to deploy it, and disable it along with any other account it can reach.
    3. Look for the deployment mechanism (group policy, a scheduled task, a management tool, PsExec), because that is what will reach the rest of the estate.
  4. Protect the backups. Verify that backups exist, are recent, and are offline or immutable. Attackers target backups deliberately, and often before deploying the encryptor. Do not connect a backup system to the affected network to check.
  5. Assume data was stolen. Review outbound transfers in the days before the detection, particularly large uploads to cloud storage or unfamiliar destinations. Data theft carries GDPR notification obligations independently of whether encryption succeeded.
  6. Do not pay, and do not communicate with the attacker, before taking advice. Both are decisions with legal and practical consequences that should be made with your IR team and legal counsel.
  7. Rebuild affected systems from known-good media. Do not restore a cleaned system to production on the basis that the detected file was removed.

More information