처리중입니다. 잠시만 기다려주세요.
TTJ 코딩클래스
정규반 단과 자료실 테크 뉴스 코딩 퀴즈
테크 뉴스
Hacker News 2026.05.24 27

마이크로소프트 내부 계정이 스팸 발송에 악용되고 있다는 경고

Hacker News 원문 보기
마이크로소프트 내부 계정이 스팸 발송에 악용되고 있다는 경고

신뢰받는 도메인이 무기가 될 때

이메일 보안에 관심 있는 분이라면 이런 경험 한 번쯤 있으실 거예요. 회사 메일함을 열었는데 @microsoft.com이나 @notice.microsoft.com처럼 익숙한 도메인에서 메일이 와 있고, 제목도 "결제 확인"이나 "구독 갱신" 같은 그럴듯한 내용이라 무심코 클릭할 뻔한 상황이요. 최근 보도에 따르면 사기꾼들이 실제로 마이크로소프트의 내부 계정을 악용해서 이런 스팸성 링크를 대량으로 뿌리고 있다고 해요.

공격자들은 마이크로소프트가 정식 고객 안내에 사용하는 인프라를 그대로 통해서 메일을 보내고 있어요. 그러니까 받는 사람 입장에서는 "진짜 마이크로소프트에서 왔다"고 신뢰하게 되는 거죠. SPF, DKIM, DMARC 같은 이메일 인증 체계도 다 통과해버려서, 회사 메일 서버의 스팸 필터가 걸러내기가 굉장히 까다로워요. 보안업계에서는 이런 수법을 "신뢰 남용(trust abuse)"이라고 부르거든요.

어떻게 이런 일이 가능한가

조금 더 자세히 들여다볼게요. 마이크로소프트는 365 구독, 애저, 깃허브 같은 수많은 서비스에 대해 자동화된 안내 메일을 보내요. 이런 메일은 회사 내부의 "트랜잭션 메일" 인프라를 통해 발송되는데, 일부 협력사나 영업 파트너 계정이 이 인프라에 접근할 수 있는 권한을 가지고 있어요. 이번 사건에서는 그 협력사 계정 중 일부가 탈취되었거나, 권한 검증이 허술해서 외부인이 임의로 메일 본문을 채워 보낼 수 있었던 것으로 보여요.

SPF, DKIM, DMARC가 뭔지 잠깐 짚고 갈게요. 이게 뭐냐면, "이 메일이 진짜 그 도메인에서 보낸 게 맞는지" 확인해주는 일종의 도장 같은 기술이에요. SPF는 "이 IP에서 보내는 건 우리 메일이다"라고 도메인 소유자가 미리 등록해두는 거고, DKIM은 메일 본문에 디지털 서명을 붙여 위변조를 막아주고, DMARC는 위 두 가지가 실패했을 때 어떻게 처리할지 정책을 정해주는 표준이에요. 평소에는 이 세 가지가 피싱 메일을 잘 막아주는데, 이번 케이스처럼 "정식 인프라"를 거쳐서 발송되면 모든 인증을 통과해버리니까 무력해지는 거죠.

공격자들은 이렇게 정식 인증을 통과한 메일에 단축 URL이나 가짜 결제 페이지 링크를 심어요. 사용자가 클릭하면 마이크로소프트 로그인 페이지를 흉내 낸 사이트로 이동시켜 계정 정보를 빼내거나, 가상화폐 결제를 유도하기도 한다고 보도되고 있어요.

이런 "신뢰 남용"은 처음이 아니다

사실 이런 수법은 작년부터 점점 늘어나는 추세예요. 페이팔의 인보이스 발송 기능을 악용해 가짜 청구서를 진짜 페이팔 서버에서 보내는 사례, 구글 캘린더 초대를 통한 피싱, 깃허브 노티피케이션 시스템을 악용한 악성코드 배포 같은 사건들이 줄줄이 이어졌어요. 공통점은 "공격자가 직접 이메일 서버를 세팅하지 않고, 신뢰받는 빅테크의 인프라를 빌려 쓴다"는 점이에요.

이런 흐름은 방어자 입장에서 굉장히 골치가 아파요. 예전에는 도메인 평판이나 IP 평판 기반으로 차단하면 됐는데, 이제는 마이크로소프트나 구글 같은 "화이트리스트"에 거의 무조건 들어가는 도메인에서 공격 메일이 날아오니까요. 그래서 최근 보안 솔루션들은 단순한 도메인 필터링을 넘어서 메일 본문의 의도(intent)를 머신러닝으로 분석하거나, 링크를 자동으로 열어보고 동작을 검증하는 "URL detonation" 같은 기법을 쓰기 시작했어요.

한국 개발자가 챙겨봐야 할 점

실무에 적용할 수 있는 부분이 꽤 있어요. 첫째, 사내에서 마이크로소프트 365나 애저를 쓰고 있다면 보안 관리자와 상의해서 DMARC 정책을 quarantine이나 reject로 강화하는 걸 검토해보세요. 한국 기업들은 의외로 DMARC를 none(아무 조치 안 함)으로 두는 경우가 많아요. 둘째, 사용자 교육 자료에서 "보낸 사람 도메인이 유명 회사면 안전하다"는 식의 설명을 빼야 해요. 이제는 그 가정 자체가 깨졌거든요.

서비스 개발자라면 우리 서비스에서 보내는 트랜잭션 메일도 한 번 점검해볼 만해요. 만약 외부 협력사가 우리 도메인으로 메일을 발송할 수 있는 구조라면, 그 권한이 적절히 분리되어 있는지, 발송 가능한 템플릿이 제한되어 있는지 확인이 필요해요. "우리 도메인의 평판"은 한 번 무너지면 회복하기가 정말 어려워요. 글로벌 메일 사업자들이 한 번 "스팸 발송지"로 낙인찍으면, 정상 메일까지 다 스팸함으로 가버리거든요.

마무리

신뢰는 가장 강력한 무기이자 동시에 가장 큰 약점이 될 수 있다는 걸 잘 보여주는 사건이에요. 여러분 회사에서는 외부 협력사에 메일 발송 권한을 어떻게 관리하고 계신가요? 한 번쯤 점검 일정을 잡아볼 만한 주제 같아요.


🔗 출처: Hacker News

이 뉴스가 유용했나요?

이 기술을 직접 배워보세요

파이썬으로 자동화를 시작해보세요

파이썬 기초부터 자동화까지 실전 강의.

파이썬 강의 보기

"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"

실제 수강생 후기
  • 비전공자도 6개월이면 첫 수익
  • 20년 경력 개발자 직강
  • 자동화 프로그램 + 소스코드 제공

매일 AI·개발 뉴스를 받아보세요

주요 테크 뉴스를 매일 아침 이메일로 전해드립니다.

스팸 없이, 언제든 구독 취소 가능합니다.