Phân loại và điều tra email phishing với AI hỗ trợ

Playbook giúp SOC dùng AI để phân loại sơ bộ, tóm tắt dấu hiệu và định tuyến email đáng ngờ, đồng thời xác minh bằng telemetry từ email gateway, endpoint, IdP và SaaS trước khi quyết định xử lý.

Một email tự xưng là đối tác gửi tệp đính kèm. Một email khác dẫn tới trang đăng nhập SSO. Báo cáo từ người dùng thì chỉ ghi: “Có vẻ lạ, kiểm tra giúp”.

Nếu mọi trường hợp cùng đi vào một hàng đợi, SOC có thể mất thời gian ở bước triage trước khi nhận ra email nào cần ưu tiên. AI có thể hỗ trợ đọc, tóm tắt và phân tuyến nhanh hơn — nhưng không thay thế email gateway, sandbox, EDR hay quyết định của analyst.

MITRE ATT&CK xếp phishing vào kỹ thuật T1566, thuộc chiến thuật Initial Access. Mục tiêu của playbook này không phải là để AI tự kết luận “an toàn” hoặc “độc hại”, mà là biến email đáng ngờ thành một giả thuyết điều tra có cấu trúc và có thể kiểm chứng.

AI phù hợp ở đâu trong triage phishing?

Theo MITRE ATT&CK, phishing có thể là chiến dịch đại trà hoặc spearphishing — lừa đảo nhắm vào cá nhân, tổ chức hoặc ngành cụ thể. Các biến thể chính của T1566 gồm:

T1566.001 — Spearphishing Attachment: mồi nhử bằng tệp đính kèm. T1566.002 — Spearphishing Link: mồi nhử bằng liên kết. T1566.003 — Spearphishing via Service: phishing qua dịch vụ bên thứ ba, như nền tảng mạng xã hội hoặc công cụ cộng tác. T1566.004 — Spearphishing Voice: phishing qua giọng nói. Trong thực tế, email cũng có thể đóng vai trò mồi “callback”, dụ nạn nhân gọi vào một số điện thoại rồi được hướng dẫn mở URL, tải mã độc hoặc cài công cụ quản trị từ xa.

Phishing còn có thể dùng giả mạo người gửi (email spoofing) hoặc chèn nạn nhân vào một chuỗi email có sẵn (thread hijacking). Vì vậy, chỉ tìm từ khóa như “khẩn cấp”, “hóa đơn” hoặc “đăng nhập” là không đủ.

Tài liệu của Anthropic về định tuyến ticket cho thấy LLM hữu ích khi đầu vào là văn bản phi cấu trúc, nhãn phân loại thay đổi, dữ liệu gán nhãn còn hạn chế, hoặc đội vận hành cần lời giải thích dễ đọc. Mailbox báo cáo phishing có nhiều đặc điểm tương tự: nội dung đa dạng, mức độ khẩn khác nhau và đích xử lý không cố định.

Nên giới hạn AI vào ba nhiệm vụ:

Phân loại sơ bộ dạng phishing theo ATT&CK. Tóm tắt tín hiệu quan sát được và điểm chưa chắc chắn. Đề xuất tuyến xử lý phù hợp, chẳng hạn email security, endpoint, IdP, SaaS hoặc analyst review.

Không nên trao cho AI quyền tự động xóa email, chặn domain, cô lập máy hoặc xác nhận URL là an toàn.

Thiết kế taxonomy trước khi viết prompt

Chất lượng phân loại phụ thuộc trước hết vào định nghĩa nhãn. Trước khi gửi email cho mô hình, SOC nên thống nhất taxonomy với trực ca, nhóm email security và IAM.

Các trường nên có gồm:

Kênh nhận: email, dịch vụ SaaS, lời mời lịch hoặc callback. Dạng mồi nhử: tệp đính kèm, liên kết, lời mời đăng nhập, yêu cầu gọi điện hoặc chưa rõ. Mức độ điều tra: ưu tiên cao, cần phân tích hoặc thiếu dữ liệu. Đích xử lý: email security, endpoint, Identity Provider (IdP), SaaS hoặc analyst review. Tín hiệu quan sát được: chỉ ghi nhận dữ liệu hiện có, không suy diễn thành kết luận. Dữ liệu cần bổ sung: header, kết quả SPF/DKIM/DMARC, telemetry endpoint, URL click hoặc log đăng nhập.

Đừng gộp nhãn “phishing” với “malware confirmed”. Một email có dấu hiệu lừa đảo không đồng nghĩa tệp đã được thực thi, URL đã bị truy cập hay tài khoản đã bị chiếm.

SPF, DKIM và DMARC trong triage

MITRE nêu SPF, DKIM và DMARC là các cơ chế có thể hỗ trợ lọc và xác thực email:

SPF kiểm tra máy chủ được phép gửi thư thay mặt domain. DKIM hỗ trợ kiểm tra tính toàn vẹn của email qua chữ ký. DMARC cho phép áp dụng chính sách xử lý dựa trên kết quả SPF và DKIM.

Các tín hiệu này hữu ích, nhưng không tự giải quyết những tình huống như tài khoản gửi thư hợp lệ đã bị xâm phạm hoặc thread hijacking.

Quy trình đưa AI vào triage có kiểm soát

1. Lập tập case lịch sử đã được review

Bắt đầu bằng các case đã có kết luận từ analyst, chẳng hạn:

Email hợp lệ. Phishing chứa liên kết. Phishing chứa tệp đính kèm. Callback phishing. Case chưa đủ bằng chứng để kết luận.

Nếu tổ chức xử lý nhiều ngôn ngữ, tập case nên phản ánh các ngôn ngữ thực tế xuất hiện trong mailbox.

Tài liệu Anthropic nhấn mạnh rằng nhãn càng được định nghĩa rõ, việc định tuyến càng đáng tin cậy. Với SOC, điều đó có nghĩa là phải mô tả cụ thể điều kiện chuyển case sang IdP, endpoint hoặc email security, thay vì chỉ dùng nhãn chung chung như “nghi ngờ”.

2. Chuẩn hóa và giảm thiểu dữ liệu đầu vào

Chuẩn bị một biểu mẫu có các trường cần thiết:

Subject. Tên hiển thị và domain người gửi. Nội dung email. Tên tệp đính kèm. URL ở dạng an toàn để đọc. Kết quả SPF/DKIM/DMARC, nếu có. Ngữ cảnh báo cáo từ người dùng.

Không nên gửi nguyên trạng dữ liệu không cần thiết. Thông tin định danh cá nhân như tên, địa chỉ email, mã nhân sự hoặc nội dung trao đổi nội bộ nên được giảm thiểu theo chính sách dữ liệu của doanh nghiệp.

Nếu email chứa dữ liệu nhạy cảm hoặc bằng chứng điều tra, tổ chức cần xác định rõ công cụ AI nào được phép sử dụng, phạm vi truy cập, cách lưu kết quả và thời gian lưu giữ phù hợp với quy định nội bộ.

3. Buộc đầu ra theo cấu trúc

Dùng công cụ AI đã được tổ chức phê duyệt và yêu cầu đầu ra có cấu trúc cố định. Ví dụ:

text Bạn là trợ lý triage cho SOC. Chỉ phân loại sơ bộ; không kết luận email an toàn, không yêu cầu người dùng nhấp link hoặc mở tệp, và không đề xuất hành động chặn tự động.

Dựa duy nhất trên dữ liệu đầu vào, hãy trả về:

Dữ liệu email: <subject> <senderdisplayname> <senderdomain> <emailbody> <attachmentnames> <urls> <spfdkimdmarcresults> <userreportcontext>

Đầu ra có cấu trúc giúp analyst đọc nhanh, đưa vào hệ thống quản lý ticket và so sánh kết quả theo thời gian. Nếu cần đưa vào SIEM — hệ thống tập trung log và cảnh báo — các trường rõ ràng cũng thuận tiện hơn cho việc ánh xạ vào case.

4. Đối chiếu một case mẫu với bằng chứng

Ví dụ đầu vào:

text <subject> Yêu cầu xem lại tài liệu chia sẻ <senderdisplayname> Bộ phận hỗ trợ <senderdomain> <domain> <emailbody> Vui lòng mở liên kết để xem tài liệu và đăng nhập để tiếp tục. <attachmentnames> không có <urls> <url> <spfdkimdmarcresults> chưa có <userreportcontext> Người dùng báo email đến bất ngờ.

Một đầu ra hữu ích không nên khẳng định chắc chắn đây là phishing. Thay vào đó, mô hình có thể:

Gắn classification là suspicious hoặc likelyphishing theo quy tắc nội bộ. Ánh xạ sơ bộ tới T1566.002. Đề xuất chuyển tới emailsecurity; cân nhắc IdP nếu có dấu hiệu giả mạo đăng nhập. Nêu rõ tín hiệu đã thấy: có liên kết và lời kêu gọi đăng nhập. Yêu cầu kiểm tra header, SPF/DKIM/DMARC, lịch sử URL click và bất thường đăng nhập sau khi thư được phát.

MITRE mô tả các chiến lược phát hiện dựa trên tương quan giữa metadata email, hoạt động tạo tệp, thực thi tiến trình và kết nối mạng sau khi người dùng nhận thư. Với tài liệu Office, cần chú ý tình huống ứng dụng Office sinh tiến trình con đáng ngờ hoặc tạo kết nối ra ngoài. Với phishing nhắm IdP, cần đối chiếu luồng đăng nhập, dấu hiệu liên quan MFA và bất thường địa lý sau thời điểm email được gửi.

Xác minh đầu ra AI bằng telemetry

AI chỉ nhìn thấy dữ liệu được cung cấp. Analyst cần đối chiếu kết quả với các nguồn điều tra thực tế:

Email gateway: header, xác thực domain, lịch sử phân phối và các người nhận khác. Endpoint: tệp được ghi xuống đĩa, tiến trình mới và quan hệ tiến trình cha–con. Network: kết nối đi ra sau khi click URL hoặc mở tệp. IdP: đăng nhập bất thường, lời mời giả SSO hoặc tín hiệu liên quan MFA. SaaS: hoạt động click link, tải tệp đáng ngờ hoặc dấu hiệu lạm dụng token.

Hãy kiểm thử quy trình bằng các trường hợp khó: email hợp lệ nhưng dùng ngôn ngữ khẩn cấp, email giả mạo tinh vi, email đa ngôn ngữ và case thiếu header. Mục tiêu là tìm ra nơi mô hình định tuyến sai trước khi kết quả ảnh hưởng đến SLA hoặc quy trình ứng phó.

Tài liệu Anthropic cũng đề xuất theo dõi tính nhất quán phân loại, khả năng xử lý edge case, mức độ thích nghi khi nhãn thay đổi và chênh lệch hiệu quả giữa các ngôn ngữ. SOC nên duy trì một tập kiểm thử cố định, rồi so sánh kết quả khi thay đổi prompt, taxonomy hoặc mô hình.

Checklist triển khai

[ ] Taxonomy có nhãn ATT&CK, mức ưu tiên và đích chuyển xử lý rõ ràng. [ ] AI chỉ đề xuất; analyst hoặc kiểm soát nội bộ mới quyết định chặn hay cô lập. [ ] Dữ liệu đầu vào đã giảm thiểu thông tin nhạy cảm không cần thiết. [ ] Prompt yêu cầu nêu tín hiệu quan sát được và phần chưa chắc chắn. [ ] Kết quả được đối chiếu với email gateway, SIEM, endpoint, IdP và SaaS khi phù hợp. [ ] Có tập case đã review để kiểm tra tính nhất quán sau mỗi thay đổi. [ ] Case mơ hồ luôn được chuyển về analystreview.

AI có thể giảm tải phần đọc, tóm tắt và phân tuyến email báo cáo. Giá trị thực với SOC nằm ở việc dùng kết quả đó làm giả thuyết điều tra — sau đó xác nhận hoặc bác bỏ bằng log, telemetry và hành vi thực tế.