Wprowadzenie do problemu / definicja luki
SANS Internet Storm Center opisał serię japońskojęzycznych e-maili phishingowych podszywających się pod różne marki (m.in. ANA, DHL, myTOKYOGAS) i prowadzących do stron wyłudzających dane logowania. Choć motywy wiadomości są różne, kampania ma powtarzalne wzorce infrastruktury, co sugeruje jednego operatora lub jeden klaster narzędzi.
Phishing w tym wydaniu to klasyczne brand impersonation: napastnik wykorzystuje zaufanie do znanej marki, aby skłonić ofiarę do kliknięcia linku i podania danych (czasem również danych płatniczych).
W skrócie
- Opisane próbki podszywały się pod: ANA (All Nippon Airways), DHL, myTOKYOGAS.
- Wspólny mianownik: domeny z TLD .cn zarówno w adresach nadawcy, jak i w linkach do stron phishingowych.
- Charakterystyczny ślad w nagłówkach: „X-mailer: Foxmail 6, 13, 102, 15 [cn]” – bardzo użyteczny do korelacji kampanii.
- Realne ryzyko: kampania może być szczególnie skuteczna wobec odbiorców japońskojęzycznych i środowisk z gorszym filtrowaniem spamu.
Kontekst / historia / powiązania
Podszywanie się pod rozpoznawalne marki (linie lotnicze, logistyka, dostawcy usług komunalnych) to stały trend, bo:
- użytkownik spodziewa się komunikacji (np. „przesyłka”, „rachunek”, „konto”, „weryfikacja”),
- treści łatwo budują presję („pilne”, „problem z kontem”, „wstrzymana dostawa”),
- fałszywe witryny potrafią wyglądać jak oryginalne portale logowania.
Same marki regularnie publikują ostrzeżenia o fałszywych e-mailach i stronach do wyłudzania danych, co pokazuje skalę zjawiska (ANA oraz DHL mają dedykowane strony ostrzegawcze).
Analiza techniczna / szczegóły kampanii
1. Wspólne elementy infrastruktury
W trzech przykładach z ISC powtarzają się:
- nadawcy w domenach *.cn,
- linki phishingowe hostowane w domenach *.cn,
- podobna „konstrukcja” ścieżek URL sugerująca gotowe szablony stron logowania.
Przykładowe wskaźniki (zachowuję bezpieczną obfuskację):
- ANA: member.llbyzmf@ncqjw[.]cn → hxxps[:]//branchiish.aayjlc[.]cn/amcmembr_Loginam/
- DHL: dmail.elthr@obpwnrl[.]cn → hxxps[:]//decideosity.ykdyrkye[.]cn/portal_login_exp/getQuoteTab/
- myTOKYOGAS: reportogkfgkbye@cwqfvzp[.]cn → hxxps[:]//impactish.rexqm[.]cn/mtgalogin/
2. Korelacja po nagłówkach: „X-mailer: Foxmail…”
Najbardziej „spinającym” wskaźnikiem w opisie ISC jest linia:
- X-mailer: Foxmail 6, 13, 102, 15 [cn]
To cenna wskazówka dla SOC/blue team:
- pozwala łączyć próbki po narzędziu wysyłkowym/kliencie poczty (albo po artefakcie, który atakujący zostawia),
- bywa użyteczne w regułach SIEM (korelacja zdarzeń) i w detekcji na bramie pocztowej.
3. Dlaczego .cn ma znaczenie (ale nie jest dowodem)
Samo TLD nie dowodzi pochodzenia ataku, ale:
- jest praktycznym „punktem zaczepienia” do risk-scoringu domen,
- w połączeniu z innymi sygnałami (nietypowa domena nadawcy, brak zgodności SPF/DKIM/DMARC, świeża rejestracja, podobne ścieżki URL) wzmacnia decyzje filtrów.
Praktyczne konsekwencje / ryzyko
Najczęstszy scenariusz:
- Użytkownik dostaje e-mail po japońsku, wyglądający jak komunikat marki (np. o koncie, przesyłce, płatności).
- Klika link → trafia na stronę imitującą portal logowania (brand phishing).
- Podaje dane → napastnik przejmuje konto, wykorzystuje je do dalszego phishingu/BEC, prób logowania do innych usług (credential stuffing) lub nadużyć finansowych.
Dla organizacji ryzyko to nie tylko „jedno konto”:
- przejęty e-mail może posłużyć do ataków wewnętrznych,
- rośnie ryzyko incydentów związanych z resetami haseł i MFA-fatigue,
- dochodzą koszty obsługi: helpdesk, IR, blokady płatności, komunikacja do klientów.
Rekomendacje operacyjne / co zrobić teraz
Na bramie pocztowej / MTA
- Wzmocnij polityki SPF, DKIM i DMARC (monitoring → quarantine/reject, gdzie możliwe).
- Dodaj reguły wykrywające anomalia brand-phishing: nazwy marek w temacie/nadawcy przy jednoczesnym braku autoryzacji domeny.
- Koreluj po nagłówkach: warunek na wystąpienie X-mailer: Foxmail 6, 13, 102, 15 [cn] jako sygnał pomocniczy (nie jedyny).
Na warstwie DNS/Proxy
- Wprowadź politykę blokad dla nowo rejestrowanych domen (NRD) oraz domen o niskiej reputacji; kampanie phishingowe często „żyją krótko”.
- Monitoruj ruch do domen *.cn z kontekstów „logowanie do usług”, zwłaszcza gdy firma nie prowadzi relacji biznesowych w tym zakresie.
Na endpointach i w IAM
- Wymuś MFA (preferuj FIDO2/WebAuthn) i monitoruj nietypowe logowania.
- Włącz alerty na: masowe nieudane logowania, logowania z nowych lokalizacji/ASN, zmiany metod MFA.
Dla użytkowników
- Szybka edukacja „punktowa”: „nie loguj się z linku w mailu — wejdź na stronę manualnie / z zakładki”.
- Przypominaj, iż prawdziwe komunikaty firm często wskazują oficjalne domeny (np. ANA opisuje typowe cechy fałszywych wiadomości).
Różnice / porównania z innymi przypadkami
To, co wyróżnia opis ISC na tle „zwykłego” brand-phishingu, to łatwo korelowalny artefakt w nagłówkach (Foxmail + konkretna wersja) oraz konsekwentne użycie domen *.cn w wielu przynętach tematycznych. W typowych kampaniach operatorzy częściej mieszają infrastrukturę i narzędzia wysyłkowe, żeby utrudnić łączenie próbek.
Podsumowanie / najważniejsze wnioski
- Kampania podszywa się pod różne japońskie i globalne marki, ale zdradza wspólne DNA: .cn + powtarzalne wzorce + „X-mailer: Foxmail … [cn]”.
- Największe ryzyko dotyczy odbiorców, u których takie wiadomości przejdą przez filtry oraz którzy mogą zaufać komunikacji „od marki”.
- Dla obrony liczy się połączenie: mocne uwierzytelnianie domen (DMARC), detekcja na bramie, polityki DNS/proxy i monitoring IAM.
Źródła / bibliografia
- SANS Internet Storm Center (ISC) – „Japanese-Language Phishing Emails” (Brad Duncan, 2026-02-21). (SANS Internet Storm Center)
- ANA – ostrzeżenia i przykłady dot. phishingu / fałszywych e-maili. (ANA)
- DHL – Fraud Awareness / „Uważaj na oszustów”. (DHL)
- Check Point – opis zjawiska „brand phishing” (m.in. na przykładzie DHL). (Check Point Software)
