The minute that decides everything
You can argue about prevention versus detection forever. But once an attacker is on a box with an interactive shell, the next sixty seconds usually decide whether you spot them today, next week, or never. The behavior in that window is remarkably consistent across red-team operators, opportunistic crews, and most ransomware affiliates. They are not creative yet. They are checking who they are and what they have.
This post is a walkthrough of that minute, command by command, with the MITRE ATT&CK technique that maps to each step. At the end, we contrast what an eBPF-based agent sees in real time against what a log-only stack sees, which in many cases is nothing.
Seconds 0-10: who am I, where am I
The very first commands are almost always identity and orientation. Even experienced operators run them, because skipping them once means accidentally running root-only commands as a service account and burning the foothold. Expect to see whoami, id, hostname, and uname -a.
MITRE maps these to System Owner/User Discovery (T1033) and System Information Discovery (T1082). Individually they are boring. As a burst inside one TTY in under five seconds they are one of the cleanest signals you ever get.
Seconds 10-25: the credential and trust map
Now the operator wants to know what they can pivot to. The classic next reads are cat /etc/passwd, cat ~/.bash_history, ls -la ~/.ssh, and sudo -l.
These map to Account Discovery (T1087.001), Credentials In Files (T1552.001), and Unsecured Credentials: Bash History (T1552.003). The signature here is not any single read, it is the sequence: passwd then ssh keys then sudoers, in that order, in the same session, by a process that is not a normal admin tool.
A real admin reads one of these for a reason and moves on. Attackers read all of them, fast, because they do not yet know which one will pay.
Seconds 25-40: persistence and privilege scouting
With identity and credentials mapped, the focus shifts to staying. Expect crontab -l, systemctl list-units --type=service, a quick walk of /etc/cron.*, and the SUID hunt:
find / -perm -4000 -type f 2>/dev/null
find / -perm -2000 -type f 2>/dev/null
getcap -r / 2>/dev/nullSUID enumeration touches thousands of inodes. It is one of the loudest things you can do on a Linux box, and yet most defenders never see it because nothing in the standard log stack records it. eBPF does, because it sees the syscalls that find issues. Maps to Privilege Escalation: Setuid and Setgid (T1548.001).
Seconds 40-50: network surface
Now the operator wants to know who they can talk to. Expect ss -tnp or netstat -plant, ip a, cat /etc/resolv.conf, and a peek at /proc/net/tcp. This is System Network Configuration Discovery (T1016) and System Network Connections Discovery (T1049).
The interesting tell is when the operator follows up by piping listening ports through grep for non-localhost binds, looking for misconfigured services that are reachable from outside. Defenders rarely do that on demand. Attackers always do.
Seconds 50-60: outbound and stage
The minute usually closes with a check that egress works and a first staging beacon. Expect a curl to an attacker-controlled domain, sometimes a wget that pulls a tool into /tmp, and frequently a DNS lookup with dig to a domain that looks like cdn-static-9f2a.tld. That is Application Layer Protocol: Web Protocols (T1071.001) and frequently Ingress Tool Transfer (T1105).
By second sixty the operator either has a second-stage payload running or has decided the box is too watched and disconnects. Whichever happens, the discovery burst is the only signal you are guaranteed to get.
What eBPF sees in real time
An agent attached to the kernel sees every execve, openat, and connect, with the parent PID, TTY, and command line attached. That is the difference between knowing a TTY ran some commands and knowing that PID 12993 read /etc/passwd 0.4 seconds after a SUID enumeration that started 0.6 seconds after a successful SSH login from a country the host has never been logged into before.
The single events are noisy. The chain is not. A correlation engine that fuses these into one incident is what turns the first sixty seconds into an alert before the second minute starts.
What log-only stacks miss
auth.log records the SSH login. syslog might record sudo calls. That is most of what you get out of the box. The discovery burst itself, including the SUID hunt, the bash history read, the ssh key listing, and the curl to a staging domain, is invisible to syslog because none of those commands log themselves.
Auditd can be told to record some of this, but the rule sets that catch it generate so much noise on a healthy server that they are usually disabled within a week. eBPF lets you filter at the kernel before the event ever reaches user space, which is why the noise floor is workable.
How Inner Warden uses this
Inner Warden's sensor watches forty eBPF hooks and emits normalized events. The agent runs a correlation engine over those events and looks for patterns that match this exact burst: identity reads, credential reads, persistence reads, network reads, and a first outbound, all within a short window from one process tree. That correlation, not any single command, is what fires the incident.
Read more on this in Cross-Layer Correlation and Sigma rules on eBPF.