Webshell PHP con cookie su Linux: elusione

Introduzione

Microsoft ha pubblicato una nuova ricerca su una tecnica stealth di webshell PHP che colpisce gli ambienti di hosting Linux. Invece di usare parametri URL evidenti o corpi delle richieste, gli attaccanti utilizzano cookie HTTP come canale di attivazione e controllo per l'esecuzione malevola, rendendo queste webshell più difficili da individuare nel normale traffico web e nei log delle applicazioni.

Per i team di sicurezza e gli amministratori che gestiscono web app ospitate su Linux, questo è importante perché la tecnica consente persistenza a basso rumore, attivazione ritardata e un accesso post-compromissione più evasivo.

Cosa c'è di nuovo

Microsoft ha osservato più varianti di webshell PHP che si basano tutte su un'esecuzione vincolata dai cookie:

• Attivazione controllata da cookie: La webshell resta inattiva a meno che l'attaccante non invii specifici valori dei cookie.
• Offuscamento a livelli: Alcune varianti ricostruiscono dinamicamente funzioni PHP e logica di esecuzione in fase di runtime per evitare il rilevamento statico.
• Staging del payload: Diversi campioni ricostruiscono e scrivono payload secondari su disco solo quando vengono soddisfatte le condizioni dei cookie richieste.
• Comportamento interattivo della webshell: Le versioni più semplici usano un singolo cookie come chiave per abilitare l'esecuzione di comandi o il caricamento di file.
• Persistenza basata su cron: In un caso analizzato, gli attaccanti hanno usato flussi di lavoro legittimi del pannello di controllo dell'hosting per registrare attività pianificate che ricreavano il loader PHP malevolo se veniva rimosso.

Perché è più difficile da rilevare

I cookie spesso ricevono meno attenzione rispetto ai percorsi delle richieste, alle query string o ai corpi POST. In PHP, i valori dei cookie sono direttamente accessibili tramite $_COOKIE, il che li rende un canale di input pratico per gli attaccanti. In combinazione con l'offuscamento e la distribuzione graduale dei payload, questo consente ai file malevoli di apparire inerti durante il traffico normale e di attivarsi solo durante interazioni deliberate da parte dell'attaccante.

Impatto su amministratori e difensori

Per gli amministratori IT e della sicurezza, il rischio principale è l'esecuzione persistente di codice remoto all'interno di un account di hosting compromesso, anche senza accesso a livello root. In ambienti di hosting condiviso o shell con restrizioni, gli attaccanti possono comunque avere permessi sufficienti per:

• Modificare contenuti web
• Distribuire loader PHP
• Ricreare malware eliminato tramite cron job
• Mantenere accesso a lungo termine con un'impronta minima nei log

Questo può complicare la remediation, soprattutto quando un'attività pianificata di tipo “self-healing” ripristina la webshell dopo la pulizia.

Passaggi successivi consigliati

Gli amministratori dovrebbero esaminare le indicazioni di Microsoft e dare priorità a queste azioni:

• Eseguire un audit delle applicazioni PHP e delle web root alla ricerca di script offuscati sospetti
• Esaminare attività pianificate e cron job per individuare meccanismi di persistenza non autorizzati
• Monitorare pattern dei cookie associati a insolite esecuzioni lato server
• Abilitare e analizzare i rilevamenti e la threat analytics di Microsoft Defender XDR
• Cercare file PHP accessibili dal web che scrivono o includono payload secondari
• Rafforzare il monitoraggio dell'integrità dei file e i permessi negli ambienti di hosting Linux

Le organizzazioni che eseguono carichi di lavoro PHP esposti a Internet dovrebbero anche assicurarsi che i playbook di incident response includano controlli sulla persistenza tramite cron, attività di hunting per webshell basate su cookie e validazione successiva dopo la pulizia.