Beyond Encryption: How Blue Teams Detect Ransomware Before the Damage Is Done

When people think about ransomware, they usually picture encrypted files, inaccessible systems, and a ransom note appearing on the screen. However, effective ransomware detection begins much earlier.

Before attackers deploy ransomware, they often spend hours—or even days—exploring the environment, stealing credentials, escalating privileges, moving between systems, and disabling security controls. Every one of these actions can leave traces in endpoint, identity, network, and security logs.

For Blue Teams and Security Operations Centers, the objective is not simply to detect file encryption. The real goal is to recognize attacker behavior early enough to contain the incident before critical systems are affected.

Why Ransomware Detection Must Begin Before Encryption

One of the biggest misconceptions surrounding ransomware is that the attack begins when files start being encrypted.

In reality, encryption is usually the final stage of a much larger intrusion. By that point, the attacker may already have administrative access, compromised multiple accounts, identified valuable systems, and prepared the environment for widespread impact.

A typical ransomware attack may involve:

• Initial access through phishing, exposed services, or compromised credentials
• Internal reconnaissance and system discovery
• Privilege escalation
• Credential theft and account abuse
• Lateral movement across the network
• Disabling security tools and recovery mechanisms
• Data exfiltration
• File encryption and ransom deployment

Each stage creates opportunities for early ransomware detection.

Blue Teams that monitor the complete attack lifecycle have a much greater chance of stopping the threat before the final payload is executed.

Behavioral Indicators of Ransomware Activity

Traditional indicators of compromise, such as malicious file hashes, domains, and IP addresses, remain useful. However, sophisticated attackers frequently change their infrastructure and tools.

For this reason, modern ransomware detection increasingly focuses on attacker behavior.

Behavioral indicators can reveal what an attacker is attempting to accomplish, even when the specific malware family has never been observed before.

Suspicious PowerShell Execution

PowerShell is a legitimate administration tool, but it is also frequently abused by attackers.

Suspicious activity may include:

• Encoded PowerShell commands
• Obfuscated command-line arguments
• PowerShell launched by an unusual parent process
• Downloads from external locations
• PowerShell establishing unexpected network connections
• Attempts to bypass execution policies
• Script execution from temporary directories

A single PowerShell event may not confirm an attack. However, when combined with other suspicious activity, it can become an important ransomware detection signal.

This is important because PowerShell itself is not the ransomware indicator. The value comes from understanding what PowerShell is doing, who launched it, where it was executed, and what happened immediately before and after it.

For example, PowerShell activity becomes significantly more suspicious when it is associated with a privileged account, followed by remote execution, security-tool tampering, or recovery deletion.

This pattern has also been observed in real ransomware operations.

Black Basta affiliates have been documented using PowerShell to disable antivirus products before moving toward encryption. Ryuk operators have used PowerShell-based tools for credential theft and lateral movement, while LockBit 2.0 cases have included Base64-encoded PowerShell scripts and PowerShell-based Group Policy activity.

Credential Access and Account Abuse

Many ransomware operators use valid credentials to move through an environment. This allows them to appear more like legitimate administrators and avoid some traditional security controls.

Blue Teams should investigate activity such as:

• Repeated authentication failures followed by a successful login
• Privileged accounts logging in from unusual workstations
• Accounts accessing systems they do not normally use
• Authentication outside normal working hours
• Sudden use of inactive or rarely used accounts
• Multiple systems accessed by the same account within a short period

Identity and authentication logs are therefore essential data sources for ransomware detection.

Lateral Movement

After gaining access to one system, attackers often attempt to reach additional endpoints, servers, domain controllers, and backup infrastructure.

Common lateral movement indicators include:

• Remote service creation
• PsExec activity
• Windows Management Instrumentation commands
• Remote PowerShell sessions
• Administrative share access
• Unusual Remote Desktop Protocol connections
• Scheduled tasks created on remote systems
• A single account connecting to many endpoints

Detecting lateral movement can provide defenders with one of the strongest opportunities to contain an attack before encryption spreads across the organization.

For example, Microsoft has documented Black Basta activity in which attackers used PsExec to deploy the ransomware throughout the network.

Attempts to Disable Security Controls

Attackers often attempt to weaken the environment before deploying ransomware.

This may involve:

• Disabling antivirus or endpoint protection
• Stopping security services
• Modifying firewall rules
• Clearing Windows event logs
• Excluding directories from security scanning
• Disabling monitoring agents
• Tampering with backup services

These actions are particularly important because they indicate that an attacker may be preparing for a disruptive operation.

Black Basta is a strong real-world example. CISA and its partners documented the use of PowerShell to disable antivirus products, as well as the use of a tool called Backstab to disable EDR tooling.

Attempts to Remove Recovery Options

Ransomware operators understand that reliable backups reduce the pressure on victims to pay a ransom. As a result, they frequently attempt to delete shadow copies and disable recovery mechanisms.

Commands involving the following utilities should receive immediate attention:

• vssadmin
• wmic shadowcopy
• bcdedit
• wbadmin
• PowerShell commands that modify or delete recovery data

For example, shadow copy deletion combined with suspicious PowerShell execution and privileged account activity should be treated as a high-priority ransomware detection scenario.

This is not just a theoretical detection pattern. CISA has documented Black Basta affiliates using vssadmin.exe to delete shadow copies before encryption. Ryuk operators have also been observed attempting to delete backups and Volume Shadow Copies.

Mass File Modifications

Large-scale file activity may indicate that encryption has started or is about to begin.

Potential indicators include:

• Hundreds of files modified within a short period
• Rapid file renaming
• New or unusual file extensions
• Increased write activity across shared directories
• One endpoint modifying files on multiple network shares
• Ransom notes appearing in several folders

Although this behavior may occur late in the attack lifecycle, rapid detection can still help limit the impact.

Real-World Ransomware: PowerShell Is Only One Piece of the Attack

Real ransomware incidents demonstrate why defenders should avoid building detections around a single tool.

Black Basta

Black Basta provides a clear example of how multiple behaviors can form one ransomware attack chain.

According to CISA and the FBI, Black Basta affiliates have used credential scraping tools such as Mimikatz, exploited vulnerabilities for privilege escalation, used PowerShell to disable antivirus products, used RClone for data exfiltration, deleted Volume Shadow Copies using vssadmin.exe, and ultimately encrypted files. CISA also documented the use of PsExec for remote execution.

This means a SOC could potentially observe a sequence such as:

Credential Access → Privilege Escalation → PowerShell → Security Tool Tampering → Remote Execution → Shadow Copy Deletion → Encryption

The important detection opportunity is not necessarily the final encryption event.

A stronger detection strategy is to connect several weaker signals and identify when they form a ransomware pattern.

Microsoft has also documented Black Basta activity in which Storm-1811 used social engineering, Quick Assist, malicious downloads, RMM tools, Cobalt Strike, and eventually PsExec to deploy Black Basta across the network.

This is a good example of why ransomware detection should extend beyond malware signatures.

Ryuk

Ryuk is another example of ransomware operators relying heavily on legitimate or dual-use administration tools.

CISA reported that Ryuk operators used tools such as Cobalt Strike and PowerShell Empire to steal credentials and relied on native tools including PowerShell, WMI, Windows Remote Management, and RDP for lateral movement. Operators also used scheduled tasks, attempted to delete backups and Volume Shadow Copies, and attempted to disable security applications.

From a SOC perspective, none of these activities necessarily means “ransomware” on its own.

PowerShell can be legitimate.

RDP can be legitimate.

Scheduled tasks can be legitimate.

Backup administration can be legitimate.

But the combination of these behaviors, occurring across multiple systems and involving privileged accounts, tells a very different story.

LockBit 2.0

LockBit 2.0 demonstrates another important principle: attackers can use scripting and administration capabilities without relying on a single custom malware tool.

Unit 42 documented LockBit 2.0 activity involving scheduled tasks, PsExec, compromised accounts, Group Policy modification, disabling security tools, removal of Windows event logs, and Base64-encoded PowerShell scripts. It also observed the use of the PowerShell module InvokeGPUpdate for Group Policy updates.

This creates another realistic sequence for defenders to monitor:

Valid Account → PowerShell → Group Policy Activity → Defense Evasion → PsExec → Lateral Movement → Ransomware Deployment

Again, the key lesson is that the attacker does not need to start with a ransomware executable.

They can spend significant time using legitimate Windows functionality to prepare the environment.

Why Individual Alerts Are Not Enough

A major challenge for SOC analysts is that many attacker actions also occur during legitimate administrative activity.

PowerShell may be used by IT teams.

Remote services may be created during software deployment.

Privileged users may access multiple systems during maintenance.

A scheduled task may be part of an approved business process.

This is why effective ransomware detection cannot depend on one isolated alert.

Consider the following sequence:

1. An encoded PowerShell command is executed.
2. A privileged account logs in from an unusual workstation.
3. PsExec is used to connect to several endpoints.
4. A command attempts to delete volume shadow copies.
5. A large number of files are modified.

Each event may appear inconclusive on its own. Together, however, they form a strong indication of ransomware-related activity.

The purpose of correlation is to transform disconnected events into a meaningful attack story.

The Role of Logstail SIEM in Ransomware Detection

Detecting ransomware early depends on having visibility across the systems and activities involved in an attack. Logstail SIEM provides a central layer for collecting, searching, correlating, and investigating security telemetry from across the environment.

For ransomware detection, this can include data such as:

• Windows Security Event Logs
• Sysmon and endpoint telemetry
• PowerShell activity
• Active Directory authentication events
• Firewall and VPN logs
• DNS and network activity
• Endpoint security events
• File server activity
• Backup-related events

The value is not simply collecting these logs. The important part is being able to connect related activity and give analysts the context needed to determine whether an individual event is part of a larger attack.

For example, an encoded PowerShell command may initially look like a suspicious but inconclusive event. When the same investigation also shows an unusual privileged login, remote execution on additional endpoints, and an attempt to remove shadow copies, the evidence becomes significantly stronger.

With Logstail SIEM, security teams can search and correlate these events to reconstruct what happened across users, endpoints, servers, and network activity.

Detection rules can then be used to identify suspicious behaviors and generate alerts when defined conditions are met. Instead of treating every individual event as an incident, detections can be designed to focus on higher-value combinations of behavior and context.

When an alert requires further investigation, Logstail SOAR can support the next stage of the workflow through cases, investigation processes, and response playbooks.

This creates a workflow that moves from:

Telemetry → Detection → Investigation → Case Management → Response

The objective is not to generate the largest possible number of alerts. It is to provide analysts with relevant signals, useful context, and a clear path from detection to action.

Building Effective Ransomware Detection Rules with Logstail

Detection rules are one of the most important components of ransomware monitoring. However, effective detection is not simply about creating a rule for every suspicious command or process.

In Logstail, detection logic can be built around the behavior that security teams want to identify and the telemetry available from their environment.

A useful ransomware detection rule may consider factors such as:

• The type of process or command being executed
• The account performing the activity
• The system where it occurs
• The command-line context
• Related authentication activity
• Network or remote execution activity
• The timing of related events
• Other suspicious behaviors occurring around the same time

This allows detections to focus on meaningful activity rather than generating an alert every time a legitimate administrative tool is used.

For example, detecting every PowerShell execution would create significant noise in most enterprise environments. A more useful detection could increase the importance of PowerShell activity when it is combined with characteristics such as encoded commands, unusual execution context, external downloads, privileged accounts, or subsequent remote execution.

The same principle can be applied to ransomware behaviors such as shadow copy deletion.

A command involving vssadmin may be legitimate in some environments. However, if it occurs shortly after suspicious PowerShell activity, follows an unusual privileged login, and is accompanied by remote activity across multiple systems, the combined evidence provides a much stronger detection signal.

Logstail allows security teams to configure detection logic around these types of conditions and turn relevant telemetry into actionable alerts.

The exact implementation will depend on the organization’s environment, available log sources, and detection requirements. The important principle is to build rules around attacker behavior and context rather than relying on isolated events.

Once rules are deployed, they can be continuously reviewed and tuned using real operational activity. This helps security teams improve detection quality while reducing unnecessary alert volume.

Reducing False Positives Through Alert Tuning

Ransomware detection rules must be tested and tuned against real organizational activity.

Without tuning, analysts may receive alerts for legitimate administrative tasks, backup processes, software deployments, vulnerability scans, and maintenance operations.

Useful tuning methods include:

• Excluding approved service accounts
• Documenting authorized administration tools
• Creating allowlists for known management servers
• Defining normal working hours
• Setting thresholds based on historical activity
• Increasing severity when multiple behaviors occur together
• Reviewing closed incidents for recurring false positives

However, exclusions should be implemented carefully. Broad allowlists can create detection gaps that attackers may exploit.

The goal of tuning is not to eliminate every false positive. It is to ensure that the alerts reaching analysts are relevant, understandable, and actionable.

A Practical Blue Team Investigation Workflow

When a potential ransomware alert is triggered, analysts should evaluate the broader context rather than focusing only on the event that generated the alert.

A practical investigation may include:

1. Validate the Alert

Determine whether the detected command, process, account, or network connection is expected.

Review:

• The affected user
• The source and destination systems
• The process tree
• The command line
• The event timestamp
• Related alerts
• Historical activity

2. Identify the Scope

Establish whether the activity is limited to one endpoint or has spread to additional systems.

Look for:

• The same user authenticating elsewhere
• Similar commands on other endpoints
• Shared indicators across several hosts
• Remote administrative activity
• Access to file servers and backups

3. Reconstruct the Timeline

Use SIEM data to determine what happened before and after the alert.

The timeline may reveal:

• The initial login
• Privilege escalation
• Credential access
• Remote execution
• Defense evasion
• File modifications

4. Contain the Threat

Depending on the evidence, containment actions may include:

• Isolating affected endpoints
• Disabling compromised accounts
• Blocking malicious network indicators
• Terminating suspicious processes
• Restricting access to shared storage
• Protecting backup infrastructure

5. Preserve Evidence

Logs, memory data, process information, command history, and affected files may be required for further investigation and recovery.

The response should therefore balance rapid containment with proper evidence preservation.

From Ransomware Detection Theory to Practice

Understanding ransomware techniques is only the first step. Analysts also need to know how those techniques appear in real logs, how detection rules are configured, and how suspicious activity is investigated within a SIEM environment.

Hands-on training helps Blue Team professionals develop these operational skills in a controlled environment.

The Combating Ransomware: Effective Detection Using SIEM course at Logstail Academy focuses on configuring ransomware-related detection, analyzing Windows log data, monitoring suspicious activity, and managing ransomware-related incidents through practical exercises.

The course includes topics such as ransomware indicators, log collection, detection-rule creation, alert configuration, and hands-on simulation and detection of potential ransomware activity using Logstail’s SIEM platform.

This allows learners to connect the theoretical attack behaviors discussed in this article with the practical responsibilities of a SOC analyst: identifying suspicious activity, correlating events, prioritizing alerts, and responding before attackers can cause widespread disruption.

Final Thoughts on Ransomware Detection

Ransomware rarely begins with encryption.

Before the final payload is deployed, attackers usually generate a trail of suspicious activity across identities, endpoints, services, and network connections.

PowerShell may be part of that activity. So may PsExec, RDP, WMI, scheduled tasks, stolen credentials, security-tool tampering, and recovery deletion.

Real ransomware operations such as Black Basta, Ryuk, and LockBit 2.0 demonstrate why defenders should focus on the attack chain rather than one specific tool or command.

These behaviors provide Blue Teams with multiple opportunities to detect and interrupt the attack.

Successful ransomware detection depends on visibility, quality telemetry, effective SIEM correlation, carefully tuned rules, and analysts who understand how individual events form part of a larger attack.

Organizations should not measure ransomware defense only by how quickly they recover encrypted systems.

A stronger measure is whether defenders can identify malicious behavior early enough to prevent encryption from happening at all.

Contact Our Experts or Sign Up for Free