Skip to main content

Hit by ransomware? Isolate affected systems now. Do not reboot or reformat.

SheMo Noransom舍末无勒

Service

Incident Response

  • Round-the-clock intake: contain first, preserve evidence second, recover third.

Emergency handling while an incident is still spreading or the attacker may still have access: contain the blast radius, remove persistence, preserve evidence, and open a safe window for recovery.

What this service covers

Incident response addresses the case where the incident is not over yet. Many organizations rush straight to recovery after discovering encryption — but if the attacker still holds domain credentials, a remote channel or a scheduled task, restored data tends to get encrypted a second time. Our order is: contain, preserve, then recover.

What the engagement covers

  • Blast-radius assessment across encrypted hosts, shared paths, virtualization platforms and backup systems, including whether lateral movement already reached domain controllers and the backup domain.
  • Containment and isolation: tighter segmentation and access control, disabling compromised accounts, taking down suspicious remote tooling (RDP, VPN accounts, RMM agents), and removing malicious scheduled tasks and services.
  • Evidence preservation: capturing critical logs, memory and disk images before the environment is altered, so that later attribution work and compliance reporting have usable material.
  • Persistence removal and re-check: locating and eliminating backdoors, web shells, newly created accounts and credential-theft tooling, then re-checking before recovery work is allowed to start.
  • Recovery escort: defining a safe recovery order, supporting the data recovery team, and completing baseline hardening and credential rotation before systems go back online.

Limits

Incident response limits the damage and lowers the chance of re-encryption, but it does not by itself mean the data is recoverable — that depends on the family and version, the state of backups, and how badly files were damaged, and it is answered by the recoverability assessment. Likewise, attribution does not always reach a named actor: where logs were wiped or never enabled, we provide reasoned inference from available evidence and label the strength of that evidence in the report. We do not negotiate with attackers and take no part in ransom payment.

Deliverables

  • Response log and incident timeline covering detection, containment, eradication and re-check
  • Affected asset inventory and blast-radius conclusion
  • Containment checklist: accounts disabled, channels closed, artifacts removed
  • Eradication and re-check report for backdoors, web shells, rogue accounts and scheduled tasks
  • Recommended safe recovery order and a pre-go-live checklist
  • Immediate remediation items plus medium-term hardening recommendations

How it works

  1. Intake and rapid triage

    We respond quickly after intake and use a call plus a remote session to establish the incident type, when it was noticed, what has already been done, and whether it is still spreading — then issue containment instructions: isolate without powering off, do not reboot, do not reinstall, pause backup overwrites, keep the note and the logs.

  2. Containment and evidence preservation

    Evidence is fixed before anything is cleaned: memory and disk images from key hosts, firewall and VPN logs, domain controller and backup system logs. In parallel we segment the network, disable compromised credentials and shrink the exposed surface to cut the attacker's live channel.

  3. Root cause analysis and eradication

    The work centres on the entry point: internet-exposed services, weak VPN and RDP credentials, unpatched edge appliances, phishing, supply chain and administration tooling. Once located we remove backdoors, web shells, malicious services and rogue accounts, and rotate every related credential.

  4. Recovery escort and re-verification

    This runs alongside recovery: which core production systems come back first, in which isolated segment they are rebuilt, and in what order access is re-opened. Each restored system is re-checked for residual persistence before it rejoins the production network.

  5. Post-incident review and remediation follow-up

    We deliver the timeline and root-cause conclusion, list the immediate must-fix items and medium-term hardening work, hand over to forensics (for police reporting and compliance) or hardening where needed, and follow up within an agreed interval to confirm remediation actually happened.

When to use it

  • Encryption is still spreading and new hosts keep appearing with ransom notes
  • A domain controller or core management platform looks compromised and servers fell together
  • Unexplained outbound connections, unknown accounts or unfamiliar remote-management agents are running
  • A system you already restored was encrypted again, suggesting the attacker still has access
  • A regulator, head office or customer requires an incident handling account and timeline
  • There is no internal security team and the on-site response needs to be led from outside

Emergency response

Data already encrypted? Stop and let an engineer look first

We do not pay ransoms and we do not negotiate with attackers. Engineers run a free assessment first, then propose a recovery plan and a firm quote.

Related scenarios

Related ransomware families

Related questions

FAQ

Frequently asked questions

  • What is the very first thing to do after discovering encryption?

    Three things, in order:

    1. Isolate. Unplug or switch-isolate the affected hosts, and cut their connections to shared drives, virtualization platforms and backup systems.
    2. Do not touch. No shutdown or reboot, no reinstall, no formatting, no disk repair utilities, and do not delete the ransom note.
    3. Preserve. Keep the original note, encrypted samples, firewall and VPN logs, and pause any automated backup job that might overwrite data.

    Then contact us with when it was noticed, how many hosts are affected, and what has already been done.

  • Are incident response and data recovery the same thing?

    No. Incident response answers whether the attack is ongoing, where it came in and how to stop the bleeding. Data recovery answers whether the data can be retrieved and how.

    They normally run in parallel: recovering without responding invites a second encryption, while responding without recovering leaves the business down. We schedule both under one engagement so they do not interfere with each other.

  • Can this be handled remotely, or is an on-site visit required?

    We provide 24/7 remote response, and most incidents can be contained and handled remotely — usually faster that way. Remote access goes through a controlled channel with an operation log kept as the client requires.

    We send engineers on site when the environment is fully air-gapped, external access is not permitted, physical disks must be imaged locally, or the client wants someone present to work alongside internal procedures. On-site coverage extends nationwide.

  • We keep very few logs — can anything still be determined?

    It depends on what evidence survives. Even with application logs missing, edge-device logs, domain controller security logs, system events, registry and filesystem timelines and leftover tooling artifacts often reconstruct the main links of the attack path.

    Where key evidence really was wiped or overwritten, we say which conclusions are reasoned inference rather than confirmed fact, and label the evidence strength in the report instead of overstating it.

  • Will you communicate or negotiate with the attacker for us?

    No. We do not contact attackers on a client's behalf, do not negotiate, and take no part in ransom payment or cryptocurrency purchase.

    What we do provide is a path that does not depend on the attacker: recoverability assessment, data recovery, backup and business rebuild planning, and the forensic material needed to report the crime to the police.

Updated