Auswertung der als potentieller CxO-Fraud erkannten Mails/Absender

[itabtlg]

Hallo zusammen,

seit einigen Monaten haben wir die CxO-Aktion aktiv, ohne Mails abzuweisen oder umzulenken, nur zur Protokollierung. Um zunächst Daten zu sammeln haben wir hierfür einen größeren Personenkreis gewählt. Für einen nächsten Schritt würden wir nun gerne auswerten, von welchen Mailadressen diese Mails gesendet wurden. Dann könnten wir hier nach Prüfung diese erlauben, und zukünftig verschärfen. In den Nachrichtendetails kann ich das sehen, bei dem Volumen unserer E-Mails ist es jedoch nicht praktikabel, alle E-Mails einzeln anzuklicken und per Hand auszuwerten.

(Wie) Ist es möglich hier (per Datenbankabfrage oder per Powershell, oder einem anderen Weg) einen Bericht zu erstellen, wo wir sehen können, welche AD-User und (notfalls oder) welche Mail-Adressen betroffen sind?

Wir nutzen Version 15 des NSP-Servers.

Grundsätzlich würden wir das gerne mit dem lizenzierten Disclaimer-Modul kombinieren, um eine sehr sichtbare Warnung in potentiell betrügerische E-Mails einzufügen, aber das scheint nicht zu gehen, bzw. ich habe dazu keinen Weg gefunden, auch eine Änderung des Betreffs scheint nicht möglich.

Daher nun doch der Versuch der Filterung in eine Quarantäne, aber dazu braucht es vorher eben eine Datenbasis, auf der wir aufbauen können, um keine Unruhe zu verursachen.

 

[JanJäschke]

Guten morgen itabtlg,

eine erste simple SQL Abfrage für einen eine initiale Auswertung könnte wie folgt aussehen:

SELECT TOP (1000)
MTS.*,
O.Data
  FROM [NoSpamProxyAddressSynchronization].[MessageTracking].[MessageOperation] MO
  JOIN MessageTracking.MessageTrackSummary MTS ON MO.MessageTrackId = MTS.Id AND MO.TenantId = MTS.TenantId
  JOIN MessageTracking.Operation O ON MO.OperationId = O.Id AND MO.TenantId = O.TenantId
  Where O.Type = 'FraudDetection' AND JSON_VALUE(O.Data, '$.action') = 'DetectedButDelivered'

Achte bitte darauf die korrekte Datenbank bei dir anzugeben.

Ich hätte hier auch noch einen veralteten PowerShell Report rumliegen der einen Report nur über die NSP CmdLets erstellt.
Dieser war dafür gedacht erkannte E-Mails an die Mitarbeiter zu berichten damit diese dann direkt eine Liste an die IT schicken können.
Per SQL bist du initial aber auf jeden Fall schneller dran =)

Bezüglich Disclaimer:
Du würdest gerne den Disclaimer auftragen lassen wenn CxO Fraud etwas erkannt hat, habe ich das so richtig verstanden?


LG
Jan

 

[Fabian]

Hallo zusammen,

ich schließe mich dieser Anforderung an, jedoch würde ich es begrüßen zwecks doppelten Boden von EoP (Disclaimer eingehend bricht DIKIM somit ist der NSP Disclaimer für mich hier eher uninteressant) den Header von NSP in Exchange (Online) auszuwerten und hier den Banner als HTML Frame einzufügen.

Das Problem: Der Header gibt den vermeintlichen Treffer nicht wieder (Version 15.1). Hier mit Aktion: Annehmen bei der "CxO-Fraud Detection":



Ergebnis im Header:
X-NoSpamProxy-Tests: Real-time blocklists: 0; CSA Certified IP List: 0; Core
Antispam Engine: 0; 32Guards: 0; Reputation filter: 0; CxO Fraud Detection:
Pass; Greylisting: Pass; URL Safeguard: Pass; S/MIME and PGP validation as
well as decryption (preferably inbound): Pass; Content filtering: Pass;
Malware scanner: Pass; 32Guards: Pass

Würden man den Header X-NoSpamProxy-Tests bzw. dessen Ergebnis wie folgt umbauen z.B."[...] CxO Fraud Detection: suspicious [...]" o.ä. für den Treffer, jedoch erwünschte Annahme der E-Mail könnte man das auswerten bzw. mit Folgeaktionen im nächsten Gaetway versehen.

CxO Fraud Detection: pass -> Kein CxO-Fraud gefunden
CxO Fraud Detection: suspicious -> CxO-Fraud gefunden, jedoch wissentlich angenommen

[...]
Grundsätzlich würden wir das gerne mit dem lizenzierten Disclaimer-Modul kombinieren, um eine sehr sichtbare Warnung in potentiell betrügerische E-Mails einzufügen, aber das scheint nicht zu gehen, bzw. ich habe dazu keinen Weg gefunden, auch eine Änderung des Betreffs scheint nicht möglich.
[...]

Ist auch mein Stand, daher die Idee den Header der E-Mail im darauf folgenden Gateway auszuwerten, was aber aktuell auch noch nicht klappt.

Mit freundlichen Grüßen
Fabian

 

[itabtlg]

eine erste simple SQL Abfrage für einen eine initiale Auswertung könnte wie folgt aussehen:

SELECT TOP (1000)
MTS.*,
O.Data
  FROM [NoSpamProxyAddressSynchronization].[MessageTracking].[MessageOperation] MO
  JOIN MessageTracking.MessageTrackSummary MTS ON MO.MessageTrackId = MTS.Id AND MO.TenantId = MTS.TenantId
  JOIN MessageTracking.Operation O ON MO.OperationId = O.Id AND MO.TenantId = O.TenantId
  Where O.Type = 'FraudDetection' AND JSON_VALUE(O.Data, '$.action') = 'DetectedButDelivered'

Achte bitte darauf die korrekte Datenbank bei dir anzugeben.

Vielen Dank. Werde ich gerne ausprobieren.

Ich hätte hier auch noch einen veralteten PowerShell Report rumliegen der einen Report nur über die NSP CmdLets erstellt.
Dieser war dafür gedacht erkannte E-Mails an die Mitarbeiter zu berichten damit diese dann direkt eine Liste an die IT schicken können.
Per SQL bist du initial aber auf jeden Fall schneller dran =)

Könnte ich dieses auch haben? Dann könnten wir vielleicht dann leichter automatisieren, wenn wir dafür einen guten Mechanismus finden.

Bezüglich Disclaimer:
Du würdest gerne den Disclaimer auftragen lassen wenn CxO Fraud etwas erkannt hat, habe ich das so richtig verstanden?

Ja genau, ich würde gerne die User sehr deutlich warnen, dass etwas mit dieser E-Mail sehr komisch ist, aber um möglichen Ärger bei der Einführung zu reduzieren, gerne statt einer Umleitung in eine Quarantäne die Mail durchzulassen, aber eben nur mit deutlicher Warnung.

Zertifikatsbasierte Signaturen würde das brechen, aber die werden bei uns sowieso schon gebrochen, da wir bereits externe Mails mit einem Disclaimer versehen, da dies so gewünscht war. (Das kann aber natürlich über das Plugin oder einen Anhang dargestellt werden.)

 

[itabtlg]

Hallo zusammen,

ich schließe mich dieser Anforderung an, jedoch würde ich es begrüßen zwecks doppelten Boden von EoP (Disclaimer eingehend bricht DIKIM somit ist der NSP Disclaimer für mich hier eher uninteressant) den Header von NSP in Exchange (Online) auszuwerten und hier den Banner als HTML Frame einzufügen.

Das ist eine sehr gute Idee; wir nutzen Exchange ausschließlich On-Premise; aber Regeln könnte man ja sonst trotzdem bauen, die Mails auf Ebene der Exchange-Server entsprechend markieren

Das Problem: Der Header gibt den vermeintlichen Treffer nicht wieder (Version 15.1). Hier mit Aktion: Annehmen bei der "CxO-Fraud Detection":

Würden man den Header X-NoSpamProxy-Tests bzw. dessen Ergebnis wie folgt umbauen z.B."[...] CxO Fraud Detection: suspicious [...]" o.ä. für den Treffer, jedoch erwünschte Annahme der E-Mail könnte man das auswerten bzw. mit Folgeaktionen im nächsten Gaetway versehen.

CxO Fraud Detection: pass -> Kein CxO-Fraud gefunden
CxO Fraud Detection: suspicious -> CxO-Fraud gefunden, jedoch wissentlich angenommen

Das fände ich auch sehr gut, ich hatte schon mit bedauern festgestellt, dass im Header hier nichts zu sehen ist, denn damit kann man ja auch schon sehr viel anfangen.

 

[itabtlg]

Ich habe die Datenbankabfrage versucht, jedoch hatte ich Schwierigkeiten sie auszuführen, wahrscheinlich war es die falsche DB, aber die Tabellennamen in eckigen Klammern habe ich nirgends gefunden (wir nutzen MSSQL Express).

 

[JanJäschke]

Hey,

im Anhang ist einmal das PowerShell Skript.
Ich habe es eben mal noch kompatible gemacht und rudimentär getestet - sah soweit gut aus =)

Bei der SQL Abfrage:
SQL Express ist kein Problem, die eckigen Klammern einfach ignorieren nur das innen drin ist relevant.
Ggf. ist aber auch beim From es etwas unglücklich, dass ich da meinen Datenbanknamen noch drin habe:
FROM [NoSpamProxyAddressSynchronization]
Im SQL Server Management Studio musst du also einmal oben bei der Abfrage die richtige DB wählen und im Skript den Namen entfernen oder anpassen. Die Tabellen/Views werden auf jeden Fall dann da sein.

Bezüglich der möglichen SMIME Signature, wenn es keinen Grund gibt die unbedingt behalten zu wollen (auch wenn sie gebrochen wird) entfernt sie über die Encryption Funktion vom NSP. Dann sieht das intern auch keiner.

Zum Thema Header und Disclaimer spreche ich gleich mal mit den Kollegen, mit etwas Glück lässt sich das schon kombinieren ansonsten nehme ich es als Feature-Request mal auf.


Gruß
Jan

 

[JanJäschke]

Die aktuelle Umsetzung würde es zwar erlauben den Header für den Disclaimer abzufragen, da wir aber nicht den Wert des Headers derzeit auswerten hilft dir das leider nicht weiter. Feature-Request ist also offen