Microsoft Defender 취약점 CVE-2026-41091, CVE-2026-45498

Microsoft Defender 취약점 2건(CVE-2026-41091, CVE-2026-45498) 대응 매뉴얼

마이크로소프트의 기본 보안 제품인 Defender에서 발견된 취약점 2건이 실제 공격에 악용된 것으로 알려진 상황에서는, “영향 확인 → 즉시 완화 → 패치 적용 → 사후 점검”의 속도가 곧 피해 규모를 결정합니다. CVE-2026-41091(권한 상승), CVE-2026-45498(서비스 거부)를 운영 환경 기준으로 정리합니다.

핵심 요약
- 권한 상승(EoP): 로컬 사용자/침입자가 Defender 관련 구성요소를 발판으로 SYSTEM급 권한을 노릴 수 있는 시나리오가 핵심
- 서비스 거부(DoS): Defender 기능이 비정상 종료/중단되거나 보호 상태가 흔들리는 형태로 “보안 공백”이 생길 수 있음
- 실무 기준으로 보면: “Defender 플랫폼/엔진/서명 버전”과 “Windows 보안 업데이트 적용 상태”를 먼저 고정하고, 그 다음 침해 징후를 확인하는 흐름이 안정적입니다.

개요

이번 이슈의 포인트는 “기본 탑재되는 보안 제품”에서 발생했고, 실제 악용 정황이 언급된다는 점입니다. 즉, 단순히 특정 기능을 켠 일부 환경만의 문제가 아니라 “기본 보호 체계” 자체가 공격 표면이 될 수 있습니다.

취약점 1

CVE-2026-41091 · 권한 상승(EoP)

취약점 2

CVE-2026-45498 · 서비스 거부(DoS)

이 문서는 “일반오류형(확장형 매뉴얼)” 구조로, 개요 → 환경 → 증상 → 1차 점검 → 심화 분석 → 복구 → 재발 방지 순서로 바로 실행 가능한 체크리스트를 제공합니다.

환경

Defender는 구성요소가 여러 겹(플랫폼/엔진/서명/서비스)이라 “정확히 무엇이 설치되어 있고 어떤 버전인지”부터 잡아야 합니다. 운영 환경에서는 Windows 업데이트 정책(WSUS/Intune/ConfigMgr 등)과 함께 관리되는 경우가 많아, 정책과 실제 단말 상태가 일치하는지 확인하는 과정이 중요합니다.

사전 수집(권장)

• OS 버전/빌드, 누적 업데이트 적용 여부
• Microsoft Defender 플랫폼/엔진/서명 버전
• Defender 관련 서비스 상태(실행/중지/비정상 종료 반복)
• 단말이 서버인지(Windows Server) 클라이언트인지, 그리고 조직 정책(실시간 보호/클라우드 보호 등)

버전/상태 확인(기본 명령)

# PowerShell (관리자 권한 권장)
Get-ComputerInfo | Select-Object OsName, OsVersion, OsBuildNumber

# Defender 상태/버전
Get-MpComputerStatus | Select-Object AMProductVersion, AMEngineVersion, AntispywareSignatureVersion, AntivirusSignatureVersion, NISEngineVersion, NISSignatureVersion, RealTimeProtectionEnabled

# Defender 서비스(예: WinDefend 등) 상태 확인
Get-Service | Where-Object { $_.Name -match 'WinDefend|WdNisSvc|Sense' } | Select-Object Name, Status, StartType

운영 환경에서는
“정책상 최신”이라고 가정하지 말고, 실제 단말에서 버전 값을 수집해 표준값과 비교하세요.
특히 악용 정황이 있는 경우, 패치/플랫폼 업데이트가 일부 단말에서만 누락되는 순간 공격 표면이 열립니다.

증상

두 취약점은 성격이 다르기 때문에 증상도 다르게 나타날 수 있습니다. 다만 “권한 상승”은 성공하면 흔적이 은밀할 수 있고, “서비스 거부”는 오히려 눈에 띄는 장애로 나타나는 편입니다.

가능한 징후(참고)

• EoP(권한 상승) 관점: 일반 사용자 컨텍스트에서 SYSTEM 권한 프로세스/서비스가 비정상적으로 생성되거나, 권한이 급격히 상승한 실행 흐름이 관찰됨
• DoS(서비스 거부) 관점: Defender 서비스가 반복적으로 중지/재시작, 실시간 보호가 꺼짐, 스캔/업데이트 실패가 급증
• 보안 이벤트 로그에 Defender 관련 오류/크래시 이벤트가 특정 시점부터 집중

로그 확인(기본)

# 이벤트 로그(Defender Operational)
# GUI: 이벤트 뷰어 > Applications and Services Logs > Microsoft > Windows > Windows Defender > Operational
# PowerShell 예시:
Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" -MaxEvents 50 | Select-Object TimeCreated, Id, LevelDisplayName, Message

주의
“서비스가 살아있다”는 것만으로 안전하다고 결론 내리기 어렵습니다.
악용 정황이 있는 이슈는 “패치/플랫폼 업데이트 적용”과 “침해 지표 점검”을 함께 진행해야 합니다.

1차 점검

1) 노출 단말 식별(자산 기준)

• 조직 자산 목록에서 Windows 단말/서버를 “Defender 사용 그룹”으로 묶어 대상 범위를 확정
• 중요도 기준으로 우선순위 부여: 인터넷 노출 서버, 원격 접속 사용자 단말, 관리 서버(AD/배포 서버) 우선

2) 업데이트 적용 상태 확인(우선순위 1)

실제 악용 정황이 언급된 상황에서는 “취약 버전인지 여부”가 1차 분기점입니다. 조직의 업데이트 경로(Windows Update/WSUS/Intune/ConfigMgr)를 기준으로, (1) 배포 성공 여부, (2) 재부팅 대기 여부, (3) 실패 코드 존재 여부를 함께 봅니다.

# 설치된 업데이트(간단 확인)
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 20

# Windows Update 상태/로그는 운영 표준에 따라 확인(WSUS/Intune/ConfigMgr 포함)

3) Defender 보호 상태 확인(우선순위 2)

# 핵심 플래그 빠르게 확인
(Get-MpComputerStatus).RealTimeProtectionEnabled
(Get-MpComputerStatus).AntivirusEnabled
(Get-MpComputerStatus).AMServiceEnabled

빠른 판단 기준
- 업데이트가 누락된 단말이 존재한다면: 그 그룹을 “긴급 패치/격리 우선”으로 분류
- DoS 징후(서비스 반복 중지)가 있다면: 운영 영향(보안 공백)을 고려해 임시 방어(네트워크 제한/정책 강화) 병행
- EoP 우려가 큰 단말(다중 사용자/원격 접속/개발 도구 설치 등)은 로그인/권한 정책을 즉시 강화하는 것이 현실적인 완화가 됩니다.

심화 분석

1) 타임라인 기반 분석

• 이상 징후 시작 시각(Defender 오류/중지)과 사용자 로그인/프로세스 생성 이벤트를 같은 축으로 정렬
• 업데이트 배포 시각과 장애 발생 시각이 겹치는지 분리(업데이트 부작용 vs 공격 가능성)

2) 권한 상승(EoP) 가설 검증 포인트

• 비관리자 사용자에서 시작된 프로세스 트리가 SYSTEM 권한으로 급격히 전환되는 흐름
• 로컬 관리자 그룹/권한 정책 변경, 신규 서비스 등록, 스케줄러 작업 생성 여부
• EDR/Defender for Endpoint가 있다면, 해당 단말의 경고 타임라인과 함께 확인

3) 서비스 거부(DoS) 가설 검증 포인트

• Defender 서비스 크래시/재시작 패턴이 동일 이벤트 ID로 반복되는지
• 서명 업데이트 실패/엔진 업데이트 실패가 특정 네트워크 구간(프록시/SSL 검사 등)에서 집중되는지
• 자원 고갈(디스크/메모리)과 동반되는지(공격이든 오작동이든 결과적으로 보호 공백이 생김)

# 최근 크래시/서비스 관련 이벤트(시스템 로그)
Get-WinEvent -LogName "System" -MaxEvents 200 |
  Where-Object { $_.Message -match "WinDefend|WdNisSvc|Sense|Windows Defender" } |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

실무 기준 팁
“악용됨”이라는 정보가 있을 때는, 단순 패치로 끝내지 말고 최소한
(1) 의심 단말의 이벤트 로그 백업, (2) 핵심 지표(서비스 중지/보호 비활성) 추적, (3) 관리자 권한 변경 감사를 같이 남겨야 합니다.

복구

1) 즉시 완화(패치 전까지)

• 업데이트 누락 단말은 네트워크 접근을 제한(내부 중요 시스템 접근/관리 포트 접근 차단 등)
• 로컬 관리자 권한 최소화(임시 승격 차단, 관리 계정 사용 통제)
• 원격 접속 경로(예: RDP/SSH/VDI) 접근 제어 강화 및 MFA 적용 범위 확대
• Defender 보호 기능이 비활성화된 단말은 “보호 공백” 상태로 분류해 우선 복구 대상 지정

2) 패치/플랫폼 업데이트 적용(근본 해결)

조직 표준 업데이트 경로를 통해 해당 취약점에 대한 수정이 포함된 보안 업데이트/플랫폼 업데이트를 적용합니다. 운영 환경에서는 “배포 성공”만 확인하지 말고, 적용 후 버전 값과 보호 상태가 정상인지까지 확인하는 것이 중요합니다.

# 업데이트 적용 후 버전/보호상태 재확인
Get-MpComputerStatus | Select-Object AMProductVersion, AMEngineVersion, AntivirusSignatureVersion, RealTimeProtectionEnabled, AMServiceEnabled

# 필요 시 재부팅 상태/적용 대기 여부도 함께 확인(조직 도구 기준)

3) 침해 의심 시 조치(보수적 루트)

• 의심 단말 격리(네트워크 분리) → 증거 보존(로그/타임라인) → 계정/자격 증명 회수(비밀번호 변경, 토큰 폐기)
• 관리자 계정/서비스 계정의 권한 변경 및 신규 계정 생성 여부 점검
• 필요 시 단말 재이미징/클린 설치까지 고려(권한 상승 성공 후에는 신뢰 회복이 어려울 수 있음)

중요
EoP가 실제로 성공했을 가능성이 있다면 “패치 적용”은 시작일 뿐이고,
관리자 권한 탈취/지속성(서비스·스케줄러·레지스트리·시작 프로그램) 점검이 함께 따라가야 합니다.

재발 방지

운영 정책

• 패치 SLA 설정: 기본 보안 제품 취약점은 일반 앱보다 더 짧은 기한으로 “긴급 배포” 트랙을 별도로 운영
• 버전 수집 자동화: 단말의 Defender 버전/보호 상태를 중앙에서 수집해 “누락/비활성”을 즉시 탐지
• 권한 관리 강화: 로컬 관리자 최소화, JIT(필요 시점에만 승격) 및 MFA 확대로 EoP 성공 시 피해를 줄임

탐지/대응

• 보호 공백 알림: 실시간 보호 OFF, 서비스 중지, 업데이트 실패 등은 즉시 티켓/알림으로 전환
• 중요 자산 분리: 관리 서버/배포 서버/도메인 컨트롤러는 일반 사용자 단말과 네트워크·권한 측면에서 분리
• 사후 점검 루틴: 대규모 패치 후 24~72시간 동안 Defender 오류/중지 이벤트를 집중 모니터링

관리자 입장에서
기본 보안 제품의 취약점은 “보안의 바닥”이 흔들리는 사건입니다.
따라서 이번처럼 악용 정황이 거론되면, 패치 적용 + 보호 공백 모니터링 + 권한 통제(최소권한)를 한 세트로 묶어 운영하는 것이 재발 방지의 핵심입니다.