A 05-01 vam escalar privilegis i ja som root/SYSTEM en un o diversos hosts de TechNova. Un atacant real, arribat a aquest punt, voldria no perdre aquest accés: si la màquina es reinicia, si es canvia la contrasenya que va explotar o si es pega la fallada d'entrada, vol poder tornar sense reexplotar. A això se'n diu persistència o manteniment de l'accés. En un pentest autoritzat, la persistència té un sentit molt diferent del de l'atacant: serveix per demostrar l'impacte —"amb aquest foothold, un adversari hauria pogut reenganxar-se aquí"— i per provar si TechNova ho detecta. No és una finalitat en si mateixa, i ni de bon tros és deixar portes obertes.

Aquesta lliçó exigeix l'enquadrament més estricte del mòdul, i no l'afluixem. La regla d'or es converteix aquí en l'eix central: el pentester documenta cada mecanisme de persistència que crea —compte, tasca, servei, clau, webshell— i el REVERTEIX en acabar, lliurant al client la llista completa de tot allò introduït. Res d'accessos ocults que es queden. De fet, els pentesters professionals no oculten aquesta activitat: deixen rastre auditable precisament perquè el client pugui verificar la neteja. I per això ensenyem cada mecanisme des de la perspectiva defensiva: què faria l'atacant, per què, i —en primer pla— com ho detecta i ho preveu l'equip blau. No hi ha receptes de rootkits ni d'ocultació profunda; aquests només s'anomenen per explicar què ha de caçar el defensor.

1. Què significa "persistència" en un engagement autoritzat
2. La regla d'or: crear, documentar, revertir
3. Mecanismes de persistència i la seva detecció
4. Un exemple controlat: clau SSH autoritzada
5. La perspectiva defensiva en primer pla
6. Rootkits i ocultació: només allò que el defensor ha de caçar
7. Errors comuns i consells (inclosos els ètics)
8. Exercicis
9. Conclusió

Per a l'atacant, persistir és sobreviure a reinicis, pegats i canvis de credencials. Per al pentester de TechNova, la persistència respon a dues preguntes de l'informe:

• Impacte: un adversari que arribés fins aquí podria reenganxar-se de manera estable? Demostrar-ho eleva la gravetat d'un descobriment de "accés puntual" a "compromís sostenible".
• Detecció: el SOC de TechNova se n'assabenta quan algú crea un compte nou, una tasca programada o un servei? Aquest és, moltes vegades, el descobriment més valuós —una escletxa en la capacitat de detecció.

La persistència mai és l'objectiu final de l'engagement autoritzat. L'objectiu és l'informe; la persistència és una evidència més que es captura i, tot seguit, es retira.

Tot artefacte de persistència segueix un cicle tancat i auditable:

Això se sosté amb una bitàcola d'artefactes: una taula que el pentester manté en temps real.

Aquesta taula és part de l'entregable. Si alguna cosa no es pot revertir dins de la finestra, es marca i es comunica explícitament al contacte tècnic perquè l'elimini. Un pentester no se'n va deixant dubtes sobre allò que va introduir.

Els mecanismes que un atacant faria servir —i que, per tant, el defensor ha de conèixer i caçar. La columna protagonista és com es detecta i preveu:

El patró es repeteix: gairebé tota persistència crea o modifica quelcom que un sistema amb baseline, integritat de fitxers i alertes d'esdeveniments pot detectar. Aquesta és la lliçó per a TechNova.

Il·lustrem un sol mecanisme, de baix impacte i fàcilment reversible, per veure el cicle complet. Afegir la nostra clau pública a authorized_keys d'un compte dona accés per SSH sense contrasenya. Ho fem amb marca identificable per poder revertir-ho i auditar-ho.

El comentari pentest-technova és deliberat: fa l'entrada traçable i garanteix que revertim exactament el que vam posar, sense tocar claus legítimes. Contrapartida defensiva (protagonista): protegir authorized_keys amb monitoratge d'integritat de fitxers (que alerti davant qualsevol canvi), restringir-ne els permisos, i preferir gestió centralitzada de claus; un canvi en aquest fitxer fora d'un procés aprovat ha de generar una alerta al SIEM.

Si aquesta lliçó deixa un sol missatge per a TechNova, és com detectar i prevenir la persistència —perquè és exactament el que un atacant real intentaria i el que el SOC ha de caçar:

• Baselines: conèixer l'estat normal —quins comptes, serveis, tasques i claus existeixen— perquè qualsevol afegit ressalti. Sense baseline no hi ha detecció.
• Integritat de fitxers (FIM): vigilar fitxers sensibles (authorized_keys, /etc/passwd, webroot, punts d'arrencada) i alertar davant canvis.
• Alertes d'esdeveniments al SIEM: creació de comptes (4720), de tasques (4698), de serveis (7045), canvis a cron. Reenviats de manera centralitzada (enllaça amb 05-04).
• EDR: detecta els patrons de comportament típics de la persistència (processos que es registren per a autoarrencada, shells llançades per serveis web).
• Mínim privilegi i revisió de comptes: menys comptes privilegiats i revisions periòdiques redueixen tant la superfície com el lloc on amagar-se.
• Higiene de credencials: rotar claus després d'un incident i no refiar-se només del canvi de contrasenya —una clau SSH o una tasca persistent l'ignoren.

Un atacant avançat intentaria ocultar la seva persistència amb rootkits (que amaguen processos, fitxers o connexions) o tècniques d'ocultació profunda. Aquí no les ensenyem com a recepta, i el pentester professional de TechNova no les fa servir per amagar-se del client: al contrari, deixa tot traçable. Les anomenem només perquè el defensor sàpiga què existeix i què buscar:

• Què són: programari que manipula el sistema operatiu perquè els seus artefactes no apareguin a les eines normals (ps, ls, llistat de serveis).
• Per què importen al defensor: per això la detecció no es pot refiar només del propi host compromès —un rootkit menteix al sistema on corre.
• Com es cacen (el rellevant): verificació d'integritat des de fora de l'host (arrencada neta, comparació d'imatges), telemetria centralitzada que l'host no pot alterar (logs ja reenviats al SIEM), detecció d'anomalies de xarxa, i eines de comprovació de rootkits. La defensa robusta assumeix que l'host compromès no és font fiable i es recolza en evidència externa.

Aquest és l'enfocament correcte: conèixer l'amenaça per defensar-se, no per executar-la contra el client.

• [Ètic] Deixar un artefacte sense revertir. És l'error més greu del mòdul: un compte, tasca o webshell oblidada és un backdoor real que pot acabar en mans d'un atacant de veritat. Reverteix tot i lliura la llista completa. La bitàcola existeix perquè no se t'escapi cap.
• [Ètic] Persistir sense que el RoE ho contempli. Provar persistència pot requerir acord explícit; instal·lar-la "perquè sí" excedeix el mandat. Confirma l'abast abans.
• [Ètic] Ocultar la teva activitat al client. El pentester professional deixa rastre auditable; no evadeix el SOC per "guanyar", sinó per mesurar la seva detecció si així es va pactar. Amagar-te del client traeix l'encàrrec.
• Usar artefactes sense marca identificable. Sense un comentari o nom reconeixible (pentest-technova), no pots garantir que vas revertir exactament el teu. Marca sempre allò que crees.
• Reportar la persistència sense la contrapartida. Cada mecanisme va amb la seva detecció/prevenció (baseline, FIM, alertes). El valor per a TechNova és aprendre a caçar-la.
• Confondre persistència amb moviment lateral. Mantenir l'accés en aquest host és 05-02; fer-lo servir per saltar a altres hosts és 05-03. No els barregis.
• Consell: tracta cada artefacte com un préstec, no com una possessió. El crees, el mostres, el documentes i el retornes. Si dubtes de si podràs revertir alguna cosa, no la creïs.

Exercici 1. Vas a demostrar persistència en un host Linux de TechNova (10.10.10.15) afegint una clau SSH autoritzada, dins d'un RoE que ho contempla. Escriu el cicle complet —crear, documentar, capturar evidència, revertir— amb especial cura en com garanteixes que vas revertir exactament el teu artefacte. Afegeix la contrapartida defensiva que TechNova hauria d'implementar.

Exercici 2. El SOC de TechNova pregunta quins esdeveniments hauria de vigilar per detectar els tres mecanismes de persistència més comuns a Windows (compte nou, tasca programada, servei nou). Enumera'ls i explica quin paper juga tenir un baseline perquè aquestes alertes siguin útils.

Exercici 3. Un company júnior proposa instal·lar un rootkit "perquè la persistència no la detecti el SOC i així l'exercici sigui més realista". Explica per què això és un error ètic i metodològic en un pentest autoritzat, i reformula l'objectiu de manera correcta.

Solució 1. Cicle complet: (1) Crear amb marca identificable: echo "ssh-ed25519 AAAA... pentest-technova" >> ~/.ssh/authorized_keys. (2) Documentar a la bitàcola: host 10.10.10.15, compte, fitxer ~/.ssh/authorized_keys, comentari pentest-technova, data i hora. (3) Capturar evidència: demostrar el re-accés per SSH una sola vegada (captura amb hora) i parar. (4) Revertir exactament allò afegit usant el comentari com a àncora: sed -i '/pentest-technova/d' ~/.ssh/authorized_keys i verificar amb grep -c pentest-technova ~/.ssh/authorized_keys que retorna 0. La marca garanteix que s'elimina només la clau del pentester, sense tocar claus legítimes. Contrapartida: monitoratge d'integritat de fitxers sobre authorized_keys amb alerta davant qualsevol canvi, permisos restrictius, i gestió centralitzada de claus; el canvi s'hauria reflectit com a alerta al SIEM.

Solució 2. Esdeveniments de Windows: 4720 (creació d'un compte d'usuari), 4698 (creació d'una tasca programada) i 7045 (instal·lació d'un servei nou). Reenviats a un SIEM central perquè l'host compromès no pugui ocultar-los (enllaça amb 05-04). El baseline és imprescindible perquè aquestes alertes per si soles generen molt soroll en un entorn gran: només sabent quins comptes, tasques i serveis són normals i esperats pot el SOC distingir un afegit maliciós de l'activitat legítima d'administració. Sense baseline, l'alerta 4720 es perd entre les creacions rutinàries; amb baseline, un compte nou no previst salta de seguida.

Solució 3. És un error ètic perquè el pentester professional no oculta la seva activitat al client: manté un rastre auditable de tot allò que fa, i un rootkit va just en contra d'això, a més d'introduir programari difícil de revertir del tot (risc de deixar un artefacte persistent real). És un error metodològic perquè l'objectiu de l'engagement no és "guanyar-li al SOC amagant-se", sinó mesurar i millorar la detecció de TechNova. Reformulació correcta: si el RoE contempla provar la capacitat de detecció, es creen artefactes de persistència traçables i documentats (amb marca identificable), s'observa si el SOC els detecta, i el descobriment —el detecti o no— es porta a l'informe amb la seva contrapartida; en acabar, tot es reverteix i es lliura la llista al client. L'amenaça del rootkit es documenta com quelcom que el defensor ha de poder caçar (telemetria externa, integritat des de fora de l'host), no com quelcom que el pentester executa.

Hem tractat el manteniment de l'accés com el que ha de ser en un pentest professional: una demostració d'impacte i una prova de la capacitat de detecció de TechNova, no una finalitat ni un backdoor. Vam veure els mecanismes que un atacant faria servir —comptes, tasques/cron, serveis, claus SSH, webshells— sempre amb la seva contrapartida defensiva en primer pla (baselines, integritat de fitxers, alertes d'esdeveniments al SIEM, EDR), i vam il·lustrar el cicle complet amb una clau SSH marcada i revertida. Els rootkits i l'ocultació van aparèixer només com a amenaça que el defensor ha de conèixer i caçar amb telemetria externa, mai com a recepta.

Per damunt de la tècnica, queda la regla d'or: tot artefacte es crea amb acord, es documenta a la bitàcola, es captura com a evidència i es reverteix, lliurant al client la llista completa. El pentester no deixa accessos ocults ni amaga la seva activitat. Amb l'accés escalat (05-01) i la seva persistència entesa i controlada (05-02), el compromís en aquest host està mesurat. La següent pregunta és fins on arriba a la xarxa: com fer servir aquest host com a trampolí cap a segments interns que no eren accessibles directament. Això és 05-03 Pivoting i Moviment Lateral.