This hunt targets the presence of DCRat IOCs to identify potential ransomware activity or initial access footholds within the environment. Proactively hunting for these indicators is critical because DCRat is a high-severity threat often associated with data exfiltration and encryption, allowing the SOC to detect and isolate compromised assets before the adversary achieves full lateral movement or impact.
Malware Family: DCRat Total IOCs: 4 IOC Types: ip:port
| Type | Value | Threat Type | First Seen | Confidence |
|---|---|---|---|---|
| ip:port | 46[.]246[.]6[.]18:8848 | botnet_cc | 2026-09-18 | 75% |
| ip:port | 45[.]202[.]0[.]48:8443 | botnet_cc | 2026-09-18 | 75% |
| ip:port | 45[.]202[.]0[.]55:8443 | botnet_cc | 2026-09-18 | 75% |
| ip:port | 191[.]107[.]92[.]58:9002 | botnet_cc | 2026-09-18 | 75% |
// Hunt for network connections to known malicious IPs
// Source: ThreatFox - DCRat
let malicious_ips = dynamic(["45.202.0.55", "46.246.6.18", "45.202.0.48", "191.107.92.58"]);
CommonSecurityLog
| where DestinationIP in (malicious_ips) or SourceIP in (malicious_ips)
| project TimeGenerated, SourceIP, DestinationIP, DestinationPort, DeviceAction, Activity
| order by TimeGenerated desc// Hunt in Defender for Endpoint network events
let malicious_ips = dynamic(["45.202.0.55", "46.246.6.18", "45.202.0.48", "191.107.92.58"]);
DeviceNetworkEvents
| where RemoteIP in (malicious_ips)
| project Timestamp, DeviceName, RemoteIP, RemotePort, InitiatingProcessFileName, ActionType
| order by Timestamp desc| Sentinel Table | Notes |
|---|---|
CommonSecurityLog | Ensure this data connector is enabled |
DeviceNetworkEvents | Ensure this data connector is enabled |
Scenario: A DevOps team uses dcstat (or similar DCRat-based tools) as part of a standard CI/CD pipeline to validate Docker image metadata or perform automated security scans on container registries.
jenkins.exe, gitlab-runner.exe, azure-pipelines-agent.exe) or when the working directory is within a designated CI/CD workspace (e.g., C:\jenkins\workspace\, C:\gitlab-runner\builds\).Scenario: A security engineer runs dcstat manually in a controlled lab environment to test new container configurations or to reproduce a specific vulnerability before deploying a fix to production.
env=lab, role=dev).Scenario: An application administrator uses dcstat as part of a scheduled maintenance job to clean up or verify Docker Compose project states in a staging environment.
Task Scheduler entry named “DCRat_Staging_Cleanup”) or where the command line arguments include specific flags associated with the maintenance script (e.g., --verify-only or --cleanup).Scenario: A developer installs dcstat via a package manager (like pip or npm) and runs it locally during the development phase of a new microservice, before it is containerized.