What To Do After Ransomware Attack Network: Clear Privacy Guide

By Katia Belokon

Quick Answer

Understanding what to do after ransomware attack network recovery begins with isolating infected systems, documenting visible network changes, and verifying which devices can safely reconnect. A ransomware incident forces immediate decisions about network segmentation, IP address visibility, DNS behavior, and whether compromised endpoints are leaking information that could enable reinfection or lateral movement.

The practical response separates containment from verification. First, disconnect affected devices to prevent spread. Second, use network diagnostic tools to confirm which systems show clean traffic patterns and which still exhibit suspicious DNS queries, unexpected outbound connections, or residual command and-control communication. Third, document the public-facing network signals—IP addresses, resolver behavior, and routing paths—so you can compare before-attack baselines with post-recovery states.

What to do after ransomware attack network containment is not a single checklist. It requires understanding which network signals indicate ongoing compromise, which tools can verify isolation, and how to interpret results when DNS, browser traffic, and application-layer connections may behave differently across a partially recovered infrastructure.

Immediate Containment Steps

Isolate Infected Systems Without Restarting

The first instinct after discovering ransomware is often to restart affected machines. Resist this. Some ransomware variants trigger additional encryption or wiper payloads on reboot. Instead, physically disconnect network cables or disable wireless adapters to prevent the malware from spreading to other devices or communicating with attacker infrastructure.

Document the visible state before disconnection: note which IP addresses were assigned to infected machines, which DNS servers they were using, and whether any unusual outbound connections appear in router logs or firewall records. This baseline helps later when you need to verify that cleaned systems are behaving normally.

For systems that must remain powered on for forensic imaging, isolate them on a separate VLAN or physically separate network segment. Do not allow them to reach the internet or communicate with production systems. Use a dedicated forensic workstation to capture memory dumps and disk images before any remediation begins.

Identify the Ransomware Variant

Knowing the specific ransomware family helps determine whether decryption tools exist, whether the malware includes data exfiltration components, and what network behaviors to expect. Check the ransom note file extension, note text, and any contact information against known ransomware databases.

Some variants leave distinctive network signatures: specific DNS queries to check-in domains, predictable command and-control IP ranges, or characteristic TLS certificate patterns. Capture network traffic from isolated infected systems using packet capture tools, then analyze DNS queries and outbound connection attempts. This evidence helps confirm whether the malware is still active and attempting to communicate.

Do not pay the ransom. Payment does not guarantee decryption, funds criminal operations, and may mark your organization as a willing payer for future attacks. According to CISA’s ransomware guidance, many victims who pay never receive working decryption keys, and some ransomware families have flawed encryption that makes recovery impossible even with the key.

Network Verification After Containment

Check Public IP Addresses and Routing Paths

After isolating infected systems, verify the network perimeter from clean devices. Use MyIPScan to check the public IP address, ISP assignment, and approximate location for devices you believe are unaffected. Compare these results against your documented network baseline.

If the public IP address or ISP routing has changed unexpectedly, investigate whether the ransomware modified network settings, installed a proxy, or created unauthorized VPN tunnels. Some advanced ransomware families establish persistence by routing traffic through attacker-controlled infrastructure to maintain command and-control access even after initial cleanup.

Check multiple devices across different network segments. A single clean result does not prove the entire network is safe. Test from wired and wireless connections, from different VLANs, and from devices that were powered off during the attack. Consistent results across diverse endpoints suggest the network perimeter is behaving as expected.

Verify DNS Resolver Behavior

DNS is a common persistence and exfiltration vector. Ransomware may modify DNS settings to route queries through attacker-controlled resolvers, enabling traffic interception or providing a covert communication channel. After containment, verify that all systems are using your intended DNS servers.

Run a DNS leak test from each network segment. The test should show queries resolving through your corporate DNS servers or your chosen public resolver—not through unexpected third-party services. If results show unfamiliar DNS providers, check whether the ransomware modified DHCP settings, router configurations, or individual device DNS assignments.

Pay special attention to DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) settings in browsers and operating systems. These encrypted DNS protocols can bypass network-level DNS controls, potentially allowing compromised systems to communicate with attacker infrastructure even when traditional DNS is locked down. Audit browser and system DNS settings on all recovered devices.

Monitor for Residual Command and-Control Traffic

Even after removing ransomware executables, residual components may attempt to phone home. Set up network monitoring to capture outbound connection attempts from supposedly cleaned systems. Look for:

• Repeated connection attempts to the same external IP addresses, especially to hosting providers known for bulletproof hosting
• DNS queries for recently registered domains or domains with suspicious TLDs
• Outbound traffic on unusual ports or protocols inconsistent with normal business applications
• TLS connections with invalid or self-signed certificates
• Periodic beaconing patterns—connections at regular intervals suggesting automated check-ins

Capture and analyze this traffic before allowing cleaned systems back onto the production network. A system that appears clean but continues attempting suspicious outbound connections likely still harbors malware components or persistence mechanisms.

What Network Signals Reveal About Recovery State

Signal	What It Indicates	How to Verify	Red Flags
Public IP Address	Visible network endpoint and routing path	Check from multiple devices using MyIPScan	Unexpected changes, unfamiliar ISP assignments, proxy indicators
DNS Resolver	Where domain lookups are processed	Run DNS leak tests from each network segment	Queries resolving through unknown third-party services
Outbound Connections	Active communication attempts from endpoints	Packet capture and firewall log analysis	Repeated attempts to suspicious IPs, beaconing patterns
TLS Certificates	Identity of remote services being contacted	Inspect certificates in captured traffic	Self-signed certificates, recently issued certificates, mismatched domains
Network Configuration	DHCP, gateway, and routing settings	Compare current settings against documented baseline	Unauthorized changes to DNS, gateway, or proxy settings

Restoration and Clean Network Rebuild

Prioritize Critical Systems on Isolated Segments

Do not restore all systems simultaneously. Identify the most critical business functions and restore those systems first on a clean, isolated network segment. This quarantine network should have no connection to the compromised production environment and no internet access until you verify each system is clean.

Restore from known-good backups that predate the infection. Verify backup integrity before restoration—some ransomware families specifically target backup systems and may have corrupted or encrypted backup files weeks before the visible attack. Test restored systems in isolation, monitoring for any signs of reinfection or suspicious network behavior.

As each system passes verification, document its network configuration: assigned IP address, DNS settings, installed software, and baseline network traffic patterns. This documentation becomes your new security baseline for detecting future anomalies.

Rebuild Network Infrastructure with Segmentation

Ransomware spreads through flat networks where any compromised system can reach any other system. Use the recovery process to implement proper network segmentation. Separate user workstations, servers, administrative systems, and IoT devices into distinct VLANs with firewall rules controlling inter-segment traffic.

Implement the principle of least privilege at the network layer. A compromised workstation should not be able to directly access database servers, backup systems, or domain controllers. Require all cross-segment traffic to pass through inspection points where you can monitor for lateral movement attempts.

Change all network infrastructure passwords: router admin interfaces, switch management, firewall consoles, and wireless access point credentials. Ransomware operators often harvest these credentials during reconnaissance and may retain access even after the visible attack is contained.

Verify Each System Before Production Reconnection

Before allowing a restored system back onto the production network, run a comprehensive verification checklist:

• Scan with updated antimalware tools from a known-clean boot environment
• Verify the operating system and all applications are fully patched
• Check for unauthorized scheduled tasks, startup items, and service configurations
• Review installed browser extensions and system-level proxies
• Confirm DNS settings match the intended configuration
• Monitor outbound network connections for a short remediation window in isolation
• Verify the system’s public IP and DNS behavior match expectations

A system that passes all technical checks but shows unusual network behavior should remain isolated for additional investigation. Trust the network signals—they often reveal persistence mechanisms that file-based scans miss.

Common Verification Mistakes

Assuming Clean Scans Mean Clean Systems

Antimalware scans are necessary but not sufficient. Signature-based detection misses novel malware variants, and many ransomware families use fileless techniques that leave minimal disk artifacts. A clean scan result means the tool did not find known malware signatures—it does not prove the system is uncompromised.

Network behavior provides additional evidence. A system with clean scans but suspicious DNS queries, unexpected outbound connections, or modified network settings likely still harbors malware components. Use network diagnostics as a second verification layer, not as a replacement for endpoint scanning.

Trusting Single-Point Verification

Checking network behavior from a single device or a single network segment provides incomplete information. Ransomware may have established persistence on specific VLANs, modified DHCP server configurations, or compromised network infrastructure devices that affect only certain traffic paths.

Verify from multiple vantage points: different physical locations, different network segments, wired and wireless connections, and both domain-joined and standalone systems. Inconsistent results across these checks indicate the attack affected network infrastructure, not just endpoints.

Misinterpreting IP Geolocation Changes

IP-based location is approximate and should not be over-interpreted. A location showing a different city or region does not automatically indicate compromise—it may reflect ISP routing changes, load balancer assignments, or stale geolocation databases.

Focus on whether the IP address belongs to your expected ISP or hosting provider, not on precise geographic coordinates. According to Cloudflare’s explanation of IP addresses, geolocation accuracy varies widely and should be used for general verification, not precise physical location claims.

Ignoring Split-Tunnel and Browser-Level DNS

Modern browsers and operating systems increasingly use encrypted DNS protocols that bypass network-level DNS settings. A system may show correct DNS behavior at the network layer while browsers independently use DNS-over-HTTPS to different resolvers.

Check browser-specific DNS settings separately from system-level configuration. Firefox, Chrome, Edge, and Safari all support encrypted DNS with different default behaviors. A DNS leak test may show your corporate resolver while browsers silently use public encrypted DNS services, creating a verification blind spot.

Long-Term Network Hardening

Implement Continuous Network Monitoring

Post-recovery is the time to establish baseline network behavior for anomaly detection. Deploy network monitoring tools that capture DNS queries, outbound connection attempts, and traffic volume patterns. Establish alerts for deviations from baseline: unusual DNS query volumes, connections to newly registered domains, or traffic spikes to unfamiliar IP ranges.

Monitor for indicators of compromise specific to the ransomware family that affected you. Many ransomware operators reuse infrastructure across campaigns. Blocking known command and-control IP addresses and domains provides defense against reinfection attempts and related malware families.

Segment Backup Systems Completely

Ransomware increasingly targets backup systems to prevent recovery. Isolate backup infrastructure on a separate network with no standing access from production systems. Implement air-gapped or immutable backups that cannot be modified or deleted even by administrative accounts.

Test backup restoration regularly, and verify that restored systems show expected network behavior. A backup that restores successfully but immediately exhibits suspicious DNS queries or outbound connections may have been compromised before the backup was created.

Require Multi-Factor Authentication for Network Changes

Protect network infrastructure management interfaces with strong authentication. Ransomware operators often gain initial access through compromised credentials, then modify network settings to establish persistence and evade detection.

Require multi-factor authentication for router administration, switch management, firewall configuration, and DNS server changes. Log all configuration modifications and review logs regularly for unauthorized changes.

When to Seek External Assistance

Some ransomware incidents exceed internal response capabilities. Consider engaging external incident response specialists when:

• The ransomware variant is unknown or exhibits novel behaviors
• Network monitoring reveals ongoing command and-control communication despite cleanup efforts
• Critical systems cannot be restored from backups due to encryption or corruption
• Evidence suggests data exfiltration occurred alongside encryption
• The attack affected network infrastructure devices, not just endpoints
• Regulatory reporting requirements apply to the incident

External specialists bring forensic tools, threat intelligence, and experience with similar incidents. They can identify persistence mechanisms that internal teams miss and provide guidance on regulatory obligations and communication strategies.

Interpreting Network Diagnostic Results Safely

Separate Signal from Assumption

Network diagnostic tools show specific signals: public IP addresses, DNS resolver assignments, routing paths, and connection attempts. These signals provide evidence about network behavior, but they do not automatically prove a system is clean or compromised.

A system showing the expected public IP and DNS resolver may still harbor malware using encrypted channels or time-delayed activation. Conversely, a system showing unexpected network behavior may simply have legitimate software using split-tunnel VPNs or browser-level encrypted DNS.

Interpret results in context. Compare against documented baselines, verify from multiple vantage points, and correlate network signals with endpoint evidence. No single diagnostic proves complete security.

Use Consistency as a Verification Metric

Reliable verification comes from consistent results across repeated checks. Run the same network diagnostics multiple times over several days. Check from different devices, different network segments, and different times of day.

Inconsistent results indicate either ongoing compromise or legitimate network complexity that requires investigation. A system that shows clean behavior during business hours but suspicious activity overnight may have time-based malware activation. A system that shows different DNS behavior on wireless versus wired connections may have segment-specific configuration issues.

FAQ

Should I restart infected systems immediately after a ransomware attack?

No. Avoid restarting infected systems until you have documented their state and, ideally, captured forensic images. Some ransomware variants trigger additional encryption, wiper payloads, or anti-forensic routines on reboot. Instead, disconnect network connections to prevent spread, then power down systems gracefully if forensic imaging is not immediately available. Restart only after malware removal is complete and verified.

How can I tell if ransomware modified my network’s DNS settings?

Check DNS resolver assignments at multiple levels: individual device settings, DHCP server configuration, and router DNS forwarding rules. Run DNS leak tests from several devices across different network segments and compare results against your documented baseline. If tests show queries resolving through unfamiliar third-party services, investigate DHCP logs, router configuration history, and device-level DNS settings for unauthorized changes. Pay special attention to browser-level DNS-over-HTTPS settings, which can bypass network-level controls.

What network signals indicate a system is still compromised after cleanup?

Watch for repeated outbound connection attempts to the same suspicious IP addresses, DNS queries for recently registered or unusual domains, periodic beaconing patterns suggesting automated check-ins, TLS connections with invalid certificates, and traffic on unexpected ports. Capture and analyze this traffic using packet capture tools. A cleaned system should show only expected business application traffic. Persistent suspicious patterns indicate residual malware components or reinfection.

Can I trust my backups after a ransomware attack?

Verify backup integrity before restoration. Some ransomware families specifically target backup systems and may have encrypted or corrupted backup files weeks before the visible attack. Test restore a sample of files from multiple backup dates and scan restored data with updated antimalware tools. Monitor restored systems in isolation for a short remediation window, checking for suspicious network behavior that might indicate the backup contained malware. If multiple backup generations show signs of compromise, you may need to restore from much older backups or rebuild systems from scratch.

How long should I monitor systems after ransomware removal before trusting them?

Monitor restored systems in isolation for at least a short remediation window before allowing them back onto the production network. Capture all outbound connection attempts, DNS queries, and unusual traffic patterns during this period. Some ransomware includes time-delayed activation or checks in with command and-control infrastructure on irregular schedules. Extended monitoring provides higher confidence, especially for critical systems or when the ransomware variant is sophisticated. Continue monitoring after production reconnection, comparing behavior against your documented baseline.

What should I do if network diagnostics show inconsistent results across different devices?

Inconsistent results indicate either segmented compromise or legitimate network complexity requiring investigation. Document exactly which devices show which behaviors, noting network segment, connection type (wired/wireless), and time of day. Check whether inconsistencies correlate with specific VLANs, physical locations, or device types. Review network infrastructure configurations for segment-specific DNS, proxy, or routing rules. If inconsistencies persist without clear infrastructure explanation, treat affected segments as potentially compromised and extend isolation and verification procedures to all devices showing anomalous behavior.