In October 2025, over 100 SonicWall SSL VPN accounts were compromised across 16 organizations.
Attackers used valid credentials to authenticate rapidly, implying prior credential theft—not brute force.
Some sessions disconnected quickly, others led to full-blown network scanning and ransomware deployment.
🛡️ Defense Tips
Enforce MFA for all VPN users, especially NetExtender and SSL VPN.
Monitor VPN logs for unusual login patterns.
Restrict VPN access to known IPs or devices.
Regularly rotate credentials and audit firewall config backups.
8 thoughts on “Akira ransomware”
Key Risks of Using Personal Devices for Work
1. Lack of Centralized Control
IT teams can’t enforce security policies (e.g., patching, antivirus, firewall rules) on unmanaged personal devices.
No guarantee of disk encryption (e.g., BitLocker), secure boot, or endpoint protection.
2. Credential Theft
Personal devices may store work credentials in browsers or VPN clients.
If infected with malware or infostealers, attackers can harvest these and breach the corporate network.
3. Shared Usage
Family members may use the same device, increasing exposure to phishing, risky downloads, or accidental data leakage.
4. Unsecured Networks
Personal laptops often connect to public or poorly secured Wi-Fi, making them vulnerable to man-in-the-middle attacks.
5. Data Leakage & Compliance Violations
Sensitive files downloaded to personal devices may violate data protection laws (e.g., GDPR, HIPAA).
If the device is lost or stolen, there’s no way to remotely wipe or revoke access.
6. No Logging or Visibility
IT teams lose visibility into user activity, making it harder to detect anomalies or respond to incidents.
🛡️ How to Mitigate the Risk
Use Virtual Desktop Infrastructure (VDI) or remote apps to isolate work environments.
Enforce MFA for all remote access.
Deploy Mobile Device Management (MDM) or Endpoint Detection and Response (EDR) agents on BYOD machines.
Require VPN with split tunneling disabled to route all traffic through corporate inspection points.
Educate users on phishing, secure storage, and proper handling of work data.
Key Risks of Using Personal Devices for Work
1. Lack of Centralized Control
IT teams can’t enforce security policies (e.g., patching, antivirus, firewall rules) on unmanaged personal devices.
No guarantee of disk encryption (e.g., BitLocker), secure boot, or endpoint protection.
2. Credential Theft
Personal devices may store work credentials in browsers or VPN clients.
If infected with malware or infostealers, attackers can harvest these and breach the corporate network.
3. Shared Usage
Family members may use the same device, increasing exposure to phishing, risky downloads, or accidental data leakage.
4. Unsecured Networks
Personal laptops often connect to public or poorly secured Wi-Fi, making them vulnerable to man-in-the-middle attacks.
5. Data Leakage & Compliance Violations
Sensitive files downloaded to personal devices may violate data protection laws (e.g., GDPR, HIPAA).
If the device is lost or stolen, there’s no way to remotely wipe or revoke access.
6. No Logging or Visibility
IT teams lose visibility into user activity, making it harder to detect anomalies or respond to incidents.
🛡️ How to Mitigate the Risk
Use Virtual Desktop Infrastructure (VDI) or remote apps to isolate work environments.
Enforce MFA for all remote access.
Deploy Mobile Device Management (MDM) or Endpoint Detection and Response (EDR) agents on BYOD machines.
Require VPN with split tunneling disabled to route all traffic through corporate inspection points.
Educate users on phishing, secure storage, and proper handling of work data.
Initial Access via VPN
A user connected to the corporate network from a personal laptop using VPN (NetExtender).
The laptop was likely compromised—possibly via malware, infostealer, or remote access trojan.
VPN credentials were either harvested or the attacker used an active session.
Lateral Movement via RDP
The attacker used the VPN tunnel to RDP into an internal desktop located on the corporate LAN.
This desktop had RDP enabled and was accessible from the VPN subnet.
The attacker attempted to log into the Domain Controller (DC) from this desktop—possibly using:
Credential reuse
Pass-the-hash or token theft
LSASS memory scraping
Privilege Escalation Attempt
Failed or successful login attempts to the DC were logged (check Event ID 4625 or 4624).
If successful, attacker may have:
Queried AD for user/group info
Created new accounts or modified group memberships
Deployed malware or backdoors
Persistence & Payload Deployment
Attacker may have dropped tools like:
Advanced IP Scanner, Mimikatz, PCHunter64
Scheduled tasks or WMI scripts
If ransomware was deployed (e.g., Akira), look for:
Encrypted files
Ransom notes
Beaconing behavior
Exfiltration or Cleanup
Check for outbound traffic to suspicious IPs or domains.
Review SonicWall logs for large data transfers or unusual protocols.
Look for signs of log tampering or deletion.
🛠️ Next Steps
Preserve evidence: RAM dumps, disk images, VPN logs, RDP logs, DC event logs.
Reset credentials: For affected users and any accounts accessed.
Audit access controls: Especially RDP permissions and VPN group policies.
Scan for persistence: Scheduled tasks, registry keys, startup folders.
Document everything: Timestamped, source-referenced, and legally defensible.
NetExtender Client Logs (on the user’s machine)
📍 Location
Default path:
Code
C:\Program Files\SonicWall\SSL VPN\NetExtender\NetExtender.dbg
📋 What It Contains
Connection and disconnection timestamps
VPN tunnel status
Authentication results
IP address assignments
Errors or debug messages
🧭 How to View
Right-click the NetExtender icon in the system tray → View Log
Or open the NetExtender client and click the Log Viewer icon
You can export logs for analysis or support
🔐 Server-Side Logging (on the SonicWall firewall)
The firewall logs VPN session events, including:
User logins/logouts
Source IPs
Session durations
Authentication method (e.g., TOTP, RADIUS)
These can be viewed under:
Code
Log > View
or exported to a Syslog server for long-term retention and correlation.
🧠 Pro Tip for Forensics
If you’re investigating a breach:
Correlate NetExtender.dbg timestamps with firewall logs and Windows Event Logs
Look for:
Logins from unusual IPs or times
Repeated failed attempts followed by success
Sessions from unmanaged or personal devices
Recommended Workflow for a Full Virus Scan
✅ 1. Disconnect from the Network
Unplug Ethernet or disable Wi-Fi.
This prevents malware from communicating with command-and-control servers or spreading laterally.
✅ 2. Boot into Safe Mode
Safe Mode loads minimal drivers, which helps prevent malware from hiding.
Press Shift + Restart → Choose Troubleshoot > Advanced Options > Startup Settings > Restart → Select Safe Mode with Networking.
✅ 3. Run a Full Antivirus Scan
Use Windows Defender or a trusted tool like Malwarebytes, ESET, or Kaspersky Rescue Disk.
Prefer offline or bootable scanners for deeper cleaning (e.g., Microsoft Defender Offline Scan).
✅ 4. Review and Quarantine Findings
Don’t just delete—quarantine first to preserve forensic evidence.
Save scan logs for your incident report.
🧠 Forensic Considerations
If the laptop is part of an active investigation:
Imaging first: Consider capturing a disk image before scanning to preserve the original state.
RAM dump: If malware is memory-resident, scan may miss it—use Volatility or FTK Imager to capture RAM.
Chain of custody: Document every step, including scan tools used and timestamps.
https://learn.microsoft.com/en-us/defender-endpoint/safety-scanner-download
Post-Imaging Workflow: Investigating the Disk Image
✅ 1. Verify the Image
Use md5sum or sha256sum to generate a hash of the image:
bash
sha256sum disk.img > disk.img.sha256
This ensures integrity and lets you detect any future tampering.
✅ 2. Mount the Image (Read-Only)
Use loopback mounting:
bash
sudo mount -o ro,loop disk.img /mnt/forensics
Or use kpartx if the image contains partitions:
bash
sudo kpartx -av disk.img
✅ 3. Extract Artifacts
Use tools like:
plaso or log2timeline for timeline analysis
bulk_extractor for keyword and pattern scanning
autopsy or sleuthkit for file system analysis
strings, grep, find, stat for manual inspection
✅ 4. Analyze Malware or Persistence
Look for:
Suspicious binaries in %AppData%, %Temp%, or startup folders
Registry hives (SYSTEM, SOFTWARE) for autoruns
Browser history, downloads, and saved credentials
✅ 5. Correlate with Logs
Match timestamps from the image with:
VPN logs
RDP session logs
Domain controller events
NetExtender.dbg
🛡️ Chain of Custody Tip
Document every step: imaging command, hash values, mount points, tools used.
Keep the original image write-protected and work only on copies.
When It’s Safe to Reimage the Original Disk
1. Disk Image Verified
You’ve created a full disk image using ddrescue or similar.
The image hash (e.g., SHA-256) is recorded and verified.
The image is stored securely and write-protected.
2. Evidence Fully Extracted
You’ve completed:
Timeline reconstruction
Malware identification
Credential harvesting analysis
Persistence mechanism review
All relevant logs, artifacts, and registry hives have been extracted.
3. Chain of Custody Documented
You’ve logged:
Imaging commands and timestamps
Hash values
Storage location
Access history
4. No Further Need for Live Analysis
You’ve ruled out the need for:
Memory forensics (RAM dump already captured)
Live malware behavior analysis
Volatile data inspection
5. Approval from Stakeholders
If this is part of an incident response or legal case:
Confirm with legal, compliance, or security teams.
Ensure reimaging won’t interfere with ongoing investigations.
Post-Investigation Safety of Disk Images
✅ Safe by Default
A raw image (.img, .dd) is just a static snapshot of the disk.
Malware inside it is not active—it’s just data.
You can safely analyze it using forensic tools like Autopsy, plaso, bulk_extractor, or strings.
⚠️ When It Could Become Dangerous
If you mount the image read-write and accidentally execute a malicious binary.
If you boot a VM from the image without isolating it (e.g., no network sandbox).
If you extract and run suspicious files without containment.
🛡️ Best Practices for Safe Analysis
Mount read-only:
bash
sudo mount -o ro,loop disk.img /mnt/forensics
Use non-executable environments for analysis (e.g., forensic VMs with no internet).
Extract suspicious files to a sandbox or use tools like cuckoo or any.run for behavioral analysis.
Never double-click unknown .exe, .js, or .vbs files from the image on your host system.