Impersonazione del Centro Assistenza in Microsoft Teams: Quando il Supporto IT ti Contatta per Primo

Sommario

Gli aggressori si spacciano per il supporto IT tramite Microsoft Teams contattando gli utenti da tenant esterni. Si affidano all’ingegneria sociale per convincere le vittime a installare pacchetti MSI dannosi o a concedere l’accesso remoto tramite Quick Assist. Gli obiettivi principali sono il furto di credenziali, il controllo remoto e l’instaurazione di persistenza nell’ambiente della vittima.

Indagine

L’indagine ha identificato un caricatore di malware chiamato SynkLoader che utilizza diversi linguaggi di programmazione ed esegue sostanzialmente in memoria per eludere l’EDR. I ricercatori hanno osservato un modulo di schermata di blocco di Windows falso chiamato PhishLocker progettato per catturare password in chiaro, insieme a un TrafficRedirector proxy inverso utilizzato per il tunneling di rete. Le prove includevano anche attività pianificate sospette e l’abuso di strumenti legittimi come Rclone per l’esfiltrazione.

Mitigazione

Le organizzazioni dovrebbero limitare l’accesso esterno di Microsoft Teams mantenendo una lista di domini approvati e bloccando i sottodomini non attendibili. Gli amministratori dovrebbero disabilitare la possibilità per gli account non gestiti di avviare chat e rivedere le impostazioni relative ai tenant solo di prova. Quick Assist dovrebbe essere disabilitato o rigidamente limitato per prevenire sessioni remote non autorizzate.

Risposta

Se viene rilevata attività dannosa, le macchine colpite dovrebbero essere isolate dalla rete pur rimanendo accese per preservare gli artefatti in memoria. Tutte le sessioni di identità attive dovrebbero essere revocate e la password dell’utente reimpostata da un dispositivo affidabile. Si raccomanda una reimmagine completa del punto finale invece di tentare la pulizia, seguita da un’analisi del raggio d’azione utilizzando i log Single Sign-On (SSO).

Esecuzione di simulazione

• Narrativa dell’attacco e comandi: L’avversario ha ottenuto l’accesso iniziale alla workstation Windows. Per facilitare il movimento laterale ed esfiltrare dati, scaricano il chisel binario. Il loro obiettivo è impostare un tunnel che consenta loro di raggiungere risorse interne dal loro server C2 remoto. Eseguono chisel.exe per avviare una connessione. Poiché la regola di rilevamento cerca la stringa “chisel” nel percorso del processo, questa azione dovrebbe attivare un avviso di alta gravità.

• Script di test di regressione:

  # Script di simulazione: attivare il rilevamento del proxy inverso tramite Chisel
  # Nota: questo script presuppone che chisel.exe sia presente nella directory corrente.
  # Se non presente, tenterà di scaricare un segnaposto o fallirà.
  
  $toolName = "chisel.exe"
  $destination = "8.8.8.8" # Utilizzando DNS di Google come destinazione fittizia per simulare un tentativo di connessione
  $port = "80"
  
  Write-Host "[+] Avvio simulazione: esecuzione di $toolName" -ForegroundColor Cyan
  
  if (Test-Path $toolName) {
      # Eseguire chisel per creare un tentativo di connessione. 
      # Utilizziamo la modalità 'client' per tentare una connessione in uscita.
      Start-Process -FilePath ".$toolName" -ArgumentList "client $destination:$port" -WindowStyle Hidden
      Write-Host "[!] Comando di simulazione inviato. Controlla SIEM per Event ID 3 con immagine contenente 'chisel'." -ForegroundColor Yellow
  } else {
      Write-Error "[!] Errore: $toolName non trovato nella directory corrente. Per favore posiziona il binario qui per eseguire la simulazione."
  }

• Comandi di pulizia:

  # Pulizia: terminare eventuali processi chisel in esecuzione e rimuovere il binario.
  Stop-Process -Name "chisel" -ErrorAction SilentlyContinue
  Remove-Item ".chisel.exe" -Force -ErrorAction SilentlyContinue
  Write-Host "[+] Pulizia completata." -ForegroundColor Green