Arribem a l'última lliçó del Mòdul 2. Fins aquí hem après a recollir informació de manera passiva (02-01), a confirmar-la i ampliar-la de manera activa (02-02) i a fer-ho amb les eines adequades orquestrades en un flux (02-03). El resultat és un inventari llarg però desordenat: subdominis, IP, amfitrions vius, versions, correus, usuaris, tecnologies. Un munt de dades, sí, però encara no una superfície d'atac.

Aquesta lliçó fa dues coses. Primer, incorpora la disciplina de l'OSINT (Open Source Intelligence) en la seva vessant més rica i delicada: la que gira entorn de les persones (correus, credencials filtrades, empremta digital) i de l'exposició moderna (núvol, buckets, repositoris de codi). Segon, i sobretot, consolida tot el recollit al mòdul en un mapa de superfície d'atac prioritzat: el lliurable que diu al pentester —i al Mòdul 3— per on començar. Com que l'OSINT toca dades personals, dedicarem un apartat central al seu marc ètic i legal (RGPD), coherent amb les RoE de TechNova.

1. Què és l'OSINT i com encaixa en el reconeixement
2. OSINT de persones: correus, empleats i empremta digital
3. Credencials filtrades en bretxes
4. Exposició al núvol: buckets i serveis
5. Repositoris de codi i secrets
6. Marc ètic i RGPD de l'OSINT sobre persones
7. Consolidar: el mapa de superfície d'atac
8. Prioritzar la superfície d'atac de TechNova
9. Errors comuns i consells
10. Exercicis
11. Conclusió

L'OSINT és la disciplina d'obtenir i analitzar informació de fonts obertes (públiques) per produir intel·ligència: no dades soltes, sinó coneixement accionable. En pentesting, l'OSINT és la capa que dona context humà i organitzatiu a la infraestructura que ja hem mapat.

Convé situar bé els termes:

• Tot el que vam fer a 02-01 és, en sentit ampli, OSINT (fonts obertes).
• Però quan parlem d'"OSINT" com a disciplina pròpia, solem referir-nos al més orientat a persones i exposició indirecta: qui treballa a l'empresa, quins correus tenen, si les seves credencials apareixen en bretxes, què han pujat sense voler al núvol o a GitHub.

És informació que rarament és al DNS o en un certificat, però que obre vectors molt reals (phishing dirigit, reutilització de contrasenyes, accés a dades exposades). Gairebé tot l'OSINT és passiu; el seu risc no és tècnic, sinó ètic i legal, perquè treballem amb dades d'individus.

Les organitzacions deixen una empremta de persones: perfils professionals, autors d'articles, ponents en esdeveniments, signants de documents. A partir del patró de correu que vam deduir en lliçons anteriors ([email protected], vist a jlopez, mgarcia, sistemas@), podem construir i validar llistes de correus corporatius.

A partir d'aquí s'elabora un mapa de persones amb rol i correu. Per a què serveix, dins de l'abast?

• Vector de phishing/enginyeria social (només si l'abast ho autoritza): el correu de rrhh@ o d'un administrador és un objectiu típic.
• Llavor per a atacs a credencials (Mòdul 4): usuaris probables per a proves autoritzades.
• Comprensió organitzativa: qui administra què ajuda a interpretar la infraestructura.

Contrapartida defensiva: formació en conscienciació anti-phishing, no publicar organigrames tècnics detallats i fer servir àlies de rol (soporte@) en lloc de noms personals on sigui possible.

Amb el temps, multitud de serveis pateixen bretxes de dades i les credencials acaben en abocaments públics. Si un empleat va fer servir el seu correu corporatiu en un servei de tercers que va ser compromès, aquest correu —i de vegades una contrasenya o el seu hash— apareix en aquests abocaments. Consultar aquestes fonts és passiu (interroguem una base de dades de tercers com ara Have I Been Pwned), però és del més sensible del mòdul.

Lectura: el correu [email protected] apareix en dues bretxes que inclouen contrasenyes. Això importa per la reutilització de contrasenyes: si jlopez va fer servir la mateixa contrasenya a ForoTech2019 que a la VPN de TechNova, un atacant entra sense explotar cap vulnerabilitat tècnica.

Enquadrament imprescindible:

• Només verifiquem l'exposició, no fem servir les contrasenyes filtrades fora de l'abast ni contra tercers.
• L'ús de credencials concretes per intentar accés (credential stuffing) pertany al Mòdul 4 i només si el contracte ho autoritza explícitament.
• Manejar abocaments de contrasenyes reals té implicacions legals serioses; en una auditoria real es tracta amb molta cura i assessoria legal.

Contrapartida defensiva: MFA a tots els accessos, polítiques que prohibeixin reutilitzar contrasenyes corporatives en serveis externs i monitoratge de credencials exposades.

La infraestructura moderna viu al núvol, i una font enorme de fuites són els buckets d'emmagatzematge mal configurats (S3 d'AWS, Blobs d'Azure, GCS) deixats com a públics. Solen seguir convencions de nom predictibles a partir del nom de l'empresa: technova-backups, technova-dev, technova-assets.

Un codi 200 (en lloc de 403 Forbidden) suggereix que el bucket és accessible. Si a més permet llistar-ne el contingut, podríem veure fitxers exposats:

Un db_dump_2023.sql o un fitxer .env (que sol contenir credencials de base de dades i claus d'API) és una troballa crítica. Important d'abast: el bucket ha de pertànyer a TechNova i estar dins del contracte. Trobar un bucket amb el seu nom no autoritza a descarregar-ne el contingut si l'abast no ho inclou; documenta l'exposició i consulta abans d'anar més enllà.

Contrapartida defensiva: bloquejar l'accés públic per defecte, revisar polítiques de bucket periòdicament i no emmagatzemar secrets ni abocaments en emmagatzematge accessible.

Els desenvolupadors de vegades publiquen codi en repositoris (GitHub, GitLab) que filtra informació: claus d'API, contrasenyes, tokens, rutes internes, adreces IP. Recordem que a 02-02 va aparèixer un git.technova.lab. Cercar pel nom de l'organització o el domini en repositoris públics és OSINT passiu molt productiu.

Exemple de troballa (fragment fictici trobat en un commit antic):

Lectura: un desenvolupador va pujar credencials reals que, encara que després les "esborrés", continuen a l'historial de commits. Veiem l'amfitrió intern db-interno.technova.lab (coincideix amb el 10.10.10.40 de la transferència de zona de 02-02), un usuari de BD i una contrasenya. Eines com els cercadors de secrets automatitzen la detecció d'aquests patrons en repositoris. Tot això es documenta com a exposició; el seu ús per accedir és matèria del Mòdul 4 i només dins de l'abast.

Contrapartida defensiva: escaneig de secrets a CI/CD (pre-commit hooks), rotació immediata de qualsevol secret que arribi a un repositori i política de no versionar mai fitxers de configuració amb credencials.

L'OSINT sobre persones és legal i potent, però trepitja terreny de dades personals, regulades a la UE pel RGPD. Que una cosa sigui accessible públicament no vol dir que el seu ús sigui lliure. Principis que han de guiar la teva feina:

• Base i finalitat legítimes. L'única raó per recollir aquestes dades és l'auditoria autoritzada de TechNova. No les facis servir per a res més.
• Minimització. Recull només el necessari per a l'objectiu. No acumulis dades personals "per si de cas".
• Abast estricte. OSINT sobre empleats només de l'organització objectiu i només si el contracte ho contempla. Res de familiars, tercers o proveïdors fora de l'abast.
• No fer mal. Trobar la vida privada d'un empleat no autoritza a exposar-la, contactar-la ni fer-la servir fora del que s'hagi pactat. Res d'assetjament ni enginyeria social no autoritzada.
• Seguretat i esborrat. Guarda aquestes dades xifrades, amb accés restringit, i esborra-les segons el que s'hagi acordat en tancar el projecte.
• Transparència a l'informe. Documenta què vas recollir i per què; el client ha de poder entendre i justificar el tractament.

En resum: el límit de l'OSINT no és tècnic (gairebé tot és assolible), és ètico-legal. Un professional es distingeix precisament per respectar aquest límit. En cas de dubte, consulta el contracte i, si cal, assessoria legal.

La superfície d'atac és el conjunt de tots els punts pels quals un atacant podria intentar entrar: cada amfitrió, servei, subdomini, compte, credencial o dada exposada. Consolidar el mòdul consisteix a reunir tot el recollit (02-01 a 02-04) en un únic mapa.

El mapa distingeix tres capes: externa (el que és accessible des d'Internet), interna (la xarxa 10.10.10.0/24) i humana/dades (persones, credencials, exposició al núvol i codi). Els nodes en vermell marquen el més crític.

Un mapa no n'hi ha prou: cal prioritzar perquè el Mòdul 3 sàpiga per on començar. Un criteri senzill combina valor (què es guanya si cau) i exposició/facilitat (com d'accessible i feble sembla). La taula següent ordena la superfície de TechNova:

Com es llegeix aquesta priorització:

• El crític combina alt valor i evidència forta de debilitat: un db-interno amb credencials ja filtrades i un bucket públic amb un abocament de BD.
• La botiga és prioritat alta per ser l'objectiu principal de l'abast, estar a Internet i executar programari sense suport (PHP 7.2).
• Els entorns de staging/dev pugen de prioritat perquè solen estar pitjor protegits que producció.

Aquesta taula prioritzada és el lliurable que connecta el reconeixement amb l'escaneig. No hem explotat res: hem dibuixat on mirar primer.

• Confondre "públic" amb "d'ús lliure". Que una dada personal sigui accessible no autoritza qualsevol ús; el RGPD i el contracte manen.
• Sortir de l'abast amb OSINT. Investigar familiars d'un empleat, un proveïdor o fer servir credencials filtrades contra serveis de tercers és creuar la línia. Cenyeix-te a l'organització i a l'abast.
• Acumular dades personals innecessàries. Recull el mínim; guarda xifrat; esborra en tancar. La minimització et protegeix a tu i al client.
• Lliurar un inventari sense prioritzar. Una llista de 200 amfitrions no ajuda; un mapa amb 5 prioritats sí. El valor és en l'anàlisi, no en el volum.
• Fer servir troballes d'OSINT per explotar en aquesta fase. El recon documenta; l'explotació (fer servir aquelles credencials o aquell secret) és de mòduls posteriors i només dins del contracte.
• Consell: en prioritzar, creua sempre valor i exposició. Una fallada greu en un sistema inaccessible pesa menys que una de mitjana en un sistema exposat a Internet.

Exercici 1. Trobes que [email protected] apareix en una bretxa de dades amb contrasenya. Enumera què pots fer amb aquesta dada en la fase de reconeixement i què no pots fer (i en quin mòdul i sota quina condició es podria fer el segon).

Exercici 2. Ordena per prioritat aquestes tres troballes per al Mòdul 3 i justifica-ho amb els criteris de valor i exposició: (a) un intranet intern només accessible des de dins; (b) la botiga a Internet amb PHP 7.2 sense suport; (c) un bucket technova-backups públic amb un db_dump.sql.

Exercici 3. Un company proposa investigar els perfils personals a xarxes socials de la parella de l'administrador de sistemes "per tenir més context". Explica per què això és inacceptable, citant almenys dos principis del marc ètic/RGPD.

Solució 1. Puc: documentar que el correu apareix en una bretxa, anotar el vector (possible reutilització de contrasenya) i reflectir-ho al mapa de superfície com a risc, informant-ne TechNova. No puc: fer servir aquesta contrasenya per intentar accedir a la VPN, la intranet o qualsevol sistema. Aquest intent (credential stuffing) pertany al Mòdul 4 i només si el contracte ho autoritza explícitament. En reconeixement només es verifica i documenta l'exposició, mai s'empra la credencial.

Solució 2. Ordre: 1r (c) el bucket públic amb db_dump.sql (valor molt alt —un abocament de BD— i exposició màxima —accessible des d'Internet sense autenticació—: crític i immediat). 2n (b) la botiga amb PHP 7.2 (valor alt —objectiu principal de l'abast— i exposició alta —Internet + programari sense suport, propens a vulnerabilitats conegudes—). 3r (a) la intranet interna (encara que el seu valor sigui rellevant, la seva exposició és baixa: només assolible des de dins, així que requereix primer trepitjar la xarxa). El criteri: a igualtat de valor, prioritza el més exposat i fàcil d'assolir.

Solució 3. És inacceptable perquè: (1) viola l'abast: la parella de l'administrador és un tercer aliè a l'organització objectiu i no és al contracte; (2) incompleix la minimització del RGPD: no és una dada necessària per a la finalitat d'auditar la seguretat de TechNova; i (3) vulnera el principi de no fer mal/no assetjar: investigar la vida privada de persones no relacionades és intrusiu i potencialment il·lícit. L'OSINT de persones es limita a empleats de l'organització objectiu, només si el contracte ho contempla i només amb dades pertinents a l'objectiu tècnic.

Amb aquesta lliçó tanquem el Mòdul 2. Hem completat el reconeixement incorporant la dimensió OSINT —persones i correus, credencials filtrades en bretxes, exposició al núvol i secrets en repositoris— sempre sota un marc ètic i de RGPD estricte, i hem fet el més important: consolidar i prioritzar tot el recollit en un mapa de superfície d'atac. Ja no tenim un inventari dispers, sinó una llista raonada d'objectius amb la seva prioritat, distingint superfície externa, interna i humana.

Recapitulant el mòdul: vam partir de zero sobre TechNova i ara coneixem el seu domini i contactes (02-01), quins amfitrions estan vius i quines versions executen (02-02), amb quines eines orquestrar el recon (02-03) i com es veu —i per on començar— la seva superfície d'atac prioritzada (02-04). El reconeixement ha complert la seva funció: ens diu on mirar.

Ara toca mirar de debò. Al Mòdul 3: Escaneig i Enumeració, agafarem aquesta llista prioritzada —començant per la botiga, els entorns exposats i els amfitrions vius de 10.10.10.0/24— i passarem del "què existeix i on" al "quins ports, serveis i versions exactes hi ha, i quines vulnerabilitats presenten". La primera lliçó, 03-01 Escaneig de Ports, reprèn just on vam deixar el nmap -sn: ara sí, obrirem els ports en profunditat.