발견 사항의 의미

이 도구의 각 검사가 실제로 무엇을 살펴보는지, 그리고 발견 사항이 알려 주는 것과 알려 주지 않는 것.

결과 화면의 모든 발견 사항에는 한 줄 설명과 그 근거가 된 증거가 붙어 있습니다. 이 페이지는 그 긴 버전입니다. 밑바탕의 메커니즘은 무엇인지, 공격자가 왜 그런 방식으로 이를 이용하는지, 그리고 발견 사항에 얼마나 무게를 두어야 하는지를 설명합니다.

전체에 걸쳐 기억해 둘 것이 하나 있습니다. 이 검사들은 서로를 뒷받침합니다. 어느 것도 그 자체로는 판정이 아닙니다. 여러 검사는 정당한 메일에서도 흔하며, 다른 신호와 함께 나타날 때만 의미가 생깁니다.

메일은 어떻게 구성되는가

메일은 두 부분으로 되어 있습니다. 맨 위의 헤더 블록과 그 아래의 본문입니다. 헤더에는 발신자가 적혀 있고, 메일을 처리한 각 서버가 자신의 기록을 남기며, 인증 결과가 기록됩니다. 메일 프로그램은 이 대부분을 숨기고 이름, 제목, 본문만 보여 줍니다.

이 도구가 하는 일은 거의 모두 헤더를 읽는 것입니다. 그래서 스크린샷이나 전달된 메일이 아니라 원본 소스를 요구합니다. 전달하면 원래 헤더가 사라지고 사용자 쪽 헤더로 바뀝니다.

인증, 그리고 통과가 안심을 뜻하지 않는 이유

세 가지 메커니즘이 실제로 확인하는 것

SPF는 이렇게 묻습니다. 이 메일을 전달한 서버가 이 도메인을 대신해 메일을 보내도록 허용된 서버 목록에 있는가? 그 목록은 도메인 소유자가 게시합니다.

DKIM은 이렇게 묻습니다. 이 메일은 도메인이 게시한 키를 가진 누군가가 암호학적으로 서명했으며, 그 뒤로 변경되지 않았는가? 서명에는 서명한 도메인이 적혀 있으며, 증거에서 보게 되는 d= 값이 그것입니다.

DMARC는 이 둘을 실제로 보이는 주소와 연결합니다. SPF나 DKIM 결과가 통과했더라도, 그것만으로는 From 줄의 도메인과 전혀 다른 도메인의 결과일 수 있으며, 그렇다면 읽는 사람에게는 아무 의미가 없습니다. DMARC는 정렬을 요구합니다. 통과한 도메인이 사용자에게 표시되는 도메인과 일치해야 합니다.

정렬의 구체적인 의미

어떤 메일의 From 줄에 notice@bank.example.jp가 표시되고, mailer.example.net의 DKIM 서명이 붙어 있다고 합시다. 서명은 유효합니다. 하지만 메일을 보증한 도메인이 읽는 사람이 보는 도메인과 다르므로 정렬되지 않았고, DMARC는 이 메일을 bank.example.jp에 대해 인증된 것으로 취급하지 않습니다.

정렬에는 엄격 정렬(도메인이 정확히 일치)과 완화 정렬(등록 도메인만 일치하면 되므로 mail.bank.example.jp는 bank.example.jp와 정렬됨)이 있습니다. 등록 도메인을 알아내는 부분에는 단서가 붙습니다. 이 페이지 맨 아래의 안내를 참조하십시오.

통과가 이 페이지에서 가장 덜 흥미로운 이유

이것은 이 도구에서 가장 중요한 개념이며, 대부분의 사람이 생각하는 것과 정반대입니다.

인증은 누가 도메인을 소유하는지를 증명합니다. 메일이 스스로 주장하는 그대로라는 것을 증명하지는 않습니다. bank-example-support.com을 등록한 공격자는 그 도메인을 완전히 소유합니다. 그 도메인에 SPF 레코드를 게시하고, DKIM으로 서명하고, DMARC 정책을 게시할 수 있습니다. 도메인 비용만 들이면 몇 분 만에 가능합니다. 그러면 그들이 보내는 모든 메일은 완벽하게 인증됩니다. 메일이 자신에 대해 하는 모든 말이 사실이기 때문입니다. 다만 은행이 아닐 뿐입니다.

관측된 피싱에서 이것은 예외가 아니라 다수입니다. 약 절반이 공격자가 등록한 도메인에서 오며, 그 대부분이 DMARC를 통과합니다. 그래서 이 도구는 통과를 ‘이 도메인은 스스로 밝힌 그대로입니다’라고만 표시하고 그보다 따뜻한 말은 하지 않으며, 여기서는 인증보다 유사 도메인 분석과 링크 분석에 더 무게를 둡니다.

실패도 알아 둘 가치가 있습니다. 위조된 발신자가 만들어 내는 형태이기 때문입니다. 하지만 메일링 리스트와 전달 서비스는 일상적으로, 그리고 악의 없이 인증을 깨뜨리므로 실패만으로도 판정은 되지 않습니다.

전달된 메일을 위한 ARC

메일링 리스트가 메일을 다시 쓰면 원래 서명이 깨집니다. ARC는 각 홉이 메일을 넘기기 전에 자신이 본 것을 기록하게 해서, 나중 서버가 지금은 인증이 실패하더라도 앞에서는 통과했다는 것을 볼 수 있게 합니다. 이 도구가 검증에 실패한 ARC 체인을 보고한다면 그 기록을 신뢰할 수 없다는 뜻이며, 따라서 메일이 도착하기 전에 무슨 일이 있었는지 확인할 수 없습니다.

전달 경로

Received 체인이란

메일을 처리하는 모든 서버는 헤더 맨 위에 Received 줄을 추가합니다. 누가 접속했고, 누가 받았으며, 언제였는지를 기록합니다. 아래에서 위로 읽으면 메일의 여정이 됩니다. 이 도구는 이를 최신순으로 보여 주며, 각 쌍 사이의 간격을 둘을 잇는 선 위에 표시합니다.

믿을 수 있는 것은 뒤쪽 홉뿐입니다. 각 서버는 자신이 직접 받아들인 접속만 보증할 수 있습니다. 사용자의 메일 서비스가 관리하는 첫 서버보다 아래에 있는 모든 줄은 믿을 이유가 없는 기계가 쓴 것이며, 공격자는 원하는 만큼 줄을 지어낼 수 있습니다. 그래서 이상해 보이는 앞쪽 홉은 증거가 아니라 신호입니다.

거꾸로 가는 타임스탬프

각 홉은 자신의 시계로 시각을 기록하므로, 약간의 불일치는 정상입니다. 시계는 어긋나기 마련입니다. 나중 서버가 앞 서버보다 이른 시각을 시계 오차로 설명할 수 있는 수준 이상으로 기록했다면, 시계가 크게 틀렸거나 경로의 일부가 손으로 작성된 것입니다. 위조된 헤더는 보통 계산에 신경 쓰지 않는 누군가가 한 번에 작성합니다.

설명되지 않는 긴 공백

두 홉 사이에 하루가 넘게 걸린 경우입니다. 메일 대기열과 재시도 때문에 실제로 이런 일이 생기므로, 조치할 일이 아니라 눈여겨볼 일로 보고합니다. 그래도 살펴볼 가치가 있는 것은, 메일이 미리 작성된 뒤 나중에 주입되었거나 실제 메일에서 헤더 블록을 복사했다는 뜻일 수도 있기 때문입니다.

공개된 경로 속의 사설 주소

어떤 주소 범위는 사설 네트워크 안에서만 작동하며 인터넷에서 도달할 수 없습니다. 공개된 경로 중간에 이런 주소가 나타난다면 보통 그 줄이 복사되었거나 지어낸 것입니다. 그 줄이 묘사하는 접속은 일어날 수 없었기 때문입니다.

이름 없는 클라우드 서버에서 발송됨

자체 메일을 보내는 조직은 보통 메일 서버에 직접 고른 이름을 붙입니다. 첫 홉의 이름이 호스팅 업체가 자동으로 생성한 것이라면, 발신자는 빌린 자원을 설정하지 않은 채 쓰고 있다는 뜻입니다. 일부 소규모 발신자에게는 평범한 일이지만, 아무도 모르는 주소에서 메일을 보내는 가장 값싼 방법이기도 합니다. 판정이 아니라 세부 사항으로만 보고하며, 호스트가 누구라는 이유만으로 보고하는 일은 결코 없습니다.

수신 서버가 남긴 메모

메일을 처리한 서버가 자신에게 접속한 상대에 대한 의심을 기록한 경우가 있습니다. 흔히 접속한 주소에 역방향 이름이 없다는 내용이며, 이는 대량 발신자에게 유난히 많이 해당합니다. 이런 내용이 보이면 그것은 그 서버의 메모를 적힌 그대로 인용한 것입니다. 이 도구는 자체 조회를 하지 않으며, 메일에 이미 있는 내용을 보고할 뿐입니다.

메일이 밝힌 발신자

이름과 주소는 따로 설정됩니다

발신자는 표시 이름과 주소로 이루어지며, 둘은 서로 독립된 필드이고 둘 다 발신자가 씁니다. 대부분의 메일 프로그램, 특히 휴대전화에서는 이름만 보여 줍니다. 그래서 메일에 계정 보안팀이라고 표시되어도 그 아래 주소는 전혀 다를 수 있으며, 위조된 것은 하나도 없습니다. 이 도구가 의심스러운 메일뿐 아니라 모든 메일에서 이 한 쌍을 보여 주는 이유입니다.

이름 속에 숨은 두 번째 주소

같은 속임수의 한 변형입니다. 이메일 주소를 표시 이름 안에 적어 넣는 것입니다. 메일 프로그램은 이름을 보여 주므로, 메일은 다른 주소에서 왔는데도 사용자는 그 주소를 읽게 됩니다.

텍스트를 읽는 방향을 뒤집는 문자

Unicode에는 아랍어와 히브리어가 섞인 텍스트에서 올바르게 표시되도록 존재하는 제어 문자가 있습니다. 이름이나 파일 이름에 넣으면 실제 문자는 그대로인 채 화면에서만 텍스트가 거꾸로 읽히며, .exe 파일을 .jpg로 끝나는 것처럼 보이게 만드는 방법이 바로 이것입니다. 이 도구는 이런 문자를 절대 적용하지 않고, <U+202E> 같은 보이는 라벨로 표시해 어디에 있는지 볼 수 있게 합니다.

보이지 않는 문자

폭이 전혀 없는 문자를 이름이나 주소 안에 넣은 것입니다. 익숙한 이름과 똑같아 보이는 이름이 실제로는 일치하지 않게 되어, 평범한 텍스트로 일치 여부를 확인하는 필터와 메일 규칙이 무력해집니다.

유사 도메인

이 검사와 링크 구조 검사가 여기서 가장 무게가 큰 검사입니다. 인증과 달리 공격자가 정직하게 충족하기 어렵기 때문입니다.

한 이름 안의 문자 체계 혼용

도메인 이름에는 세계 대부분의 문자 체계에서 온 문자를 쓸 수 있으며, 몇몇 글자는 문자 체계가 달라도 모양이 똑같습니다. 라틴 문자 a와 키릴 문자 а, 라틴 문자 o와 그리스 문자 오미크론이 그렇습니다. 평범한 이름에 이런 글자 하나를 바꿔 넣으면 눈으로는 똑같지만 기술적으로는 다른 도메인이 생기며, 아무도 가지고 있지 않으므로 등록할 수 있습니다.

문자 체계를 섞어 쓰는 것 자체는 의심스러운 일이 아니며, 이 도구도 그렇게 취급하지 않습니다. 일본어는 평범한 단어에서도 세 가지 문자 체계를 섞어 쓰며, 일본어, 한국어, 중국어 도메인은 정상입니다. 이 검사는 어떤 조합이 실제로 함께 쓰이는지에 관한 Unicode 규칙을 사용해, 그렇지 않은 조합, 즉 하나의 레이블 안에서 라틴 문자가 키릴 문자나 그리스 문자와 섞인 경우를 경고합니다.

Punycode는 경고 신호가 아닙니다

비ASCII 도메인은 xn-- 접두어로 시작하는 인코딩된 형태로 전송됩니다. 정당한 일본어, 한국어, 중국어, 러시아어 도메인은 모두 전송될 때 이런 형태로 쓰입니다. 이것이 보인다고 해서 그 자체로 의미가 있는 것은 아니며, 이 도구는 이를 의심스럽다고 경고하지 않습니다. 대신 디코딩된 형태와 인코딩된 형태를 나란히 보여 주어, 문자가 실제로 바꿔치기된 경우에는 그 차이가 그저 존재하는 데 그치지 않고 눈에 보이게 합니다.

실제 도메인과 한두 글자 차이

글자 하나를 바꾸거나 더하거나 뺀 것입니다. m 대신 rn, 알파벳 o 대신 숫자 0. 보통 글자 크기에서는 구별하기 어렵고 아주 쉽게 등록할 수 있습니다. 이 비교에는 대조할 실제 브랜드 도메인 목록이 필요하므로, 그 목록에 있는 브랜드만 대상으로 합니다. 한계 페이지를 참조하십시오.

악용에 유난히 많이 쓰이는 도메인 끝부분

일부 끝부분은 값싸고 심사가 느슨해서, 일반 메일보다 피싱에 훨씬 자주 나타납니다. 정당한 사이트도 많이 쓰므로, 이것은 전체 그림에 보태질 뿐 그 자체로 결정짓는 것은 없습니다.

목록은 의도적으로 짧게 유지하며, 어떤 끝부분이 목록에 없다는 것은 아무것도 뜻하지 않습니다. 공개된 출처를 제시할 수 있고, 둘 이상의 출처와 둘 이상의 기간에 걸쳐 측정된 끝부분만 담습니다. 그런 끝부분은 많지 않으며, 현재 3개입니다. 목록에 있는 것보다 훨씬 많은 끝부분이 피싱에 쓰이며, 대부분의 피싱은 어차피 .com 같은 평범한 끝부분을 씁니다. 도메인 끝부분에 대해 아무 말도 없는 결과는 승인이 아니라 이 도구가 할 말이 없다는 뜻으로 읽으십시오.

링크

텍스트와 실제 링크가 다른 곳을 가리키는 경우

HTML 메일에서는 보이는 텍스트와 실제로 이동할 주소가 따로 있습니다. 둘을 서로 다르게 만드는 것은 피싱의 가장 믿을 만한 단일 징후이며, 링크에 마우스를 올리거나 소스를 읽지 않으면 보이지 않습니다. 이 도구는 둘을 위아래로 나란히 보여 주어, 한 번 내려다보는 것으로 비교할 수 있게 합니다.

이 도구의 링크는 절대 클릭할 수 없습니다. 주소는 복사할 수 있는 비활성 텍스트로 표시됩니다. 피싱 분석기 안에 작동하는 피싱 링크를 넣는 것은 변명의 여지가 없기 때문입니다.

실제 목적지 앞의 @

웹 주소에서 @ 앞에 있는 부분은 모두 브라우저가 무시합니다. https://www.bank.example.jp@evil.example/는 evil.example로 이동합니다. 익숙한 부분은 링크가 그럴듯하게 시작하도록 거기 들어가 있을 뿐입니다.

주소 대신 명령을 담은 링크

어떤 링크 스킴은 페이지로 전혀 이어지지 않습니다. 브라우저가 실행할 코드나, 링크 안에 인코딩된 문서 전체를 담고 있습니다. 일반 메일에는 이런 링크가 없습니다.

이름 대신 숫자 주소

도메인 이름이 없는 목적지입니다. 조직은 자신의 사이트에 이름을 붙이며, 이름 없는 주소는 무엇과도 대조해 확인할 수 없습니다.

리디렉션과 인코딩된 매개변수

안에 두 번째 주소를 담고 있어 다른 곳으로 넘겨주는 링크입니다. 읽게 되는 부분은 한 사이트의 것이지만, 도착하는 곳은 링크를 작성한 사람이 정합니다. 쿼리 문자열의 인코딩된 부분은 일반적인 추적 링크에서도 흔하지만, 주소나 명령을 언뜻 보아서는 알아채지 못하게 숨기는 방법이기도 합니다. 고발하지 않고 보고만 합니다.

보안 제품이 재작성한 링크

메일 서비스와 필터링 서비스는 클릭이 자신을 거치도록 링크를 자체 링크로 바꿉니다. 원래 주소가 새 주소 안에 인코딩되어 있으면, 이 도구는 이를 해독해 실제 목적지를 보여 줍니다. 감싼 링크가 아니라 그 목적지를 보고 판단하십시오. 서비스가 원래 주소를 자체 서버에 보관하고 참조만 남긴다면 해독할 것이 없으며, 이 도구는 추측하는 대신 그렇다고 밝힙니다.

누구나 신뢰하는 서비스에 올라간 페이로드

누구나 잘 알려진 문서 서비스나 저장 서비스에 페이지를 올려 그 평판을 빌릴 수 있습니다. 호스팅 업체 자체는 결코 신호가 아닙니다. 정당한 메일에 있는 정당한 서비스로의 링크는 정당한 서비스로의 링크일 뿐입니다. 이 검사는 메일이 누군가를 사칭하는 것으로 도 보일 때만 경고하며, 그때도 중간 정도의 신호입니다.

목록에 있는 브랜드로 한정됩니다. 메일이 어떤 브랜드를 사칭한다고 판단하려면 그 목록이 필요하므로, 이 검사는 목록에 있는 브랜드, 즉 52개 브랜드에 대해서만 경고할 수 있습니다. 목록에 없는 브랜드를 사칭하는 메일은 똑같은 서비스에 올라가 있어도 여기서 전혀 경고되지 않습니다. 이 도구가 탐지할 수 없는 것을 참조하십시오.

문자 인코딩

선언된 인코딩이 내용과 맞지 않는 경우

메일은 자신의 텍스트를 어떻게 읽어야 하는지 밝힙니다. 그 표시가 실제 바이트와 맞지 않아도 모든 내용은 표시됩니다. 바로 그 점이 핵심입니다. 표시된 대로 메일을 읽는 필터는 사용자가 보는 것과 다른 텍스트를 보게 되며, 필터가 읽는 쪽이 무해해 보이도록 메일을 만들 수 있습니다.

폐기된 인코딩

특히 한 인코딩은 웹 표준에서 철회되어 더 이상 브라우저가 디코딩하지 않습니다. 지금은 거의 전적으로 보안 필터가 해독하지 않는 방식으로 텍스트를 쓰는 수단으로만 남아 있습니다.

일반 문자를 흉내 내는 문자

수학용, 원문자, 장식 문자 형태는 사람에게는 평범한 단어로 읽히지만 실제로는 다른 문자이며, 평범한 철자로 일치 여부를 확인하는 필터를 단어가 빠져나가는 방법이 바로 이것입니다.

심각도, 그리고 점수가 없는 이유

발견 사항에는 악성, 의심, 참고 정보, 문제 없음의 네 가지 심각도 중 하나가 붙으며, 각 심각도는 계산되는 것이 아니라 그 발견 사항을 만든 규칙이 정합니다. 헤드라인은 나타난 발견 사항 가운데 가장 심각한 것을 따릅니다.

숫자 점수는 없으며, 숨기고 있는 것도 아닙니다. 아예 존재하지 않습니다. 숫자는 이 분석에 없는 정밀함을 암시하고 ‘30 미만이면 괜찮다’ 같은 기준선을 부르는데, 이것이 바로 28점을 받은 메일에 속아 피싱을 당하는 사고방식입니다. 이름이 붙은 네 가지 심각도와 동료에게 그대로 전할 수 있는 한 문장이, 실제로 알려진 것에 대해 더 정직합니다.

초록색은 절대 쓰지 않으며, 어떤 결과도 메일이 안전하다고 말하지 않습니다. 깨끗한 결과는 실행된 검사에서 고위험 요소를 찾지 못했다는 뜻이며, 모든 결과에 붙는 확인 범위 안내가 어떤 검사가 실행되었는지 알려 줍니다.

공개된 근사치: 등록 도메인

정렬은 등록 도메인이 어디서 끝나는지 아는 데 달려 있습니다. example.co.jp는 등록 도메인이고 co.jp는 아닙니다. 현행 DMARC 표준은 이를 실시간으로 이어지는 DNS 조회로 결정합니다.

이 도구는 어떤 종류의 네트워크 요청도 하지 않으므로 그런 조회를 할 수 없습니다. 대신 Public Suffix List를 사용합니다. 사람들이 그 아래에 이름을 등록하는 도메인 끝부분을 관리하는 목록이며, 여기서 등록 도메인을 도출합니다.

두 방식은 대개 일치합니다. 다를 경우, 여기 표시되는 정렬 결과는 수신 메일 서버가 계산하는 결과보다 더 엄격하거나 더 느슨할 수 있습니다. 이것은 근사치이며, 이에 의존하는 모든 결과에 명시됩니다. 사용자가 스스로 알아내도록 남겨 두지 않습니다. 의도적인 맞교환입니다. 다른 방법은 메일의 도메인을 DNS 리졸버로 보내는 도구이며, 그러면 ‘메일은 기기 밖으로 나가지 않습니다’라는 말은 더 이상 사실이 아니게 됩니다.