Microsoft Entra 패스키 등록 피싱: M365 계정 탈취 대응 체크리스트

도입

Microsoft Entra 패스키는 피싱 저항성이 강한 인증 수단으로 평가된다. 그러나 강한 인증 수단도 “등록 과정”이 사회공학에 노출되면 다른 문제가 생긴다. 최근 Okta Threat Intelligence가 공개한 분석은 이 지점을 노린 Microsoft 365 계정 탈취 시나리오를 보여준다.

핵심은 패스키나 FIDO2의 암호기술 자체가 깨졌다는 뜻이 아니다. 공격자는 IT 지원팀이나 보안 담당자를 사칭해 사용자에게 전화하고, Microsoft Entra 패스키 등록 화면처럼 보이는 피싱 사이트로 유도한다. 사용자가 기존 비밀번호와 MFA 승인을 제공하는 사이, 공격자는 실제 Microsoft 로그인 흐름에서 정상 세션을 얻고 피해자 계정에 공격자 소유 패스키를 등록하려 한다.

이 공격이 위험한 이유는 지속성에 있다. 비밀번호만 바꾸는 대응으로는 부족할 수 있다. 계정에 등록된 공격자 패스키가 남아 있으면, 공격자는 이후에도 계정 재접속, 메일 접근, 내부 피싱, OAuth 앱 동의, 데이터 탈취로 공격을 확장할 수 있다. 따라서 M365와 Entra 관리자는 “패스키를 도입했는가”보다 “누가, 어디서, 어떤 조건으로 패스키를 등록할 수 있는가”를 먼저 점검해야 한다.

공격 흐름

Okta가 분석한 캠페인은 O-UNC-066/Pink 관련 행위자가 Microsoft Entra 패스키 등록 절차를 모방한 피싱킷을 사용한 사례로 설명된다. Okta는 모든 Microsoft 계정 침해를 직접 관측했다고 단정하지는 않았지만, 피싱킷의 기능과 운영 방식은 공격자가 실제 Entra 패스키 등록 흐름을 악용할 수 있도록 설계된 것으로 보인다.

공격은 보통 전화 기반 사회공학에서 시작된다. 공격자는 helpdesk, IT 운영자, 보안팀을 사칭해 “패스키 등록”, “보안정보 갱신”, “계정 보호 조치” 같은 명목으로 사용자를 설득한다. 이후 사용자를 Microsoft 로그인 또는 Entra 패스키 등록 화면처럼 꾸민 사이트로 유도한다.

피싱킷은 단계별 화면을 제공한다. Okta가 언급한 흐름에는 /identify, /password, /processing, /submit-otp, /submit-authenticator, /approve-authenticator, /passkey/register 같은 경로가 포함된다. 사용자가 UPN과 비밀번호를 입력하면 공격자는 이를 실시간으로 받아 정상 Microsoft 로그인 페이지에 입력한다.

Entra가 MFA를 요구하면 피싱 화면도 그에 맞춰 바뀐다. SMS OTP, TOTP, Microsoft Authenticator push, number matching 등 피해자 환경에 맞는 화면이 표시될 수 있다. 사용자는 통화 중 안내에 따라 OTP를 입력하거나 Authenticator 승인을 완료한다. 이때 사용자는 자신이 패스키 등록 절차를 진행한다고 믿지만, 실제로는 공격자 로그인 시도를 승인하는 셈이 된다.

공격자가 정상 세션을 얻으면 다음 목표는 피해자 계정에 공격자 소유 패스키 또는 FIDO2 인증 방법을 등록하는 것이다. 피해자 화면에는 등록 성공, 복구키 저장, 시드구문 저장처럼 보이는 위장 절차가 표시될 수 있다. 특히 Entra 패스키 등록과 시드구문 또는 BIP-39 문구는 관계가 없으므로, 이런 안내가 보이면 강한 의심 신호로 봐야 한다.

Okta가 관측한 관련 도메인에는 assignpasskey[.]com, deploypasskey[.]com, passkeydeploy[.]com, passkeyadd[.]com, setpasskey[.]com 등이 포함된다. BleepingComputer는 관련 활동이 식음료, 기술, 헬스케어, 자동차, 건설, 항공 분야 조직을 표적으로 삼았다고 보도했다.

관리자가 확인할 로그

관리자는 “패스키 등록 이벤트”만 보면 안 된다. 등록 직전의 로그인, MFA 성공, 조건부 액세스 결과, 등록 이후의 메일·앱·파일 접근을 시간순으로 이어서 봐야 한다.

우선 Entra ID Audit logs에서 보안정보 등록 이벤트를 확인한다. User registered security info, 인증 방법 추가·삭제·변경, FIDO2 또는 Passkey 등록 관련 이벤트가 핵심이다. 대상 사용자, Initiated by, IP, User-Agent, Correlation ID, TargetResources, ModifiedProperties, AdditionalDetails를 함께 확인한다.

다음으로 Entra Sign-in logs를 확인한다. 패스키 등록 직전 30분 안에 평소와 다른 국가, ASN, VPN, 호스팅 사업자 IP, 새 User-Agent, 비정상적인 앱 접근이 있었는지 본다. MFA challenge 성공 직후 보안정보 등록 이벤트가 이어지는지도 중요하다. Authentication Details, Conditional Access 결과, Correlation ID를 Audit logs와 연결하면 흐름을 더 정확히 볼 수 있다.

Authentication Methods Activity도 점검 대상이다. 조직 전체에서 Passkey/FIDO2 등록이 특정 시간대, 특정 부서, 특정 캠페인 직후 급증했는지 확인한다. 평소 등록량이 낮은 조직에서 갑작스러운 등록 증가가 보이면 캠페인성 사회공학을 의심해야 한다.

Microsoft Graph에서는 /users/{id}/authentication/fido2Methods로 사용자별 FIDO2 인증 방법을 확인할 수 있다. createdDateTime, displayName, aaGuid, model, attestationLevel, passkeyType 같은 필드를 통해 등록 시점과 인증기 특성을 검토한다. 특히 관리자 계정이나 민감 권한 계정에서 예상하지 못한 AAGUID, 모델명, attestation 상태가 확인되면 우선 조사 대상으로 올린다.

등록 이후의 후속 행위도 함께 봐야 한다. Exchange Online에서는 Inbox rule, 외부 포워딩, mailbox delegation을 확인한다. Entra와 M365에서는 OAuth 앱 동의, 의심스러운 앱 등록, 관리자 역할 변경, SharePoint·OneDrive 대량 파일 접근과 다운로드를 확인한다. 패스키 등록은 시작점일 뿐, 실제 피해는 그 뒤의 메일·데이터·권한 남용에서 커진다.

탐지 쿼리는 환경에 맞게 조정해야 하지만, 다음 흐름을 기본 축으로 삼을 수 있다.

AuditLogs
| where TimeGenerated > ago(14d)
| where ActivityDisplayName has_any ("registered security info", "authentication method", "FIDO2", "Passkey")
| project TimeGenerated, ActivityDisplayName, Result, InitiatedBy, TargetResources, AdditionalDetails, CorrelationId
| order by TimeGenerated desc

let suspiciousRegistrations =
AuditLogs
| where TimeGenerated > ago(14d)
| where ActivityDisplayName has_any ("registered security info", "authentication method", "FIDO2", "Passkey")
| project RegTime=TimeGenerated, UserPrincipalName=tostring(TargetResources[0].userPrincipalName), CorrelationId;
SigninLogs
| where TimeGenerated > ago(14d)
| join kind=innerunique suspiciousRegistrations on UserPrincipalName
| where TimeGenerated between ((RegTime - 30m) .. RegTime)
| project RegTime, TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName,
          AuthenticationDetails, ConditionalAccessStatus, UserAgent, CorrelationId

통제 체크리스트

가장 먼저 보호해야 할 지점은 Security info registration이다. 모든 사용자가 어디서든 보안정보를 등록할 수 있으면, 공격자는 전화 한 통과 실시간 피싱만으로 강한 인증 수단을 자기 지속 접근 수단으로 바꾸려 할 수 있다. Conditional Access의 User actions에서 보안정보 등록 흐름에 조건을 적용하고, 신뢰 위치, 관리형 또는 준수 디바이스, 사용자 위험도, 로그인 위험도를 반영한다. 고위험 사용자 상태에서는 인증 방법 등록을 차단하는 정책도 검토한다.

패스키 등록 범위도 줄여야 한다. Passkey(FIDO2) self-service setup이 전체 사용자에게 열려 있는지 확인하고, 관리자 계정과 고위험 계정은 별도 그룹으로 분리한다. 업무상 필요한 사용자부터 단계적으로 허용하고, 허용 AAGUID, attestation, device-bound passkey 중심 정책을 검토한다. Microsoft 문서 기준으로 attestation은 등록 시 인증기 모델·벤더 검증에 활용될 수 있지만, 나중에 정책을 켠다고 기존 미검증 패스키 로그인이 자동 차단되는 것은 아니라는 점도 운영 계획에 반영해야 한다.

관리자와 민감 앱에는 phishing-resistant MFA strength를 요구한다. 다만 Authentication Strength만으로 초기 비밀번호 입력이나 보안정보 등록 사회공학을 막을 수는 없다. 따라서 등록 흐름 보호, 관리자 권한 분리, 사용자 위험 기반 차단과 함께 설계해야 한다.

Helpdesk 절차도 명확히 해야 한다. 조직은 “전화로 보안정보 등록을 지시하지 않는다”, “MFA 번호 입력이나 OTP 전달을 요구하지 않는다”, “Authenticator 승인 요청을 대신 눌러 달라고 하지 않는다”는 원칙을 사용자에게 반복 공지해야 한다. Temporary Access Pass 발급은 최소 권한 관리자, 짧은 수명, 단일 사용, 티켓 기반 승인으로 제한한다.

의심 계정이 나오면 등록된 모든 FIDO2/passkey 방법을 확인하고 불필요하거나 의심스러운 항목을 삭제한다. 동시에 비밀번호 재설정, 모든 세션과 refresh token revoke, MFA 재등록 강제를 수행한다. 이후 Exchange 규칙과 포워딩, OAuth 앱 동의, 관리자 역할 변경, SharePoint·OneDrive 대량 접근을 확인한다. 관련 도메인과 하위 도메인은 DNS, Proxy, SWG에서 차단하고 헌팅한다.

위협 레벨별 대응 우선순위

현실적인 우선순위는 관리자와 고위험 계정부터 잡는 것이다. 모든 사용자를 한 번에 막기보다, 관리자 계정의 패스키 등록 조건을 강하게 제한하고, Security info registration 조건부 액세스를 적용한 뒤, 일반 사용자 등록 정책을 단계적으로 정리하는 편이 운영 충돌을 줄인다. 이미 의심 등록이 확인된 계정은 비밀번호 변경만으로 끝내지 말고 인증 방법과 세션을 함께 정리해야 한다.

마지막으로 이 이슈를 “패스키의 실패”로 해석하면 대응 방향이 흐려진다. 문제는 패스키 자체보다 등록 절차와 운영 통제다. 패스키는 여전히 강한 인증 수단이지만, 강한 인증 수단을 누가 등록할 수 있는지 감시하지 않으면 공격자의 지속 접근 수단으로 바뀔 수 있다. M365 관리자의 첫 번째 점검 항목은 최근 FIDO2 등록 로그, Security info registration 조건부 액세스, 관리자 계정의 AAGUID와 attestation 상태다.

참고자료

• Okta Threat Intelligence, Vishing actors target Microsoft Entra passkey enrollment: https://www.okta.com/blog/threat-intelligence/vishing-actors-target-microsoft-entra-passkey-enrollment-/
• BleepingComputer, Entra passkey enrollment vishing targets Microsoft 365 users: https://www.bleepingcomputer.com/news/security/entra-passkey-enrollment-vishing-targets-microsoft-365-users/
• The Hacker News, Hackers use fake Microsoft Entra passkey enrollment pages: https://thehackernews.com/2026/07/hackers-use-fake-microsoft-entra.html
• Microsoft Learn, Passkeys(FIDO2) authentication method: https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-passkeys-fido2
• Microsoft Learn, Conditional Access for security info registration: https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-security-info-registration
• Microsoft Learn, Authentication methods activity: https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-methods-activity
• Microsoft Learn, Sign-in log activity details: https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-in-log-activity-details
• Microsoft Graph, fido2AuthenticationMethod resource: https://learn.microsoft.com/en-us/graph/api/resources/fido2authenticationmethod?view=graph-rest-1.0

본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.