Sapere quando le credenziali emergono.

In arrivo

Corvidint segnala quando email, domini e credenziali della sua organizzazione compaiono in leak e sulle fonti monitorate, così il suo team può reimpostare gli accessi per primo.

L’editor delle watchlist nel prodotto: termini, fonti, lingue, gravità e responsabile della watchlist che genera gli alert.

Schermata del prodotto con dati fittizi

Monitoraggio delle credenziali per i domini che possiede.

I riscontri compaiono solo per i domini verificati dalla sua organizzazione. Si dimostra un dominio una volta, e ogni account al suo interno viene monitorato, quelli di nessun altro.

  • Account dei dipendenti

    Accessi che usano un indirizzo di uno dei suoi domini email.

    Monitorato

    [@]example[.]com

  • Account dei clienti

    Credenziali registrate sulle pagine di accesso dei suoi servizi.

    Monitorato

    hxxps://login[.]example[.]com

  • I suoi domini

    I suoi domini citati in file trapelati, log di infostealer e post sulle fonti monitorate.

    Monitorato

    example[.]comsso[.]example[.]com

  • Non verificato

    Un dominio di cui non è stata dimostrata la proprietà non restituisce alcun riscontro.

    Nessun riscontro

Cosa dice ogni riscontro di esposizione.

Quanto basta per agire, e nulla di più. Il segreto in sé resta sempre mascherato.

Un account sul suo dominio, esposto con il suo cookie di sessione in un log di infostealer su un forum chiuso, visto dal 30 settembre al 4 ottobre.

Revocare le sessioni, reimpostare la password e imporre l’MFA.

  1. Account

    L’accesso interessato sul suo dominio verificato, mostrato solo a chi è autorizzato ad agire.

    [@]example[.]com

  2. Esposizione

    Password, cookie di sessione, contesto di un log di infostealer o record di database. Il tipo decide la correzione; il valore resta mascherato.

  3. Visto su

    Un riferimento defanged e il tipo di fonte, come un forum chiuso, un servizio onion o un leak site.

    hxxps://forum[.]example[.]net/…

  4. Prima e ultima comparsa

    Da quanto tempo l’account è esposto e se continua a essere rilevato.

  5. Azione

    Il passaggio che chiude l’esposizione, così il responsabile può agire prima che l’accesso venga usato.

Da una credenziale trapelata a un reset.

I riscontri di esposizione arriveranno dove il suo team già lavora: watchlist, alert e incidenti, ciascuno con un responsabile, uno stato e un motivo.

  1. Watchlist

    I suoi domini verificati stanno in una watchlist, confrontati con regola esatta sulle raccolte nuove e passate.

    Il dettaglio di una watchlist nel prodotto: termini, ambito, gravità, responsabile e ultima corrispondenza.
  2. Alert

    Una corrispondenza apre un alert con la sua gravità, la sua fonte, un responsabile e il motivo per cui è scattato.

    Il dettaglio di un alert nel prodotto: stato, gravità, responsabile, fonte, la regola che ha trovato corrispondenza e perché è scattato.
  3. Incidente

    Gli alert correlati si raggruppano in un unico incidente con un proprio responsabile e un proprio stato. Ogni alert conserva i suoi.

    Il dettaglio di un incidente nel prodotto: riepilogo, stato, gravità e responsabile di un incidente che raggruppa alert correlati.
  4. Reset e chiusura

    Il suo team reimposta la password, revoca le sessioni e impone l’MFA, poi chiude l’alert indicando un motivo.

    La chiusura di un alert nel prodotto: il motivo è obbligatorio e la chiusura viene registrata nell’audit trail.
Il dettaglio di una watchlist nel prodotto: termini, ambito, gravità, responsabile e ultima corrispondenza.
Il dettaglio di un alert nel prodotto: stato, gravità, responsabile, fonte, la regola che ha trovato corrispondenza e perché è scattato.
Il dettaglio di un incidente nel prodotto: riepilogo, stato, gravità e responsabile di un incidente che raggruppa alert correlati.
La chiusura di un alert nel prodotto: il motivo è obbligatorio e la chiusura viene registrata nell’audit trail.

Gli alert possono anche raggiungere i suoi strumenti tramite webhook.

Schermata del prodotto con dati fittizi

Credenziali solo quando lo dimostra la struttura.

Il parser legge i file trapelati così come sono organizzati. Un valore è considerato una credenziale solo quando lo dimostra il suo stesso record.

Identificativo di accessoSegreto, sempre mascherato

Letto come credenziali

  • Combo list

    indirizzopasswordnota

    Coppie di indirizzo e password, in qualsiasi ordine, con o senza nota.

    Credenziale

  • Esportazioni di database

    ID rigaindirizzopassword

    Righe di una tabella utenti, esportate con la chiave in testa.

    Credenziale

  • Record di accesso

    sitologinpassword

    Un sito, un login e una password, in qualunque ordine arrivino login e password.

    Credenziale

  • File di cookie

    dominio cookiepercorsoscadenzanomevalore

    Esportazioni dei cookie del browser, lette come materiale di sessione e mai come login.

    Materiale di sessione

  • Log di infostealer

    passwordcookieautofillsistema

    La cartella di log di un singolo dispositivo, attribuita solo quando la sua struttura è inequivocabile.

    Un dispositivo

Mai letto come credenziali

  • Elenchi di contatti

    indirizzonome

    Un nome accanto a un indirizzo non diventa mai una password.

    Contatto

  • Elenchi telefonici

    indirizzotelefono

    Un indirizzo accanto a un numero resta un contatto, mai una credenziale.

    Contatto

  • Elenchi di indirizzi e siti

    indirizzosito

    Un indirizzo accanto a un sito non è un accesso.

    Non è un accesso

  • Segnalibri e cronologia

    paginatitolo

    In un log di infostealer, una pagina salvata o visitata non viene mai letta come un accesso.

    Non è un accesso

  • Intestazioni in molte lingue corrispondono agli stessi campi:contraseña, Passwort, senha, wachtwoord
  • Password, cookie e token non vengono mai indicizzati per la ricerca.
  • Un login in un elenco non dimostra né la titolarità né un accesso funzionante.

Come il parser legge i file

Una provenienza da mostrare a un auditor.

Ogni riscontro rimanda alla fonte, all’esecuzione che lo ha raccolto e all’evidenza che lo supporta, conservata com’è stata raccolta.

Un alert chiuso nel prodotto: i suoi collegamenti all’incidente, all’esecuzione di raccolta e all’evidenza, e la sua timeline da aperto a chiuso.
Un alert chiuso nel prodotto: i suoi collegamenti all’incidente, all’esecuzione di raccolta e all’evidenza, e la sua timeline da aperto a chiuso.
Schermata del prodotto con dati fittizi

Mascherati. Verificati. Tracciati. Mai condivisi.

Queste tutele fanno parte del progetto, non sono impostazioni che qualcuno deve ricordarsi di attivare.

  • Mascherati

    Password, cookie e token restano mascherati. Non vengono mai indicizzati per la ricerca né mostrati in un riscontro.

  • Verificati

    I riscontri compaiono solo per i domini di cui la sua organizzazione ha dimostrato la proprietà.

  • Tracciati

    Chi ha aperto un riscontro e chi ha agito su di esso viene registrato nell’audit trail.

  • Mai condivisi

    I dati di esposizione restano nel suo deployment. Non vengono mai venduti, condivisi o redistribuiti.

Un alert aperto senza il permesso di modificarlo: si può leggere, mentre prenderlo in carico, assegnarlo e chiuderlo richiedono il permesso alerts.ack.
Un alert aperto senza il permesso di modificarlo: si può leggere, mentre prenderlo in carico, assegnarlo e chiuderlo richiedono il permesso alerts.ack.
Schermata del prodotto con dati fittizi
  • Controllati per ruolo

    I ruoli di lettore, analista, operatore e amministratore decidono chi può vedere un riscontro e chi può chiuderlo.

  • Fonti autorizzate

    La raccolta proviene solo da fonti che il suo team è autorizzato a monitorare.

Lo metta alla prova sulle sue fonti.

Ci dica di cosa ha bisogno. Le mostreremo una cattura dal vivo, dal post al record sigillato.

Richiedi un briefing

Preferisce l’email? Scriva a [email protected].