ThreatFox: neshta IOCs | SOC Hunt Feed

Hunt Hypothesis

This detection rule identifies adversary activity by monitoring network traffic and endpoint logs against three specific Indicators of Compromise (IOCs) linked to the Neshta threat actor. Proactively hunting for these IOCs in Azure Sentinel is critical because early identification of Neshta’s unique signatures allows the SOC team to isolate affected assets before lateral movement or data exfiltration occurs.

IOC Summary

Malware Family: neshta Total IOCs: 3 IOC Types: md5_hash, sha256_hash, sha1_hash

Type	Value	Threat Type	First Seen	Confidence
md5_hash	`f75568d900a96c55b60e19d0e7670dcf`	payload	2026-08-02	95%
sha256_hash	`b0171c900fcc422ebb4bae4807728717a9f7fd9dce2f6c3735a83196905a2105`	payload	2026-08-02	95%
sha1_hash	`ccc88d2b303448a4d0cac621ab30eb84835de808`	payload	2026-08-02	95%

KQL: Hash Hunt

// Hunt for files matching known malicious hashes
// Source: ThreatFox - neshta
let malicious_hashes = dynamic(["f75568d900a96c55b60e19d0e7670dcf", "b0171c900fcc422ebb4bae4807728717a9f7fd9dce2f6c3735a83196905a2105", "ccc88d2b303448a4d0cac621ab30eb84835de808"]);
DeviceFileEvents
| where SHA256 in (malicious_hashes) or SHA1 in (malicious_hashes) or MD5 in (malicious_hashes)
| project Timestamp, DeviceName, FileName, FolderPath, SHA256, InitiatingProcessFileName
| order by Timestamp desc

Required Data Sources

Sentinel Table	Notes
`DeviceFileEvents`	Ensure this data connector is enabled

References

ThreatFox — neshta

False Positive Guidance

Here are the documented false positive scenarios and corresponding exclusion strategies for the ThreatFox: neshta IOCs detection rule:

Scenario: Enterprise Antivirus Definition Updates
- Context: The organization utilizes CrowdStrike Falcon or Microsoft Defender for Endpoint. During scheduled nightly definition updates, the security agent downloads signature files from upstream repositories that may be hosted on infrastructure sharing IP ranges with the neshta campaign. This triggers a match against the network IOCs in the hunt package.
- Filter/Exclusion: Create an exclusion rule to ignore alerts where the source process is falcon.sys, MsMpEng.exe, or DefenderSvc. Additionally, exclude traffic originating from known vendor update subnets (e.g., 13.0.0.0/8 for Microsoft) during the maintenance window of 02:00–04:00 UTC.
Scenario: Scheduled Backup and Archiving Jobs
- Context: The IT Operations team runs a daily Veeam Backup & Replication job that archives logs to an external cloud storage provider (e.g., AWS S3 or Azure Blob). The destination endpoint for this transfer utilizes a CDN edge node that matches one of the neshta DNS IOCs, causing the hunt package to flag the legitimate backup traffic as suspicious.
- Filter/Exclusion: Implement a logic filter to suppress alerts where the destination port is 443 and the source process name contains “Veeam” or “Backup”. Alternatively, add the specific FQDN of the storage provider (e.g., *.blob.core.windows.net) to the global allow-list for this detection rule.
Scenario: Third-Party SaaS Integration Sync
- Context: The Helpdesk team utilizes a ServiceNow instance that integrates with an