Nidhogg v2.0는 공개 GitHub 저장소에서 배포된 Windows 커널 루트킷 프로젝트의 최신 릴리스다. 2026-02-22 10:00 KST 기준 공개 자료를 보면, 이번 이슈는 새로운 취약점(CVE) 공지가 아니라 루트킷 프레임워크의 안정성·호환성·운영성 개선 업데이트에 가깝다. 다만 커널 공간에서 프로세스/스레드/드라이버/레지스트리 가시성과 보안 기능(예: ETW 관련 기능)에 영향을 줄 수 있는 기능이 다수 포함되어 있어, SOC/IR팀은 즉시 탐지 기준과 헌팅 쿼리를 보강해야 한다.
Nidhogg v2.0 TL;DR
- 확인된 사실: v2.0 릴리스는 대규모 리팩터링, 기능별 테스트케이스 추가, 신규 TUI, 22H2~25H2 지원 확대, NOF(Nidhogg Object File) 도입을 공지했다.
- 확인된 사실: 프로젝트 README는 x64 Windows 10/11 지원, Windows 11 25H2까지 기능 테스트 완료를 명시한다.
- 확인된 사실: 공식 저장소에 YARA 룰이 제공되며
\Device\Nidhogg,\??\Nidhogg,Nidhogg.pdb같은 문자열 IOC가 포함돼 있다. - 중요 포인트: 이것은 ‘취약점 패치 뉴스’가 아니라 ‘공개 루트킷의 실전 운용성 강화’ 이슈다. 공격 표면 자체보다 공격자 도구 생태계 관점에서 우선순위를 올려야 한다.
- 미확인/제한: 제공된 소스만으로는 특정 APT 캠페인 연계, 실제 대규모 악용 사례, 샘플 해시 목록은 확인되지 않는다.
배경: 이번 이슈는 무엇인가
Reddit의 blueteamsec 게시글은 Nidhogg v2.0 릴리스를 공유하며 원문 링크로 GitHub Release를 연결한다. 릴리스 본문과 Discussion #74를 교차 확인하면, 작성자는 코드베이스를 대폭 리팩터링했고 안정성·가독성·유지보수성을 핵심 목표로 삼았다고 밝혔다. 즉 ‘신기능 폭증’보다 ‘기존 기능의 신뢰도와 호환성 강화’가 이번 버전의 중심이다.
동시에 README 기준 기능 범위는 매우 넓다. 프로세스/스레드 은닉·보호, 파일·레지스트리 보호, ETW 관련 조작, 커널 콜백 조회·제거·복원, 드라이버/모듈 은닉, 포트 은닉, 자격증명 덤프 등 방어자가 민감하게 보는 커널 수준 행위가 다수 열거되어 있다. 저장소 API 기준으로 작성 시점 Star 2,259/Fork 319인 공개 프로젝트라는 점도 운영팀이 무시하기 어려운 배경이다.
Nidhogg v2.0가 왜 중요한가
1) 호환성 확대는 탐지 난이도 분산으로 이어진다
릴리스 노트는 22H2부터 최신 25H2까지 지원 확대를 명시한다. 이는 단일 버전에서만 동작하는 실험 코드가 아니라, 여러 Windows 빌드에서 동작을 맞추려는 의도가 반영됐다는 의미다. 보안운영팀은 ‘특정 빌드 예외’에 기대기보다, 드라이버 로드·서비스 생성·은닉 징후 같은 공통 행위 기반 탐지를 우선해야 한다.
2) NOF 도입은 커널 측 확장성 이슈다
README에 따르면 v2.0에서 NOF(Nidhogg Object File)가 도입됐고 커널 모드 COFF 실행을 지향한다. 또한 해당 기능은 VBS 환경에서 HVCI/kCFG 위반으로 호환되지 않는다고 명시돼 있다. 방어 관점에서는 VBS/HVCI 정책 상태를 자산별로 점검하고, 비활성 자산을 우선 위험군으로 분류하는 근거가 된다.
3) 리플렉티브 로딩 관련 제약은 오히려 탐지 포인트가 된다
README는 kdmapper 기반 리플렉티브 로딩 시 PatchGuard 트리거 문제 때문에 일부 콜백 기반 기능이 기본 비활성화된다고 설명한다. 이는 공격자가 목표 기능 확보를 위해 로딩 방식·설정을 조정해야 할 가능성을 뜻하며, 반대로 블루팀에는 비정상 드라이버 적재·콜백 상태 변화·센서 가시성 저하를 함께 보는 탐지 전략이 유효함을 시사한다.
영향 범위와 리스크 평가
영향받는 시스템/버전(공개 문서 기준)
- x64 Windows 10, Windows 11 지원 명시
- 기능 테스트 범위: Windows 11 25H2까지 명시
- v2.0 릴리스 노트: 22H2~25H2 지원 확대 언급
공격이 가능해지는 조건(개념 수준)
- 커널 드라이버 로드가 가능한 권한/환경이 필요하다. README의 테스트 절차 자체가 관리자 권한 CMD,
bcdedit,sc create ... type= kernel를 전제로 한다. - 즉 초기 침투 자체보다, 침투 이후 권한 상승/지속성/탐지 회피 단계에서 위험도가 커지는 유형으로 보는 것이 합리적이다.
- 제공 소스에는 ‘어떤 침투 벡터로 유포 중인지’에 대한 확정 정보가 없다. 따라서 특정 캠페인 단정은 금물이다.
탐지 포인트(로그/IOC)
- 서비스/드라이버 행위:
sc create nidhogg type= kernel ...,sc start nidhogg같은 패턴과Nidhogg.sys파일 생성·실행 시도. - 부팅/디버깅 설정 변경:
bcdedit /set testsigning on,bcdedit /debug on실행 흔적. - 문자열 IOC(공식 YARA):
\Device\Nidhogg,\??\Nidhogg,Nidhogg.pdb,\Driver\Nsiproxy,31122.6172,31105.6171. - 행위 IOC: 프로세스/스레드/드라이버/포트/레지스트리 은닉·보호, ETW provider 비활성화/재활성화 시도, 커널 콜백 제거/복원 같은 고위험 행위.
- 로그 소스 예시: Windows 서비스 설치 이벤트, 프로세스 생성(명령행 포함), Sysmon DriverLoad(구성 시) 등을 우선 상관분석.
대응 체크리스트(SOC/IR/보안운영팀)
우선순위 P0 (즉시~4시간)
- EDR/SIEM에 Nidhogg 관련 키워드·문자열 IOC 룰을 즉시 배포한다.
- 전사 엔드포인트에서
nidhogg서비스명,Nidhogg.sys,NidhoggClient.exe흔적을 긴급 헌팅한다. bcdedit기반 테스트서명/디버그 모드 변경 이력을 조회하고, 변경 자산을 고위험군으로 격리 검토한다.- 의심 호스트는 네트워크 격리 후 메모리/드라이버/서비스 아티팩트를 우선 보전한다(포렌식 선행).
우선순위 P1 (24시간)
- 드라이버 로드 정책(WDAC, 서명 정책, 허용 드라이버 목록)과 예외를 재검토한다.
- VBS/HVCI 활성 상태를 자산 인벤토리와 대조해 미적용 구간을 축소한다.
- ETW/EDR 텔레메트리 공백(갑작스러운 이벤트 감소, 센서 비정상)을 품질 지표로 모니터링한다.
- 탐지 룰은 단일 파일 해시보다 행위 조합(서비스 생성+드라이버 로드+보호/은닉 명령) 중심으로 개선한다.
우선순위 P2 (7일)
- 공개 YARA(
Nidhogg.yar)를 내부 스캐닝 파이프라인에 통합하고 주기 스캔을 자동화한다. - 커널 위협 대응 런북에 ‘드라이버 기반 은닉 징후 점검 절차’를 명문화한다.
- 보안관제·IR·엔드포인트 운영팀 합동으로 탐지 시나리오(방어 목적) 테이블탑을 수행한다.
FAQ
Q1. Nidhogg v2.0는 새로운 CVE 취약점 공지인가?
아니다. 제공된 소스 기준으로는 특정 CVE 공개/패치 공지가 아니라, 공개 루트킷 프로젝트의 버전 업데이트다. 따라서 취약점 패치 관리만으로 끝내면 안 되고, 커널 행위 탐지 관점 대응이 필요하다.
Q2. 이 릴리스가 곧바로 ‘침해 발생’을 의미하나?
아니다. 릴리스 존재 자체는 침해 증거가 아니다. 다만 조직 내부에서 관련 서비스/드라이버/명령행 IOC가 관측되면 즉시 고위험 인시던트로 승격해야 한다.
Q3. VBS/HVCI를 켜면 완전히 안전한가?
README는 NOF가 VBS(HVCI/kCFG)와 비호환이라고 밝히지만, 이를 ‘전체 위협 제거’로 해석하면 안 된다. VBS/HVCI는 중요한 완화책이지만, 드라이버 정책·권한 통제·탐지 운영과 함께 가야 한다.
Q4. 지금 당장 가장 먼저 할 일은?
첫째, IOC/행위 룰 배포. 둘째, 서비스·드라이버·bcdedit 변경 이력 긴급 헌팅. 셋째, 의심 자산 격리와 증적 보전이다. 이 세 가지를 먼저 끝내야 이후 분석 품질이 올라간다.