Anatomy of a Spydertrace: Glasgow Smile 1.1 Vulnhub
Updated: 3 days ago
In this blog, we analyze the Spydertrace captured by attacking the vulnhub image called Glasgow Smile v1.1 created by vulnhub author mindsflee.
You can find the vulnhub here: https://www.vulnhub.com/entry/glasgow-smile-11,491/.
There are a few walk-throughs available for this vulnhub. Here are a couple:
Spydertraces differ from log analysis. A Spydertrace presents a focused view of the causal activity of an attack to clearly expose the attack's full set of steps from its initial intrusion to its current progression. Rather than rely on inference on incomplete log data, Spydertraces are created by capturing system-level interactions (e.g. processes, network connections, file interactions) with the operating system and automatically establishing the causal links between these interactions. (e.g. a process receives a network connection, spawning a new process that reads a file, etc.)
Rather than serve as a forensic exercise, Spydertraces capture activity as it occurs. All preceding and subsequent causal activities are presented from an alert, including other alerts. A security analysts can view a Spydertrace even as the action is unfolding to compress investigation time with a full understanding of the attack's initial intrusion and current impact.
Let's introduce three components of Spyderbat’s investigation UI so we can dissect the Spydertrace.
The Records Table provides a table view of information including the Machines, Sessions, Processes, Connections, and Red Flags captured in the Spydertrace
The Causal Tree provides a graphical view of the causal connections between Machines, Processes, Connections and Red Flags captured in the Spydertrace
The Details pane provides additional information about a selected Record or Causal Tree node.
The Story of the Attack
Red Flags combine both third-party alerts (e.g. from existing SIEM, NGFW, etc.) and Spyderbat-generated flags. A single red flag with no causal activity is a characteristic of a false positive. Credible attacks include a growing cluster of red flags. By looking at the list of red flags in the records table, we gain an overall understanding of the attack.
We see a first phase of the attack involving the user “www-data”.
There was a series of user privilege escalations.
The last red flag shows the attacker using the root account.
Let’s break down the stages of the attack using the Causal Tree of the Spydertrace to learn exactly what the attacker did (note that this is not represented from left-to-right):
As the attacker, after running netdiscovery and nmap to discover the system and enumerate open ports, we attacked the Joomla administration login page with a brute force attack.
As a Joomla administrator, we edited index.php to insert a web reverse shell on port 5555:
We set the attack Machine to listen on port 5555 and received our reverse shell connection:
Looking at the Spydertrace, we see the successful reverse shell generated from an apache2 (web server) process (out on ephemeral port 41990) to the attack machine on IP address 192.168.0.17 on port 5555.
Note that while there are many other activities, including web activity, taking place simultaneously on this system, these are currently hidden from our view. While all activity is captured by Spyderbat, the Spydertrace presents a focused view of causal activity. In this case, the pre-causal activity includes the apache2 parent processes are displayed along with the pre-causal activity leading to the first set of red flags:
The network connection causes a shell, "sh", to spawned from the apache2 process
In this shell, the following commands are executed as the user www-data:
As the attacker, in the "sh" interactive shell, we type the following commands:
id -- to see which user we are
which python3 -- to see if we have access to python3
python3 -c "import pty;pty.psawn('/bin/bash')" -- to create a bash shell
Below, we see these interactive commands as captured in the Spydertrace:
By looking at the details of the python3 node, we see the script which when executed spawned a bash shell process and generated a red flag.
Returning to our red flags, we can see the next flagged activity is the attacker escalating to the user Abner.
But how did the attacker get the information needed to escalate to Abner?
As the attacker, we read the file configuration.php which exposed a MySQL username and password used by joomla.
In MySQL, we find Rob’s password encoded in base64:
The Spyderbat Investigation UI allows us to step through each step captured in the Spydertrace:
In this sequence, we see the attacker:
Read the file configuration.php
Access mysql as the user joomla
Creates an ssh connection into the system from the attack machine, creating a bash shell as ‘rob’
The ssh session takes place 2 minutes after www-data accessing MySQL.
Rob authenticated with standard credentials.
It would be easy to miss the connection between the initial shell access as www-data and a separate ssh connection using valid connections by Rob. With Spyderbat, we clearly see the connection of these otherwise distinct events.
In the Spydertrace, we see Rob’s ssh session includes a number of red flags and user escalations:
How does Rob become Abner and then Penguin?
As the attacker,
We read a file called “Abnerineedyourhelp” which includes a cipher.
With the help of cyberchef (https://0x1.gitlab.io/code/CyberChef/), we expose the text to reveal Abner’s password encoded in base64.
After becoming Abner, we read Abner’s bash_history, and get a clue to search for a file called .dear_penguin.zip. After unzipping this file, we read it to reveal Penguin’s password.
In the Spydertrace, we expand each bash shell to view it’s “children”, exposing the attacker’s exact steps:
Reads the file “Abnerineedyourhelp”
Becomes Abner 11 minutes after reading the file (with no actions in between).
Reads the file user2.txt (second flag in the vulnhub)
Reads the file info.txt
Uses the commands ‘find’ and ‘grep’ to locate the file .dear_penguins.zip
Unzips the file into /tmp and reads it
Becomes penguin (28 seconds after reading the file)
Note how different this is from log analysis. Rather than filtering through system logs and manually correlating information based on time stamps, the Spydertrace provides a clear understanding of the attacker's steps based on the causal relationships of activities.
As the attacker, we learn that Penguin is working on a file and has given it root permissions:
Using a program called pspy64s, we learn this file is executed regularly by a cronjob as root:
We edit the file to include a reverse shell on port 8888 and wait for cron to run it.
In the Spydertrace, the playback "next" button reveals the steps in order of the attack even as it jumps across user sessions and different network connections:
After reading .trash_old, the attacker:
Uses scp to copy over a program called pspy64s from the attacker machine
Runs the pspy64s program
Under cron, executes the file .trash_old
.trash_old creates a network connection on port 8888 to the attacker machine
In an interactive sh shell, executes a python script that creates a bash shell
The next command performed by the attacker as root is to read /root/root,txt (which is the flag in the Glasgow Smile v1.1 vulnhub image). The last steps are to perform cleanup actions.
In the Spydertrace, we see the last actions of the attacker are to remove the file pspy64s and the .bash_history files for Penguin, Abner, and Rob.
The Spydertrace provides a clear representation of the attack, allowing us to understand the actions performed at each stage without the distraction of extraneous logs and relying on manual correlation of events. With the Spydertrace, we quickly understand:
If you enjoyed walking through the Spydertrace, we are creating a series of interactive challenges using real attacks and their resulting Spydertraces. We are seeking individuals who like solving puzzles, want to expand their blue team skills, and can provide us feedback as we develop our Defend the Flag Challenges: