PULSAR RAT (server.exe)

Campaign Identifier: PULSAR-RAT-185.208.159.182
Last Updated: December 1, 2025
Threat Level: CRITICAL

BLUF (Bottom Line Up Front)

server.exe is Pulsar RAT (9.2/10 CRITICAL) — a .NET remote access trojan distributed from an open directory at hxxp://185[.]208[.]159[.]182/d/server[.]exe. Static code analysis confirms complete remote control, automated credential harvesting across all major browsers, keylogging, HVNC covert desktop access, and BCrypt-encrypted C2 with a Pastebin dead-drop resolver. Multi-layered anti-analysis targets VMware, VirtualBox, QEMU, Hyper-V, and common debuggers. Registry RunOnce persistence is confirmed; recovery partition abuse capability is present in code and requires per-system verification. The infrastructure also hosts Quasar RAT and NjRAT/XWorm families — see the follow-up report Dual-RAT Analysis for full campaign scope. Capabilities are detailed in Section 6; detection rules and IOCs are in the sidebar.

Business Impact Summary

Pulsar RAT provides attackers with complete control over infected systems, enabling data theft, credential harvesting, and network-wide compromise. This represents a CRITICAL threat (9.2/10).

Key Risk Factors

Technical Summary

What This Malware Enables:

• Complete Data Access: All information accessible to compromised users
• Credential Harvesting: All passwords and authentication tokens used on infected systems
• Hidden Remote Access: Covert control undetectable to end users
• Network Propagation: Ability to spread from single infection to broader infrastructure

Why This Threat Is Significant:

• Professional Development: Sophisticated code quality indicating organized threat actors
• Advanced Evasion: Defeats standard security controls and analysis techniques
• Persistent Presence: Survives basic remediation attempts through multiple mechanisms

Organizational Guidance

For Executive Leadership

• Incident Scope: Treat any confirmed infection as a full-system compromise — all credentials and accessible data should be considered exposed
• Regulatory Exposure: Data breach notification obligations depend on jurisdiction and the nature of data accessible on affected systems; engage legal counsel to assess
• Remediation Decision: System rebuild provides the highest assurance of clean state; cleanup carries residual risk, especially where recovery partition access cannot be forensically excluded

For Technical Teams

• Deploy Detection Signatures: Detection rules are in the sidebar; deploy across endpoints before hunting
• Hunt for IOCs: Search for file hashes and behavioral indicators provided in the IOC feed
• Network Analysis: Review egress logs for connections to paste sites and ipwho.is from unexpected hosts
• Isolate Confirmed Systems: Network-isolate without powering down (preserve volatile memory)
• Evidence Preservation: Capture memory and disk images before remediation

Capability detail: Section 6 · Detection coverage: sidebar · IOC feed: sidebar · Response guidance: Section 7

Primary Threat Vector

• Distribution Point: Open directory at hxxp://185[.]208[.]159[.]182/d/server[.]exe
• Infrastructure Analysis: Known malicious IP hosting multiple malware families
• Confidence Level: HIGH based on static code analysis and OSINT correlation

Assessment Basis: Static code analysis, behavioral indicators, and correlation with known RAT families. Confidence levels provided throughout to distinguish confirmed findings from analytical judgments.

Investigation Status: Follow up investigations were done and can be found in the report Dual-RAT Analysis (server.exe)

1. EXECUTIVE SUMMARY

server.exe is Pulsar RAT, a .NET remote access trojan derived from the open-source Quasar RAT family. Static code analysis establishes the threat at 9.2/10 CRITICAL. An attacker who executes this payload gains the equivalent of unrestricted physical access: complete filesystem control, automated credential harvesting from all major browsers, live keylogging, covert Hidden Virtual Network Computing (HVNC) desktop access invisible to the user, screen and webcam capture, microphone recording, clipboard hijacking targeting cryptocurrency addresses, and a SOCKS proxy module for lateral movement into network segments not directly reachable from the internet.

Infrastructure context: 185[.]208[.]159[.]182 (AS42624, associated with “NOAVARAN SHABAKEH SABZ MEHREGAN Ltd.” and “SETEL CONECTA S.L.”) has been reported as an active C2 node for RedLine Stealer on port 1912, a Quasar RAT distribution point, and hosts additional malware families documented in the follow-up investigation — Dual-RAT Analysis. Threat intelligence feeds flag the broader 185.208.15x.xxx range for malicious activity across multiple platforms (HIGH confidence — OSINT correlation).

Capability cross-references: full technical detail in Section 6 (capabilities), Section 6/Evasion subsection (anti-analysis), Section 7 (incident response). Risk scores below are reproduced from the BLUF for convenience; the scoring methodology is in Section 3.

Risk Rating: CRITICAL

2. BUSINESS RISK ASSESSMENT

Understanding the Real-World Impact

Pulsar RAT’s full-spectrum remote control places every data asset and credential accessible to a compromised account at attacker disposal. The scenarios below reflect the realistic downstream consequences.

Impact Scenarios

Operational Impact Timeline

If infection confirmed:

• Initial Phase: Network isolation, evidence preservation, credential rotation
• Investigation Phase: Forensic analysis, threat hunting across the environment for lateral spread
• Remediation Phase: System rebuild or verified cleanup, continued monitoring
• Ongoing: Enhanced monitoring; breach notification assessment if data access is confirmed

3. WHAT IS server.exe?

Classification & Identification

File Identifiers

Why This Is Professional-Grade Malware

Not commodity crimeware - not script-kiddie code

Evidence of professional development (CONFIRMED through static analysis):

✓ Modular architecture - 30+ functional modules organized by purpose (Surveillance, Admin, Networking, Persistence, Evasion) ✓ Proper software engineering - Exception handling, async/await patterns, organized namespaces matching professional development practices ✓ Custom cryptography - Windows CNG (BCryptEncrypt, BCryptImportKey) for secure communications ✓ Advanced persistence techniques - Multiple mechanisms including recovery partition manipulation ✓ Multi-layered evasion - Anti-analysis targeting VMs, debuggers, and sandboxes in combination ✓ HVNC implementation - Complex covert remote desktop technique ✓ MessagePack serialization - Efficient binary C2 protocol (not basic HTTP)

3.1 Internal String Analysis: Unveiling Pulsar’s Architecture

Based on analysis of embedded strings and YARA rule matches, server.exe is confirmed to be Pulsar RAT, a full-featured variant derived from the open-source Quasar RAT family. The strings, appearing as internal .NET namespaces and class names (e.g., Pulsar.Common.Messages.Administration.RemoteShell, Pulsar.Common.Messages.Monitoring.KeyLogger), directly reveal the malware’s extensive capabilities and modular architecture. These include:

• Administration & Control: Remote shell, file management, task management, registry editing.
• Surveillance: Keylogging, remote desktop, webcam access, password harvesting, clipboard monitoring, and Hidden Virtual Network Computing (HVNC).
• Networking & Communication: Use of encrypted channels (BCryptEncrypt) and efficient MessagePackSerializer for Command & Control (C2) communication, dynamically fetching C2 configurations.
• System Interaction: Utilities for User Account Control (UAC) manipulation and Windows Recovery Environment (WinRE) persistence.

This detailed internal naming scheme provides strong evidence of the malware’s design for comprehensive remote system compromise and further reinforces its classification as a professional-grade threat.

4. INFECTION VECTORS

How Pulsar RAT Reaches Target Systems

Executive Impact Summary

Delivery Risk: High — Multiple infection pathways identified User Interaction: Required for initial execution in most observed delivery scenarios Key Takeaway: Prevention at the delivery stage is the most effective control layer

Primary Distribution Method

Open Directory Distribution (CONFIRMED)

The analyzed sample was obtained from an open web directory:

• URL: hxxp://185[.]208[.]159[.]182/d/server[.]exe
• Access Method: Direct HTTP download (no authentication required)
• Risk Level: HIGH - Publicly accessible malware distribution point

Common Social Engineering Tactics

Phishing Email Themes (Based on RAT Distribution Patterns):

1. Financial/Invoice Themes
   • “Urgent: Unpaid Invoice #[number]”
   • “Payment Confirmation Required”
   • “Bank Statement - Action Required”
   • Attachment names: invoice.exe, payment_receipt.exe, statement.pdf.exe
2. Shipping/Delivery Notifications
   • “FedEx/UPS/DHL Delivery Failure”
   • “Package Tracking Information”
   • “Shipment Delayed - Action Required”
   • Attachment names: tracking.exe, delivery_info.exe, label.pdf.exe
3. IT/Security Themes
   • “Urgent Security Update Required”
   • “Password Expiration Notice”
   • “System Maintenance Tool”
   • Attachment names: security_update.exe, system_check.exe, it_tool.exe
4. Business Communication
   • “Q4 Report - Please Review”
   • “Contract for Signature”
   • “Meeting Notes Attached”
   • Attachment names: report.exe, contract.pdf.exe, notes.exe

File Naming Techniques to Evade Suspicion

CONFIRMED filename from distribution: server.exe

Common RAT distribution filenames:

• Generic system names: server.exe, client.exe, update.exe, setup.exe
• Double extensions: document.pdf.exe, invoice.doc.exe (exploits Windows hiding of extensions)
• Trusted software names: chrome_installer.exe, office_update.exe, adobe_reader.exe
• Legitimate-sounding utilities: system_repair.exe, disk_cleanup.exe, network_tool.exe

Defense Strategies by Attack Vector

Email Security: Email filtering with attachment scanning, DMARC/SPF/DKIM enforcement, and attachment sandboxing reduce delivery success rates for phishing-based campaigns.

Web Security: DNS filtering to block known-malicious domains; egress controls restricting access to open directory listings; browser isolation for untrusted content.

Endpoint Protection: Application control (whitelisting) blocks unauthorized .NET executables. Behavioral EDR catches evasive malware that signature-based AV misses.

Network Controls: Egress filtering on known-malicious IP ranges; monitoring for outbound connections to paste sites from unexpected hosts; IDS/IPS signatures for known Quasar-family traffic patterns.

User Awareness

Phishing delivery requires user execution. Training focused on executable attachment recognition, urgency-pressure tactics, and low-penalty incident reporting reduces initial access success. Phishing simulation programs provide measurable reinforcement.

5. MITRE ATT&CK MAPPING

Comprehensive Threat Intelligence Mapping

Executive Impact Summary

Framework Purpose: Industry-standard classification of adversary tactics and techniques Business Value: Enables threat hunting, detection engineering, and gap analysis Intelligence Sharing: Common language for discussing threats across organizations Key Takeaway: Understanding attacker techniques enables proactive defense

What is MITRE ATT&CK?

MITRE ATT&CK is a globally accessible knowledge base of adversary tactics and techniques based on real-world observations. It provides a common framework for describing how cyber adversaries operate, enabling organizations to:

• Develop threat-informed defenses
• Perform gap analysis of security controls
• Share threat intelligence using common terminology
• Prioritize detection and response capabilities

Pulsar RAT: Full Technique Mapping

The following table maps all confirmed Pulsar RAT capabilities to MITRE ATT&CK techniques:

ATT&CK Tactic Coverage Analysis

Pulsar RAT demonstrates comprehensive coverage across the MITRE ATT&CK framework:

Detection and Mitigation Priorities by Tactic

CRITICAL PRIORITY (Implement Immediately):

1. Defense Evasion Detection (7 techniques)
   • Deploy EDR with behavioral detection
   • Implement memory scanning
   • Monitor for process injection
   • Alert on VM/sandbox evasion attempts
2. Credential Access Prevention (6 techniques)
   • Deploy Credential Guard
   • Implement MFA universally
   • Monitor browser credential store access
   • Deploy anti-keylogging controls
3. Persistence Detection (3 techniques)
   • Monitor registry RunOnce modifications
   • Audit recovery partition access
   • Alert on boot configuration changes

HIGH PRIORITY (Implement This Quarter):

1. Command and Control Disruption (6 techniques)
   • Implement egress filtering
   • Deploy DNS filtering
   • Monitor paste site access
   • Inspect encrypted traffic where possible
2. Collection Prevention (6 techniques)
   • Deploy DLP controls
   • Monitor screen capture APIs
   • Implement clipboard protection
   • User awareness training

Using This Mapping for Threat Hunting

Detection Engineering:

FOR EACH technique in table:
  1. Review existing detection coverage
  2. Identify gaps (no detection rule exists)
  3. Develop detection logic using technique details
  4. Deploy detection rule to SIEM/EDR
  5. Tune to reduce false positives
  6. Document in security runbooks

SIEM Query Development Example:

Based on T1102.001 (Web Service: Dead Drop Resolver):

# Splunk query to detect paste site C2 configuration retrieval
index=proxy OR index=dns OR index=firewall
(dest="pastebin.com" OR dest="paste.ee" OR dest="hastebin.com")
| stats count by src_ip, dest, url
| where count > 5
| table src_ip, dest, url, count

EDR Hunting Query Example:

Based on T1555.003 (Browser Credential Theft):

process_name:"*.exe"
AND file_path:*Login Data*
AND (file_path:*Chrome* OR file_path:*Firefox* OR file_path:*Edge*)
AND NOT process_name:(chrome.exe OR firefox.exe OR msedge.exe)

Gap Analysis Framework

This mapping supports security control gap analysis:

Step 1: Control Mapping — For each technique, document existing controls (prevention, detection, response).

Step 2: Gap Identification — Identify techniques with no coverage, detection-only, or prevention-only coverage.

Step 3: Risk Prioritization — Rank gaps by business impact using the tactic coverage table above.

Step 4: Remediation Planning — Develop an implementation plan for critical-priority gaps, starting with Defense Evasion, Credential Access, and Persistence detection.

6. TECHNICAL CAPABILITIES DEEP-DIVE

Analyst note: This section documents Pulsar RAT’s functional modules as confirmed through static code analysis of server.exe. Each subsection leads with a confidence level and the specific code evidence that supports it. Defenders can use this detail to build targeted detection rules and evaluate which controls are directly tested by each capability.

Executive Impact Summary

Business Risk: Critical — Complete system compromise possible Detection Difficulty: High — Advanced evasion techniques present Remediation Complexity: High — Multiple persistence mechanisms Key Takeaway: Well-engineered malware requiring comprehensive response

Quick Reference: Pulsar RAT Capabilities Matrix

6.1 PERSISTENCE MECHANISMS

Analyst note: Persistence mechanisms are the techniques malware uses to survive reboots and re-establish access after the user logs off. Pulsar implements two distinct persistence methods at different privilege levels — one standard (registry RunOnce) and one advanced (Windows Recovery Environment). The WinRE technique survives some OS reinstallation scenarios, which is why remediation decisions hinge on whether this method was activated.

Executive Summary

Persistence Risk: High — Multiple mechanisms including advanced recovery partition abuse Detection Challenge: Medium — Standard registry persistence is detectable; WinRE requires specialized analysis Remediation Impact: High — May require complete system rebuild for assured removal Business Impact: Survives standard remediation in some scenarios, enabling long-term access

CONFIDENCE LEVEL: HIGH (technique present in code) — VERIFICATION REQUIRED FOR SPECIFIC SYSTEMS

Critical Finding: Recovery Partition Persistence - Understanding the Risks

What is WinRE and How Can It Be Abused?

Windows Recovery Environment (WinRE) is a minimal operating system stored on a separate partition that loads when Windows detects system problems. IT professionals use it for system recovery and troubleshooting.

The Persistence Technique:

The malware contains code to:

1. Elevate to Administrator privileges
2. Access the recovery partition (typically hidden from normal file system view)
3. Place malicious files in the recovery partition directory structure
4. Modify boot configuration to execute malware during recovery processes

Why This Matters - But With Important Caveats:

Standard OS reinstallation typically reformats only the primary Windows partition (C:), leaving the recovery partition untouched. However, this persistence technique has important limitations:

Reality Check: When This Technique Works vs. Doesn’t Work

Scenarios Where Persistence SURVIVES: ✓ Standard Windows “Reset this PC” function (keeps recovery partition) ✓ Quick format and reinstall on C: drive only ✓ Many OEM recovery processes (Dell, HP, Lenovo recovery tools) ✓ Upgrade installations that preserve recovery partitions

Scenarios Where Persistence FAILS: ✗ Complete disk wipe including all partitions (secure erase) ✗ UEFI Secure Boot with recovery partition integrity checks (if properly configured) ✗ BitLocker-encrypted recovery partitions with TPM verification ✗ Installation from external clean media with full repartitioning ✗ Disk replacement (new physical drive) ✗ Modern Windows 11 systems with hardware-backed recovery verification

Research Context:

Recovery partition abuse is documented in security research but remains relatively uncommon compared to registry-based persistence:

• ESET Research (2020): Documented FinSpy malware using UEFI bootkit persistence (similar concept, different location)
• Kaspersky (2020): Reported MosaicRegressor malware abusing UEFI firmware for persistence
• Microsoft Security (2022): Advisory on boot partition malware noting detection complexity

Why this technique is serious but not “undefeatable”:

While this is an advanced technique, calling it “survives all remediation” overstates the reality. Many organizations already use remediation procedures that would eliminate this persistence:

• Enterprise imaging processes that repartition drives
• MDT/SCCM deployments from network images
• Compliance-mandated secure wipe procedures

Verification Steps

Safe verification process (READ-ONLY - does not modify system):

# Check if WinRE partition is accessible (requires Administrator)
# This is a READ-ONLY check - safe to run

Write-Host "Checking WinRE configuration..." -ForegroundColor Cyan

# Check WinRE status
reagentc /info

# Check for recovery partition
Get-Partition | Where-Object {$_.Type -eq 'Recovery'} |
    Select-Object DiskNumber, PartitionNumber, Size, Type

# If recovery partition exists, check for suspicious files (mounting required)
# NOTE: Only proceed with mounting if you have forensic training
Write-Host "`nWARNING: Mounting recovery partition for inspection should only be done by trained personnel" -ForegroundColor Yellow
Write-Host "Consider imaging the partition first for forensic preservation" -ForegroundColor Yellow

For thorough verification, forensics specialists can:

• Create forensic images before any inspection
• Mount recovery partitions in read-only mode
• Analyze boot configuration safely
• Document chain of custody if evidence preservation needed

Evidence Supporting This Assessment

Code Analysis Findings (CONFIRMED):

• WinRE-related string references: Recovery\OEM\ directory paths
• Boot configuration manipulation functions
• Partition mounting utilities referenced in imports

Actual exploitation success rate (UNKNOWN):

• Code presence ≠ guaranteed execution
• Requires administrative privileges
• May fail on hardened systems
• Real-world success rate requires incident data

Assume the capability exists; verify on specific systems rather than assuming all infected systems have active WinRE persistence.

Secondary Persistence: Registry RunOnce

CONFIDENCE LEVEL: CONFIRMED (standard technique, well-documented)

Location:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce (system-wide)
• HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce (current user)

How it works:

• Entry executes once at next login/boot, then automatically deletes itself
• Helps evade simple autorun scanners looking for persistent Run keys
• Malware recreates the entry each time it runs (self-perpetuating)

Why this is the more common persistence method:

• Survives reboots (but NOT OS reinstallation)
• Requires only user-level privileges for HKCU variant
• Well-understood and reliable
• Detected by most EDR solutions

Detection: Standard registry monitoring will catch this. Any competent EDR/endpoint security solution monitors RunOnce modifications.

6.2 COMMAND & CONTROL (C2) INFRASTRUCTURE

Analyst note: Command and control (C2) is how the attacker sends instructions to the infected system and receives stolen data. This section explains why Pulsar’s C2 design is harder to detect than typical malware: it avoids hardcoded server addresses by reading them from a legitimate public website (Pastebin), then encrypts all traffic using Windows-native cryptography.

The Encrypted, Dynamic C2 Protocol

CONFIDENCE LEVEL: CONFIRMED (code analysis + behavioral indicators). Traditional C2 detection relies on identifying suspicious domains or IP addresses. Pulsar defeats this through a multi-layered approach:

Architecture:

1. INFECTED SYSTEM STARTUP
   ↓
2. Retrieves C2 configuration from public paste site
   (e.g., pastebin.com/raw/[attacker-specified-ID])
   ↓
3. Decrypts configuration using embedded keys to get C2 server IP/domain
   ↓
4. Establishes BCrypt-encrypted connection to C2 server
   ↓
5. Attacker sends commands via MessagePack binary protocol
   ↓
6. Malware executes commands, returns encrypted results

Why This Complicates Detection:

• No hardcoded C2 servers - Addresses retrieved dynamically, changing infrastructure doesn’t require new malware variants
• Encrypted communications - Windows CNG (BCrypt) encryption makes network traffic analysis difficult
• MessagePack binary protocol - Not HTTP/JSON, harder to pattern-match with standard IDS rules
• Legitimate infrastructure abuse - Paste sites like Pastebin are legitimate services (see blocking discussion below)

Secondary Network Indicators (CONFIRMED in code):

• https://ipwho.is/ - Victim IP geolocation (attacker reconnaissance)
• https://www.amyuni.com/downloads/usbmmidd_v2.zip - Virtual display driver for HVNC functionality

6.3 SURVEILLANCE & DATA THEFT CAPABILITIES — Hidden Virtual Network Computing (HVNC)

Analyst note: HVNC creates an invisible second desktop session that the attacker controls while the user sees their normal screen. Unlike standard remote desktop tools, there are no visible indicators — no cursor movement, no window flicker. This subsection covers what HVNC is, why it matters for detection, and what limitations affect its real-world effectiveness.

CONFIDENCE LEVEL: HIGH (code present; requires driver installation to function)

What Is HVNC?

A technique that creates an invisible virtual desktop session, allowing attackers to control a system without the victim seeing desktop activity.

Comparison:

NORMAL REMOTE DESKTOP (RDP/VNC):
User sees:    Desktop flicker, mouse moving, applications opening
User can:     Disconnect, close applications, observe attacker activity
Detection:    Process monitor shows rdp/vnc processes, network shows connections

HVNC (Hidden Virtual Network Computing):
User sees:    Normal desktop - no visible changes
User can:     Nothing - virtual session is separate from visible desktop
Detection:    Requires specialized monitoring (see below)

Reality Check: Is HVNC Truly “Undetectable”?

Short answer: No, but it’s harder to detect than normal remote access.

What makes detection difficult:

• No visible UI changes (victim doesn’t see it)
• Runs in separate virtual desktop context
• Legitimate driver (usbmmsvc64.exe) may be digitally signed
• Activity appears to originate from victim’s computer

Detection Methods: See Appendix C for detailed HVNC detection procedures and industry research

Realistic Assessment:

HVNC is hard to detect but not impossible to detect. It’s particularly effective against:

• Organizations without EDR
• Environments relying only on antivirus
• Systems without comprehensive logging

It’s less effective against:

• Modern EDR with behavioral detection
• Security operations teams actively threat hunting
• Environments with comprehensive logging and SIEM correlation

The activity is harder to detect because it appears to come from the legitimate user, but it’s not invisible to comprehensive security monitoring.

Keystroke Logging - Complete Credential Capture

CONFIDENCE LEVEL: CONFIRMED (keylogging module present in code)

What’s Captured:

• All keyboard input including passwords, even if not displayed on screen
• Corporate credentials (Active Directory, VPN, email)
• Banking and financial credentials
• Social media and personal account passwords
• Cryptocurrency wallet passwords
• Two-factor authentication codes (if typed or copy/pasted)

Why It’s Effective:

Even with password managers, users often:

• Type master passwords
• Copy/paste credentials (captured via clipboard monitoring)
• Manually enter verification codes
• Use keyboard shortcuts that reveal information

Detection Methods:

• EDR behavioral monitoring for keylogging API calls (GetAsyncKeyState, SetWindowsHookEx)
• Monitoring for suspicious input capture libraries
• Behavioral analytics detecting keystroke logging patterns

Browser Password Theft — Automated Extraction

CONFIDENCE LEVEL: CONFIRMED (code modules present)

How It Works:

1. Identify browser installations (Chrome, Firefox, Edge, Opera, Brave)
2. Locate credentials database:
   - Chrome: %LocalAppData%\Google\Chrome\User Data\Default\Login Data
   - Firefox: %AppData%\Mozilla\Firefox\Profiles\[profile]\logins.json
3. Use Windows DPAPI (Data Protection API) to decrypt passwords
4. Extract username/password pairs for all saved credentials
5. Transmit to attacker via encrypted C2 channel

Why This Is Effective:

• Fully automated - runs without user interaction
• Comprehensive - extracts ALL stored passwords from ALL browsers
• Scalable - affects all user profiles on compromised system
• Difficult to prevent - browsers must store credentials to auto-fill them

Targets (CONFIRMED):

• Google Chrome / Chromium-based browsers (Edge, Brave, Vivaldi, Opera)
• Mozilla Firefox
• Legacy Internet Explorer

Mitigation:

• Hardware security keys for critical accounts (FIDO2/WebAuthn)
• Separate credential management solutions with encryption
• Limit credential storage in browsers for sensitive accounts

Clipboard Hijacking — Cryptocurrency Theft

CONFIDENCE LEVEL: CONFIRMED (clipboard monitoring code present)

The Attack Scenario:

Victim:     "I'll send Bitcoin to my friend"
Victim:     Copies friend's wallet address: 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
Malware:    Detects Bitcoin address format in clipboard
Malware:    Replaces with attacker's address: 1AttackerWalletAddress...
Victim:     Pastes into transaction field (doesn't notice change)
Victim:     Confirms transaction
Result:     Funds sent to attacker instead of intended recipient

Specific Evidence (CONFIRMED in code):

Bitcoin Cash Address Detection

Why Cryptocurrency Theft Is Permanent:

Unlike bank transfers (reversible) or credit cards (chargeback protection), blockchain transactions are:

• Irreversible once confirmed
• Anonymous (difficult to trace to real-world identity)
• No recovery mechanism exists

Real-World Impact:

• Blockchain transactions are irreversible once confirmed; there is no recovery mechanism
• Clipboard hijacking is transparent to the victim at the moment of the transaction
• Targets include individual cryptocurrency users and organizational treasury operations

Screen Capture & Video Recording

CONFIDENCE LEVEL: CONFIRMED (modules present)

Capabilities:

• Continuous screen capture at configurable intervals
• Video encoding with JPEG compression (bandwidth efficiency)
• Webcam access and image capture
• Microphone/audio recording

Attacker Use Cases:

• Visual surveillance of user activity
• Capture sensitive documents displayed on screen
• Reconnaissance to understand network layout from visible applications
• Evidence gathering for social engineering or extortion

Detection:

• EDR monitoring of screen capture APIs (BitBlt, GDI+)
• Webcam/microphone usage indicators (modern OS shows camera usage)
• Unusual CPU usage during idle periods

6.4 PRIVILEGE ESCALATION & LATERAL MOVEMENT

Analyst note: Privilege escalation allows malware to gain administrative rights beyond its initial execution context. Lateral movement allows an attacker to reach other systems from the first compromised host. Together, these capabilities turn a single infected workstation into a network-wide incident.

UAC Bypass

CONFIDENCE LEVEL: MODERATE (UAC bypass techniques referenced; specific method requires dynamic analysis)

Pulsar includes UAC (User Account Control) bypass capabilities, allowing it to:

• Elevate from standard user to Administrator privileges
• Modify system-wide settings and protected registry keys
• Install advanced persistence mechanisms requiring admin rights (WinRE)

Common UAC bypass methods in similar malware:

• DLL hijacking of auto-elevated processes
• Token manipulation
• COM interface abuse
• Windows registry manipulation

Detection: Modern EDR monitors UAC bypass attempts through behavioral analysis.

Token Manipulation & Impersonation

CONFIDENCE LEVEL: CONFIRMED (API calls present)

The malware uses Windows security token manipulation:

• AdjustTokenPrivileges - Modify security tokens to gain additional permissions
• ImpersonateLoggedOnUser - Assume identity of another logged-in user

Impact:

• Can impersonate domain administrators if they’ve logged into compromised system
• Can access resources using service account identities
• Can escalate privileges beyond initial infection context

Detection: Security Event 4672 (Special privileges assigned to new logon) can indicate token manipulation when correlated with other suspicious activity.

Process Injection

CONFIDENCE LEVEL: CONFIRMED (injection code present)

Injects malicious code into legitimate system processes:

• Target processes: explorer.exe, svchost.exe, other trusted Windows processes
• Hides malware presence (malicious code runs under legitimate process name)
• Evades process-based detection and application whitelisting

Detection Methods:

• EDR monitoring for CreateRemoteThread API calls
• Memory scanning for unsigned or anomalous code in process space
• Behavioral monitoring for legitimate processes exhibiting unusual network activity

SOCKS Proxy & Network Tunneling

CONFIDENCE LEVEL: CONFIRMED (SOCKS proxy module present)

Configures infected system as a network relay/proxy:

Capabilities:

• Attackers can route traffic through infected system
• Enables access to internal network segments not directly reachable from internet
• Makes attacker traffic appear to originate from trusted internal system

Lateral Movement Scenario:

Internet → Infected Workstation (SOCKS Proxy) → Internal Database Server
         Appears as legitimate internal traffic ↑

Why this matters for network segmentation:

• Segmented networks remain vulnerable if a single system within a segment is compromised
• Firewall rules permitting internal communication become attacker pathways
• Traffic routed through the SOCKS proxy is difficult to distinguish from legitimate internal access

Detection:

• Monitor for unexpected SOCKS proxy services
• Network traffic analysis showing internal connections from unexpected sources
• Behavioral analysis of systems acting as network relays

6. EVASION & ANTI-ANALYSIS TECHNIQUES

Analyst note: Evasion techniques make malware harder to analyze in security research environments and harder to detect in production. When malware checks for virtual machines or debuggers before executing, automated sandbox reports may show it as benign — masking its actual capabilities. This section documents what Pulsar checks for and what it means for analysis validity.

Pulsar includes multi-layered evasion targeting analysis environments, with the goal of hindering security research and extending operational lifespan on deployed systems.

Anti-VM Detection

CONFIDENCE LEVEL: CONFIRMED (VM detection code present)

What Pulsar Checks For:

Why This Matters:

Most malware analysis occurs in virtual machines. When malware detects a VM environment:

• May refuse to execute (analysis gets no results)
• May enter “harmless mode” (appears benign)
• May intentionally crash (disrupts analysis)

Defender Perspective:

• This is why “just run it in a VM” isn’t always effective
• Requires sandbox solutions that actively hide VM indicators
• May require bare-metal analysis for full behavioral understanding

Anti-Debugger Detection

CONFIDENCE LEVEL: CONFIRMED (debugger detection code present)

Techniques Used:

1. IsDebuggerPresent() - Windows API check for attached debugger
2. NtQueryInformationProcess() - Lower-level kernel query
3. Timing checks - Detects slowdown caused by single-stepping
4. Thread manipulation detection - Identifies debugging activity

Impact on Analysis:

When security researchers attempt to step through code line-by-line, malware:

• Detects debugging and alters behavior
• May take different code paths hiding malicious functionality
• Can intentionally crash or terminate

Why this matters for defenders:

• Makes understanding full malware capabilities more difficult
• Requires advanced analysis techniques (behavioral, memory-level)
• Indicates professional development and serious intent

Sandbox Evasion

CONFIDENCE LEVEL: CONFIRMED (sandbox detection code present)

Detects:

• Sandboxie - Checks for SbieDll.dll
• ThreatExpert - Looks for dbghelp.dll in specific configurations
• Generic sandbox indicators - Unusual environment variables, specific registry keys

Methods:

• DLL enumeration to detect sandbox-injected libraries
• Registry key checks for sandbox-specific entries
• Environment variable analysis

Real-world impact:

• Automated sandbox analysis may not reveal full capabilities
• “File is clean” verdict from automated analysis may be incorrect
• Requires manual analysis or advanced sandbox solutions

Cryptographic Obfuscation

CONFIDENCE LEVEL: CONFIRMED (cryptographic code present)

The malware uses:

• RSA/large integer constants - Asymmetric encryption for key exchange
• Base64 encoding - String obfuscation
• SipHash - Fast cryptographic hashing for integrity verification

Impact:

• Static analysis (reading the code) is difficult without decryption
• Configuration data and C2 addresses are encrypted
• Complicates signature-based detection

7. INCIDENT RESPONSE PROCEDURES

Executive Impact Summary

Response Urgency: Critical — Immediate isolation required Business Disruption: High — System rebuilds may be necessary Decision Complexity: High — Rebuild vs. cleanup requires careful consideration

Quick Verification Guide

Before launching full incident response, verify actual compromise:

1. Run hash check (PowerShell script above) - 10 minutes
2. Check registry persistence (PowerShell script above) - 2 minutes
3. Review recent network connections to paste sites - 5 minutes
4. Check for suspicious processes (usbmmsvc64.exe, unknown conhost.exe) - 5 minutes

If ANY of these checks show indicators, proceed with full IR:

Priority 1: Immediate Response (CRITICAL - Confirmed Compromise)

Isolation (Do First)

1. Network isolation - Physically disconnect network cable (preferred) OR disable network adapter
2. WiFi isolation - Disable WiFi hardware switch or adapter
3. USB removal - Disconnect all USB network adapters
4. Keep system powered on - Do NOT shut down (preserves memory for forensics)
5. Document time - Record exact time of isolation for incident timeline

Why we isolate but don’t shut down:

• Prevents continued C2 communication and data exfiltration
• Preserves volatile memory (RAM) containing encryption keys, active connections
• Allows forensic memory capture before evidence is lost

Alert Leadership

1. Notify security leadership immediately — this is a critical security incident
2. Notify Legal — potential data breach with regulatory implications
3. Establish incident command — designate an incident commander and define roles

Why early leadership notification matters:

• RAT compromises often trigger breach notification obligations
• Legal privilege may apply to investigation communications
• Resource allocation decisions are needed quickly

Preserve Evidence

1. Memory dump - Capture RAM before system powers off
   • Tools: Magnet RAM Capture (free), winpmem, FTK Imager
   • Save to external drive, not compromised system
2. Document system state - Screenshot running processes, network connections
3. Initiate chain of custody - Log who handles evidence, when, why
4. Plan forensic imaging - Prepare clean write-blocker and forensic workstation
5. Do NOT reboot before imaging (destroys memory evidence)

Why evidence preservation matters:

• Supports law enforcement investigation if pursued
• Supports root cause analysis and lessons learned
• Demonstrates due diligence for regulatory and legal purposes

Credential Rotation - Phase 1 (Immediate)

CRITICAL: Assume all credentials used on infected system are compromised

1. Reset user account password - All accounts logged into compromised system
2. Reset service accounts - Any service accounts with cached credentials
3. Reset admin passwords - Any administrator accounts used on system
4. Force re-authentication - Invalidate all active sessions for affected accounts
5. Enable MFA - If not already enabled, require multi-factor authentication

Important: Change passwords from a DIFFERENT, CLEAN system. Do not change passwords from the compromised system (malware may capture new passwords).

Prioritization:

1. Domain administrator accounts (highest impact)
2. Service accounts with broad access
3. Financial/banking application credentials
4. Email and communication system accounts
5. Standard user accounts

Block C2 Infrastructure (Network Level)

1. Block paste sites (see considerations below) - pastebin.com, paste.ee, hastebin.com
2. Block geolocation services - ipwho.is, ip-api.com
3. Block identified C2 IPs/domains - If any identified from network logs
4. Monitor for C2 attempts - Set up alerts for blocked connection attempts
5. Document blocks - Maintain list of what was blocked and when

Note: See “Pastebin Blocking Decision Framework” section for business impact considerations.

Priority 2: Investigation Phase

Deploy Detection Signatures

1. Deploy YARA rule to EDR/AV platforms across environment
2. Deploy network signatures to IDS/IPS (if C2 traffic patterns identified)
3. Update SIEM with behavioral detection rules (threat hunting queries)
4. Enable enhanced logging - Process creation, registry changes, file access
5. Alert SOC team - Brief on indicators and expected alert patterns

Network-Wide Threat Hunt

Assumption: If one system is infected, others may be as well

1. Run YARA across all systems - Endpoint sweep for file hash matches
2. Search for IOC hashes - File hash search across file servers, workstations
3. Scan registry keys - Automated check for RunOnce persistence across fleet
4. Check for services - Look for suspicious or unauthorized services
5. Review network connections - Identify other systems connecting to paste sites

Tools for enterprise threat hunting:

• SIEM correlation (hunting queries provided in Section 5)
• EDR platform capabilities (fleet-wide process, file, and registry search)
• PowerShell remoting for script execution across multiple systems
• Active Directory log analysis for unusual authentication patterns

Priority 3: Remediation Phase

Forensic Analysis

1. Complete disk imaging - Forensic bit-for-bit image of compromised system
2. Memory analysis - Analyze captured RAM dump for artifacts
3. Timeline analysis - Reconstruct sequence of events from logs and artifacts
4. Malware extraction - Safely extract malware sample for further analysis
5. Chain of custody maintenance - Document all evidence handling

Forensic Questions to Answer:

• When did initial infection occur?
• How did malware arrive (email, download, USB, network share)?
• What data was accessed or exfiltrated?
• Were other systems compromised from this pivot point?
• What was the extent of attacker activity?

Scope Assessment

1. Identify affected user accounts - All accounts used on compromised system
2. Identify accessed data - File access logs, database query logs
3. Identify network propagation - Lateral movement to other systems
4. Identify external communication - Data exfiltration volumes, C2 communication
5. Regulatory impact assessment - Determine if breach notification required

Breach Notification Triggers (varies by jurisdiction): Confirmed data exfiltration may trigger notification obligations under applicable data protection regulations (personal data, health data, payment card data). Notification scope and timeline depend on jurisdiction and the categories of data accessible on affected systems — engage legal counsel to assess.

Priority 4: Remediation Decision Framework

The Critical Question: Rebuild vs. Cleanup? This is often the most contentious decision in incident response. Here’s an evidence-based framework.

OPTION A: Complete System Rebuild (RECOMMENDED)

When this is MANDATORY:

1. WinRE persistence confirmed or strongly suspected (recovery partition accessed)
2. Administrative privileges confirmed compromised
3. System contains or accesses highly sensitive data (financial, healthcare, trade secrets)
4. Applicable compliance or regulatory requirements mandate an assured clean state
5. Multiple persistence mechanisms detected
6. Attacker dwell time exceeds an extended period (greater opportunity for additional implants)

When this is STRONGLY RECOMMENDED:

1. WinRE persistence cannot be definitively ruled out
2. EDR/advanced logging was not present before infection (full attacker activity cannot be reconstructed)
3. Any uncertainty remains about the scope of compromise
4. The organization has resources and processes for rebuild

Rebuild Process: See Appendix A.1 for detailed step-by-step procedures

Business Impact:

• Downtime: Several hours per system
• IT effort: Several hours per system
• Risk reduction: Highest assurance of clean state

OPTION B: Aggressive Cleanup (HIGHER RESIDUAL RISK)

ONLY consider this when:

1. WinRE persistence DEFINITIVELY ruled out (recovery partition forensically analyzed, confirmed clean)
2. Full EDR visibility existed BEFORE and DURING infection (complete attacker activity logged)
3. System does NOT contain/access sensitive data
4. Business continuity demands (critical system, rebuild timeline unacceptable)
5. A skilled incident response team is available for thorough cleanup
6. Residual risk is accepted and compensated with intensive monitoring

WARNING: Cleanup is inherently less reliable than rebuild

Industry IR guidance consistently recommends rebuild over cleanup for any compromise involving administrative access or unknown persistence mechanisms. Re-infection after partial remediation is a common and well-documented outcome in post-incident reporting.

If cleanup is pursued despite the risks:

1. Boot into Safe Mode or WinPE (prevents malware execution during cleanup)

2. Remove registry persistence (15 minutes):

   # VERIFY BEFORE DELETING - ensure these are malicious
   # Document what you're removing
   Remove-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce" -Name [suspicious_entry]
   Remove-ItemProperty -Path "HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce" -Name [suspicious_entry]
   

3. Remove filesystem persistence (30 minutes):
   • Delete malware executable (verify hash first)
   • Remove any dropped files in AppData, Temp directories
   • Check startup folders for malicious entries

4. Clean recovery partition (significant time) - HIGH RISK OPERATION: See Appendix A.2 for detailed procedures

5. Anti-malware scan (several hours):
   • Run multiple AV engines (Microsoft Defender, Malwarebytes, etc.)
   • Run rootkit scanner (GMER, TDSSKiller)
   • Scan in both Safe Mode and Normal Mode
6. System integrity checks (30 minutes):
   • Run System File Checker: sfc /scannow
   • Run DISM repair: DISM /Online /Cleanup-Image /RestoreHealth
7. Enhanced monitoring (extended period):
   • Daily EDR review for this system
   • User awareness training (report ANY unusual behavior)
   • Network traffic analysis for C2 indicators
   • Be prepared to rebuild if ANY signs of re-infection

Business Impact:

• Downtime: Several hours initially, plus ongoing monitoring overhead
• Risk: Moderate-High residual risk of incomplete remediation

Residual Risk with Cleanup:

• Unknown persistence mechanisms may survive
• Malware may have installed additional backdoors not yet detected
• Attacker may maintain access through undiscovered means
• Re-infection may occur without obvious indicators

Decision Matrix

Use this matrix to guide the rebuild vs. cleanup decision:

Scoring:

• 8+ points for rebuild: Rebuild is clearly recommended
• 5-7 points either: Rebuild recommended unless strong business justification for cleanup
• 8+ points for cleanup: Cleanup may be considered with intensive monitoring

In practice: Most enterprise security teams default to rebuild for any RAT compromise due to superior assurance and lower long-term risk.

8. LONG-TERM DEFENSIVE STRATEGY

Executive Impact Summary

Implementation Timeline: Several weeks for initial EDR deployment Business Impact: Some operational disruption during deployment Risk Reduction: High — Prevents most commodity malware execution

Endpoint Security Enhancements

Deploy EDR (Endpoint Detection & Response):

EDR provides continuous behavioral monitoring, real-time threat detection, automated isolation capabilities, and threat hunting. Behavioral EDR detects evasive malware like Pulsar that signature-based antivirus misses because it monitors what the process does, not just what it looks like.

Application Control (Application Whitelisting):

Application control allows only approved executables to run, blocking unauthorized .NET applications including Pulsar. Initial deployment requires an application inventory and policy creation (typically several weeks); ongoing maintenance involves approving new legitimate applications. Moderate operational impact during rollout; high security benefit once established.

Credential Protection:

Credential Guard:

• Hardware-based credential isolation (requires Enterprise license and Hyper-V capable CPU)
• Protects against credential dumping attacks

Best Practices:

• Enforce complex passwords (minimum 14 characters)
• Mandatory MFA for all remote access
• Privileged Access Workstations (PAWs) for admin accounts
• Regular password rotation for service accounts

Network Security Hardening

Network Segmentation:

Why it matters for RAT mitigation:

• Limits lateral movement scope
• Contains compromise to single segment
• Enables segment-specific monitoring

Implementation:

• Separate VLANs for workstations, servers, management
• Firewall rules restricting inter-segment traffic
• Monitor and alert on segment-crossing connections

Business benefit: Even if one workstation is compromised, database servers in different segment remain protected.

DNS Filtering & Monitoring:

DNS filtering blocks known-malicious domains and reveals suspicious query patterns. Pulsar’s paste site queries are visible in DNS logs even when HTTPS prevents content inspection — making DNS an effective detection layer for this specific C2 mechanism.

Egress Filtering:

Traditional approach: Allow all outbound traffic (only filter inbound)

Better approach:

• Whitelist approved outbound destinations
• Monitor and alert on outbound connections to unknown destinations
• Block by default, allow by exception

Business impact: Moderate implementation effort, but prevents data exfiltration to attacker infrastructure.

Pastebin Blocking Analysis: See Appendix B for detailed business impact analysis and implementation strategies

Threat Monitoring & Detection

SIEM Rules (Critical for Early Detection):

Implement detection rules for:

• Process injection attempts
• Credential access activities (browser password database access)
• Unusual network connections (paste sites from workstations)
• Registry persistence modifications
• Recovery partition access attempts

Behavioral Analytics:

Modern security platforms can detect:

• Processes exhibiting unusual behavior (legitimate process accessing unusual files)
• Data access patterns inconsistent with user role
• Network communication patterns matching C2 profiles
• Unusual authentication patterns (credential stuffing after compromise)

User Awareness & Training

Security Awareness Training:

Training covers phishing recognition (suspicious attachments, urgency tactics, unusual senders), safe computing practices (not running unknown executables, reporting suspicious emails), and a low-penalty incident reporting culture that encourages early escalation.

Phishing simulation programs measure click and reporting rates over time and direct targeted training to users who fall for simulations.

9. FAQ - ADDRESSING COMMON QUESTIONS

Q1: “How do I know if my system has WinRE persistence?”

Short answer: Difficult to confirm without specialized tools and expertise.

Safe verification steps:

1. Check if WinRE is enabled:

   reagentc /info
   

   If disabled, WinRE persistence unlikely (but check why it’s disabled)

2. Check for recovery partition:

   Get-Partition | Where-Object {$_.Type -eq 'Recovery'}
   

   If no recovery partition exists, WinRE persistence impossible

3. For definitive verification:
   • Engage forensic specialist
   • Create forensic image of recovery partition
   • Mount in read-only mode in isolated environment
   • Analyze contents for non-OEM files
   • Compare against known-good recovery partition from same hardware model

Manual inspection of recovery partitions without forensic training risks rendering the system unbootable or destroying evidence.

Practical guidance: Given the verification difficulty, the default recommendation when WinRE-capable malware was present is system rebuild — unless forensic analysis can definitively rule out recovery partition compromise.

Q2: “Can the recovery partition be cleaned instead of rebuilding?”

Short answer: Risky — malware may have additional persistence mechanisms not yet found.

The core problem:

• Malware often implements multiple persistence mechanisms
• WinRE persistence may be just one of several
• Cleaning one mechanism does not guarantee removal of others
• A single missed mechanism means the attacker retains access

Industry incident response guidance consistently identifies partial remediation as a leading cause of re-infection, particularly in cases involving administrative access or unknown persistence mechanisms.

If cleanup is attempted:

• Complete forensic analysis first (understand all attacker activity)
• Remove all identified persistence mechanisms simultaneously
• Maintain intensive extended monitoring
• Prepare to rebuild at the first sign of re-infection

Default recommendation: System rebuild eliminates uncertainty and provides the highest assurance of clean state.

Q3: “Is blocking Pastebin really necessary?”

Short answer: Not always — depends on the environment, risk tolerance, and monitoring capabilities.

Reality check:

• Pastebin blocking is ONE control, not a silver bullet
• Sophisticated attackers can easily switch to alternative infrastructure
• Business disruption must be weighed against security benefit
• Alternative approaches exist (see “Pastebin Blocking” section)

What security research shows:

• Blocking paste sites reduces C2 success for commodity malware (high volume, low sophistication)
• Targeted attackers adapt quickly to blocks (use alternative infrastructure)
• Monitoring may be more valuable than blocking for threat intelligence

Recommended instead of blanket blocking:

1. With EDR/strong monitoring: Monitor paste site access, alert on unusual patterns
2. Without EDR: Selective blocking (allow for developer VLANs, block elsewhere)
3. High-security environments: Block with an internal paste service as alternative
4. Developer-heavy environments: Monitor-only with behavior-based alerting

See detailed analysis in “Pastebin Blocking: A Realistic Analysis” section.

Q4: “What if rebuilding every potentially affected system is not feasible?”

Short answer: Prioritize based on risk, with the understanding that systems not rebuilt carry residual compromise risk.

Risk-based prioritization framework:

TIER 1 - MUST REBUILD (highest priority):

• Systems with confirmed malware presence (hash match, confirmed IOCs)
• Systems with administrative access to critical infrastructure
• Systems accessing sensitive data (financial, healthcare, PII, trade secrets)
• Systems with confirmed WinRE partition access in logs
• Domain controllers, servers, critical infrastructure

TIER 2 - SHOULD REBUILD (medium priority):

• Systems in same network segment as confirmed infections
• Systems with same user accounts as confirmed compromised accounts
• Systems showing suspicious but not definitive indicators
• Systems with administrative privileges in any domain

TIER 3 - MONITOR INTENSIVELY (lower priority):

• Systems with no indicators but in potentially affected environment
• Standard user workstations in isolated segments
• Systems with comprehensive EDR logging available for review
• Systems without access to sensitive data

For Tier 3 systems (if rebuild not feasible):

• Deploy or upgrade EDR if not present
• Enhanced monitoring for extended period
• User awareness (report ANY unusual behavior)
• Priority response if any indicators detected
• Plan to rebuild if compromise confirmed

Efficiency strategies:

• Automated rebuild process reduces per-system effort
• Image-based deployment (network imaging) reduces rebuild time significantly
• Phased approach: critical systems first, lower-risk systems over time

Risk tradeoff: Rebuild removes a known, bounded risk. Accepting a retained compromise preserves an unknown, open-ended risk that may expand over time.

Q5: “Our antivirus didn’t detect this - is our AV worthless?”

Short answer: No, but AV alone is insufficient for modern threats.

Why traditional AV missed this:

1. Signature-based detection limitations:
   • Pulsar can be repacked/obfuscated (changes signature)
   • New variants appear faster than signature updates
   • AV vendors may not have sample yet
2. .NET malware challenges:
   • .NET code is more difficult for static analysis
   • Obfuscation tools readily available
   • JIT compilation makes some analysis harder
3. Evasion techniques:
   • Pulsar actively detects and evades sandbox analysis
   • Encrypted strings hide suspicious content
   • Legitimate components (drivers) used for malicious purposes

This doesn’t mean AV is worthless:

• Still catches a significant portion of commodity malware with known signatures
• An important defense-in-depth layer
• Detects known variants and related families

What you need BEYOND AV:

• EDR: Behavioral detection catches what signature-based AV misses
• Network monitoring: Detects C2 communication even if endpoint infection undetected
• User awareness: Prevents execution in first place
• Application control: Prevents unauthorized execution regardless of AV detection

Modern security approach: “Defense in Depth”

• AV is ONE layer, not the ONLY layer
• Multiple controls means one failure doesn’t equal breach
• Assume one control will fail, ensure others can compensate

Q6: “How long might attackers have had access before detection?”

Short answer: Unknown without forensic analysis - could be days to months.

What affects dwell time:

Factors REDUCING detection time: ✓ EDR present and monitored ✓ SIEM with behavioral analytics ✓ Active threat hunting program ✓ User reports suspicious activity ✓ Automated security alerting

Factors INCREASING dwell time: ✗ No EDR or security monitoring ✗ AV-only security posture ✗ Limited logging retention ✗ No SOC or security team monitoring ✗ Sophisticated attacker operational security

Industry data: Published incident response reports consistently show median dwell times measured in days to weeks for externally detected compromises, and shorter windows for organizations with mature internal detection. Advanced persistent threat (APT) dwell times are routinely measured in months. The key variable is the quality of endpoint and network monitoring in place at the time of infection.

For this specific case:

Forensic analysis can determine:

• File creation timestamps (when malware first appeared)
• Registry modification times (when persistence established)
• Log correlation (when C2 communications began)
• User account timeline (credential theft timing)
• File access logs (what data was accessed, when)

What to assume if forensics not available:

• Conservative estimate: Assume compromise since last known-clean state
• For critical decisions (breach notification): Assume worst-case timeline
• For scoping: Assume all activity during possible window is potentially compromised

Practical guidance:

• Early stage: Limited attacker reconnaissance, probably automated credential theft only
• Mid stage: Possible manual attacker activity, network reconnaissance, lateral movement attempts
• Extended stage: Assume comprehensive reconnaissance, possible additional implants, potential data staging for exfiltration

10. KEY TAKEAWAYS - WHAT MATTERS MOST

1. Complete System Compromise — Understand the Scope

Pulsar RAT is not ransomware with a specific destructive purpose, nor spyware with a single objective. It is a universal remote control tool — attackers can do anything a user can do, plus administrative actions. Any infected system should be treated as if an attacker is at the keyboard.

Practical implications: Every credential used on the infected system is exposed. Every data asset accessible to the compromised account is exposed. Every system reachable from that network location is at risk. Active MFA sessions during the compromise window may have been bypassed.

2. Persistence — Understanding the Real Risk

Registry RunOnce persistence (CONFIRMED) survives reboots but not OS reinstallation and is detectable by EDR.

WinRE persistence (HIGH confidence — code present) may survive standard OS reinstallation in some scenarios. It does not survive a complete disk wipe or full repartitioning. Effectiveness depends on the specific recovery procedures used. Assume the capability is present; verify on specific systems; default to rebuild where forensic exclusion is not possible. This technique is serious but not undefeatable with proper remediation. See Section 6.1 for the full scenario matrix.

3. Professional Development — Not Casual Malware

Pulsar’s modular architecture, async/await patterns, Windows CNG cryptography, and HVNC implementation reflect organized development effort, not commodity assembly. The Quasar RAT open-source base means wide availability — professional build quality does not automatically imply APT attribution. Financial motivation aligns with the credential harvesting and clipboard hijacking capabilities observed (MODERATE confidence).

4. Detection — Hard, But Not Impossible

Encrypted C2, dynamic infrastructure, anti-analysis checks, and legitimate signed drivers make detection harder than commodity malware. Behavioral EDR, comprehensive SIEM logging, paste-site egress monitoring, and memory forensics can all detect this family. Hard to detect is not the same as undetectable. See the sidebar for specific YARA and Sigma rules.

5. Business Impact

Direct: Incident response effort, system rebuilds, credential rotation.

Indirect: Productivity loss, regulatory notification obligations (if data exfiltration confirmed), legal engagement, potential reputational harm from disclosed breach.

11. Response Timeline — Recommended Actions

Confirmed Infection

Initial Response:

1. Isolate affected systems from the network (physical cable disconnect preferred over software disable)
2. Do NOT shut down — preserve volatile memory evidence
3. Alert security leadership immediately
4. Document timeline and initial observations

Response Phase 1:

1. Capture memory dump before any system shutdown
2. Reset credentials for all accounts used on the infected system
3. Block C2 infrastructure at the network perimeter
4. Notify legal; begin breach notification assessment
5. Begin evidence preservation (chain of custody)

Response Phase 2:

1. Deploy detection signatures across the environment (sidebar → detections page)
2. Initiate a network-wide threat hunt for lateral spread
3. Collect and analyze event logs
4. Assess scope: systems affected, data accessed, accounts compromised

Response Phase 3:

1. Complete forensic imaging
2. Breach notification assessment (legal-led, based on data access findings)
3. Remediation decision: rebuild vs. cleanup (see Section 7, Priority 4)

Proactive Threat Hunting (No Confirmed Infection)

Immediate:

1. Run hash searches against critical systems first, then all systems
2. Deploy YARA rule to endpoint security platforms (sidebar → detections page)
3. Run registry persistence checks
4. Review egress logs for paste site connections from unexpected hosts

This Week:

1. Deploy SIEM hunting queries (Section 5)
2. Review security control gaps identified in this report
3. Assess current EDR and monitoring capabilities

This Month:

1. Evaluate and deploy behavioral EDR if not present
2. Implement application control (phased rollout)
3. Review and enhance network segmentation

This Quarter:

1. Mature threat hunting program and coverage
2. Implement long-term defensive strategy recommendations (Section 8)
3. Test backup and restore procedures
4. Conduct tabletop exercise using this campaign as a scenario

License

© 2026 Joseph. All rights reserved. See LICENSE for terms.