Phänomen: Der RDP-Port verändert sich selbstständig am W2K3 SBS

[fthomma]

Hallo!

Ich hab da gerade etwas, was mich verwundert. Nun weiß ich nicht ob ich auf dem Schlauch stehe und wollte daher mal fragen, ob jemand diesen Effekt kennt:

Es handelt sich um einen etwas betagteren Windows 2003 SBS Server. Dieser erhielt einen Neustart, nachdem seine Diesnte nicht mehr antworten wollten. Danach versuchte ich die Remoteverwaltung zu erreichen. Aber die war nicht mehr da. Auch keine Antort mit Telnet. Ich konnte dann auf anderem Wege eine Verbindung herstellen. Hab Netstat mit Option a in eine Textdatei schreiben lassen. Und siehe da - nichts hörte auf den Port 3389. Ich hab dann mal in die Registry geblickt und nachgesehen, wo der RDP jetzt hört. PortNumber war auf 3366 umgestellt.

Da keiner außer einem Kollegen und mir Zugriff auf die Maschine hat, frage ich mich nun, was da geschehen sein kann. Wir hatten den gleichen Effekt bei der gleichen Maschine schon einmal.

Kennt jemand dieses Verhalten? Was löst es aus? Wie schalte ich es ab?

Danke für die Antworten.

Grüße

[Don_Mega]

Hast du vielleicht irgend ne Remote-Control Software installiert, die dir ggf. den Microsoft RDP Port umgebogen hat?

Cheers

[fthomma]

Hallo Don Mega.

Danke für die Antwort. Dachte schon es interessiert niemanden.

Nein, es keine andere Remotesoftware installiert.

Aber wir haben Fortschritte gemacht. Es fiel auf, dass in den "Geplanten Tasks" ein Eintrag stand, den wir noch nie zuvor gesehen haben. Demnach soll einmal monatlich eine 222.exe ausgeführt werden. Wir haben uns diese 222.exe dann mal genauer angesehen. Es handelt sich um ein verschlüsseltes selbstextrahierendes Archiv, in welchem sich ein tianxia.bat befand. Die kann ich aber nicht herausziehen, weil das Archiv verschlüsselt ist. Den Task haben wir dummerweise gelöscht. Möglicherweise war das PSW dort hinterlegt.

Die Recherche nach 222.exe ergibt viele Hinweise auf verschiedene Trojaner. Die Kombination aus beidem ergibt nur einen Treffer in Russland bei Kaspersky Lab. Wenn man den Text übersetzt, hat ein Russischer Kollege exakt diese Symptome auch festgestellt. Der RDP-Port verändert sich diese unbekannten Dateien sind vorhanden und es werden Tasks geplant, die man nicht kennt.

Wir haben dann nach Dateien gesucht, welche zur ähnlichen Zeiten wie die festgestellte 222.exe Aktivitäten aufwies. In der gleichen Sekunde wurde eine XG.exe erstellt. Die Dateibeschreibung dieser Datei gibt Aufschluss über das Verhalten des Übeltäters.

Beschreibung: modify port for 3389

Firma: Ó¢×ËÃøÂç|Ö÷»úÃùÜ|Ö÷»ú×âÓÃ|ÕØÇìÃùÜ|ïÃûÃùÜ|ÉîÛÚÃùÜ|Ë«ÃßÃùÜ|ÕØÇìµçÃÃ…|ÕØÇìÃøè|Ë«Ãß×âÓÃ|·þÎñÆ÷ÃùÜ|¿Õ¼äÓòÃû|ÃéÄâÖ÷»ú

Dateiversion: 1.0.0.2

Interner Name: 3389

Kommentare: design: bobhe2003@163.com

Originaldateiname: 3389修改器.exe

Produktname: modi3389.exe

Sprache: Chinesisch (VR)

Vorgestern fanden wie wieder einen Eintrag in den "Geplanten Tasks". Es sollte eine bootvrfo.exe ausgeführt werden. Diese fanden wir im Windows-Ordner.

Die bootvrfo.exe enthält eine Bootvrfo.bat. Diese ist unverschlüsselt und sieht wie folgt aus:

net stop skserver

net start skserver

del bootvrfo.bat

Wir haben uns dann mal die Datei angesehen die in den letzen Tagen verändert wurden und fanden eine winhelp64.exe. Ebenfalls ein selbstextrahierendes RAR-Archiv. In diesem Archiv befand sich die die bootvrfo.exe und eine winmls.exe. Weiteres Suchen ergab, dass diese Winhelp64.exe auch in den Profilen auftauchte. Dubioserweise in "Dokumente und Einstellungen\Default User\Lokale Einstellungen\Temporary Internet Files\IE5.Content\HFGESY\". Wer hält schon Cache-Müll für einen neuen User parat? Sie wurde bereits im September 2006 dort abgelegt.

Die winmls.exe ist – wer hätte es gedacht – wieder ein Archiv. Diese enthält einen winmsd.bat.

Dieser weist folgenden Inhalt auf:

@echo off

@sc config Schedule start= auto

@net start Schedule

@at 20:00 /every:1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31 bootvrfo.exe

@del winmsd.bat

@del c:\winhelp64.exe (diese Zeile wiederholt sich dann ca. 100 mal)

Wir haben Avira Server laufen. Trotz maximaler Sucheinstellungen erkennt Avira in diesen Dateien NICHTS. Ich habe die Dateien an Avira übertragen und erhielt ein Email mit dem Hinweis diese Dateien enthielten keine Schadsoftware. Ich hab daraufhin angerufen und die Symptomatik geschildert. Ergebnis: Nichts. Man könne die eine Datei nicht öffnen und in der anderen sei nichts Schadhaftes. Man wolle die Daten an ein Labor übertragen. Andere, ältere Funde welche ich auch übertragen hatte seien Fehlalarme. Ich bin entsetzt über Avira. Von deren Professional Produkten haben wir eigentlich immer viel gehalten.

Auch wenn diese Dateien nicht den endgültigen Hinweis liefern: Ich habe die Symptome und ein Russischer Kollege exakt die gleichen. Viele anderen werden das auch haben, der eine Teil publiziert es nicht, der andere Teil hat es einfach noch nicht bemerkt.

Wir haben dann alle betreffenden Dateien an Virus-Total.com übertragen. Das Ergebnis war komisch: 9 von 43 Virusprodukten erkannten "etwas". Die einen erkannten einen Virus, die anderen erkannten Trojaner. Jeder verwendete einen anderen Namen. Ein Produkt erkannte einen Hupigon-Virus. Den selbigen erkannte Avira in der Datei pDXNpCnT.dll vor einigen Monaten.

Die XG.exe wurde von KEINER Schutzsoftware als Schädling erkannt.

Die anderen Dateien schon, mit folgenden Ergebnissen:

222.exe:

MD5 : aeaaebd338e0bfbff70722b0d7b20ce6

SHA1 : 12eaa488d371d32d96fdcb1efe1929928c5caa13

SHA256: a9734993cd30f8417aba336e5a7544ed1cbd4cee8934d84a9a42aae5e07ad26e

DrWeb 5.0.1.12222 2010.03.17 Trojan.Siggen.25614

K7AntiVirus 7.10.1000 2010.03.17 Non-Virus:

cAfee+Artemis 5923 2010.03.17 Artemis!AEAAEBD338E0

Panda 10.0.2.2 2010.03.17 Bck/Sksocket.H

Prevx 3.0 2010.03.17 Medium Risk Malware

Sunbelt 5938 2010.03.17 Trojan.Win32.Generic!BT

TheHacker 6.5.2.0.236 2010.03.17 Backdoor/Hupigon.dflx

Bootvrfo.exe

MD5 : 2a28af7d20f3c05e5d1477808eed2742

SHA1 : a4fa0c5431a2f01d7bc1e4e39852fef0e0911fa8

SHA256: c0fdb34605207ffd44d3dd3332ccdb5eb2c445075a4834dc2c2660035fb0d815

Comodo 6214 2010.09.27 Heur.Packed.Unknown

Sunbelt 6934 2010.09.27 Trojan.Win32.Generic!BT

SUPERAntiSpyware 4.40.0.1006 2010.09.27 Trojan.Agent/Gen-OnlineGames[Halfhaz]

TheHacker 6.7.0.0.035 2010.09.27 Backdoor/Hupigon.dflx

Winhelp64.exe

MD5 : 2a28af7d20f3c05e5d1477808eed2742

SHA1 : a4fa0c5431a2f01d7bc1e4e39852fef0e0911fa8

SHA256: c0fdb34605207ffd44d3dd3332ccdb5eb2c445075a4834dc2c2660035fb0d815

Comodo 6214 2010.09.27 Heur.Packed.Unknown

eTrust-Vet 36.1.7878 2010.09.27 Win32/MaranPWS!SFX

Sunbelt 6934 2010.09.27 Trojan.Win32.Generic!BT

SUPERAntiSpyware 4.40.0.1006 2010.09.27 Trojan.Agent/Gen-OnlineGames[Halfhaz]

TheHacker 6.7.0.0.035 2010.09.27 Backdoor/Hupigon.dflx

Winmls.exe

MD5 : ae57f0b629bab6fe7c1284aaea182edc

SHA1 : 5d0c8b749bd25991547114062f8c8213c1fd28c9

SHA256: 4b3f52f5ecd1724b96684c4d184cc20546ad785aec05fe20f82b096fa701e595

Sunbelt 6934 2010.09.27 Trojan.Win32.Generic!BT

SUPERAntiSpyware 4.40.0.1006 2010.09.27 Trojan.Agent/Gen-OnlineGames[Halfhaz]

Comodo 6214 2010.09.27 Heur.Packed.Unknown

TheHacker 6.7.0.0.035 2010.09.27 Backdoor/Hupigon.dflx

Gemäß diesem Ergebnis haben wir SUPERAntiSpyware heruntergeladen. Dieser fand mehrere verdächtige Dateien, sowie zwei Registry-Keys. Gleichzeitig haben wir den Stinger von McAffe laufen lassen. Auch dieser hatte zwei Treffer analog zu den Treffern von SuperAntiSpyware – wiederum Hupigon. .

Scheinbar ist die Analytik dieser beiden kostenlosen Tools besser, als die von Avira.

Das Tool zum entfernen bösartiger Software Nov 2010 von Microsoft fand nichts

Ärgerlich ist, dass man Avira eine sehr gute Vorarbeit liefert und man diese gemächlich ignoriert. Zwar meldete sich jemand und es wurde auch ein Ticket geöffnet, aber nur um es mit dem Hinweis, dass man nichts gefunden hat wieder zu schließen. Wie sieht das denn sonst aus, wenn man einen neuen Virus hat. Dann finden die üblichen Tools eben nichts- aber trotzdem ist der Schädling da.

Was ist mit den Symptomen? Sind die dann auch nicht da und wir haben uns diese nur eingebildet?

Und die Hinweise auf die Funktionalität der XG.exe sind auch nur ein Scherz?

Wenigstens hat sich bei AVIRA überhaupt irgendeine Regung gezeigt, bei anderen Herstellern kommt man meist nicht mal bis zum Callcenter. Dass sich der Service von Avira der Tätigkeitslosigkeit ihrer Software anschließt ist allerdings unschön.

Noch eine wichtige Anmerkung:

Während des Rumprobierens fiel meinem Kollegen und mir auf, dass wir den RDP auf Port 3389 nicht mehr mit dem Remotedesktopclient erreichen konnten. Aber eine Verbindung mit TELNET lies irgendetwas antworten, sprich der Bildschirm blieb schwarz. Wir haben dann blödsinnige Zeichen geschickt. Als ein @ kam, brach die Verbindung ab und wir konnten mit Telnet auch keine Verbindung mehr zum Port 3389 herstellen. Wir haben dummerweise keinen Netstat zu diesem Zeitpunkt ausgeführt. Möglichweise hätte man erkennen können, wer da auf dem Port lauscht. Wahrscheinlich wird dieses Vorgehen verwendet um die Windows-Kennwörter bei der RDP-Anmeldung abzufangen.

[Don_Mega]

Oh Oh, das klingt nicht so heiß.

An deiner Stelle würd ich den Server am Wochenende vom Netz nehmen, Daten und Rollen auf einen anderen übertragen (zur Not mit VMWare migrieren) und anschließend den Server neu aufsetzen.

Das wäre mir zu heiß.

Kannst du vielleicht irgendwie nachvollziehen wie du dir hättest was einfangen können? Nicht das du irgenwo im Netz n Leck hast ...

Cheers

[hades]

Sofort den Server vom Netz trennen!

Egal ob da etwas sehr Wichtiges drauf laeuft oder nicht.

Du hast Kenntnis von der Infektion und bist damit fuer Schaeden anderer durch Deinen Server haftbar.

Es hilft aus Sicht der Sicherheit und Kosten/Nutzen nur eine Neuinstallation mit Einspielen des vorher auf Virenfreiheit geprueften Backups.

Und dann hilft das, solche Infektionen zu verringern:

- regelmaessig die Windows Sicherheitsupdates einspielen (Dienst Automatische Updates einschalten, aber bei einem Server die faellige Installation und den notwendigen Neustart ggfl. von automatisch auf manuell aendern)

- eingeschraenkte Userrechte: mit lokalen / Domain-Adminrechten nur dann arbeiten, wenn es wirklich notwendig ist

- nur wirklich benoetigte Software installieren

- regelmaessige Updates fuer alle installierten Anwendungen/Dienste

- alternativen Browser nutzen, der aktive Inhalte nicht sofort oeffnet (z.B. Firefox mit NoScript Addon)

- keine unbekannten Links/Anhaenge anklicken

Bearbeitet 1. Dezember 2010 von hades