La Season 11 di Hack The Box si è appena chiusa: tredici settimane, tredici macchine, difficoltà crescente da Easy a Insane. Nell'ordine: Reactor, DevHub, Connected, Checkpoint, Nimbus, Enigma, MakeSense, Paperwork, Bedside, Cohort, DarkZeroReturns, DanglingTree e BlockSynergy.
Abbiamo affrontato l'intera stagione con BackBox AI e siamo arrivati in fondo: tredici user flag e tredici system flag, comprese le macchine classificate Insane.
Il punteggio è il dato meno significativo di quella schermata. Non abbiamo rincorso i first blood, e la posizione in classifica dipende dai tempi di risoluzione più che dalle capacità messe in campo. Da tredici settimane passate su bersagli sempre nuovi volevamo ricavare altro: capire quanta parte di un'attività offensiva riesca oggi a sostenere un agente da solo, e in quali momenti abbia ancora bisogno di una persona accanto.
Una stagione che somiglia sempre meno a un CTF
Il pregio di una stagione intera sta nel fatto che non esiste una tecnica singola in grado di coprirla. Le macchine spaziavano tra Linux e Windows, applicazioni web moderne, Active Directory, ambienti cloud e AWS, strumenti di sviluppo, servizi infrastrutturali, scenari di supply chain e stack di machine learning. Ogni settimana l'agente ripartiva da zero su un bersaglio sconosciuto, con una struttura diversa e presupposti diversi da rimettere in discussione.
È proprio questa varietà a rendere l'esercizio significativo. Un modello che ha memorizzato una tecnica risolve una macchina. Portarne a termine tredici di seguito, in ecosistemi che non hanno quasi nulla in comune, richiede qualcosa di diverso: guardare un sistema sconosciuto, capire di cosa si tratta e decidere da dove cominciare.
Un agente non è un modello
La conclusione che ricaviamo dalla stagione è netta. Gli agenti risolvono ormai in autonomia una quota consistente dei problemi che compongono il lavoro di sicurezza offensiva. Non significa che ogni scenario possa procedere senza supervisione, e più avanti spieghiamo dove non è andata così. Significa però che un agente costruito con l'architettura giusta percorre già catene di attacco complesse, dall'enumerazione alla compromissione completa, senza che gli venga spiegato come.
Vale la pena sottolineare che è un'affermazione sul sistema, non sul modello che ne sta al centro. Le prestazioni dipendono dall'harness: gli strumenti che l'agente può richiamare, la possibilità di osservare e modificare l'ambiente, il modo in cui vengono gestiti memoria e contesto, l'orchestrazione che gli permette di pianificare, agire, verificare il risultato e riprovare. Abbiamo spiegato in dettaglio perché il vantaggio si costruisca nell'harness, e una stagione come questa ne è la verifica sul campo.
Due sistemi costruiti sullo stesso modello linguistico possono comportarsi in modo completamente diverso. Gran parte della differenza sta in tutto ciò che circonda i pesi del modello.
Il codice sorgente e il sistema in esecuzione
La lezione tecnica più chiara della stagione riguarda ciò che succede quando analisi statica e analisi dinamica si incontrano.
Quando il codice sorgente è disponibile, un agente lo legge, ricostruisce la logica applicativa e individua comportamenti anomali o superfici di attacco promettenti molto più in fretta di quanto farebbe una persona sugli stessi file. Da lì nascono ipotesi. A trasformarle in risultati è la possibilità di agire su un bersaglio in esecuzione all'interno dello stesso ciclo di lavoro.
A quel punto l'agente non si ferma alla constatazione che qualcosa sembra sfruttabile: invia la richiesta, legge la risposta reale, corregge i propri presupposti, scarta le strade che l'applicazione esclude e costruisce progressivamente una rappresentazione dell'ambiente. Lettura e sperimentazione si sostengono a vicenda: il codice suggerisce dove guardare, il sistema conferma o smentisce quella lettura.
Avevamo già osservato questo meccanismo in un caso isolato, quando l'agente aveva concatenato due CVE fino a root su HTB Snapped. Dopo tredici macchine, quel meccanismo assomiglia molto meno a una circostanza fortunata e molto di più alla caratteristica che definisce l'approccio agentico alla sicurezza offensiva.
La difficoltà sta nell'incertezza, non nella conoscenza
I modelli attuali ragionano bene quando hanno davanti informazioni sufficienti. Le cose si complicano in condizioni black box, dove le informazioni di partenza sono poche e il sistema deve capire che cosa ha davanti prima ancora di poterci ragionare sopra.
È esattamente qui che l'architettura fa la differenza. Un agente progettato per esplorare in modo metodico, raccogliere evidenze, formulare ipotesi, verificarle e rivedere il piano compensa limiti che si notano chiaramente osservando un modello linguistico da solo. L'esito non dipende dal fatto che il modello sottostante sia proprietario o open weight. La capacità complessiva è una proprietà del sistema agentico, non del modello.
Dove siamo dovuti intervenire
La stagione ha confermato anche un limite che merita di essere descritto con precisione.
I problemi veri si sono concentrati sulle macchine classificate Insane, dove la distanza tra avere gli strumenti giusti e capire quale strada percorrere è più ampia. In quei casi l'intervento umano è stato talvolta necessario, ma la forma di quell'intervento è la parte interessante: non abbiamo mai fornito la soluzione. Abbiamo detto all'agente di continuare, indicandogli direzioni che non aveva ancora esplorato.
"Hai considerato questa possibilità?" "Può esserci un'altra superficie di attacco?" "Verifica questa ipotesi." Analisi, validazione ed esecuzione sono rimaste sempre in carico all'agente.
Questa distinzione cambia completamente la natura del coinvolgimento umano. Quello che l'operatore ha messo sul tavolo non era conoscenza tecnica, ma insistenza e orientamento: il giudizio che una strada non fosse ancora esaurita e un'idea di dove puntare. Conviene notare che si tratta di uno dei contributi meno costosi per una persona e tra i più difficili da automatizzare, il che descrive abbastanza bene quello che dovrebbe essere il ruolo della supervisione.
Cosa può dire una stagione, e cosa no
Le macchine dei CTF restano ambienti artificiali. Sono costruite per essere risolte, quindi una strada esiste sempre: su una rete reale questa garanzia non c'è. Qualsiasi lettura onesta di questi risultati deve partire da qui.
Detto questo, le macchine migliori somigliano ormai sempre di più a sistemi reali: software aggiornato, configurazioni imperfette, componenti interni non esposti direttamente, relazioni di fiducia tra identità, servizi cloud, codice sviluppato su misura e vulnerabilità che contano solo se concatenate. La distanza tra "progettato per essere risolto" e "risulta sfruttabile" si è ridotta parecchio.
Una stagione, quindi, non è un benchmark di un modello. È un indicatore della velocità con cui stanno evolvendo gli agenti autonomi, misurata su un'intera stagione invece che su un singolo caso favorevole.
È cambiata la domanda
Non ci chiediamo più se un modello linguistico riconosca una vulnerabilità o suggerisca il comando giusto: quella domanda ha ormai una risposta. Oggi ci chiediamo se un agente sia in grado di osservare un ambiente, formulare un'ipotesi, agire di conseguenza, imparare da ciò che fallisce e percorrere fino in fondo una catena di attacco.
Per tredici macchine di fila il nostro agente lo ha fatto. Sulle più difficili ha avuto bisogno di una persona, non per farsi dare la risposta, ma per sentirsi dire di continuare a cercare.
È in quello spazio, tra automazione e autonomia, tra il modello e il sistema che gli viene costruito attorno, che si deciderà buona parte del lavoro di sicurezza dei prossimi anni.
Se vuoi vedere come si comporta un sistema del genere sulla tua infrastruttura, e non su una macchina di un CTF, scrivici.