E-posta ve DNS Güvenliği

SPF / DKIM / DMARC, Domain Sahteciliği ve Phishing Tespit Mimarisi

Kapsam: SPF, DKIM, DMARC/DMARCbis, Microsoft 365 compauth, DMARC RUA/RUF, Authentication-Results, ARC, Direct Send, cousin-domain, display-name spoofing, Reply-To manipülasyonu, URL/ek/QR phishing, compromised mailbox, DNS drift ve SOC triyaj korelasyonu.

Amaç: Bölüm 1'de anlatılan zafiyetlerin ve Bölüm 2'de önerilen kontrollerin izlenmesi, doğrulanması ve olay müdahalesine bağlanması.

3.1 Yönetici Özeti

SPF/DKIM/DMARC tespiti yalnızca spf=fail, dkim=fail veya dmarc=fail aramaktan ibaret değildir.. Etkili bir tespit modeli; kimlik doğrulama sonuçlarını, başlık (header) anomalilerini, sender reputation, domain benzerliği, URL/ek riski, kullanıcı aksiyonu ve mailbox davranışını birlikte korele eder.

Temel zincir:

• Authentication sonucu

• → SPF/DKIM/DMARC alignment

• → compauth / ARC / policy override

• → Header From / MailFrom / Reply-To / Sender farkları

• → Domain reputation / cousin-domain / IDN / CT log

• → URL / attachment / QR / sandbox verdict

• → User click / OAuth consent / inbox rule / forwarding

• → Kampanya korelasyonu ve containment

Sonuç: DMARC fail exact-domain spoofing için güçlü sinyaldir; DMARC pass ise yalnızca authentication'ın geçtiğini söyler, mesajın güvenli veya iş bağlamında meşru olduğunu kanıtlamaz.

3.2 MITRE ATT&CK v19 Eşlemesi

MITRE ATT&CK v19 ile sosyal mühendislik sınıflandırması güncellenmiştir.

DET0899 mantığı:

1. Şüpheli sosyal mühendislik etkileşimi

2. → ardından olağandışı kullanıcı-otorize aksiyon

Örnek zincir:

• DMARC başarısızlığı veya kimliğe bürünme (impersonation) içeren e-posta

• → URL click

• → OAuth consent

• → inbox rule

• → outbound spike

3.3 Detection Katman Modeli

• L0 — Edge / inline: SEG, MDO, Gmail verdict, DMARC action, Safe Links, sandbox

• L1 — SOC : KQL/Sigma alarmları, EmailEvents, SEG logs, UrlClickEvents, CloudAppEvents

• L2 — Stratejik / threat intel: DMARC RUA trendleri, DNS drift, CT logs, dnstwist, domain reputation

3.4 Telemetry Kaynakları

Not: RUA raporlarını toplayıp SIEM'e parse etmiyorsan detection yapmıyorsun sadece XML arşivliyorsun.

3.5 Authentication-Results ve compauth Analizi

Örnek header:

Authentication-Results: mx.example;
 spf=pass smtp.mailfrom=sender.example;
 dkim=pass header.d=sender.example header.s=s2026;
 dmarc=fail header.from=hedef.com;
 compauth=fail reason=000

Yorum:

• SPF/DKIM pass olabilir

• Ancak başarılı olan alan adı (domain), From alanındaki alan adıyla eşleşmiyorsa (aligned)

İzlenecek alanlar:

3.6 Microsoft compauth Reason Kodları

Microsoft 365 compauth, SPF/DKIM/DMARC ve mesaj meta verisini birlikte değerlendirir. SOC triyajında reason code çok değerlidir.

Kritik not: Sadece compauth=fail ararsan 109, 130, 201 gibi zayıf ama önemli durumları kaçırırsın.

Dokümante edilmemiş reason code'lara alarm mantığı bağlama. Üçüncü taraf blog/forumlarda geçen 604, 605, 703 gibi kodlar resmi Microsoft tablosuyla doğrulanmadan production kuralı olmamalı.

3.7 DMARC RUA / RFC 9990 Aggregate Analizi

RFC 9990, DMARC aggregate reporting'i ayrı standart haline getirir.

Önemli alanlar:

Örnek modern policy block:

<policy_published>
  <domain>ornek.com</domain>
  <p>reject</p>
  <sp>reject</sp>
  <testing>n</testing>
  <discovery_method>treewalk</discovery_method>
</policy_published>

Policy override örneği:

<policy_evaluated>
  <disposition>none</disposition>
  <policy_override>
    <reason>
      <type>policy_test_mode</type>
      <comment>DMARC record has t=y tag</comment>
    </reason>
  </policy_override>
</policy_evaluated>

RUA Detection Sinyalleri

Not: p=reject gördün diye teslimatın kesin reddedildiğini varsayma. RFC 9989 sonrası receiver local policy, quarantine davranışı ve DeliveryAction ile çapraz doğrulama şarttır.

3.8 DMARCbis Etiket Drift Detection

RFC 9989 sonrası izlenecek kayıt değişiklikleri:

Not: DMARC policy downgrade, DeliveryAction beklenmeden security event sayılmalıdır. Etki analizi DeliveryAction/RUA ile yapılır; alarm üretmek için teslimat kanıtı beklenmez.

3.9 DMARC RUF ve Header Analizi

RUF raporları mevcutsa değerli olabilir ancak çeşitli kısıtlamalara sahiptir:

• birçok sağlayıcı göndermez

• PII/gizlilik riski vardır

• içerik redakte edilebilir

• hacim düşük olabilir

RUF varsa aranacaklar:

• 1- Targeted recipients

• 2- Subject pattern

• 3- Reply-To mismatch

• 4- Return-Path mismatch

• 5- Message-ID anomaly

• 6- Received chain anomaly

• 7- DKIM fail reason

• 8- ARC-Seal cv result

Header kontrol listesi:

3.10 Microsoft 365 KQL — Temel Auth Parse

AuthenticationDetails string tipindedir. parse_json() kullanılmalı.

EmailEvents
| where Timestamp > ago(24h)
| extend Auth = parse_json(AuthenticationDetails)
| extend
    SPF = tostring(Auth.SPF),
    DKIM = tostring(Auth.DKIM),
    DMARC = tostring(Auth.DMARC),
    CompAuth = tostring(Auth.CompAuth)
| where DMARC == "fail" or CompAuth == "fail"
| project Timestamp, NetworkMessageId, SenderIPv4,
          SenderFromAddress, SenderMailFromAddress,
          RecipientEmailAddress, Subject,
          SPF, DKIM, DMARC, CompAuth,
          DeliveryAction, ThreatTypes

Alternatif:

EmailEvents
| where Timestamp > ago(7d)
| extend Auth = parse_json(AuthenticationDetails)
| evaluate bag_unpack(Auth)
| where DMARC == "fail"

3.11 M365 KQL — Organizational Domain Spoof

let OrgDomains = dynamic(["company.com", "company.net"]);
let KnownGoodIPs = dynamic([]);   // Bölüm 2 §2.4 sender inventory'den doldurun
EmailEvents
| where Timestamp > ago(24h)
| where EmailDirection == "Inbound"                          
| where SenderFromDomain in~ (OrgDomains) or SenderMailFromDomain in~ (OrgDomains)
| where SenderIPv4 !in (KnownGoodIPs)                         
| extend Auth = parse_json(AuthenticationDetails)
| extend CompAuth = tostring(Auth.CompAuth), DMARC = tostring(Auth.DMARC)
| where CompAuth == "fail" or DMARC in ("fail", "none")       
| summarize
    MsgCount = count(),
    Recipients = dcount(RecipientEmailAddress),
    Subjects = make_set(Subject, 10),
    DeliveryActions = make_set(DeliveryAction),
    DeliveredCount = countif(DeliveryAction == "Delivered"),  
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
    by SenderIPv4, SenderIPv6, SenderFromDomain, CompAuth, DMARC   
| where MsgCount >= 3                                        
| sort by DeliveredCount desc, MsgCount desc                   

3.12 M365 KQL — compauth Reason Triage

Reason code çoğu ortamda AuthenticationDetails JSON içinde doğrudan olmayabilir. Full header veya AdditionalFields şeması doğrulanmalı.

EmailEvents
| where Timestamp > ago(7d)
| extend Auth = parse_json(AuthenticationDetails)
| extend
    CompAuth = tostring(Auth.CompAuth),
    CompAuthReason = tostring(Auth.CompAuthReason),
    SPF = tostring(Auth.SPF),
    DKIM = tostring(Auth.DKIM),
    DMARC = tostring(Auth.DMARC)
| where CompAuthReason in ("000", "001", "002", "010", "601")   
| project Timestamp, NetworkMessageId, SenderFromAddress, SenderIPv4,
          RecipientEmailAddress, Subject,
          SPF, DKIM, DMARC, CompAuth, CompAuthReason,
          DeliveryAction, ThreatTypes
| sort by Timestamp desc

Not: Tenant'ta AdditionalFields header içermiyorsa Bu sorgunun görünürlüğü sınırlı kalacaktır.. Email entity headers, Explorer export veya message trace ile doğrulama gerekir.

3.13 M365 KQL — Reply-To Mismatch

EmailEvents'te her tenant için native ReplyTo kolonu yoktur. Header parse gerekir.

EmailEvents
| where Timestamp > ago(7d)
| extend AF = parse_json(AdditionalFields)
| extend ReplyTo = tostring(AF["Reply-To"])   
| extend TaggedMismatch = Subject startswith "[REPLY-TO UYUMSUZ]"   
| where isnotempty(ReplyTo) or TaggedMismatch
| extend FromDomain = tostring(split(SenderFromAddress, "@")[1])
| extend ReplyToDomain = iff(isnotempty(ReplyTo), tostring(split(ReplyTo, "@")[1]), "")
| where TaggedMismatch or (isnotempty(ReplyToDomain) and FromDomain != ReplyToDomain)
| project Timestamp, SenderFromAddress, ReplyTo, FromDomain, ReplyToDomain,
          TaggedMismatch, RecipientEmailAddress, Subject,
          DeliveryAction, ThreatTypes, NetworkMessageId

Alternatif kaynaklar:

• MDO Explorer → Email entity → Headers

• Exchange message trace detail

• Raw EML export

• SEG header logs

3.14 M365 KQL — Direct Send / Internal Spoof Şüphesi

Direct Send faaliyetleri tek bir göstergeyle doğrulanamaz. Baseline gerekir.

let KnownRelayIPs = dynamic(["203.0.113.10", "203.0.113.11"]);
let OrgDomains = dynamic(["company.com"]);
EmailEvents
| where Timestamp > ago(7d)
| where EmailDirection == "Inbound"          
| where isempty(Connectors)                  
| where SenderFromDomain in~ (OrgDomains)
| where SenderIPv4 !in (KnownRelayIPs)
| extend Auth = parse_json(AuthenticationDetails)
| extend
    DMARC = tostring(Auth.DMARC),
    CompAuth = tostring(Auth.CompAuth),
    CompAuthReason = tostring(Auth.CompAuthReason)     
| where DMARC == "fail" or CompAuth == "fail" or CompAuthReason in ("010", "601")
| summarize
    Count = count(),
    Subjects = make_set(Subject, 10),
    Recipients = make_set(RecipientEmailAddress, 30),
    DeliveryActions = make_set(DeliveryAction)
    by SenderIPv4, SenderFromAddress, DMARC, CompAuth, CompAuthReason
| sort by Count desc

Yüksek risk kombinasyonu:

• Internal From

• + unknown sender IP

• + delivered

• + reason=010/601

• + finance/executive recipients

3.15 M365 KQL — BEC Keyword + Weak Auth

let KnownGoodSenders = dynamic([]);   // sender inventory'niz varsa 
EmailEvents
| where Timestamp > ago(24h)
| where EmailDirection == "Inbound"                
| where SenderFromAddress !in (KnownGoodSenders)
| extend Auth = parse_json(AuthenticationDetails)
| extend CompAuth = tostring(Auth.CompAuth), DMARC = tostring(Auth.DMARC)
| where CompAuth in ("fail", "softpass") or DMARC == "fail"
| where Subject has_any (
    "urgent", "wire", "invoice", "payment", "confidential",
    "acil", "havale", "fatura", "ödeme", "gizli", "iban", "banka"
)
| extend Severity = case(DeliveryAction == "Delivered", 3, DeliveryAction == "Junked", 2, 1)
| project Timestamp, NetworkMessageId, SenderFromAddress, SenderDisplayName,
          RecipientEmailAddress, Subject,
          CompAuth, DMARC, DeliveryAction, Severity, ThreatTypes
| sort by Severity desc, Timestamp desc

3.16 M365 Korelasyon — Auth Fail + URL Click

let AuthFails =
EmailEvents
| where Timestamp > ago(24h)
| extend Auth = parse_json(AuthenticationDetails)
| where tostring(Auth.DMARC) == "fail" or tostring(Auth.CompAuth) == "fail"
| project EmailTime = Timestamp, NetworkMessageId, RecipientEmailAddress,
          SenderFromAddress, Subject;
UrlClickEvents
| where Timestamp > ago(24h)
| where ActionType in ("ClickAllowed", "ClickBlocked")
| join kind=inner (AuthFails) on NetworkMessageId
| project EmailTime, ClickTime = Timestamp, AccountUpn, Url,
          ActionType, SenderFromAddress, Subject, NetworkMessageId

Critical kombinasyon: DMARC/compauth fail + delivered + click allowed

3.17 M365 Korelasyon — Phishing Sonrası OAuth Consent

let SuspiciousRecipients =
EmailEvents
| where Timestamp > ago(7d)
| extend Auth = parse_json(AuthenticationDetails)
| where tostring(Auth.CompAuth) == "fail" or tostring(Auth.DMARC) == "fail"
| extend RecipientEmailAddress = tolower(RecipientEmailAddress)
| distinct RecipientEmailAddress;
CloudAppEvents
| where Timestamp > ago(7d)
| where ActionType has "Consent"
| extend UserUpn = tolower(tostring(RawEventData.UserId))   // tenant şemasına göre UserId / UserPrincipalName
| where UserUpn in (SuspiciousRecipients)                   // AccountId (GUID) DEĞİL — e-posta/UPN ile eşle
| project Timestamp, AccountDisplayName, UserUpn, Application, ActionType, IPAddress, RawEventData

Not: Ortam şemasına göre AccountDisplayName yerine AccountId/UserPrincipalName gerekebilir.

3.18 Google Workspace Detection

Kaynaklar:

• Gmail log search

• Security Investigation Tool

• Admin audit logs

• OAuth app access logs

• Login audit logs

• Alert Center

• Postmaster Tools

Detection mantıkları:

• 1- DMARC fail + delivered

• 2- SPF pass but DMARC fail

• 3- DKIM pass but unaligned

• 4- External sender using executive display name

• 5- Forwarding rule created

• 6- Suspicious OAuth app granted Gmail scopes

• 7- Mass outbound after risky login

• 8- New sender domain + suspicious URL

Özellikle izle:

3.19 SEG / Non-M365 Detection

Proofpoint, Mimecast, FortiMail, Cisco ESA gibi ortamlarda alan eşlemesi gerekir.

Pseudo-Sigma — DMARC fail burst:

title: DMARC Fail Event (Base Rule)
status: experimental
logsource:
  product: email_gateway
  category: mail_flow          
detection:
  selection:
    dmarc_result: 'fail'
  condition: selection
fields:
  - sender_ip
  - sender_domain
  - recipient
  - subject
level: low                       # tek olay düşük önem — asıl önem korelasyon kuralında
tags:
  - attack.t1684.002
  - attack.t1566.002

Not1: Aggregation/timeframe kullanılan SIEM altyapısına göre uyarlanmalıdır: count by sender_ip over 10m > threshold

Not2: Sigma aggregation syntax'ını SIEM backend'ine göre uyarlamadan production kuralı diye yayınlama.

3.20 Cousin-Domain / Typosquatting Detection

Cousin-domain DMARC pass alabilir.

Kaynaklar:

• 1- dnstwist

• 2- CT logs

• 3- passive DNS

• 4- RDAP/WHOIS

• 5- newly registered domain feeds

• 6- MX record monitoring

• 7- inbound sender domains

• 8- URL domains

• 9- PDNS logs

Risk skoru:

Detection mantığı:

IF sender_domain similar_to protected_brand
AND sender_domain not in owned_domains
AND domain_age < 60d
THEN alert

Örnek kombinasyon: DMARC pass + lookalike domain + login URL + executive/finance recipient

3.21 Display-Name Impersonation Detection

DisplayName matches VIP
AND sender domain external
AND sender not approved

Ek risk sinyalleri:

• Free-mail provider

• First-time sender

• Reply-To mismatch

• Payment/invoice/urgent language

• Attachment/link present

• No prior communication graph

• Recipient finance/HR/executive

Severity:

3.22 Reply-To Manipulation Detection

IF Reply-To domain != From domain
AND not approved workflow
THEN suspicious

Yüksek risk:

• From trusted vendor + Reply-To free-mail

• From executive display-name + Reply-To external

• Payment content + Reply-To mismatch

• Reply-To newly registered domain

• Reply-To cousin-domain

Not: Reply-To farkı çoğu BEC olayında attachment'tan daha değerli sinyaldir.

3.23 URL, Attachment ve QR Detection

URL sinyalleri:

• Newly registered domain

• Punycode/IDN

• URL shortener

• IP literal

• Multiple redirect

• Login/payment/MFA path

• Brand impersonation

• Time-of-click verdict

Attachment — yüksek riskli tipler: html, htm, iso, img, vhd, lnk, js, vbs, exe, scr, one, zip/rar/7z (password-protected)

QR phishing sinyalleri:

• Embedded image/PDF

• No visible URL

• MFA/login/verify language

• External sender

• New sender domain

• Mobile click after desktop email

M365 attachment örneği:

EmailAttachmentInfo
| where FileType in~ ("html", "htm", "iso", "img", "vhd", "lnk", "js", "vbs", "exe", "scr")
| project Timestamp, NetworkMessageId, SenderFromAddress,
          RecipientEmailAddress, FileName, FileType, SHA256

3.24 Compromised Mailbox Detection

SPF/DKIM/DMARC genellikle pass olur. Bu yüzden identity/mailbox telemetry gerekir.

Sinyaller:

• 1- Impossible travel

• 2- New device/country

• 3- MFA fatigue

• 4- OAuth app consent

• 5- New inbox rule

• 6- External forwarding

• 7- Mass outbound spike

• 8- Unusual recipients

• 9- Sent items deletion

• 10- Thread hijacking

• 11- Legacy auth

• 12- SMTP AUTH abuse

Inbox rule tespiti:

CloudAppEvents
| where ActionType has_any ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules")
| project Timestamp, AccountDisplayName, AccountId, ActionType, RawEventData

External forwarding tespiti:

CloudAppEvents
| where RawEventData has_any ("ForwardTo", "ForwardingSmtpAddress", "RedirectTo")
| project Timestamp, AccountDisplayName, AccountId, ActionType, RawEventData

Outbound spike tespiti:

EmailEvents
| where EmailDirection == "Outbound"
| summarize Count=count(), Recipients=dcount(RecipientEmailAddress)
          by SenderFromAddress, bin(Timestamp, 1h)
| where Count > 100 or Recipients > 50

3.25 DNS Drift ve Registrar Detection

İzlenecek kayıtlar: MX, NS, TXT SPF, TXT DKIM, TXT DMARC, MTA-STS, TLS-RPT, BIMI, DS/DNSSEC, CAA

Not: DNS drift bir deliverability detayı değil, security event'tir.

3.26 SMTP Smuggling / Parser Anomaly Detection

Asıl kontrol patch ve hardening'dir. Tespit mekanizmaları ise tamamlayıcı niteliktedir.

Sinyaller:

• Bare LF rejection/normalization

• Unexpected DATA terminator

• Multiple Message-ID in one SMTP session

• Gateway one message, backend two message gördü

• Malformed From

• Multiple From headers

• Header/body boundary inconsistency

• CHUNKING/BDAT anomaly

• Dot-stuffing anomaly

SOC mantığı: MTA parser anomaly + delivered message mismatch + auth/header inconsistency = High

3.27 Korelasyon Playbookları

Exact-domain spoofing:

header.from in protected_domains
AND dmarc=fail
AND delivered

SPF pass ama DMARC fail:

spf=pass
AND smtp.mailfrom domain != header.from domain
AND dmarc=fail

DKIM pass ama DMARC fail:

dkim=pass
AND header.d domain != header.from domain
AND dmarc=fail

Cousin-domain phishing:

dmarc=pass
AND sender_domain similar_to protected_brand
AND sender_domain not owned
AND domain_age < 60d
AND URL/login/payment present

Display-name BEC:

display_name matches VIP
AND sender external
AND reply_to mismatch
AND payment/urgent language

Compromised mailbox:

dmarc=pass
AND sender internal
AND risky sign-in within 24h
AND inbox rule or outbound spike

Phishing delivered and clicked:

email delivered
AND high-risk URL
AND user clicked

3.28 False Positive Yönetimi

Allowlist kuralları dar olmalı: domain + IP/ASN + DKIM selector + sender address + use-case + time window + owner

Not: "trusted-vendor.com allow" gibi geniş allowlist, saldırgana kalıcı bypass kapısı açar.

3.29 Triage Playbook

Soru Tablosu

Toplanması Gereken/önerilen Artifact Tablosu

3.30 Severity ve SLA

Containment örnekleri:

• • Quarantine/purge message

• • Block sender/domain/IP/URL

• • Disable malicious OAuth app

• • Revoke sessions

• • Remove inbox rules

• • Disable external forwarding

• • Reset credentials

• • Notify users

• • Update DMARC/vendor config

• • Open DNS rollback

3.31 Detection Olgunluk Modeli

D2 → D3 geçişi için:

• [ ] AuthenticationDetails parse_json standardı

• [ ] compauth reason-code triyajı

• [ ] parsedmarc SIEM pipeline

• [ ] Reply-To header triyaj prosedürü

• [ ] Direct Send baseline

• [ ] DNS drift alerting

• [ ] UrlClick correlation

• [ ] Mailbox audit correlation

3.32 Araç ve Somut Sinyal Ekleri

3.32.1 RUA Parse Aracı — parsedmarc (Somut Pipeline)

§3.4/3.7'deki "RUA'yı SIEM'e sok" tavsiyesinin somut karşılığı parsedmarc'tır (aktif geliştirilen, açık kaynak Python aracı; RFC 9990/9991 ve TLS-RPT şemalarını destekler).

pip install parsedmarc
parsedmarc -c parsedmarc.ini

[general]
save_aggregate = True
save_forensic = True


[imap]
host = outlook.office365.com
user = dmarc-agg@hedef.com
password = ...

[mailbox]
watch = True
delete = False

[elasticsearch]
hosts = http://localhost:9200
ssl = False

[splunk_hec]
url = https://splunk.hedef.com:8088
token = ...
index = dmarc

Bu konfigürasyon, rua@/ruf@ kutusunu IMAP üzerinden düzenli tarar, RFC 9990 (aggregate)/RFC 9991 (failure) XML'lerini ayrıştırır ve doğrudan Elasticsearch veya Splunk HEC'e besler. §3.7'deki <discovery_method>, <policy_override>, <envelope_from> gibi DMARCbis alanları dahil.

Alternatif (kurumsal/SaaS tercih edenler için): dmarcian, Valimail, EasyDMARC, PowerDMARC aynı işlevi UI ile sunar, kendi altyapınızı işletmek istemiyorsanız tercih edilebilir.

3.32.2 Yeni EmailEvents Kolonları (Ocak 2026) ile Sadeleştirilmiş Sorgular

Microsoft'un şema değişiklik günlüğü, §3.10–3.24'teki bazı sorguları basitleştiren iki yeni sütun ekledi:

// Native ForwardingInformation ile auto-forward tespiti — CloudAppEvents'e gitmeden
EmailEvents
| where Timestamp > ago(7d)
| where isnotempty(ForwardingInformation)
| where EmailDirection in ("Outbound", "Intra-org")
| project Timestamp, SenderFromAddress, RecipientEmailAddress, ForwardingInformation, DeliveryAction

// IsFirstContact ile sadeleşmiş display-name/cousin-domain kuralı (§3.21'in kısaltılmış hali)
EmailEvents
| where Timestamp > ago(1d)
| where IsFirstContact == true
| where SenderDisplayName has_any ("CEO", "CFO", "Finans Direktörü", "Genel Müdür")
| where SenderFromDomain != "hedef.com"
| extend AuthData = parse_json(AuthenticationDetails)
| where tostring(AuthData.DMARC) != "pass"
| project Timestamp, SenderDisplayName, SenderFromAddress, RecipientEmailAddress, IsFirstContact, Subject

Not: Bu kolonlar tenant'ınızın şema sürümüne bağlıdır. sorguyu üretime almadan EmailEvents | getschema ile kolonun ortamınızda mevcut olduğunu doğrulayın yoksa mevcut CloudAppEvents-tabanlı yaklaşımınız (§3.24) geçerliliğini korur, bu yalnızca bir sadeleştirmedir zorunlu değişiklik değildir.

3.32.3 SMTP Smuggling (Postfix Log Sinyali)

§3.26'daki kavramsal "bare LF rejection/normalization" sinyalinin, gerçek log dosyasında arayacağınız satır:

# Postfix — smtpd_forbid_bare_newline aktifken bir smuggling denemesi engellendiğinde üretilir
grep "bare <LF> received" /var/log/mail.log

# Otomatik izleme (cron veya log-forwarder ile SIEM'e besleme)
tail -F /var/log/mail.log | grep --line-buffered "bare <LF> received" | \
  logger -t smtp-smuggling-alert

Yorumlama:

• Bu satırın varlığı → bir smuggling denemesi gerçekten yapıldı ve engellendi (IOC, kaynak IP'yi izleyin).

• Bu satırın yokluğu → tek başına "güvendeyim" anlamına gelmez. Ya hiç deneme olmadı ya da smtpd_forbid_bare_newline ayarınız aktif değil. Ayarın gerçekten devrede olduğunu ayrıca doğrulayın:

postconf smtpd_forbid_bare_newline
# Beklenen çıktı: smtpd_forbid_bare_newline = normalize  (veya yes)

3.32.4 CVE-2025-61084 Sınıfı Unicode Tespit Regex'i

§3.9'daki "Unicode invisible chars" maddesinin uygulanabilir hali Form: başlığında görünen ad ile gerçek adres arasına gizlenen ince-boşluk/sıfır-genişlik karakterlerini arar:

[\x{2000}-\x{200F}\x{2028}-\x{202F}\x{FEFF}]

// Ham From header'da invisible/thin-space karakter taraması
EmailEvents
| where Timestamp > ago(7d)
| where SenderFromAddress matches regex @"[\x{2000}-\x{200F}\x{2028}-\x{202F}\x{FEFF}]"
| project Timestamp, SenderFromAddress, RecipientEmailAddress, Subject, DeliveryAction

# Postfix/Sendmail raw header taraması (SIEM'e beslenmeden önce ham log üzerinde)
grep -P "From:.*[\x{2000}-\x{200F}\x{2028}-\x{202F}\x{FEFF}]" /var/log/maillog

Not: Bu regex'in çalışması için ham (raw) Form: header verisine erişmeniz gerekir. Çoğu SIEM/log toplama pipeline'ı varsayılan olarak Unicode normalizasyonu yapar ve bu karakterleri sessizce temizler/kaybeder. EmailEvents.SenderFromAddress alanının bu karakterleri ham haliyle koruyup korumadığını kendi tenant'ınızda test edin korumuyorsa mail gateway'inizin "raw header logging" özelliğini (varsa) ayrıca etkinleştirin.

3.33 Sonuç

E-posta detection, authentication sonuçlarını okumakla başlar ama orada bitmez. DMARC fail exact-domain spoofing için güçlü alarmdır fakat cousin-domain, display-name spoofing ve ele geçirilmiş gerçek hesap saldırılarında DMARC pass görülebilir. Bu yüzden SOC modeli; Authentication-Results, compauth reason code, DMARC RUA/RUF, mail gateway verdict, URL/attachment analizi, DNS/domain reputation, CT logs, mailbox audit ve identity telemetry'yi birlikte korele etmelidir.

Authentication fail saldırı sinyalidir. Authentication pass ise yalnızca kimlik doğrulama katmanının geçtiğini söyler phishing, BEC ve account compromise tespiti için header, domain, içerik, kullanıcı aksiyonu ve identity davranışı birlikte analiz edilmelidir.