ThreatFox: Aisuru IOCs | SOC Hunt Feed

Hunt Hypothesis

This hunt detects adversary activity linked to the Aisuru threat by correlating network and endpoint telemetry against five specific Indicators of Compromise (IOCs) known to this campaign. Proactively hunting for these signatures in Azure Sentinel is critical because early identification of Aisuru’s unique behavioral patterns enables rapid containment before the threat can establish persistence or exfiltrate sensitive data from the environment.

IOC Summary

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

Type	Value	Threat Type	First Seen	Confidence
ip:port	`206[.]189[.]146[.]157:9035`	botnet_cc	2026-07-14	100%
ip:port	`159[.]89[.]132[.]240:8443`	botnet_cc	2026-07-14	100%
ip:port	`178[.]128[.]208[.]65:9035`	botnet_cc	2026-07-14	100%
ip:port	`206[.]189[.]146[.]157:34567`	botnet_cc	2026-07-14	100%
ip:port	`188[.]166[.]146[.]39:5555`	botnet_cc	2026-07-14	100%

KQL: Ip Hunt

// Hunt for network connections to known malicious IPs
// Source: ThreatFox - Aisuru
let malicious_ips = dynamic(["206.189.146.157", "188.166.146.39", "159.89.132.240", "178.128.208.65"]);
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(["206.189.146.157", "188.166.146.39", "159.89.132.240", "178.128.208.65"]);
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 — Aisuru

False Positive Guidance

Here are specific false positive scenarios for the ThreatFox: Aisuru IOCs detection rule in an enterprise environment, along with recommended filters or exclusions:

Antivirus Definition Updates via Microsoft Endpoint Configuration Manager (MECM)
- Scenario: The organization uses MECM to push daily definition updates for their endpoint protection suite. If the Aisuru malware family shares a common hash or network signature with legitimate update servers (e.g., update.microsoft.com or specific CDN endpoints used by the AV vendor), the deployment of these updates across thousands of workstations may trigger the rule when the AV service contacts the update server to download new signatures.
- Filter/Exclusion: Create a whitelist entry for the specific IP ranges and FQDNs used by the organization’s internal SCCM distribution points and the known public endpoints of the antivirus vendor (e.g., *.update.microsoft.com, *.download.windowsupdate.com). Additionally, exclude process paths matching the AV update service executable (e.g., C:\Program Files\Microsoft Antimalware\MsMpEng.exe or specific vendor executables) when initiating network connections to these trusted destinations.
Scheduled Software Patching via SCCM or Intune
- Scenario: A scheduled job runs weekly on domain-joined servers to apply critical security patches using tools like WSUS or Intune. If the patching agent (e.g., WindowsUpdateAgent or a third-party tool like Ivanti) downloads a specific software installer that contains an embedded library or component matching one of the 5 Aisuru IOCs, the rule will flag this as suspicious activity during the maintenance window.
- Filter/Exclusion: Implement a time-based exclusion for the known maintenance windows (e.g., Sunday 02:00–06:00 UTC) combined with a process filter for the patching agent service