Neues zum Exchange-Hack – Testtools von Microsoft & Co.

[English]Der Hafnium-Hacker-Gruppe ist es wohl gelungen, weltweit Hundertausende an Exchange-Installationen über Schwachstellen zu kompromittieren. Ein Patch zum Schließen der Schwachstellen steht zwar bereit, aber es kann zu spät sein. Inzwischen gibt es aber von Microsoft und Dritten Tools, um Exchange-Instanzen auf Anzeichen des Hacks zu überprüfen.


Anzeige

Hundertausende Exchange-Server infiltriert

Es scheint, dass nach der SolarWinds-Attacke durch mutmaßlich staatsnahe russische Angreifer der nächste Sicherheits-GAU gerade offenbart wurde. Hacker der mutmaßlich staatsnahen chinesischen Hackergruppe Hafnium haben monatelang Schwachstellen in On-Premise Exchange Servern zum Eindringen benutzt. Die Schwachstelle wurde erst am 2. März 2021 durch Sicherheitsupdates geschlossen. Ich hatte in diversen Blog-Beiträgen darüber berichtet (siehe Artikelende). Und im Volexity-Blog (deren Sicherheitsforscher haben den Angriff und die Schwachstellen entdeckt) findet sich dieser Beitrag zum Thema.

Ziel der Angreifer war es, Kontrolle über die E-Mails der Opfer zu bekommen und möglicherweise über die Active Directory-Berechtigungen auf deren Netzwerk-Infrastruktur zuzugreifen und sich dort einzunisten. Vor wenigen Tagen ging ich noch davon aus, dass nur einige wenige US-Institutionen und Firmen gezielt angegriffen wurden.

Inzwischen steht fest, dass Massen-Scans im Internet erfolgten und die Hafnium-Gruppe wohl aggressiv versuchte, angreifbare Exchange-Instanzen zu infiltrieren. Im Beitrag Wichtige Hinweise Microsofts und des BSI zum Exchange-Server Sicherheitsupdate (März 2021) hatte ich die Warnung des BSI transportiert, die von Tausenden deutscher Exchange-Installationen, die gehackt wurden, ausgeht. Das BSI hat angefangen, identifizierte Betroffene per Post zu informieren.

Infizierte Exchange-Server
Infizierte Exchange-Server, Quelle: Rapid7Zum Vergrößern klicken

Sicherheitsanbieter Rapid7 geht in diesem Artikel von 170.000 gefährdeten Exchange-Servern aus, wobei es in den USA und in Deutschland wohl „Hot-Spots“ mit mehr als 10.000 Instanzen gibt. Im Beitrag sind auch IP-Adressen angegeben, die das Internet scannen – und es findet sich eine Analyse, wie man eine Infektion erkennen könnte. Weitere Informationen und Analysen liefert dieser Microsoft-Artikel, sowie diese US-CERT-Warnung.

Das Ganze ist ein GAU, dürfte es doch viele kleine Unternehmen getroffen haben, wo ein Exchange-Server herumdümpelt (siehe auch diesen Wired-Beitrag). Sicherheitsforscher des entdeckenden Sicherheitsanbieters Volexity betrachten das Ganze als tickende Zeitbombe. Und jetzt noch patchen hilft nicht, wenn die Hafnium-Gruppe bereits eine Webshell als Backdoor installiert hat.

Scan-Tools von Microsoft & Co.

Microsoft hat ein bereits seit längerem bestehendes, als Test-Hafnium bekanntes, PowerShell-Script mit dem Namen  Test-ProxyLogon.ps1 so erweitert, dass es die jetzt genutzten Schwachstellen erkennt. Das Script sowie zusätzliche Hinweise finden sich auf GitHub.

Test-ProxyLogon.ps1


Anzeige

Bleeping Computer weist in obigem Tweet auf das PowerShell-Script Test-ProxyLogon.ps1 hin – in diesem Artikel finden sich noch einige Hinweise zum Thema. Microsoft Sicherheitsforscher Kevin Beaumont weist in folgendem Tweet auf ein offizielles Microsoft nmap-Skript hin, das unabhängig von der CU/SU-Situation identifiziert, ob Systeme für die Exchange-Schwachstellen anfällig sind. Keine Authentifizierung erforderlich.

Microsoft nmap Script für Exchange-Schwachstellen

Microsoft nmap Script für Exchange-Schwachstellen

Auch das CERT Lettland hat auf GitHub ein Script veröffentlicht, mit dem sich prüfen lässt, ob ein Exchange-Server mit einer Webshell infiziert wurde. Catalin Cimpanu weist in nachfolgendem Tweet auf das Thema hin.

Exchange-Test des CERT-Lettland
Exchange-Test des CERT-Lettland

Ergänzung: Beachtet auch die Hinweise in den nachfolgenden Beiträgen, insbesondere unter Exchange-Hack: Neue Patches und neue Erkenntnisse.

Ähnliche Artikel:
Exchange-Server 0-day-Exploits werden aktiv ausgenutzt, patchen!
Wichtige Hinweise Microsofts und des BSI zum Exchange-Server Sicherheitsupdate (März 2021)
Exchange-Probleme mit ECP/OWA-Suche nach Sicherheitsupdate (März 2021)
Neues zum Exchange-Hack – Testtools von Microsoft & Co.
Microsoft MSERT hilft bei Exchange-Server-Scans
Exchange-Hack: Neue Patches und neue Erkenntnisse
Anatomie des ProxyLogon Hafinum-Exchange Server Hacks
Exchange-Hack: Neue Opfer, neue Patches, neue Angriffe
Neues zur ProxyLogon-Hafnium-Exchange-Problematik (12.3.2021)
Gab es beim Exchange-Massenhack ein Leck bei Microsoft?
ProxyLogon-Hack: Repository für betroffene Exchange-Administratoren


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Anzeige


Dieser Beitrag wurde unter Sicherheit abgelegt und mit Exchange, Sicherheit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

35 Antworten zu Neues zum Exchange-Hack – Testtools von Microsoft & Co.

  1. Gert sagt:

    Das kann ja noch spaßig werden :-(

  2. Mr.Blacksmith sagt:

    Tja!

    Da die studierte Führungselite wiederholt nicht zuhören wollte, ist es wohl um einen unserer Server in den USA geschehen! Und auch jetzt, nachdem ich den Hack gemeldet habe: Null Reaktionen!

    Was soll der geneigte Hauptschüler da noch machen!? Lege ich jetzt Hand an, wird mir der Hack noch untergeschoben!

    Also heißt es, wie so oft…zurücklehnen und warten, bis die Führungsriege reagiert und mir den Biohaufen als Ticket serviert!

    Spätestens dann sind Pilze am Horizont zu erblicken!

    ICH…WILL…HIER…WEG…!!!

  3. Stephan sagt:

    Ich will gar nicht wissen, wie viele das jetzt noch gar nicht mitbekommen haben und Montag einen Schock kriegen werden.

    Laut Proxylogon hat die taiwanesische Firma DEVCORE die Lücken bereits im Dezember gefunden und an Microsoft gemeldet, bevor die Angriffe losgingen.
    https://proxylogon.com/

  4. Mr.Blacksmith sagt:

    Noch kritischer ist, schätze ich mal:
    Viele meinen, mit den Updates nach einem vermeintlichen Befall ist es erledigt!

    Das ist es mitnichten! WER weiß schon, WAS alles in der Zwischenzeit im Netzwerk wie und wo verbreitet und manifestiert wurde…!?!?

    Selbst wenn die Schäden durch diese Lücke „beseitigt“ wurden…welchen Effekt hatten sie bereits auf weitere Systeme und Komponenten, die heute noch gar nicht bekannt sind..?!?

    • MOM20xx sagt:

      tja da kann man jetzt an der architektur vom exchange server diskutieren. klar kann man bis zu einem gewissen grad in der jetzigen form separieren, aber im prinzip ist der exchange gefallen, ist zu einem hohen prozentsatz auch das AD gefallen und man hat quasi verloren im eigenen netz.
      und ich. möchte gar nicht wissen, welche probleme die mit exchange in der cloud haben. da bekommt es halt so nur keiner in der schärfe mit.
      der aufbau mit ad und allem und zentraler verwaltung hat sicher seine vorteile, kann und wird vor allem bei vielen firmen in so einem fall zum desaster schlecht hin.

    • HannibalSD sagt:

      Vorallem … ich schaue immer mit einem skeptischen Auge auf solche Patchaktionen.
      Wenn ich jemand wäre, der eine solche Lücke gefunden und genutzt hat… dann würde rein gehen, eine andere Tür öffnen und meine schließen. Ich checke also jetzt das System, ob ich verwundbar bin… ;-)
      Wenn es der eigene Server ist, dann weiß man ja noch was da vorher eingestellt war… aber bei Kunden, die anrufen und sagen“ Hey, check mal ob ich dat ding hab! Aber pronto!!! „

  5. Mnauhiri sagt:

    Mir fällt da spontan die Kanzlerin ein, die bei dem Begriff „Neuland“ schon einen abgehängten Eindruck auf mich machte, obwohl man ihr gern das „Denken vom Ende her“ attestiert. Es wird der Tag kommen, an dem ich meine elektronische Patientenakte an igendeine Hauswand projiziert sehe…

    Ich bleibe bei meiner Bedrohungsrangliste für das europäische Projekt, falls es sowas noch gibt: China, Russland, Naher/Mittlerer Osten. Das werden Demokratien nicht dauerhaft aushalten. Wir sind gerade Zeitzeugen einer enormen Beschleunigung fast aller Entwicklungen.

  6. MOM20xx sagt:

    hilfreich wäre wohl eher ein script, das checked ob man erwischt wurde und infiziert ist. angreifbar war wohl jeder bis anfang märz. die patches sind nun installiert. nur ich möchte wissen ob es mich erwischt hat und die installation was abbekommen hat. gibts da was effektives zum prüfen?

    • Mr.Blacksmith sagt:

      Wie soll es da was geben? Prüfen kann man nur, ob man durch eine der vier Sicherheitslücken erwischt wurde. Liegt z.B. eine aspx-Datei im Pfad:

      C:\inetpub\wwwroot\aspnet_client\system_web

      Ist man wohl dabei gewesen.

      Vielmehr lautet das Problem nach erfolgreichem Patch und wenn man dabei war:

      WAS wurde noch in der Zwischenzeit WO und WIE hinterlegt als Bombe, was dann späteren Zugriff / Schaden verursachen kann..?

      Da wird es ja erst richtig „spannend“…;-/.

      Dinge, auf die der geneigte Sysadmin durchaus verzichten kann…

    • Tim Hägele sagt:

      am ehesten Noch Microsoft Safety Scanner.
      https://docs.microsoft.com/de-de/windows/security/threat-protection/intelligence/safety-scanner-download

      Das tool findet nach und nach Trojaner und Backdoors die hinterlassen wurden.
      Am besten die nächsten Tage immer wieder herunterladen, falls der Server nicht von Backups wiederhergestellt oder neu installiert werden soll.

  7. Stefan sagt:

    Mal einfach gesponnen aus den Daten bei Proxylogon von Devcore und Velocity:

    Ich bin Hacker und suche Schwachstellen.

    A) ich suche selber

    B)
    Ich Hacke/überwache weltweite PEN Tester, wie devcore. Finde diese was und sind in Kontakt mit Herstellern, habe ich den Proof of Concept gleich im Blick.

    Insbesondere das velocity wohl erst ab 06.01.2021 verdächtige Sachen entdeckte.
    (Devcore war bereits Ende 2020 mit dem MSRC in Kontakt.)

    Auch das die Aktivitäten wohl ab 26.02. Zunahmen, ist mit Bezug auf die Devcore timeline verdächtig.

    Wirklich schone neue Welt !

  8. Ron sagt:

    Auf Microsofts GitHub-Repository ‚CSS-Exchange‘ steht ein PowerShell-Skript bereit, das einen oder mehrere Exchange-Server auf Spuren untersucht, die ein erfolgreicher Angriff hinterlässt: https://github.com/microsoft/CSS-Exchange/tree/main/Security

  9. Tom sagt:

    Bisher funktioniert keines der ganzen Menge an Scripten, die bisher freundlicherweise bereitsgestellt wurden, auf Exchange Server 2010 CU32.

    • Martin B sagt:

      Sehe ich genauso:
      [PS] C:\> .\Test-ProxyLogon.ps1 -DisplayOnly

      Der Typ [pscredential] kann nicht gefunden werden: Stellen Sie sicher, dass die Assembly, die diesen Typ enthält, geladen wird.
      Bei C:\Users\sbsadmin\Downloads\Test-ProxyLogon.ps1:84 Zeichen:27
      + [pscredential] <<<<
      + CategoryInfo : InvalidOperation: (pscredential:String) [], RuntimeException
      + FullyQualifiedErrorId : TypeNotFound

  10. Mr.Blacksmith sagt:

    Bei meiner Arbeit auf unserem US-Exchangeserver bin ich bei einem der anderen Server im Netzwerk auf einen Ordner gestoßen, der sich nicht löschen oder in seinen Zugriffsrechten (bin als Admin unterwegs!) ändern lässt. Auch die Besitzübernahme ist nicht möglich:

    C:\Windows\SoftwareDistribution\Download\5a8bb2f9f136c3a8aff6a96ef4b139cc

    Gleiches Erstellungsdatum wie beim Befall des Exchangeservers!

  11. Andreas sagt:

    Da die Scripte nicht auf einem Exchange 2010 funktionieren würde mich eine „Indizienliste“ intererssieren, nach der man auf den Servern nach der Installation SP3 RU32 prüfen kann, ob man das Ei bereits ins Nest gelegt bekommen hat.

    Mr. Blacksmith hatt dazu oben etwas geschrieben:
    C:\inetpub\wwwroot\aspnet_client\system_web

    Hat jemand weitere Tipps? Meine bisherige Suche war erfolglos.

    • Günter Born sagt:

      Möglicherweise habe ich was nicht mitbekommen – aber ich habe doch einige Artikel zu Microsoft, Rapid7 etc. verlinkt. Hier ein Auszug aus dem Rapid7-Beitrag:

      Technical Analysis of Attacker Activity
      Automated scanning to discover vulnerable Exchange servers from the following DigitalOcean IP addresses:
      165.232.154.116
      157.230.221.198
      161.35.45.41
      2. Analysis of Internet Information Services (IIS) logs shows a POST request is then made from the scanning DigitalOcean IP to multiple paths and files:
      
      /ecp/y.js
      /rpc/
      /owa/auth/signon.aspx
      /aspnet_client/system_web/.aspx
      IIS Path ex: /aspnet_client/system_web/TInpB9PE.aspx
      File system path ex: C:\inetpub\wwwroot\aspnet_client\system_web\TInpB9PE.aspx
      /aspnet_client/aspnet_iisstart.aspx
      File system path: C:\inetpub\wwwroot\aspnet_client\aspx_iisstart.aspx
      /aspnet_client/aspx_client.aspx
      File system path: C:\inetpub\wwwroot\aspnet_client\aspx_client.aspx
      /aspnet_client/aspnet.aspx
      File system path: C:\inetpub\wwwroot\aspnet_client\aspnet.aspx
      In some cases, additional dynamic link libraries (DLLs) and compiled aspx files are created shortly after the  webshells are first interacted with via POST requests in the following locations:
      
      C:\Windows\Microsoft.NET\Framework64\\Temporary ASP.NET Files\root\
      C:\Windows\Microsoft.NET\Framework64\\Temporary ASP.NET Files\owa\
      3. Next, a command executes, attempting to delete the “Administrator” from the “Exchange Organization administrators” group:
      
      cmd /c cd /d C:\\inetpub\\wwwroot\\aspnet_client\\system_web&net group "Exchange Organization administrators" administrator /del /domain&echo [S]&cd&echo [E]
      4. With the command executed, and the webshell successfully uploaded, interaction with the webshell will begin from a different IP.
      
      We have monitored interaction from 45.77.252[.]175
      5. Following the POST request, multiple commands are executed on the asset:
      
      a. Lsass.exe dumping using procdump64.exe and C:\Temp\update.exe
      (MD5: f557a178550733c229f1087f2396f782):
      
      cmd /c cd /d C:\\root&procdump64.exe -accepteula -ma lsass.exe lsass.dmp&echo [S]&cd&echo [E]
      b. Reconnaissance commands:
      
      whoami.exe
      ping.exe
      tasklist.exe
      quser.exe
      query.exe
      Indicators Of Compromise (IOCs)
      
      Type	Value
      IP Address	165.232.154.116
      IP Address	157.230.221.198
      IP Address	161.35.45.41
      IP Address	45.77.252.175
      IP Address	104.248.49[.]97
      IP Address That Interacts with Uploaded Webshells	194.87.69[.]35
      URL	/ecp/y.js
      URL	/ecp/DDI/DDIService.svc/GetList
      URL	/ecp/DDI/DDIService.svc/SetObject
      URL	/owa/auth/errorEE.aspx
      URL	/owa/auth/logon.aspx
      URL	/owa/auth/errorFE.aspx
      URL	/aspnet_client/aa.aspx
      URL	/aspnet_client/iis
      URL	/iistart.aaa
      URL	/owa/iistart.aaa
      User Agent	python-requests/2.25.1
      User Agent	antSword/v2.1

      Der erste Link am Ende des Rapid7-Beitrag führt zu Microsoft, die weitere technische Analysen gepostet haben. Ich bin in dem Exchange-Zeug nicht unterwegs – aber die Frage: Diese ganzen Informationen helfen nicht weiter?

      Beachte zudem die anderen Artikel – auch zu MSERT – die ich jetzt noch am Artikelende verlinkt habe. Der Defender hilft auch.

  12. Rick sagt:

    Wir hatten anscheinend Glück gehabt. Patch ab Veröffentlichung notfallsmäßig untertags eingespielt (das machen wir sonst *nie*). 2 Stunden nach Abschluss hatten wir schon die ersten Logeinträge. Prüfen jetzt aber dennoch täglich die Server auf Veränderungen im Webroot und den anderen angegebenen Verzeichnissen…

  13. Patrick sagt:

    Ich habe am Wochenende den Patch eingespielt, als ich von der Lücke gehört habe.
    Das Test-Script von Github zeigt an, dass es verdächtige Einträge gibt,
    vom Datum her noch vorm Einspielen des Patch.
    Wenn ich selbst in die Ordner schaue, sehe ich die Dateien nicht. Wurden diese beim Patch installieren gelöscht oder hat der Angreifer dies selbst verschleiert?

    Unser Antiviren Programm (GDATA) und der Microsoft Safetey Scanner finden nichts. Auf dem Server kann ich auch keine neuen Benutzerkonten erkennen und auch verdächtige Prozesse finde ich nicht. Habe ich nun Glück gehabt oder kommt da noch eine Angriffswelle?

  14. Giuseppe sagt:

    Glück gehabt, keines meiner Systeme betroffen.
    Ich setze vor dem Exchange-Server einen Reverse Proxy, da mehrere Web-Anwendungen über eine IP-Adresse erreichbar sein sollen.
    Der Reverse Proxy unterscheidet nach der aufgerufenen URL, und leitet weiter auf die jeweilige Anwendung.
    Bei Anfragen auf die IP-Adresse, weiß der Reverse Proxy nicht wohin damit, und schickt die Anfrage ins Nirvana.
    Gepatcht habe ich natürlich trotzdem…
    Vielleicht eine Anregung für die Zukunft!

    Grüße
    Giuseppe

    • Günter Born sagt:

      Gratulation und danke für die Ergänzung. Ist vielleicht für andere Admins hilfreich – ich selbst habe mit dem Zeugs nichts zu tun. Wäre wohl ein guter Berater geworden (Keine Ahnung von nix, davon aber ganz viel ;-).

    • Christoph sagt:

      Achtung an dieser Stelle: Das hat bei uns leider keinen Unterschied gemacht. 95% der Exchange Server unserer Kunden werden ebenfalls hinter Reverse Proxys betrieben. Leider gab es aber auch bei diesen erfolgreiche Angriffe. Die Logs auf den Exchange Servern zeigen leider teilweise erfolgreiche Kompromittierungen, neu erstellte OAB Verzeichnisse, teilw. .aspx Dateien im Webroot, ein ganz toller Tag heute…

      • Ralf M sagt:

        Hallo,
        hier 2 EX, einmal 2016, einmal 2013. Beide verschont soweit man das prüfen kann.
        Bei beiden:
        ReverseProxy vor OWA, ECP ist nicht erreichbar
        Formbased Authentication
        Keine Chance für die EX-Server ins Internet zu kommen außer SMTP natürlich und URLs, die explizit erlaubt sind.
        Vielleicht ist es ja eine Kombination aus allem oder aber Glück …

      • Manuel sagt:

        Ich kann auch ein neu erstelltes OAB bestätigen und eine supp0rt.aspx Datei unter wwwroot\aspnet_client.
        Wie geht ihr bei der Bereinigung vor? Ich weiß – platt machen und neu installieren wäre natürlich die beste Option, bei der Menge an Infektionen wären das aber viele schlaflose Nächte.
        Meint ihr das löschen und neu erstellen vom OABVirtualDirectory reicht?

  15. No sagt:

    Hier gibt es eine Analyse des Codes von John Hammond: sehr detailliert
    https://www.youtube.com/watch?v=rn-6t7OygGk

  16. DWE sagt:

    Ist eigentlich aktuell schon irgendetwas bekannt, das Exchange Server, die kein OWA / ECP nach extern bereitstellten betroffen sind?
    Angeblich soll ja auch EWS oder ActiveSync ausnutzbar gewesen sein.

  17. Chris sagt:

    Wie kann ich den nun meinen alten SBS 2011 mit Exchangfe 2010 prüfen?
    Ich weiß, der müsste längst weg sein, ist er auch endlich in ein paar Wochen, aber jetzt gibt es ihn eben noch und bis vor einigen Tagen war auch OWA noch frei im Internet erreichbar.

    Mitllerweile nur noch erreichbar von einigen IPs aus (Homeoffice), aber das ist erst seit dem 05.03.2021.

    Also, gibts ein einfaches Verfahren um den ev. hack festzustellen? Auf dem alten Exchange 2010?

  18. Detlef N sagt:

    Hallo,

    es wurden bei einigen Servern folgendes angezeigt:
    [CVE-2021-26855] Suspicious activity found in Http Proxy log!
    Report exported to: C:\Windows\system32\Test-ProxyLogonLogs\EXCHANGE-Cve-2021-26855.csv

    Was ist zu tun ?

    Gruß
    Detlef

  19. Detlef N sagt:

    ich vergaß:

    Please review the following files for ‚Set-*VirtualDirectory‘ entries

    es wurden keine Einträge gefunden.

    Ist man dan clean???

  20. Marko sagt:

    Hallo zusammen,

    Ich habe mehrere Exchange Server zu administrieren, von 2010 bis 2019, alle hinter Reverse Proxy (ohne Pre Auth). Alle Server sind/waren sauber, wurden letzte Woche Freitag/Samstag gepatcht. Wenn ich die Blogartikel von Rapid7 richtig lese, benötigt ein erfolgreicher Angriff Zugriff auf /aspnet_client/… welches bei mir durch den Reverse Proxy gefiltert wird, daher meine Vermutung, dass bei restriktiver RP Konfiguration ein Angriff verhindert wurde.
    Als RP nutze ich pound und Sophos UTM, je nachdem was der Kunde bezahlen kann/möchte.

  21. Frank Carius sagt:

    Nachdem ich nun in zwei Adhoc angesetzten öffentlichen Webcasts quasi überrannt wurde, habe ich ein paar Dinge auf https://youtu.be/dmH5-lVCjwk als Video besprochen und mehr Technik gibt es auf https://www.msxfaq.de/exchange/update/hafnium-exploit.htm

    Hinweis: Das Bild mit den potenziell betroffenen Exchange Servern bezieht sich auf den Feb2021 Security Patch und nicht auf den aktuellen thread. Allerdings: Wer damals schon nicht gepatcht hat, wird auch jetzt wieder dabei sein.

  22. Olli sagt:

    Exchange 2010 hat nur eine der vier Lücken, womit zumindest ein Angriff in der aktuellen Form auf Exchange 2010 nicht funktioniert. Außerdem ganz grundlegend: EX2010 hat kein(!) webbasiertes ECP – das ist aber das nötige Einfalls-Tor von außerhalb.

    Frank Carius hat seinen Blog ja oben verlinkt, da steht das im Detail.

    EX2010 ist also bei diesen aktuellen Angriffen safe – was nichts darüber sagt, wie es mit anderen Lücken bei dem alten Server aussieht.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.