Reverse Shell

In diesem Dokument wird ein Typ von Bedrohungsergebnissen in Security Command Center beschrieben. Bedrohungsergebnisse werden von Bedrohungsdetektoren generiert, wenn sie eine potenzielle Bedrohung in Ihren Cloud-Ressourcen erkennen. Eine vollständige Liste der verfügbaren Bedrohungsergebnisse finden Sie im Index der Bedrohungsergebnisse.

Übersicht

Ein Prozess, bei dem die Stream-Weiterleitung an einen Remote-Socket gestartet wurde. Das Erstellen einer mit dem Netzwerk verbundenen Shell kann es einem Angreifer ermöglichen, nach einem begrenzten anfänglichen Kompromiss beliebige Aktionen auszuführen.

So reagieren Sie

Gehen Sie folgendermaßen vor, um auf dieses Ergebnis zu reagieren:

Schritt 1: Ergebnisdetails prüfen

  1. Öffnen Sie ein Reverse Shell-Ergebnis, wie unter Ergebnisse prüfen beschrieben. Der Detailbereich für das Ergebnis wird geöffnet und der Tab Zusammenfassung wird angezeigt.

  2. Sehen Sie sich auf dem Tab Zusammenfassung die Informationen in den folgenden Abschnitten an:

    • Was wurde erkannt?, insbesondere die folgenden Felder:
      • Binärdatei des Programms: der absolute Pfad des Prozesses, der mit der Streamweiterleitung zu einem Remote-Socket gestartet wurde.
      • Argumente: die Argumente, die beim Aufrufen der Prozessbinärdatei angegeben werden.
    • Betroffene Ressource, insbesondere die folgenden Felder:
      • Vollständiger Ressourcenname: der vollständige Ressourcenname des Clusters.
      • Vollständiger Name des Projekts: Das betroffene Google Cloud Projekt.
    • Weitere Informationen, insbesondere die folgenden Felder:
      • VirusTotal-Indikator: Link zur VirusTotal-Analyseseite.
  3. Klicken Sie in der Detailansicht des Ergebnisses auf den Tab JSON.

  4. Achten Sie in der JSON-Datei auf die folgenden Felder.

    • resource:
      • project_display_name: Der Name des Projekts, das das Asset enthält.
    • sourceProperties:
      • Pod_Namespace: der Name des Kubernetes-Namespace des Pods.
      • Pod_Name: der Name des GKE-Pods.
      • Container_Name: der Name des betroffenen Containers.
      • VM_Instance_Name: der Name des GKE-Knotens, auf dem der Pod ausgeführt wurde.
      • Reverse_Shell_Stdin_Redirection_Dst_Ip: die Remote-IP-Adresse der Verbindung
      • Reverse_Shell_Stdin_Redirection_Dst_Port: der Remote-Port
      • Reverse_Shell_Stdin_Redirection_Src_Ip: die lokale IP-Adresse der Verbindung
      • Reverse_Shell_Stdin_Redirection_Src_Port: der lokale Port
      • Container_Image_Uri: der Name des ausgeführten Container-Images.

Schritt 2: Cluster und Knoten prüfen

  1. Rufen Sie in der Google Cloud Console die Seite Kubernetes-Cluster auf.

    Zur Seite Kubernetes Clusters

  2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

  3. Wählen Sie den in resource.name aufgeführten Cluster aus. Notieren Sie sich alle Metadaten zum Cluster und zu seinem Inhaber.

  4. Klicken Sie auf den Tab Knoten. Wählen Sie den in VM_Instance_Name aufgeführten Knoten aus.

  5. Klicken Sie auf den Tab Details und notieren Sie sich die Annotation container.googleapis.com/instance_id.

Schritt 3: Pod überprüfen

  1. Rufen Sie in der Google Cloud Console die Seite Kubernetes-Arbeitslasten auf.

    Zur Seite "Kubernetes-Arbeitslasten"

  2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

  3. Filtern Sie bei Bedarf nach dem in resource.name aufgeführten Cluster und dem in Pod_Namespace aufgeführten Pod-Namespace.

  4. Wählen Sie den in Pod_Name aufgeführten Pod aus. Notieren Sie sich alle Metadaten zum Pod und zu seinem Inhaber.

Schritt 4: Protokolle prüfen

  1. Rufen Sie in der Google Cloud Console den Log-Explorer auf.

    Zum Log-Explorer

  2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

  3. Wählen Sie für Zeitraum auswählen den gewünschten Zeitraum aus.

  4. Gehen Sie auf der Seite, die geladen wird, so vor:

    1. Suchen Sie mit dem folgenden Filter Pod-Logs für Pod_Name:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
    2. Suchen Sie mit dem folgenden Filter Cluster-Audit-Logs:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
    3. Suchen Sie nach Logs der GKE-Knotenkonsole mit dem folgenden Filter:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Schritt 5: Laufenden Container prüfen

Wenn der Container noch ausgeführt wird, können Sie die Containerumgebung möglicherweise direkt untersuchen.

  1. Rufen Sie die Google Cloud Console auf.

    Google Cloud Konsole öffnen

  2. Wählen Sie in der Symbolleiste der Google Cloud Console bei Bedarf das in resource.project_display_name aufgeführte Projekt aus.

  3. Klicken Sie auf Cloud Shell aktivieren .

  4. Rufen Sie die GKE-Anmeldedaten für Ihren Cluster ab, indem Sie die folgenden Befehle ausführen.

    Für zonale Cluster:

      gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
    

    Für regionale Cluster:

      gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
    
  5. Starten Sie eine Shell in der Containerumgebung, indem Sie Folgendes ausführen:

      kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
    

    Bei diesem Befehl muss für den Container eine Shell unter /bin/sh installiert sein.

    Führen Sie den folgenden Befehl in der Container-Shell aus, um alle im Container ausgeführten Prozesse aufzurufen:

      ps axjf
    

    Bei diesem Befehl muss für den Container /bin/ps installiert sein.

Schritt 6: Forschungsangriffs- und Reaktionsmethoden

  1. Prüfen Sie die MITRE-ATT&CK-Framework-Einträge für diesen Ergebnistyp: Befehls- und Skriptinterpreter, Ingress-Tool Transfer.
  2. Prüfen Sie den SHA-256-Hashwert für die als schädlich gekennzeichnete Binärdatei auf VirusTotal, indem Sie auf den Link in VirusTotal-Indikator klicken. VirusTotal ist ein Alphabet-eigener Dienst, der Kontext zu potenziell schädlichen Dateien, URLs, Domains und IP-Adressen bereitstellt.
  3. Wenn Sie einen Reaktionsplan entwickeln möchten, kombinieren Sie Ihre Untersuchungsergebnisse mit der MITRE-Forschung und der VirusTotal-Analyse.

Schritt 7: Antwort implementieren

Der folgende Antwortplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Vorgänge auswirken. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Ergebnisse zu ermitteln.

  • Wenden Sie sich an den Inhaber des Projekts mit dem manipulierten Container.
  • Beenden oder löschen Sie den manipulierten Container und ersetzen Sie ihn durch einen neuen Container.

Nächste Schritte