Accesso ai CRM: Customer Relationship Management Software (T1213.004)

Sul piano offensivo, questa tecnica presuppone che si sia già dentro: si dispone di credenziali valide o di una sessione autenticata verso il CRM. L'obiettivo di un red team è dimostrare quanto rapidamente un account compromesso possa esfiltrare dati clienti su larga scala.

Il vettore iniziale più efficace, come mostrato dalle attività reali, è la Spearphishing Voice (vishing): si contatta l'help desk o un utente business impersonando IT o un fornitore, inducendo la vittima a fornire credenziali o ad approvare un push MFA. In ambiente Salesforce, una tecnica documentata è convincere l'utente ad autorizzare una connected app malevola o un'app OAuth (ad esempio abusando del flusso di autorizzazione di Data Loader), ottenendo così un token API persistente.

Una volta ottenuto l'accesso, la raccolta si concentra sugli oggetti standard che contengono PII:

• Salesforce: interrogazioni SOQL via API REST/Bulk per estrarre gli oggetti Account, Contact, Lead, Case. Il tool ufficiale Salesforce CLI (open source, comando sf data query --query "SELECT ...") e Data Loader (gratuito, fornito da Salesforce) permettono export massivi legittimi.
• Microsoft Dynamics 365: la Web API OData consente query paginate; curl con bearer token verso l'endpoint dell'organizzazione recupera contatti e opportunità.
• Zendesk / HubSpot / Zoho: API REST documentate con export di ticket e contatti tramite chiamate autenticate a token.

Per simulazioni cloud più ampie, framework come ROADtools (open source) enumerano Azure AD e le app collegate, mentre PowerZure (open source) supporta la ricognizione delle risorse cloud. In laboratorio, gli ambienti gratuiti Salesforce Developer Edition e HubSpot developer sandbox permettono di testare query ed export senza toccare dati reali.

La catena tipica da riprodurre in un esercizio autorizzato è lineare: vishing verso help desk → reset o furto credenziali → autorizzazione app OAuth o login diretto → enumerazione oggetti PII → export Bulk API → staging dei dati per esfiltrazione.

Dal punto di vista OPSEC, l'attaccante realistico evita download singoli anomali e frammenta le query in finestre temporali multiple per restare sotto le soglie di rilevamento. Un red team maturo documenterà volume esfiltrato, tempo di permanenza e assenza di alert, fornendo al blue team metriche concrete su cui calibrare le regole di detection descritte più avanti.

Il rilevamento di questa tecnica è quasi interamente comportamentale e si gioca nei log applicativi SaaS, non sull'endpoint. La logica di riferimento (DET0550) punta a identificare accessi anomali ad alto volume ai record clienti compiuti da account che normalmente non svolgono quella funzione.

Le log source primarie sono gli event log della piattaforma CRM e i sign-in log dell'identity provider: saas:salesforce (Salesforce Event Monitoring / Setup Audit Trail) e m365:signinlogs per gli accessi Azure AD/Entra. In Salesforce sono particolarmente utili gli event type ReportExport, BulkApi, ApiTotalUsage e LoginAs, che tracciano export ed uso massivo delle API.

Il pattern di allarme (AN1520) combina più segnali correlati. Un singolo indicatore raramente basta; la forza sta nella correlazione tra autenticazione sospetta e comportamento successivo:

• Autenticazione da geolocalizzazione rara o impossibile rispetto alla baseline dell'utente, o da device mai visto.
• Accesso ad alto volume a campi PII o export di oggetti (contatti, deal, log) da parte di un account non-admin o di un utente estraneo al reparto vendite.
• Superamento di una soglia di export anomala entro una finestra temporale ristretta (tipicamente 1–5 minuti).

Il tuning è essenziale e va calibrato sui parametri della detection: la TimeWindow in cui avvengono le query bulk, il UserContext (ruolo, dipartimento, funzione), la AnomalousExportThreshold rispetto al normale, e la SourceLocation. Ogni organizzazione ha pattern d'uso diversi: un profilo di sales operations che esporta liste è legittimo, lo stesso volume da un utente marketing o help desk no.

I falsi positivi più frequenti derivano da integrazioni legittime (ETL, backup, sincronizzazioni Marketing Cloud), migrazioni dati pianificate e utenti in trasferta dietro VPN aziendali. Mantenere una allowlist di service account e delle app OAuth approvate riduce drasticamente il rumore.

Sul fronte preventivo, allineare la detection alle mitigazioni: M1018 (User Account Management) con MFA obbligatoria e least privilege riduce la superficie; M1054 (Software Configuration) impone logging dettagliato e integrazione SIEM (ad esempio via Splunk, a pagamento, che aggrega gli event log Salesforce); M1047 (Audit) garantisce revisione periodica di account e privilegi sui dati critici. Monitorare in tempo reale l'autorizzazione di nuove connected app è un controllo ad alto valore, perché intercetta il vettore OAuth prima dell'esfiltrazione.

L'analisi forense di un incidente CRM è prevalentemente cloud-centrica: gli artefatti risiedono nei log della piattaforma SaaS e dell'identity provider, non sui dischi degli endpoint. La priorità è preservare rapidamente questi log, che hanno finestre di retention limitate e spesso richiedono licenze specifiche per essere disponibili.

In ambiente Salesforce, gli artefatti chiave sono il Setup Audit Trail (traccia modifiche di configurazione, creazione di connected app, cambi di permessi), gli Event Monitoring log file (con eventi Login, ReportExport, BulkApi, ApiTotalUsage) e il Login History, che registra IP, user agent e tipo di autenticazione. Per Microsoft Dynamics 365 l'auditing di Dataverse traccia lettura e modifica dei record, mentre i log di Microsoft Purview correlano gli accessi.

Sul fronte identità, i sign-in log di Azure AD/Entra (m365:signinlogs) forniscono geolocalizzazione, device, esito MFA e applicazione target. Sono il punto di partenza per costruire la timeline: correlare l'orario del login anomalo con i successivi eventi di export permette di ricostruire la sequenza compromissione → enumerazione → esfiltrazione.

La timeline tipica da ricostruire prevede: contatto iniziale via vishing (spesso non lasciato nei log tecnici, ma ricavabile da ticket help desk e registrazioni), evento di autenticazione da IP/device inusuale, eventuale autorizzazione di una connected app OAuth con relativo consent, picco di chiamate Bulk API o report export, e volume di oggetti PII acceduti. Ogni tappa va ancorata a timestamp coerenti tra i diversi log source.

Artefatti di supporto includono i token OAuth e le refresh token rilasciate: la loro revoca e l'analisi delle app connesse rivelano meccanismi di persistenza. Sul lato endpoint, se l'attaccante ha operato da una workstation compromessa, la cronologia browser, i cookie di sessione e le voci di autofill possono confermare l'origine dell'accesso.

La campagna C0059 (Salesforce Data Exfiltration) è il caso di riferimento: iniziata a ottobre 2024, ha visto UNC6040 compromettere istanze Salesforce via vishing per furto massivo di dati, seguito da richieste di estorsione da UNC6240. Sul piano investigativo questo si traduce nel cercare accessi API massivi post-vishing e nel documentare il volume esfiltrato per quantificare l'esposizione dei dati clienti. Le policy di retention (M1054) influenzano quanto materiale storico l'analista potrà effettivamente recuperare.

Il quadro di intelligence su questa tecnica ruota attorno a un'unica campagna tracciata ma altamente significativa, che illustra un modello operativo destinato a replicarsi. La lettura corretta non è "un incidente isolato", ma l'emergere di un ecosistema criminale organizzato attorno al furto di dati SaaS.

La campagna C0059 (Salesforce Data Exfiltration), attiva da ottobre 2024, è guidata da UNC6040, attore a movente finanziario. Il suo tratto distintivo è l'uso della Spearphishing Voice (vishing) per compromettere istanze Salesforce aziendali e sottrarne i dati clienti su larga scala. Non si tratta di sfruttamento di vulnerabilità software, ma di ingegneria sociale mirata contro help desk e utenti business, un approccio che aggira gran parte dei controlli tecnici tradizionali.

Un elemento notevole è la separazione dei ruoli nella catena estorsiva. Dopo il furto iniziale operato da UNC6040, le vittime ricevono richieste di riscatto da un attore distinto, UNC6240, che si presenta come il gruppo "ShinyHunters". Questa divisione tra chi accede/esfiltra e chi monetizza suggerisce un modello a specializzazione, in cui l'accesso e i dati diventano una merce scambiata all'interno di community criminali.

Sul piano delle affiliazioni, infrastruttura e TTP osservate durante la campagna mostrano sovrapposizioni con gruppi sospettati di legami con il collettivo più ampio noto come "The Com". È fondamentale l'avvertenza analitica fornita: tali overlap possono derivare da attori che operano nelle stesse community piuttosto che da una relazione operativa diretta. Questo è un classico problema di attribuzione, dove condivisione di strumenti e tecniche non implica catena di comando unificata.

Il trend che emerge è chiaro: i CRM cloud sono bersagli di alto valore perché concentrano PII monetizzabile e perché il loro accesso passa spesso da identità legittime abusate. Il vishing si conferma vettore preferito per superare l'MFA tramite manipolazione umana, mentre l'esfiltrazione avviene tramite strumenti nativi e API legittime, riducendo la visibilità difensiva.

Per un intelligence officer, le implicazioni pratiche sono due. Primo, il rischio downstream: i dati rubati alimentano phishing personalizzato e SIM swapping contro i clienti delle vittime, estendendo l'impatto ben oltre l'organizzazione compromessa. Secondo, la priorità di indurire il fattore umano nell'help desk, il punto in cui questa catena inizia. La combinazione di M1017 (User Training) con simulazioni di vishing e di M1018 con MFA resistente al phishing rappresenta la contromisura più aderente al comportamento osservato di questi attori.

MITRE ATT&CK: tecnica T1213.004 (Customer Relationship Management Software), tattica TA0009. Campagna citata: C0059 (Salesforce Data Exfiltration), attori UNC6040 e UNC6240. Mitigazioni M1017, M1018, M1047, M1054. Detection DET0550 / AN1520. Tool di detection e configurazione richiamati: Splunk, Nessus, Ansible, CIS-CAT, Wireshark, Zeek. Parte dei contenuti operativi su comandi, API CRM e tool (Salesforce CLI, Data Loader, ROADtools, PowerZure) deriva da conoscenza professionale di cybersecurity, non dai dati MITRE forniti.