UEFI 부트킷 지속성 분석은(는) 무엇을 하나요?
사용 시기
- 손상된 시스템이 OS 재설치 또는 디스크 교체 후에도 C2 통신을 재개하는 경우
- Secure Boot가 변조되었거나 비활성화되었거나 예상치 못한 MOK(Machine Owner Key) 등록이 있는 경우
- 공급업체 기준선과 비교하여 펌웨어 무결성 검증이 실패하는 경우
- 메모리 포렌식에서 부팅 초기 단계에 로드되는 루트킷 컴포넌트가 발견되는 경우
- UEFI 임플란트를 배포하는 것으로 알려진 고급 지속 위협(APT) 캠페인을 조사하는 경우
- 엔터프라이즈 엔드포인트 강화를 위한 펌웨어 보안 태세 감사
사용하지 말아야 할 경우: UEFI가 없는 레거시 BIOS 시스템의 표준 MBR 기반 부트킷은 사용하지 마십시오. 대신 MBR/VBR 부트킷 분석을 사용하십시오.
사전 요구 사항
- SPI 플래시 덤프, UEFI 변수 검사 및 펌웨어 보안 모듈을 위한 chipsec 프레임워크
- 펌웨어 볼륨 파싱 및 DXE 드라이버 추출을 위한 UEFITool / UEFIExtract
- struct, hashlib, subprocess, os 모듈을 포함한 Python 3.8+
- 오프라인 분석을 위한 부팅 가능한 Linux 라이브 USB (손상된 OS 실행 방지)
- 부팅 단계 아티팩트 메모리 포렌식을 위한 Volatility 3
- 패턴 기반 탐지를 위한 UEFI 악성코드 룰셋이 포함된 YARA
- 무결성 비교를 위한 공급업체 펌웨어 기준선 접근 권한
워크플로우
1단계: SPI 플래시 펌웨어 덤프
오프라인 분석을 위해 SPI 플래시 칩에서 UEFI 펌웨어를 획득합니다:
# chipsec을 사용하여 SPI 플래시 내용 덤프
python chipsec_util.py spi dump firmware_dump.rom
# 대안으로 flashrom 사용
flashrom -p internal -r firmware_dump.rom
# 덤프 무결성 확인
sha256sum firmware_dump.rom
# SPI 플래시 디스크립터 정보 읽기
python chipsec_util.py spi info
# SPI 플래시 영역 접근 권한 확인
python chipsec_main.py -m common.spi_access
# BIOS 쓰기 보호 활성화 확인
python chipsec_main.py -m common.bios_wp
# SPI 플래시 컨트롤러 잠금 확인
python chipsec_main.py -m common.spi_lock
2단계: UEFI 변수 검사
승인되지 않은 수정 사항을 찾기 위해 UEFI 변수를 열거하고 분석합니다:
# 라이브 시스템의 모든 UEFI 변수 나열
python chipsec_util.py uefi var-list
# SPI 플래시 덤프에서 UEFI 변수 나열
python chipsec_util.py uefi var-list-spi firmware_dump.rom
# 특정 Secure Boot 변수 읽기
python chipsec_util.py uefi var-read SecureBoot 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read SetupMode 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read PK 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read KEK 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read db D719B2CB-3D3A-4596-A3BC-DAD00E67656F
# 분석을 위한 UEFI 키 데이터베이스 덤프
python chipsec_util.py uefi keys
# Secure Boot 구성 모듈 확인
python chipsec_main.py -m common.secureboot.variables
3단계: EFI 시스템 파티션(ESP) 분석
승인되지 않았거나 수정된 부트 컴포넌트를 찾기 위해 ESP를 검사합니다:
# ESP 마운트 (일반적으로 첫 번째 FAT32 파티션, 약 100-500MB)
mkdir /mnt/esp
mount /dev/sda1 /mnt/esp
# 타임스탬프와 함께 ESP의 모든 파일 나열
find /mnt/esp -type f -exec ls -la {} \;
# BlackLotus 지표 확인 - ESP:/system32/ 아래의 사용자 정의 디렉토리
ls -la /mnt/esp/system32/ 2>/dev/null
# Windows Boot Manager 서명 확인
sigcheck -a /mnt/esp/EFI/Microsoft/Boot/bootmgfw.efi
# 알려진 정상 값과 비교하기 위해 모든 EFI 바이너리 해싱
find /mnt/esp -name "*.efi" -exec sha256sum {} \;
# 표준 디렉토리 외부의 승인되지 않은 .efi 파일 확인
find /mnt/esp -name "*.efi" | grep -v "Microsoft\|Boot\|ubuntu\|grub"
# BlackLotus에 의해 설치된 grubx64.efi 찾기
find /mnt/esp -name "grubx64.efi" -exec sha256sum {} \;
# 이상 징후에 대한 MeasuredBoot 로그 검사 (Windows)
# 로그 위치: C:\Windows\Logs\MeasuredBoot\
4단계: 알려진 부트킷 시그니처로 펌웨어 스캔
알려진 UEFI 악성코드 패턴에 대해 펌웨어 덤프를 분석합니다:
# UEFIExtract로 모든 펌웨어 모듈 추출
UEFIExtract firmware_dump.rom all
# 공급업체 기준선에서 펌웨어 모듈 화이트리스트 생성
python chipsec_main.py -m tools.uefi.whitelist -a generate,baseline.json,firmware_vendor.rom
# 현재 펌웨어를 화이트리스트와 비교
python chipsec_main.py -m tools.uefi.whitelist -a check,baseline.json,firmware_dump.rom
# UEFI 특화 YARA 룰로 펌웨어 스캔
yara -r uefi_bootkits.yar firmware_dump.rom
# 추출된 모듈을 개별적으로 스캔
find firmware_dump.rom.dump -name "*.efi" -exec yara -r uefi_bootkits.yar {} \;
# 수정된 CORE_DXE 모듈 확인 (MoonBounce, CosmicStrand의 대상)
# GUID와 해시를 공급업체 기준선과 비교
5단계: Secure Boot 우회 메커니즘 탐지
알려진 Secure Boot 우회 기술을 확인합니다:
# Secure Boot 활성화 여부 확인
python chipsec_main.py -m common.secureboot.variables
# SMM(System Management Mode) 보호 확인
python chipsec_main.py -m common.smm
# SMM BIOS 쓰기 보호 확인
python chipsec_main.py -m common.bios_smi
# Windows에서 우회 지표에 대한 부트 구성 확인
bcdedit /enum firmware
bcdedit /v
# testsigning/nointegritychecks/debug 플래그 확인
bcdedit | findstr /i "testsigning nointegritychecks debug"
# HVCI(하이퍼바이저 강화 코드 무결성) 비활성화 여부 확인
# BlackLotus는 HKLM:\...\DeviceGuard\...\HypervisorEnforcedCodeIntegrity Enabled=0 설정
reg query "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled
# PowerShell을 통해 Secure Boot 상태 확인
# Confirm-SecureBootUEFI는 제대로 활성화된 경우 True 반환
6단계: 부트 체인 무결성 검증
펌웨어부터 커널까지 부트 체인의 모든 구성 요소를 확인합니다:
# 공급업체 해시와 비교하여 펌웨어 무결성 확인
sha256sum firmware_dump.rom
# 공급업체 게시 해시와 비교
# 부트로더 서명 확인
sigcheck -a C:\Windows\Boot\EFI\bootmgfw.efi
sigcheck -a C:\Windows\System32\winload.efi
sigcheck -a C:\Windows\System32\ntoskrnl.exe
# 서명되지 않았거나 잘못된 부트 드라이버 확인
sigcheck -u -e C:\Windows\System32\drivers\
# 예상치 못한 EFI_Boot_Services_Application 항목에 대한 Measured Boot 로그 분석
# BlackLotus 구성 요소는 EV_EFI_Boot_Services_Application으로 나타남
# 부팅 단계 아티팩트에 대한 메모리 포렌식
vol3 -f memory.dmp windows.modules
vol3 -f memory.dmp windows.driverscan
7단계: UEFI 부트킷 분석 결과 문서화
포괄적인 분석 보고서를 작성합니다:
보고서에는 다음이 포함되어야 합니다:
- 펌웨어 버전, 공급업체 및 플랫폼 식별
- SPI 플래시 보호 상태 (쓰기 방지, 잠금 비트, 접근 제어)
- Secure Boot 구성 및 감지된 모든 우회 지표
- UEFI 변수 이상 (승인되지 않은 키, 수정된 db/dbx, MOK 등록)
- 알려진 정상 기준선과의 해시 검증을 포함한 ESP 콘텐츠 인벤토리
- 공급업체 화이트리스트와의 펌웨어 모듈 비교 (추가, 수정, 제거)
- 신뢰 수준을 포함한 알려진 부트킷 패밀리 귀속
- 각 구성 요소에 대한 부트 체인 무결성 검증 결과
- 수정 단계 (재플래시, 키 교체, 하드웨어 교체)
- MITRE ATT&CK 매핑 (T1542.001 - 시스템 펌웨어, T1542.003 - 부트킷)
주요 개념
| 용어 | 정의 |
|---|---|
| UEFI 부트킷 | UEFI 펌웨어 또는 부트 프로세스에 지속되는 악성코드로, 운영 체제가 로드되기 전에 실행되며 OS 재설치에도 생존함 |
| SPI 플래시 | 마더보드의 직렬 주변 장치 인터페이스 플래시 메모리 칩으로 UEFI 펌웨어를 저장함; LoJax 및 MoonBounce와 같은 펌웨어 수준 부트킷은 SPI 플래시 내용을 수정함 |
| EFI 시스템 파티션(ESP) | EFI 부트로더 및 드라이버를 포함하는 FAT32 파티션; BlackLotus 및 ESPecter와 같은 부트킷은 지속성을 위해 ESP의 파일을 수정함 |
| Secure Boot | 부트 구성 요소의 디지털 서명을 확인하는 UEFI 보안 기능; 취약점(CVE-2022-21894) 또는 MOK 등록을 통해 우회될 수 있음 |
| DXE 드라이버 | UEFI 부팅 중 로드되는 드라이버 실행 환경 드라이버; 펌웨어 임플란트는 OS보다 먼저 실행되는 악성 DXE 드라이버를 주입함 |
| MOK(Machine Owner Key) | 사용자가 설치할 수 있는 Secure Boot 키; BlackLotus는 공격자 제어 MOK를 등록하여 악성 부트로더에 서명함 |
| chipsec | SPI 플래시, UEFI 변수, Secure Boot 및 하드웨어 보안 구성을 분석하기 위한 Intel 플랫폼 보안 평가 프레임워크 |
| HVCI | 하이퍼바이저 강화 코드 무결성, 부트킷이 서명되지 않은 커널 드라이버를 로드하기 위해 비활성화하는 Windows 보안 기능 |
도구 및 시스템
- chipsec: SPI 플래시 덤프, UEFI 변수 읽기, 펌웨어 쓰기 방지 확인, Secure Boot 구성 감사를 위한 Intel 프레임워크
- UEFITool: 펌웨어 볼륨 검사, DXE 드라이버 추출, 모듈 GUID 비교를 위한 오픈 소스 UEFI 펌웨어 이미지 파서
- sigcheck: EFI 바이너리 및 부트 체인 구성 요소의 디지털 서명을 확인하기 위한 Sysinternals 유틸리티
- flashrom: 지원되는 플랫폼에서 펌웨어 칩을 읽고 쓰기 위한 오픈 소스 SPI 플래시 프로그래머
- YARA: 펌웨어 덤프에서 알려진 부트킷 시그니처를 탐지하기 위해 UEFI 특화 룰셋과 함께 사용되는 패턴 매칭 엔진
일반 시나리오
시나리오: OS 재설치 후에도 생존하는 지속적인 침해 조사
컨텍스트: 엔터프라이즈 엔드포인트가 확인된 침해 후 재이미징되었지만, 동일한 C2 비콘닝이 몇 시간 내에 재개되었습니다. 엔드포인트에는 Secure Boot가 활성화된 UEFI 펌웨어와 TPM 2.0 칩이 있습니다. 보안 팀은 BlackLotus 또는 LoJax와 유사한 UEFI 수준 임플란트를 의심하고 있습니다.
접근 방식:
- 신뢰할 수 있는 Linux 라이브 USB에서 시스템을 부팅하여 손상된 OS 구성 요소 실행 방지
chipsec_util.py spi dump를 사용하여 오프라인 분석을 위해 SPI 플래시 펌웨어 덤프- ESP를 마운트하고 모든
.efi파일을 해싱하여 동일한 하드웨어의 알려진 정상 값과 비교 ESP:/system32/디렉토리(BlackLotus 지표) 및 승인되지 않은grubx64.efi확인- UEFIExtract로 펌웨어 모듈을 추출하고 GUID 인벤토리를 공급업체 기준선과 비교
- Secure Boot 변수 확인 -- 승인되지 않은 MOK 등록 또는 수정된 db/dbx 찾기
- chipsec 모듈을 사용하여 SPI 플래시 쓰기 방지 및 잠금 비트 확인
- UEFI 특화 YARA 룰로 펌웨어 덤프 및 추출된 모듈 스캔
- BlackLotus가 의심되는 경우 HVCI 비활성화 및 MeasuredBoot 로그의 이상 항목에 대한 레지스트리 확인
주의사항:
- 손상된 OS에서 분석 실행 (루트킷 구성 요소가 라이브 분석에서 숨겨짐)
- SPI 플래시 펌웨어를 검사하지 않고 ESP만 확인 (LoJax, MoonBounce와 같은 펌웨어 수준 임플란트 누락)
- Secure Boot가 모든 부트킷을 방지한다고 가정 (CVE-2022-21894 및 기타 우회 방법 존재)
- 수정 전 원본 펌웨어 덤프를 보존하지 않음 (중요한 포렌식 증거)
- 공급업체 이미지가 정품이고 수정되지 않았는지 확인하지 않고 펌웨어 재플래시
출력 형식
UEFI BOOTKIT PERSISTENCE ANALYSIS REPORT
============================================
시스템: Lenovo ThinkPad X1 Carbon Gen 11
펌웨어: N3HET82W (1.54) - Lenovo UEFI BIOS
플랫폼: Intel 13th Gen (Raptor Lake)
TPM: 2.0 (Infineon SLB 9672)
Secure Boot: ENABLED (BYPASSED via CVE-2022-21894)
분석 방법: Linux live USB + chipsec + UEFITool
SPI FLASH 보호 상태
BIOS 쓰기 방지: DISABLED [!]
SPI 플래시 잠금(FLOCKDN): SET [OK]
SMM BIOS 쓰기 방지: DISABLED [!]
SPI 보호 범위: Region 0 only (descriptor)
UEFI 변수 분석
SecureBoot: Enabled (value=1)
SetupMode: Disabled (value=0)
PK: Lenovo Ltd. (legitimate)
KEK: Microsoft + Lenovo (legitimate)
db: MODIFIED - contains unauthorized entry [!]
[!] Unknown certificate: CN=Secure Boot Signing, O=Unknown
[!] Not present in vendor baseline db
MOK: 1 unauthorized key enrolled [!]
[!] MOK enrolled: CN=shim, self-signed, not from distro vendor
ESP 파티션 분석
총 EFI 바이너리: 12
확인됨 (서명됨): 9
수정됨 (해시 불일치): 2 [!]
승인되지 않음: 1 [!]
[!] EFI/Microsoft/Boot/bootmgfw.efi - MODIFIED
예상 SHA-256: a3f2c8...
현재 SHA-256: 7b1e4d...
서명: Valid (signed with unauthorized MOK)
[!] EFI/Microsoft/Boot/grubx64.efi - UNAUTHORIZED
SHA-256: e9c1a7...
공급업체 기준선에 없음
BlackLotus stage-2 loader 서명과 일치
[!] ESP에 system32/ 디렉토리 존재 (BlackLotus 아티팩트)
디렉토리 비어 있음 (설치 후 파일 삭제됨)
펌웨어 모듈 분석
총 펌웨어 모듈: 312
공급업체 기준선 모듈: 312
추가된 모듈: 0
수정된 모듈: 0
SPI 플래시 무결성: CLEAN (펌웨어 수준 임플란트 미탐지)
부트킷 귀속
패밀리: BlackLotus
신뢰도: HIGH
지속성: ESP 기반 (SPI 플래시 아님)
우회 방법: CVE-2022-21894 (baton drop)
MITRE ATT&CK: T1542.003 (Bootkit), T1553.006 (Code Signing Policy Modification)
침해 지표
- ESP:/system32/ 디렉토리 (비어 있음, 사후 정리 아티팩트)
- ESP:/EFI/Microsoft/Boot/grubx64.efi (승인되지 않음, BlackLotus 로더)
- 수정된 bootmgfw.efi (공격자 MOK로 재서명됨)
- 레지스트리를 통해 HVCI 비활성화됨: DeviceGuard\...\Enabled = 0
- UEFI 변수 저장소의 승인되지 않은 MOK 등록
- MeasuredBoot 로그에 grubx64.efi에 대한 EV_EFI_Boot_Services_Application 표시됨
수정
1. bootmgfw.efi를 Windows 설치 미디어의 정품 복사본으로 교체
2. ESP에서 승인되지 않은 grubx64.efi 및 system32/ 디렉토리 삭제
3. Secure Boot 키를 공장 기본값으로 재설정 (MOK 지우기, PK/KEK/db 복원)
4. BIOS 쓰기 방지 활성화 및 SPI 플래시 잠금 비트 확인
5. 펌웨어를 최신 버전으로 업데이트 (CVE-2022-21894 패치)
6. HVCI 활성화 및 그룹 정책을 통해 확인
7. 신뢰할 수 있는 인증서만 Secure Boot db로 다시 가져오기
8. 비정상적인 부트 구성 요소 로드에 대한 MeasuredBoot 로그 모니터링