Tanquem el Mòdul 4 amb un o diversos footholds a TechNova, gairebé sempre amb privilegis limitats: una shell com a www-data a la botiga, un usuari de servei al servidor intern Linux, un compte sense permisos en una estació Windows. La pregunta que obre el Mòdul 5 —fins on arriba realment aquest compromís?— comença a respondre's aquí. L'escalada de privilegis és el pas que converteix un accés menor en control total de l'host: de www-data a root, d'un usuari de domini corrent a Administrador o SYSTEM. Sense aquest salt, molts descobriments semblen inofensius; amb ell, una fallada "menor" es demostra com un compromís complet.

L'enquadrament no s'afluixa, ans al contrari. La post-explotació és el punt on un pentest professional es distingeix d'un manual d'abús. Tot passa al laboratori autoritzat de TechNova, dins de l'scope i les Regles d'Enfrontament (RoE). L'escalada té una única finalitat: mesurar i demostrar l'impacte real per a l'informe del Mòdul 6, no perjudicar ningú. I la regla d'or que repetirem a cada lliçó d'aquest mòdul: el pentester documenta cada acció i cada artefacte que crea, i el reverteix en acabar. Aquí, a més, cada tècnica ofensiva va acompanyada de la seva remediació, perquè l'objectiu és que TechNova tanqui el forat, no col·leccionar camins cap a root.

1. Què és l'escalada de privilegis i per què importa
2. Escalada vertical vs. horitzontal
3. Enumeració: el 90% de la feina (linPEAS/winPEAS)
4. Vectors a Linux
5. Vectors a Windows
6. PoC de baix impacte i captura d'evidència
7. Contrapartida: hardening i mínim privilegi
8. Errors comuns i consells
9. Exercicis
10. Conclusió

Escalar privilegis és passar del nivell d'accés que dona el foothold a un de superior. Importa per tres raons que van directes a l'informe:

• Mesura l'impacte real. Un RCE com a www-data és seriós; el mateix RCE que acaba en root significa control del servidor, les seves dades i les seves credencials. La diferència és la que el client necessita per prioritzar.
• Habilita tota la resta. Amb privilegis alts s'accedeix a hashos de credencials, configuracions i altres hosts. La persistència (05-02) i el pivoting (05-03) solen requerir aquest pas.
• Revela fallades de hardening. Cada via d'escalada és una mala configuració concreta i corregible: un SUID de més, un sudo massa permissiu, un servei amb permisos febles.

Dos moviments diferents que convé no confondre:

L'escalada horitzontal sembla menys greu, però sovint és el trampolí: el compte de contable pot tenir accés a dades sensibles o a un sudo que el de devapp no tenia. Totes dues es documenten. I compte: moure's a una altra màquina ja no és escalada, és moviment lateral —això és 05-03, no ho cobrim aquí.

L'escalada rarament és un exploit espectacular; gairebé sempre és trobar la mala configuració que ja hi és. Per això la fase reina és l'enumeració local des del foothold: entendre el sistema des de dins. S'automatitza amb scripts especialitzats que revisen centenars de comprovacions conegudes.

Aquests scripts ressalten els descobriments interessants (a linPEAS, en vermell/groc). No substitueixen el criteri: cal entendre per què cada descobriment és explotable. Nota professional: linPEAS/winPEAS són sorollosos i els detecta qualsevol EDR decent —cosa que, en un pentest, és també informació útil: si el SOC de TechNova no salta, és un descobriment defensiu per si mateix.

Els camins clàssics d'usuari a root en un host Linux. Cadascun amb què el fa explotable i com es remeia.

SUID — el vector més didàctic. Un binari amb el bit SUID s'executa amb els privilegis del seu propietari, no de qui el llança. Si aquest propietari és root i el binari permet executar comandes (o llegir/escriure fitxers arbitraris), tenim root. El projecte GTFOBins cataloga quins binaris comuns són abusables així.

La sortida uid=0(root) és la prova. No obrim una shell root persistent ni toquem /etc/shadow: demostrar l'escalada n'hi ha prou per a l'informe. Remediació: aquest find mai no hauria d'haver tingut SUID; es retira amb chmod u-s /usr/bin/find i s'audita la resta.

sudo mal configurat. Es revisa amb sudo -l. Si apareix quelcom com (root) NOPASSWD: /usr/bin/vim, és explotable: vim permet llançar una shell des de dins, així que executar-lo com a root dona root. Remediació: concedir per sudo només comandes que no permetin escape a shell, amb arguments concrets, evitant comodins.

A Windows l'objectiu sol ser SYSTEM o Administrador. Els camins canvien de nom però la lògica —una configuració feble que dona més del que toca— és idèntica.

Exemple — permisos de servei febles. Si un servei corre com a SYSTEM i el nostre compte pot reconfigurar el seu binari, podem fer que executi quelcom nostre amb privilegis SYSTEM.

El fitxer poc.txt amb nt authority\system demostra l'execució com a SYSTEM. Immediatament després es restaura el binPath original (l'anotem abans de tocar-lo) per no deixar el servei trencat: revertir és obligatori. Remediació: corregir l'ACL del servei perquè els usuaris normals no puguin reconfigurar-lo; auditar amb accesschk.

Credencials a alt nivell. Un cop amb privilegis d'administrador, un atacant abocaria secrets de la memòria del procés LSASS (eines tipus Mimikatz) o de configuracions insegures. Aquí només ho anomenem com a impacte a documentar: l'ús d'aquestes credencials per saltar a altres hosts és moviment lateral (05-03), no escalada.

El principi de tot el mòdul: demostrar, no destruir. Una PoC d'escalada correcta:

• Executa la mínima acció que prova el privilegi: id (Linux) o whoami (Windows), amb hora i hostname.
• No obre backdoors, no toca dades sensibles, no deixa shells root permanents.
• Reverteix qualsevol canvi temporal (un binPath alterat, un fitxer de PoC): es restaura l'estat i s'anota a la bitàcola de l'engagement.
• Captura evidència clara per al Mòdul 6: comanda, sortida (uid=0/SYSTEM), marca de temps, i el vector concret (quin SUID, quina regla sudo, quin servei).

El missatge que portarà l'informe a TechNova. Gairebé totes les vies d'escalada són configuració, no fallades irreparables:

• Mínim privilegi en tot: serveis amb el menor privilegi possible, usuaris sense sudo innecessari, comptes d'administrador separats de l'ús diari.
• Auditar SUID/capabilities/serveis: revisions periòdiques de find -perm -4000, getcap -r /, ACL de serveis; retirar tot allò que no tingui justificació.
• sudo restringit: regles específiques, sense comodins, sense binaris amb escape a shell.
• Pegat del kernel i del SO: tanca els exploits locals d'escalada.
• Windows modern: LAPS (contrasenyes d'administrador local úniques i rotades), Credential Guard, UAC alt, permisos NTFS correctes.
• Detecció: EDR i monitoratge de creacions de processos anòmales, canvis de configuració de serveis, execució de linPEAS/winPEAS o d'eines conegudes.

• Saltar primer a un kernel exploit. Són els més propensos a tombar l'host (kernel panic = denegació de servei no acordada). Esgota abans SUID, sudo, cron i serveis; deixa el kernel per al final i només amb acord.
• No revertir un canvi temporal. Deixar un binPath alterat o un servei aturat és trencar producció i saltar-se la regla d'or. Anota l'estat abans de tocar i restaura'l sempre.
• Escalar i posar-se a furgar en dades. La PoC acaba en uid=0/SYSTEM. Llegir nòmines o correus excedeix la demostració llevat que el RoE ho demani explícitament.
• Confondre escalada horitzontal amb "no greu". Moure's a un altre compte del mateix nivell sol ser el trampolí cap a root o a dades sensibles; documenta-la.
• Reportar la via sense la remediació. "Es va escalar a root" sense dir quin SUID o quina regla sudo ho va permetre no li serveix al client. El valor és a l'arranjament concret.
• Oblidar que linPEAS/winPEAS són sorollosos. Si l'EDR no els detecta, això també és un descobriment (defensa insuficient) que va a l'informe.
• Consell: enumera exhaustivament abans d'intentar res. El 90% de les escalades estan servides a la sortida de linPEAS/winPEAS si saps llegir-la.

Exercici 1. Des del teu foothold com a www-data a la botiga de TechNova, find / -perm -4000 revela que /usr/bin/find té SUID root. Explica per què això permet escalar, escriu una PoC de baix impacte que només demostri el privilegi, i dona la remediació exacta. Com detectaria l'equip blau aquest abús?

Exercici 2. En una estació Windows tens un compte d'usuari normal. accesschk mostra que pots reconfigurar un servei que corre com a SYSTEM. Descriu la seqüència d'escalada respectant el control d'impacte i la reversió, quina evidència capturaries i dues mesures de hardening que ho haurien impedit.

Exercici 3. Distingeix, amb un exemple de TechNova cadascun, escalada vertical i horitzontal, i explica per què l'horitzontal, encara que sembli menys greu, es documenta igual. Indica a més on acaba l'escalada i què ja seria matèria de la lliçó 05-03.

Solució 1. find amb SUID root s'executa amb privilegis del seu propietari (root), i find permet llançar comandes amb -exec; per tant pot executar qualsevol ordre com a root. PoC de baix impacte (segons GTFOBins), demostrant només el privilegi: find . -exec /bin/sh -p -c 'id' \;, la sortida de la qual uid=0(root) és la prova —no s'obre shell persistent ni es toquen fitxers. Remediació: aquest find mai no hauria d'haver tingut SUID; es retira amb chmod u-s /usr/bin/find i s'auditen periòdicament els binaris SUID amb find / -perm -4000. Detecció (equip blau): l'auditoria del kernel (auditd) o l'EDR alerten davant un procés fill /bin/sh amb EUID 0 llançat per find des d'un compte sense privilegis, un patró anòmal característic de l'abús de SUID.

Solució 2. Seqüència: (1) confirmar amb accesschk que el servei és reconfigurable pel nostre compte; (2) anotar el binPath original abans de tocar res; (3) reconfigurar-lo temporalment a una comanda inocua (cmd /c whoami > C:\Windows\Temp\poc.txt); (4) reiniciar el servei i llegir poc.txt, que mostra nt authority\system com a prova d'execució amb privilegis SYSTEM; (5) restaurar de seguida el binPath original amb sc config i esborrar poc.txt, anotant-ho a la bitàcola. Evidència: el whoami com a SYSTEM, hora i nom del servei afectat. Hardening que ho hauria impedit: (a) corregir l'ACL del servei perquè els usuaris normals no puguin reconfigurar-lo; (b) aplicar mínim privilegi i auditar serveis amb accesschk de manera periòdica.

Solució 3. Vertical: de www-data (usuari de servei) a root al servidor de la botiga —es puja de nivell de privilegi—. Horitzontal: de devapp al compte contable, tots dos usuaris normals sense privilegis de root —es passa d'un compte a un altre del mateix nivell—. L'horitzontal es documenta perquè sol ser el trampolí: contable pot tenir accés a dades sensibles o una regla sudo que devapp no tenia, habilitant després una escalada vertical. L'escalada acaba en el control de l'host (root/SYSTEM en aquesta màquina); usar les credencials o l'accés obtinguts per saltar a altres màquines de la xarxa 10.10.10.0/24 ja és moviment lateral (05-03), fora de l'abast d'aquesta lliçó.

Hem fet el primer pas de la post-explotació: convertir un foothold amb privilegis limitats en control de l'host. Vam veure la diferència entre escalada vertical i horitzontal; que el gruix de la feina és enumerar (linPEAS/winPEAS) per trobar la mala configuració que ja hi és; i vam recórrer els vectors clàssics a Linux (SUID, sudo, cron, capabilities, PATH, kernel) i a Windows (serveis, tokens, UAC, credencials), cadascun amb una PoC de baix impacte que només demostra el privilegi, amb reversió de tot canvi temporal i la seva remediació concreta. La contrapartida va ser constant: mínim privilegi, hardening i pegat, amb detecció per EDR.

Ja som root/SYSTEM en un o diversos hosts de TechNova, amb l'evidència capturada. La següent pregunta natural de l'atacant —i per tant del pentester que mesura la seva capacitat— és com conservar aquest accés sense haver de reexplotar cada vegada. Això és 05-02 Manteniment de l'Accés: els mecanismes de persistència, però entesos com a demostració d'impacte en un engagement autoritzat, amb la contrapartida defensiva en primer pla i la regla d'or més present que mai: tot allò que es crea, es documenta i es reverteix.