패스키 피싱이 클라우드 계정까지 뚫었다: 마이크로소프트가 경고한 공격 흐름
패스키는 비밀번호를 없애는 강력한 방법이지만, 사용자가 가짜 로그인 화면에서 승인을 누르도록 유도하는 공격까지 막아 주는 만능 방패는 아니에요. 9월 13일 공개된 보안 분석은 패스키를 주제로 한 사회공학 공격이 마이크로소프트 클라우드 계정 침해로 이어지고, 이후 공격자가 조직 내부를 탐색하고 데이터를 빼내는 흐름을 설명했어요.[1]
AI를 활용하여 생성한 이미지입니다.
공격은 로그인 화면보다 먼저 시작돼요
공격자는 먼저 직원에게 정상 서비스처럼 보이는 메일이나 링크를 보냅니다. 링크를 누르면 계정 보호나 패스키 등록을 안내하는 화면이 열리고, 사용자는 실제 로그인 과정이라고 생각한 채 인증을 진행할 수 있어요. 이때 문제는 패스키 자체가 아니라 사용자가 승인한 대상과 도메인을 제대로 확인하지 못했다는 점이에요.[1]
이 방식은 비밀번호를 훔치는 전통적인 피싱과 조금 달라요. 공격자가 사용자의 비밀 문자열을 직접 알아내지 않아도, 사용자가 공격자 쪽 사이트에서 인증을 끝내도록 유도하면 세션이나 접근 권한을 넘겨받을 수 있습니다. 따라서 패스키를 도입한 조직도 메일 링크, 도메인, 로그인 대상 검증을 별도로 운영해야 해요.
침해 뒤에는 조용한 내부 탐색이 이어져요
계정에 들어온 뒤 바로 파일을 지우거나 대량으로 내려받는 공격만 있는 것은 아니에요. 분석에 따르면 공격자는 Microsoft Graph API 등을 이용해 사용자, 그룹, 권한, 리소스, 접근 가능한 콘텐츠를 조사하고 고가치 계정과 서비스 아이덴티티를 찾습니다.[1]
이 단계가 위험한 이유는 정상 계정의 정상 기능을 악용하기 때문이에요. 로그인 자체만 보면 이상 징후가 약할 수 있고, 공격자는 인증·조사·자료 반출 단계마다 다른 IP와 인프라를 사용해 탐지를 어렵게 만들 수 있습니다. 최종적으로는 이메일과 파일을 몇 시간에서 며칠 동안 나눠서 가져갈 수 있어요.[1]
AI는 미끼를 더 그럴듯하게 만들어요
마이크로소프트가 별도로 설명한 기업 대상 사기 사례에서는 공격자가 8월 3일부터 5일까지 100만 건이 넘는 사기 메일을 보내고, CEO 사칭과 가짜 ServiceNow 청구서, 조작된 대화 흐름을 한 묶음으로 사용했어요.[2] 수신자가 한 통의 수상한 메일을 보는 것이 아니라, 앞뒤가 맞는 업무 대화처럼 느끼게 만드는 방식입니다.
생성형 AI는 이런 공격의 문장 작성과 수신자별 맞춤화 비용을 낮출 수 있어요. 그렇다고 메일이 자연스럽다는 이유만으로 진짜라고 판단하면 안 됩니다. 오히려 문체가 자연스럽고 조직 내부 정보가 정확할수록 별도 확인 절차가 필요해요.
기업과 개인이 지금 확인할 항목
- 메일 안의 로그인·보안 등록 링크를 누르기 전에 도메인을 직접 확인하세요.
- 고액 결제나 계정 권한 변경은 메일 답장 대신 기존에 알고 있던 연락처로 재확인하세요.
- 클라우드 관리자 계정에는 최소 권한과 별도 관리자 계정을 적용하세요.
- Graph API 호출, 새 애플리케이션 승인, 비정상적인 파일 대량 접근을 함께 모니터링하세요.
- 침해가 의심되면 비밀번호만 바꾸지 말고 세션 폐기, 토큰 취소, 앱 동의 철회, 감사 로그 보존을 순서대로 진행하세요.
패스키 도입 뒤에도 남는 과제
패스키는 비밀번호 재사용과 서버 측 비밀번호 탈취 위험을 줄여 줍니다. 하지만 사용자가 공격자가 준비한 화면에서 인증하도록 만들면 계정 침해의 경로가 남아요. 보안팀은 인증 기술을 도입한 뒤에도 도메인 보호, 피싱 저항형 교육, 권한 통제, 세션 감시를 함께 설계해야 합니다.
개인 사용자는 로그인 알림만 믿지 말고, 인증을 요청한 서비스의 주소와 작업 내용을 먼저 확인하는 습관을 들이는 편이 안전해요. 기업은 인증 성공을 정상 로그인으로 간주하는 데서 멈추지 말고, 그 직후 어떤 API와 파일에 접근했는지까지 살펴봐야 합니다.
패스키를 썼는데도 왜 속을 수 있을까?
패스키는 서버에 비밀번호를 보내는 방식을 줄여 주지만, 사람이 무엇에 인증하는지는 별개의 문제예요. 사용자가 회사 계정 보호를 위해 인증하라는 안내를 보고 공격자 도메인에 들어가면, 브라우저와 인증 장치가 그 사이트의 요청을 처리할 수 있습니다. 그래서 패스키 정책과 함께 허용 도메인, 조건부 접근, 관리자 승인 절차를 묶어야 해요.
특히 헬프데스크나 협업 도구를 통해 들어오는 요청은 메일 필터만으로 걸러지지 않을 수 있어요. 직원이 받은 링크를 메신저로 다시 전달하거나, 외부 협력사가 보낸 문서에서 로그인 화면으로 이동하는 경우도 있기 때문입니다. 로그인 주소를 즐겨찾기하거나 회사 포털에서 직접 들어가는 습관이 링크 기반 공격을 줄이는 데 도움이 돼요.
로그만 봐도 남는 흔적이 있어요
침해가 의심될 때는 단순히 해외 IP 하나를 찾는 방식보다 흐름을 봐야 합니다. 새로운 위치에서 인증한 뒤 Graph API 호출이 갑자기 늘었는지, 평소 사용하지 않던 앱에 동의했는지, 짧은 시간에 많은 파일을 읽었는지, 관리자나 서비스 계정에 접근했는지를 함께 확인해야 해요. 공격자가 탐지 회피를 위해 단계마다 다른 인프라를 쓸 수 있다는 분석을 감안하면, IP 주소 하나만 차단해서는 충분하지 않습니다.[1]
관리자는 감사 로그를 평소 보관 기간보다 길게 남기고, 고위험 작업에 다시 인증을 요구하며, 외부 공유 파일과 메일 전달 규칙을 정기적으로 점검해야 합니다. 개인 이용자도 새 로그인 알림이 오면 위치만 보지 말고 최근 승인한 앱과 세션 목록을 함께 확인하는 편이 좋아요.
사고가 난 뒤의 우선순위
계정 탈취가 의심되면 먼저 해당 계정의 세션과 토큰을 끊고, 공격자가 추가한 앱 동의와 전달 규칙을 제거해야 해요. 다음으로 관리자 계정과 서비스 계정으로 확산됐는지 조사하고, 영향을 받은 파일의 공유 권한을 잠그며, 로그를 보존해야 합니다. 비밀번호 변경은 필요하지만 그것만으로 세션과 이미 발급된 토큰이 모두 무효화되는 것은 아니므로 순서를 잘못 잡으면 공격자가 계속 남아 있을 수 있어요.
기업은 직원에게 “패스키도 피싱될 수 있다”는 사실만 알리는 데서 끝내지 말고, 가짜 보안 등록 안내를 신고하고 확인하는 경로를 짧게 만들어야 해요. 신고가 복잡하면 직원은 링크를 다시 눌러 확인하려고 할 수 있습니다. 실제 대응 절차는 기술 설정만큼 중요해요.
Sources
- [1] The Hacker News
- [2] Microsoft Security
