Listen to this Post
Introduction:
Security Operations Centers (SOCs) and Managed Security Service Providers (MSSPs) are constantly battling alert fatigue. Manually enriching each alert to determine its validity consumes valuable time, allowing threats to proliferate within the network. By integrating dynamic malware analysis platforms like ANY.RUN with a Security Information and Event Management (SIEM) system such as Microsoft Sentinel, teams can automate the enrichment process. This integration bridges the gap between detection and decision-making, providing actionable threat intelligence directly within the existing security stack to contain attacks earlier.
Learning Objectives:
- Understand how to integrate a third-party sandbox (ANY.RUN) with Microsoft Sentinel for automated alert enrichment.
- Learn to write Kusto Query Language (KQL) queries to correlate sandbox results with SIEM data.
- Identify the steps to automate threat containment workflows based on dynamic analysis verdicts.
You Should Know:
- The Architecture of Integration: Connecting ANY.RUN to Microsoft Sentinel
The core concept of this integration relies on pushing data from the ANY.RUN sandbox into the Microsoft Sentinel workspace. ANY.RUN can be configured to send task results—including network traffic (PCAPs), extracted hashes, dropped files, and registry changes—to a Sentinel Data Collection Endpoint (DCE) via HTTP. Alternatively, organizations can use a Logic App or an Azure Function to poll the ANY.RUN API for new analyses and ingest them as custom logs.
To verify the connection, you must first obtain the necessary credentials from ANY.RUN (API Key) and from Azure (Workspace ID and Primary Key).
Step-by-step guide to setting up the data connector (Conceptual):
1. Generate ANY.RUN API Key: Log in to ANY.RUN, navigate to your profile settings, and create a new API token with permissions to fetch tasks.
2. Prepare Sentinel Endpoint: In Microsoft Sentinel, go to “Data connectors”. If a native connector isn’t available, you will create a “Custom Log”. This requires defining a sample log file to generate the DCE.
3. Configure the Forwarder: Using a lightweight script (Python or PowerShell) on a Linux or Windows jump box, use cURL or Invoke-WebRequest to pull recent tasks from the ANY.RUN API and push them to the Sentinel DCE.
Linux Command to test API connectivity:
curl -X GET "https://api.any.run/v1/analysis" \ -H "Authorization: API-Key YOUR_ANYRUN_API_KEY" \ -H "Content-Type: application/json"
Windows PowerShell command to push data to Sentinel (example):
This is a simplified example of posting data
$LogEntry = @"
[{\"Timestamp\": \"$(Get-Date -Format o)\", \"AlertID\": \"12345\", \"Verdict\": \"Malicious\"}]
"@
Invoke-WebRequest -Uri "https://YOUR_WORKSPACE_ID.ods.opinsights.azure.com/api/logs?api-version=2016-04-01" `
-Method Post `
-Headers @{"Authorization"= "SharedKey YOUR_WORKSPACE_ID:YOUR_SIGNATURE"; "Log-Type" = "ANYRUN_Alerts"} `
-Body $LogEntry
2. Enriching Alerts with KQL (Kusto Query Language)
Once the data is ingested into Sentinel as a custom table (e.g., ANYRUN_Alerts_CL), SOC analysts can use KQL to correlate this threat intelligence with their existing security alerts. Instead of manually switching contexts, the analyst can run a query that joins a Windows Event log (like SecurityEvent) with the ANYRUN verdicts based on file hashes or IP addresses.
KQL Query for Hash Lookup:
// Join Windows process creation events with ANY.RUN malicious verdicts SecurityEvent | where EventID == 4688 // Process Creation | extend ProcessHash = tostring(parse_json(CommandLine).Hashes.SHA256) | join kind=inner ( ANYRUN_Alerts_CL | where Verdict_s == "Malicious" | extend Hash = tostring(parse_json(Process_s).sha256) ) on $left.ProcessHash == $right.Hash | project TimeGenerated, Account, ProcessName, CommandLine, ANYRUN_Verdict = Verdict_s, ANYRUN_ReportLink = ReportLink_g
What this does: This query automatically filters Windows Security events to show only those processes whose hashes were previously classified as “Malicious” by ANY.RUN, providing instant context.
3. Automating Response with Playbooks
The true power of this integration lies in automation. Using Azure Logic Apps (Sentinel Playbooks), you can trigger an automated response when a high-confidence malicious verdict arrives from ANY.RUN.
Step-by-step guide for a basic containment workflow:
- Trigger: Configure the Logic App to trigger when a new entry is added to the `ANYRUN_Alerts_CL` table with a “Malicious” verdict.
- Parse: Parse the JSON payload to extract the malicious IP address, domain, or user agent.
- Action (Windows Firewall): Use the Logic App to run a PowerShell script on a domain controller or firewall management appliance to block the IP.
– Example PowerShell Command to Block IP on Windows Firewall:
Run on a Windows Server via remote PowerShell New-NetFirewallRule -DisplayName "Block Malicious IP from ANYRUN" -Direction Outbound -LocalPort Any -Protocol Any -Action Block -RemoteAddress "MALICIOUS_IP_ADDRESS"
4. Action (Linux Iptables): If managing a Linux gateway, you can SSH into the box and execute:
sudo iptables -A OUTPUT -d MALICIOUS_IP_ADDRESS -j DROP sudo iptables-save > /etc/iptables/rules.v4
4. API Security and Key Hardening
When automating the flow between ANY.RUN and Sentinel, the security of the API keys is paramount. Hardcoding keys in scripts is a common vulnerability.
Securing the Automation Script:
Instead of storing the API key in plain text in a Python script, use environment variables or Azure Key Vault.
Linux (Setting Environment Variable):
export ANYRUN_API_KEY="your_super_secret_key"
Then, in your Python script:
import os
import requests
api_key = os.environ.get('ANYRUN_API_KEY')
headers = {'Authorization': f'API-Key {api_key}'}
response = requests.get('https://api.any.run/v1/analysis', headers=headers)
Windows (Setting Environment Variable via Command Line):
setx ANYRUN_API_KEY "your_super_secret_key"
Best Practice: In Azure, use a Logic App with Managed Identity or reference secrets from Key Vault directly in the connector.
5. Vulnerability Exploitation and Malware Configuration Extraction
ANY.RUN provides deep visibility into malware behavior. When a suspicious file is submitted, the sandbox extracts configuration data (C2 servers, encryption keys). By ingesting this into Sentinel, you can proactively hunt for other assets communicating with those infrastructure pieces.
Hunting Query Example:
If ANY.RUN extracts a C2 server `evil.c2.com` from a malware sample, you can query your DNS logs (or Zeek/Bro logs) for any internal hosts attempting to resolve this domain.
KQL for DNS Hunting:
// Assuming DnsEvents table from a DNS connector
let MaliciousDomains = ANYRUN_Alerts_CL | where Verdict_s == "Malicious" | project Domain = extractjson("$.domains", AdditionalData_s);
DnsEvents
| where QueryName in (MaliciousDomains)
| project TimeGenerated, ClientIP, QueryName, ResponseCode
- Cloud Hardening: Restricting Access to the Sentinel Workspace
To ensure the integrity of the threat intelligence pipeline, the Data Collection Endpoint (DCE) in Azure must be hardened. Only the ANY.RUN integration server should be allowed to send data to this specific endpoint.
Azure CLI Command to set Network ACLs on Log Analytics Workspace:
Restrict ingestion to a specific IP (your ANY.RUN VM public IP) az monitor log-analytics workspace update \ --resource-group MyResourceGroup \ --workspace-name MyWorkspace \ --ingestion-access Enabled \ --public-network-access-for-ingestion Disabled \ --default-action Deny You would then add a rule via ARM template or Portal to allow the specific IP.
7. Linux Command Line for Malware Analysis (Correlation)
Sometimes, SOC analysts retrieve a PCAP from ANY.RUN and want to verify if similar traffic exists on their network. Using Linux command-line tools on a security VM can help.
Extract all unique IPs from a PCAP:
tshark -r malicious_traffic.pcap -Y "ip" -T fields -e ip.dst | sort -u > ips.txt
You can then use these IPs to create a threat intelligence indicator in Sentinel.
What Undercode Say:
- Operational Efficiency is Key: The primary takeaway is that manual enrichment is a bottleneck. Integrating ANY.RUN with Sentinel transforms raw sandbox data into structured, queryable intelligence, drastically reducing Mean Time to Respond (MTTR).
- Context is King: Simply having a “malicious” verdict is not enough. The integration allows analysts to see why a file is malicious—the network connections, the registry changes—directly within the SIEM interface, leading to faster and more confident decision-making.
The integration of dynamic analysis tools with SIEM platforms represents a shift from reactive alert triage to proactive threat hunting. By automating the feedback loop, organizations can ensure that the knowledge gained from one sandbox analysis is immediately applied to protect the entire enterprise. This creates a self-hardening security posture where the environment learns and adapts to new threats in near real-time.
Prediction:
As AI-driven analysis becomes more prevalent in sandboxes, future integrations will move beyond simple IOC (Indicator of Compromise) sharing. We will likely see the automation of “Threat Behavior” profiles. Instead of just blocking an IP, the SIEM will receive a behavioral fingerprint (e.g., “Process A spawns Process B and modifies Registry Key C”) from ANY.RUN. The SIEM will then actively monitor for that specific behavioral chain across all endpoints, catching novel, fileless attacks that leave no static IoCs to block.
▶️ Related Video (84% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Anyrun Share – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
