Fraud: ein vom englischen fraud übernommener, in der Fachsprache der Revision häufig verwendeter Begriff für „Betrug“, auch „betrügerische Handlung“ oder „dolose Handlung“

Wikipedia

Fraud in der IT = Cryptomining auf Azure und die Rechnung zahlt jemand anderes.

Wer gewährt einem Unternehmen den größten Kredit? Eine Bank? Ein Venture Capital?

Nein, es sind die Hyperscaler! 😮

1. Cloud Fraud – was ist das eigentlich?
2. Gedanken der Cloud Anbieter
3. Geeignete Maßnahmen
4. Fazit

tldr> Wer das Thema in Videoform anschauen möchte: https://aka.ms/1millionin17days

Denn oft können beliebig (oder zumindest ausreichend viele) Ressourcen über die Cloud Mechanismen auf Rechnung genutzt werden, ohne, dass eine harte (Kredit-)Grenze existiert, zumindest bis zur nächsten Rechnungsstellung!
[Natürlich abhängig von der verwendeten Vertragsart, etc., der Einfachheit halber bleibe ich bei „unendlich“ um das Problem nachdrücklicher zu verstehen.]

Und genau das gefährdet jedes Unternehmen, sofern nicht gewisse Vorkehrungen getroffen werden/wurden, denn die tatsächlichen Kosten, möchte der Diensterbringer (aka Cloudanbieter) in vielen Fällen natürlich auch – gemäß der geltenden Verträge – gedeckt bekommen! Kurz: in deiner Subscription sind die Dienste erbracht worden, also zahlst du auch dafür, denn du (Kunde) bist dafür verantwortlich Missbrauch und Schaden von deiner Infrastruktur abzuhalten. Stw. „Shared Responsibility„.

Natürlich bleibt das Risiko Ransomware – über die Abwehrmaßnahmen habe ich schon geschrieben, insbesondere in „Kein Mitleid mit Ransomware”!

Spannend ist jedoch, dass die initiale Kompromittierung bei beiden Angriffsarten (Ransomware + Cloud Fraud) identisch ist:

die Übernahme einer User*innenidentität

und somit sind die ersten und wichtigsten drei Abwehrmaßnahmen ebenfalls komplett gleich:

1. Multifactor Authentication!
2. Multi-factor Authentication!!
3. Mfa!!!

Um es noch mal etwas nachdrücklicher zu sagen:

Ein Unternehmen, welches seine Identitäten nicht (mindestens mit MFA) schützt, darf sein restliches Security Budget gemeinnützigen Organisationen spenden, denn dort hat es einen größeren Impact!

Stephanus Schulte

Es ist nach meinem Dafürhalten mal wenigstens als fahrlässig anzusehen, wenn Identitäten – und damit meine ich sowohl User*innen, wie auch Administrator*innen – nicht mittels MFA Mechanismen abgesichert sind!
FYI: laut Microsoft Digital Defense Report 10/2022 verwenden mehr als 70% aller Administratoren KEINE GEEIGNETE FORM VON MFA!

Das Business-Risiko durch Cloud Fraud, welches ohne MFA und weitere Maßnahmen (vgl. weiter unten) für das Unternehmen existieren, übersteigen das einfache Risiko durch Ransomware um ein Vielfaches!!!

Cloud Fraud – was ist das eigentlich?

Das Vorgehen bei Cloud Betrugsfällen ist einfach:

1. Übernahme einer User*innen Identität
2. Sog. Lateral Movement, bis eine (User*innen) Identität gefunden und übernommen wurde, welche in der Lage ist, Clouddienste zu buchen/starten, z.B. zusätzliche VMs.
   Das bedeutet, dass nicht mal zwingend eine typische Admin-Identität benötigt wird, die ggf/hoffentlich besser überwacht ist, sondern dass es lediglich (!) auf das Recht ankommt, neue Ressourcen in ausreichender Menge zu allokieren und zu starten.
3. Per Script werden – typischerweise an einem Freitagnachmittag (am Wochenende ist die Gefahr entdeckt zu werden deutlich geringer!) – in möglichst vielen, verschiedenen Regionen der Welt VMs gestartet [auf die Skalierung kommt es hier den Angreifenden an!] mit der Idee so schnell wie möglich die eigenen Ziele (z.B. Crypto-mining)  zu erreichen und Geld zu verdienen
4. Sobald die VMs laufen, verabschiedet sich der Angreifende für immer, da die Maschinen automatisch ihre Ergebnisse liefern und keinerlei Zutun mehr erforderlich ist
5. Dies läuft so lange, bis es jemand merkt, also manchmal auch über Tage oder Wochen
6. Die Rechnung mit oft 5, 6 oder 7stellen kommt dann im nächsten Monat, spätestens dann sollte es auffallen.
   

Um es noch einmal deutlich zu sagen: es geht hier um
100.000  bis MILLIONENEN €
an angefallenen, tatsächlichen Kosten pro Einzelfall!!

Für den Cloudanbieter ergeben sich daraus mehrere Fragestellungen, die nicht einfach zu beantworten sind:

1. Sollte ich das Verhalten auf der angebotenen Plattform überwachen und die Kunden aktiv vor Missbrauch schützen? Das würde aber bedeuten, dass ich genauer analysieren muss, was ein Kunde mit der Plattform anstellt – wie sieht es hier mit Vertrauen und Rechtmäßigkeit aus? Darf ich das? Soll ich das? Wird das von mir erwartet?
2. Sollte ich automatische Obergrenzen erstellen, die einen „unendlichen“ Gebrauch einschränken?
   Und wenn ja, welche Hard- und Softlimits sollte es geben?
3. Wie kann AI bei der Detektion unterstützen? „Eine Subscription, die bis jetzt 0€ verbraucht hat und plötzlich tausende Euro verbraucht muss gestoppt werden!“ […oder wurde der Zweck für die Subscription grade erst gestartet, z.B. ein großes Marketing Event, welches jetzt viele Ressourcen verwendet, vorher nicht, und es sehr unschön wäre, wenn es durch Automatismen erstmal aufgehalten würde!?]
4. Welche (möglichst einfachen) Support Wege muss dem Kunden dargeboten werden?
5. Wie kulant kann oder darf ich sein?

Das sind Fragestellungen, die nicht mal eben so zu beantworten sind – die auch je nach Anbieter gegebenen Falls unterschiedlich beantwortet werden.

Daher möchte ich gerne Möglichkeiten aufzeigen, wie denn jede*r selber etwas tun kann um entweder den Fraud gar nicht erst entstehen zu lassen, diesen einzuschränken oder zumindest rechtzeitig den Missbrauch zu detektieren:

Geeignete Maßnahmen

1. Wie schon oben angedeutet ist die aller wichtigste Maßnahme bei der Verwendung von (dynamischen) Cloud-Diensten, die Identitäten so gut wie möglich zu schützen, mindestens mittels Phishing Resistenter Multifactor Authentication!
2. Ein geeignetes Rollen- und Rechtemanagement
   „Wer darf wann was und wieviel?“
   Stichwort hier ist RBAC „Role Based Access Control“: What is Azure role-based access control (Azure RBAC)? | Microsoft Learn
   Ich werde jetzt nicht auf das Thema eingehen, weil das den Rahmen dieses Posts sprengen würde.
   
   Aber kurz: es sollte sichergestellt werden, dass jede handelnde Rolle möglichst wenig Rechte besitzt, insb. nur so viel, wie für die meisten Aktionen notwendig sind. Außergewöhnliche Tätigkeiten sollten über eine andere Rolle/Identität durchgeführt werden.
   Dabei hilft Priviledge Identity Management!
3. Es sollten, sofern möglich und sinnvoll, Cost capping Mechaniken genutzt werden. Und ja, mit entsprechender Berechtigung lassen sich diese gegebenen Falls durch Angreifende ändern oder deaktivieren, wo wir aber wieder bei 2. wären! 😉
   Azure spending limit – Microsoft Cost Management | Microsoft Learn
4. Je nach Cloudanbieter lassen sich auch Alerts auf ungewöhnliche Veränderungen bei Ressourcen und/oder Kosten erstellen und diese entsprechend durch das eigene Security Opperation Center (SOC) bzw. den Ressource Besitzern bewerten:

Subscribe to emails – Microsoft Azure
Bei Azure ist es so, dass wenn ich ein Budget erstellt habe (siehe 3.), ich daraus sofort auch einen Alert machen kann:
Tutorial – Create and manage Azure budgets – Microsoft Cost Management | Microsoft Learn
How to configure Azure budgets and costs alerts – YouTube

5. Damit sind wir insgesamt bei dem Thema „HowTo: Kosten Überwachen“:
   Track costs across business units, environments, or projects – Cloud Adoption Framework | Microsoft Learn
6. Auch die Überwachung von Cost Alerts durch Microsoft Sentinel kann ein geeignetes Mittel sein:
   Azure-Sentinel/Playbooks/Send-IngestionCostAlert at master · iwafula025/Azure-Sentinel · GitHub
7. Generell sollte anhand von (Governance) Frameworks agiert werden:
   Govern methodology for the cloud – Cloud Adoption Framework | Microsoft Learn

8. Sofern die Azure Subscriptions durch einen Microsoft Partner bezogen werden, lassen sie sich durch diesen bei der Limitierung der Budgets unterstützen:
   Set an Azure spending budget for customers – Partner Center | Microsoft Learn
9. Grade für Partner bietet es sich an Microsoft 365/Azure Lighthouse zu nutzen:
   What is Azure Lighthouse? – Azure Lighthouse | Microsoft Learn
   Overview of Microsoft 365 Lighthouse | Microsoft Learn
10. Für ein standardisiertes Herangehen hat mein Kollege Niels Ophey ein GitHub Rep erstellt:
    https://aka.ms/CAF-basic-govern
    an dem sich alle gerne beteiligen dürfen und sollen!
11. Außerdem sollte darüber nachgedacht werden – sofern in der Cloudplattform verfügbar – Policies zu definieren, die zum Beispiel die Nutzung in vielen, verschiedenen, weltweiten Regionen einschränken oder nur vordefinierte Sizes für die Ressourcen vorgeben:
    Common Azure Policy examples -Restrict resource regions – Cloud Adoption Framework | Microsoft Learn
    Common Azure Policy examples – Restrict VM Size – Cloud Adoption Framework | Microsoft Learn

Fazit

Governance sichert das Überleben!

Wer sich nicht um die wesentlichen Dinge

1. Identity Protection & MFA
2. Rollenmanagement
3. Cost Governance

kümmert, der setzt sich ohne Not einer riesigen Gefahr und einem potentiell hohen finanziellen Risiko aus – und genau das ist doch eigentlich gar nicht notwendig, da Governance sowieso für eine gute und sinnvolle Cloudnutzung notwendig ist!

P.S.: Dieser Artikel wurde ohne die Hilfe von ChatGPT erstellt! 😮