Anatomy of a Spydertrace: Glasgow Smile 1.1 Vulnhub

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:

• https://www.infosecarticles.com/glasgow-smile-1-vulnhub-walkthrough/
• https://www.hackingarticles.in/glasgow-smile-1-1-vulnhub-walkthrough/

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. 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.

1. The Records Table provides a table view of information including the Machines, Sessions, Processes, Connections, and Red Flags captured in the Spydertrace

2. The Causal Tree provides a graphical view of the causal connections between Machines, Processes, Connections and Red Flags captured in the Spydertrace

3. 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):

Initial Intrusion

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:

1. The network connection causes a shell, “sh”, to spawned from the apache2 process

2. In this shell, the following commands are executed as the user www-data:

uname
w
id

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.

Privilege Escalation

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:

1. Read the file configuration.php

2. Access mysql as the user joomla

3. Creates an ssh connection into the system from the attack machine, creating a bash shell as ‘rob’

Note — The ssh session takes place 2 minutes after www-data accessing MySQL and 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,

1. We read a file called “Abnerineedyourhelp” which includes a cipher.

2. With the help of 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:

As Rob:

1. Reads the file “Abnerineedyourhelp”

2. Becomes Abner 11 minutes after reading the file (with no actions in between).

As Abner:

1. Reads the file user2.txt (second flag in the vulnhub)

2. Reads the file info.txt

3. Uses the commands ‘find’ and ‘grep’ to locate the file .dear_penguins.zip

4. Unzips the file into /tmp and reads it

5. 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 timestamps, the Spydertrace provides a clear understanding of the attacker’s steps based on the causal relationships of activities.

Data Exfiltration

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:

As penguin,

1. Uses scp to copy over a program called pspy64s from the attacker machine

2. Runs the pspy64s program

3. Edits .trash_old

As root,

1. Under cron, executes the file .trash_old

2. .trash_old creates a network connection on port 8888 to the attacker machine

3. 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.

Conclusion

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:

The Story	Red Flags provide a quick, reviewable synopsis of the attack to its current progression
The Impact	The machines, files, and user accounts compromised by the attacker during the attack
What to clean	Restore joomla web pages from backup (or remove edited pages by attacker) Change passwords for user accounts Rob, Abner, Penguin Change the joomla MySQL password
Prevention	Fortify the Joomla administrator account with a stronger password Do not re-use passwords across system and MySQL accounts Do not create cronjob entries with root permissions

Interact with this Spydertrace in Spyderbat’s Defend the Flag Linux Challenges “Gotham Series”, available here: https://app.spyderbat.com/signup

Thanks, and Happy Tracing!