피싱 이메일 초동 분석 가이드: 헤더 정합성·SPF/DMARC·첨부파일 검증 순서

개요

신고된 피싱 메일의 초동 분석은 “표시는 합법인데 실제 경로는 다르다”는 점을 단계별로 확인하는 작업입니다. 제공된 분석 사례에서는 From 헤더가 mutawamarine.com이라는 합법 도메인으로 표시되지만, 실제 회신 라우팅은 info.mutawamarine@mail.com로 설정되어 있었습니다. 원본 .eml 헤더에서 확인된 이 Reply-To 불일치는, 표준 주위 시각 검사(standard perimeter visual checks)를 우회하기 위한 기법으로 분류됩니다.

이 사례가 주는 핵심 시사점은, 발신 표시만으로는 신뢰를 판단할 수 없으므로, From·Reply-To·Received 헤더, 도메인 인증 기록, 첨부파일 식별값이라는 서로 다른 공격 단계를 각각 증명할 자료를 순서대로 확인해야 한다는 것입니다. 아래는 확인된 사실을 바탕으로 한 적용 범위, 절차, 운영상 의미, 탐지·대응 순서입니다.

적용 환경·전제조건

이 가이드는 아래 조건을 전제로 합니다.

• 수신 메일에 대한 원본 .eml 파일(From, Reply-To, Received 헤더 포함)을 확보할 수 있는 상황
• Received 헤더에서 소스 IP와 ISP/ASN을 추출할 수 있어야 하는 SOC 분석자의 판단을 전제로 함
• 해당 도메인의 DNS SPF/DMARC 기록을 조회할 수 있는 이메일 보안 담당자의 환경을 전제로 함

적용 대상은 아래입니다.

• Reply-To 불일치, 표시 이름 위장, 이중 확장자 위장(CAB)을 사용한 피싱 이메일을 받은 수신자
• SPF/DMARC 도메인 인증 기록을 점검해야 하는 이메일 보안 담당자
• 원본 .eml 헤더(Received, From, Reply-To)를 해석할 수 있어야 하는 SOC 분석자

기술 절차·판단 근거

검증은 서로 다른 공격 단계를 증명하는 자료의 성격에 따라 순서를 갖습니다. 헤더 정합성, 송신 경로, 도메인 인증, 첨부파일 식별값의 순서로 확인합니다.

From·Reply-To 정합성

From 헤더와 Reply-To 주소를 비교합니다. 사례에서 확인된 값은 아래입니다.

• From: info@mutawamarine.com
• Reply-To: info.mutawamarine@mail.com

From이 합법 기업 도메인으로 보이는 동안 회신 라우팅이 제3자 주소로 설정되어 있는 것은 회신 가로채기 구조입니다. 수신자가 회신할 경우 합법 도메인으로 보이는 From이 아니라 공격자 지정 주소로 내용이 전달되므로, 이 불일치를 발견한 시점에 회신을 금지하는 것이 첫 대응입니다.

Received 경로·소스 IP·ASN

Received 헤더의 네트워크 경로를 추적해 원본 송신 서버를 확인합니다. 사례에서 확인된 값은 아래입니다.

• 소스 IP: 192.119.71.157
• ISP/ASN(IPinfo 기준): HostPapa

이 두 값은 이 사례에서 Received 헤더를 추적해 추출된 식별값입니다. 제공된 인용에는 IP·ASN 값과 이 사례에서 Received 헤더를 추적했다는 사실만 포함되어 있으며, 이 값이 표시 도메인 인프라와 다른 제3자 경유임을 보여주는 직접적 근거로 쓰이지 않습니다.

SPF/DMARC 도메인 인증

이 사례에서는 발신 도메인의 DNS 기록을 평가해 도메인 인가를 점검하는 단계를 수행했습니다. 이 단계가 참조하는 표준은 아래입니다.

• SPF(RFC 7208): 도메인의 이메일 발신 사용을 인가하는 표준
• DMARC(RFC 7489): 도메인 기반 메시지 인증·보고·정책 준수를 다루는 표준

SPF/DMARC 기록과 실제 송신 IP의 정합성을 확인하지 않고 메일을 신뢰하면 발신 위장 메일을 식별하기 어렵습니다. 단, 제공된 원문 인용에는 DNS 조회의 최종 판정(pass/fail)이나 정책 값이 포함되어 있지 않아, 이 가이드에서는 인증 절차의 존재와 점검 순서만 기술합니다.

첨부파일 이중 확장자·해시

첨부파일의 확장자와 실제 파일 유형이 일치하는지 확인합니다. 사례의 첨부파일은 아래 값으로 식별됩니다.

• 파일명: SWT_#09674321____PDF__.CAB
• SHA-256: 2e91c533615a9bb8929ac4bb76707b2444597ce063d84a4b33525e25074fff3f

이 파일은 PDF 문서인 것처럼 보이기 위해 이중 확장자로 위장한 CAB 아카이브입니다. 이중 확장자 위장은 확장자 기반 차단을 우회하는 수단으로 사용될 수 있으며, 실행될 경우 내부 시스템에 악성 부하가 도입되는 구조적 위험을 갖습니다. CAB 내부 페이로드의 실제 동작은 제공된 근거에 해시만 포함되어 있어 확인되지 않습니다.

사례 기법 분류

보고서는 이 사례의 기법을 Display Name Spoofing, Reply-To Mismatch, Double-Extension Obfuscation(Compressed Malicious Cabinet)로 분류했습니다.

운영상 영향

위 절차가 주는 운영상 의미는, 각 검증 항목이 서로 다른 공격 단계를 담당하는 만큼 순서를 건너뛰면 특정 단계를 놓칠 수 있다는 것입니다.

• From·Reply-To 정합성: 표시된 From과 실제 회신 라우팅의 불일치를 확인하는 항목
• Received 경로: 사례에서 원본 송신 서버로 추적된 소스 IP·ASN 식별값을 확인하는 항목
• SPF/DMARC: 사례에서 평가된 도메인 DNS 인가 기록을 확인하는 항목
• 첨부파일 해시: 사례에서 제시된 파일명·SHA-256으로 첨부 파일을 식별하는 항목

즉, 발신 표시를 합법 도메인으로 가장하면서 회신을 제3자 주소로 유도하는 패턴과, 확장자를 숨겨 유포한 악성 첨부파일이라는 결합된 패턴을 포착하려면 이 네 항목을 단계적으로 확인해야 합니다. 단일 항목의 정합성만으로는 전체 공격 구조를 판단하기 어렵습니다.

탐지·대응

즉시 대응은 아래 순서로 수행합니다.

• 신고된 메일의 원본 .eml 파일을 확보해 From·Reply-To·Received 헤더를 먼저 비교
• Reply-To 주소가 From 도메인과 다른지 확인하고 회신을 금지
• 첨부파일 확장자와 파일 유형이 일치하는지(예: .PDF__.CAB) 확인하고 실행 전 격리
• 신고한 사용자에게 Reply-To 불일치를 인식하는 표적 가이드를 제공

한계 및 참고자료

제공된 근거에 기반하지 않아 확인되지 않은 항목은 아래입니다.

• 해당 공격의 캠페인 규모, 공격자 귀속, 추가 IOC 집합은 확인되지 않습니다
• mutawamarine.com 도메인의 SPF·DMARC DNS 조회 최종 판정(pass/fail)과 정책 값(p=?)은 원문에 포함되어 있지 않아, 이 글에서는 인증 절차와 점검 순서만 기술합니다
• SHA-256에 해당하는 페이로드의 실제 동작(다운로더, 매크로, 실행 파일 등)은 unpack 또는 샌드박스 분석이 없어 확인되지 않습니다
• 소스 IP 192.119.71.157(HostPapa) 관련 캠페인의 규모·기간·추가 IOC는 단일 인스턴스만 기술되어 있어 확인되지 않습니다
• 해당 피싱 메일과 정부 기관 공개 통보의 직접적 연관성은 확인되지 않았습니다
• 독립적 교차 검증 소스는 제공되지 않아, 해당 사례의 사실관계는 단일 출처(Medium @nitchsx)에 기반합니다

참고자료

• Investigating Phishing & Spoofing in the SOC: A Practical Email Analysis Write-up
• Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
• Domain-based Message Authentication, Reporting, and Conformance (DMARC)

함께 읽으면 좋은 글

• CVE-2026-19410: Google Cloud Build GitHub 트리거 코멘트 제어의 권한 검증 우회 취약점 분석
• Google SecOps에서 AI 기반 UEBA를 설계할 때 확인할 다단계 분석과 탐지 품질
• 차량 NFC 디지털 키 릴레이 공격의 성립 조건과 운영 대응 점검

본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.