wp-login.php je jeden z nejznámějších souborů ve WordPress. Přes něj se standardně přihlašujete do administrace, takže je dlouhodobě oblíbeným cílem brute force útoků. Pojďme se podívat na data z logů WEDOS Global Protection.
Pro účely dnešního článku, jsme vybrali pouze blokované requesty, které v URL obsahovaly wp-login.php a pouze z domén, které jsou chráněné službou WEDOS Global Protection. Data jsou za 24 hodin – pondělí 04.05.2026.
Možná to některé z vás překvapí, ale útočníci často vůbec neřeší, jestli na cílové doméně WordPress opravdu běží. Prostě to zkusí. A když to nevyjde v hlavním adresáři, zkusí jinou cestu. A potom další. A další.
Za 24 hodin jsme v čistě blokovaném provozu viděli:
- 133 523 hostů*
- 51 aktivních PoP lokalit, přes které provoz šel
- 9 923 unikátních IP adres
- 4 362 672 blokovaných requestů
* nemusí se jednat o skutečnou doménu anebo subdoménu, útočníci to rádi zkouší
A to je jen provoz, který byl zablokovaný. Řada zákazníků má navíc ochranu wp-login.php vypnutou či omezenou, případně mají na whitelistu útočící IP adresy. Tyto v statistikách tedy nejsou. Reálně pokud bychom blokovali vše přibylo by dalších zhruba 500 tisíc requestů.
Jeden den blokovaného provozu na wp-login.php
Na prvním grafu je vidět součet blokovaných requestů po třicetiminutových intervalech.
wp-login.php za 24 hodin. Graf ukazuje součet blokovaných requestů v třicetiminutových intervalech napříč weby chráněnými přes WEDOS Global Protection.Na první pohled je tam vidět jedna výrazná špička kolem poledne. To byl velký nárůst blokovaného provozu, který na úrovni celkového grafu vypadá jako jeden dominantní brute force útok.
Jenže když se na data podíváme podrobněji, tak je vidět, že to není jen jeden jednoduchý typ útoku.
To je u podobných dat důležité. Když se člověk dívá jen na agregovaný graf, snadno získá pocit, že stačí najít jeden problém a napsat jedno pravidlo. Jenže v reálném provozu se většinou míchá více věcí najednou.
Něco je čistý brute force. Něco je skenování. Něco je hledání WordPressu. Něco jsou pokusy trefit nestandardní cestu. Něco je provoz, který už narazil na rate limit. A něco je obecně podezřelé chování, které nedává smysl řešit izolovaně jen podle jedné URL.
WEDOS Global Protection obsahuje více než 100 pravidel. Desítky z nich jsou dynamické a přizpůsobují se aktuálnímu provozu i chování útočníka. K tomu se přidávají různé rate limity, které sledují chování konkrétní IP adresy, provoz na konkrétní doménu, JA4/JA4H fingerprinty a další signály. Výsledkem je, že robot hledající zranitelnosti může udělat pár pokusů na několika webech, ale na další tisíce už se nedostane.
Nešlo jen o brute force
Druhý graf ukazuje rozpad podle důvodů blokace.
Za celý den vypadaly největší důvody blokace takto:
| Důvod blokace | Requesty |
|---|---|
| Detekována útoční signatura na citlivý soubor WordPress | 669 103 |
| Brute force útok | 538 644 |
| Známý scanner zranitelnosti podle JA4 signatury | 514 441 |
| Rate limit (IP na greylistu) | 333 045 |
| Dosažen hodinový limit pro greylistované IP přes port 80 | 262 403 |
| Vysoký rate limit, posláno PoW challenge | 248 405 |
| Podezřelý GET request na citlivý WP soubor | 201 714 |
| Překročení rate limityu | 117 753 |
| Podezřelá JA4 signatura, posláno PoW challenge | 83 085 |
| Podezřelý signál v GET request na citlivý WP soubor | 76 895 |
| Překročen limit na IP za 1 vteřinový interval (IP na přísnějším greylistu) | 38 118 |
| Nepoužívaný useragent | 31 155 |
| Podezřelá signatura v GET požadavku (generický web) | 4 073 |
| Další více jak stovka různých pravidel a ratelimitů | 1 243 838 |
Tady je dobře vidět, proč se na podobný provoz nedá dívat jen jako na „útok na WordPress login“.
Ano, část provozu jsou brute force pokusy. Ale velká část je něco jiného (zvláště když na webu žádný WordPress není). Nemůžete je prostě tolerovat a nechávat si zbytečně přetěžovat servery. Vše prověřujeme a hledáme hlavně scannery zranitelností a podezřelé GET requesty.
Ale zpět k WordPress. V praxi to znamená, že jeden útočný scénář může vypadat třeba takto:
- Bot zkusí najít
wp-login.php. - Vyzkouší více cest.
- Pokud něco odpovídá, začne posílat další requesty.
- Pokud najde login formulář, může přejít na POST.
- Při vyšší aktivitě narazí na rate limit.
- Podle chování klienta, TLS fingerprintu, HTTP fingerprintu nebo dalších znaků může spadnout i do jiných pravidel. Často se tak na
wp-login.phpani nemusí dostat.
Na grafu potom nevidíme jeden útok. Vidíme směs automatizovaného provozu, který se v různých fázích zachytává různými částmi ochrany.
U brute force útoků se běžně používají rate limity. Jenže proč útočníka nechat udělat několik zbytečných pokusů, které zatěžují server, když jej můžeme odhalit dříve podle nepoužívaného User-Agentu, JA4/JA4H fingerprintu nebo jiného podezřelého signálu?
GET hledá, POST zkouší
Zajímavé je i rozložení podle HTTP metod.
| Metoda | Requesty | Unikátní IP |
|---|---|---|
| GET | 2 785 506 | 6 397 |
| POST | 1 535 106 | 5 469 |
| HEAD | 111 | 68 |
GET requestů bylo za den výrazně více než POST requestů.
To odpovídá tomu, jak podobné automatizované útoky většinou fungují. GET je často fáze hledání. Bot si ověřuje, jestli daná cesta existuje, jestli server odpovídá, jestli vrací něco zajímavého a jestli má smysl pokračovat dál.
POST už je zajímavější. U wp-login.php typicky znamená, že se někdo pokouší něco odeslat do přihlašovacího formuláře. Tedy například kombinaci uživatelského jména a hesla. Ale může to být i něco jiného.
HEAD requestů bylo minimum. V těchto datech nehrají prakticky žádnou roli.
Tady je dobré připomenout jednu věc. Když někdo vidí miliony requestů na wp-login.php, nemusí to automaticky znamenat miliony pokusů o zadání hesla. Část provozu je samotné hledání. Část je ověřování. Část jsou scannery. A až část jsou skutečné pokusy o login.
I tak je to ale problém. Protože i samotné hledání zatěžuje infrastrukturu. Request musí přijít, musí se zpracovat, musí se rozhodnout, co s ním, a ideálně se nesmí dostat až na backend zákazníka.
Útočníci nehledají jen /wp-login.php
Nejvíce requestů šlo podle očekávání na klasickou cestu (2 432 655 requestů):
/wp-login.phpTo ale není celé. V datech se objevovala i řada dalších cest:
/wp-includes/images/wp-login.php
/wp-admin/css/wp-login.php
/wp-includes/css/dist/preferences/wp-login.php
/wp-admin/wp-login.php
/wp-admin/js/wp-login.php
/.well-known/acme-challenge/wp-login.php
/wp-content/plugins/classic-editor/wp-login.php
/wp-includes/Requests/library/wp-login.php
/wp-includes/js/imgareaselect/wp-login.php
/wp-includes/l10n/wp-login.php
/wp-includes/html-api/wp-login.php
/wp-admin/css/colors/ocean/wp-login.php
/wp-content/themes/bltm/wp-login.php
/wp-includes/certificates/wp-login.php
/wp-includes/js/tinymce/skins/lightgray/img/wp-login.php
/wp-includes/images/media/wp-login.php
/js/wp-login.php
/wp-content/plugins/wp-login.php
/wp-admin/css/colors/midnight/wp-login.phpTohle je na celé věci možná nejzajímavější.
Kdyby šlo jen o pokus přihlásit se do WordPressu, člověk by čekal hlavně /wp-login.php. Jenže tady vidíme i cesty, které na první pohled nedávají smysl.
Proč by někdo hledal wp-login.php například tady?
/wp-admin/css/wp-login.phpNebo tady?
/.well-known/acme-challenge/wp-login.phpJedno z pravděpodobných vysvětlení je, že v těchto případech útočníci nehledají skutečný přihlašovací formulář WordPressu. Hledají soubor pojmenovaný wp-login.php, který může být ve skutečnosti backdoor.
wp-login.php je známý název legitimního WordPress souboru. Právě proto se může hodit i útočníkům. Když se jim podaří kompromitovat WordPress, mohou si do něj uložit vlastní soubor se stejným nebo podobně důvěryhodně vypadajícím názvem. Ne do hlavního adresáře, kde by byl více na očích, ale někam hlouběji do struktury webu. Třeba mezi obrázky, CSS, pluginy nebo jiné soubory WordPressu.
Z pohledu běžného správce webu to pak může na první pohled vypadat méně podezřele. A z pohledu některých bezpečnostních pravidel může být název wp-login.php navíc problematický tím, že jde o běžný soubor WordPressu. Některé ochrany proto k podobným požadavkům mohou přistupovat opatrněji, aby nerozbily legitimní přihlášení do administrace.
Útočníci to vědí.
Na WordPress dnes ve velkém neútočí člověk ručně. Dělají to automatizované skripty. Hledají známé zranitelnosti, zkouší slabá hesla, testují pluginy, staré instalace, špatná oprávnění a známé cesty. Když se útok povede, malware si často vytvoří perzistenci, tedy způsob, jak se do webu dostat znovu i po částečném odstranění původní zranitelnosti Typicky právě přes backdoor.
A tady přichází další zajímavá věc. Tyto backdoory potom nehledá jen původní útočník. Hledají je i další boti. Pokud je někde na internetu už kompromitovaný WordPress s backdoorem, jiný útočník se ho může pokusit najít a převzít.
Jinými slovy: jeden útočník web napadne, druhý se pokusí využít jeho zadní vrátka.
Z pohledu útočníka to dává smysl. Request je levný. Když jich pošle miliony, stačí mu velmi malé procento úspěchu.
Z pohledu ochrany je to ale přesně ten typ provozu, který nechceme pouštět dál. Backend zákazníka nemá řešit, že někdo zkouší najít soubor pojmenovaný wp-login.php v adresáři s obrázky, CSS, pluginy nebo ACME challenge.
Část provozu je koncentrovaná, ale pořád rozprostřená
Podívali jsme se také na ASN, ze kterých blokovaný provoz přicházel.
Největší zdroje podle počtu requestů:
| ASN | Requesty | Unikátní IP |
|---|---|---|
| AS31898 | 817 010 | 118 |
| AS8075 | 432 664 | 151 |
| AS41564 | 323 397 | 39 |
| AS215930 | 295 653 | 13 |
| AS206092 | 293 033 | 952 |
| AS42708 | 172 741 | 66 |
| AS14061 | 143 525 | 601 |
| AS396356 | 123 007 | 395 |
| nezjištěno | 118 301 | 1 516 |
| AS154247 | 76 775 | 11 |
Část provozu byla silně koncentrovaná. Některá ASN poslala za den stovky tisíc requestů. Zároveň ale celý provoz přicházel z 9 923 unikátních IP adres.
Blokace celého ASN může v některých případech pomoct. Ale ve sdílené infrastruktuře je to zásah, který může mít vedlejší dopady. V jednom ASN může být útočný provoz, ale také legitimní uživatelé, firemní sítě, VPN, cloudové služby, monitoring nebo různé automatizované systémy.
Proto je lepší pracovat s více signály najednou. Nejen odkud request přišel, ale také co přesně chce, jak často to chce, jak se chová, jaký má fingerprint, jaký má User-Agent, jestli opakuje stejné vzory, jestli se snaží přistupovat na citlivé cesty a jestli už dříve vykazoval podezřelé chování.
Například i velice problémovou IP můžete pustit na web pokud projde přes Proof of Work challenge.
Nicméně pokud máte u WEDOS Global Protection alespoň plán Expert, tak máte přístup k řadě nástrojů jako jsou třeba Combo rules a s těmi si velice snadno můžete řídit provoz pomocí komplexních podmínek. Ať už se jedná o whitelites, blacklist anebo třeba nasazení Proof of Work.
Běžný internetový šum, který ve velkém už běžný není
Těchto 4,3 milionu blokovaných requestů nebyl žádný výjimečný incident, který by sám o sobě znamenal nějaký zásadní problém. Je to spíš ukázka toho, jak dnes vypadá běžný automatizovaný provoz na internetu.
Vlastně to bylo celkem klidné pondělí. Za den evidujeme i 10x větší provoz pokud se objeví nějaká zranitelnost WordPress anebo velký únik dat.
Nicméně i když se nic neděje, tak každý den, doslova každou vteřinu boti hledají WordPress. Hledají administrace. Hledají staré instalace. Hledají zapomenuté soubory. Hledají cokoliv, co by mohlo odpovědět.
A neřeší, jestli na dané doméně WordPress opravdu běží. Provoz prostě pošlou a pokud nestudujete serverové logy, tak o tom ani netušíte. Váš web je jen pomalejší a vy netušíte proč.
Úkolem ochrany WEDOS Global Protection je, aby se takový provoz ideálně vůbec nedostal k vašemu serveru. Aby zbytečně nezatěžoval webhosting, VPS, dedikovaný server nebo aplikaci. A aby se legitimní uživatel dostal tam, kam má, zatímco automatizovaný odpad skončil co nejdříve na hraně sítě.