Dopo aver esplorato come una Certificate Authority mal configurata può trasformarsi in una leva per scalare privilegi fino al dominio, è importante ricordare che non è l’unico componente critico di Active Directory. Anche strumenti come SCCM (System Center Configuration Manager), utilizzati quotidianamente per distribuire software e configurazioni, possono diventare una porta d’ingresso per gli attaccanti se non configurati correttamente. In questo articolo vedremo come SCCM può essere sfruttato e quali rischi comporta.
SCCM ulteriore leva di escalation
Configuration Manager (SCCM), ora noto come Microsoft Configuration Manager (ConfigMgr), è una piattaforma di gestione dei sistemi utilizzata per distribuire software, gestire gli aggiornamenti e applicare le impostazioni di configurazione su un gran numero di dispositivi Windows. Proprio per questo, se mal configurato, può diventare un veicolo ideale per muoversi tra i livelli (tier) di un’organizzazione e raggiungere il dominio. Spesso riscontriamo che negli ambienti con un modello a livelli, in cui viene utilizzato SCCM, sono presenti numerose configurazioni errate che possono essere sfruttate.
Network Access Account (NAA)
SCCM spesso usa un Network Access Account (NAA) per accedere alle risorse di rete (denominati distribution points). Il problema è che le credenziali NAA sono memorizzate localmente su ciascun endpoint gestito (protette con DPAPI) e, se estratte, possono consentire l’accesso a risorse critiche. Tool come SharpSCCM o sccmsecrets.py permettono di estrarre queste credenziali dagli endpoint o di registrare un nuovo device per recuperarle, anche sfruttando la possibilità che un utente normale possa creare account macchina (Machine Account Quota). L’esposizione del NAA può portare a privilege escalation diretta (es. modifiche a gruppi, accesso al DB di SCCM) e, in casi estremi, alla promozione ad amministratore SCCM cambiando record direttamente nel database.
Client Push Credentials
Un’altra configurazione delicata è la funzione di Client Push Installation, che consente al server SCCM di installare automaticamente l’agente di gestione sui computer del dominio. Per farlo, SCCM utilizza un account dedicato con privilegi amministrativi sui sistemi di destinazione, in modo da potersi collegare in remoto, copiare file ed eseguire comandi. Il rischio nasce quando queste credenziali vengono archiviate nel server SCCM (nel database o nel registro di sistema) e riutilizzate su più dispositivi o livelli di rete. Un attaccante che compromettesse un server o un ruolo SCCM secondario potrebbe estrarre queste credenziali e usarle per accedere ai computer gestiti, ottenendo privilegi amministrativi locali o, in certi casi, anche di dominio.
In pratica, il meccanismo pensato per semplificare la gestione dei client potrebbe trasformarsi in un mezzo di propagazione dell’attacco, consentendo a un intruso di spostarsi rapidamente tra decine di macchine sfruttando un’unica coppia di credenziali.
Application & Script Looting
Durante i deployment o nelle task sequence, è comune usare script, file di configurazione o pacchetti che possono, accidentalmente, contenere credenziali in chiaro (password, token) o riferimenti a risorse sensibili. Un attaccante che ha accesso a pacchetti SCCM o file nelle condivisioni può recuperare queste informazioni e usarle per scalare privilegi. Gli attaccanti possono enumerare il contenuto dei pacchetti direttamente dai distribution point o analizzare le cache locali dei client per individuare script contenenti credenziali di servizio o amministrative.
Questa tecnica è una forma diffusa di credential harvesting e spesso è banale da risolvere con pratiche operative più attente.
Authentication Coercion
Un’ulteriore tecnica di escalation, spesso sottovalutata, è l’Authentication Coercion, ossia la forzatura di un sistema o servizio ad autenticarsi verso un host controllato dall’attaccante. Nel contesto SCCM, questo può avvenire sfruttando la fiducia e l’interazione continua tra server, management point e client. Un attaccante che ha accesso limitato all’ambiente può indurre un server SCCM o un client gestito a inviare un’autenticazione NTLM verso di sé (tramite vulnerabilità note come PetitPotam o PrinterBug), per poi rilanciare tale autenticazione (NTLM relay) verso un altro sistema più privilegiato. Il risultato è la possibilità di ottenere accesso come account di sistema o amministratore, senza conoscere le credenziali reali.
In pratica, l’attaccante sfrutta la fiducia che SCCM ha costruito per gestire l’ambiente e la trasforma in un canale per salire di livello all’interno del dominio.
Conclusioni
SCCM è uno dei “vicini” più potenti di Active Directory: gestisce centinaia di endpoint e garantisce la distribuzione di software e aggiornamenti, ma proprio questo ruolo lo rende anche un potenziale strumento di attacco se trascurato. Una configurazione errata può consentire a un attaccante di distribuire codice malevolo, rubare credenziali o sfruttare le autenticazioni interne per ottenere privilegi elevati.
Proteggere SCCM significa proteggere l’intera infrastruttura: isolare gli account, mantenere puliti i pacchetti di deployment e monitorare costantemente le sue attività sono passaggi fondamentali per preservare la fiducia nel dominio.
Scopri di più su come il team Kokishin può supportare la tua azienda nel rafforzare la sicurezza di Active Directory e dei suoi “vicini” più critici.
