ShieldCrash, 9월 패치를 깐 뒤에도 디펜더가 다시 거론되는 이유

9월 업데이트를 깔았는데 디펜더 이야기가 다시 나온 이유

2026년 9월 8일 패치 화요일은 이미 쓰인 Windows 제로데이 2건과 기록적인 수정 건수로 주목받았습니다. 그 직후 같은 주 안에 다른 이름이 붙었습니다. ShieldCrash입니다.

검색 의도는 단순합니다. 방금 깐 9월 보안 업데이트가 이 문제까지 막아주는지, 아니면 디펜더만 따로 봐야 하는지입니다. 결론부터 나누면, 9월 누적 업데이트가 고친 것은 Windows Update Stack(CVE-2026-81963)과 ALPC(CVE-2026-85880) 같은 OS 구성 요소입니다. ShieldCrash가 겨냥하는 지점은 Microsoft Malware Protection Engine, 즉 디펜더 엔진입니다. 엔진 업데이트는 누적 업데이트와 같은 날짜에 묶이지 않을 수 있습니다.

이름이 헷갈리기 쉬운 이유는 한 연구자가 같은 제품을 연속으로 공개했기 때문입니다. 6월 RoguePlanet, 8월 ShieldBreak, 9월 ShieldCrash입니다. 세 이름은 서로 다른 날짜의 주장이고, 공식 번호가 있는 것은 지금 ShieldBreak뿐입니다.

RoguePlanet에서 ShieldCrash까지, 지금 확인된 연표

마이크로소프트가 공식으로 적은 것과 연구자·언론이 이은 일정을 분리해야 합니다.

MSRC 권고문의 ShieldBreak 요지는 짧습니다. Microsoft Defender의 멀웨어 보호 엔진에서 권한 상승이 있고, 약점은 CWE-284(부적절한 접근 제어), CVSS 기본 점수 7.8, 심각도는 Important입니다. 공격 벡터는 로컬, 필요한 권한은 낮음, 사용자 조작은 없습니다. 공개는 됐고, 권고 작성 시점 기준 실제 악용은 없다고 적혀 있습니다. 악용 가능성은 “Exploitation More Likely”입니다.

NVD 제품 표는 엔진 1.1.0.0 이상, 1.1.26080.3 미만을 영향 범위로 둡니다. 버전 표기에서 FAQ의 1.26070.7과 제품 표의 1.1.x 형식이 섞여 있으므로, PC에서 볼 때는 AMEngineVersion 숫자 전체를 그대로 적고 1.1.26080.3과 비교하는 편이 안전합니다.

ShieldCrash 쪽에는 아직 이 표가 없습니다. 연구자 README는 “Microsoft가 ShieldBreak를 제대로 고치지 못했다. 특정 조건에서는 같은 문제가 다시 발생한다. 9월 패치가 적용된 지원 Windows 전부에서 SYSTEM으로 임의 파일 읽기를 보여 준다”고 적습니다. BleepingComputer는 마이크로소프트 대변인에게 논평을 요청했으나 당시 응답이 없었다고 했습니다. SecurityWeek도 논평을 구했다고 적었습니다. 확인일 기준 공식 권고 추가는 보이지 않습니다.

PoC가 보여 주는 것과 보여 주지 않는 것

제로데이라는 단어만 보면 브라우저를 열기만 해도 PC가 넘어가는 그림이 떠오릅니다. 공개된 설명은 그 그림과 거리가 있습니다.

연구자는 나중에 전체 SYSTEM 개념 증명으로 다시 만들 수 있다고 여지를 남겼습니다. 그 문장은 가능성이며, 지금 배포된 파일이 그 단계라는 뜻은 아닙니다. SecurityWeek는 연구자 설명을 바탕으로 “전체 System 권한을 얻어 SAM을 떨어뜨릴 수 있다”고 적었습니다. 공개 README의 현재 문장과 톤이 다르므로, 보도 문장과 PoC 범위를 같은 확정 사실로 묶지 않는 것이 맞습니다.

GitHub에 소스와 부가 파일이 올라와 있습니다. 이 글은 파일 구성과 실행 방법을 다루지 않습니다. 보안 뉴스를 확인하려고 저장소를 클론하거나 실행 파일을 받는 행동은 이득보다 위험이 큽니다. 테스트가 필요하면 격리된 가상 머신과 공식 대응이 나온 뒤를 전제로 해야 합니다.

집 PC에서 디펜더 엔진 버전을 확인하는 순서

지금 할 일은 개념 증명을 재현하는 것이 아니라, 내 PC가 어떤 엔진을 쓰는지 기록하는 것입니다. 화면 경로는 Windows 11 기준입니다.

1. 시작 메뉴에서 Windows 보안을 엽니다.
2. 바이러스 및 위협 방지로 들어갑니다.
3. 바이러스 및 위협 방지 업데이트 아래의 보호 업데이트를 엽니다.
4. 보안 인텔리전스 버전과 마지막 업데이트 시각을 적습니다.
5. 같은 화면에서 업데이트를 한 번 더 확인합니다.

엔진 번호는 보안 앱 화면보다 PowerShell이 분명합니다. Windows Terminal 또는 PowerShell에서 아래를 실행합니다.

Get-MpComputerStatus | Select-Object AMEngineVersion, AMProductVersion, AntivirusSignatureVersion, AntivirusSignatureLastUpdated, RealTimeProtectionEnabled, IsTamperProtected

AMEngineVersion이 엔진입니다. ShieldBreak 공식 수정선은 1.1.26080.3입니다. 이 숫자보다 낮으면 최소한 ShieldBreak 구간에도 못 미친 상태입니다. 이 숫자 이상이어도 ShieldCrash 우회 주장은 남습니다. 우회를 막는 새 엔진 번호는 확인일 기준 공식 문서에 없습니다.

화면의 보안 인텔리전스 버전과 엔진 버전은 다릅니다. 인텔리전스 버전은 탐지 서명이 언제 갱신됐는지를 보여 주고, 엔진 버전은 검사 코드 자체가 어느 빌드인지를 보여 줍니다. 서명이 오늘 날짜여도 엔진이 8월 이전이면 ShieldBreak 공식선과 비교할 숫자가 부족한 상태일 수 있습니다. 반대로 엔진이 최신이어도 서명이 며칠 전이면 일반적인 악성코드 탐지가 늦습니다. 둘 다 적어야 “업데이트했다”는 말이 의미가 있습니다.

업데이트 채널도 OS 패치와 다릅니다. 디펜더 엔진과 서명은 월례 누적 업데이트를 기다리지 않고 Microsoft Update와 클라우드 보호로 따로 내려옵니다. 회사 PC에서 월례 패치만 승인하고 디펜더 채널을 막아 두면, 집 PC보다 엔진이 오히려 늦을 수 있습니다. 관리 콘솔이 있다면 승인 범주에 보안 인텔리전스와 안티멀웨어 플랫폼이 포함돼 있는지 같이 봅니다.

서명이 오래됐다면 관리자 명령 프롬프트에서 다음으로 보안 인텔리전스만 받을 수 있습니다.

"%ProgramFiles%\Windows Defender\MpCmdRun.exe" -SignatureUpdate

플랫폼이 최신이면 Microsoft Learn 안내대로 C:\ProgramData\Microsoft\Windows Defender\Platform\<버전>\MpCmdRun.exe를 씁니다. 명령이 실패하면 타사 백신이 디펜더를 수동 모드로 내린 경우가 많습니다. 그때는 주 백신 콘솔의 엔진·모듈 업데이트를 먼저 봅니다.

지금 할 일과 하지 말아야 할 일

일반 이용자에게 필요한 조치는 공격 기법을 따라 하는 일이 아닙니다. 로컬 권한 상승이 의미 있으려면 먼저 낮은 권한의 실행 권한이 있어야 합니다. 그 앞단을 줄이는 쪽이 체감 효과가 큽니다.

Windows 보안에서 변조 방지(Tamper Protection)가 꺼져 있으면 켭니다. IsTamperProtected가 True여야 합니다. 실시간 보호가 꺼져 있으면 이번 이슈와 별개로 먼저 복구합니다.

타사 백신을 쓰는 환경은 디펜더가 꺼져 있거나 제한 모드일 수 있습니다. 그 경우 ShieldCrash 전제는 달라집니다. 반대로 “디펜더를 끄면 안전하다”는 결론은 나오지 않습니다. 엔진 구멍을 피하려고 실시간 보호를 내리는 선택은 더 흔한 악성코드 경로를 엽니다.

마이크로소프트가 다음 엔진 수정을 내면 같은 PowerShell 명령으로 숫자만 다시 비교하면 됩니다. 그 전까지 공식 미확인 우회를 “이미 막혔다”거나 “모든 PC가 장악된다”로 단정할 근거는 없습니다.

9월 OS 패치와 디펜더 엔진을 따로 봐야 하는 이유

같은 주 보안 뉴스가 한 덩어리로 보이지만, 이용자가 눌러야 하는 스위치는 두 개입니다.

• 설정 → Windows 업데이트의 9월 누적 업데이트. 이미 악용된 OS 권한 상승 2건이 여기 들어 있습니다.
• Windows 보안 → 보호 업데이트. 디펜더 엔진·서명이 여기 있습니다.

전자만 초록으로 바뀌고 후자의 날짜가 며칠 전이면, ShieldBreak 공식 수정선조차 못 지켰을 수 있습니다. 반대로 엔진이 1.1.26080.3 이상이어도 ShieldCrash는 연구자 주장 단계로 남습니다. 두 상태를 한 문장으로 섞으면 “업데이트했으니 끝” 또는 “업데이트해도 소용없다”는 잘못된 결론이 나옵니다.

누구에게 급한가. 관리자 권한으로 평소 웹을 하고, 출처가 불분명한 도구를 자주 실행하며, 원격 데스크톱이 열려 있는 Windows가 우선입니다. 개발용으로 여러 유틸리티를 관리자 권한으로 돌리는 PC, 공용 계정 하나로 세금·뱅킹·게임까지 처리하는 가정용 데스크톱도 같은 줄에 둡니다. 권한 상승은 이미 실행된 코드를 키우는 단계라, 앞단에서 설치 파일을 많이 받는 환경일수록 의미가 커집니다.

굳이 덜 급한 쪽은 표준 사용자 계정만 쓰고, 업데이트가 자동이며, 설치 파일을 거의 받지 않는 개인 노트북입니다. 회사 MDM이 엔진을 강제하고 로컬 관리자를 막아 둔 단말도 우선순위가 내려갑니다. 다만 그 노트북도 엔진 숫자 한 줄은 확인해 두는 편이 낫습니다. 확인 비용이 작습니다.

SYSTEM으로 파일을 읽는다는 말이 실무에서 가리키는 지점은 “인터넷에서 바로 해킹된다”가 아닙니다. Windows는 일반 계정이 못 보는 설정·자격 증명 파일이 있습니다. 그 파일을 읽을 수 있으면 이미 들어와 있는 공격자가 다음 계정으로 넘어가거나, 오프라인으로 비밀번호 해시를 가져갈 여지를 얻습니다. 연구자가 SAM을 언급한 이유도 그 맥락입니다. 반대로 읽기만 되는 현재 PoC는 설정을 바꾸거나 서비스를 설치하는 단계까지는 가지 않습니다. 이 차이를 무시하면 위험도 과대평가하거나, “읽기뿐이니 무시해도 된다”는 반대 착각이 생깁니다.

가정집 이용자가 추가로 손볼 만한 항목은 짧습니다. 로컬 계정이든 Microsoft 계정이든 일상 작업은 표준 사용자로 두고, 설치가 필요할 때만 관리자 확인창을 받습니다. 원격 데스크톱을 쓰지 않으면 끕니다. 공유기 관리자 페이지 기본 비밀번호는 바꿉니다. 이 세 가지는 ShieldCrash 전용 조치가 아니라, 로컬 권한 상승 계열 이슈가 나올 때마다 반복되는 기본값입니다.

Windows Server를 돌리는 환경은 집 PC보다 계정 파일의 가치가 큽니다. 도메인 컨트롤러나 파일 서버에 디펜더만 올려 두고 월례 패치 창을 길게 열어 둔 경우가 그렇습니다. 서버는 누적 업데이트 일정과 엔진 자동 승인 여부를 따로 적습니다. 일부 외신은 연구자 테스트를 인용해 Windows 11 25H2와 Windows Server 2025에서 재현률이 높다고 전했습니다. 이 문장은 2차 보도이며, 마이크로소프트 제품별 영향 표가 아닙니다. 서버 담당자는 그 문장을 공식 범위로 읽지 말고, 지원 버전 전체에 대한 연구자 주장을 전제로 엔진 번호를 수집하면 됩니다.

앞으로 볼 지점은 세 가지입니다. MSRC가 ShieldCrash 또는 CVE-2026-69414 개정으로 새 엔진 번호를 적는지, CISA KEV에 올라가는지, 실제 공격 기록이 나오는지입니다. 그 전 단계의 공개 PoC는 위험 신호이지, 가정집 인터넷 회선만으로 PC가 넘어간다는 증거가 아닙니다.

자주 나오는 질문

디펜더를 끄면 ShieldCrash를 피할 수 있나

공식 권고도, 연구자 README도 그런 처방을 내리지 않습니다. 엔진을 끄는 선택은 이번 주장보다 발생 빈도가 높은 일반 악성코드 경로를 엽니다. 보호를 유지한 채 엔진·서명을 갱신하는 쪽이 기본입니다.

타사 백신을 쓰면 무관한가

주 백신이 타사이고 디펜더가 꺼져 있으면 ShieldCrash 전제는 약해집니다. 정기 검사만 남는 제한 모드인지는 Windows 보안 첫 화면에서 확인합니다. 타사 제품 자체의 엔진 업데이트는 별도입니다.

9월 누적 업데이트를 아직 안 깔았다

그 업데이트는 이미 악용된 OS 제로데이 2건을 포함합니다. ShieldCrash와 주제가 겹치지 않습니다. 누적 업데이트를 먼저 설치하고, 이어서 디펜더 보호 업데이트를 확인하면 됩니다.

주요 출처: MSRC CVE-2026-69414, NVD CVE-2026-69414, BleepingComputer, SecurityWeek, The Register, Microsoft Learn Get-MpComputerStatus. 확인일 2026-09-10.