구글, DKIM 리플레이 공격으로 스푸핑 당함: 기술적 분석

(easydmarc.com)

1P by GN⁺ 17시간전 | ★ favorite | 댓글 1개

공격자가 DKIM 리플레이 공격을 이용해 Google로 가장한 피싱 이메일을 성공적으로 보낸 사례임
이메일의 발신 주소 및 인증 결과가 실제 구글 공식 메일처럼 보여 사용자가 쉽게 속을 수 있음
공격자는 Google Sites를 활용해 공식 지원 페이지처럼 보이도록 사이트를 제작해 신뢰도를 높임
SPF, DMARC, DKIM 모두 인증을 통과하지만, 본문 및 서명 헤더 수정 없이 이메일 재전송이 핵심임
실질적 대응책으로 DKIM 키 주기적 변경과 사용자 인지 제고가 권장됨

시작: 정상으로 보이는 피싱 메일

아침에 한 지인이 구글 계정에 대한 법적 서류 요청을 받았다는 이메일을 받음
발신자는 Google 공식 no-reply 주소로 표시, 오타나 수상한 링크, 비정상적인 도메인 없이 정교하게 작성됨
수신자는 진위여부 판단이 어려워 전문가에게 의뢰함

이메일 상세 분석

이메일 헤더 및 링크 프리뷰를 샌드박스 환경에서 조사
발신 주소, 브랜딩, 언어 품질, 첨부 파일 유무 모두 정상적임
하지만 SPF, DKIM, DMARC 인증결과 체크 시 이상 징후 발견됨

피싱 메일 주의사항

수상한 이메일 내 링크 클릭·지시사항 실행 금지 강조
샌드박스가 아닌 환경에서 해당 이메일에 응답하거나 첨부파일 열 경우 정보 유출, 기업 이메일 침해, 계정 탈취, 네트워크 침해 위험 존재함
의심스러운 경우 즉시 전문 분석 및 보안팀에 보고 필요

공격 흐름: Google Sites 활용

공격 이메일의 링크는 로그인 상태라면 바로 Google Sites로 연결
Google Sites는 아무나 무료로 제작할 수 있는 공식 google.com 서브도메인이지만, 내용 자체는 공식 지원 페이지가 아님
내부 위키, 프로젝트 대시보드, 문서화, 이벤트 웹사이트 등 다양한 목적으로 쓰이며, 이번 공격처럼 악용될 수 있음

인프라 신뢰가 위협이 되는 순간

Google Sites(2008년 출시)는 Google Workspace와 연동, 손쉬운 제작·배포·SSL 인증·브랜드 신뢰도 제공
공격자는 별도 도메인/호스팅 없이 공식처럼 보이는 피싱 사이트를 쉽고 저비용으로 구축 가능

DKIM 리플레이 공격 과정 상세

1단계: 실제 구글 이메일 확보

공격자는 no-reply@accounts.google.com 계정에서 정상 이메일 수신 후, 원본 본문 및 헤더를 저장함

2단계: 서명 메시지 재전송 준비

DKIM은 메일 본문 일부 및 특정 헤더에 대해 디지털 서명을 부여
원본 메시지와 서명 헤더가 유지되면, 재전송 시에도 인증 유지됨

3단계: Outlook을 통한 재전송

공격자는 Outlook 계정에서 공격용 메일 전송
발신지, 경로 정보 일부가 변경되나, DKIM 서명이 유효하게 남음

4단계: Jellyfish SMTP 중계서버 이용

Microsoft에서 Jellyfish 시스템을 경유하여 메일 라우팅(발신 서버와의 거리 확보)

5단계: Namecheap PrivateEmail을 통한 전송

Namecheap PrivateEmail 서비스가 메일을 수신 후 추가 중계 역할 수행
이 과정에서 새로운 DKIM 서명이 추가되지만, DMARC 기준에는 부합하지 않음
원본 구글 DKIM 서명이 일치/유효하여 DMARC 검증 통과

6단계: Gmail 최종 배달

최종적으로 수신자는 Google 공식 메일로 보이는 이메일 수신
SPF, DKIM, DMARC 모두 인증 통과하는 결과

가짜 소환장 이메일이 위험한 이유

‘소환장’ 메일은 수신자에게 공포·긴박감·혼란 유발
실제 소환장 발부/전달 방식과 차이가 있으며, 정상적이라면 물리적 전달이나 공식 채널을 통해 진행
이런 유형의 피싱은 매우 설득력 있어, 기술적으로 숙련된 사용자도 쉽게 속을 수 있음

결론 및 대응

예상치 못한 긴급 이메일일수록 항상 진위 검증 및 전문가 조치 요청 필수
링크 클릭, 회신, 실행 일체 금지
보안팀 혹은 조사 전문 인력에게 분석 요청 권장

추가: 공격 재현 과정

공격자는 Namecheap에서 도메인 등록, 무료 PrivateEmail 서비스 획득
Google Workspace(무료 평가판) 가입 및 도메인 인증 후, 악성 Google OAuth App 생성
App Name 필드를 통해 원하는 이름 설정 가능(예: Google Support)
구글이 발송한 계정 알림이 PrivateEmail로 전송되며, 발신 주소와 회신 주소 조작 가능
최종적으로 공격 메일이 원하는 타겟에게 전달됨

자주 묻는 질문

DKIM 리플레이 공격: 공격자가 유효한 DKIM 서명이 포함된 정상 이메일을 캡처 후, 동일 내용·헤더로 재전송
SPF, DMARC 차단 한계: SPF는 보낸 서버/IP만 검증, 리플레이 공격 시 DMARC도 DKIM 정합성 있으면 통과 가능
탐지 어려움 이유: 본문·헤더 변조 없이 서명 검증만으로는 식별 곤란
공격의 Google OAuth 우회: 공격자는 악성 OAuth App 생성, 구글이 전송한 공식 알림을 재전송해 신뢰도 확보
대응책: DKIM 키 주기적 변경(30일 이하 주기) 및 사용자 교육(수상한 링크 주의, URL 점검, 보고 문화 확산) 중요

▲

GN⁺ 17시간전 [-]

Hacker News 의견

저는 이 문제의 해결책을 만들고 있음 (Google과 Yahoo 출신 공저자들과 함께 하며, 신뢰할 만한 프로젝트임)
Draft: DKIM2 Motivation 문서를 참고 바람
이 방식은 사용자가 입력한 텍스트가 Google에서 실제로 발송되는 건 막지는 못하지만, Google의 실제 의도 없이 해당 메시지가 재전송되는 것만큼은 막아줌
왜냐하면 SMTP FROM/TO 필드가 보호됨
동기 부여 초안은 기술적 디테일을 포함하지 않으며, 관련 문서들에서 초안을 볼 수 있음
DKIM Working Group Documents 링크 참고 바람
- Datatracker 사이트가 후보 문서를 잘 보여주지 않아 직접 링크 첨부함
  Draft: dkim2-dns
  Draft: dkim2-header
  Draft: dkim2-modification-algebra
  Draft: dkim2-bounce-processing
  Draft: dkim2-message-examples
- 이 방식은 메일링 리스트나 그룹에는 어떻게 작동할지 궁금함
  예를 들어, 외부에서 accounts-payable@example.com으로 온 메일을 팀원들에게 자동 전달하는 경우가 많음
  최종 수신자의 시스템에서는 메일링 리스트 포워더를 신뢰하는 설정이 필요할지, 아니면 어떤 리스트에 포함되어 있는지 트래킹하는 내부 로직이 있어야 하는지 궁금함
  원래 수신자인 accounts-payable이 유효한 수신자임을 확인 가능해야 함
실제로 컴퓨터 해킹 혐의로 유죄 판결을 받은 후 FBI가 제 Google 계정 자료 전체를 압수한 경험이 있음
2016년에 한 번, 2018년에 다시 한 번 자료를 가져감
실제로는 이 기사에서처럼 하지 않음
경험에 따르면, Google 특정 부서에 이메일을 보내서 공식 소통을 진행함
수사기관은 최대한 수사 대상자가 눈치 못 채게 신중하게 움직임
- curious한 분들을 위해 자세히 설명함
  usernotice@google.com에서 이런 내용의 이메일을 받음:

Dear Google user,

Google received and responded to legal process issued by the United States Department of Justice (<FEDERAL DISTRICT>) compelling the release of information related to your Google account. A court order previously prohibited Google from notifying you of the legal process. We are now permitted to disclose the receipt of the legal process to you. The agency reference number or case number on the legal process is <DISTRICT COURT CASE NUMBER>.

For more information about how Google handles legal process, view our transparency report at http://google.com/transparencyreport/userdatarequests/….

Google is not in a position to provide you with legal advice or discuss the substance of the legal process. If you have other questions regarding this matter, you may wish to contact an attorney.

Please reply to this email and/or include the case identification number located in the subject line in any further communications regarding this matter.

Regards, 
Legal Investigations Support
Google LLC

연방 대배심 소환장(Federal Grand Jury subpoena)에서는 일반적으로 서비스 제공자(Google 등)가 당신에게 알리지 못하도록 1~2년 지연 통지를 요청함
소환장은 일반화된 기록(청구정보, 로그인 기록 등)만 제공하며, 콘텐츠(이메일 등)는 제공하지 않음
이메일 등 실제 데이터는 수색영장을 따로 받아야 하고, Google은 보통 이런 수색영장이 집행된 사실을 별도로 통지하지 않음

금요일인데 이 댓글이 저를 10% 깨어나게 해줌
자세한 뒷이야기가 궁금함
흥미로움
이 요청 사항이 GDPR의 "내 계정 관련 모든 데이터 달라" 요청 등에 포함돼서 내 계정 데이터 전체 파일에 기록되거나 태그가 남는지 궁금함
추측인데, 수색 영장은 CFAA 위반, 전신사기(wire fraud), 또는 음모죄(conspiracy) 등으로 나왔을 것 같음
잘 변호사 선임해서 잘 해결됐길 바람
최근 유사한 공격이 저에게도 옴
공격자는 yourgoogleaccount@google.com(정확히 gmail.com이 아님)으로 메일을 보내고, 그 후 Google의 메일 서버에서 받은 전달 오류 메시지(bounce)를 yourgoogleaccount@gmail.com으로 포워딩한 뒤 끝에 스팸 메시지를 끼워넣음
모든 보안 체크를 통과하게 됨
postmaster 오류와 피싱캠페인이 섞여서 이뤄지는 점이 정말 특이함
비기술자라면 쉽게 넘어갈 수 있을 만함
제 경우에는 피싱 메일 내용이 건설 공구에 당첨됐다는 식임
- 저도 몇 주째 이런 메일을 받고 있음
  이제 Google이 메일을 포기한 것 같다는 생각이 듦
글을 읽으면서 매우 혼란스러웠음
공격자가 이메일 본문을 조작해서 피싱 링크를 삽입한 것처럼 보이게 자세히 묘사하지만, 실제로는 그런 증거나 조작이 없었음
DKIM 서명에는 본문의 해시가 포함됨
기술적으로 I= 필드를 써서 해시 범위를 제한 가능하긴 한데, Google이 짧은 메일에 그 옵션을 사용하지 않는 걸로 확인함(no-reply@accounts.google.com 메일 직접 확인 결과)
즉, DKIM과 DMARC 검사를 통과하려면 본문이 변경되면 안 되므로 피싱 링크도 원래 Google에서 보냈던 내용임(단, 예상 수신 대상자가 다른 경우일 것)
따라서 실제로는 "무서운 이메일이 잘못 포워딩된 사례"가 더 핵심이고, 'DKIM replay attack'이라는 제목이 이 분야에 익숙하지 않은 사람들에게 훨씬 더 심각하게 들릴 수 있음
편집: TFA의 "The Takeaway?"를 보고 글이 끝난 줄 알았지만 그 아래 업데이트에서 링크가 실제로 Google OAuth 앱 이름에 삽입되어 Google 이메일 템플릿에 포함된 것임을 설명함
이 부분이 이 공격의 가장 중요한 점인데 글의 구조가 너무 안 좋아서 bury(묻혀버림)되어 있고, 마치 임의의 콘텐츠 전송이 가능한 것처럼 오해를 불러 일으킴
추가: 다른 댓글에서 이메일 스크린샷이 중간에 잘려서 Google 이메일 템플릿의 고정 부분이 안 보이도록 편집된 것도 지적함
공격 자체가 생각보다 훨씬 허술함
- 이 글은 의도적으로 오해를 불러일으키는 방식으로 작성된 것 같음
  캡처에 나온 부분만 이메일의 전부인 것처럼 만들었지만 실제로는 경고할 법한 텍스트가 이어졌을 것임
- 이해한 바로는 DKIM이 검증되는 이유는 공격자가 실제로 Google에서 받은 이메일을 그대로 포워딩하고 있기 때문임
  실제 공격 벡터는 Google이 공격자가 특정 텍스트를 컨트롤하는 이메일을 보내주게 만드는 점임
개인적으로 여기서의 진짜 취약점은 Google OAuth 앱 이름에 URL을 넣을 수 있고, 이게 Google의 루트 도메인에서 임의의 주소로 무차별적으로 no-reply 메일에 렌더링된다는 점임
비록 링크가 클릭 불가능하더라도, 주변 텍스트를 충분히 위협적으로 만들면 피해자가 직접 접속할 가능성이 큼
DKIM 무결성이 유지되는 포워딩 서비스들이 여러 겹 쌓일 수 있다는 점은 부가적으로 교육적인 측면임
OAuth 앱 이름에 URL, 특히 google.com이 포함된 URL이 들어가는 걸 아예 막아야 함
드디어!
몇 달 전 거의 동일한 이메일을 받은 경험이 있음(google domains 관리자 대상)
확실히 저도 그 메일에 소름이 끼쳤음
저 역시 섣불리 링크를 누르지 않고 기다렸고, 이 사기에 대한 다른 참고자료를 찾으려고 했음
이상했던 점은 모든 이메일 주소가 가려져 있었고 그 마스킹 패턴이 제가 관리하는 이메일과 일치하지 않는다는 점임
이메일 자체는 legit(진짜)이었고, 구글링 해보니 본문 텍스트도 일치함
제 경우엔 사망자 계정 관련 이메일이었는데 실제와 맞지 않았음
하지만 정말로 누군가가 Google을 설득해 제가 사망한 걸로 처리하고 내 Google 계정 전체를 탈취하려는 게 아닐까 100% 가까이 의심함
엄청 무서웠던 경험임
Step 3: 공격자가 Outlook에서 이메일 발송
제가 알기로는 Received: 헤더의 경로를 위조(spoof)하는 건 불가능함
모든 서버는 스스로의 경로 정보를 계속 추가함
그래서 항상 이메일 출처를 검증할 때 그 정보를 확인함
Google에서 온 메일은 Microsoft 서버를 경유할 리가 없음
- 마지막 '신뢰할 수 있는(Trusted)' 서버의 헤더는 위조 불가임, 그 외 경로는 위조 가능함
- 모든 이메일의 헤더를 일일이 수동으로 확인하는지 궁금함
  아니면 이를 표시하거나 시각화하는 도구를 사용 중인지 궁금함
정말 무서운 상황임
이 글에서 배우는 교훈을 친척에게 설명한다고 상상해 보길 바람
신뢰하는 도메인에서 온 메일이고, dkim/dmarc/spf 순서대로 모두 통과해도 항상 의심해야 한다고 설명해야 한다는 게 마음이 무거워짐
하지만 이 공격은 할 수 있는 범위가 꽤 제한됨
예를 들어 남의 Gmail 계정에서 메세지를 위조해 보낼 순 없음
"메시지가 포워딩될 때, DKIM 서명은 본문과 서명 대상 헤더가 변경되지 않는 한 보전됨"
의외인 점은 To: 헤더가 DKIM 서명 대상에 포함되어 있지 않다는 점임
서명 설정 방식을 바꾸거나, 이메일 클라이언트가 메일은 정상적이더라도 To가 변경되었을 때 경고하는 기능이 추가돼야 한다고 생각함
- 이 글의 교훈을 친척에게 설명하는 걸 상상해보라 – 항상 의심하라고
  dkim/dmarc/spf가 뭔지부터 설명해야 하는 난감함
  사실 이런 기술들은 사용자가 몰라도 되는 백엔드 기술임
  이 공격은 생각보다 무섭지 않음
  글이 제품을 팔려고 과장해서 쓰여진 면이 있음
  To: 헤더가 서명에 포함되지 않았다는 점은 사실 별 의미가 없음
  실제로 이메일의 To는 반드시 최종 수신자를 적는 것이 아님
- 이메일에서 항상 의심해야 한다는 태도는 오랫동안 이어진 디폴트 상태였음
  From 필드 자체를 절대 신뢰하지 않는 것이 최선임
- To: 헤더가 DKIM 서명에 포함되지 않은 게 놀랍다고 했는데, 실제로 포함되어 있음
  그래서 원래 To: 값을 유지했어야 함
  재현 섹션의 스크린샷에 원래 To: 주소가 나옴
  이 주소로 배달된다는 의미는 아님
  본질적으로 이메일은 어떤 주소로든, 아무 To: 값을 갖고 배달할 수 있음
- 저의 기본 조언은, 어떤 이메일에서든 행동(action)을 촉구한다면 직접 해당 웹사이트로 이동하라는 것임
  어떤 링크도 클릭하지 않는 것임
  불편해지긴 하지만 결과적으로 문제를 해결할 수 있음
  특히 은행이나 중요한 시스템은 이런 불편함을 감수할 가치가 충분함
- 이런 위협 상황은 나의 직장에서는 이미 정책으로 정착됨
  인터넷 상에서는 뭐든 의심하는 게 좋은 관례임
  많은 소규모 비즈니스, 프리랜서들이 아직도 MFA같은 걸 쓰지 않고, 쓰더라도 토큰 탈취에 쉽게 당함
  이런 계정들이 뚫리면 진짜로 내부 사용자처럼 보이는 악성 메일들이 날아오게 됨
  사용자 입장에서는 정말 legit하게 보임
  그래서 이메일은 늘 의심스럽게 다뤄야 함
작성자는
"Here is the URL from that email [...] https://sites.google.com[...]";
이 링크야말로 첫 번째 의심 신호(red flag)
작성자는 이 포인트를 세 문단 뒤가 아니라 바로 초기에 집어줬어야 했다고 생각함
- 모든 사람이 google.com의 서브도메인을 다 아는 것은 아님
  진짜 문제점은 (SSO의 유효 필드 문제 외에도) Google이 사용자 컨텐츠를 메인 도메인 서브도메인에서 제공한다는 것임
  Drive 같은 다른 서비스들도 그럴 수 있음
- 본인에게는 빨간 신호일지 몰라도, 우리 부모님에게는 아닐 수 있음
전체적으로 이메일 보안이 얼마나 취약한 시스템인지 보여주는 사례라고 생각함
이 포럼에 이렇게 똑똑한 사람들이 많은데, 이런 문제를 한 번에 해결할 대안을 내놓을 수 있다고 생각함
Google도 이런 사이트들은 메인 도메인이 아니라 hostedbygoogle.com 같은 따로 분리된 도메인에서 제공해야 한다는 생각임
왜 지금까지 분리하지 않는지 의문임
- 현실적으로 가능한 모든 대안들은 결과적으로 모든 통제권을 단일 기업에 넘기는 체계임
  이것이 이메일의 남아있는 주요 가치, 즉 누구에게도 완전히 통제되지 않는 시스템의 가치를 잃게 만듦
  기술적인 문제는 충분히 풀 수 있지만, 사람과 이해관계 문제는 훨씬 더 어려움
  문제를 해결할 자원이 있는 주체는, 대부분 완전히 개방된 플랫폼을 만들 동기가 없음
  모든 돈과 통제권을 자기들이 가져가지 않는 이상, 그런 노력을 들일 리 없음
  반대로 모든 이들이 한 회사에 모든 통제권을 넘기고 싶어하지 않음
  이게 바로 기술적 문제가 아니라 비즈니스 문제임
  (메타버스에서 모든 서비스가 아바타·아이템을 공유하는 게 사실상 불가능한 이유도 똑같음
  기술적으로 불가능하다기보단, 권리자들이 절대 허용하지 않을 이슈임)
- Thiel이 투자한 새로운 스타트업 Shadowfax 발표!
  우리의 안전하고 중앙집중화된 독점 서비스는 AI, 블록체인 기반 레이어를 탑재했고 이메일의 낡은 시스템을 대체할 예정임
  이미 미 국방성 수주도 확보했고, 2027년까지 내·외부 모든 연방정부 커뮤니케이션의 표준이 될 전망임

답변달기