That image is dangerously incomplete.

In a modern enterprise attack, encryption is often the last visible event in a chain that may include exploitation of an internet-facing server, identity theft, lateral movement, data exfiltration, backup deletion, and security-tool tampering. By the time the ransom note appears, the attackers may have spent hours, days, or weeks learning how the environment works.

The useful question is not, “How do we detect ransomware?”

It is, “How do we detect the intrusion before ransomware becomes the attacker’s final move?”

As of September 4, 2026, that distinction matters more than ever. Vulnerability exploitation, compromised identities, software supply-chain attacks, voice phishing, remote-management tools, and AI-assisted reconnaissance are giving attackers more ways to enter networks. Ransomware crews are also becoming much better at destroying recovery options before they touch production data.

The good news is that these operations still leave evidence.

Usually quite a lot of it.

Ransomware is the outcome, not the intrusion

A serious ransomware incident rarely begins with encryption software.

It may begin with an unpatched VPN appliance. A stolen session cookie. A compromised developer token. A help-desk employee tricked into resetting multifactor authentication. A malicious package pulled into a build pipeline. An administrator who accidentally exposes a management interface to the internet.

From there, the attack often develops like this:

1. The attacker establishes initial access.

2. They create a persistent way back into the environment.

3. They enumerate users, servers, domains, cloud resources, and backups.

4. They steal or abuse privileged credentials.

5. They move into systems with higher business value.

6. They collect and exfiltrate sensitive data.

7. They weaken endpoint protection and recovery mechanisms.

8. They deploy ransomware or otherwise disrupt operations.

The ransom note is step eight.

That is why an organization can technically “stop the ransomware binary” and still have a major incident. If customer data has already been stolen, domain administrator credentials are exposed, cloud tokens remain valid, and hidden persistence survives, blocking one executable does not solve the underlying compromise.

Microsoft documented a 2026 investigation that initially looked like a conventional ransomware case but turned out to involve two unrelated threat actors operating in the same environment. One actor’s noisy activity helped obscure the quieter activity of the other. The case is a good reminder that responders cannot safely assume every suspicious event belongs to one clean, linear attack chain. (microsoft.com)

The front door has changed

For years, stolen credentials were the most common answer to the question, “How did they get in?”

That is no longer the whole story.

Verizon’s 2026 Data Breach Investigations Report found that vulnerability exploitation accounted for 31 percent of breaches in its dataset, surpassing stolen credentials as the leading entry point for the first time in the report’s 19-year history. The report uses 2025 incident data, but its conclusion is directly relevant to security decisions in 2026. (verizon.com)

This does not mean passwords stopped mattering. Credentials remain central because an exploited server often gives the attacker access to passwords, tokens, keys, certificates, and active sessions.

The more accurate attack chain looks like this:

vulnerable server → initial execution → credential theft → privileged access → data theft → recovery sabotage → ransomware

Patching and identity security are not competing priorities. They protect different stages of the same attack.

Internet-facing systems deserve special attention because attackers can scan them continuously and automatically. A forgotten file-transfer server, development dashboard, VPN gateway, remote-management portal, or on-premises collaboration server may be more useful to an attacker than a carefully crafted phishing email.

The practical problem is speed.

Google’s M-Trends 2026 report found that exploitation was routinely occurring before a patch became available in some investigated cases. The report estimated a mean time to exploit of negative seven days, reflecting the role of zero-day exploitation in the dataset. It also highlighted attackers targeting edge devices such as VPNs and routers, where organizations often lack the endpoint telemetry they have on workstations and servers. (cloud.google.com)

Installing patches faster is necessary, but “patch everything immediately” is not an operational plan. Most organizations have too many assets, dependencies, maintenance restrictions, and incomplete inventories for that advice to be useful on its own.

A more realistic priority order is:

• Known-exploited vulnerabilities on internet-facing assets

• Vulnerabilities allowing unauthenticated code execution

• Identity, remote-access, and administrative systems

• Security, backup, and virtualization infrastructure

• Systems holding credentials, tokens, or sensitive data

• Internal vulnerabilities that enable privilege escalation or lateral movement

• Everything else, based on exposure and business impact

CVSS scores still have value, but they should not make the decision alone. An actively exploited vulnerability on an exposed appliance can be more urgent than a theoretically critical bug buried inside a segmented test environment.

Identity is still where a breach becomes a disaster

Exploitation may open the door. Identity often determines how far the attacker gets.

Attackers want accounts that let them act like trusted users. Even better, they want accounts that can change security policies, access backups, manage cloud applications, alter identity systems, or control hundreds of endpoints.

A valid session can be especially valuable because it may avoid some password and MFA checks. That is why modern social engineering increasingly targets help desks, session cookies, OAuth grants, access tokens, and account-recovery processes.

Google’s M-Trends 2026 report describes a move away from traditional email phishing in many investigated intrusions and toward interactive voice-based social engineering. It also notes attackers harvesting long-lived OAuth tokens and session cookies, then using compromised SaaS providers or embedded secrets to reach downstream environments. (cloud.google.com)

This is where companies sometimes discover that their expensive MFA deployment has a very cheap bypass: calling the help desk.

If a caller can reset a privileged employee’s password, replace their MFA method, or convince support to enroll a new device without strong verification, the authentication technology is not the weak point. The business process is.

Help-desk identity verification needs to be treated as a security control. For sensitive resets, that can mean:

• No approval based only on information found in HR records or social media

• No unsolicited MFA-method changes during an inbound call

• A documented callback through a known corporate number

• Manager approval for privileged accounts

• Delayed activation or additional monitoring after high-risk resets

• Immediate alerts when new authentication methods are registered

• Separate procedures for administrators and executives

Phishing-resistant authentication also deserves priority. Passkeys and hardware security keys are much harder to relay than one-time codes, although account recovery can still undermine them if recovery is weak.

The pre-encryption signals that actually matter

There is no single event that proves ransomware is about to be deployed.

Administrators legitimately use PowerShell. Backup operators delete old snapshots. IT teams deploy remote-management software. Domain administrators create accounts and modify Group Policy.

The signal comes from context, timing, privilege, and combinations of behavior.

One isolated command might be normal. The same command executed across 80 servers by a recently compromised account at 2:13 a.m. is different.

Here are the warning signs I would take seriously.

Sudden identity and privilege changes

Look for:

• New domain, cloud, or local administrator accounts

• Dormant privileged accounts becoming active

• Users added to sensitive groups

• New credentials or MFA methods registered unexpectedly

• Service accounts logging on interactively

• Privileged access from unmanaged devices

• Authentication from unusual networks or locations

• Password resets followed by immediate administrative activity

• New OAuth consent grants or application credentials

• Certificates issued through unusual Active Directory Certificate Services templates

The strongest alerts connect identity changes to endpoint activity.

For example, a privileged account logging in from a new workstation is interesting. That same workstation running domain-enumeration commands, touching multiple servers, and opening remote SMB sessions should be treated as a possible incident.

Enumeration of the environment

Before attackers can cause widespread damage, they need to understand what they compromised.

Common targets of reconnaissance include:

• Domain controllers

• Privileged users and groups

• File servers

• Backup servers

• Hypervisors

• Database servers

• Security-management systems

• Network shares

• Remote sites

• Cloud subscriptions and storage

• Password vaults

• Source-code repositories

Tools such as net, nltest, whoami, dsquery, PowerShell, LDAP utilities, and commercial administration products all have legitimate uses. The behavior becomes suspicious when it appears on the wrong device, under the wrong account, or in an unusual sequence.

A marketing employee’s laptop should not suddenly enumerate domain trusts and administrative groups. A web server should not normally discover every network share in the domain.

Credential dumping and Authentication Abuse

Credential access is one of the most important transitions in an intrusion.

Watch for:

• Attempts to access LSASS memory

• NTDS database access or copying

• Kerberoasting activity

• Unusual volume shadow copies of domain-controller disks

• Registry access involving stored secrets

• Credential-dumping tools or renamed versions of them

• Repeated authentication across many systems

• Pass-the-hash or pass-the-ticket patterns

• Remote logons using accounts that rarely move between machines

Microsoft’s 2026 GPO ransomware case included Active Directory enumeration, Kerberoasting, NTDS dumping, creation of local accounts, and lateral movement before the attacker attempted broad deployment. Those earlier behaviors gave defenders opportunities to intervene before encryption. (microsoft.com)

Unexpected remote-management tools

Attackers do not always need custom malware.

Legitimate remote monitoring and management tools already provide command execution, file transfer, persistence, and remote access. They are signed, trusted by administrators, and sometimes allowed through network controls.

That makes them useful to both IT teams and intruders.

Investigate:

• New RMM agents appearing outside approved deployment systems

• Portable remote-access executables running without installation

• RMM tools installed by ordinary user accounts

• Connections to newly created external management tenants

• Multiple remote tools on one endpoint

• Remote access installed shortly after a suspicious login

• Services with misleading names launching remote-control software

Blocking every remote-management tool is not realistic for many organizations. Maintaining an allowlist of approved products, tenants, hashes, publishers, and deployment paths is much more useful.

Lateral movement that does not fit normal operations

Human-operated ransomware is a network problem.

Attackers may move through RDP, SMB, WinRM, WMI, PsExec, SSH, remote services, stolen cloud sessions, or management platforms. What matters is spotting movement that conflicts with the organization’s normal administrative patterns.

Possible signs include:

• One workstation connecting to many servers over SMB

• Administrative shares accessed by unusual accounts

• RDP sessions originating from user subnets

• PsExec appearing on systems where it is not normally used

• Remote services created across multiple endpoints

• Scheduled tasks created remotely

• The same account authenticating to many hosts in a short period

• East-west traffic from an internet-facing server

• A service account moving between unrelated systems

This is one reason network segmentation matters. It does not magically prevent ransomware, but it limits how many systems a compromised identity can reach and gives defenders additional control points.

Data staging and unusual outbound traffic

Many ransomware groups steal data before encrypting anything.

They do this for leverage. Even if the victim restores every server, the attacker can threaten to publish customer data, internal documents, source code, health information, or employee records.

Watch for:

• Large archives created in temporary directories

• Sudden use of 7z, WinRAR, or similar compression tools on servers

• Large outbound transfers outside business hours

• Rclone, Rsync, FTP, SFTP, or cloud-storage clients appearing unexpectedly

• Cloud tunnels or reverse proxies launched from internal systems

• Database exports by accounts that do not normally perform them

• File access spikes involving sensitive shares

• An endpoint reading far more data than it writes

CISA specifically recommends hunting for unusual outbound data volumes, unexpected RMM software, cloud-tunneling tools, new scheduled tasks, new services, credential dumping, and abnormal endpoint-to-endpoint communication during a suspected ransomware intrusion. (cisa.gov)

Attempts to destroy recovery

This is one of the clearest signs that an intrusion is approaching its destructive phase.

Attackers may:

• Delete volume shadow copies

• Remove backup catalogs

• Disable recovery environments

• Stop backup services

• Delete cloud backup objects

• Change retention policies

• Compromise backup-administration accounts

• Encrypt backup repositories

• Delete virtual machines or snapshots

• Target hypervisor datastores

• Modify boot-recovery settings

MITRE ATT&CK tracks this behavior as T1490, Inhibit System Recovery. Native Windows utilities commonly associated with it include vssadmin.exe, wbadmin.exe, diskshadow.exe, bcdedit.exe, wmic.exe, and reagentc.exe. These tools are not malicious by themselves. The dangerous part is how, where, and when they are used. (attack.mitre.org)

Google’s M-Trends 2026 report describes ransomware operators targeting backup infrastructure, identity services, virtualization-management planes, and cloud backup objects. The objective is no longer limited to encrypting production files. It is to make independent recovery painful or impossible. (cloud.google.com)

That changes how backups should be designed.

A backup that can be deleted by the same identity used to administer production is not a strong ransomware defense. It is another production resource.

Security tampering and log destruction

Attackers often try to reduce visibility before creating maximum impact.

Warning signs include:

• Endpoint protection disabled through policy changes

• Antivirus exclusions added across many systems

• Security services stopped

• Event logs cleared

• Audit policies weakened

• EDR agents uninstalled

• Firewall rules modified

• Logging pipelines interrupted

• Group Policy changed to deploy security exclusions

• Management platforms used to push disabling commands

A single service stop may be troubleshooting. Ten security services stopped across dozens of hosts within five minutes is an incident until proven otherwise.

A practical hunting query for Windows environments

Microsoft Defender XDR exposes endpoint process information through the DeviceProcessEvents table. The following KQL query looks for several recovery-sabotage and log-clearing behaviors that can appear before ransomware deployment.

It is not a magic ransomware detector. It is a starting point for hunting and should be adjusted for legitimate administrative activity in the environment.

kusto

DeviceProcessEvents| where Timestamp > ago(24h)| where    (        FileName =~ "vssadmin.exe"        and ProcessCommandLine has_all ("delete", "shadows")    )    or (        FileName =~ "wbadmin.exe"        and ProcessCommandLine has_any (            "delete catalog",            "delete systemstatebackup",            "disable backup"        )    )    or (        FileName =~ "bcdedit.exe"        and ProcessCommandLine has_any (            "recoveryenabled no",            "bootstatuspolicy ignoreallfailures"        )    )    or (        FileName =~ "fsutil.exe"        and ProcessCommandLine has_all ("usn", "deletejournal")    )    or (        FileName =~ "wevtutil.exe"        and ProcessCommandLine has_any (" cl ", "clear-log")    )    or (        FileName =~ "wmic.exe"        and ProcessCommandLine has_all ("shadowcopy", "delete")    )| project    Timestamp,    DeviceName,    AccountName,    FileName,    ProcessCommandLine,    InitiatingProcessFileName,    InitiatingProcessCommandLine| order by Timestamp desc

Microsoft’s current ransomware-hunting guidance recommends correlating multiple behaviors, including backup deletion, shadow-copy removal, service stopping, process termination, boot modification, and event-log clearing. Multiple signals on the same device within a short period deserve much more attention than one isolated command. (learn.microsoft.com)

A simple correlation layer can help identify those clusters:

kusto

DeviceProcessEvents| where Timestamp > ago(24h)| where FileName in~ (    "vssadmin.exe",    "wbadmin.exe",    "bcdedit.exe",    "fsutil.exe",    "wevtutil.exe",    "wmic.exe",    "sc.exe",    "net.exe",    "net1.exe",    "taskkill.exe")| summarize    ToolCount = dcount(FileName),    EventCount = count(),    Tools = make_set(FileName),    Commands = make_set(ProcessCommandLine, 50)    by DeviceId, DeviceName, bin(Timestamp, 5m)| where ToolCount >= 3 or EventCount >= 10| order by Timestamp desc

Do not immediately isolate a production server because it crossed an arbitrary threshold. First establish whether the activity came from an approved backup process, software deployment, maintenance window, or recovery test.

But do not spend three hours debating it in Slack either.

High-privilege recovery sabotage, especially when combined with lateral movement or security tampering, requires immediate investigation.

Group Policy can turn one compromise into hundreds

Group Policy is powerful because it lets administrators control many Windows devices centrally.

That is also why attackers want it.

With sufficient privileges, an attacker can use Group Policy Objects to:

• Create scheduled tasks

• Run scripts

• Change registry settings

• Disable security features

• Add firewall exceptions

• Distribute executables

• Alter local group membership

• Launch ransomware across many domain-joined machines

In Microsoft’s March 2026 case study, the attacker attempted to use GPOs to tamper with security controls and distribute ransomware through scheduled tasks. Microsoft reported that its automated defensive controls detected the preparation and hardened hundreds of devices before the GPO deployment path could encrypt them. (microsoft.com)

The important lesson is not that every organization needs one specific Microsoft feature.

The lesson is that changes to centralized administrative mechanisms should receive centralized monitoring.

Security teams should alert on:

• GPO creation by unusual accounts

• GPO changes outside approved windows

• New scripts placed in SYSVOL

• Scheduled tasks distributed through policy

• Security exclusions introduced through policy

• GPOs linked to large or sensitive organizational units

• Administrative templates changed shortly after credential alerts

The same principle applies outside Active Directory. Watch Kubernetes operators, endpoint-management platforms, cloud automation, configuration-management tools, mobile-device-management systems, and orchestration services.

Anything that can legitimately change 1,000 machines can maliciously change 1,000 machines.

The software supply chain is now an initial-access system

Developers need to stop treating package security as a theoretical application-security concern.

A compromised dependency can be an identity attack.

Malicious install scripts and build-time code can search for:

• Package-registry tokens

• Cloud credentials

• SSH keys

• CI/CD secrets

• GitHub tokens

• Environment variables

• Signing keys

• Deployment credentials

• Internal service endpoints

Once those secrets leave the build environment, the attacker may be able to move into source repositories, cloud accounts, container registries, production systems, or downstream customer environments.

In July 2026, Google Threat Intelligence Group reported growing large-scale attacks against open-source repositories and developer tooling. It described campaigns targeting PyPI, npm, and Docker Hub, including abuse of GitHub Actions configurations to obtain repository secrets and write permissions. Google also warned that attackers were using stolen credentials from software-supply-chain compromises for direct monetization or partnerships with extortion and ransomware groups. (cloud.google.com)

The defensive answer is not “never use dependencies.” Modern software development does not work that way.

The useful controls are less dramatic:

• Pin dependency versions

• Commit and review lockfiles

• Require review for dependency updates

• Restrict package publication permissions

• Use short-lived CI/CD credentials

• Separate build credentials from production credentials

• Disable unnecessary package install scripts

• Scan packages before internal promotion

• Use an internal registry or controlled package proxy

• Record build provenance

• Protect maintainer and publisher accounts with phishing-resistant MFA

• Avoid exposing secrets to untrusted pull-request workflows

• Monitor for unexpected outbound connections during builds

GitHub Actions configurations deserve special care. Workflows triggered through pull_request_target can run with access to the base repository’s context and potentially sensitive permissions. Combining that trigger with checkout or execution of untrusted contributor code can create a direct path to repository secrets.

A CI runner should be treated like a privileged production system, not a disposable laptop that happens to compile code.

AI is accelerating attacks, but it is not magic

Cybersecurity discussions about AI tend to fall into two bad extremes.

One side acts as if AI has changed nothing. The other talks as if fully autonomous digital supervillains are already breaking into every network on Earth.

The current reality is more practical.

AI can help attackers:

• Research targets faster

• Generate convincing social-engineering content

• Translate and localize scams

• Analyze source code

• Find suspicious logic and security mistakes

• Modify scripts and malware

• Produce decoy code

• Summarize stolen documentation

• Automate parts of reconnaissance

• Scale operations that previously required more human labor

Google Threat Intelligence Group reported in May 2026 that it had identified a criminal threat actor using what Google assessed with high confidence was an AI-assisted zero-day exploit. The vulnerability involved a semantic logic flaw in two-factor authentication rather than a conventional memory-safety bug. Google also reported experimentation with AI-assisted malware development, obfuscation, and more autonomous command execution. (cloud.google.com)

That is significant, but it does not mean attackers can press a button and compromise any target.

AI still needs access, context, infrastructure, operational security, and a vulnerable environment. It makes capable attackers faster and helps less-skilled actors automate certain tasks. It does not eliminate the need for conventional intrusion techniques.

The defensive implication is straightforward: organizations need to reduce the amount of time an exposed weakness remains usable.

That means faster asset discovery, better prioritization, automated containment, stronger identity controls, and detections built around behavior rather than one known malware hash.

What I would prioritize before buying another security product

Most organizations already have more security tools than they can operate properly.

Adding another dashboard does not fix missing endpoint coverage, unmonitored appliances, permanent administrative accounts, or backups controlled by production credentials.

My priority list would look like this.

Know what is exposed

Maintain a continuously updated inventory of internet-facing systems.

Do not rely only on a spreadsheet. Compare internal records with external discovery. Track the owner, software version, authentication method, data sensitivity, and business purpose of each exposed service.

If nobody owns an internet-facing system, it should not be internet-facing.

Separate privileged identities

Administrators should not browse the web, read email, and manage domain controllers with the same account.

Use separate privileged accounts, just-in-time access where possible, managed administrative workstations, and strong authentication. Closely monitor accounts that can control identity, backups, endpoint security, virtualization, or cloud policy.

Protect the systems that make recovery possible

Backup servers, hypervisors, domain controllers, identity providers, and management planes are not secondary infrastructure.

They are primary ransomware targets.

Use separate administrative credentials, network restrictions, immutable storage where appropriate, offline copies, protected retention settings, and alerts for backup-policy changes.

Then perform real recovery tests.

A green “backup completed” notification only proves that something was written. It does not prove the organization can rebuild its critical services under pressure.

CISA recommends offline, encrypted backups, regularly tested restoration procedures, golden system images, and protected infrastructure-as-code templates for rebuilding cloud resources. (cisa.gov)

Centralize the evidence

Collect and retain telemetry from:

• Endpoints

• Domain controllers

• Identity providers

• VPNs

• Firewalls

• Cloud control planes

• SaaS applications

• Backup platforms

• Hypervisors

• CI/CD systems

• Source repositories

• Network appliances

• DNS and proxy services

Edge devices are particularly important because attackers know they may lack conventional EDR coverage. If a VPN gateway or router cannot run an endpoint agent, its authentication, configuration, flow, and administrative logs need to go somewhere defenders can search them.

Detect combinations, not isolated commands

Alert fatigue grows when every administrative tool is treated as malware.

Better detections connect events:

• Suspicious login followed by privilege escalation

• Privilege escalation followed by remote execution

• Remote execution followed by security tampering

• Security tampering followed by backup deletion

• Archive creation followed by unusual outbound traffic

• GPO modification followed by scheduled-task creation

That sequence tells a story.

Security teams should build detections around attack progression, not just indicators of compromise published after someone else has already been hit.

What to do when the warning signs appear

Suppose the security team sees a domain administrator account logging into several servers, new scheduled tasks, unexpected RMM software, and commands deleting shadow copies.

Do not wait for encrypted files.

Start incident response.

The initial actions should include:

1. Confirm the affected identities, endpoints, servers, and cloud resources.

2. Isolate compromised systems using EDR or network controls.

3. Disable or restrict exposed accounts and revoke active sessions.

4. Protect backup, identity, security-management, and virtualization systems.

5. Block confirmed attacker infrastructure and unauthorized remote tools.

6. Preserve volatile evidence and relevant logs.

7. Hunt for the initial access point and alternate persistence.

8. Check for data staging and exfiltration.

9. Move coordination to a trusted out-of-band channel if communications may be monitored.

10. Begin recovery only after understanding how the attacker maintained access.

Do not assume resetting one password removes the attacker. They may have created new accounts, added authentication methods, stolen tokens, installed remote tools, issued certificates, modified federation settings, or compromised a second administrator.

CISA also warns that attackers may monitor organizational communications after compromise. Poorly coordinated containment can cause them to accelerate lateral movement or deploy ransomware before defenders finish isolating the environment. (cisa.gov)

Containment should be fast, but it cannot be random.

Ordinary users are part of this story too

Enterprise ransomware sounds like a problem for security teams, but ordinary users are often affected twice.

First, their account may be targeted for initial access.

Then their personal information may be exposed when the organization is breached.

A few practices make a real difference:

• Use a password manager and unique passwords

• Prefer passkeys or security keys when available

• Never approve an unexpected MFA prompt

• Verify urgent requests through a separate communication channel

• Be suspicious of callers asking you to install remote-access software

• Keep computers, phones, browsers, and routers updated

• Maintain a backup that is not permanently connected to the computer

• Treat session cookies and account-recovery methods as sensitive credentials

• Report suspicious activity quickly instead of quietly deleting it

The last point matters.

People sometimes hide mistakes because they are embarrassed. Attackers depend on that hesitation. Reporting a suspicious approval or downloaded file within two minutes can turn a serious intrusion into a manageable investigation.

The real cybersecurity trend is compression

The biggest change in the current threat landscape is not one malware family, one hacking group, or one AI model.

It is compression.

The time between discovering a vulnerability and exploiting it is shrinking. The time between initial access and resale is shrinking. The time between credential theft and lateral movement is shrinking. The time defenders have to distinguish an odd event from an active intrusion is shrinking.

Google reported that the median handoff time between an initial-access actor and a secondary threat group in its investigations fell from more than eight hours in 2022 to 22 seconds in 2025. In some cases, the first actor had already prepared malware or tunnels for the next group. (cloud.google.com)

That number changes how I think about ransomware defense.

A daily report is too slow for some attack paths. A weekly vulnerability meeting is too slow for an exploited edge device. An approval process that takes three days to isolate a server is not an incident-response process.

Automation will be necessary, but it needs guardrails. Security systems should be able to temporarily restrict a suspicious identity, isolate an endpoint, block a malicious hash, or protect likely exposed credentials without waiting for encryption to begin.

The goal is not to automate every decision.

The goal is to prevent one compromised account or server from becoming an organization-wide outage while humans investigate.

Ransomware remains dangerous, but the encryption stage is not invisible or inevitable. Attackers have to acquire access, understand the environment, gain authority, reach valuable systems, steal data, weaken recovery, and prepare deployment.

Every one of those actions creates an opportunity to catch them.

The organizations that handle ransomware well will not necessarily be the ones with the largest security budgets. They will be the ones that know what they expose, protect their administrative systems, collect usable evidence, rehearse containment, and react to the attack before the ransom note makes the situation obvious.

Andriy Kovalenko

Sources

1. Verizon: Vulnerability exploitation tops breach entry points in the 2026 DBIR

2. Google Cloud: M-Trends 2026

3. Google Threat Intelligence Group: AI-assisted vulnerability exploitation and initial access

4. Google Threat Intelligence Group: Mitigation guidance for software supply-chain compromise

5. Microsoft: GPO-based ransomware stopped before deployment

6. Microsoft: Two threat actors discovered inside one compromised environment

7. Microsoft Learn: Advanced hunting for ransomware activity

8. CISA: StopRansomware Guide

9. MITRE ATT&CK: Inhibit System Recovery, T1490