ThreatFox: Ghost RAT IOCs

Hunt Hypothesis

This detection rule identifies the presence of four specific indicators of compromise linked to the Ghost Remote Access Trojan (RAT), which adversaries deploy to establish persistent access and exfiltrate sensitive data from compromised endpoints. A proactive hunt in Azure Sentinel is critical because Ghost RAT often operates stealthily within legitimate network traffic, requiring early identification of these IOCs to prevent lateral movement and potential data breaches before they escalate.

IOC Summary

Malware Family: Ghost RAT Total IOCs: 4 IOC Types: domain, ip:port

KQL: Ip Hunt

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

KQL: Domain Hunt

// Hunt for DNS queries to known malicious domains
// Source: ThreatFox - Ghost RAT
let malicious_domains = dynamic(["shdufysuf.com", "airuhuo.xyz"]);
DnsEvents
| where Name has_any (malicious_domains)
| project TimeGenerated, Computer, Name, IPAddresses, QueryType
| order by TimeGenerated desc

Required Data Sources

References

• ThreatFox — Ghost RAT

False Positive Guidance

Here are 5 specific false positive scenarios for the ThreatFox: Ghost RAT IOCs detection rule, including suggested filters and exclusions:

• Scenario: Security Team Manual IOC Hunting

  • Context: The Threat Intelligence team is actively investigating a new campaign and manually ingests the “Ghost RAT” IOC set into their SIEM or EDR platform (e.g., Microsoft Defender for Endpoint or Splunk) to verify current coverage. This triggers the rule as if a live threat was detected, even though it is a controlled test.
  • Filter/Exclusion: Exclude events where the Initiating Process belongs to known security management tools (e.g., defender-sensor.exe, splunkd.exe) or where the User Account matches a specific “SOC_Admin” group. Alternatively, add a tag-based exclusion for events marked with Tag: ThreatIntel_Test.

• Scenario: Scheduled Endpoint Vulnerability Scanning

  • Context: An enterprise vulnerability management tool (e.g., Tenable Nessus or Qualys) is configured to run nightly scans that include an IOC matching engine. The scanner queries the Ghost RAT signature database, generating network traffic and file hash matches that mimic a real infection on multiple endpoints simultaneously.
  • Filter/Exclusion: Create a time-based exclusion window (e.g., 02:00 – 04:00 UTC) for events originating from the specific service accounts used by the scanner (e.g., NT SERVICE\TenableAgent). Filter out alerts where the Parent Process is the vulnerability scanner’s agent executable.

• Scenario: Automated Software Deployment via Configuration Management

  • Context: The IT Operations team uses a configuration management tool like Ansible or SCCM to deploy a new security policy update that includes the Ghost RAT signature definitions across the fleet. During the deployment phase