ThreatFox: VShell IOCs | SOC Hunt Feed

Hunt Hypothesis

This hunt identifies potential VShell implant activity by correlating network traffic against known Indicators of Compromise, signaling an adversary’s attempt to establish a persistent, encrypted command-and-control channel. Proactively hunting for these IOCs in Azure Sentinel is critical to detect stealthy backdoor communications before the attacker leverages the VShell framework for lateral movement or privilege escalation.

IOC Summary

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

Type	Value	Threat Type	First Seen	Confidence
ip:port	`173[.]249[.]206[.]44:8084`	botnet_cc	2026-09-11	100%
ip:port	`121[.]41[.]29[.]228:8004`	botnet_cc	2026-09-11	100%
ip:port	`1[.]14[.]120[.]4:8084`	botnet_cc	2026-09-11	100%
ip:port	`154[.]91[.]63[.]114:8074`	botnet_cc	2026-09-11	100%
ip:port	`154[.]91[.]63[.]112:8074`	botnet_cc	2026-09-11	100%

KQL: Ip Hunt

// Hunt for network connections to known malicious IPs
// Source: ThreatFox - VShell
let malicious_ips = dynamic(["154.91.63.114", "154.91.63.112", "1.14.120.4", "173.249.206.44", "121.41.29.228"]);
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(["154.91.63.114", "154.91.63.112", "1.14.120.4", "173.249.206.44", "121.41.29.228"]);
DeviceNetworkEvents
| where RemoteIP in (malicious_ips)
| project Timestamp, DeviceName, RemoteIP, RemotePort, InitiatingProcessFileName, ActionType
| order by Timestamp desc

Required Data Sources

Sentinel Table	Notes
`CommonSecurityLog`	Ensure this data connector is enabled
`DeviceNetworkEvents`	Ensure this data connector is enabled

References

ThreatFox — VShell

False Positive Guidance

Legitimate Use of VShell for Internal Tooling or Development
- Scenario: Developers or DevOps engineers intentionally deploy VShell on staging or development servers to facilitate quick remote debugging, file transfers, or ad-hoc command execution during application testing. The VShell binary or its associated network connections (e.g., WebSocket traffic to a known internal IP) match the IOCs.
- Filter/Exclusion: Exclude processes where the parent process is a known development tool (e.g., code.exe, docker.exe, kubectl.exe) or restrict the detection to production environments only. Alternatively, whitelist VShell instances running on specific hostnames or IP ranges designated for development/staging.
Scheduled Maintenance or Backup Jobs Using VShell
- Scenario: An IT operations team uses VShell as a lightweight remote management tool for specific scheduled tasks, such as log rotation, configuration sync, or backup verification on edge devices or legacy servers. The scheduled task launches the VShell client, triggering the IOC for process creation or network connection.
- Filter/Exclusion: Correlate the VShell process creation with a parent process of schtasks.exe or taskeng.exe (Windows Task Scheduler) or cron (Linux). Exclude VShell processes if the command line arguments contain known maintenance keywords (e.g., “backup”, “sync”, “rotate”) or if the parent process is a recognized service management tool.
Third-Party Monitoring or APM Agents
- Scenario: Application Performance Monitoring (APM) or endpoint detection and response (EDR) agents from vendors like Dynatrace, New Relic, or Datadog may bundle or invoke VShell components for agent management, log collection, or remote configuration updates. The VShell binary or its network behavior matches the IOCs.
- **Filter/Exclusion