패스키 피싱이 클라우드 계정까지 뚫었다: 마이크로소프트가 경고한 공격 흐름

AI를 활용하여 생성한 이미지입니다.

패스키는 비밀번호 재사용과 서버 측 비밀번호 탈취 위험을 줄이는 인증 방식이지만, 사용자가 가짜 사이트에서 인증을 승인하도록 유도하는 사회공학까지 자동으로 막아 주는 만능 방패는 아닙니다. 9월 13일 공개된 보안 분석은 패스키를 미끼로 한 피싱이 마이크로소프트 클라우드 계정 침해로 이어지고, 이후 공격자가 조직 내부를 조사하고 자료를 가져가는 흐름을 설명했습니다.[1] 대응의 초점은 패스키를 버리는 것이 아니라 인증 전후의 계정·세션·API 활동을 함께 통제하는 데 있습니다.

공격은 인증 화면보다 먼저 시작됩니다

공격자는 정상 서비스처럼 보이는 메일이나 링크를 보냅니다. 계정 보호, 패스키 등록, 보안 경고를 이유로 만든 페이지에서 사용자는 실제 로그인이라고 생각하고 인증을 진행할 수 있습니다. 이때 패스키 자체의 비밀을 훔친다기보다, 사용자가 공격자가 준비한 대상에게 인증을 완료하도록 유도하는 것이 핵심입니다.[1]

패스키는 사이트와 기기의 결합을 이용해 비밀번호 피싱에 강한 특성이 있지만, 사람이 잘못된 도메인에서 인증을 승인하면 계정 침해 경로가 남을 수 있습니다. 따라서 “패스키를 쓰니 링크를 눌러도 안전하다”는 해석은 피해야 합니다.

침해 뒤에는 정상 기능을 이용한 탐색이 이어질 수 있어요

분석에 따르면 공격자는 계정에 들어온 뒤 Microsoft Graph API 등을 이용해 사용자, 그룹, 권한, 리소스와 접근 가능한 콘텐츠를 조사하고 가치가 높은 계정과 서비스 아이덴티티를 찾습니다.[1] 바로 파일을 지우거나 한 번에 내려받지 않고, 정상 계정이 평소 사용하던 기능을 이용하면 로그인 한 건만으로는 이상 징후가 약하게 보일 수 있습니다.

그래서 탐지는 인증 성공 여부 하나로 끝나면 안 됩니다. 새 위치나 기기에서의 로그인, 평소 사용하지 않던 API 호출, 애플리케이션 동의와 권한 상승, 짧은 시간의 광범위한 파일 열람을 연결해서 봐야 합니다. 조직의 정상 업무가 자동화되어 있다면 허용 목록만 믿지 말고 담당자와 실제 작업 범위를 맞춰야 합니다.

AI가 만든 자연스러운 미끼를 확인하는 법

마이크로소프트가 별도로 설명한 기업 대상 사기 사례에서는 공격자가 8월 3일부터 5일까지 100만 건이 넘는 사기 메일을 보내고, CEO 사칭, 가짜 ServiceNow 청구서, 조작된 대화 흐름을 함께 사용했습니다.[2] 수신자는 문장 하나가 이상한 메일이 아니라 앞뒤가 이어지는 업무 대화처럼 보이는 흐름을 만나게 됩니다.

생성형 AI가 문장 작성과 수신자별 맞춤화 비용을 낮출 수 있다는 점은 경계할 필요가 있지만, 문체가 자연스럽다는 사실만으로 AI 작성이나 공격을 판정할 수는 없습니다. 금액·계정·권한 변경이 포함된 요청은 메일의 설득력과 관계없이 기존에 알고 있던 전화번호나 내부 시스템에서 다시 확인하세요.

개인 사용자가 지킬 세 가지

1. 메일의 로그인·보안 등록 링크를 누르기 전에 주소를 직접 확인하고, 가능하면 북마크나 공식 앱에서 로그인합니다.
2. 인증 화면에 표시된 서비스 이름과 실제 브라우저 도메인, 지금 승인하는 작업을 확인합니다.
3. 결제·권한 변경·새 기기 등록은 메일 답장 대신 별도 채널로 재확인합니다.

로그인 알림이 왔다는 사실만 보고 승인하지 마세요. 내가 시작하지 않은 인증 요청은 거부하고, 반복되면 조직 보안팀이나 서비스의 공식 지원 경로에 신고합니다. 브라우저가 도메인 전환을 표시하거나 인증 대상이 평소와 다르게 보이면 진행을 중단하는 것이 좋습니다.

기업 관리자가 준비할 통제

• 관리자 계정과 일반 업무 계정을 분리하고 최소 권한을 적용합니다.
• 새 애플리케이션 동의, 권한 상승, 서비스 아이덴티티 사용을 별도로 승인합니다.
• Graph API 호출, 비정상 파일 대량 접근, 새 위치·기기의 인증을 상관 분석합니다.
• 메일 보안에서 유사 도메인, 외부 리디렉션, 긴급 결제 요청을 표시합니다.
• 사용자가 실수로 승인했을 때 신고해도 불이익이 없도록 신고 경로와 훈련을 마련합니다.

패스키 도입 프로젝트의 성공 기준도 “비밀번호가 사라졌는가”만으로 잡지 마세요. 등록과 복구 절차, 분실 기기, 공유 기기, 관리자 계정, 외부 협력사, 계정 탈취 후 세션 폐기까지 포함해야 합니다. 피싱 저항형 인증을 사용하더라도 권한이 과도하면 침해 한 건의 영향이 커질 수 있습니다.

의심될 때의 초기 대응

1. 감염이 의심되는 기기에서 추가 로그인을 반복하지 말고 보안팀에 알립니다.
2. 해당 계정의 세션과 토큰을 폐기하고, 새 애플리케이션 동의와 위임 권한을 확인합니다.
3. 필요한 경우 자격 증명을 재설정하되, 비밀번호만 바꾸고 끝내지 않습니다.
4. 감사 로그·메일·파일 접근 기록을 보존해 공격자의 탐색 범위를 파악합니다.
5. 영향받은 계정과 서비스 아이덴티티의 권한을 임시로 줄이고 복구 계획을 세웁니다.

로그를 먼저 보존하지 않고 계정과 앱을 무작정 삭제하면 범위 파악에 필요한 흔적을 잃을 수 있습니다. 반대로 침해가 진행 중이면 보존과 격리의 우선순위가 달라질 수 있으므로, 조직의 사고 대응 절차와 전문 담당자의 지시를 따르세요.

자주 묻는 질문

패스키를 삭제하면 피싱을 막을 수 있나요?

패스키 삭제가 근본적인 해결책은 아닙니다. 안전한 인증 방식과 도메인 확인, 최소 권한, 세션 감시를 함께 운영하는 것이 중요합니다.

메일 문장이 자연스러우면 진짜일 가능성이 높은가요?

아닙니다. 자연스러운 문장과 내부 정보는 공격자가 준비할 수 있습니다. 금액·권한·로그인 요청은 독립된 채널로 확인하세요.

인증 알림만 확인하면 충분한가요?

인증 요청의 서비스·도메인·작업 내용을 확인해야 합니다. 인증 뒤의 API 호출과 파일 접근도 이상 징후가 될 수 있습니다.

실수로 가짜 화면에서 인증했다면?

즉시 조직 보안팀이나 서비스의 공식 사고 대응 경로에 알리고, 세션·토큰 폐기와 앱 동의 철회를 진행해야 합니다. 상황에 따라 비밀번호 변경과 기기 점검도 포함하되, 로그 보존을 잊지 마세요.

복구 뒤에 다시 확인할 항목

계정을 되찾았다고 바로 정상 업무로 돌아가기보다, 공격자가 남긴 지속 접근을 확인해야 합니다. 최근 로그인 기기와 위치, 등록된 인증 수단, 복구 이메일과 전화번호, 새로 추가된 애플리케이션 동의, 메일 전달 규칙, 공유 링크와 파일 권한을 목록으로 비교하세요. 조직 계정이라면 관리자 역할과 서비스 아이덴티티의 비밀값도 검토해야 합니다.

침해가 의심되는 사용자가 여러 명이면 개별 비밀번호 변경만으로 끝내지 말고 공통으로 사용한 앱과 로그인 페이지, 리디렉션 도메인을 차단합니다. 단, 공격에 쓰인 메일과 URL은 조사에 필요한 증거가 될 수 있으므로 무심코 삭제하기보다 보안팀의 보존 절차를 따르세요. 복구 완료의 기준은 로그인 성공이 아니라 세션·토큰·앱 권한·자동 전달 경로를 확인하고 재발 방지 통제를 적용한 상태입니다.

복구 후에는 같은 공격이 반복되지 않도록 짧은 모의 훈련을 실제 업무 흐름에 맞춰 설계하세요. 보안 등록 링크를 메일에서 누르지 않고 공식 포털로 이동하는 절차, 결제 요청을 별도 채널로 확인하는 절차, 의심스러운 인증을 신고하는 절차를 각각 연습하면 단순히 “피싱을 조심하라”는 안내보다 행동 기준이 분명해집니다. 훈련 결과는 처벌보다 개선할 통제와 교육 항목을 찾는 데 사용해야 합니다.

복구 보고서에는 무엇을 확인했고 무엇이 확인되지 않았는지도 남기세요. 로그인 기록이 없다고 침해가 없었다고 단정하지 말고, 로그 보관 기간과 API 활동의 가시성을 함께 기록해야 합니다. 이후 권한 검토 날짜와 담당자를 정해 두면 시간이 지난 뒤에도 새 앱 동의나 관리자 역할 변화를 놓치기 어렵습니다.

Sources

1. [1] The Hacker News: Attackers use passkey phishing to compromise cloud accounts
2. [2] Microsoft Security: Protecting organizations from AI-assisted executive impersonation and invoice fraud