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/09/18"
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 "Noise: Medium",
87 "Performance: Normal",
88 "Rule Type: Event Correlation (EQL)",
89 "Platform: Linux",
90]
91type = "eql"
92query = '''
93sequence by host.id, process.entity_id with maxspan=5s
94 [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and
95 process.executable like (
96 "/boot/*", "/dev/shm/*", "/tmp/*", "/var/tmp/*", "/var/log/*", "/var/run/user/*", "/run/user/*"
97 ) and
98 not (
99 destination.ip == null or
100 destination.ip == "0.0.0.0" or
101 cidrmatch(
102 destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12",
103 "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",
104 "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",
105 "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",
106 "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10",
107 "FF00::/8", "FC00::/7"
108 )
109 )]
110 [file where host.os.type == "linux" and event.type == "creation" and process.executable like (
111 "/boot/*", "/dev/shm/*", "/tmp/*", "/var/tmp/*", "/var/log/*", "/boot/*", "/var/run/user/*", "/run/user/*"
112 ) and
113 not (
114 file.name like "tmp*" or file.extension in ("sqlite-journal", "db-journal", "lockfile", "tmp") or
115 file.path like (
116 "/loki/wal/*", "/dev/shm/.org.chromium.Chromium.*", "/opt/rapid7/nexpose/*",
117 "/usr/local/ltechagent*", "/var/lib/cloudendure/agent_keystore_temp", "/var/cache/yum/*",
118 "/run/aws-node/ipam.json.tmp*", "/run/systemd/journal/streams/.*"
119 ) or
120 (process.executable == "/tmp/terraform" and file.path like "/tmp/terraform-provider*") or
121 process.name in ("podman", "minikube", "logrotate", "java", "aws-k8s-agent", "grafana", "postman") or
122 process.executable : (
123 "/etc/cron.daily/logrotate", "/etc/update-motd.d/50-motd-news", "/etc/cron.hourly/0yum-hourly.cron",
124 "/etc/cron.hourly/BitdefenderRedline", "/tmp/token_handler", "/tmp/.sentry-cli*.exe",
125 "/etc/cron.daily/0yum-daily.cron", "/etc/init.d/fortiedr"
126 )
127 )]
128'''
129
130[[rule.threat]]
131framework = "MITRE ATT&CK"
132
133 [rule.threat.tactic]
134 name = "Command and Control"
135 id = "TA0011"
136 reference = "https://attack.mitre.org/tactics/TA0011/"
137
138 [[rule.threat.technique]]
139 name = "Application Layer Protocol"
140 id = "T1071"
141 reference = "https://attack.mitre.org/techniques/T1071/"
142
143 [[rule.threat.technique.subtechnique]]
144 name = "Web Protocols"
145 id = "T1071.001"
146 reference = "https://attack.mitre.org/techniques/T1071/001/"
147
148[[rule.threat]]
149framework = "MITRE ATT&CK"
150
151 [rule.threat.tactic]
152 name = "Execution"
153 id = "TA0002"
154 reference = "https://attack.mitre.org/tactics/TA0002/"
155
156 [[rule.threat.technique]]
157 id = "T1059"
158 name = "Command and Scripting Interpreter"
159 reference = "https://attack.mitre.org/techniques/T1059/"
160
161 [[rule.threat.technique.subtechnique]]
162 name = "Unix Shell"
163 id = "T1059.004"
164 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
- Curl or Wget Egress Network Connection via LoLBin
- Simple HTTP Web Server Connection
- Simple HTTP Web Server Creation
- At Job Created or Modified
- Azure Run Command Script Child Process