ThreatFox: VShell IOCs | SOC Hunt Feed

Hunt Hypothesis

This detection identifies adversary activity involving four specific Indicators of Compromise (IOCs) linked to the VShell threat actor, signaling potential reconnaissance or initial access attempts within the environment. A proactive hunt is essential in Azure Sentinel to rapidly validate these IOCs against current telemetry, enabling the SOC team to isolate compromised assets before the adversary establishes persistence or exfiltrates sensitive data.

IOC Summary

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

Type	Value	Threat Type	First Seen	Confidence
ip:port	`1[.]14[.]193[.]53:7717`	botnet_cc	2026-08-11	100%
ip:port	`101[.]32[.]34[.]248:8084`	botnet_cc	2026-08-11	100%
ip:port	`166[.]0[.]27[.]224:8084`	botnet_cc	2026-08-11	100%
ip:port	`101[.]132[.]120[.]245:8084`	botnet_cc	2026-08-11	100%

KQL: Ip Hunt

// Hunt for network connections to known malicious IPs
// Source: ThreatFox - VShell
let malicious_ips = dynamic(["101.132.120.245", "166.0.27.224", "1.14.193.53", "101.32.34.248"]);
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(["101.132.120.245", "166.0.27.224", "1.14.193.53", "101.32.34.248"]);
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

Here are the false positive scenarios and corresponding filters for the ThreatFox: VShell IOCs detection rule:

Scenario 1: Scheduled Patch Deployment via Admin Workstations
- Context: Enterprise patch management systems (e.g., Microsoft SCCM, Ivanti, or WSUS) often push security updates to the VShell service during nightly maintenance windows. The update installer may generate network connections matching the VShell IOCs as part of its verification routine, triggering a hit on the detection rule even though no malicious activity is occurring.
- Filter/Exclusion: Create an exclusion based on Source Host and Time Window. Exclude alerts where the source host belongs to the Patch-Management OU (Organizational Unit) or specific IP ranges of known patch servers, limited to the maintenance window (e.g., 02:00 – 04:00 UTC).
Scenario 2: Legitimate Remote Administration by Helpdesk
- Context: Tier-1 and Tier-2 support staff frequently use remote management tools like Microsoft System Center Configuration Manager (SCCM) or BeyondTrust to troubleshoot user sessions. When an admin initiates a remote session that interacts with the VShell service, the tool’s background processes may trigger the specific IOCs associated with VShell communication patterns.
- Filter/Exclusion: Implement a filter excluding alerts where the User Account is part of the Helpdesk-Admins or IT-Support groups. Additionally, exclude traffic originating from known jump-host IPs (e.g., 10.x.x.50-60) used for secure remote access.
Scenario 3: Automated Backup and Compliance Scans
- Context: Enterprise backup solutions such as Veeam, Rubrik, or