EML Header Viewer: เปิดดู header อีเมลและจับ phishing ก่อนที่มันจะหลอกคุณ
ใช้ EML Header Viewer เปิดไฟล์ .eml ในเบราว์เซอร์เพื่อตรวจ header, ผลการตรวจ SPF/DKIM/DMARC, ความไม่ตรงกันของ Reply-To และ Received chain โดยไม่ต้องอัปโหลดไฟล์
Table of Contents
อีเมล phishing มักเล่าเรื่องราวสองรอบ: รอบแรกอยู่ที่เนื้อหาข้อความซึ่งถูกเขียนขึ้นมาเพื่อหลอกลวงคุณ และอีกรอบคือ header ของอีเมล ซึ่งเป็นจุดที่ความจริงทางเทคนิคมักหลุดออกมาเสมอ ปัญหาคือ mail client ส่วนใหญ่มักซ่อน header เหล่านี้ไว้หลังเมนู "show original" ที่เต็มไปด้วยศัพท์เทคนิคยาก ๆ ตัว EML Header Viewer ช่วยแก้ปัญหานี้โดยให้คุณเปิดไฟล์ .eml ได้โดยตรงในเบราว์เซอร์ พร้อมจัดวางหลักฐานให้อ่านง่าย ทั้ง header ฉบับเต็ม ผลการตรวจ SPF/DKIM/DMARC ความไม่ตรงกันระหว่าง Reply-To กับ From และ Received chain ฉบับสมบูรณ์ โดยทุกอย่างถูกประมวลผลในเครื่องของคุณ ไม่มีการอัปโหลดไฟล์ขึ้นเซิร์ฟเวอร์ใด ๆ
ไฟล์ .eml คือข้อความดิบของอีเมลฉบับเดิม ตรงตามที่มันเดินทางข้ามอินเทอร์เน็ตมา เมื่อเพื่อนร่วมงานส่งต่ออีเมลที่น่าสงสัย หรือฝ่ายการเงินได้รับใบแจ้งหนี้ปลอม การบันทึกอีเมลนั้นเป็นไฟล์ .eml จะเก็บ header ทุกบรรทัดที่ mail app ปกติซ่อนไว้ จากนั้นนำไฟล์มาวางในตัว viewer คุณก็จะคัดกรอง (triage) ข้อความได้เหมือนนักวิเคราะห์ความปลอดภัย คือตรวจว่าใครส่งจริง มาจากไหนจริง และข้อมูลการยืนยันตัวตนตรงกันหรือไม่
บทความนี้จะพาคุณไปดูวิธีใช้งานเครื่องมือ วิธีอ่านค่าที่เครื่องมือแสดง และวิธีเปลี่ยน header ไม่กี่บรรทัดให้กลายเป็นการตัดสินใจแบบ go/no-go ที่มั่นใจได้
เหตุใดควรใช้ EML Header Viewer?
- ทำ phishing triage ในเครื่อง ไม่มีการอัปโหลด ไฟล์ถูกประมวลผลทั้งหมดในเบราว์เซอร์ของคุณ อีเมลที่ละเอียดอ่อน เช่น ใบแจ้งหนี้ สัญญา หรือบทสนทนาภายในองค์กร จึงไม่มีวันออกจากเครื่องของคุณระหว่างการตรวจสอบ
- สรุปผลการยืนยันตัวตนโดยไม่ต้องเดา แทนที่จะไล่อ่านค่า Authentication-Results เอง เครื่องมือสรุปผล SPF, DKIM และ DMARC ของอีเมลฉบับนั้นออกมาเป็นภาษาที่อ่านเข้าใจได้ทันที
- ตรวจจับ Reply-To mismatch เทคนิคเก่าแก่ที่สุดอย่างหนึ่งของ phishing คือแสดงที่อยู่ From ที่ดูน่าเชื่อถือ แต่สั่งให้การตอบกลับไปลงกล่องจดหมายของผู้โจมตี เครื่องมือจะเทียบ Reply-To กับ From แล้วเตือนทันทีเมื่อไม่ตรงกัน
- เดินตาม Received chain ได้ทีละ hop ไล่ดูแต่ละ hop จากเซิร์ฟเวอร์ผู้ส่งถึงกล่องจดหมายของคุณ เพื่อจับ relay ที่ผิดปกติ ประเทศที่แปลก หรือโดเมนผู้ส่งที่ไม่ตรงกับเครือข่ายที่เชื่อมต่อเข้ามาจริง
- เห็น header ครบทุกแถว ไม่มีอะไรถูกซ่อน ทั้ง Message-ID, X-Mailer, ลายเซ็น DKIM และ X- header อื่น ๆ ยังอยู่ในสายตา สิ่งที่ผู้ส่งแอบแทรกมาจึงรอดสายตาไม่ได้
- ฟรี รวดเร็ว และเหมาะกับการฝึกอบรม ไม่ต้องสมัครบัญชี ไม่ต้องติดตั้ง ไม่มีความเสี่ยง จึงเหมาะกับการอบรม security awareness ที่ให้พนักงานฝึกตรวจตัวอย่างจริงอย่างปลอดภัย
คุณสมบัติหลักของ EML Header Viewer
| คุณสมบัติ | สิ่งที่ทำ |
|---|---|
| อ่านไฟล์ .eml ในเครื่อง | เปิดไฟล์ .eml ในเบราว์เซอร์และประมวลผลบนอุปกรณ์ของคุณทั้งหมด ไม่มีการอัปโหลด ไม่มีการประมวลผลบนเซิร์ฟเวอร์ |
| ตรวจ header ฉบับเต็ม | แสดง header ทุกแถว ตั้งแต่ From และ Reply-To ไปจนถึง Message-ID และ X- header เฉพาะต่าง ๆ |
| สรุปผล SPF/DKIM/DMARC | อ่านค่า Authentication-Results และสรุปผลผ่าน/ไม่ผ่านของการตรวจสอบสิทธิ์อีเมลแต่ละแบบ |
| ตรวจจับ Reply-To mismatch | เทียบที่อยู่ Reply-To กับ From แล้วแจ้งเตือนเมื่อการตอบกลับจะถูกส่งไปที่อื่น |
| เดินตาม Received chain | แสดงแต่ละ Received hop เพื่อให้ไล่เส้นทางการส่งของอีเมลจากต้นทางถึงกล่องขาเข้าได้ |
- มุมมองสรุปผลยุบการตรวจสอบทั้งสามแบบไว้ในหน้าเดียว คุณจะเห็นทันทีว่าอีเมลฉบับนี้จะไม่ผ่านนโยบายของผู้ให้บริการอีเมลหรือไม่
- มุมมอง Received chain คงลำดับและรายละเอียดของทุก hop ทั้ง timestamp ชื่อเซิร์ฟเวอร์ และที่อยู่ IP ซึ่งเป็นวัตถุพยานที่นักสืบต้องใช้ในการสร้างเส้นทางการส่งขึ้นมาใหม่
วิธีใช้งาน EML Header Viewer
- บันทึกอีเมลที่น่าสงสัยเป็นไฟล์ .eml ใน Gmail ให้เปิดอีเมล กดเมนูสามจุด แล้วเลือก "Download message" ส่วนใน Outlook ให้ใช้ "Save As" แล้วเลือกนามสกุล .eml ไฟล์ .eml จะเก็บ header ต้นฉบับไว้ครบถ้วน ส่วนการส่งต่ออีเมลแทนอาจทำให้ header ถูกลบหรือถูกเขียนใหม่
- เปิดไฟล์ใน EML Header Viewer เข้าไปที่เครื่องมือในเบราว์เซอร์แล้วโหลดไฟล์ .eml การประมวลผลจะเกิดขึ้นบนอุปกรณ์ของคุณภายในไม่กี่วินาที
- อ่านผลการยืนยันตัวตน เริ่มจาก SPF, DKIM และ DMARC หาก DMARC ไม่ผ่านพร้อมกับโดเมน From ที่หน้าตาคล้ายของจริง นั่นแทบเป็นหลักฐานชัดเจน ส่วนผลที่ผ่านหมดยังไม่ใช่ใบรับรองความปลอดภัย
- เดินตาม Received chain อ่านแต่ละ hop จากล่างขึ้นบน เพราะ hop แรกสุด (ต้นทางจริง) อยู่ท้ายสุดของ chain ตรวจว่าอีเมลเกิดขึ้นที่ไหนกันแน่ ผ่านเซิร์ฟเวอร์ใดบ้าง และ timestamp สมเหตุสมผลหรือไม่
- ตัดสินใจแบบ go/no-go รวมผลการยืนยันตัวตน ผลเทียบ Reply-To และเส้นทางทั้งหมดเข้าด้วยกัน แล้วสรุปว่า ปล่อยผ่านได้ รายงานว่าเป็น phishing หรือควรส่งต่อให้ทีมความปลอดภัย
อ่าน header อย่างมืออาชีพแบบนักสืบ
Header จะให้รางวัลกับผู้ที่อ่านตามลำดับที่ถูกต้อง เมื่อคุณรู้ว่าผู้โจมตีมักพลาดตรงไหน อีเมล phishing ส่วนใหญ่จะเผยตัวเองภายในไม่ถึงนาที
เริ่มจากการเทียบ From กับ Reply-To Mail client จะตอบกลับไปที่ที่อยู่ Reply-To ไม่ใช่ From และชุดเครื่องมือโจมตีหลายตัวตั้งค่าให้ทั้งสองต่างกันโดยเจตนา อีเมลที่อ้างว่ามาจาก CFO แต่ Reply-To ชี้ไปที่เว็บเมลฟรี คือรูปแบบคลาสสิกของ business email compromise บริการที่ถูกต้องตามกฎหมายบางครั้งก็แยกสองค่านี้เพื่อการ routing งาน support แต่ถ้าโดเมนไม่เกี่ยวข้องกันเลย โดยเฉพาะ Reply-To ที่เขียนชื่อบริษัทคุณแบบสลับตัวอักษรหนึ่งตัว ให้ถือว่าเป็นภัย นี่คือจุดที่เครื่องมือไฮไลต์ให้อัตโนมัติ
อ่าน Received chain จากล่างขึ้นบน จุดนี้มักทำให้มือใหม่แปลกใจ เพราะเซิร์ฟเวอร์ทุกตัวที่แตะอีเมลจะเติม Received header ของตัวเองต่อท้าย ทำให้ hop แรก (ต้นทางจริง) อยู่ล่างสุดของ chain และเซิร์ฟเวอร์เมลของคุณเองอยู่บนสุด การอ่านจากล่างขึ้นบนจะเผยถิ่นกำเนิดจริงของอีเมลก่อนที่มันจะถูกซักผ่าน relay ต่าง ๆ ให้จับตาผู้ส่งที่อ้างโดเมนองค์กร แต่ hop แรกกลับมาจากช่วง IP ของบ้านหรือผู้ให้บริการ hosting ในประเทศที่บริษัทไม่มีสำนักงาน timestamp ควรไล่ไปข้างหน้าอย่างต่อเนื่อง ถ้ามีช่องว่างใหญ่หรือเวลาย้อนกลับ ให้สงสัยว่าถูกแก้ไข
ตีความ SPF, DKIM และ DMARC ร่วมกัน พร้อมเช็ค alignment SPF ตรวจว่าเซิร์ฟเวอร์ผู้ส่งได้รับอนุญาตให้ส่งในนามโดเมน envelope หรือไม่ DKIM ตรวจว่าเนื้อหาถูกเซ็นด้วยกุญแจของโดเมนจริง ส่วน DMARC ตรวจว่าตัวที่ผ่านนั้นสอดคล้อง (align) กับโดเมน From ที่คุณเห็นหรือไม่ อีเมลอาจ "ผ่าน" DKIM ทางเทคนิคแต่ยังเป็น phishing ได้ ถ้าลายเซ็นเป็นของโดเมนอื่นที่ไม่เกี่ยวข้อง นั่นคือ pass ที่ไม่ align กับ From ที่มองเห็น ด้วยเหตุนี้ผล DMARC จึงมักเป็นตัวตัดสิน เพราะมันผูกการยืนยันตัวตนเข้ากับตัวตนที่ผู้รับเห็น
ระวังการปลอม display name ชื่อที่แสดงผลอย่าง "Microsoft Support [email protected]" เป็นเพียงฉากตกแต่งที่ใครก็ตั้งเป็นอะไรก็ได้ ให้อ่านที่อยู่จริงในเครื่องหมาย angle bracket เสมอ เพราะ display name คือส่วนที่น่าเชื่อถือน้อยที่สุดใน header ทั้งหมด
แปลผลการตรวจเป็นการตัดสินใจ DMARC ไม่ผ่าน DKIM ผ่านแต่ไม่ align และ Reply-To ไม่ตรงกัน รวมกันคือ no-go: รายงานอีเมลแล้วปิดเรื่อง ส่วนผลผ่านสวยงามจากโดเมนที่รู้จัก Reply-To ตรงกัน และ Received chain ปกติ ก็มักปลอดภัยพอที่จะดำเนินการต่อ ส่วนโซนสีเทา เช่น ผลผ่านหมดแต่ hop แรกแปลก หรือค่า X-Mailer น่าสงสัย ควรส่งต่อให้ผู้เชี่ยวชาญแทนการตัดสินเอง
กรณีการใช้งานจริง
ตรวจสอบใบแจ้งหนี้ปลอม
ฝ่ายการเงินคือเป้าหมายชั้นดีของใบแจ้งหนี้ปลอมและการเปลี่ยนเลขบัญชีธนาคาร เมื่อใบแจ้งหนี้มาพร้อมข้อความว่า "ข้อมูลการชำระเงินมีการอัปเดต" ให้บันทึกเป็น .eml แล้วตรวจก่อนที่ใครจะลงมือ ถ้า Reply-To ชี้ไปกล่องเมลส่วนตัว โดเมน From เพี้ยนไปหนึ่งตัวอักษรจากซัพพลายเออร์จริง หรือ hop แรกมาจาก IP บ้าน รายการชำระเงินปกติก็กลายเป็นเคสที่ต้อง escalate ทันที และอาจช่วยหยุดการโอนเงินให้อาชญากรได้ทันเวลา
การฝึกอบรม Security Awareness
วิธีสอนเรื่อง phishing ที่ดีที่สุดคือให้ผู้เรียนได้สืบสวนเองจริง ๆ มอบตัวอย่าง .eml จากแคมเปญซ้อมจู่โจมหรือเหตุการณ์จริงที่ปกปิดตัวตนแล้ว แล้วให้ผู้เรียนหา Reply-To mismatch หาผล DMARC ที่ไม่ผ่าน และไล่ Received chain เพราะการประมวลผลเป็นแบบ local พนักงานจึงฝึกกับตัวอย่างจริงได้โดยข้อมูลไม่หลุดออกจากห้อง ซึ่งเปลี่ยนคำเตือนลอย ๆ ให้กลายเป็นทักษะที่พวกเขาได้ลงมือใช้จริง
การคัดกรองไฟล์แนบที่ Helpdesk
ทีม Helpdesk มักเป็นผู้แรกที่ได้รับคำถามว่า "อีเมลนี้ของจริงไหม" แทนที่จะเสี่ยงเปิดไฟล์แนบเพื่อดูข้างใน ให้ขอไฟล์ .eml จากผู้แจ้ง แล้วตัดสินอย่างรวดเร็วและป้องกันตัวได้จาก header เพียงอย่างเดียว ไฟล์แนบจะยังคงไม่ถูกเปิด ซึ่งเป็นสิ่งที่คุณต้องการที่สุดระหว่าง triage ในขณะที่ผู้แจ้งก็ได้คำตอบภายในไม่กี่นาที
การวิเคราะห์ขั้นแรกสำหรับ Forensics
สำหรับผู้ตอบสนองเหตุการณ์ viewer ตัวนี้คือเครื่องมือ first-pass ที่เร็วก่อนลงมือวิเคราะห์หนัก ๆ header ให้ artifact ที่ใช้งานได้ทันที ทั้งโดเมนใน Message-ID ที่อยู่ IP ต้นทางจาก Received chain ชื่อ DKIM selector และโครงสร้าง Reply-To ต่าง ๆ ข้อมูลเหล่านี้ป้อนเข้าสู่การสอบสวนขั้นถัดไปได้ตรง และผลลัพธ์ยังจับคู่ได้ดีกับการตรวจ homoglyph เพื่อเปิดเผยอักขระหน้าตาคล้ายที่ซ่อนอยู่ในโดเมน From
แนวปฏิบัติที่ดีที่สุด
- เชื่อ Received chain มากกว่า display name Display name เป็นข้อความอิสระที่ใครก็พิมพ์ได้ แต่ chain ของเซิร์ฟเวอร์ที่รับส่งอีเมลจริงไม่ใช่ เมื่อทั้งสองขัดแย้งกัน ให้เชื่อ chain
- อย่าเปิดไฟล์แนบระหว่าง triage ดึงสิ่งที่ต้องการจากไฟล์ .eml เอง เอกสารข้างในอาจเป็น payload และการเปิดมันบนเครื่อง production คือวิธีเปลี่ยนงาน triage ให้กลายเป็นเหตุการณ์ด้านความปลอดภัย
- รายงาน phishing ที่ยืนยันแล้วทุกครั้ง ใช้ปุ่มรายงานใน mail client และแจ้งทีมความปลอดภัย การตรวจแล้วเงียบทิ้งทำให้คนที่เหลือในองค์กรยังเสี่ยงกับแคมเปญเดิม
- เก็บตัวอย่างไว้ใช้ฝึกอบรม เมื่อปกปิดข้อมูลผู้ส่งแล้ว ตัวอย่าง phishing ที่ยืนยันแล้วคือสื่อการสอนที่มีค่าที่สุดที่โปรแกรมความปลอดภัยจะมีได้
- ประกอบสัญญาณอ่อนหลายอย่างเข้าด้วยกัน header แปลกหนึ่งจุดคือสัญญาณรบกวน แต่ DMARC ไม่ผ่าน + Reply-To ไม่ตรง + hop แรกผิดคาด คือรูปแบบ (pattern) จงตัดสินจาก pattern ไม่ใช่ข้อมูลจุดเดียว
- ยืนยันเรื่องเงินผ่านช่องทางอื่นเสมอ ไม่ว่า header จะสะอาดแค่ไหน ให้ยืนยันการเปลี่ยนบัญชีหรือข้อมูลการชำระเงินผ่านเบอร์โทรที่รู้จักหรือพบตัวกัน ไม่ใช่ผ่านที่อยู่ที่พบในอีเมลฉบับนั้น
พร้อมตรวจอีเมลที่น่าสงสัยแล้วหรือยัง? เปิด EML Header Viewer วางไฟล์ .eml ของคุณลงไป แล้วรับผลตรวจครบชุดภายในไม่กี่วินาที โดยไม่ต้องอัปโหลดข้อมูลแม้แต่ไบต์เดียว
เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:
- Email Authentication Chain Checker - ตรวจค่าตั้ง SPF, DKIM และ DMARC ของโดเมนของคุณเอง
- Email Header Parser - วาง header ดิบเพื่อดูผลแยกส่วนอย่างรวดเร็ว
- Homoglyph Detector - เปิดเผยอักขระหน้าตาคล้ายที่ซ่อนอยู่ในโดเมนลวง
ขอให้คุณปลอดภัยจากภัยออนไลน์ทุกวัน!
คำถามที่พบบ่อย
ถ: ใช้ EML Header Viewer แล้วอีเมลของฉันถูกอัปโหลดไปที่ไหนหรือไม่? ตอบ: ไม่ เครื่องมือประมวลผลไฟล์ .eml ทั้งหมดในเบราว์เซอร์ของคุณ อีเมลจึงไม่เคยออกจากอุปกรณ์ ทำให้ใช้กับอีเมลลับ ตัวอย่างจากเหตุการณ์ความปลอดภัย หรือข้อมูลที่อยู่ใต้กฎระเบียบได้อย่างปลอดภัย
ถ: หาไฟล์ .eml จาก Gmail หรือ Outlook ได้อย่างไร? ตอบ: ใน Gmail ให้เปิดอีเมล กดเมนูสามจุด แล้วเลือก "Download message" ส่วน Outlook บนเดสก์ท็อปให้เปิดอีเมลแล้วใช้ File > Save As โดยเลือกนามสกุล .eml ทั้งสองวิธีจะได้ไฟล์ที่เก็บ header ต้นฉบับไว้โดยไม่ถูกแก้ไข
ถ: ถ้า SPF, DKIM และ DMARC ผ่านทั้งหมด แปลว่าอีเมลนั้นปลอดภัยแน่นอนใช่ไหม? ตอบ: ไม่จำเป็นเสมอไป ผลที่ผ่านพิสูจน์ว่าอีเมลถูกยืนยันตัวตนอย่างถูกต้องในนามโดเมนที่ถูกเซ็นเท่านั้น แต่ใครก็จดทะเบียนโดเมนของตัวเองที่ดูน่าเชื่อถือ ตั้งค่าอย่างเรียบร้อย แล้วยังหลอกคุณได้ การยืนยันตัวตนยืนยันว่าผู้ส่งคือคนที่ header อ้างว่าเป็น ไม่ใช่ว่าเนื้อหาน่าเชื่อถือ
ถ: ใช้เครื่องมือนี้กับอีเมลจาก mail app บนมือถือได้หรือไม่? ตอบ: ได้ ตราบใดที่ export อีเมลออกมาเป็นไฟล์ .eml ได้ client บนเดสก์ท็อปและ webmail ส่วนใหญ่มีตัวเลือกนี้ สำหรับมือถือวิธีที่ง่ายที่สุดมักเป็นการส่งต่อตัวอย่างไปยัง client เดสก์ท็อปก่อน แล้วจึง export ออกมาจากที่นั่น