noreply.net으로 샌 기업 기밀 40만 통, 이메일 주소 한 줄이 만든 보안 사고

noreply.net으로 샌 기업 기밀 40만 통, 이메일 주소 한 줄이 만든 보안 사고

AI 뉴스 썸네일

메일을 버릴 주소가 필요했던 기업들이 실제 외부 도메인을 입력했어요. 그 결과 고객 정보와 직원 기록, 내부 접근 정보가 도메인 소유자에게 계속 전달됐어요. 공격자가 침입한 사건이 아니라, 시스템 설정과 계정 정리 관행이 만든 유출이에요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
유출 규모	noreply.net에는 2024년 12월 이후 401,796통이 도착했고 28,365통에 첨부 파일이 있었어요	한두 회사의 오타가 아니라 여러 조직의 반복된 설정 문제라는 점이 드러났어요
발생 원인	기업 시스템이 실제 소유자가 있는 외부 도메인을 버리는 주소처럼 사용했어요	사람이 실수로 보낸 메일보다 계정 관리와 자동 발송 규칙이 더 큰 위험을 만들었어요
대응 방법	외부 도메인 대신 내부 주소나 예약된 `.invalid` 도메인을 써야 해요	퇴사자 계정 처리와 알림 수신처를 함께 점검하면 같은 유형의 유출을 줄일 수 있어요

1. 존재하지 않는다고 믿은 주소로 기업 정보가 흘렀어요

보안 연구자 코리 솔로위츠는 2020년에 noreply.us를, 2024년에 noreply.net을 샀어요. 개인 메일을 정리하려고 캐치올 받은 편지함을 열었는데, 곧 여러 기업 시스템이 이 도메인으로 민감한 메일을 보내고 있다는 사실을 확인했어요. 지방정부의 부상 보고서와 학교 계정 설정 메일, 수리 주문서, 시험 플랫폼 접근 정보까지 섞여 있었어요. 2

noreply.net에는 2024년 12월 이후 401,796통이 들어왔어요. 하루 평균 약 700통이에요. 이 가운데 첨부 파일이 있는 메일은 28,365통이었어요. noreply.us에도 구매 후 2,345일 동안 37,255통이 쌓였어요. 두 도메인이 발표 직전 한 달 동안 받은 메일만 11,000통이 넘었고, 발신 주소는 14,000여 개, 루트 도메인은 6,200여 개였어요. 2

유출 경로는 의외로 평범했어요. 일부 시스템은 `[회사명]@noreply.net` 같은 주소가 아무에게도 전달되지 않을 거라고 여겼어요. 퇴사자나 삭제된 계정의 이메일 주소를 외부 플레이스홀더 도메인으로 바꾼 사례도 있었어요. 하지만 noreply.net은 등록된 공개 도메인이었고, 소유자는 모든 주소로 온 메일을 받을 수 있었어요.

728x90

비슷한 일은 deleteduser.com에서도 반복됐어요. 이 도메인을 약 15달러에 산 마이크 셰워드는 첫 한 시간에 서로 다른 조직 3곳의 메일을 받았어요. 이후 휴가 승인 요청과 실명이 담긴 호텔 예약, 영국 정부 기관의 화상회의 초대가 들어왔어요. 한 AI 기업은 산업 현장의 CCTV 정지 이미지 수천 장을 보냈어요. 계정을 지우지 않고 이메일 주소만 바꾸는 관행이 실제 외부 수신자에게 정보를 넘긴 셈이에요. 2

연구자들은 비슷한 도메인을 악의적인 사람이 사들이는 일을 줄이려고 30개가 넘는 도메인을 별도로 매입했어요. 솔로위츠가 플레이스홀더 후보 7,136개를 조사했을 때 328개에서 캐치올 받은 편지함이 확인됐어요. 확인된 숫자만으로 전체 범위를 계산하기는 어려워요. 다만 실제 외부 도메인을 폐기용 주소로 쓰는 관행이 특정 조직 하나에 머물지 않았다는 점은 분명해요. 1

어디부터 확인해야 하나요

먼저 퇴사자와 삭제 계정의 이메일 필드를 확인해요. 주소가 `noreply`, `deleteduser`, `example` 같은 외부 도메인으로 바뀌었다면 즉시 내부 주소로 옮겨야 해요. 계정을 비활성화할 때 이메일 값만 바꾸지 말고, 알림 구독과 결재선, 예약 작업, 외부 서비스 연동도 함께 끊어야 해요.

메일 발송 규칙에는 허용 도메인 목록을 두는 편이 안전해요. 고객 정보나 첨부 파일을 보내는 작업이라면 수신 도메인이 회사 소유인지 먼저 확인할 수 있어요. 등록되지 않은 외부 도메인이 들어오면 발송을 막고 보안 담당자에게 알려야 해요. 메일 로그에서 `noreply`, `deleted`, `invalid` 같은 문자열을 찾는 것만으로도 오래된 설정을 발견할 수 있어요.

존재하지 않는 도메인이 꼭 필요하다면 `.invalid`를 쓸 수 있어요. RFC 6761은 `.invalid` 아래 이름이 존재하지 않는다는 부정 응답을 내도록 정하고 있어요. 실제 소유자가 생길 수 있는 일반 도메인보다 목적이 명확해요. 3

왜 중요한가요

이번 사례는 외부 공격을 막는 장비만으로는 잡기 어려운 유출이에요. 정상 권한을 가진 기업 시스템이 정해진 규칙에 따라 메일을 보냈기 때문이에요. 방화벽이나 로그인 경보에는 이상이 없어도 수신 주소가 잘못돼 있으면 정보는 조직 밖으로 나가요. 2

개발팀과 보안팀은 계정 생애주기를 함께 봐야 해요. 퇴사자를 비활성화한 뒤에도 알림, 보고서, 첨부 파일이 예전 계정에 연결돼 있을 수 있어요. 계정 삭제 절차에 메일 수신처와 예약 작업, 제3자 연동 확인을 넣으면 이런 빈틈을 줄일 수 있어요.

운영 중인 서비스도 버리는 주소를 문자열로 직접 넣지 않는 편이 좋아요. 발송하지 않을 상황이라면 애플리케이션 단계에서 작업을 종료해야 해요. 꼭 주소가 필요하다면 회사가 통제하는 내부 도메인이나 `.invalid`처럼 용도가 예약된 이름을 사용해요. 공개 도메인은 지금 비어 보여도 나중에 누군가 살 수 있어요. 3

참고 자료

1. 한 연구자가 noreply.net을 샀더니 기업 기밀이 쏟아짐 — GeekNews
2. A researcher bought noreply.net. Companies started sending him secrets. — Ars Technica·WIRED
3. RFC 6761: Special-Use Domain Names — IETF