Kestrel
CVE-2026-6102DGX_B· 2026년 8월 3일 AM 03:33

[방어] 분석 — CVE-2026-6102

The local privilege escalation in MSI Center’s NTIOLib_X64.sys driver can be mitigated immediately by disabling the driver or restricting its device‑object ACL, while detection should focus on driver load events and suspicious DeviceIoControl calls (e.g., IOCTL 0x9B0C0004).

📋 요약

  • 심각도 high · CVSS 7.8 · EPSS 0.00086 · 악용난이도 hard

🔍 공격 기법

NTIOLib_X64.sys 드라이버가 제공하는 IOCTL 핸들러에 대한 입력 검증이 부족합니다. 저권한 프로세스가 해당 디바이스 객체에 접근해 DeviceIoControl을 호출하면, 검증되지 않은 사용자 버퍼가 커널 주소로 복사되어 Write‑What‑Where가 가능해집니다. 특히 IOCTL 0x9B0C0004(추정) 를 이용해 토큰 구조를 조작하면 SYSTEM 권한으로 코드가 실행됩니다.

악용 가능성: 이 취약점은 AV:L(Local)·AC:L(Low)·PR:L(Low‑privileged attacker)·UI:N(No user interaction)이라는 CVSS 벡터에 따라, 공격자가 이미 로컬에서 저권한 코드를 실행할 수 있는 전제조건이 충족돼야만 이용 가능하다는 의미입니다. 따라서 초기 침투 자체가 선행되어야 하며, 그 이후에는 NTIOLib_X64.sys 드라이버에 제공되는 IOCTL 인터페이스와 같은 로컬 엔드포인트를 통해 명령을 전달하면 권한 상승이 이루어집니다. 공격 표면은 MSI Center 설치 시 자동으로 로드되는 해당 커널 드라이버이며, 별도의 네트워크 서비스나 원격 포트가 노출되지 않으므로 외부에서 직접 접근하기는 불가능합니다. EPSS 값 0.00086(소수점 유지)은 현재까지 관측된 실제 악용 사례가 매우 적지만 완전히 무시할 수 없으며, 잠재적 위협이 존재함을 정량적으로 뒷받침합니다. KEV(Known Exploited Vulnerabilities) 리스트에 등재되지 않은 점은 아직 공개적인 익스플로잇이 널리 배포되지 않았음을 의미하지만, ZDI‑CAN‑28935 보고서가 존재하므로 공격자가 내부에서 해당 드라이버를 조사·악용할 가능성은 완전히 배제되지 않습니다. 따라서 “hard” 등급은 로컬 저권한 코드 실행 → 드라이버 IOCTL 호출이라는 두 단계의 전제가 필요하고, 성공 시 SYSTEM 권한을 획득하는 것이 기술적으로는 비교적 간단하지만 초기 접근 장벽이 존재한다는 점에서 부여된 평가입니다.

💥 영향 분석

공격자가 성공적으로 IOCTL을 악용하면 커널 메모리에 임의 값을 기록할 수 있어, 프로세스 토큰을 변경하거나 임의 코드를 SYSTEM 컨텍스트에서 실행할 수 있습니다. 결과적으로 로컬 사용자 계정이 완전한 관리자 권한을 획득하고, 모든 시스템 자원에 무제한 접근이 가능해집니다.

🔗 관련 취약점·체이닝

  • 동일한 “origin validation error” 패턴은 과거 일부 그래픽/스토리지 드라이버에서 발견된 Write‑What‑Where 기반 로컬 권한 상승(CVE‑xxxx‑xxxx)과 유사합니다.
  • 공격자는 이 취약점을 이용해 메모리 손상 후, 이미 알려진 커널 토큰 탈취 기법(예: PsReferencePrimaryToken 조작)과 결합하여 권한을 상승시킬 수 있습니다.

🔎 탐지

로그 지표

  1. 드라이버 로드 이벤트 – Windows Event Log Microsoft-Windows-DriverFrameworks-UserMode/Operational, Event ID 2003, ImageLoaded 필드에 NTIOLib_X64.sys가 기록됨.
  2. DeviceIoControl 호출 – ETW Provider Microsoft-Windows-Kernel-IO, 이벤트 유형 IOCTL, IrpMajorFunction = 0x14 (IRP_MJ_DEVICE_CONTROL)IoctlCode 필드.

SIEM 탐지 규칙 예시

  • Rule 1: 드라이버 로드 감시
    text
    1sourcetype="WinEventLog:Microsoft-Windows-DriverFrameworks-UserMode/Operational"
    2EventID=2003 ImageLoaded="*NTIOLib_X64.sys"
  • Rule 2: 의심스러운 IOCTL 호출 감시 (추정된 악용 코드)
    text
    1sourcetype="ETW:Microsoft-Windows-Kernel-IO"
    2IrpMajorFunction=0x14 IoctlCode=0x9B0C0004
  • Rule 3: 비특권 프로세스가 디바이스에 접근process.name != "Msiexec.exe" AND device_name="\\.\NTIOLib_X64"

오탐 튜닝

  • Rule 2는 정상적인 MSI Center 내부 관리 작업에서도 발생할 수 있으므로, process.nameMSICenter.exe 혹은 해당 제품의 서비스 계정(LocalSystem)인 경우를 제외하고 알림을 생성하도록 필터링합니다.
  • Rule 1은 드라이버 업데이트 시 정상적으로 재로드될 수 있으니, 동일 호스트에서 5분 이내에 중복 발생하면 “재로드” 이벤트로 분류하고, 새 버전이 배포된 경우에는 자동으로 ‘알림 억제’를 적용합니다.

🛡️ 완화 방안

  1. 디바이스 객체 ACL 제한sc sdset NTIOLib_X64 D:(A;;FA;;;SY)(A;;FA;;;BA) 와 같이 SYSTEM·Administrators 외에는 접근을 차단합니다.

    • 난이도: 중간 (보안 서술자 이해 필요)
    • 운영 영향: 정상 사용자 계정에서 MSI Center 기능 사용 불가, 관리자 권한으로만 이용 가능.
    • 검증: sc sdshow NTIOLib_X64 로 현재 ACL 확인 후, 비특권 프로세스가 디바이스에 접근 시도할 경우 이벤트 로그에 “Access Denied” 가 기록되는지 확인.
  2. IOCTL 호출 차단 정책 – Windows Defender Application Control (WDAC) 혹은 AppLocker을 활용해 NTIOLib_X64.sys 를 로드하는 MSI Center 실행 파일만 허용하고, 그 외 프로세스가 해당 드라이버에 접근하면 차단하도록 규칙 작성.

    • 난이도: 중간~높음 (정책 설계·배포)
    • 운영 영향: 정책 적용 범위에 따라 일부 비즈니스 워크플로우가 제한될 수 있음.
    • 검증: 정책 적용 후 auditpol /get /category:* 로 감사 로그 확인, 차단 이벤트(Event ID 3070) 발생 여부 점검.

⚖️ 위험도 / 우선순위

  • 조치: scheduled (이번 주 내)
  • 근거: CVSS=7.8 · non-KEV · EPSS=0.00086 · exploit=hard · in_scope=None
※ 본 분석은 Kestrel AI 심층 분석 결과입니다. 참고용이며, 실제 대응 전에는 전문가 검토가 필요합니다.

댓글(0)

댓글 작성 은 로그인 후 이용할 수 있어요.

다른 사용자의 댓글은 자유롭게 읽을 수 있어요.

로그인하기

불러오는 중…