ThreatFox: VShell IOCs

Hunt Hypothesis

This detection rule identifies adversary activity involving specific Indicators of Compromise (IOCs) linked to the VShell remote access tool, which is frequently leveraged by threat actors for initial access and lateral movement. Proactively hunting for these IOCs within Azure Sentinel allows the SOC team to rapidly detect and respond to potential unauthorized remote sessions before adversaries can establish persistence or exfiltrate sensitive data.

IOC Summary

Malware Family: VShell Total IOCs: 2 IOC Types: ip:port

KQL: Ip Hunt

// Hunt for network connections to known malicious IPs
// Source: ThreatFox - VShell
let malicious_ips = dynamic(["8.148.13.91", "38.47.102.194"]);
CommonSecurityLog
| where DestinationIP in (malicious_ips) or SourceIP in (malicious_ips)
| project TimeGenerated, SourceIP, DestinationIP, DestinationPort, DeviceAction, Activity
| order by TimeGenerated desc

KQL: Ip Hunt Device

// Hunt in Defender for Endpoint network events
let malicious_ips = dynamic(["8.148.13.91", "38.47.102.194"]);
DeviceNetworkEvents
| where RemoteIP in (malicious_ips)
| project Timestamp, DeviceName, RemoteIP, RemotePort, InitiatingProcessFileName, ActionType
| order by Timestamp desc

Required Data Sources

References

• ThreatFox — VShell

False Positive Guidance

Here are specific false positive scenarios and corresponding exclusion strategies for the ThreatFox: VShell IOCs detection rule in an enterprise environment:

• Scenario: Automated Vulnerability Scanning by Enterprise Security Suite

  • Context: Scheduled vulnerability scans performed by tools like Tenable Nessus, Qualys, or Microsoft Defender for Endpoint often utilize the VShell protocol to query device configurations and verify agent health. These scanners generate traffic matching the VShell IOCs as they probe endpoints across the network during off-hours maintenance windows.
  • Filter/Exclusion: Create a rule exclusion based on the source IP ranges of the scanning servers (e.g., 10.50.20.0/24) and restrict the alert to non-scan hours or specific user accounts used by the scanner service (e.g., svc_nessus, qualys_agent).

• Scenario: Legacy Application Migration via PowerShell Scripts

  • Context: During IT migration projects, System Administrators often execute custom PowerShell scripts that leverage VShell to migrate data or update configurations on legacy servers. These scripts may be triggered by Azure Automation Accounts or Ansible Tower, generating legitimate IOCs as they establish secure shell connections to target hosts.
  • Filter/Exclusion: Exclude alerts where the process name matches known automation tools (e.g., pwsh.exe, ansible-runner) and the source user is a recognized service account (e.g., svc_migration, admin_ansible). Additionally, filter by specific destination ports if the migration targets a distinct subnet.

• Scenario: Third-Party Backup Solution Connectivity Checks

  • Context: Enterprise backup solutions such as Veeam Backup & Replication, Rubrik, or Commvault frequently use VShell connections to perform pre-backup health checks, inventory collection,