Turning the Shield into a Vault: Attackers Abuse Elastic Cloud for Data Exfiltration

In a stark reminder that creativity is the enemy of security, researchers at Huntress have uncovered a disturbing campaign where threat actors are not just stealing data—they are managing it using legitimate enterprise security infrastructure. By exploiting web application vulnerabilities to gain initial access, attackers are exfiltrating sensitive information directly into Elastic Cloud SIEM instances, effectively using a security tool as a personal command-and-control (C2) and data storage hub.

The Attack Vector: From Web Flaw to Cloud Storage

The attack chain begins with a familiar story: unpatched or misconfigured web applications. Actors are actively exploiting specific vulnerabilities (CVEs) in public-facing web servers to establish a foothold. However, the deviation from standard playbooks happens during the exfiltration phase.

Rather than transferring stolen data to a traditional malicious IP address—which would likely trigger immediate alerts in modern egress filtering systems—these actors are leveraging the Elastic Stack. They utilize the Elastic Cloud API to push stolen JSON data into indices they control within the Elastic Cloud environment.

Why this TTP is Dangerous

This technique poses a significant risk to defenders for several reasons:

• Traffic Camouflage: Connections to Elastic Cloud (*.elastic-cloud.com) are whitelisted in many environments. Traffic to these endpoints is treated as trusted, allowing large volumes of data to leave the network without raising suspicion.
• SSL/TLS Encryption: The data is transmitted over HTTPS, making it impossible for standard deep packet inspection (DPI) tools to inspect the content of the payloads without SSL interception.
• Legitimacy of Infrastructure: Security operations centers (SOCs) rarely flag traffic destined for security tool vendors as malicious, providing a perfect "living off the land" scenario for cloud environments.

Technical Analysis and TTPs

Once the attackers have compromised a web server, often via a remote code execution (RCE) flaw or a deserialization vulnerability, they drop a web shell or simple script. This script is configured to serialize sensitive data (credentials, configuration files, database dumps) and POST it to a known Elastic Cloud endpoint.

The attackers typically authenticate using embedded API keys found in the compromised environment or by provisioning their own free/trial instances. The data is then indexed and searchable by the threat actor, providing them a structured UI to manage the loot of multiple victims simultaneously.

Detection and Threat Hunting

Defending against this requires a shift in mindset. We must look for contextual anomalies rather than just signature-based alerts. We need to identify when a legitimate tool is being used in an illegitimate way.

Hunting for Suspicious Processes

The web server processes (e.g., Apache, Nginx, IIS) should generally not be initiating outbound connections to Elastic Cloud ports (9200 or 9243) directly. We can hunt for processes spawning curl or powershell to reach these endpoints.

PowerShell Detection Script:

# Hunt for processes initiating connections to Elastic Cloud endpoints
Get-NetTCPConnection -State Established -RemotePort 9200,9243,443 | 
    ForEach-Object { 
        $process = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue
        if ($process) {
            $remoteAddress = (Get-NetNeighbor -IPAddress $_.RemoteAddress -ErrorAction SilentlyContinue).LinkLayerAddress
            [PSCustomObject]@{
                ProcessName = $process.ProcessName
                PID         = $_.OwningProcess
                RemoteAddr  = $_.RemoteAddress
                RemotePort  = $_.RemotePort
                Path        = $process.Path
            }
        }
    } | Where-Object { $_.ProcessName -notin @"elastic-agent", "filebeat", "metricbeat"@ }

KQL Queries for Sentinel/Defender

If you are forwarding network logs to Microsoft Sentinel or Defender, use the following KQL query to identify potential data exfiltration to Elastic Cloud from non-standard processes.

DeviceNetworkEvents
| where RemoteUrl contains "elastic-cloud.com" or RemotePort in (9200, 9243)
| where InitiatingProcessFileName !in ("elastic-agent.exe", "filebeat.exe", "metricbeat.exe", "logstash.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessParentFileName, RemoteUrl, SentBytes, ReceivedBytes
| order by Timestamp desc
| extend Score = iff(SentBytes > 1000000, 10, 1) // Flagging large outbound transfers
| where Score > 1

Analyzing Web Server Logs

On the compromised source, you may find evidence of the exploitation or the script execution.

# Check access logs for suspicious POST requests or anomalous user agents
grep -iE "POST|wget|curl|python" /var/log/httpd/access_log | 
awk '{print $1, $7, $12, $13}' | 
sort | uniq -c | sort -rn | head -20

Mitigation Strategies

Stopping this campaign requires a multi-layered approach that addresses both the entry vector and the exfiltration method.

1. Patch Web Applications Aggressively: The entry point is almost always a known CVE in a web application or framework. Ensure your external-facing assets are scanned regularly and patched immediately upon vulnerability disclosure.

2. Implement Egress Filtering: Do not allow servers to communicate freely with the internet. Use strict firewall rules to limit outbound traffic. If you use Elastic Cloud, restrict egress to only the specific IP addresses or endpoints assigned to your organization via the Elastic Cloud dashboard.

3. Rotate API Keys: If attackers have exfiltrated API keys, they retain access until the keys are rotated or revoked. Audit your Elastic Cloud API key usage for anomalies and rotate keys used in production environments regularly.

4. Monitor SIEM Ingest Volume: While this is an attacker using Elastic, you should also monitor your own Elastic instance. A sudden, unexplained spike in ingest volume or the creation of new, unauthorized indices could indicate an attacker is using your licenses to store their data.

Conclusion

The misuse of Elastic Cloud SIEM highlights a growing trend: attackers are leveraging trust. By hiding their malicious traffic inside the legitimate traffic of trusted security vendors, they bypass traditional defenses. Vigilance requires us to monitor not just who is coming in, but what is going out, even when the destination looks safe.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub