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
- Suspicious Command Execution via Busybox Proxy
- Deprecated - Uncommon Destination Port Connection by Web Server
- Deprecated - Unusual Command Execution from Web Server Parent
- Deprecated - Unusual Process Spawned from Web Server Parent
- AWS EC2 LOLBin Execution via SSM SendCommand