Questa richiesta prova a contattare qualcosa che si trova all'URL /shell e che accetta come parametro un insieme di comandi di shell da eseguire.
Sebbene i comandi della shell da eseguire possano sembrare inizialmente offuscati, la maggior parte delle possibilità è che in realtà non lo sono. I comandi di shell possono spesso contenere caratteri che hanno un significato speciale negli URL HTTP, quindi per evitare che i comandi vengano corrotti dal client o dal server HTTP, la soluzione più semplice è semplicemente codificarla completamente in HTTP (questo è meno una questione di offuscamento che In effetti, molto probabilmente l'autore dell'attacco non si preoccupa della leggibilità dell'URL.
Riguardo questo /shell URL che (fortunatamente!) non è stato trovato sul tuo server, ci sono due possibilità principali:
- Questo potrebbe essere il nome di una risorsa specifica per il servizio designato dall'attaccante. Il nome del file che questo comando tenta di scaricare sembra indicare che si aspetta un dispositivo ARM, quindi l'utente malintenzionato potrebbe essere un bot che esegue la scansione di Internet per uno specifico dispositivo vulnerabile incorporato dove questo
/shell URL è presente e abilitato per impostazione predefinita ( ad esempio una funzione di debug lasciata abilitata da un produttore. Succedono cose brutte ...).
- Un'altra possibilità è che questa richiesta non sia il primo passo dell'attacco. L'autore dell'attacco potrebbe aver già adottato uno o più passaggi prima di questo, che, di fronte a un server vulnerabile, avrebbe portato alla creazione di questo
/shell di script sul lato server. Questi passaggi precedenti avrebbero potuto essere davvero qualsiasi cosa che avrebbe costretto il server o il servizio che esegue in qualche modo a generare questo file /shell o ad accettarlo per caricarlo.
Nei tuoi commenti, riguardo alla seconda opzione, ti sembra che ti chiedi perché agire in due (o più) passi. Quando un attaccante ottiene il suo primo piede su un bersaglio, molto spesso deve affrontare varie limitazioni in termini di dimensioni e contenuto del carico utile che può eseguire (ad esempio può essere in grado di caricare / creare solo file ASCII, o il contenuto deve essere più corto di 100 caratteri, ecc.).
Pertanto, al fine di compromettere completamente una macchina, per prima cosa eliminerà un payload di prima fase che sarà il minimo indispensabile che gli consentirà di scaricare un carico utile binario completo come seconda fase. Il modo classico è di creare uno script sul lato server che eseguirà qualsiasi comando di shell passato come parametro (un classico web shell ). L'accesso a tale shell Web produrrebbe esattamente lo stesso tipo di registro rispetto a quello riportato nella domanda.
E infine, per quanto riguarda il motivo per cui procedere con i seguenti passaggi se il precedente apparentemente non ha funzionato, ancora due possibilità:
- A seconda dei dettagli dell'exploit, accade che l'attaccante non abbia feedback definitivi durante i primi passi che gli consentono di definire chiaramente se il server è vulnerabile o meno. Lo saprà se l'attacco ha avuto successo e contattare l'URL '/ shell' non genera un messaggio di errore 404 ma correttamente scarica ed esegue il payload della seconda fase.
- Alcuni robot che analizzano Internet sono sviluppati in modo rapido e sporco e eseguono tutti i passaggi di un dato attacco su tutti i server trovati in un intervallo IP, ignorando la risposta del server. Le macchine vulnerabili eseguendo il payload della seconda fase richiamano l'autore dell'attacco da soli.