#email_spoofing — Public Fediverse posts

[Перевод] Подсмотрел PIN от двери, а затем воткнул Wi-Fi-жучка за принтер — и ты внутри сети банка

Проник в банк не через вайфай и не через фишинг — а просто пристроился к аудиторам с улицы. Никто не спросил имени. Никто не проверил. А через час уже сидел у них в сети с рабочим пропуском. Как это случилось — и почему «следовать инструкции» не спасло — в новой статье.

https://habr.com/ru/companies/flant/articles/979672/

#редтиминг #взлом #социальная_инженерия #фишинг #DKIM #DMARC #email_spoofing #управление_паролями #доступ_к_данным

🎯 Threat Intelligence
===================

Executive summary: A phishing scheme leverages legitimate Google infrastructure and addresses to impersonate Google Support and trick users into disclosing credentials. The campaign uses the genuine sender [email protected] and hosts cloned support pages on sites.google.com instead of support.google.com, increasing perceived legitimacy.

Technical details:
• Sender address observed: [email protected].
• Phishing landing pages hosted under: sites.google.com (Google Sites subdomains).
• Legitimate support domain expected: support.google.com.
• Suspicious header artifact example in reported mail: to field containing me[@]googl-mail-smtp-out-198-142-125-38-prod[.]net rather than the real recipient address.

Analysis:
Using Google-owned domains and services (Google Sites) reduces visual indicators of fraud and can bypass naive domain-based allowlists. The flow described in reports uses a genuine Google login page when the victim is not authenticated, which then redirects to a convincingly styled sites.google.com page that mimics an official support case view. Attackers populate the email with details — Google Account ID and support ticket numbers — to reinforce trust.

Detection:
• Inspect email headers for mismatched to and mailed-by values; look for domains that imitate Google via typos or added tokens.
• Flag messages where the displayed link domain differs from expected Google support domain (sites.google.com vs support.google.com).
• Monitor for accounts that receive inbound messages claiming legal/subpoena notices with embedded external-hosted pages.

Mitigation (as described in the report):
• Treat sites.google.com links that purport to be official support documents with caution; verify domain differences in the header and link target.
• Educate recipients to check from, to, and mailed-by header fields when an email requests sensitive action or login.

Limitations & open questions:
Observed details do not attribute the campaign to a named actor or provide expanded IoC lists beyond header artifacts and the use of Google Sites. The report focuses on the deception technique rather than exploitation of vulnerabilities.

🔹 phishing #google_sites #email_spoofing #threatintel #security

🔗 Source: https://www.kaspersky.com/blog/dkim-replay-attack-through-google-oauth/53392/