Threat Actor Abuse of Elastic Cloud: Detecting Stolen Data Hubs

Introduction

Recent research from Huntress has uncovered a concerning trend in the threat landscape: threat actors are not just stealing data; they are adopting enterprise-grade tools to manage it. Specifically, actors have been observed abusing Elastic Cloud (SIEM) infrastructure to act as a central repository for stolen information.

This activity represents a shift in operational security for adversaries. By leveraging legitimate, high-volume cloud services like Elastic Cloud, attackers blend their malicious data exfiltration traffic with legitimate operational traffic, making detection significantly harder for legacy security controls. Defenders must recognize that their SIEM data—or similar cloud repositories—can become a "dead drop" for stolen credentials and sensitive files if access controls are not strictly enforced.

Technical Analysis

Affected Products & Platforms:

Elastic Cloud (Elasticsearch Service): Used by adversaries as a Command & Control (C2) or data staging environment.
Victim Environments: Windows and Linux endpoints where initial access has been achieved via underlying "security issue" vulnerabilities (as noted in the source report).

The Attack Chain:

Initial Access: Attackers exploit specific security vulnerabilities (various CVEs depending on the target) to gain a foothold on the victim's network.
Data Staging: Instead of immediately exfiltrating data to a bespoke command-and-control server, the actor configures the compromised host to send data to an adversary-controlled Elastic Cloud instance.
Management: The attacker utilizes the Elastic Cloud interface (Kibana) to query, sort, and manage the stolen data, effectively treating the victim's data as if it were just another log stream.

Exploitation Status:

Confirmed Active Exploitation: Huntress researchers have confirmed this activity is actively occurring in the wild.
Technique: Abuse of legitimate services (Living off the Land) for data exfiltration and management.

Detection & Response

Detecting this activity requires distinguishing between legitimate business use of Elastic Cloud and malicious exfiltration. If your organization does not use Elastic Cloud, any traffic to it should be treated as malicious. If you do use it, you must baseline the specific processes and user-agents allowed to communicate with your instances.

━━━ DETECTION CONTENT ━━━

YAML

---
title: Potential Data Exfiltration to Elastic Cloud via Non-Standard Processes
id: 9a8b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects suspicious processes attempting to connect to Elastic Cloud endpoints. This may indicate an attempt to use Elastic Cloud as a data hub for stolen information.
references:
  - https://www.infosecurity-magazine.com/news/elastic-cloud-siem-manage-stolen/
author: Security Arsenal
date: 2025/03/27
tags:
  - attack.exfiltration
  - attack.t1567.001
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    DestinationHostname|endswith:
      - '.elastic.co'
      - '.elasticsearch-cloud.com'
      - '.elastic-cloud.com'
  filter_legit:
    Image|endswith:
      - '\elastic-agent.exe'
      - '\filebeat.exe'
      - '\metricbeat.exe'
      - '\packetbeat.exe'
      - '\winlogbeat.exe'
      - '\java.exe' # Often used by Elastic Java clients, whitelist carefully
  condition: selection and not filter_legit
falsepositives:
  - Legitimate custom scripts using official Elastic SDKs (Java/Python)
  - Administrative use of curl/Powershell for one-off troubleshooting (should be rare)
level: high
---
title: PowerShell Upload to Elastic Cloud Suspicious Pattern
id: b1c2d3e4-5f6a-7b8c-9d0e-1f2a3b4c5d6e
status: experimental
description: Detects PowerShell commands that appear to be posting data to Elastic Cloud URLs, a common method for manual data exfiltration.
references:
  - https://www.infosecurity-magazine.com/news/elastic-cloud-siem-manage-stolen/
author: Security Arsenal
date: 2025/03/27
tags:
  - attack.execution
  - attack.t1059.001
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
  selection_cli:
    CommandLine|contains:
      - 'elastic.co'
      - 'elasticsearch-cloud.com'
  condition: all of selection_*
falsepositives:
  - Administrators managing Elastic Cloud via API in PowerShell (Verify user)
level: medium

KQL — Microsoft Sentinel / Defender

// Hunt for unusual network connections to Elastic Cloud infrastructure
// Adjust the list of 'LegitimateProcesses' based on your environment's baseline
let LegitimateProcesses = dynamic(["elastic-agent.exe", "filebeat.exe", "metricbeat.exe", "java.exe"]);
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteUrl has "elastic.co" or RemoteUrl has "elasticsearch-cloud.com"
| where InitiatingProcessFileName !in (LegitimateProcesses)
| project Timestamp, DeviceName, InitiatingProcessAccountName, InitiatingProcessFolderPath, 
          InitiatingProcessCommandLine, RemoteUrl, RemotePort, RemoteIP
| order by Timestamp desc

VQL — Velociraptor

-- Hunt for active network connections to Elastic Cloud domains from non-standard processes
-- Note: Requires elevated privileges to view all network connections
SELECT 
    Pid, 
    Name, 
    Username, 
    Cmdline, 
    RemoteAddress, 
    RemotePort
FROM netstat()
WHERE RemoteAddress =~ '\.elastic\.co$' 
   OR RemoteAddress =~ '\.elasticsearch-cloud\.com$'
   // Add specific processes to whitelist as needed for your env
   AND Name NOT IN ('elastic-agent.exe', 'filebeat.exe', 'java.exe')

PowerShell

# Remediation and Detection Script: Check for Suspicious Elastic Connections
# Run as Administrator to capture all process network data

Write-Host "Checking for processes connecting to Elastic Cloud domains..." -ForegroundColor Cyan

# Define Elastic domains
$elasticDomains = @('*.elastic.co', '*.elasticsearch-cloud.com')

# Get established TCP connections
$connections = Get-NetTCPConnection -State Established -ErrorAction SilentlyContinue

$suspiciousActivity = @()

foreach ($conn in $connections) {
    try {
        $process = Get-Process -Id $conn.OwningProcess -ErrorAction Stop
        $remoteAddr = $conn.RemoteAddress
        
        # Reverse DNS lookup to check for domain match (can be slow, optimizing for direct IP check if known, otherwise checking if it resolves)
        try {
            $dns = [System.Net.Dns]::GetHostEntry($remoteAddr)
            $hostName = $dns.HostName
        } catch {
            continue
        }

        if ($hostName -match 'elastic.co' -or $hostName -match 'elasticsearch-cloud.com') {
            # Whitelist legitimate agent processes (adjust for your environment)
            $legitProcessNames = @('elastic-agent', 'filebeat', 'metricbeat', 'packetbeat', 'java', 'msedge', 'chrome')
            
            if ($legitProcessNames -notcontains $process.ProcessName.ToLower()) {
                $suspiciousActivity += [PSCustomObject]@{
                    Timestamp = Get-Date
                    ProcessName = $process.ProcessName
                    PID = $process.Id
                    CommandLine = $process.MainModule.FileName
                    RemoteAddress = $remoteAddr
                    RemoteHostName = $hostName
                    RemotePort = $conn.RemotePort
                    User = (Get-CimInstance -ClassName Win32_Process -Filter "ProcessId = $($process.Id)").GetOwner().User
                }
            }
        }
    } catch {
        # Handle system processes where access might be denied
        continue
    }
}

if ($suspiciousActivity.Count -gt 0) {
    Write-Host "[!] SUSPICIOUS ACTIVITY DETECTED:" -ForegroundColor Red
    $suspiciousActivity | Format-Table -AutoSize
} else {
    Write-Host "[+] No suspicious connections to Elastic Cloud detected from non-whitelisted processes." -ForegroundColor Green
}

Remediation

Identify Legitimate Traffic: Immediately inventory all authorized Elastic Cloud instances within your organization. Document their specific IP addresses, hostnames, and the authorized processes (agents) that communicate with them.
Network Segmentation & Firewall Rules:
- If Elastic Cloud is not an approved vendor: Block all traffic to *.elastic.co and *.elasticsearch-cloud.com at your perimeter firewalls and proxies.
- If Elastic Cloud is approved: Implement egress filtering. Only allow specific subnets or specific Application IDs (if using AppID) to reach your specific Elastic Cloud deployment endpoints.
Agent Validation: Ensure that all endpoints running elastic-agent or Beats agents are signed by the vendor and are executing from standard program directories (e.g., C:\Program Files\Elastic\Agent or /usr/share/elastic-agent).
Review Cloud Tenants: If you utilize Elastic Cloud, audit your tenants for any new indexes, users, or API keys that were not created by your administrative team. Threat actors may create their own indices within a compromised tenant or spin up trial instances.

Related Resources

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