Verwenden Sie das Playbook „mögliches Passwortspray“

Verwenden Sie dieses Playbook, um Passwortspray-Warnungen zu untersuchen, die durch mehrere fehlgeschlagene Anmeldungen ausgelöst wurden (zu viele Authentifizierungsfehler von mehr als einer IP-Adresse für denselben Anwender). Die folgenden Schritte geben Ihnen einen Rundgang durch die Aktionen, Aufgaben und Subflows, die im Playbook „mögliches Passwortspray“ verfügbar sind.

Vorbereitungen

Erforderliche Rolle:

• sn_si.admin
• Flow_Designer

Stellen Sie sicher, dass Sie Security Operations Spoke ( sn_sec_Spoke ).

Prozedur

1. Wenn das Playbook ausgelöst wird und die Ausführung beginnt, müssen Sie in Aktion 1 überprüfen, ob die Aktivitäten von der IP-Adresse des Kunden stammen.
   Identifizieren Sie die IP-Adressen, die den Passwortspray-Angriff durchführen. Verwenden Sie beispielsweise die TXIDs (Transaktions-IDs) aus der Warnung, und suchen Sie sie anhand der F5-Protokolle.
2. Führen Sie in Aktion 2 die folgenden Aktionen aus, wenn die Aktivitäten von der IP-Adresse des Kunden stammen:
   1. In Aktion 3 müssen Sie eine Überprüfung des möglichen Passwortspray-Angriffs nach dem Incident initiieren.
   2. In Aktion 4 endet der Flow.
3. Wenn die Aktivitäten in Aktion 5 nicht von der IP-Adresse des Kunden stammen, bestimmen Sie die Quell-IP des Angreifers aus den Warnungsdetails.
4. In Aktion 6 müssen Sie die IP-Reputation mithilfe von Open Source Intelligence-Tools (OSINT) und des Datenverkehrsmusters dieser IPs in den letzten sieben Tagen validieren.

   Abbildung : 1. Mögliches Playbook für Passwortspray

   

5. In Aktion 7 müssen Sie die Anwendernamen identifizieren, die sich erfolgreich mit dem Passwortspray-Angriff angemeldet haben.
6. In Aktion 8 müssen Sie die Anzahl der fehlgeschlagenen Anmeldungen und Muster identifizieren.
7. In Aktion 9 müssen Sie die Indikatoren für „wirklich positiv“ identifizieren.
   • Überprüfen Sie den Datenverkehr von den Quell-IPs in den letzten 60 Tagen. Kein historischer Datenverkehr kann ein Hinweis auf ein wirklich positives Ergebnis sein.
   • Überprüfen Sie die Anwendernamen-Muster mit Authentifizierungsfehlern und die Anzahl. Je höher die Anzahl, desto höher ist die Wahrscheinlichkeit, dass es sich um ein wirklich positives Ergebnis handelt.
   • Der Anwendername sieht wie eine Wörterbuchbasis aus (beginnend von A bis Z) und kann allgemeine Administratornamen wie admin, sysadmin, root usw. haben
   • Derselbe Anwendername kann verschiedene Muster im Sprayangriff aufweisen, z. B. dieselbe Warnung kann Fehler für john.doe, johnd, jdoe, john_doe, jdoe7 usw. aufweisen. gibt an, dass Angreifer das Anwendername-Muster basierend auf allgemeinen Anwendungsfällen erraten.
   • Beachten Sie den Anwender-Agent und die URIs aus den F5-Protokollen im obigen Schritt, und überprüfen Sie, ob sich die IOCs auf die roten Kondor-Warnungen beziehen. Wenn sie übereinstimmen, ist es ein wirklich positives Ereignis.
8. In Aktion 10 müssen Sie basierend auf der bisher durchgeführten Untersuchung überprüfen, ob es sich um einen möglichen Passwortspray-Angriff handelt oder nicht.
9. Führen Sie in Aktion 11 die folgenden Aktionen aus, wenn es sich um einen möglichen Passwortspray-Angriff handelt:
   1. In Aktion 12 müssen Sie sich mit den entsprechenden Teams abstimmen, um alle erforderlichen Accounts zu sperren und böswillige Aktivitäten zu untersuchen.

      Abbildung : 2. Mögliches Playbook für Passwortspray

      

   2. In Aktion 13 müssen Sie eine Überprüfung des möglichen Passwortspray-Angriffs nach dem Incident initiieren.
   3. In Aktion 14 endet der Flow.
10. In Aktion 15 müssen Sie überprüfen, ob es sich nicht um einen möglichen Passwortspray-Angriff handelt.
11. Führen Sie in Aktion 16 die folgenden Aktionen aus, wenn es sich nicht um einen möglichen Passwortspray-Angriff handelt:
    1. In Aktion 17 müssen Sie die Ergebnisse bisher dokumentieren.
    2. In Aktion 18 müssen Sie eine Überprüfung des möglichen Passwortspray-Angriffs nach dem Incident initiieren.
    3. In Aktion 19 endet der Flow.
12. In Aktion 20 müssen Sie sich an die Kollegen und den GIR-Manager wenden, um Anleitungen zu erhalten.
13. In Aktion 21 wird eine Antwortaufgabe erstellt, um die Überprüfung nach dem Incident abzuschließen, bevor die Aufgabe geschlossen wird.