Guarda una demo×
×

Guarda NinjaOne in azione!

Inviando questo modulo, accetto La politica sulla privacy di NinjaOne.

Guida alla riduzione delle vulnerabilità 0-Day di Microsoft Exchange

Banner di avviso di sicurezza MSP

Aggiornato al 16 marzo 2021. 

Martedì 2 marzo, Microsoft ha annunciato di aver individuato una serie di quattro exploit 0-day utilizzati attivamente per attaccare versioni di Exchange Server in sede. Le patch sono disponibili e si consiglia alle organizzazioni di identificare, aggiornare e verificare i sistemi vulnerabili il più rapidamente possibile.

Abbiamo creato questo post per raccogliere risorse e informazioni correlate e lo aggiorneremo regolarmente.

Contenuti

 

Panoramiche

I seguenti sono ottimi riassunti e thread da seguire per aggiornarsi:

 

Informazioni sulle minacce da parte delle aziende di sicurezza

Huntress
Sfruttamento di massa dei server Exchange in loco (thread su r/msp)

Un thread di risposta rapida da parte di Huntress orientato specificamente agli MSP, che include informazioni sulle minacce e risultati dell’esame della loro base di partner. Huntress si aggiorna attivamente non appena sono disponibili nuove informazioni.

Huntress ha anche organizzato un webinar il 4 marzo alle 13:00 ET e ha fornito una sintesi della ricerca e delle osservazioni fatte finora. Guardalo su richiesta qui.

Volexity
Operation Exchange Marauder: Sfruttamento attivo di molteplici vulnerabilità Zero-Day di Microsoft Exchange

Uno dei primi a identificare (il 6 gennaio!) e a segnalare questa attività. Questo post fornisce maggiori dettagli sul modo in cui le vulnerabilità vengono effettivamente sfruttate, nonché un breve elenco di tattiche, tecniche e procedure (TTP) osservate dopo lo sfruttamento. Fornisce inoltre ulteriori IoC.

FireEye
Rilevamento e risposta allo sfruttamento delle vulnerabilità Zero-Day di Microsoft Exchange

Conferma anche l’osservazione dell’abuso di gennaio e contiene un’altra ottima analisi tecnica degli attacchi. Contiene ulteriori suggerimenti per indagare su potenziali compromissioni (vedi sotto).

Red Canary
Sfruttamento del server Microsoft Exchange: Come individuare, ridurre le vulnerabilità e mantenere la calma

Fornisce una ripartizione delle attività di minaccia post-sfruttamento che Red Canary ha identificato, insieme a opportunità pratiche di rilevamento e consigli di rimedio.

CrowdStrike
Falcon Complete blocca gli exploit Zero-Day di Microsoft Exchange Server

Se riuscite a superare il titolo e l’aspetto commerciale, questo post fornisce ulteriori dettagli tecnici, IoC e un utile riepilogo sulla scoperta e la caccia alle minacce.

 

Quali sono le vulnerabilità?

Microsoft ha identificato quattro vulnerabilità che vengono sfruttate attivamente, ma l’aggiornamento di sicurezza out-of-band dell’azienda affronta anche tre ulteriori vulnerabilità di esecuzione di codice remoto (remote code execution o RCE) che non sono state associate agli attacchi attivi.

Accesso iniziale

CVE-2021-26855 

CVSSv3: 9.1

Una vulnerabilità SSRF (server-side request forgery) in Exchange che consente agli aggressori remoti di inviare richieste HTTP arbitrarie e di autenticarsi come server Exchange.

Secondo la società di sicurezza Volexity:

Questa vulnerabilità è sfruttabile da remoto e non richiede alcun tipo di autenticazione né conoscenze particolari o accesso all’ambiente di destinazione. L’utente malintenzionato deve solo conoscere il server che esegue Exchange e l’account da cui vuole estrarre la posta elettronica.

Se riesce a sfruttare questa vulnerabilità, un utente malintenzionato ha la possibilità di sfruttare le tre vulnerabilità aggiuntive riportate di seguito.

Esecuzione di codice remoto post-autenticazione (RCE)

CVE-2021-26857

CVSSv3: 7.8

Secondo Tenable, il difetto risiede nel Exchange Unified Messaging Service, che abilita la funzionalità di posta vocale oltre ad altre caratteristiche. Permette di eseguire codice come SISTEMA sul server Exchange, ma richiede l’autorizzazione dell’amministratore o un’altra vulnerabilità da sfruttare.

CVE-2021-26858

CVSSv3: 7.8

Se gli aggressori sono in grado di autenticarsi con il server Exchange (sfruttando la CVE-2021-26855 o compromettendo le credenziali di un amministratore legittimo), possono utilizzare questa vulnerabilità per scrivere un file in qualsiasi percorso del server.

CVE-2021-27065

CVSSv3: 7.8

Idem.

 

Note sull’attività post-sfruttamento

Come hanno riportato FireEye, Volexity e altri, gli aggressori hanno abusato di queste vulnerabilità per rilasciare web shell, tra cui varianti di China Chopper. Questi danno agli aggressori la possibilità di preparare la scena ed eseguire una serie di attività di post-exploitation.

I TTP osservati includono:

  • Furto di credenziali utilizzando ProcDump (strumento legittimo di Windows Sysinternals) per eseguire il dump della memoria del processo LSASS
  • Esfiltrazione di dati, incluse le rubriche offline di Exchange
  • Esportazione dei dati della cassetta postale tramite gli snap-in di Exchange PowerShell
  • Stabilire l’accesso remoto tramite PowerCat e altri framework di attacco

Per maggiori informazioni sull’attività di minaccia post-sfruttamento, vedere la ricerca di Red Canary.

 

“Bonus” vulnerabilità non correlate

Oltre a queste vulnerabilità zero-day, Microsoft ha anche patchato le seguenti falle RCE non correlate:

  • CVE-2021-26412 (CVSSv3: 9.1)
  • CVE-2021-26854 (CVSSv3: 6.6)
  • CVE-2021-27078 (CVSSv3: 9.1)

 

Quali versioni di Exchange sono interessate?

Come ha detto sinteticamente Huntress durante il webinar, tutte quante.

quali versioni di Exchange sono vulnerabili

  • Exchange Server 2010
  • Exchange Server 2013
  • Exchange Server 2016
  • Exchange Server 2019

Nota: Microsoft ha confermato che Exchange Online NON è interessato.

Quanto sono diffusi gli attacchi?

Nonostante Microsoft abbia inizialmente descritto gli attacchi come “limitati e mirati”, i risultati successivi di altri fornitori e ricercatori indicano che l’attività è stata molto più diffusa e indiscriminata.

Aggiornamento: Si stima che almeno 30.000 organizzazioni statunitensi siano state compromesse

Venerdì 5 marzo Brian Krebs ha riferito che diverse fonti hanno stimato che centinaia di migliaia di organizzazioni sono state compromesse in tutto il mondo, con 30.000 solo negli Stati Uniti.

Andy Greenberg, giornalista di Wired, ha poi confermato:

L’U.S. Computer Emergency Readiness Team (US-CERT) ha definito lo sfruttamento diffuso e ha sottolineato che tutte le organizzazioni di tutti i settori dovrebbero seguire le linee guida per la riduzione delle vulnerabilità.

 

Le organizzazioni compromesse includono amministrazioni locali, un’ampia varietà di PMI.

Secondo John Hammond, ricercatore senior di Huntress, le vittime compromesse identificate includono piccoli hotel, un’azienda produttrice di gelati, un’azienda produttrice di elettrodomestici da cucina, diverse comunità di anziani e altre aziende “poco sexy” del mercato medio. Huntress ha fatto notare che anche molte vittime erano enti di città e contee, fornitori di servizi sanitari, banche/istituzioni finanziarie e diversi fornitori di elettricità per uso residenziale.

Su circa 2.000 server Exchange analizzati, quasi 200 erano stati compromessi con la presenza di payload web shell.

Molteplici gruppi di attori minacciosi stanno attivamente abusando delle vulnerabilità.

Mentre Microsoft ha attribuito la campagna osservata con grande sicurezza al creatore delle minacce con sede in Cina, HAFNIUM, ESET ha riferito di aver visto altri gruppi entrare nel mix.

 

 

Aggiornamento: ESET ha pubblicato una nuova ricerca che indica che almeno 10 gruppi APT stanno sfruttando attivamente le vulnerabilità.

I primi attacchi sono stati identificati il 6 gennaio 2021.

Brian Krebs ha messo insieme una cronologia di alto livello che indica che Microsoft è stata informata di una delle vulnerabilità il 5 gennaio. Un giorno dopo, l’azienda di sicurezza Volexity ha identificato gli attacchi in-the-wild ovvero che si diffondono tra i computer del mondo reale..

  • 5 gennaio: DEVCOR avvisa Microsoft delle sue scoperte.
  • 6 gennaio: Volexity individua attacchi che utilizzano vulnerabilità sconosciute in Exchange.
  • 8 gennaio: DEVCOR riferisce che Microsoft ha riprodotto i problemi e verificato i risultati.
  • 11 gennaio: DEVCOR si accaparra proxylogon.com, un dominio ora utilizzato per spiegare il suo processo di scoperta delle vulnerabilità.
  • 27 gennaio: Dubex avvisa Microsoft di attacchi su una nuova falla di Exchange.
  • 29 gennaio: Trend Micro pubblica un post sul blog in merito alla caduta di web shell “Chopper” tramite falle di Exchange.
  • 2 febbraio: Volexity avverte Microsoft di attacchi attivi su vulnerabilità di Exchange precedentemente sconosciute.
  • 8 febbraio: Microsoft comunica a Dubex di aver “intensificato” il rapporto internamente.
  • 18 febbraio: Microsoft conferma con DEVCOR la data prevista del 9 marzo (domani) per la pubblicazione degli aggiornamenti di sicurezza per le falle di Exchange. Questo è il secondo martedì del mese, ovvero “Patch Tuesday“, quando Microsoft rilascia gli aggiornamenti di sicurezza mensili (e sì, questo significa che domani tornate qui per la sempre avvincente carrellata di Patch Tuesday).
  • 26-27 febbraio: lo sfruttamento mirato si trasforma gradualmente in una scansione globale di massa; gli aggressori iniziano rapidamente a fare il backdooring dei server vulnerabili.
  • 2 marzo: una settimana prima del previsto, Microsoft rilascia aggiornamenti per eliminare 4 falle zero-day.
  • 3 marzo: decine di migliaia di server Exchange compromessi in tutto il mondo, con migliaia di server violati ogni ora.
  • 5 marzo: KrebsOnSecurity svela la notizia che almeno 30.000 organizzazioni negli Stati Uniti – e centinaia di migliaia in tutto il mondo – hanno ora installato delle backdoor.
  • 5 marzo: Wired.com conferma il numero di vittime riportato. La Casa Bianca esprime preoccupazione per le dimensioni dell’attacco. L’ex capo del CISA Chris Krebs tweeta che il numero delle vittime reali oscura quello che è stato riportato pubblicamente.
  • 6 marzo: CISA dice di essere a conoscenza di un “diffuso sfruttamento nazionale e internazionale delle falle di Microsoft Exchange Server”.
  • 7 marzo ad oggi: gli esperti di sicurezza continuano a informare le vittime, a coordinare i rimedi e a rimanere vigili sulla “Fase 2” di questo attacco (ulteriore sfruttamento dei server già compromessi).

Timeline creata da Brian Krebs

 

Aggiornamento: Nuove ricerche indicano che lo sfruttamento potrebbe estendersi fino al novembre 2020.

aggiornamento della tempistica di sfruttamento dello scambio

Fonte: Esaminare lo sfruttamento degli scambi e le sue lezioni per i difensori di Joe Slowik

 

Come fare le patch

Opzioni di aggiornamento di Microsoft Exchange

Grafico di Microsoft che illustra i tre percorsi per l’applicazione degli aggiornamenti di Exchange

 

Gli aggiornamenti di sicurezza che risolvono queste vulnerabilità sono disponibili per le seguenti versioni specifiche di Exchange:

Nota: Se si installano manualmente, è necessario farlo come amministratore. Altrimenti, c’è un problema noto. Come sottolinea Kevin Beaumont, ricercatore di sicurezza Microsoft, c’è stata un po’ di confusione sulla necessità di avere i server con uno degli ultimi due aggiornamenti cumulativi (CU).

Microsoft fornisce maggiori chiarimenti qui:

Queste correzioni possono essere installate solo sui server che eseguono le versioni specifiche elencate in precedenza, considerate aggiornate. Se i server stanno eseguendo un aggiornamento cumulativo o un rollup di Exchange Server meno recente, è necessario installare una RU/CU attualmente supportata prima di poter installare gli aggiornamenti di sicurezza.

Hai bisogno di aiuto per trovare la CU giusta da installare?

Michel de Rooij è un eroe e ha collegamenti per il download degli aggiornamenti cumulativi elencati per versioni di Exchange che includono anche i numeri di build e le date di rilascio.

Aggiornamento: Con una CU non supportata e non è possibile ottenere gli ultimi aggiornamenti?

Microsoft ha iniziato a fornire aggiornamenti di sicurezza (SU) che possono essere applicati ad alcune vecchie CU non supportate. Questi aggiornamenti contengono solo correzioni per le CVE 0-day e sono disponibili solo attraverso il Microsoft Download Center (non Microsoft Update). Ulteriori dettagli e istruzioni per l’installazione sono disponibili qui.

Nota: Microsoft sottolinea che queste SU sono “intese solo come misura temporanea per aiutare l’utente a proteggere i computer vulnerabili in questo momento”. È comunque necessario fare l’aggiornamento all’ultima CU supportata e quindi applicare le SU applicabili”.

** Se non è possibile applicare immediatamente la patch, è una soluzione temporanea **

Per le organizzazioni che non sono in grado di applicare la patch, Microsoft ha fornito la seguente raccomandazione come soluzione provvisoria:

Implementare una regola di riscrittura di IIS e disabilitare i servizi Unified Messaging (UM), Exchange Control Panel (ECP) VDir e Offline Address Book (OAB) VDir

  • Queste riduzioni hanno un impatto noto sulle funzionalità descritte di seguito in dettaglio.
  • Queste riduzioni sono efficaci contro gli attacchi che abbiamo visto finora in-the-wild, ma non sono garantite come riduzioni complete per tutti i possibili sfruttamenti di queste vulnerabilità.
  • Non eviterà un utente malintenzionato che ha già compromesso un server.
  • Dovrebbe essere usato solo come soluzione temporanea fino a quando i server di Exchange non saranno completamente dotati di patch.

Dettagli e script PowerShell forniti da Microsoft qui.

** Nota: Né le patch né queste riduzioni sono in grado di risolvere i problemi di compromissione **

Come sottolinea Microsoft, non si tratta di un rimedio se i server Exchange sono già stati compromessi. Per un aiuto nel determinare questo aspetto, vedere di seguito.

** Aggiornamento: Microsoft rilascia uno “strumento di riduzione in un clic” progettato per le organizzazioni che non dispongono di team interni di IT o di sicurezza **

I dettagli dello strumento sono disponibili tramite Microsoft qui.

Identificazione dei server vulnerabili

A causa del volume di scansioni e sfruttamenti attivi, unitamente ai rischi connessi, Huntress e altri fornitori di sicurezza consigliano di fidarsi ma verificare. Le patch devono essere convalidate e gli MSP devono scansionare attivamente le reti dei loro clienti per assicurarsi che non ci sia un server dimenticato a sorpresa. Ne basta uno.

Kevin Beaumont ha sviluppato un semplice script Nmap che potete utilizzare qui.

 

 

Nota: Se si è utilizzato lo script precedente per eseguire la scansione di ambienti con Exchange 2013 prima del 7 marzo, è necessario eseguire nuovamente la scansione. 

I ricercatori di Rapid7 hanno identificato una falla nello script che causava la segnalazione di falsi negativi per i server Exchange 2013, in particolare.

Lo script è stato aggiornato e il problema è stato risolto.

Se siete clienti paganti di Shodan Monitor, potete anche ricevere automaticamente una notifica se viene rilevato un server vulnerabile.

 

Identificazione e investigazione delle compromissioni

Aggiornamento: Microsoft ha aggiornato il suo Microsoft Support Emergency Response Tool (MSERT) per rilevare e rimuovere il malware associato alla compromissione.

Si tratta di un’ottima notizia, in quanto fornisce protezione alle organizzazioni con server che non hanno installato Defender for Endpoint.

Microsoft ha inoltre delineato una serie di opportunità di rilevamento e ha creato uno script che può essere utilizzato per scansionare i file di registro di Exchange alla loro ricerca.

Qui si possono trovare anche gli elenchi di IoC:

Oltre a fornire IoC, FireEye raccomanda anche di controllare i seguenti elementi per individuare potenziali prove di compromissione:

  • Processi figli di C:WindowsSystem32inetsrvw3wp.exe sui server Exchange, in particolare cmd.exe.
  • File scritti nel sistema da w3wp.exe o UMWorkerProcess.exe.
  • File ASPX di proprietà dell’utente SYSTEM .
  • Nuovi file ASPX compilati in modo imprevisto nella directory Temporary ASP.NET Files .
  • Richieste di ricognizione e test di vulnerabilità alle seguenti risorse da un indirizzo IP esterno:
    • /rpc/ directory
    • /ecp/DDI/DDIService.svc/SetObject
    • Risorse inesistenti
    • Con gli agenti utenti HTTP sospetti o soggetti a spoofing
  • Richieste inattese o sospette di Exchange PowerShell SnapIn per l’esportazione di caselle di posta elettronica

** Se si sospetta che un server sia stato compromesso **

  • Iniziate il vostro piano di risposta agli incidenti / contattate un fornitore di servizi di risposta agli incidenti (non esitate a chiedere l’aiuto di esperti se non avete esperienza di IR al vostro interno).
  • Isolare il server
  • FireEye consiglia di conservare i seguenti documenti per l’analisi forense
    • Almeno 14 giorni di log web HTTP dalle directory inetpubLogsLogFiles (includere i log da tutte le sottodirectory)
    • Il contenuto del server web di Exchange (che si trova anche nella cartella inetpub )
    • Almeno 14 giorni di registri del Pannello di controllo di Exchange (ECP), che si trovano in Program FilesMicrosoftExchange Serverv15LoggingECPServer
    • Registri eventi di Microsoft Windows
  • Ripristinare Exchange a prima del primo incidente noto (le notizie attuali indicano il 5 gennaio)
  • Patch o applicazione di riduzione di emergenza
  • Eseguire un audit completo per verificare quanto segue:
    • Nuovi utenti e utenti privilegiati (utilizzare RMM e PowerShell)
    • Date di modifica della password
    • Inoltro per le caselle postali
    • Inoltro/reindirizzamento delle cartelle della posta in arrivo
  • Modifica delle password di dominio
  • Rimanete vigili e aggiornati sulle nuove informazioni relative alle minacce.

 

Video: Aggiornatevi velocemente con John Hammond di Huntress

Ho avuto l’opportunità di parlare con John della ricerca del suo team, di sentire cosa lo ha sorpreso e di ricevere le sue raccomandazioni su come gli MSP dovrebbero rispondere.

Trascrizione

Jonathan: Ciao a tutti. Con me c’è John Hammond di Huntress. E naturalmente l’argomento di cui stiamo parlando è Microsoft Exchange e le vulnerabilità zero day che vengono attivamente sfruttate. È stata una settimana folle. John, a questo punto sei pieno di adrenalina e ti esce il fumo dalle orecchie. Sono giorni che non dormite. Hai aperto un thread su Reddit e hai continuato a occupartene fin dall’inizio, aggiornandolo costantemente con le tue scoperte. Come va? Come fai a resistere?

John: Grazie Jonathan. Me la cavo bene. Siamo un po’ in affanno. Prima stavo scherzando con te. Ho la mia bevanda energetica. Mi tengo aggiornato. Ma ci stiamo dando da fare. Stiamo cercando di aggiornare gli indicatori di compromesso. Stiamo cercando di produrre un webinar che andremo a trasmettere in diretta questo pomeriggio alle 13:00 ET. Stiamo quindi cercando di educare la comunità e di diffondere la consapevolezza.

Jonathan: Sì. Assolutamente. Inserirò un link a quella discussione su Reddit perché avete fatto un lavoro straordinario, includendo ciò che avete detto sugli IOC e anche aggiornamenti su ciò che avete trovato da voi.Fate davvero le ore piccole, avete chiamato i partner alle 2 di notte per aiutarli a capire questo problema e ci sono state molte domande e a questo punto credo che si possa dire che molte persone hanno fatto i primi passi. Esistono alcuni strumenti condivisi per la scansione dei server vulnerabili. Ci sono patch da parte di Microsoft, ma ci sono state molte domande. Ok, se ho trovato gli IOC cosa devo fare ora? Hai qualche suggerimento su ciò che ha visto prima di tutti con questi IOC e poi sulle azioni di riduzione delle vulnerabilità?

John: Sì. La cosa più ovvia è la patch. Una volta fatto questo, il passo successivo è la convalida della patch. Kevin Beaumont ha messo a punto un ottimo motore di scripting Nmap, un’utilità che si può utilizzare con Nmap per convalidare esternamente e assicurarsi di non essere più vulnerabili e quindi eseguire la tipica risposta di ripristino necessaria. Ripristinare il server di Exchange, se possibile, prima del primo incidente noto. Rivedere il proprio dominio. Utenti e computer, verificare che non vi siano cambiamenti o modifiche, nuovi amministratori nei gruppi di Exchange. Questo è fondamentale. E cambiare tutte le password dei domini. Lo diciamo sempre, ma è necessario farlo. Ripetere l’operazione, eliminare i problemi e monitorare gli IOC, rimanendo aggiornati sulle informazioni relative alle minacce. E se capita di vedere qualcosa di nuovo, se vi capita di vedere, oh, ho una webshell diversa che usa un argomento diverso in cui viene comunicato un indirizzo IP diverso. Sì, ci rendiamo conto che è una cosa brutta, ma vi preghiamo di dirlo alla comunità. Ditelo al resto di noi, così potremo continuare la caccia, perché è questo il nostro scopo.

Jonathan: Avete dato un grande contributo alla comunità, prendendo l’iniziativa e condividendo molte di queste informazioni. C’è qualcosa di nuovo a questo proposito che state vedendo in termini di IOC o di nuove attività ora che il gatto è uscito dal sacco?

John: Assolutamente. Quindi abbiamo lottato il più possibile contro questa situazione. Quando condividiamo queste informazioni è bello e meraviglioso vedere che altri hanno fiducia in Huntress. Quindi ora vediamo nuovi partner e nuovi individui conoscere il nostro dashboard. Il nostro inventario di server Exchange sta aumentando, quindi negli ultimi giorni abbiamo assistito all’aggiunta di un migliaio di nuovi server Exchange, il che porta il nostro numero a circa 3.000, quindi anche il numero di compromessi aumenta. Ora siamo arrivati a circa 300 e stiamo tenendo sotto controllo le versioni in circolazione. SU quanti è stata applicata la patch? Penso circa 900 su 3.000, ma è incredibile vedere le statistiche. È incredibile vedere i dati, ma dimostra che questa minaccia è ancora presente. Gli host infetti continuano a essere infettati. Gli utenti malintenzionati stanno scandagliando Internet e l’attacco non si è ancora concluso.

John: A questo punto, tornando rapidamente all’annuncio di Microsoft. Sottolineano che ciò è avvenuto almeno quando hanno annunciato uno sfruttamento mirato e limitato. Stavano osservando ma, naturalmente, ora le vostre scoperte indicano che forse la situazione è un po’ più ampia. Le vittime sono diverse, sembra che si tratti di un’azione indiscriminata. Forse non subito, ma quantomeno a questo punto.

John: Tendenzialmente sono d’accordo. A dire il vero, la menzione di Microsoft è che si tratta di attacchi limitati e mirati. In verità, non siamo d’accordo. Stiamo vedendo che è su una scala un po’ più ampia, giusto? Si tratta di gelaterie, piccoli alberghi, negozietti all’angolo, organizzazioni governative, amministrazioni comunali e provinciali, istituti finanziari e bancari, fornitori di servizi sanitari e persino fornitori di energia elettrica. Da quello che abbiamo visto, è stato diffuso un po’ ovunque. E questo ha causato un sacco di problemi, ovviamente con i clienti e poi con gli MSP. È stata una settimana frenetica per molte persone, anche se molti MSP hanno migrato la maggior parte dei loro clienti e hanno una manciata di server ancora in circolazione.

Jonathan: Un’altra domanda che sorge spontanea: l’attività di post sfruttamento. Cosa stavano cercando di fare questi tipi? Ci sono molte domande su questo argomento in termini di persone che hanno trovato webshell. Ci sono altre attività? Abbiamo visto Microsoft fare riferimento ad altri strumenti di attacco, tra cui Procdump, e in alcuni casi sono stati abbandonati un paio di framework di sfruttamento. Avete visto queste cose e avete altre indicazioni su ulteriori attività che potete condividere?

John: Non siamo stati in grado di analizzare personalmente l’intero post sfruttamento o le azioni successive degli aggressori. Ci concentriamo sul fatto che è una cosa brutta. Sappiamo che è una piaga. Dobbiamo venirne fuori, ma dall’altra parte, dall’intelligence sulle minacce nella comunità. Si vedono istanze di Procdump o si cerca di prendere le credenziali o gli hash dalla memoria. Stiamo vedendo l’utilità di net.exe, lo strumento a riga di comando di Windows, alcuni che sfruttano i codici binari per aggiungere e rimuovere amministratori, o alcuni strumenti di Powersploit o Powercat per essere in grado di ottenere connessioni in entrambe le direzioni. Vediamo le shell inverse attraverso PowerShell. Sicuramente c’è stato dell’altro, ma non lo sappiamo esattamente. E adesso cosa succederà? Hanno il controllo. Hanno accesso remoto RCE con questa webshell. Significherà ransomware? Significherà esfiltrazione dei dati? Significherà mining di criptovalute? Non ne siamo ancora sicuri, ma siamo ancora in lotta.

Jonathan: Beh, John, grazie mille per essere stato con noi. Oggi alle 13:00 ET per il vostro webinar analizzerete molto di quello che avete trovato e in modo molto più dettagliato. Pubblicheremo un link per la registrazione. Grazie mille per averci dedicato il tuo tempo e grazie a te e a tutti gli altri membri di Huntress per quello che fate. Lo apprezziamo molto.

John: Grazie mille Jonathan.

 

Passi successivi

La creazione di un team IT efficiente ed efficace richiede una soluzione centralizzata che funga da principale strumento per la fornitura di servizi. NinjaOne consente ai team IT di monitorare, gestire, proteggere e supportare tutti i dispositivi, ovunque essi si trovino, senza la necessità di una complessa infrastruttura locale.

Per saperne di più su NinjaOne Endpoint Management, fai un tour dal vivo, o inizia la tua prova gratuita della piattaforma NinjaOne.

Ti potrebbe interessare anche

Vuoi diventare un Ninja dell’IT?

Scopri come NinjaOne può aiutarti a semplificare le operazioni IT.

Termini e condizioni NinjaOne

Cliccando sul pulsante “Accetto” qui sotto, dichiari di accettare i seguenti termini legali e le nostre condizioni d’uso:

  • Diritti di proprietà: NinjaOne possiede e continuerà a possedere tutti i diritti, i titoli e gli interessi relativi allo script (compreso il copyright). NinjaOne ti concede una licenza limitata per l’utilizzo dello script in conformità con i presenti termini legali.
  • Limitazione d’uso: Puoi utilizzare lo script solo per legittimi scopi personali o aziendali interni e non puoi condividere lo script con altri soggetti.
  • Divieto di ripubblicazione: In nessun caso ti è consentito ripubblicare lo script in una libreria di script appartenente o sotto il controllo di un altro fornitore di software.
  • Esclusione di garanzia: Lo script viene fornito “così com’è” e “come disponibile”, senza garanzie di alcun tipo. NinjaOne non promette né garantisce che lo script sia privo di difetti o che soddisfi le tue esigenze o aspettative specifiche.
  • Assunzione del rischio: L’uso che farai dello script è da intendersi a tuo rischio. Riconosci che l’utilizzo dello script comporta alcuni rischi intrinseci, che comprendi e sei pronto ad assumerti.
  • Rinuncia e liberatoria: Non riterrai NinjaOne responsabile di eventuali conseguenze negative o indesiderate derivanti dall’uso dello script e rinuncerai a qualsiasi diritto legale o di equità e a qualsiasi rivalsa nei confronti di NinjaOne in relazione all’uso dello script.
  • EULA: Se sei un cliente NinjaOne, l’uso dello script è soggetto al Contratto di licenza con l’utente finale (EULA) applicabile.