ThreatFox: Sliver IOCs

Hunt Hypothesis

This detection rule identifies adversary activity involving the Sliver C2 framework by monitoring for three specific indicators of compromise that signal potential command and control communications or lateral movement within the network. Proactively hunting for these IOCs in Azure Sentinel is critical to rapidly detect and contain sophisticated post-exploitation operations before adversaries can establish persistent access or exfiltrate sensitive data.

IOC Summary

Malware Family: Sliver Total IOCs: 3 IOC Types: ip:port

KQL: Ip Hunt

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

Required Data Sources

References

• ThreatFox — Sliver

False Positive Guidance

Here are specific false positive scenarios and corresponding filters for the ThreatFox: Sliver IOCs detection rule, tailored for a legitimate enterprise environment:

• Scenario: Scheduled Antivirus or EDR Scans

  • Context: Enterprise Endpoint Detection and Response (EDR) agents like CrowdStrike Falcon, SentinelOne, or Microsoft Defender for Endpoint periodically perform deep scans that generate network traffic matching Sliver’s communication patterns (e.g., specific TLS JA3 fingerprints or port usage). These scans often trigger the 3-IOC hunt logic when the agent communicates with its cloud update servers.
  • Filter/Exclusion: Exclude traffic originating from known EDR service accounts (e.g., svc-crowdstrike, msdefender) and restrict the rule to exclude specific destination IP ranges belonging to the vendor’s update infrastructure (e.g., *.crowdstrike.com, *.microsoft.com).

• Scenario: Automated Software Deployment via Configuration Management

  • Context: Tools like Ansible, Puppet, or Microsoft SCCM/Intune push software updates and configuration changes to endpoints. During these deployment windows, the management server initiates connections that mimic Sliver’s beaconing behavior, particularly when using encrypted channels over standard ports (443) with specific User-Agent strings.
  • Filter/Exclusion: Create a whitelist for source IPs belonging to the Configuration Management infrastructure and exclude events where the process name matches known deployment tools (e.g., ccmsetup.exe, puppet-agent, ansible-runner) running under the context of the local system or dedicated service accounts.

• Scenario: Internal Backup and Data Replication Jobs

  • Context: Scheduled backup jobs using solutions like Veeam, Rubrik, or Commvault often establish persistent connections to central repositories. These