The enterprise EDR alerted for possible exfiltration attempts originating from a developer RedHat Linux machine. A fellow SOC member captured a disk image for the suspected machine and sent it for you to analyze and identify the attacker's footprints.
Information
Category Name: Exfiltrated
Files : c59-RedHat.zip 3.3 GB
02.E01 – 3.57 GB
My Recommendations
Download it from CyberDefenders and verify the file with sha1sum:
sha1sum /path/to/c59-RedHat.zip
SHA1: 1f190082a122f74baa19f1b8189bbb0172301c66
This is my personal preference, I like being organized and deleting a folder when I’m done with it .
mkdir Documents/CyberDefenders/Exfiltrated && cd Documents/CyberDefenders/Exfiltrated
sudo ewfmount 02.E01 /mnt/ewf sudo mount -o ro,noload /mnt/ewf/ewf1 /mnt/Linux
Walkthrough
1. What is the RHEL version installed on the machine?
This information is stored in /etc/os-release:
cat /mnt/Linux/etc/os-release
Answer: 8.4
2. How many users have a login shell?
We can check /etc/passwd and grep for bash, which indicates a login shell:
cat /mnt/Linux/etc/passwd | grep bash
Six users have a login shell.
Answer: 6
3. How many users are allowed to run the sudo command on the system?
First, we can check the sudoers file to see if any custom implementation are in place:
sudo cat /mnt/Linux/etc/sudoers
The parameters are what you would usually find on a RH system. Next, we can check which users belong to the group wheel:
cat /mnt/Linux/etc/group | grep 'wheel'
Two users belong to group wheel, cyberdefenders and rachel.
Answer: 2
4. What is the 'rossatron' user password?
To crack the user’s password, we must :
– unshadow the passwd and shadow file
– save rossatron’s individual hash
– run John The Ripper with the rockyou wordlist
sudo unshadow /mnt/Linux/etc/passwd /mnt/Linux/etc/shadow > unshadowed
grep rossatron unshadowed > rossatron_hash
john --wordlist=/usr/share/wordlists/rockyou.txt rossatron_hash
Answer: rachelgreen
5. What is the Victim's IP address?
The system doesn’t have an auth.log file, but we can look into audit.log to find IP addresses and sort them by occurance:
sudo cat /mnt/Linux/var/log/audit/audit.log| grep -oE "\b([0-9]{1,3}\.){3}[0-9]{1,3}\b" | sort | uniq -c > audit_ips
cat audit_ips
Two of the addresses occur much more than the others. A quick way to determine who’s IP address is the attacker’s is to find records of ‘failure’:
sudo grep -F '192.168.196.129' /mnt/Linux/var/log/audit/audit.log | grep failed
#returns nothing
sudo grep -F '192.168.196.128' /mnt/Linux/var/log/audit/audit.log | grep failed
#returns 218 matches
The attacker’s IP must be the one ending in 128. Next, we can check the /var/log/secure file for these IP addresses:
sudo cat /mnt/Linux/var/log/secure | grep -F '192.168.196.129'
Only three successful records are returned.
sudo cat /mnt/Linux/var/log/secure | grep -F '192.168.196.128'
A way larger output, with many failed attempts.
The victim must be 192.168.196.129.
Answer: 192.168.196.129
6. What service did the attacker use to gain access to the system?
As we saw in the previous analysis, the system was accessed via SSH.
Answer: ssh
7. What is the attacker's IP address?
Given the large occurrence of IP Address 192.168.196.128, and the evidence of failed connection attempts, it was established that 192.168.196.128 is the attacker’s IP Address.
Answer: 192.168.196.128
8. What authentication attack did the attacker use to gain access o the system?
The log files showed attempts at establishing SSH connections with multiple users, pointing to a brute force attack over SSH.
Answer: Brute-force
9. How many users the attacker was able to bruteforce their password?
Looking for the magic ssh string ‘Accepted password’:
sudo cat /mnt/Linux/var/log/secure | grep -F 'Accepted password'
Thee first three logins are not suspicious, as they are not from the attacker’s ip. Considering the timeline, it could be that the attacker bruteforced three users’ passwords. However, the logins for user rachel occurred the day after the initial attack.
For a password to be bruteforced, it must be unknown to the attacker. Meaning we need to check if the attacker created users on the system in order to maintain persistence. Looking at /var/log/secure for potential evidence:
sudo cat /mnt/Linux/var/log/secure | grep 'useradd'
The user rachel was created after the initial attack started (see question 10).
To check whether rachel was indeed create by the attacker, we can look at bash_history files:
sudo find /mnt/Linux/ -name '.bash_history' -exec grep -il 'user' "{}" \;
#returns /mnt/Linux/home/cyberdefenders/.bash_history and /mnt/Linux/home/chandler/.bash_history
cyberdefender’s bash history matches the timeline above, and contains no record of user rachel:
On the other hand, chandler’s bash_history is much more suspicious. The last lines show the user rachel being created:
We can confirm that rachel was created by the attacker, so only two user passwords were successfully bruteforced: rossatron and chandler.
Answer: 2
10. When did the attack start?
(DD/MM/YYYY).
We can look at when a pattern for failed authentication started occurring:
sudo cat /mnt/Linux/var/log/secure | grep -F 'password check failed'
From August 23rd, at around 2PM the connection attempt rate is much higher:
Answer: 23/08/2021
11. What is the user used by the attacker to gain initial access to system?
It was previously shown that the attacker brutforced rossatron’s password first. However, the attacker connected and user chandler’s account to gain access to the system.
Answer: chandler
12. What is the MITRE ID of the technique used by the attacker to achieve persistence?
Before creating the user rachel, chandler’s bash history shows that a script named ‘p3333r.sh‘ was edited/created, executed and then removed from the system:
In between editing it, the attacker also checked the .ssh/authorized_keys.
The file no longer exists in the filesystem, and I was not able to recover it manually.
However, if we google for ‘mitre ssh authorized_keys’, T1098.004 fits the attack’s development.
Answer: T1098.004
13. What is the CVE number used by the attacker to escalate his Privilege?
The user escalated his privilege by creating user ‘rachel’, which had root privileges. Looking for ‘CVE dbus create user root’ points to CVE-2021-3560.
Answer: CVE-2021-3560
14. ...What is the email used to send commands?
After gaining more privilege the attacker dropped a backdoor to gain more persistence which receives commands from Gmail account…
At this point, the attacker has created user rachel and has root privileges. We can check the /var/log/secure file to check command history:
sudo cat /mnt/Linux/var/log/secure | grep 'PWD=/home/rachel'
Now, we just need to find the file ‘c2c.py’ and see if it contains gmail crendentials:
sudo find /mnt/Linux -name 'c2c.py' -exec grep 'gmail' "{}" -B 5 -A 5 \;
Answer: cdefender16@gmail.com
15. ...What is the secret word the attacker was able to exfiltrate?
The attacker downloaded a keylogger to capture users’ keystrokes.
In the commands issued from rachel’s user directory, many concern files named ‘xfil.py’ and ‘xfil.txt’:
sudo cat /mnt/Linux/etc/xfil.py
The script writes the keystrokes to term.bin in hexformat, and then saves the link to a txt file named ‘xfil.txt’, which is at /mnt/Linux/home/rachel/xfil.txt. In this case, its contents is ‘iof5‘. This page is archived in the wayback machine:
We can copy/paste to terminal and use xxd to convert the hex values:
echo -n '#hexvalue' | xxd -r -p > iof5.bin
I found this script that could dump the keys to a dictionary format. We can identify the victim’s keymap by looking at the vconsole.conf file:
sudo cat /mnt/Linux/etc/vconsole.conf
Which shows it’s a us keyboard:
ls -la /mnt/Linux/usr/lib/kbd/keymaps/xkb/ | grep us
#returns match for us.map.gz, which we copy & decompress
cp /mnt/Linux/usr/lib/kbd/keymaps/xkb/us.map.gz .
gunzip us.map.gz
Next, I used this python script to parse the .map file into a python dictionary:
from ctypes import *
def generate_map(map_file):
f = open(map_file, "rb")
Lines = f.readlines()
Lines.pop(0)
last_line = len(Lines) - 1
Lines.pop(last_line)
count = 0
out = {}
for line in Lines:
count += 1
decoded_line = line.decode("utf-8")
split_line = decoded_line.split(" ")[:5]
key = split_line[1]
if split_line[4].startswith('U+') or split_line[4].startswith('+U'):
split_line[4] = chr(int(split_line[4][2:], 16))
else:
pass
if key not in out:
out[key] = ""
out[key] = split_line[4]
return out
out = generate_map("us.map")
Next, we parse the file to decode the keys:
class _Event(LittleEndianStructure):
_fields_ = [
('sec', c_long),
('usec', c_long),
('type', c_ushort),
('code', c_ushort),
('value', c_uint),
]
def _memcpy(buf, fmt):
return cast(c_char_p(buf), POINTER(fmt)).contents
def parse_event(event):
return _memcpy(event[:sizeof(_Event)], _Event)
def print_pressed_log(file):
logged = open(file, "rb").read()
event_data = [logged[i: i + 24] for i in range(0, len(logged), 24)]
found_keys = ''
for i in event_data:
event_field = parse_event(i)
key_code = str(event_field.code)
if event_field.type == 1:
if event_field.value == 1:
if key_code in out.keys():
key_logged = out[key_code]
found_keys += key_logged
print(found_keys)
input_file = "iof5.bin"
print_pressed_log(input_file)
Which returns: YOUR SECRET IS HAVEAGOOOODDAY.
Answer: haveagoooodday
TLDR
– A Linux Disk Image is provided.
– The machine was accessed through a SSH-Bruteforce attack.
– It was then exploited by creating a root user, and editing ssh keys for persistence.
– Data was exfiltrated via termbin.com through a keylogger.
