Phishing jménem domain.cz: co odhalila analýza podvrženého e-mailu

Infografika znázorňující phishingový e-mail s podvrženou adresou support@domain.cz, cestu zprávy od útočníka k příjemci a chybějící ochranu SPF a DMARC.
13min čtení

Rozbor dvou phishingových e-mailů, z nichž jeden podvrhl adresu support@domain.cz: co ukázaly hlavičky, co chybělo v DNS domény a jak nastavit SPF, DKIM a DMARC u vlastní domény.

10.11.2026 ve 13:09 přišel na adresu support@agencjezatrudnienia.pl e-mail od Noreply <support@domain.cz>. Psalo se v něm, že neprošla automatická platba, služby pro doménu agencjezatrudnienia.pl jsou pozastavené a obnovit je lze ručně přes tlačítko „Zobrazit fakturu“. Tlačítko ale nevedlo k žádnému registrátorovi. Mířilo do složky wp-content na cizím webu northwoodpark.co.uk. O 45 minut později dorazil druhý e-mail se stejným textem, jen z jiné adresy a s jiným odkazem.

Schránka běží na poštovním serveru, který provozujeme. Antispam oba e-maily doručil. Podívali jsme se proto na hlavičky, na DNS domény domain.cz i do registru CZ.NIC. Doménu drží ACTIVE 24, s.r.o. Firma potvrdila, že e-mail neodeslala, a hlavičky to potvrzují. Doména ale neměla v DNS záznamy DMARC ani SPF, podle kterých přijímající servery poznají podvrh spolehlivěji než podle obsahu zprávy. ACTIVE 24 o tom ví od 10.11. a do zveřejnění tohoto rozboru se na tom nic nezměnilo.

Šablona, která se tváří jako jiný hosting

Předmět obou zpráv napodoboval název jiného českého hostingu. Čtyři písmena v něm ale nebyla latinka: а, Н, і a с byla cyrilská. Člověk rozdíl nevidí, počítač ano, a filtr, který hledá konkrétní název, takový předmět snadno přehlédne. Loga útočníci ani nehostovali, vložili je jako odkazy na náhledy z Google Obrázků. Jedno patřilo napodobovanému hostingu, druhé britskému hostingu Krystal. Odhad: šablona nejspíš zbyla z kampaně proti zákazníkům jiného poskytovatele.

Útočník o příjemci nepotřeboval nic vědět. Doménu, které se „pozastavení“ týkalo, vzal z adresy, na kterou psal, a jako datum vypršení dosadil den odeslání. S jednou šablonou a seznamem adres tak každá zpráva působí jako upozornění na konkrétní službu konkrétního zákazníka.

Dva e-maily, dvě různé cesty

1. e-mail 2. e-mail
Doručeno 10.11.2026, 13:09 10.11.2026, 13:54
From support@domain.cz support-klarnarefund@telesys-japan.com
Return-Path sf21@www1071.sakura.ne.jp stejný jako From
Odesílající server www1071.sakura.ne.jp, IP 219.94.129.81, Japonsko Alibaba Cloud DirectMail, IP 8.219.25.24, Singapur
SPF / DKIM / DMARC none / none / none pass / pass / pass (politika none)
Skóre Rspamd 4,93 z 15 2,41 z 15
Odkaz vedl na northwoodpark.co.uk sandboxwp.sfadev.com

První e-mail je klasický podvrh. Do pole From útočník napsal support@domain.cz, ale zprávu odeslal ze sdíleného webhostingu japonské firmy Sakura Internet. Podle hlaviček Received ji do poštovního systému serveru předal místní uživatelský účet sf21. Odhad: jde o zneužitý hostingový účet nebo podstrčený skript, ověřené to ale nemáme. O tom, kdo útočník je a odkud pochází, tento údaj neříká nic.

Druhý e-mail žádnou adresu nepodvrhl. Přišel z domény telesys-japan.com přes službu Alibaba Cloud a prošel SPF, DKIM i DMARC. Nevíme, jestli doménu ovládá útočník, nebo jde o zneužitý účet. Na výsledku to nic nemění: DMARC potvrzuje, že zpráva opravdu pochází z domény ve From. Neříká, že je ta doména důvěryhodná. RFC 7489 to v oddílu 6.7 píše výslovně. Rspamd dal druhému e-mailu za úspěšné ověření minusové body, takže skončil s nižším skóre než podvrh. Část adresy klarnarefund navíc odkazuje na další typ podvodu. Odhad: útočníci stejnou infrastrukturu používají pro víc kampaní.

Proč první e-mail prošel filtrem

Výsledek spf=none u prvního e-mailu se týká obálkové domény www1071.sakura.ne.jp, ne domain.cz. SPF totiž kontroluje jen obálku a na viditelné pole From se vůbec nedívá. Obě adresy dává dohromady až DMARC. Ten chce, aby SPF nebo DKIM prošly pro stejnou doménu, jaká je ve From. Tomu se říká alignment. Rspamd zapsal DMARC_NA pro domain.cz: doména žádnou politiku nezveřejnila, takže přijímající server od vlastníka nedostal žádný pokyn, co s podvrhem dělat.

Body přidala pravidla FORGED_W_BAD_POLICY (3,00), URI_COUNT_ODD (1,00), AUTH_NA (1,00) a R_MIXED_CHARSET (0,25) za míchané písmo v předmětu. Pravidla FROM_NEQ_ENVFROM a FORGED_SENDER, která hlásí rozdíl mezi From a obálkou, měla váhu nula. Ten rozdíl mají i běžné newslettery a fakturační systémy. Jedno pravidlo skóre dokonce snížilo: MIME_FROM_MX_GOOD (−0,10) za to, že doména ve From má funkční poštovní server perimeter.active24.cz. Celkem to dalo 4,93 bodu. Číslo 15 ve výpisu je práh pro odmítnutí, ve výchozím nastavení Rspamd označí zprávu jako spam od 6 bodů. Filtr tedy podvod zaznamenal, jen mu chyběl signál, který by zprávu dostal přes hranici. Ten mohla dodat DMARC politika vlastníka domény.

Odkazy vedly na cizí weby s WordPressem

Oba odkazy mířily na weby s WordPressem, které s hostingem ani s doménami nesouvisejí. sandboxwp.sfadev.com je podle názvu vývojová instalace. VirusTotal tento druhý odkaz při kontrole 11.11. označil jako škodlivý. Odhad: oba weby jsou napadené a útočníkům slouží jako jednorázový hosting. Jejich majitelé s kampaní nejspíš nemají nic společného.

První odkaz jsme nechali projít izolovaným skenerem urlscan.io. Sken skončil na obyčejné stránce Google. Druhý odkaz urlscan.io skenovat odmítl. Přesměrování na Google je u phishingových sad běžný trik: automatický sken poznají podle IP adresy datacentra nebo podle prohlížeče, pošlou ho pryč a podvodný formulář ukážou jen skutečnému návštěvníkovi. Co by uviděl příjemce, proto zdokumentované nemáme a netvrdíme, že stránka sbírala karty nebo hesla. Celé odkazy v článku záměrně neuvádíme.

Proč zrovna domain.cz

Napodobovaný hosting má na hlavní doméně DMARC s politikou p=reject. Na variantě názvu bez pomlčky, kterou nejspíš drží právě proti zneužití, má navíc v=spf1 -all a sp=reject pro subdomény. Podvrhnout jeho adresu by u serverů, které DMARC kontrolují, neprošlo. To je přesně nastavení, které by měla mít každá doména se jménem, jež se dá zneužít, a provozovateli za ně patří uznání. Odhad: útočníci proto do pole From nedali adresu napodobované značky, ale sáhli po nechráněné doméně se jménem, které v e-mailu o fakturách za domény zní věrohodně.

Co bylo v DNS domény domain.cz

DNS jsme kontrolovali 11.11.2026 ve 22:33 a znovu ve 23:15 SEČ přes veřejné resolvery Cloudflare (1.1.1.1), Google (8.8.8.8), Quad9 (9.9.9.9) a ODVR CZ.NIC (193.17.47.1) a také přímo na autoritativních serverech alfa.ns.active24.cz a beta.ns.active24.cz. Všude se vrátily stejné záznamy. Nezávislý test EasyDMARC ve 22:47 dopadl stejně: DMARC chybí, SPF chybí, DKIM nenalezen, hodnocení 0 z 10. Oba výstupy zveřejňujeme: report EasyDMARC (PDF, 11.11.2026, 22:47) a výpis DNS dotazů (TXT, 11.11.2026, 23:15).

Záznam Výsledek Co to znamená
Držitel (CZ.NIC) SB:GLOBE-SGLO000001, ACTIVE 24, Praha 8; registrátor REG-ACTIVE24 Doménu drží ACTIVE 24
MX perimeter.active24.cz, mx2.active24.com Doména přijímá poštu
SPF Jediný TXT záznam je MS=ms99892746, žádný v=spf1 Není určeno, které servery smějí za doménu odesílat
DMARC _dmarc vede přes CNAME na www.domain.cz, kde je jen A záznam, žádný TXT Žádná politika
DKIM 9 běžných selektorů skončí na stejném CNAME Neprokazuje, že DKIM chybí
DNSSEC Zóna je podepsaná Odpovědi zóny lze kryptograficky ověřit

Jméno _dmarc nemá v zóně vlastní záznam. Zóna ale obsahuje zástupný (wildcard) záznam, který na www.domain.cz pošle jakékoli jméno, třeba i náhodné nextrey-test-x7q.domain.cz. Dotaz na DMARC tak nedostane odpověď „neexistuje“, ale odkaz na webový server, kde žádný TXT záznam není. Pro přijímající server je to totéž, jako kdyby DMARC chyběl. Oprava je přitom snadná: podle RFC 4592 má explicitní TXT záznam na _dmarc.domain.cz přednost před wildcardem.

Na stejný CNAME skončilo i devět selektorů DKIM, které jsme zkusili (default, selector1, google a další). Klíč DKIM ale leží pod jménem selektor._domainkey.domena a selektor zná jen ten, kdo zprávy podepisuje. Kdyby byl některý selektor zapsaný explicitně, přebil by wildcard. Netvrdíme proto, že domain.cz DKIM nemá. Na prvním e-mailu to stejně nic nemění, podvrh podepsaný nebyl.

SOA záznam zóny uvádí sériové číslo 2018061402 a primární server ns.globe.cz. Odhad: pokud provozovatel sériové číslo vede v obvyklém formátu RRRRMMDDnn, zóna se naposledy měnila 14.6.2018. Formát ale povinný není a některé DNS systémy čísla generují jinak. Identifikátor držitele SB:GLOBE-… spolu s ns.globe.cz naznačuje starší, převzatou doménu. Že se na ni při zavádění DMARC zapomnělo, je jen naše domněnka.

Hlavní domény ACTIVE 24 chráněné jsou

Stejné dotazy jsme položili i pro active24.cz a active24.com:

_dmarc.active24.cz   "v=DMARC1; p=quarantine; sp=quarantine; pct=100; rua=mailto:dmarc-report@active24.cz; ..."
active24.cz          "v=spf1 mx ip4:81.95.96.0/20 ... include:spf.protection.outlook.com ... -all"
_dmarc.active24.com  "v=DMARC1; p=reject; rua=mailto:dmarc-report@active24.cz;"
active24.com         "v=spf1 -all"

Doména active24.com má přesně takové nastavení, jaké patří doméně, ze které se poštu posílat nemá: SPF nepovoluje žádný server a DMARC žádá odmítnutí. Firma tedy ví, jak na to, a na hlavních doménách to dělá. domain.cz mezi ně nepatří, přestože se svým jménem do podvodů s „fakturou za doménu“ hodí jako málokterá.

Příjmu pošty to nijak nepřekáží. MX záznamy řídí doručování příchozích zpráv, kdežto SPF a DMARC se týkají jen pošty odeslané jménem domény. Pokud z domain.cz žádná legitimní pošta neodchází, dva TXT záznamy podle vzoru active24.com by příjem neovlivnily. Pokud odchází, je potřeba nejdřív zjistit odkud. Který případ platí, nevíme.

Jak reagovala ACTIVE 24

První e-mail jsme podpoře ACTIVE 24 přeposlali ještě 10.11.. V noci na 11.11. přišla odpověď zákaznického specialisty v plném znění:

Dobrý den, zmíněný email nebyl odeslán naší společností, jedná se o phishingový email jenž nebyl odeslán z naší infrastruktury. V případě dalších otázek, či požadavků, nás neváhejte kontaktovat.

To je pravda a hlavičky to potvrzují. Nic nenaznačuje, že by se někdo dostal do systémů ACTIVE 24 nebo že by unikla data jejích zákazníků. Odpověď se ale nevyjádřila k tomu, kvůli čemu jsme psali: že doménu lze takto zneužít.

Dopoledne 11.11. jsme proto napsali znovu a položili čtyři konkrétní otázky:

  1. Proč na domain.cz není publikovaný DMARC?
  2. Pokud doména poštu neodesílá, proč její zneužití neomezují restriktivní záznamy SPF a DMARC?
  3. Plánuje ACTIVE 24 konfiguraci napravit?
  4. Může podnět předat odpovědnému pracovníkovi nebo bezpečnostnímu týmu?

Ke 23:15 téhož dne odpověď nepřišla a DNS domény domain.cz zůstalo beze změny. Upozornění na problém tedy firma má od 10.11., a ani po více než dni se v nastavení domény nic nepohnulo. Jakmile odpověď dostaneme nebo se konfigurace změní, doplníme to sem.

Co by DMARC u těchto e-mailů změnil

První e-mail by kontrolou DMARC neprošel: SPF se domain.cz vůbec netýkalo a podpis DKIM chyběl. S politikou p=reject by ho server, který politiku dodržuje, mohl odmítnout bez ohledu na antispamové skóre. Rspamd to umí, pokud je tak nastavený. Gmail od 1.2.2024 vyžaduje DMARC od každého, kdo mu denně posílá přes 5 000 zpráv, takže u velkých odesílatelů je to dnes samozřejmost.

Druhý e-mail ukazuje, kde DMARC končí. Proti doméně, kterou útočník ovládá nebo jejíž účet zneužil, nepomůže, protože ověřením projde. Stejně tak nepomůže proti podobně vypadajícím doménám typu dornain.cz nebo proti zobrazovanému jménu „ACTIVE 24 fakturace“ s úplně jinou adresou. Útočník ale musí sáhnout po doméně bez historie a bez reputace, kterou lze nahlásit a zablokovat, a v poli From už nemá jméno, které příjemce zná. Napodobovaný hosting tohle zařídil. U domain.cz dostal útočník důvěryhodné jméno zadarmo.

Jak zkontrolovat vlastní doménu

Základní kontrola zabere v terminálu pár minut:

dig +short TXT _dmarc.vasedomena.cz          # má vrátit "v=DMARC1; ..."
dig +short TXT vasedomena.cz | grep spf1     # právě jeden záznam "v=spf1 ... -all"
dig +short MX vasedomena.cz                  # kdo přijímá poštu
dig +short TXT selektor._domainkey.vasedomena.cz   # selektor najdete v hlavičce DKIM-Signature (s=)

Když _dmarc místo TXT vrátí CNAME, má zóna nejspíš wildcard jako domain.cz a DMARC ve skutečnosti chybí.

Pak přijde pracnější část, tedy zjistit, kdo všechno jménem domény posílá poštu:

  1. Sepište všechny služby, které posílají e-maily za vaši doménu: schránky, fakturaci, CRM, kontaktní formulář, newsletter i transakční e-maily z aplikace. Na co zapomenete, to se později ozve v podobě odmítnutých faktur.
  2. Dejte je do jednoho SPF záznamu zakončeného -all. SPF smí při vyhodnocení spustit nejvýš 10 DNS dotazů (RFC 7208, 4.6.4) a každý include se počítá i s dotazy, které vyvolá on sám.
  3. U každé služby zapněte DKIM pod vlastní doménou. Podpis doménou poskytovatele alignment nesplní.
  4. Začněte s v=DMARC1; p=none; rua=mailto:... a pár týdnů čtěte agregované reporty. Až v nich zůstanou jen podvrhy, přejděte na p=quarantine a potom na p=reject. Politiku pro subdomény určuje parametr sp=.
  5. Nezapomeňte na varianty názvu a domény, které nepoužíváte. Podvodníkovi poslouží stejně dobře jako ta hlavní.
Doména SPF DMARC MX
Odesílá i přijímá poštu v=spf1 include:... -all p=none, po reportech quarantine a reject Běžné MX
Přijímá, ale nic neodesílá v=spf1 -all v=DMARC1; p=reject; sp=reject Běžné MX
Nepřijímá ani neodesílá v=spf1 -all v=DMARC1; p=reject; sp=reject Null MX 0 . (RFC 7505)

Null MX patří jen na domény, které poštu opravdu nepřijímají, na doménu s funkčními schránkami ho nedávejte. Širší kontrolu toho, co je o systému veřejně dohledatelné, popisuje audit bezpečnosti aplikace.

Proč o tom píšeme

Oba e-maily přišly do schránky, kterou spravujeme, a oba prošly filtrem. Poskytovatel domén a hostingu je pro takový podvod ideální maska, protože jeho zákazníci faktury za domény opravdu dostávají. Jeho vlastní domény, i ty okrajové, by proto měly být chráněné stejně jako active24.com. U domain.cz by stačily dva TXT záznamy a na jejich doplnění měla firma od našeho upozornění víc než den. Podle nás by doména s takovým jménem u firmy, která domény prodává, bez nich zůstat neměla.

Článek zachycuje stav k 11.11.2026, 23:15 SEČ. Pokud ACTIVE 24 na doplňující dotazy odpoví nebo nastavení domény změní, článek aktualizujeme.

Časté otázky

Byla ACTIVE 24 napadena?

Nic tomu nenasvědčuje. První zpráva přišla ze serveru Sakura Internet a ACTIVE 24 potvrdila, že ji neposlala. Útočník jen napsal cizí adresu do pole From, a tomu samotný protokol SMTP nijak nebrání.

Zastaví DMARC s p=reject každý podvržený e-mail?

Ne. Příjemce smí politiku ignorovat a DMARC neřeší podobné domény, podvržená zobrazovaná jména ani domény, které útočník ovládá. Druhý e-mail z tohoto případu ověřením DMARC prošel. U příjemců, kteří politiku dodržují, ale DMARC znemožní přímé zneužití konkrétní domény, což je pro phishing ta nejlevnější cesta.

Jak poznám, odkud e-mail skutečně přišel?

Zobrazte si zdrojový text zprávy. Rozhodující jsou Return-Path, nejspodnější hlavičky Received, které přidal váš server, a Authentication-Results od vašeho přijímajícího serveru. Pole From vyplňuje odesílatel.

Zdroje

Máte nápad, co postavit?

Pracujeme se společnostmi, které potřebují skutečný software postavit a nasadit, a často ho i nadále udržovat. Řekněte nám, co plánujete, a my vám upřímně řekneme, jak bychom k tomu přistoupili.

Ozvěte se nám