« Shell Execution via Elastic Endpoint Shared Object Load via LoLBin »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.27

Network Connection Followed by File Creation

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Network Connection Followed by File Creation

edit

Detects network connections originating from a binary located in a potentially suspicious location, followed by a file creation event. This behavior is consistent with C2 agents such as Poseidon and Athena, connecting to a C2 framework such as Mythic. The agent polls the C2 for commands through a web request, after which the command gets executed.

Rule type: eql

Rule indices:

  • logs-endpoint.events.network*
  • logs-endpoint.events.file*

Severity: low

Risk score: 21

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References: None

Tags:

  • Domain: Endpoint
  • OS: Linux
  • Use Case: Threat Detection
  • Tactic: Command and Control
  • Tactic: Execution
  • Data Source: Elastic Defend
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit
## Triage and analysis

Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

Investigating Network Connection Followed by File Creation

This rule spots a Linux process running from an unusual writable directory that makes an outbound connection and then creates a file within seconds, a pattern that often marks an active implant receiving tasks and staging follow-on activity. Attackers launch a loader from /dev/shm or /tmp, poll a remote web-based command server, and immediately drop a script or renamed payload for execution or persistence.

Possible investigation steps

  • Review the process ancestry and launch context for the binary in the writable directory to determine whether it originated from a user session, script, scheduled task, package operation, or remote execution mechanism.
  • Inspect the external destination’s reputation, ownership, protocol details, and whether other hosts contacted it at similar times to distinguish approved software behavior from likely command-and-control traffic.
  • Examine the created file’s location, type, hash, contents, permissions, and any immediate chmod, rename, or execution activity to assess whether it is a staged payload, script, or persistence artifact.
  • Build a concise timeline around the alert to identify preceding download, decode, or unpack actions and any follow-on child processes, credential access attempts, or lateral movement from the same host.
  • Search the environment for the same executable hash, destination, or dropped artifact on other systems and contain the host if you observe repeated beaconing, additional suspicious file creation, or evidence of execution.

False positive analysis

  • A legitimate software installer, updater, or bootstrap script launched from /tmp or /var/tmp can contact an external repository and immediately create unpacked files; verify the parent process, initiating user, shell history, and whether the destination IP and dropped files align with an approved installation or update at that time.
  • An administrator or automation job may execute a temporary script from /dev/shm or /run/user to fetch remote content and write logs, configuration, or cache files; confirm the activity matches a scheduled task or provisioning change and inspect the created file paths and script contents for expected benign output.

Response and remediation

  • Isolate the affected Linux host from the network except for approved management access, kill the suspicious process running from the writable directory, quarantine the binary and any files it created, and block the contacted external IP or domain at the firewall, proxy, and DNS layers.
  • Remove attacker footholds by deleting malicious systemd services, cron jobs, shell profile modifications, SSH authorized_keys entries, and any copied or renamed payloads the implant placed under writable paths or startup locations, after preserving forensic copies.
  • Reset potentially exposed access by rotating passwords, SSH keys, API tokens, and service credentials used on the host, especially if the process ran as root, touched authentication files, or dropped scripts and configuration files that may contain secrets.
  • Restore the system to a known-good state by reimaging or rebuilding the host from a trusted baseline when the binary or dropped files executed, then validate package integrity, startup items, and critical application data before reconnecting it to production.
  • Escalate immediately to incident response if the same executable hash, outbound destination, or dropped artifact appears on additional hosts, or if you identify privilege escalation, credential theft, persistence in multiple locations, or attempted lateral movement.
  • Harden the environment by blocking execution from /tmp, /dev/shm, and other writable directories where feasible, tightening egress rules to approved destinations, enforcing application allowlisting, and improving monitoring for new outbound beacons followed by file creation.

Setup

edit

Setup

This rule requires data coming in from Elastic Defend.

Elastic Defend Integration Setup

Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.

Prerequisite Requirements:

  • Fleet is required for Elastic Defend.
  • To configure Fleet Server refer to the documentation.

The following steps should be executed in order to add the Elastic Defend integration on a Linux System:

  • Go to the Kibana home page and click "Add integrations".
  • In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
  • Click "Add Elastic Defend".
  • Configure the integration name and optionally add a description.
  • Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
  • Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. Helper guide.
  • We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
  • Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. For more details on Elastic Agent configuration settings, refer to the helper guide.
  • Click "Save and Continue".
  • To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. For more details on Elastic Defend refer to the helper guide.

Rule query

edit
sequence by host.id, process.entity_id with maxspan=5s
  [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and
  process.executable like (
    "/boot/*", "/dev/shm/*", "/tmp/*", "/var/tmp/*", "/var/log/*", "/var/run/user/*", "/run/user/*"
  ) and
  not (
    destination.ip == null or
    destination.ip == "0.0.0.0" or
    cidrmatch(
      destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12",
      "192.0.0.0/24", "192.0.0.0/29","192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32",
      "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24",
      "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", "192.175.48.0/24",
      "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10",
      "FF00::/8", "FC00::/7"
    )
  )]
  [file where host.os.type == "linux" and event.type == "creation" and process.executable like (
    "/boot/*", "/dev/shm/*", "/tmp/*", "/var/tmp/*", "/var/log/*", "/boot/*", "/var/run/user/*", "/run/user/*"
  ) and
  not (
    file.name like "tmp*" or file.extension in ("sqlite-journal", "db-journal", "lockfile", "tmp") or
    file.path like (
      "/loki/wal/*", "/dev/shm/.org.chromium.Chromium.*", "/opt/rapid7/nexpose/*",
      "/usr/local/ltechagent*", "/var/lib/cloudendure/agent_keystore_temp", "/var/cache/yum/*",
      "/run/aws-node/ipam.json.tmp*", "/run/systemd/journal/streams/.*"
    ) or
    (process.executable == "/tmp/terraform" and file.path like "/tmp/terraform-provider*") or
    process.name in ("podman", "minikube", "logrotate", "java", "aws-k8s-agent", "grafana", "postman") or
    process.executable : (
      "/etc/cron.daily/logrotate", "/etc/update-motd.d/50-motd-news", "/etc/cron.hourly/0yum-hourly.cron",
      "/etc/cron.hourly/BitdefenderRedline", "/tmp/token_handler", "/tmp/.sentry-cli*.exe",
      "/etc/cron.daily/0yum-daily.cron", "/etc/init.d/fortiedr"
    )
  )]

Framework: MITRE ATT&CKTM

« Shell Execution via Elastic Endpoint Shared Object Load via LoLBin »