먼저 결론입니다. IT를 사칭한 전화가 「패스키를 지금 업데이트하라」고 할 때, 위험은 패스키 개인키가 복사되는 데 있지 않습니다. 유효한 로그인 한 번을 상대에게 넘기는 데 있습니다. 중간자가 가로채는 것은 세션입니다. 기기 코드 흐름에서는 로그인 페이지가 마이크로소프트 정식 도메인일 수도 있습니다. 비밀번호 변경은 비밀번호 한 층만 덮고, 이미 등록된 낯선 인증기는 막지 못합니다. 그 자리에서 대조할 수 있는 것은 전화가 온 경로, 주소창 호스트 이름, 보안 정보 페이지에 기기가 늘었는지입니다. 「나는 이미 패스키를 쓴다」가 아닙니다.
검색 의도를 한 문장으로 먼저 답하기
패스키(Passkey)는 WebAuthn 설계상 개인키를 이 기기나 동기화 키체인에 두고, 의존 당사자의 출처 사이트에 묶습니다. 가짜 로그인 페이지는 이 개인키를 가져가지 못합니다. 「피싱에 강하다」는 말이 성립하는 범위가 여기입니다. 성립하지 않는 범위는 따로 있습니다. 재촉에 밀려 로그인을 끝까지 마치면 세션 토큰이 상대 손에 들어갑니다. 또는 정식 도메인에 남이 준 기기 코드를 넣으면, 토큰이 상대가 통제하는 앱에 발급됩니다.
이 글은 이미 패스키를 켜 둔 사람, 그래도 전화나 문자로 「업데이트하라」는 재촉을 받는 사람, 그리고 동료에게 「패스키가 면책 금메달이 아닌 이유」를 설명해야 하는 개발자와 운영을 위한 것입니다. 마이크로소프트의 사고 통보를 대신하지 않으며, 「패스키를 끄는 방법」으로 쓰이지도 않습니다. 가져가야 할 것은 말투가 덮는 층, 세션과 기기 코드가 각각 훔치는 층, 비밀번호 변경이 부족한 이유, 전화를 끊은 뒤 이 기기에서 대조할 수 있는 항목입니다.
마이크로소프트가 이번 공개에서 가른 층
2026년 9월 9일, 마이크로소프트 보안 연구가 영문 통보를 올렸습니다. 추적한 것은 진행 중인 클라우드 신원 침해입니다. 이상한 로그인 뒤에, 상대가 추가한 인증 수단, 대량의 Microsoft Graph 접근, SharePoint와 OneDrive 내려받기, REST API로 메일을 모으는 행동이 이어집니다. 통보는 이런 활동이 2026년 5월부터 관측됐다고 적습니다. 같은 흐름을 IT조선도 한국어로 정리했습니다. 한국마이크로소프트는 비정상 로그인 이후 인증 수단 등록, Graph 정찰, 토큰 발급, 비정상 SaaS 내려받기와 메일함 활동을 하나의 공격 흐름으로 보라고 말했습니다.
시작은 정교한 피싱 메일이 아닙니다. 개인 휴대폰으로 오는 전화나 문자입니다. 발신자는 회사 IT 헬프데스크를 사칭하고, 다급함을 만듭니다. 패스키, 다중 인증, 통합 인증(SSO)을 지금 바꾸지 않으면 계정이 끊긴다는 말입니다. 링크는 같은 개인 번호로 문자를 따로 보내는 경우가 많습니다. 마이크로소프트는 단정합니다. 말투가 패스키를 맴돌아도, 패스키 등록은 흔히 진짜 목표가 아닙니다. 핑계의 역할은 사람을 두 기술 경로로 데려가는 것입니다. 중간자(AiTM) 피싱이거나, 기기 코드 승인입니다.
중간자 경로는 자격 증명과 세션 토큰을 가로챕니다. 기기 코드 경로에서는 피해자가 마이크로소프트 자신의 인증 페이지에 코드를 넣도록 설득되고, 토큰은 상대가 통제하는 클라이언트로 갑니다. 브라우저 쿠키를 다시 훔칠 필요가 없습니다. 두 길 모두, 이후 접근에서 MFA를 한 번 더 건드리지 않게 만들 수 있습니다. 링크를 Defender에 올리지 않은 개인 휴대폰에서 열면, 단말 쪽 흔적이 거의 없을 수 있습니다. 조사할 때 당사자가 전화나 문자를 기억해 주는 일이, 「침해가 어디서 시작됐는가」를 설명하는 가장 이른, 때로는 유일한 증거가 됩니다.
인프라도 「익숙해 보이게」 짜입니다. 통보가 나열한 주제 도메인에는 passkeyhelpdesk.com, setupmypasskey.com, add-passkey.com, secure-passkey.com이 있고, 회사 이름을 하위 도메인에 끼운 형태도 있습니다. 예는 contoso.add-passkey.com입니다. 같은 회사 이름은 integratedsso.com 같은 SSO 주제 도메인 아래에도 나타날 수 있습니다. 도메인은 등록 후 몇 시간 만에 쓰이므로, 차단 창은 짧습니다. 일부 사례에서는 이미 빼앗긴 동료 계정으로 Teams에 같은 「패스키 업데이트」 메시지를 보내, 전화 바깥에 내부 신뢰를 겹칩니다.
마이크로소프트는 초기 접근을 Storm-3121, Storm-3032를 포함한 여러 운영 집단에 묶었습니다. Storm-3121의 이후는 흔히 ShinyHunters와 Falcon 랜섬으로 이어지고, Storm-3032는 BlackFile에서 갈라져 지금은 Helix 깃발을 쓰는 집단으로 적혀 있습니다. 이는 생태계를 설명할 뿐, 「IT 전화」마다 같은 집단이라고 증명하지 않습니다. 인수인계에 넣을 수 있는 것은 말투와 두 기술 경로이지, 어떤 집단 이름이 아닙니다.
패스키는 가짜 사이트를 막아도, 내어 준 세션은 막지 못합니다
「피싱에 강하다」를 「다시는 속지 않는다」로 읽으면, 자격 증명 층과 세션 층을 한 문장으로 용접한 것입니다. 패스키는 등록할 때 사이트 출처에 묶입니다. 가짜 도메인이 마이크로소프트 로그인 페이지와 같아 보여도, 보통 login.microsoftonline.com용으로 저장한 개인키는 가져가지 못합니다. 비밀번호 재사용에 대한 패스키의 실제 이점입니다. 부정할 필요는 없습니다.
마이크로소프트 조사의 한 시간선이 「이점이 어디서 멈추는가」를 보여 줍니다. T+0분, 관리되지 않는 환경에서 OfficeHome에 접근하고, 오류 50074가 이차 인증을 요구합니다. T+1분, MFA가 끝납니다. 통보는 중간자에 피싱 저항형이 아닌 MFA를 더한 경우라고 적습니다. 이어서 50140이 「로그인 유지」를 끊고, 같은 분에 인증이 성공해 세션이 생깁니다. 이후 약 한 시간 동안 같은 세션이 My Apps, 프로필, 승인 관리, 보안 정보를 열고, Graph로 SharePoint와 Outlook을 열거합니다. 세션이 있으면 상대는 패스키를 다시 건드리지 않아도 됩니다.
그러므로 「나는 이미 패스키를 쓴다」가 지지할 수 있는 결론은 좁습니다. 가짜 사이트가 이 개인키를 바로 내보내기는 어렵다는 것입니다. 지지하지 못하는 결론은 이렇습니다. 사칭 페이지에서 비밀번호나 문자 코드를 한 번 더 넣도록 재촉받지 않는다. 중간자가 이번 로그인이 바꾼 토큰을 가져가지 못한다. 보안 정보 페이지에 상대의 인증기가 생기지 않는다. 뒤의 문장들은 다른 증거가 필요합니다. 누른 호스트 이름이 공식 로그인 도메인인지, 로그인 뒤 보안 정보에 낯선 기기가 있는지를 봐야 합니다.
실제 업무 계정으로 전화 속 링크나 기기 코드를 「시험」하지 마세요. 버려도 되는 한 문장이면 충분합니다. 끊고, 회사가 문서로 공개한 IT 경로로 다시 겁니다. 대조하는 것은 전화가 온 경로와 주소창이지, 유효한 로그인을 상대에게 한 번 더 보내는 일이 아닙니다.
기기 코드가 정식 도메인에서도 성공하는 이유
중간자는 적어도 로그인 페이지처럼 보이는 사이트를 하나 만들어야 합니다. 기기 코드는 그 층도 걷어 냅니다. 공식 흐름은 원래 이렇습니다. 한 클라이언트가 짧은 코드를 보여 주고, 브라우저에서 마이크로소프트 기기 로그인 페이지를 연 뒤 그 코드를 넣으면, 「그 클라이언트」가 나를 대신해 자원에 접근하는 것을 승인합니다. 페이지는 진짜이고, 인증서도 진짜이며, 주소창도 「마이크로소프트인가」를 견딥니다. 속는 지점이 바뀝니다. 이 코드를 누가 만들었고, 승인이 누구의 앱으로 떨어지는가입니다.
통보의 두 번째 공격 순서가 바로 이것입니다. 패스키 말투 뒤에 기기 코드가 오고, 피해자가 정식 인증 페이지에 상대가 준 코드를 넣으면, 토큰이 상대가 통제하는 클라이언트로 발급됩니다. 이후 상대는 이 토큰을 재생해 디렉터리와 파일을 열거합니다. 쿠키를 다시 훔칠 필요도, MFA를 한 번 더 통과할 필요도 없습니다. 「자물쇠와 도메인」을 확인하는 습관이 있는 사람에게, 가짜 사이트보다 그 자리에서 깨뜨리기 어렵습니다. 확인한 그 층이 초록색이기 때문입니다.
그러므로 「주소창이 마이크로소프트다」가 지지할 수 있는 것은 이겁니다. add-passkey.com 같은 사칭 호스트에 비밀번호를 치지 않았다는 것입니다. 지지하지 못하는 것은 이겁니다. 이 코드가 내 노트북의 것이다. 승인 뒤 토큰이 내 브라우저에만 남는다. 전화, 문자, 메신저로 불러 준 코드는 기본값을 「상대의 클라이언트」로 두고, 「공식 페이지이니 안전하다」로 두지 마세요.
비밀번호 변경이 이미 등록된 인증기를 덮지 못하는 이유
성공한 뒤 상대가 먼저 하는 일은, 파일을 더 뒤지는 것이 아니라 자기 인증 수단을 신원에 쓰는 경우가 많습니다. 통보가 적은 것은 새 휴대폰 번호, 인증기 앱, 또는 소프트웨어 일회용 비밀번호입니다. 2026년 9월 4일의 실제 감사 예시에서, 새로 생긴 기록의 기기 이름은 NO_DEVICE, 기기 표시는 SoftwareTokenActivated, 해시 함수 필드는 hmacsha1이었습니다. 「비밀번호를 하나 더 정했다」가 아닙니다. 이후의 이차 인증을 상대가 끝낼 수 있다는 뜻입니다.
마이크로소프트가 탈취가 확인된 계정에 주는 대응 순서는 붙어 있습니다. 활성 세션과 새로고침 토큰을 철회하고, 자격 증명을 재설정하고, 상대가 등록한 인증 수단을 지우고, 상대가 넣은 메일 규칙을 빼며, 피싱 저항형 방식으로 다시 등록하라고 요구합니다. 비밀번호만 바꾸고 보안 정보 페이지를 보지 않으면, 상대가 이미 맞춰 둔 열쇠를 남겨 두는 것과 같습니다. 세 번째 조사 순서는, 상대가 며칠 뒤 예전에 등록한 PhoneAppOTP로 다시 로그인한 뒤 Node.js로 Graph를 자동화하는 모습도 보여 줍니다. 비밀번호가 맞고 이차 인증도 「통과」합니다. 통과한 것은 그들 자신의 요소입니다.
이 기기의 강도 검사가 대조하는 것은 공개된 고빈도 취약 비밀번호 목록입니다. 검사할 비밀번호는 올리지 않으며, 전 웹 조회도 아닙니다. 이 문자열이 너무 흔한지는 알려 줄 수 있습니다. 보안 정보 페이지에 NO_DEVICE가 늘었는지는 알려 주지 못하고, 방금 온 전화가 가짜인지도 증명하지 못합니다. 취약 비밀번호와 세션 탈취는 같은 열의 데이터가 아닙니다. 서로 대신하지 마세요.
| 보이는 말 | 지지할 수 있는 결론 | 지지하지 못하는 결론 |
|---|---|---|
| 이미 패스키를 등록했다 | 가짜 사이트가 이 개인키를 바로 내보내기는 어렵다 | 유효한 로그인을 넘기도록 다시는 재촉받지 않는다 |
| 주소창이 마이크로소프트 공식 도메인이다 | 사칭 호스트에 비밀번호를 치지 않았다 | 기기 코드가 승인한 것은 반드시 내 클라이언트다 |
| 전화가 우리 회사 IT라 하고 부서명까지 댄다 | 상대가 공개 정보를 조사했다 | 이 전화가 회사가 확인한 회신 경로를 탔다 |
| 비밀번호를 바꿨다 | 비밀번호 한 층은 교체됐다 | 낯선 인증기와 철회하지 않은 세션이 모두 죽었다 |
| 문자 링크를 개인 휴대폰에서 열었고, 업무 PC는 멀쩡하다 | 이 업무 PC의 단말 로그는 비어 있을 수 있다 | 클라우드 신원에 상대 세션이 생기지 않았다 |
| 동료가 Teams에서도 패스키를 업데이트하라 한다 | 메시지는 로그인된 내부 계정에서 왔다 | 그 계정은 지금 본인이 통제하고 있다 |
전화를 끊은 뒤, 그 자리에서 대조할 수 있는 층
슬로건은 증거가 되지 않습니다. 아래에서 대조하는 것은 내가 통제하는 일뿐입니다. 전화가 기존 경로를 탔는지, 열려는 호스트 이름, 보안 정보 페이지에 기기가 늘었는지. 업무 계정으로 전화 속 링크를 열어 실험하지 마세요.
- 끊으세요. 회사가 문서로 공개한 IT 티켓, 내부 포털, 회신 번호로 연락하세요. 방금 온 전화로 다시 걸지 말고, 문자 속 링크도 누르지 마세요. 마이크로소프트는 직원이 먼저 찾아온 인증 요청을 신고할, 확인된 경로를 두라고 권합니다.
- 이미 링크를 열었다면 주소창 호스트 이름만 보세요. 회사 이름이 하위 도메인에 있고 접미사는
add-passkey.com,setupmypasskey.com,secure-passkey.com이면 마이크로소프트 로그인 도메인이 아닙니다. 이 페이지에 비밀번호, 문자 코드, 패스키 확인을 넣지 마세요. - 「공식 사이트에 코드 한 줄을 넣으라」고 하면, 그 코드를 어떤 앱, 어떤 기기가 만들었는지 먼저 물으세요. 남이 불러 준 코드는 상대 클라이언트로 둡니다. 공식 기기 코드 페이지는 진짜여도, 승인 대상은 상대 앱일 수 있습니다.
- 회사 계정에 로그인한 뒤 보안 정보 / My Sign-Ins를 열고 인증 수단을 한 줄씩 보세요. 늘어난 휴대폰 번호, 인증기, 소프트웨어 토큰, 특히 기기 이름이 내 휴대폰 같지 않은 것은 관리자 절차로 세션을 철회하고 지우세요. 비밀번호만 바꾸지 마세요.
- 이미 확인한 동료에게 일회용 짧은 비밀을 넘겨야 할 때는 암호문 채널로 바꾸세요. 열람 후 파기를 열고, 버려도 되는 카나리아 한 줄을 쓰세요. 예는
canary-fp-20260921-passkey-lure입니다. 개발자 도구의 Network를 열고 Preserve log를 켜세요. 만든 뒤 이 카나리아를 검색하세요.POST /secrets요청 본문에는 암호문, 만료, 열람 횟수만 있어야 하고, 원문과 해시 뒤의 키는 없어야 합니다. 링크 형태는s.html?id={id}#{key}입니다. RFC 9110은 요청 대상 URI에 프래그먼트를 넣지 않는다고 적습니다.
앞의 네 단계는 신원이 넘어가는 통로를 다룹니다. 다섯 번째는 다른 흔한 실수입니다. 「IT가 달라는 코드」나 임시 비밀번호를 스크린샷으로 채팅에 넣는 일입니다. 이미지 호스트와 앨범에는 픽셀과 OCR이 남을 수 있습니다. 이전 글이 이미 적었습니다. 열람 후 파기는 암호문만 올리고, 키는 # 뒤에 남깁니다. 두 채널을 섞지 마세요. 먼저 채팅에 넣고, 같은 그림에 열람 후 파기 URL 전체를 다시 붙이지 마세요.
전체 링크와 암호문을 같은 채널에 두지 마세요. 전화로 불러 준 기기 코드, 채팅의 스크린샷, 열람 후 파기의 s.html?id=…#… 전체 문자열은 세 가지 다른 유출면입니다. 열쇠와 자물쇠를 같은 메시지에 쓰면, 해시 뒤의 보호는 「이 메시지를 볼 수 있는 사람」에게 이미 없습니다.
「나는 패스키가 있다」를 너무 넓게 읽는 세 가지
첫째, 피싱 저항을 사회 공학 저항으로 읽는 것입니다. 패스키가 출처 사이트에 묶이는 것은, 가짜 로그인 페이지가 개인키를 바로 가져가는 경우를 겨냥합니다. 전화, 문자, 사내 채팅은 이 층을 우회해 중간자나 기기 코드로 데려갈 수 있습니다. 마이크로소프트 자신의 완화 목록에서 「피싱 저항형 MFA 강제」와 나란히 있는 것은, 음성·메일 피싱 교육과, 불필요한 기기 코드 흐름을 막는 일입니다.
둘째, 「페이지가 공식이다」를 「승인 대상이 나다」로 읽는 것입니다. 기기 코드 페이지는 정식 도메인일 수 있습니다. 자물쇠 아이콘을 확인해도, 토큰이 누구에게 발급되는지는 보이지 않습니다. 판단 근거는 코드의 출처입니다. 내 기기가 띄운 것과, 전화로 불러 준 것은 같은 일이 아닙니다.
셋째, 비밀번호 변경을 마무리로 읽는 것입니다. 비밀번호, 세션, 상대가 등록한 인증기, 메일 전달 규칙은 다른 스위치입니다. 통보는 함께 처리하라고 요구합니다. 이 기기에서 새 비밀번호 한 세트를 만드는 것은, 「아직 비밀번호를 쓰는 서비스」한 층만 덮습니다. 비밀번호 생성기를 열면 됩니다. 길이는 6–128자, 기본값은 16자이며, 8자 미만이면 보안이 낮다고 알립니다. 계산은 브라우저에서 끝나고 올리지 않습니다. 세션 철회를 대신하지 않고, 낯선 인증 수단을 지우는 일도 대신하지 않습니다.
자주 묻는 질문
이미 패스키를 등록했는데도 이 전화에 속을 수 있나요?
있습니다. 그리고 흔히 Passkey가 빠져나가서가 아닙니다. 말투는 패스키를 핑계로 쓰고, 진짜 목표는 중간자가 가로챈 세션이거나, 마이크로소프트 정식 도메인에서 상대 앱에 넣어 주는 기기 코드입니다. 패스키는 출처 사이트에 묶여 가짜 로그인 페이지가 개인키를 바로 가져가는 것은 막지만, 내가 상대 클라이언트를 승인하는 것은 막지 못합니다.
주소창이 마이크로소프트 공식 사이트처럼 보이면 기기 코드를 넣어도 되나요?
기기 코드 흐름의 로그인 페이지는 원래 공식 도메인일 수 있습니다. 위험은 「가짜 사이트인가」가 아니라 「이 코드를 누가 줬고, 승인이 누구의 앱으로 가는가」입니다. 전화나 문자로 불러 준 코드는 상대가 통제하는 클라이언트를 승인하며, 내 브라우저 세션이 아닙니다.
비밀번호를 바꿨으면 이번 통화는 끝난 건가요?
부족합니다. 마이크로소프트는 상대가 성공한 뒤 자기 휴대폰 번호, 인증기, 소프트웨어 토큰을 등록한다고 적었습니다. 비밀번호만 바꾸고 세션을 철회하지 않으며 낯선 인증 수단을 지우지 않으면, 상대는 자기가 등록한 두 번째 요소로 다시 들어올 수 있습니다. 보안 정보 페이지에 생긴 기기는 공식 대응 순서로 빼야 합니다.
동료가 채팅에서 일회용 비밀번호를 달라 하면 스크린샷으로 보내도 되나요?
살아 있는 비밀번호나 기기 코드를 채팅 앨범에 넣지 마세요. 짧은 텍스트는 지금 연 탭에서 AES-256-GCM으로 암호화한 뒤 열람 후 파기로 보내고, 키는 링크의 # 뒤에 둡니다. 형태는 s.html?id={id}#{key}입니다. 만들기와 읽기 모두 열어 바로 사용하며 계정이 필요 없습니다. 상대 신원은 방금 온 IT 사칭 전화가 아니라, 회사에 이미 있는 확인 경로로 먼저 맞추세요. 32 KB를 넘는 자료는 파일 암호화로 넘기세요. 단일 파일 5 GB 이하, 출력은 .lock / .enc입니다.
짧은 비밀을 열어 바로 쓰는 채널로 바꾸기
「비밀번호를 되돌리고, 스크린샷은 찍지 않는」 경계를 연습하고 싶다면 FastPwd의 열람 후 파기를 열면 됩니다. 가입은 필요 없습니다. 위의 카나리아를 쓰고, 열람 횟수는 1로 둔 뒤, 만든 다음 다섯 번째 절의 Network와 대조하세요. 요청 본문에는 암호문만 있어야 하고, 원문이나 해시 뒤의 키는 없어야 합니다. 이미 확인한 동료에게 짧은 비밀번호를 넘겨야 할 때만 이 채널을 쓰세요. 먼저 스크린샷을 찍지 말고, 낯선 전화에 기기 코드를 돌려 주지도 마세요.
채팅 기록이나 티켓 본문에 휴대폰 번호, 주민등록번호가 겹쳐 있으면, 보내기 전에 링크 정리에서 규칙 마스킹을 하세요. 정리는 이 기기에서 끝나고, 원문은 업무 데이터로 올리지 않으며 analytics에도 쓰지 않습니다. 아직 비밀번호를 쓰는 사이트는 비밀번호 생성기로 이 기기에서 유일한 비밀번호를 만들고, 전화로 재촉받은 그 문자열을 재사용하지 마세요. 강도 검사가 답하는 것은 「공개된 고빈도 취약 비밀번호인가」이며, 「방금 온 전화가 가짜인가」가 아닙니다.
다음에 「패스키를 지금 업데이트하라」는 전화를 받으면 세 가지를 기억하세요. 첫째, 말투 속의 패스키는 흔히 핑계일 뿐이고, 상대가 원하는 것은 세션이거나 기기 코드 승인입니다. 둘째, 정식 도메인은 토큰을 남의 앱에 발급하는 것을 막지 못합니다. 셋째, 마무리는 보안 정보 페이지와 세션 철회이지, 비밀번호만 바꾸는 일이 아닙니다. 인수인계에 넣을 수 있는 것은 이 세 문장뿐입니다. 「패스키를 켰으니 전화는 무시해도 된다」가 아닙니다.
더 읽을거리
비밀번호를 이미지 호스트에 스크린샷으로 올린 뒤, 로그인 해시가 OCR 평문과 이미지 ID를 막지 못하는 이유는 비밀번호를 이미지 호스트에 스크린샷으로 올린 뒤, OCR 평문과 이미지 ID가 해시보다 위험한 이유에 있습니다. 열람 후 파기가 서버의 암호문 삭제는 증명해도 상대의 스크린샷은 증명하지 못하는 이유는 열람 후 파기는 서버가 암호문을 삭제한 것은 증명해도, 상대가 스크린샷을 안 찍은 것은 증명하지 못한다에 있습니다. URL 해시 뒤가 HTTP에 들어가지 않는 이유는 URL 해시 뒤에 키를 두는 이유, 그리고 그 보호가 깨질 때에 있습니다.