[Windows Server] Failed login check. Event ID 4625

[whiteclear]

Vanaf afgelopen dinsdag (monitoring software) merk ik dat er elke dag veel pogingen zijn gedaan om in te loggen via "administrator" Allemaal mislukt. Heb de event viewer ook bekeken maar ik kan nou niet echt meer duidelijkheid krijgen.

Het valt op dat al onze klanten dit "probleem" hebben. Het zijn enkel de domain controllers. Windows SBS 2008, 2011 of STD 2012/2016. Willekeurig. Maar wel alleen de DC's. Het gaat om duizende login attempts.

Wij gebruiken SolarWinds monitoring software om dit soort praktijken te monitoren.
FYI Port 3389 staat dicht.

Heb nog niet veel kunnen vinden. Is dit bij iemand anders ook opgevallen?

Screenshot ter info;

[Dekaasboer]

Dat betekent dat ofwel je netwerk gecompromitteerd is of je hebt je RDP zo staan dat deze vanaf internet bereikbaar is. Dat laatste zou ik asap verhelpen.

Waar staan je servers/ Dc’s? Heb je azure VM’s? Deze worden standaard gedeployed met rdp aan internet

[whiteclear]

Dekaasboer schreef op maandag 10 februari 2020 @ 13:00:
...

Het gaat om on-premis servers. Verschillende klanten, verschillende locaties.
Gaf in mijn post al aan dat 3389 dicht staat op alle servers.

[Endpoint]

En de events staan ook daadwerkelijk op de DC's? geen spook meldingen aangezien iedereen het opeens heeft?

Spit eens in een DC

[Verwijderd]

whiteclear schreef op maandag 10 februari 2020 @ 13:03:
[...]


Het gaat om on-premis servers. Verschillende klanten, verschillende locaties.
Gaf in mijn post al aan dat 3389 dicht staat op alle servers.

Staat de poort extern uit, of intern ook?

[whiteclear]

Endpoint schreef op maandag 10 februari 2020 @ 13:13:
En de events staan ook daadwerkelijk op de DC's? geen spook meldingen aangezien iedereen het opeens heeft?

Spit eens in een DC

Ja de meldingen zijn legitiem. Ik zie ze daadwerkelijk in de event viewer.

Verwijderd schreef op maandag 10 februari 2020 @ 13:20:
[...]

Staat de poort extern uit, of intern ook?

De poort staat niet open op de router. Intern bedoel je in de windows firewall?

[ Voor 28% gewijzigd door whiteclear op 10-02-2020 13:26 ]

[Verwijderd]

Ik denk trouwens dat je hier echt goed op moet zitten want er wordt waarschijnlijk dus door een onbekende continu geprobeerd in te loggen op je servers. Zou ook al je servers eens goed scannen.

[Verwijderd]

whiteclear schreef op maandag 10 februari 2020 @ 13:25:
[...]


Ja de meldingen zijn legitiem. Ik zie ze daadwerkelijk in de event viewer.


[...]


De poort staat niet open op de router. Intern bedoel je in de windows firewall?

Ja. Als je een port forward gebruikt van poort xxx naar poort 3389 staat RDP dus gewoon open voor buitenaf en dat zou heel goed de loginpogingen kunnen verklaren.

Doe anders eens een poortscan met nmap en kijk wat er zoal open staat op je WAN verbinding naar (eventueel) intern.

[The Realone]

Je zegt dat 3389 dicht staat, maar wat staat er dan wel open?

Ik zou zeggen, pak gewoon je firewalls logs erbij. Met die aantallen moet je zo gevonden hebben wie op welke service verbinding wil maken.

[Rensjuh]

Is er niet toevallig een update geweest in je monitoring software die dit gedrag veroorzaakt?

Weet niet welke versie je draait, maar Solarwinds heeft ooit eens een bug gehad die dit soort gedrag veroorzaakte.

[ Voor 57% gewijzigd door Rensjuh op 10-02-2020 13:32 ]

[HyperBart]

Rensjuh schreef op maandag 10 februari 2020 @ 13:31:
Is er niet toevallig een update geweest in je monitoring software die dit gedrag veroorzaakt?

Weet niet welke versie je draait, maar Solarwinds heeft ooit eens een bug gehad die dit soort gedrag veroorzaakte.

Als het in eventvwr ook zichtbaar is dan zijn het wel effectief loginpogingen onder administrator, lijkt me wel heel sterk dat SolarWinds dat doet. Of het door een bug komt of een aanval; in beide gevallen moet het opgelost geraken, dat wel.

whiteclear schreef op maandag 10 februari 2020 @ 12:50:
Vanaf afgelopen dinsdag (monitoring software) merk ik dat er elke dag veel pogingen zijn gedaan om in te loggen via "administrator" Allemaal mislukt. Heb de event viewer ook bekeken maar ik kan nou niet echt meer duidelijkheid krijgen.

Het valt op dat al onze klanten dit "probleem" hebben. Het zijn enkel de domain controllers. Windows SBS 2008, 2011 of STD 2012/2016. Willekeurig. Maar wel alleen de DC's. Het gaat om duizende login attempts.

Wij gebruiken SolarWinds monitoring software om dit soort praktijken te monitoren.
FYI Port 3389 staat dicht.

Defineer "dicht"? Dus het RDP poortje op iedere server staat dicht? Of je blokkeert door segmentering van andere VLAN's en firewalls? Of je blokkeert het extern vanaf het internet?

Heb nog niet veel kunnen vinden. Is dit bij iemand anders ook opgevallen?

Screenshot ter info;
[Afbeelding]

Niks bekend. Aangezien je zegt dat het bij meerdere klanten is vraag ik me af wat je netwerk topologie is? Kan jij van op jouw netwerk doorhoppen naar alle andere klanten via bv. site to site VPN's? Want dan kan het wel eens zijn dat jij/je werkgever de gemene deler is en dat er van bij jullie uit wordt geprobeerd aan te melden bij alle klanten...


@whiteclear als ik de usernames zie in die lijst dan zou ik me nu toch sterk zorgen beginnen maken want dit zijn redelijk "klassiekertjes" qua username om te gaan sprayen/bruteforcen. Tenzij jij ze herkent als usernames die jullie intern ook gebruiken. Ik vrees dat je met een breach zit.

[ Voor 25% gewijzigd door HyperBart op 10-02-2020 13:37 ]

[Rensjuh]

HyperBart schreef op maandag 10 februari 2020 @ 13:33:
[...]


Als het in eventvwr ook zichtbaar is dan zijn het wel effectief loginpogingen onder administrator, lijkt me wel heel sterk dat SolarWinds dat doet. Of het door een bug komt of een aanval; in beide gevallen moet het opgelost geraken, dat wel.


[...]

Solarwinds maakt gewoon gebruik van een Windows (domain) account voor de monitoring om alles uit te lezen.
Mogelijk zit er een bug in de software die inlogpogingen doet die mislukken.

Zie mijn link, daarin word al aangegeven dat dat weleens vaker gebeurd is.

[Verwijderd]

Rensjuh schreef op maandag 10 februari 2020 @ 13:41:
[...]


Solarwinds maakt gewoon gebruik van een Windows (domain) account voor de monitoring om alles uit te lezen.
Mogelijk zit er een bug in de software die inlogpogingen doet die mislukken.

Zie mijn link, daarin word al aangegeven dat dat weleens vaker gebeurd is.

Mja ik vind de screenshot die er bij geplaatst wordt niet rijmen met hetgeen jij vertelt. Ook kan ik überhaupt niet opmaken uit het artikel dat er wordt ingelogd met administrator

In the DC Security logs report, SolarWinds attempted to log in to a server as OrionHostName$. The credentials do not provide any information.

Het zou fijn zijn als het een software bugje is eerlijk gezegd. Maar vooralsnog klinkt dit als een groter probleem.

[Rensjuh]

Verwijderd schreef op maandag 10 februari 2020 @ 13:46:
[...]
Mja ik vind de screenshot die er bij geplaatst wordt niet rijmen met hetgeen jij vertelt. Ook kan ik überhaupt niet opmaken uit het artikel dat er wordt ingelogd met administrator

Je kunt bij Solarwinds per klant aangeven onder welk account de monitoring software moet draaien.
Normaal gesproken maak je een apart user account aan voor de monitoring, maar ik heb (bij mijn vorige baan) ook vaak genoeg (lees: zo'n beetje altijd) meegemaakt dat dit gewoon onder Administrator draait.

Dit verklaard echter niet waar de overige accounts vandaan komen die pogen in te loggen.

[whiteclear]

Verwijderd schreef op maandag 10 februari 2020 @ 13:28:
[...]

Ja. Als je een port forward gebruikt van poort xxx naar poort 3389 staat RDP dus gewoon open voor buitenaf en dat zou heel goed de loginpogingen kunnen verklaren.

Doe anders eens een poortscan met nmap en kijk wat er zoal open staat op je WAN verbinding naar (eventueel) intern.

Poortscan met nmap: 1723, 443 en 80. Meer niet.

Rensjuh schreef op maandag 10 februari 2020 @ 13:31:
Is er niet toevallig een update geweest in je monitoring software die dit gedrag veroorzaakt?

Weet niet welke versie je draait, maar Solarwinds heeft ooit eens een bug gehad die dit soort gedrag veroorzaakte.

Hier dacht ik direct ook aan. Vandaar dat ik ook meld dat wij SolarWinds gebruiken. Maar dan lijkt het mij dat de fail attempts ook voor moeten komen bij de andere servers, de "niet" domain controllers. Die worden ook gemonitord.

Ter info screen uit event viewer dat het daadwerkelijk om "administrator" gaat

[ Voor 6% gewijzigd door whiteclear op 10-02-2020 13:54 ]

[Verwijderd]

whiteclear schreef op maandag 10 februari 2020 @ 13:48:
[...]


Poortscan met nmap: 1723, 443 en 80. Meer niet.


[...]


Hier dacht ik direct ook aan. Vandaar dat ik ook meld dat wij SolarWinds gebruiken. Maar dan lijkt het mij dat de fail attempts ook voor moeten komen bij de andere servers, de "niet" domain controllers. Die worden ook gemonitord.

Zou je willen vertellen wat voor opties je hebt gebruikt in je scan? Eventueel wil ik de scan ook voor je doen. Je kunt mij een DM sturen.

[ Voor 6% gewijzigd door Verwijderd op 10-02-2020 13:58 ]

[whiteclear]

Verwijderd schreef op maandag 10 februari 2020 @ 13:54:
[...]
Zou je willen vertellen wat voor opties je hebt gebruikt in je scan? Eventueel wil ik de scan ook voor je doen. Je kunt mij een DM sturen.

Online tool van pentest-tools. Alle 100 ports.


Nieuwe info: Het lijkt erop dat het allemaal VPN login attempts zijn.

Authentication Details:
Connection Request Policy Name: Microsoft Routing and Remote Access Service Policy
Network Policy Name: -
Authentication Provider: Windows
Authentication Server: server01.verborgen.local
Authentication Type: MS-CHAPv2
EAP Type: -
Account Session Identifier: 3233343031
Logging Results: Accounting information was written to the local log file.
Reason Code: 16
Reason: Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.

[wagenveld]

Aangezien poort 1723 voor (PPTP) VPN is, is dat niet zo vreemd dan. Waarom staat dit aan op een DC?

[whiteclear]

wagenveld schreef op maandag 10 februari 2020 @ 14:19:
Aangezien poort 1723 voor (PPTP) VPN is, is dat niet zo vreemd dan. Waarom staat dit aan op een DC?

Is dat niet goed dan? Een aantal klanten hebben "slechts" 1 server en die willen VPN kunnen maken om bestanden te benaderen.

[Verwijderd]

whiteclear schreef op maandag 10 februari 2020 @ 14:09:
[...]


Online tool van pentest-tools. Alle 100 ports.


Nieuwe info: Het lijkt erop dat het allemaal VPN login attempts zijn.

Authentication Details:
Connection Request Policy Name: Microsoft Routing and Remote Access Service Policy
Network Policy Name: -
Authentication Provider: Windows
Authentication Server: server01.verborgen.local
Authentication Type: MS-CHAPv2
EAP Type: -
Account Session Identifier: 3233343031
Logging Results: Accounting information was written to the local log file.
Reason Code: 16
Reason: Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.

PPTP VPN wordt als onveilig gezien. Beter zou SSTP VPN zijn of een ander soort VPN verbinding.

De poort scan die je gebruikt hebt scant trouwens alleen de meest bekende poorten. Er zijn er echter een stuk meer. Daarom raad ik nog steeds aan op nmap te gebruiken of een andere tool die meer dan slechts 100 poorten kan scannen.

PPTP loginpogingen klinken aannemelijk maar het lijkt mij toch wel een fijn idee om goed in kaart te brengen wat er nu zoal open staat in je netwerk naar buiten toe.

[HyperBart]

whiteclear schreef op maandag 10 februari 2020 @ 14:32:
[...]


Is dat niet goed dan? Een aantal klanten hebben "slechts" 1 server en die willen VPN kunnen maken om bestanden te benaderen.

Eh, neen niet echt. Dit kan heel wat problemen opleveren mbt multihoming en DNS. Dat doe je beter op een member-server.

Dat MS ooit besloten heeft om snoeihard tegen de eigen guidelines in te gaan en het gedrocht wat SBS heet in de markt te zetten (lovely... Exchange en een DC op één machine en dan nog wat rollen er bij) draagt er niet toe bij dat men deze praktijk eigenlijk niet zou mogen toepassen, helaas zie je het nog wel vaak bij KMO's...

[Verwijderd]

whiteclear schreef op maandag 10 februari 2020 @ 13:48:
[...]


Poortscan met nmap: 1723, 443 en 80. Meer niet.


[...]


Hier dacht ik direct ook aan. Vandaar dat ik ook meld dat wij SolarWinds gebruiken. Maar dan lijkt het mij dat de fail attempts ook voor moeten komen bij de andere servers, de "niet" domain controllers. Die worden ook gemonitord.

Ter info screen uit event viewer dat het daadwerkelijk om "administrator" gaat
[Afbeelding]

Als je zo'n event vanuit je screenshot neemt, en je scrollt een beetje naar beneden zie je ook een kopje met "network information" normaalgezien. En daarbij staat dan source network address en port.

Dit zou je toch moeten vertellen van waar de brute force komt?

[whiteclear]

Aanvallen van IP 176.113.115.102 en 176.113.115.101

https://blackhat.directory/ip/176.113.115.102

Zijn wel meerdere meldingen van de laatste dagen..

[ Voor 50% gewijzigd door whiteclear op 11-02-2020 11:02 ]

[kroegtijger]

Gebruik anders even een tooltje zoals bijvoorbeeld RDP Defender. Na x aantal mislukte inlogpogingen binnen x uur wordt het betreffende IP in de firewall toegevoegd met een deny op alle services. Let wel op dat je jezelf eventueel whitelist indien nodig

Dan hou je in ieder geval de boosdoeners vrij snel buiten de deur, en kan je daarna op zoek gaan naar wat er nu precies mis gaat dat je zo aangevallen wordt.

[whiteclear]

Probleem is opgelost door het IP adres te blocken. Ondertussen ga ik kijken naar een veiligere VPN protocol.

Dank voor jullie reacties

[ Voor 11% gewijzigd door whiteclear op 12-02-2020 08:44 ]

[McWolf82]

Poort 1723 kun je beter dichtzetten, ik zie dat ook nog bij een aantal klanten van ons dat zetten we meteen dicht, dan maar even geen VPN.
Je hebt dan wel een IP-adres geblokkeerd, maar dan probeert iemand het wel weer vanaf een ander IP-adres.
Ze scannen het internet af op zoek naar veel gebruikte standaard poorten.

In de RRAS logs zien we veel meldingen met vreemde gebruikersnamen zoals admin, 1111, vpn, van alles, wat niet voor komt in Active Directory.

Op de server waarop Routing and Remote Access draait kun je het ook zien in de logs, C:\Windows\System32\LogFiles en dan open je het meest recente log wat begint met IN en eindigt op .log

[ Voor 16% gewijzigd door McWolf82 op 12-02-2020 16:39 ]