의미 없는 MFA 확인이 반복되면 중요한 승인도 습관처럼 누르게 됩니다. MFA 피로 공격은 그 틈을 노립니다.
MFA 피로 공격은 푸시 폭탄(push-bombing) 또는 프롬프트 폭탄(prompt-bombing)이라고도 불립니다. 탈취한 비밀번호를 쥔 채 인증 푸시 요청을 쏟아부어, 지친 사용자가 알림을 멈추려고 하나쯤 승인하기를 노리는 자격증명 탈취 공격입니다. 대부분의 팀은 확인 단계를 더 늘려 대응합니다. 그러나 피로와 우회 행동을 키우는 것이 바로 그 대응입니다. 더 세게 묻는 것이 아니라 필요한 순간에 묻는 것이 답입니다.
반복 확인이 공격의 빈틈이 됩니다
CISA의 Scattered Spider 권고는 반복되는 MFA 요청을 이 그룹의 자격증명 탈취 기법 중 하나로 꼽습니다. 같은 그룹이 Marks & Spencer의 헬프데스크 비밀번호 재설정 공격에서 보여 주었듯, 이 기법 목록에는 평범한 사회공학도 들어 있습니다.
이런 패턴에 흔히 나오는 대응은 MFA 확인 지점을 더 늘리는 것입니다. VPN에 걸고, 로그인에 걸고, sudo마다 걸고, 새 터미널 창을 열 때마다 겁니다. 하나하나 따로 보면 나름의 근거가 있습니다. 이 확인들이 함께 쌓이면 공격이 의존하는 행동을 그대로 학습시킵니다. 끊임없는 재확인은 알림 무감각을 만들고, 이는 반사적인 승인으로 이어집니다. '승인' 버튼을 누르는 일이 더 이상 의식적인 보안 판단이 아니라 몸에 밴 습관이 됩니다. Verizon의 2025 DBIR는 해당 연도 공공 부문 침해에서 사회공학적 행위의 20% 이상이 MFA 피로 공격에서 비롯됐다는 결과를 내놓았습니다. 업계 전체보다 좁은 표본이고, 보고서 자체도 이 증가분 일부는 빈도가 실제로 늘어난 것이라기보다 보고 관행이 나아진 결과일 수 있다고 밝히고 있습니다. 어느 쪽이든 메커니즘은 모든 보안 팀이 이미 알고 있는 그것입니다. MFA가 의미 있게 느껴지지 않는 순간, 통제로서는 작동을 멈춥니다. 컴플라이언스 보고서에는 여전히 'MFA 사용'으로 기록되지만, 지금은 아무것도 판단하지 않는 상태입니다.
문제는 MFA의 강도가 아니라 확인을 거는 단위입니다. 위험을 막지 못하는 확인이 반복되면, 정말 중요한 확인까지 자동으로 승인하게 됩니다.
사람의 존재는 필요한 순간에만 확인해야 합니다
MFA 인증이 답하는 질문은 하나입니다. 최근에 사람이 여기 있었는가입니다. 이 답은 터미널 창이 몇 개인지나 로그인 세션을 언제 열었는지와는 별개입니다. 같은 질문을 세션 경계마다 되풀이하면 확인만 늘어납니다. 위험한 작업을 시도하는 순간에만 좁혀 물어야 합니다.
Alpacon은 Auth0로 사용자를 인증하는 배포 환경에서 이 질문을 적용합니다. 디렉터리나 로컬 계정이 아니라 Auth0를 인증 경로로 쓰는 환경입니다. MFA를 모든 터미널 진입 시점에 일괄로 요구하지는 않습니다. 첫 번째 권한 작업이 일어날 때 적용합니다. 읽기 전용이고 민감도가 낮은 세션은 로그인 직후 MFA 확인만으로 계속 진행할 수 있습니다. 여기까지가 기준선입니다.
이 기준선을 넘어서는 경우는 더 구체적입니다. 본인 계정이 아닌 OS 계정으로 터미널, 파일 전송, 명령 세션을 열 때는 그 세션이 열리는 시점으로 확인이 앞당겨집니다. Enterprise 플랜에서는 워크스페이스가 이 확인을 모든 대화형 세션에 적용하는 컴플라이언스 기준으로 설정할 수도 있습니다.
두 번째 터미널을 열었다는 이유만으로 다시 묻지는 않습니다. 요청 클라이언트에서 연 컨텍스트는 인증 시점부터 계산한 유효 기간 동안 그 인증 증명을 상속합니다. 다른 컨텍스트를 열어도 같은 인증을 다시 요구하지 않습니다. 특정 세션에서 무엇을 할 수 있는지는 별도 문제이며, MFA 재확인이 아니라 세션별 허용 범위로 다룹니다.
에이전트는 사람의 존재 확인을 물려받지 않습니다
AI 에이전트가 명령을 실행하면 이 문제는 더 분명해집니다. 에이전트는 '지금 사람이 있는가'라는 질문에 답할 수 없습니다. Alpacon의 존재 확인(presence)은 사람에 관한 사실입니다. 에이전트 모드 세션은 이를 새로 만들 수도, 사람의 확인을 물려받을 수도 없습니다. 애초에 에이전트에게는 존재 확인 요구 자체가 발급되지 않습니다. 세션이 이미 받아 둔 사람의 승인으로만 이 관문을 통과하며, 에이전트 스스로 답할 수 있는 단계 상승(step-up) 경로는 없습니다.
이는 존재 확인 모델의 빈틈이 아닙니다. 존재 확인의 대상은 애초에 에이전트가 아니기 때문입니다. 에이전트의 권한 작업은 사전 세션 승인으로 걸러집니다. 위험 판단 경로가 사람에게 넘긴 특정 명령은 검토를 한 번 더 거칩니다. '이 주체가 여기에 있어도 되는가'와 '이 행동을 허용할 것인가'는 서로 다른 질문입니다. 협력업체 직원의 노트북이든 그를 대신하는 에이전트든 이 구분은 같습니다.
확인 범위를 좁힌다고 위험까지 줄어들지는 않습니다
이 글은 확인을 줄이자는 주장이 아닙니다. 사람이 준 진짜 답을 진짜 답으로 대우하고, 새 창을 열었다는 이유만으로 그 답을 즉시 버리지 말자는 주장입니다. 자체 MFA 정책을 점검하는 보안 팀이라면 이렇게 물어야 합니다. 이 통제가 확인하는 것은 '누가 여기 있는가'입니까, 아니면 '방금 무슨 창을 클릭해 열었는가'입니까? 다시 확인할 가치가 있는 쪽은 둘 중 하나뿐입니다.
현재 MFA 정책이 최근에 확인된, 아직 바뀌지 않은 사실을 그대로 인정하는 대신 새 세션이나 새 터미널을 열 때마다 존재 확인을 다시 하고 있다면, 다음 MFA 피로 공격이 그 정책이 만든 피로 지점을 찾아내기 전에 점검할 가치가 있습니다. '이 통제가 확인하는 단위는 무엇인가'라는 범위 설정 질문은 실행 제어 전반에서 반복해서 나타납니다. 최소 권한, 세션 범위, 명령 판단까지 모두 같은 질문을 안고 있습니다. MFA 피로는 그중 사용자가 매일 몸으로 느끼는 통제라서 가장 먼저 드러나는 형태일 뿐입니다.
