อีเมล Phishing ผ่าน SPF DKIM DMARC ได้อย่างไร ไล่ดูทีละด่าน

นี่คือเรื่องของอีเมลหนึ่งฉบับ ทุกอย่างในเรื่องเป็นเรื่องสมมติ ทั้งบริษัท คน และโดเมน ชื่อโดเมนทั้งหมดลงท้ายด้วย .example ซึ่งเป็น top-level domain ที่ RFC 2606 สงวนไว้สำหรับเอกสารและตัวอย่าง จึงไม่มีทางเป็นของใครจริง สิ่งที่เป็นของจริงคือกลไกที่อีเมลต้องผ่านก่อนถึงกล่องจดหมาย และจุดที่กลไกเหล่านั้นถูกหลอกได้ครับ

บริษัทสมมติของเราชื่อ Example Corp ใช้โดเมนอีเมล corp.example ผู้อ่านสมมติของเราชื่อดาว ทำงานที่นั่น เช้าวันจันทร์ มีข้อความใหม่รออยู่

สิ่งที่ดาวเห็น

แอปอีเมลของดาวแสดงแค่สามอย่าง:

• From: IT Service Desk
• Subject: Action needed today
• เนื้อหา: "Your password expires in 24 hours. Please confirm here: [Your account]"

สำหรับคนส่วนใหญ่ นี่คือภาพทั้งหมด ชื่อที่ดูเป็นมิตร เส้นตาย และปุ่มหนึ่งปุ่ม สังเกตว่าแอปแสดง display name ("IT Service Desk") และซ่อนที่อยู่อีเมลจริงไว้ จนกว่าดาวจะแตะดู รายละเอียดนี้จะสำคัญในภายหลังครับ

สิ่งที่ header บอก

เบื้องหลังหน้าจอที่ดูเรียบร้อย อีเมลทุกฉบับมี header และมีหนึ่งบรรทัดที่ mail server ฝั่งผู้รับเติมเข้าไปเพื่อบันทึกผลการตรวจ ชื่อว่า Authentication-Results นิยามไว้ใน RFC 8601 สำหรับอีเมลสมมติของเรา อาจหน้าตาแบบนี้:

From: "IT Service Desk" <it-desk@corp.example>
Authentication-Results: mx.corp.example;
  spf=pass smtp.mailfrom=bounce.mailer.example;
  dkim=pass header.d=mailer.example;
  dmarc=fail header.from=corp.example

ผ่านสอง ไม่ผ่านหนึ่ง จะเข้าใจว่าทำไม ต้องไล่ดูทีละด่าน

ด่านที่ 1: SPF ถามว่า "server นี้ส่งแทนโดเมนนั้นได้ไหม"

Sender Policy Framework นิยามไว้ใน RFC 7208 เจ้าของโดเมนประกาศ DNS TXT record ที่ขึ้นต้นด้วย v=spf1 พร้อมรายชื่อ server ที่ได้รับอนุญาตให้ส่งอีเมลในนามโดเมนนั้น server ผู้รับดู IP address ที่เชื่อมต่อเข้ามา แล้วเทียบกับรายชื่อนี้

จุดสำคัญคือ SPF ตรวจโดเมน ไหน มันดูชื่อใน HELO และ envelope sender (MAIL FROM) ซึ่งเป็นที่อยู่สำหรับรับ bounce ไม่ใช่บรรทัด From: ที่ดาวเห็น RFC เขียนไว้ชัดว่าการตรวจเหล่านี้ ไม่ได้รับรอง identity อื่น "such as the From: header field"

ผู้โจมตีในเรื่องของเราจึงแค่ใช้ envelope address บนโดเมนที่ตัวเองควบคุม คือ bounce.mailer.example แล้วประกาศ SPF record ให้มัน ผล SPF จึงเป็น pass และก็ถูกต้องด้วย server นั้นได้รับอนุญาตให้ส่งแทน bounce.mailer.example จริง เพียงแต่ไม่เกี่ยวอะไรกับ corp.example เลยครับ

เรื่อง SPF อื่นๆ ที่ควรรู้:

• ผลที่เป็นไปได้มี pass, fail, softfail, neutral, none, temperror และ permerror (section 2.6)
• การประเมินหนึ่งครั้งเรียก term ที่ต้อง query DNS (include, a, mx ฯลฯ) ได้ไม่เกิน 10 ครั้ง ถ้าเกินจะได้ permerror (section 4.6.4)
• การ forward อีเมลทำให้ SPF fail ได้ง่าย เพราะสิ่งที่ถูกตรวจคือ IP ของตัว forward ไม่ใช่ของผู้ส่งต้นทาง (section 10.3)

ด่านที่ 2: DKIM ถามว่า "โดเมนนี้เซ็นข้อความนี้ และข้อความไม่ถูกแก้ใช่ไหม"

DomainKeys Identified Mail คือ RFC 6376 ซึ่งเป็น Internet Standard ระบบผู้ส่งเติม header DKIM-Signature ที่มี hash ของ body (bh=), รายชื่อ header ที่ถูกเซ็น (h=), ตัว signature (b=), โดเมนผู้เซ็น (d=) และ selector (s=) ผู้รับดึง public key จาก DNS ที่ <selector>._domainkey.<domain> แล้วตรวจสอบ

signature ที่ผ่านพิสูจน์สองอย่าง: โดเมนใน d= ยอมรับความรับผิดชอบบางส่วนต่อข้อความ และส่วนที่ถูกเซ็นไม่ถูกแก้ไขหลังจากเซ็น แต่มัน ไม่ได้ บอกว่าโดเมนนั้นน่าเชื่อถือ และมาตรฐาน ไม่ได้บังคับให้ identity ผู้เซ็นต้องตรงกับผู้ส่งที่ผู้ใช้เห็น

ผู้โจมตีของเราเซ็นข้อความด้วย key ของตัวเองสำหรับ mailer.example ผล DKIM จึงเป็น pass และก็ถูกต้องอีกเช่นกัน

ด่านที่ 3: DMARC ถามว่า "ผลที่ผ่านนั้น เป็นของโดเมนใน From หรือเปล่า"

นี่คือด่านที่เชื่อมการตรวจทางเทคนิคเข้ากับสิ่งที่ดาวเห็นจริง DMARC เผยแพร่ครั้งแรกเป็น RFC 7489 เมื่อมีนาคม พ.ศ. 2558 ในฐานะเอกสารประเภท Informational ไม่ใช่มาตรฐาน ต่อมาในพฤษภาคม พ.ศ. 2569 ฉบับนี้ถูกยกเลิกและแทนที่ด้วย RFC 9989 ซึ่งเป็น Proposed Standard และมี RFC คู่กันสำหรับเรื่อง report อีกสองฉบับ คือ 9990 และ 9991 แนวคิดหลักของทั้งสองฉบับเหมือนกัน คือ alignment

อีเมลจะผ่าน DMARC ได้ก็ต่อเมื่อ SPF หรือ DKIM ผ่าน และ โดเมนที่ผ่านนั้น align กับโดเมนใน header From: ในโหมด relaxed ทั้งสองโดเมนต้องอยู่ใต้ organizational domain เดียวกัน ในโหมด strict ต้องตรงกันทุกตัวอักษร (section 3.1)

ในเรื่องของเรา From: บอกว่า corp.example SPF ผ่านสำหรับ bounce.mailer.example DKIM ผ่านสำหรับ mailer.example ไม่มีอันไหน align เลย DMARC จึงบอกว่า fail

   │                                                            
   │                header From: corp.example                   
   J                                                            
                                                    ┌──────────┐
                  ┊            ┊            ┊       │  INBOX   │
                  ┊            ┊            ┊       │          │
  ┌───┐           ┊            ┊            ┊       │          │
  │\ /│ ─────────════════════───────────────────────│ ──────── │
  └───┘           ┊            ┊            ┊       │ ──────── │
                  ┊            ┊            ┊       │          │
                  ┊            ┊            ┊       │ ──────── │
                 SPF          DKIM        DMARC     │ ──────── │
                                                    └──────────┘
                                                                
                                                                
                                                                

ทำไม p=none ไม่ได้ปกป้องใคร

ตรงนี้คือจุดหักมุมครับ การ fail DMARC ไม่ได้หยุดอะไรด้วยตัวมันเอง ผู้รับจะไปดู policy ของเจ้าของโดเมนใน TXT record ที่ _dmarc.corp.example และ tag p= บอกว่าต้องทำอย่างไร:

ในเรื่องของเรา Example Corp ตั้ง p=none ไว้แล้วไม่เคยขยับต่อ RFC 9989 ฉบับใหม่ระบุว่า policy p=none ที่ตรวจพบ ต้องไม่เปลี่ยนกระบวนการจัดการอีเมลที่มีอยู่เดิม อีเมลที่ fail DMARC จึงเข้ากล่องจดหมายของดาวอยู่ดีครับ

p=none เป็น จุดเริ่มต้น ที่มีประโยชน์ report (rua=) จะบอกว่าใครบ้างส่งอีเมลในนามเรา ก่อนที่จะเริ่มบังคับใช้ ตัวอย่างเช่น Google กำหนดให้ bulk sender ที่ส่งถึง Gmail ต้องมี DMARC ตั้งแต่ 1 กุมภาพันธ์ พ.ศ. 2567 แต่ ยอมรับ policy none ส่วนคำแนะนำร่วมของ CISA, NSA, FBI และ MS-ISAC ไปไกลกว่านั้น คือแนะนำให้องค์กร ตั้ง DMARC เป็น "reject" สำหรับอีเมลที่ส่งออก การ monitor จึงเป็นช่วงหนึ่ง ไม่ใช่ปลายทางครับ

องก์ที่สอง: ผู้โจมตีเปลี่ยนตัวอักษรตัวเดียว

สมมติว่า Example Corp แก้ policy เป็น p=reject แล้ว การปลอม corp.example ตรงๆ จะ fail ทันที ผู้โจมตีจึงจดโดเมนหน้าตาคล้ายกัน c0rp-login.example (ใช้เลขศูนย์แทนตัว "o") แล้วตั้ง SPF, DKIM และ DMARC ให้ถูกต้องทุกอย่าง ทุกด่านผ่านหมด เพราะอีเมลมาจาก c0rp-login.example จริงๆ

นี่ไม่ใช่ช่องโหว่ของ DMARC แต่อยู่นอกหน้าที่ของมัน RFC 7489 ระบุว่า "visually similar domain names ("cousin domains")" และการใช้ display name ในทางที่ผิด เป็นสิ่งที่มันไม่ได้จัดการ display name เป็นข้อความอิสระ ใครจะเขียนว่า "IT Service Desk" ก็ได้

ที่เหลืออยู่คือชั้นสุดท้ายครับ

ชั้นของคน

คำแนะนำของ CISA เรื่อง การสังเกต Phishing มีสัญญาณที่ยังใช้ได้ดี:

• ภาษาเร่งรีบหรือเร้าอารมณ์: โดยเฉพาะข้อความที่อ้างว่าจะเกิดผลร้ายแรงถ้าไม่ตอบทันที "24 hours" ในอีเมลของเราทำหน้าที่นี้อยู่
• การขอให้ส่งข้อมูลส่วนตัวหรือข้อมูลทางการเงิน
• ที่อยู่อีเมลหรือลิงก์ไม่ถูกต้อง: สะกดคล้ายของจริง เช่นชื่อแบรนด์ที่ผิดไปหนึ่งตัวอักษร
• ลิงก์ย่อที่ไม่น่าไว้ใจ ซึ่งซ่อนปลายทางไว้

CISA ยังบอกด้วยว่า ไวยากรณ์ผิดหรือสะกดผิดเคยเป็นสัญญาณที่พบบ่อย แต่ในยุค AI อีเมล Phishing บางฉบับมีไวยากรณ์และการสะกดที่ถูกต้องสมบูรณ์ จึงต้องอาศัยสัญญาณอื่นมากขึ้น

นิสัยที่ใช้ได้จริงที่สุดคือดูว่าลิงก์ไปที่ไหนจริง ข้อความบนปุ่มกับปลายทางของมันเป็นสองเรื่องแยกกัน คำแนะนำของ CISA แนะนำให้ hover เมาส์บนลิงก์ก่อนคลิก ถ้าที่อยู่ที่แสดงไม่ตรงกับข้อความ ลิงก์นั้นอาจถูกปลอม

┌──────────────────────────────────────────────────────────────┐
│ ● ● ●   mail                                                 │
│──────────────────────────────────────────────────────────────│
│ • From: IT Service Desk                                      │
│   Subject: Action needed today                               │
│  Your password expires in 24 hours.                          │
│  Please confirm here: [Your account]                         │
│                                                              │
│                                                              │
│                                                   ↖          │
│──────────────────────────────────────────────────────────────│
│                                                              │
└──────────────────────────────────────────────────────────────┘
                                                                

ถ้าข้อความอาจเป็นของจริง CISA แนะนำ ว่าอย่าใช้ลิงก์หรือเบอร์โทรในข้อความนั้น ให้ติดต่อบริษัทผ่านข้อมูลติดต่อจากเว็บไซต์ที่ยืนยันแล้ว หรือติดต่อบุคคลนั้นผ่านช่องทางอื่นที่มีอยู่แล้ว เช่น เบอร์โทรศัพท์ครับ

กลเดิม หลายประตู

อีเมลเป็นเส้นทางคลาสสิก แต่ไม่ใช่ทางเดียว MITRE ATT&CK จัด Phishing เป็น technique T1566 ใน tactic Initial Access มี sub-technique สี่แบบ:

ATT&CK ระบุว่า Phishing อาจเจาะจงเป้าหมายเป็นคนหรือบริษัท หรือส่งแบบหว่านเป็นแคมเปญใหญ่ก็ได้ ในรายการ mitigation มีทั้ง user training และ software configuration ซึ่งรวม SPF, DKIM และ DMARC กล่าวอีกอย่างคือ ไม่มีชั้นไหนถูกคาดหวังให้ทำงานลำพังครับ

ดาวคลิกไปแล้ว ทำยังไงต่อ

ในเรื่องของเรา ดาวคลิก เจอหน้า login ที่ดูถูกต้อง พิมพ์รหัสผ่าน แล้วก็รู้สึกไม่ดี สิ่งที่เกิดขึ้นต่อจากนี้สำคัญกว่าการคลิกครับ

National Cyber Security Centre ของสหราชอาณาจักรพูดเรื่องนี้ตรงๆ ใน คำแนะนำเรื่อง Phishing สำหรับองค์กร ว่า "Some phishing attacks will always get through" และพนักงานควรรู้สึกว่ารายงานได้ แม้จะคลิกไปแล้ว NCSC เตือนไม่ให้สร้างวัฒนธรรมการกล่าวโทษ เพราะพนักงานที่กลัวตกงานจะไม่รายงานความผิดพลาด

สิ่งที่ช่วยได้ ตาม คำแนะนำของ CISA:

1. แจ้งทีม IT หรือทีม security ทันที เพื่อให้ทีมเฝ้าระวังความเคลื่อนไหวที่น่าสงสัยหรือผิดปกติได้
2. เปลี่ยนรหัสผ่านที่พิมพ์ไปทันที และเปลี่ยนในทุกบัญชีที่ใช้รหัสเดียวกัน
3. รายงานข้อความ เช่น ด้วยปุ่ม report ในแอปอีเมล คำแนะนำร่วมของ CISA เรียกการรายงานว่า เป็นวิธีที่มีประสิทธิภาพที่สุดวิธีหนึ่งในการปกป้ององค์กร เพราะช่วยให้ผู้ให้บริการอีเมลมองเห็นการโจมตี Phishing แบบใหม่หรือที่กำลังระบาด
4. เฝ้าดูบัญชีของตัวเอง ว่ามีรายการค่าใช้จ่ายหรือกิจกรรมที่อธิบายไม่ได้หรือไม่

คำแนะนำร่วมฉบับเดียวกันยังแนะนำ MFA แบบ FIDO หรือแบบ PKI ซึ่งระบุว่าเป็น MFA ที่ทนต่อ Phishing และเตือนว่า MFA รูปแบบที่อ่อนกว่ายังถูกเจาะผ่าน Phishing ได้

สรุปทั้งหมดในลมหายใจเดียว

SPF ตรวจ server ผู้ส่งกับ envelope domain DKIM ตรวจ signature จากโดเมนใดก็ตามที่เป็นผู้เซ็น DMARC ตรวจว่าผลเหล่านั้นเป็นของโดเมนใน From: และ policy ของมันเป็นตัวตัดสินว่าจะทำอย่างไรเมื่อไม่ใช่ ไม่มีด่านไหนตรวจว่า c0rp คือ corp หรือเปล่า ด่านสุดท้ายนั้นเป็นของคน และสิ่งที่องค์กรทำให้คนได้ดีที่สุด คือทำให้การพูดว่า "คิดว่าเผลอคลิกอะไรไปแล้ว" เป็นเรื่องง่ายและปลอดภัยครับ

แหล่งอ้างอิง

• RFC 2606: Reserved Top Level DNS Names
• RFC 8601: Message Header Field for Indicating Message Authentication Status
• RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), IETF Datatracker
• Google Workspace Admin Help: Email sender guidelines
• CISA, NSA, FBI, MS-ISAC: Phishing Guidance: Stopping the Attack Cycle at Phase One
• CISA: Recognize and Report Phishing
• CISA: Avoiding Social Engineering and Phishing Attacks
• MITRE ATT&CK: Phishing, Technique T1566
• NCSC: Phishing attacks: defending your organisation