infiltr8 Lab

MFA 피로 공격과 번호 매칭 완화 사례 분석

2026-10-08 · ##인증·iam ##인증-개념

이 글은 공개된 1차·2차 자료를 우리 관점에서 다시 쓰고 정리한 것입니다. 특정 문장·코드를 그대로 옮기지 않았으며, 자세한 내용은 하단 References의 원문을 참고하세요.

Security · 인증·IAM · 인증 개념 [정보성]

MFA는 “비밀번호 하나로는 부족하다”는 전제에서 출발합니다. 그런데 두 번째 인증이 단순한 승인/거부 버튼이라면, 그 버튼 자체가 새로운 약한 고리가 됩니다. MFA 피로 공격은 기술적 취약점을 깨는 것이 아니라 사람의 피로와 습관을 겨냥합니다. 그래서 이 사례는 “인증 수단은 맥락을 함께 보여줘야 한다”는 설계 교훈의 교과서 같은 묶음입니다.

01 MFA 피로 공격이란

MFA 피로 공격은 공격자가 이미 유효한 아이디와 비밀번호를 확보한 상태에서 시작합니다. 로그인 시도를 반복하면 피해자의 휴대폰에는 푸시 승인 요청이 계속 뜹니다. 공격자는 사용자가 실수로, 또는 알림을 멈추려는 귀찮음에 결국 한 번 승인하기를 노립니다. 영어권에서는 “push bombing”, “MFA prompt bombing”, “MFA push spam”, “MFA spamming” 같은 여러 별칭으로 불립니다.

여기서 중요한 전제가 하나 있습니다. 이 공격은 MFA를 우회하는 것이지 비밀번호를 우회하는 것이 아닙니다. 즉 비밀번호가 이미 유출되었거나 추측 가능하다는 조건이 먼저 깔려 있어야 합니다. 그래서 MFA 피로 공격은 자격증명 유출의 “후속 단계”로 이해하는 편이 정확합니다.

Cisco Talos는 이 기법을 “사용자가 수락할 때까지, 실수로든 반복 알림을 멈추려는 의도로든, 대상 기기에 대량의 푸시 요청을 보내는 과정”으로 설명합니다(우리 말로 재구성). 핵심은 양으로 밀어붙여 판단을 흐리게 만든다는 점입니다.

02 왜 통하는가 — 맥락 없는 승인 버튼

근본 원인은 단순 승인/거부 방식의 푸시 알림이 지금 승인하는 것이 어떤 세션인지 사용자에게 보여주지 않는다는 데 있습니다. 버튼만 누르면 되므로, 사용자는 “내가 방금 로그인했던가?”를 제대로 따지지 않고 반사적으로 승인할 수 있습니다. 마이크로소프트의 Alex Weinert는 이 공격이 “사용자가 인증 중인 세션의 맥락을 요구하지 않는, 단순한 음성·SMS·푸시 알림을 승인하는 능력”에 의존한다고 설명했습니다(우리 말로 재구성).

마이크로소프트는 자체 연구에서 약 1%의 사용자가 단순 승인 요청을 첫 시도에 수락한다고 밝힌 바 있습니다. ⚠️미확인: 이 수치는 마이크로소프트 블로그 원문을 본 리서치 세션에서 직접 열지 못하고 미러·2차 매체로만 확인됐으며, 표본·측정 기간 같은 정의도 공개되지 않았습니다. “마이크로소프트의 자체 주장” 정도로 받아들이는 편이 안전합니다. 다만 수치 정확성과 별개로, 단순 승인 방식에는 일정 비율의 오승인이 존재한다는 방향성 자체는 여러 사례와 표준 권고가 뒷받침합니다.

사회공학이 결합되면 성공률이 올라갑니다. 공격자는 피로를 유발한 뒤 “IT 지원팀”을 사칭해 전화나 메시지로 “알림을 멈추려면 승인하라”고 유도합니다. 실제 사례에서도 여러 날에 걸친 전화, 메신저를 통한 사내 IT 사칭이 함께 쓰였습니다.

승인이 한 번 떨어지면 끝이 아닙니다. 공격자는 보통 곧바로 자신의 새 기기를 MFA에 등록해 지속적인 접근 수단을 확보합니다. 그래서 단 한 번의 무심한 승인이 장기 침투로 이어집니다.

03 번호 매칭 — 틈을 좁히는 완화

번호 매칭의 개념은 단순합니다. 로그인 화면에 숫자를 표시하고, 사용자가 그 숫자를 인증 앱에 입력(또는 선택)해야 승인이 완료됩니다. 로그인을 시작하지 않은 사용자는 그 숫자를 알 수 없으므로, “모르고 그냥 승인”이 구조적으로 불가능해집니다.

이 설계의 묘미는 공격자에게 한 가지 일을 더 강요한다는 점입니다. 공격자가 승인을 받아내려면 피해자에게 그 숫자를 알려줘야 하는데, “화면에 뜬 숫자를 불러 달라”는 요청 자체가 사용자에게 경고 신호가 됩니다. 평범한 로그인에서는 누가 내게 숫자를 물어볼 일이 없기 때문입니다.

NIST의 디지털 신원 지침(SP 800-63B 개정 4판)도 같은 방향을 가리킵니다. 이 지침은 2차 기기와 1차 채널 사이에 비밀값(숫자)을 실제로 옮기도록 요구해, 사용자가 인증 세션에 능동적으로 참여하고 있음을 확인하게 합니다. 또한 같은 지침은 2차 채널에서 단순히 “승인”만 누르는 방식을 더 이상 권장하지 않으며, 그 이유로 “인증 피로” 공격을 직접 언급합니다.

미국 CISA는 번호 매칭의 위치를 분명히 합니다. 번호 매칭은 피싱 저항(phishing-resistant) MFA보다는 약하지만, 피싱 저항 MFA를 당장 도입하기 어려운 조직에게는 최선의 임시(interim) 완화책이라는 것입니다. 바꿔 말하면 번호 매칭은 종착지가 아니라 중간 다리입니다.

실제로 번호 매칭은 피싱 저항 수단이 아닙니다. NIST는 사용자가 출력값을 손으로 입력하는 OTP·대역외(OOB) 인증기를 피싱 저항으로 인정하지 않습니다(세션 바인딩이 없기 때문). 따라서 실시간으로 사용자와 서버 사이에 끼어드는 중간자(AiTM) 피싱 프록시 앞에서는 번호 매칭이 무력해질 수 있습니다. 번호 매칭은 “무심한 승인”은 막지만 “속아서 숫자를 넘기는” 경우까지 막지는 못합니다.

04 실제로 관측된 흐름

이 공격이 이론이 아니라는 점은 여러 공개 침해 사례가 보여줍니다. 시간순으로 짚으면 다음과 같습니다.

  • 2021년 12월 (Mandiant): 유효 자격증명을 가진 공격자가 피해자의 정상 기기에 MFA 요청을 반복 발송해 결국 승인을 받아낸 활동이 보고됐습니다. ⚠️미확인: 일부 2차 매체는 이를 SolarWinds 캠페인 자체의 침투 벡터로 묘사하나, 원 보고서는 특정 그룹의 후속 활동을 다루는 것으로 보여 단정하기 어렵습니다.
  • 2022년 3월 (마이크로소프트 DEV-0537 / Lapsus$): 대상 사용자에게 MFA 프롬프트를 스팸하는 기법이 명시됐고, 완화책으로 번호 매칭·전화 기반 MFA 회피·FIDO 토큰이 권고됐습니다.
  • 2022년 (시스코): 직원 개인 계정에서 동기화된 자격증명이 출발점이었고, 음성 전화와 MFA 피로가 결합돼 한 번의 푸시 승인을 받아낸 뒤 신규 MFA 기기 등록으로 이어졌습니다. 시스코 Talos는 2022년 8월 10일 이를 공개했습니다.
  • 2022년 9월 (우버): 외부 계약자의 자격증명이 선행 유출된 상태에서 반복된 2단계 승인 요청이 이어졌고, 계약자가 결국 하나를 수락했다고 우버가 공식 설명했습니다. ⚠️미확인: “한 시간 넘게 폭격했다”는 식의 시간 세부나 특정 메신저 사용 같은 묘사는 일부 보도·공격자 주장에 기댄 것으로, 우버 공식 발표는 “반복 요청 끝에 승인”까지만 기술합니다.

이 사례들을 나란히 놓으면 공통 구조가 보입니다. 자격증명 선행 유출 → 승인 요청 반복(+사회공학) → 한 번의 승인 → 신규 기기 등록으로 지속성 확보. 번호 매칭은 이 사슬에서 “한 번의 승인” 고리를 끊으려는 통제입니다.

벤더들의 대응도 이 흐름을 따라갔습니다. 마이크로소프트는 2022년 9월 “MFA 피로 공격 방어” 글을 내며 번호 매칭이 미리보기 단계에서 이미 매일 약 1만 개 기업에서 쓰이고 있다고 밝혔고, 이후 Authenticator 푸시 알림에 번호 매칭을 테넌트 전체에 적용했습니다(현행 Microsoft Learn 문서가 전면 적용을 확인). ⚠️미확인: “2023년 5월 8일부터”라는 특정 시행일은 인용한 11개 레퍼런스(ref5 Weinert 2022-09 글, ref4 번호 매칭 문서 포함) 어디에도 명시돼 있지 않아 이번 패스에서 1차출처로 확인하지 못했습니다. 일반 지식과는 부합하나, 확인된 것은 “전면 적용”이라는 사실까지입니다. CISA는 2022년 10월 31일 번호 매칭과 피싱 저항 MFA에 관한 안내 자료 두 종을 발행했습니다.

05 대응방안 (경량)

  • 권고 조치: 가능하면 단순 승인 푸시 대신 번호 매칭을 켭니다. 더 강한 보호가 필요하면 FIDO2/WebAuthn 하드웨어 키 같은 피싱 저항 MFA로 올라갑니다. 번호 매칭은 임시 다리, 피싱 저항이 최종 목적지입니다.
  • 차선책: 번호 매칭을 바로 못 쓰는 환경이라면, 마지막 성공 인증 이후 푸시 발송 횟수·속도에 합리적 제한을 두고(NIST도 이를 권고), 반복 거부·폭주 시 경보·일시 잠금을 겁니다. 푸시 대신 TOTP/OTP로 바꾸는 것도 한 걸음입니다.
  • 탐지 관점: 계정별 푸시 시도 급증, 반복 거부 후의 승인, 신규 MFA 기기 등록을 모니터링합니다. 사용자에게는 “요청하지 않은 승인 알림은 거부하고 신고하라”고 교육합니다.

06 벤더별 구현 메모

주요 인증 앱이 번호 매칭을 어떻게 부르고 설정하는지 간단히 정리합니다(현행 문서 기준).

  • Microsoft Authenticator: 번호 매칭이 모든 푸시 알림에 적용되며 사용자·관리자 옵트아웃이 불가합니다. ⚠️미확인: Authenticator가 “추가 컨텍스트” 기능으로 요청 앱 이름·위치 등을 함께 표시한다는 설명이 알려져 있으나, 이번에 인용한 번호 매칭 문서(ref4)에는 그 세부가 담겨 있지 않아(별도 문서 소재) 1차출처로 확인하지 못했습니다.
  • Cisco Duo — Verified Duo Push: 로그인 프롬프트의 숫자 코드를 Duo Mobile에 입력하게 합니다. 코드는 3~6자리이며 기본값은 3자리입니다. 목적은 푸시 괴롭힘·피로 공격에 대한 추가 보호입니다.
  • Okta Verify — Number Challenge: 로그인 위젯에 표시된 숫자와 일치하는 숫자를 Okta Verify에서 선택하게 합니다. 적용 범위는 세 가지(사용 안 함 / 고위험 로그인에만 / 모든 푸시 챌린지)로 설정합니다. ⚠️미확인: 선택지로 제시되는 숫자 개수는 Okta 문서가 명시하지 않습니다(통상 몇 개로 알려져 있으나 미확인).

참고로 CISA의 번호 매칭 안내 자료는 번호 매칭을 지원하는 벤더로 Microsoft, Okta, Duo를 명시합니다.

짧은 논평

MFA 피로 공격의 교훈은 특정 제품의 버그가 아니라 인증 UX 설계에 있습니다. “예/아니오” 한 번으로 끝나는 결정은 편하지만, 그 편함이 공격 표면이 됩니다. 번호 매칭은 사용자에게 최소한의 능동적 행동을 요구해 “무심한 승인”을 걷어냅니다. 같은 사고방식은 비밀번호 없는 로그인, 트랜잭션 서명, 민감 작업의 단계별 재인증에도 그대로 옮겨집니다. 다만 번호 매칭조차 실시간 중간자 피싱 앞에서는 한계가 있다는 점이 “피싱 저항 MFA”가 최종 목적지인 이유입니다.

이 한 가지 완화는 분명 도움이 되지만, 맥락 없는 승인이라는 뿌리는 다른 자리에서 또 자랍니다. 그래서 우리는 도구 하나가 아니라 “인증은 맥락을 보여줘야 한다”는 원칙을 남깁니다.

References / 참고자료

이 글은 아래 공개 자료를 우리 관점에서 다시 쓰고 정리한 것입니다. 특정 문장·코드를 그대로 옮기지 않았으며, 자세한 내용은 원문을 참고하세요.

  1. CISA, “CISA Releases Guidance on Phishing-Resistant and Numbers Matching Multifactor Authentication” (2022-10-31) — MFA 피로 공격 정의와 번호 매칭의 “임시 완화” 위치. https://cisa.gov/news-events/alerts/2022/10/31/cisa-releases-guidance-phishing-resistant-and-numbers-matching
  2. CISA, “Implementing Number Matching in MFA Applications” (팩트시트 PDF) — 번호 매칭 지원 벤더(Microsoft·Okta·Duo) 명시. https://www.cisa.gov/sites/default/files/publications/fact-sheet-implement-number-matching-in-mfa-applications-508c.pdf
  3. NIST, “SP 800-63B rev.4 — Digital Identity Guidelines” — 단순 승인 방식의 부적절성과 “인증 피로”, 비밀값 전달 요구, 푸시 속도 제한, 피싱 저항 인정 범위. https://pages.nist.gov/800-63-4/sp800-63b.html
  4. Microsoft Learn, “How number matching works in MFA push notifications for Authenticator” — Authenticator의 번호 매칭 전면 적용. https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-number-match
  5. Alex Weinert (Microsoft), “Defend your users from MFA fatigue attacks” (2022-09-28) — 맥락 없는 승인이라는 근본 원인, 1% 수치 주장, 번호 매칭 개념·채택 규모. 원문 https://techcommunity.microsoft.com/blog/microsoft-entra-blog/defend-your-users-from-mfa-fatigue-attacks/2365677 (본 리서치는 미러 https://thewindowsupdate.com/2022/09/28/defend-your-users-from-mfa-fatigue-attacks/ 로 확인)
  6. Microsoft Security, “DEV-0537 criminal actor targeting organizations…” (2022-03-22) — Lapsus$의 MFA 프롬프트 스팸 기법과 완화 권고. https://www.microsoft.com/en-us/security/blog/2022/03/22/dev-0537-criminal-actor-targeting-organizations-for-data-exfiltration-and-destruction/
  7. Cisco Talos, “Cisco Talos shares insights related to recent cyber attack on Cisco” (2022-08-10) — 시스코 침해에서의 피로+음성 사회공학 흐름과 신규 기기 등록. https://blog.talosintelligence.com/recent-cyber-attack/
  8. Uber Newsroom, “Security update” (2022-09) — 반복 2단계 승인 요청 끝에 계약자가 수락한 경위. https://www.uber.com/newsroom/security-update/
  9. Mandiant (Google Cloud), “Suspected Russian Activity Targeting Government and Business Entities Around the Globe” (2021-12-06) — 유효 자격증명 보유 상태의 반복 MFA 요청 관측. https://cloud.google.com/blog/topics/threat-intelligence/russian-targeting-gov-business
  10. Cisco Duo, “Policy & Control Documentation” (Verified Duo Push) — 숫자 코드 입력 방식과 자리수(3~6, 기본 3). https://duo.com/docs/policy
  11. Okta, “Configure Okta Verify push notification options” (Number Challenge) — 숫자 선택 방식과 세 가지 적용 범위. https://help.okta.com/oie/en-us/content/topics/identity-engine/authenticators/ov-push-settings.htm