5 jel hogy a Windows szervered RDP brute force támadás alatt áll

A legtöbb rendszergazda ugyanúgy szembesül egy RDP brute force támadással: hétfő reggel olvassa el a ransomware üzenetet. Addigra a támadó már órák vagy napok óta bent van, és a takarítás többe kerül, mint bármilyen megelőző intézkedés.

A Mandiant M-Trends 2026 jelentés szerint a kezdeti hozzáféréstől a támadó kezelői tevékenységéig eltelt idő mediánja 8 óráról (2022) körülbelül 22 másodpercre (2025) zuhant. Ha a hitelesítő adatok elesnek, az automatizáció szinte azonnal átveszi az irányítást. A felismerésnek korábbi és ellenőrizhető lépéseken kell alapulnia.

Ez a cikk 5 konkrét jelet mutat be arról, hogy a szervered most támadás alatt áll, PowerShell ellenőrzésekkel és Event Viewer útvonalakkal, amiket a következő 10 percben le tudsz futtatni. Ha kettő vagy több illik a saját helyzetedre, kezeld aktív incidensként. A háttérről bővebben az RDP brute force támadás bevezető cikkünk ír.

Több ezer sikertelen bejelentkezést látsz?

A legtisztább jelzés a Security log-ban özönlő Event ID 4625 (sikertelen bejelentkezés) bejegyzések tömege. Egy egészséges, belső Windows szerveren a baseline napi 50 alatt van, és többnyire elfelejtett jelszókból vagy elavult service account-okból jön. Egy kitett, aktívan brute force-olt szerver napi több ezernél tart, vagy annál is többnél.

Referenciaként: Jeffrey Appel kutató publikus Microsoft Sentinel honeypot projektje 7 nap alatt 209,335 sikertelen logint rögzített egy kitett tesztgépen, ez napi nagyjából 30,000. Ha a saját számaid ebben a tartományban vannak, az nem felhasználói tévedés.

Az ellenőrzéshez nyisd meg az Event Viewer-t, lépj a Windows Logs → Security alá, és szűrj Event ID 4625-re. Vagy futtasd ezt egy emelt jogú PowerShell-ből:

Get-WinEvent -FilterHashtable @{LogName='Security';Id=4625;StartTime=(Get-Date).AddDays(-7)} | Measure-Object

Egy belső szerveren 7 nap alatt 1,000 fölött gyanús. Napi 1,000 fölött egyértelmű támadási minta. Az esemény teljes sémáját a Microsoft az Event 4625 referenciában dokumentálja, mezőről mezőre pedig az Event ID 4625 cikkünkben írunk.

Lassú az RDP login és pörög az LSASS CPU-ja?

Minden hitelesítő ellenőrzést a Windows az LSASS (Local Security Authority Subsystem Service) folyamatban dolgoz fel, és minden ilyen ellenőrzés CPU-t fogyaszt. Egy normál RDP login 5-10 másodperc alatt befejeződik. Amikor több ezer brute force próbálkozás érkezik párhuzamosan, az LSASS telítődik, és a valódi felhasználók ezt érzik.

A tünet jellemzően ez: az RDP hirtelen 30-60 másodpercig is eltart, amíg eléri az asztalt, a credential prompt akadozik, és a Task Manager szerint az LSASS folyamatosan 5% fölött CPU-t használ egy egyébként tétlen szerveren. Üres workload mellett az LSASS általában 1% alatt szokott lenni.

Nyisd meg a Task Manager-t, váltsd át a Details fülre, és rendezd CPU szerint. Ha az lsass.exe folyamatosan a tetején áll, az hálózat felől érkező munkaterhelés. Egy kitett szerveren ez szinte mindig olyan hitelesítési forgalom, amit nem te indítottál.

Random fiókzárolások jelennek meg?

Ha a domain-en be van kapcsolva az Account Lockout Policy, a valódi felhasználóneveket próbálgató támadó előbb-utóbb átlépi a küszöböt. A mellékhatás az, hogy valódi felhasználók a legrosszabb pillanatokban kerülnek ki a saját fiókjukból, gyakran egyszerre több is.

A HelpDesk csapat ezt hirtelen lockout-ticket csúcsként látja, amit nem magyaráz sem deploy, sem jelszóváltás, sem szabadságolás. A Security log-ban ez Event ID 4740-ként (a felhasználó fiókja zárolva) jelenik meg. Egészséges hálózaton a 4740 eseményeknek ritkának kell lenniük. Napi 10 fölött, főleg ha különböző fiókokat érint, az erős jele aktív credential spraying-nek.

A Microsoft Event 4740 dokumentációja megmutatja, hol szerepel a forrás workstation neve, ami gyakran a támadó hosztra mutat. Az Account Lockout Policy referencia leírja, hogyan állítsd be a küszöböket úgy, hogy ne zárd ki az egész szervezetet.

Megjelent egy admin vagy lokális fiók, amit nem te hoztál létre?

Ezt a jelet senki nem akarja látni. Ha új lokális felhasználó, vagy ami rosszabb, új tag jelent meg a helyi Administrators csoportban, és nem te hoztad létre, akkor a támadás már sikerült. A brute force fázisnak vége, a támadó perzisztenciát épít.

Futtasd ezt PowerShell-ből, és nézd meg, kik a jelenlegi helyi adminok:

net localgroup administrators

Utána ellenőrizd a Security log-ot Event ID 4720-ra (felhasználói fiók létrehozva) és Event ID 4732-re (új tag biztonsági csoportban). A Microsoft mindkettőt részletesen dokumentálja: Event 4720 és Event 4732. Bármi, ami nem illeszkedik egy change ticket-re vagy egy ismert admin akcióra, megerősített kompromittáció jele.

Ha ezt látod, ne kezdd jelszót cserélni a futó gépen. Először izoláld a szervert a hálózatról (vedd ki a VLAN-ból vagy blokkold a tűzfalon), mentsd le a Security és System eseménynaplókat, és kezeld incidensként. A hitelesítő, ami beengedte őket, valószínűleg eleve kitalálható volt — ezért is jön elő rendszeresen a mennyi ideig tart feltörni egy gyenge jelszót RDP-n cikkünk. A CISA Stop Ransomware oldalán innentől kezdve hasznos post-compromise útmutatás található.

Furcsa időpontokban indulnak RDP session-ök?

A támadók ritkán jelentkeznek be munkaidőben. A Sophos 2025 Active Adversary Report szerint az áldozatok munkaidején kívül történt a ransomware bevetések 83%-a, a hétvége és a hajnali órák kifejezett kedvencek. Ha a szerveredet csak irodai dolgozók használják, de az Event ID 4624 vasárnap hajnal 3-kor sikeres RDP logint mutat, valami nem stimmel.

A Microsoft Event 4624 referenciája leírja a logon type mezőt, ami a leghasznosabb szűrési alap. A 10-es logon type a RemoteInteractive (RDP). A heti munkaidőn kívüli RDP loginok listázásához:

Get-WinEvent -FilterHashtable @{LogName='Security';Id=4624;StartTime=(Get-Date).AddDays(-7)} |
  Where-Object { $_.TimeCreated.Hour -ge 22 -or $_.TimeCreated.Hour -le 6 }

Néhány esti karbantartási login egy ismert admintól rendben van. Egy mintázat éjszakai loginokból olyan fiókokról, amik egyáltalán nem szoktak RDP-t használni, nincs rendben.

Mit tegyél most azonnal?

Öt Event ID lefedi a kép nagy részét: 4625 (sikertelen login), 4624 (sikeres login), 4740 (fiókzárolás), 4720 (fiók létrehozása), 4732 (admin csoport módosítás). Ha a monitoringod ezt az ötöt figyeli, a legtöbb brute force aktivitás láthatóvá válik még a sikere előtt.

Az alábbi akcióterv sürgősség szerint épül fel. Felülről lefelé haladj; ne hagyd ki az 5 perces lépéseket csak azért, hogy a hosszú távúakra ugorj.

Azonnal (5 perc):

1. Kapcsold be az Account Lockout Policy-t Group Policy-ban, ha még nincs élesben. A hivatalos policy referencia biztonságos küszöbértékeket javasol.
2. Engedélyezd a Network Level Authentication-t (NLA) az RDP hoszton. Ez teljesen blokkolja a pre-auth brute force-ot.
3. Nevezd át az alapértelmezett Administrator fiókot. Ezzel kiveszed a leggyakrabban próbált felhasználónevet az egyenletből.

Ma (1 óra):

4. Korlátozd az RDP-t a Windows Firewall-ban az ismert IP tartományokra (iroda, VPN gateway, jump host).
5. Tegyél erős, egyedi jelszót minden admin fiókra. A mennyi ideig tart feltörni egy gyenge jelszót RDP-n cikkünk megmutatja, miért fontosabb a hossz, mint a komplexitás.
6. Hozz be MFA-t, ahol a környezet támogatja (Duo, Microsoft Authenticator, vagy RD Gateway feltételes hozzáféréssel).

Ezen a héten:

7. Telepíts automatikus IP blokkoló eszközt, ami az Event 4625-öt figyeli és bannolja a visszatérő támadókat. A 2026-os RDP brute force védelem útmutatónk végigmegy a kategórián. A BruteFence egy lehetőség ebben a térben, és 7 napos ingyenes próbát ad, ami körülbelül 5 perc alatt települ.
8. Tervezz réteges védelmet egyetlen eszközön túl. A teljes lista a Windows Server biztonsági checklist 2026 cikkünkben van.

Hogyan tudod gyorsan ellenőrizni, mennyire súlyos a helyzet?

Ha a PowerShell parancsok futtatása a Security log ellen sok egy hétfő reggelhez, az ingyenes BruteFence Checker GitHub eszköz ugyanezt elvégzi nagyjából 30 másodperc alatt. Beolvassa a helyi Security log-ot, visszanéz 30 napra, és kiírja a teljes sikertelen próbálkozások számát, a top 10 támadó IP-t és napi bontást.

Futtasd egyszer, nézd meg a napi számokat, és dönts. Ha a Checker napi 50 alatt mutat, normál baseline-on vagy. Ha napi 1,000 felett, akkor aktív kampány zajlik a szerver ellen, és a kézi blokklistás megközelítés nem fogja bírni. A BruteFence 7 napos ingyenes próba automatizálja a blokkolást és körülbelül 5 perc alatt települ, de a Checker kimenete BruteFence telepítése nélkül is hasznos.

Az őszinte verzió: a legtöbb tűzfal és VPN mögötti Windows szerver soha nem találkozik ezekkel a jelekkel. Akik igen, általában közvetlenül a 3389-es porton vannak kitéve, gyakran véletlenül, gyakran évek óta. Ha akár csak egy a fenti 5 jel közül illik a mai helyzetedre, a következő 24 óra többet számít, mint a következő negyedév roadmap-je.