Network Connection Followed by File Creation

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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/07/02"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2026/07/06"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects network connections originating from a binary located in a potentially suspicious location, followed by a file
 11creation event. This behavior is consistent with C2 agents such as Poseidon and Athena, connecting to a C2 framework
 12such as Mythic. The agent polls the C2 for commands through a web request, after which the command gets executed.
 13"""
 14from = "now-9m"
 15index = ["logs-endpoint.events.network*", "logs-endpoint.events.file*"]
 16language = "eql"
 17license = "Elastic License v2"
 18name = "Network Connection Followed by File Creation"
 19note = """ ## Triage and analysis
 20
 21> **Disclaimer**:
 22> 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.
 23
 24### Investigating Network Connection Followed by File Creation
 25
 26This 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.
 27
 28### Possible investigation steps
 29
 30- 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.
 31- 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.
 32- 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.
 33- 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.
 34- 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.
 35
 36### False positive analysis
 37
 38- 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.
 39- 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.
 40
 41### Response and remediation
 42
 43- 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.
 44- 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.
 45- 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.
 46- 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.
 47- 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.
 48- 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.
 49"""
 50risk_score = 21
 51rule_id = "01c1e353-9d86-4344-abdf-523ab80c6f08"
 52setup = """## Setup
 53
 54This rule requires data coming in from Elastic Defend.
 55
 56### Elastic Defend Integration Setup
 57Elastic 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.
 58
 59#### Prerequisite Requirements:
 60- Fleet is required for Elastic Defend.
 61- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 62
 63#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 64- Go to the Kibana home page and click "Add integrations".
 65- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 66- Click "Add Elastic Defend".
 67- Configure the integration name and optionally add a description.
 68- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 69- 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](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
 70- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 71- 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.
 72For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 73- Click "Save and Continue".
 74- 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.
 75For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 76"""
 77severity = "low"
 78tags = [
 79    "Domain: Endpoint",
 80    "OS: Linux",
 81    "Use Case: Threat Detection",
 82    "Tactic: Command and Control",
 83    "Tactic: Execution",
 84    "Data Source: Elastic Defend",
 85    "Resources: Investigation Guide",
 86]
 87type = "eql"
 88query = '''
 89sequence by host.id, process.entity_id with maxspan=5s
 90  [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and
 91  process.executable like (
 92    "/boot/*", "/dev/shm/*", "/tmp/*", "/var/tmp/*", "/var/log/*", "/var/run/user/*", "/run/user/*"
 93  ) and
 94  not (
 95    destination.ip == null or
 96    destination.ip == "0.0.0.0" or 
 97    cidrmatch(
 98      destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12",
 99      "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",
100      "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",
101      "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",
102      "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10",
103      "FF00::/8", "FC00::/7"
104    )
105  )]
106  [file where host.os.type == "linux" and event.type == "creation" and process.executable like (
107    "/boot/*", "/dev/shm/*", "/tmp/*", "/var/tmp/*", "/var/log/*", "/boot/*", "/var/run/user/*", "/run/user/*"
108  ) and
109  not (
110    file.name like "tmp*" or file.extension in ("sqlite-journal", "db-journal", "lockfile", "tmp") or
111    file.path like (
112      "/loki/wal/*", "/dev/shm/.org.chromium.Chromium.*", "/opt/rapid7/nexpose/*",
113      "/usr/local/ltechagent*", "/var/lib/cloudendure/agent_keystore_temp", "/var/cache/yum/*",
114      "/run/aws-node/ipam.json.tmp*", "/run/systemd/journal/streams/.*"
115    ) or
116    (process.executable == "/tmp/terraform" and file.path like "/tmp/terraform-provider*") or 
117    process.name in ("podman", "minikube", "logrotate", "java", "aws-k8s-agent", "grafana", "postman") or
118    process.executable : (
119      "/etc/cron.daily/logrotate", "/etc/update-motd.d/50-motd-news", "/etc/cron.hourly/0yum-hourly.cron",
120      "/etc/cron.hourly/BitdefenderRedline", "/tmp/token_handler", "/tmp/.sentry-cli*.exe", 
121      "/etc/cron.daily/0yum-daily.cron", "/etc/init.d/fortiedr"
122    )
123  )]
124'''
125
126[[rule.threat]]
127framework = "MITRE ATT&CK"
128
129  [rule.threat.tactic]
130  name = "Command and Control"
131  id = "TA0011"
132  reference = "https://attack.mitre.org/tactics/TA0011/"
133
134  [[rule.threat.technique]]
135  name = "Application Layer Protocol"
136  id = "T1071"
137  reference = "https://attack.mitre.org/techniques/T1071/"
138
139    [[rule.threat.technique.subtechnique]]
140    name = "Web Protocols"
141    id = "T1071.001"
142    reference = "https://attack.mitre.org/techniques/T1071/001/"
143
144[[rule.threat]]
145framework = "MITRE ATT&CK"
146
147  [rule.threat.tactic]
148  name = "Execution"
149  id = "TA0002"
150  reference = "https://attack.mitre.org/tactics/TA0002/"
151
152    [[rule.threat.technique]]
153    id = "T1059"
154    name = "Command and Scripting Interpreter"
155    reference = "https://attack.mitre.org/techniques/T1059/"
156
157      [[rule.threat.technique.subtechnique]]
158      name = "Unix Shell"
159      id = "T1059.004"
160      reference = "https://attack.mitre.org/techniques/T1059/004/"

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.

Related rules

to-top