테마

3-Layer 모델 ​

치트는 탐지 압력이 오르면 비용이 더 큰 층으로 옮긴다. SS는 그 반대로, 흔적이 가장 많은 층부터 읽는다. 실제 절차는 표준 절차에 있다.

왜 층이 존재하나 ​

Windows는 CPU 권한 링(Ring3·Ring0)을 쓰고, 그 바깥에는 CPU를 거치지 않고 메모리를 읽는 하드웨어 경로(DMA)가 있다. 이 세 층이 치트·안티치트·SS가 부딪히는 전장이다.

아래로 갈수록 치트 쪽 비용이 오르고 호스트에 남는 흔적은 줄어든다. SS가 위층부터 아래로 내려가며 보는 이유다. 층마다 "증거 밀도"가 다르다.

층증거 밀도SS 접근성판정에 미치는 힘
Ring3높음 (OS가 직접 기록)높음 (읽기 전용 도구)단독으로 Confirmed까지 가능
Ring0중간 (로드 기록·서명·CI)중간 (도구·권한 필요)Ring3 교차 없이 Confirmed 금지
DMA/L0낮음 (장치 트리·간접 단서)낮음 (물리 확인 필요)Insufficient가 기본

Layer 1 · Ring3 (유저모드) ​

흔적이 가장 풍부하다. Prefetch, USN, BAM, 이벤트 로그, 모듈 목록, 서명 상태가 모두 Ring3 활동의 부산물이다. 검사자가 쓸 수 있는 도구도 이 층에 가장 많다.

보는 것 ​

아티팩트답하는 질문카드
Prefetch (.pf)무엇이 언제 실행됐나R3-PF
USN Journal파일이 언제 생성·삭제·개명됐나R3-USN
BAM / UserAssist / ShimCache / Amcache실행 흔적 교차R3-BAM · R3-REC
모듈 목록 / 프로세스 트리지금 무엇이 메모리에 있나R3-PROC
서명·경로 위생정상 위치에 정상 서명인가R3-SIG
안티포렌식 패턴흔적을 지우려 했나R3-AF
매크로 흔적입력 시퀀스를 심었나R3-MAC

여기서 닫는 조건 ​

라벨조건
Confirmed실행 흔적 + 경로·서명 이상 + 타임라인 일치(루브릭 충족)
Suspicious단서 일부 + 안티포렌식 패턴
Clean(조건부)Ring3 전 항목 정상, 안티포렌식 없음, 오탐이 설명됨, Ring0·DMA 에스컬레이션 미해당 사유 기록

이 층에서 못 보는 것 ​

Ring3가 보는 것은 호스트에 남은 흔적뿐이다. 파일을 디스크에 두지 않는 순수 파일리스, 커널에서만 일어난 은닉, 다른 기계에서 돌아가는 로직은 이 층에서 보이지 않는다. 그것이 Insufficient 라벨과 에스컬레이션 진입 조건이 존재하는 이유다.

Layer 2 · Ring0 (커널) ​

진입 비용이 높다. 드라이버 로드에는 서명이 필요하고 로그가 남는다. 흔한 우회는 BYOVD로, 정상 서명된 취약 드라이버를 가져와 커널 접근을 얻는 방식이다. 이 경로도 흔적을 남긴다.

왜 공격자가 커널로 가나 ​

안티치트가 커널에서 동작하기 때문이다. 프로세스 보호 콜백, 핸들 제한, 메모리 스캔을 같은 권한에서 뚫으려면 공격자도 커널 코드가 필요하다. 자체 드라이버를 서명받는 것은 어렵기 때문에, 이미 서명된 취약 드라이버(MSI Afterburner의 RTCore64, GIGABYTE의 gdrv, Dell의 dbutil 계열 같은 반복 등장 사례)를 가져다 쓰는 BYOVD가 반복적으로 관찰된다.

보는 것 ​

항목위치 · 도구
로드된 드라이버 목록Autoruns Drivers 탭, driverquery /v
드라이버 서명 상태Sigcheck, Autoruns
취약 드라이버 해시 대조LOLDrivers 조회
숨김 탐지도구 A와 도구 B 결과 불일치
HVCI · 메모리 무결성msinfo32, 코어 격리, Get-CimInstance
코드 무결성 이벤트CodeIntegrity 로그 3076·3077·3001·3033·3111
드라이버 서비스 설치이벤트 7045 + 타임라인

남는 흔적 ​

BYOVD라도 호스트에 흔적이 남는다.

  • 드라이버 파일 자체. .sys가 Temp·AppData·Downloads 같은 사용자 경로에 있거나, Prefetch·USN에 드라이버 파일의 생성·삭제 기록이 남는다.
  • 서비스 설치 이벤트. 드라이버는 보통 서비스로 로드되므로 System 로그 7045(새 서비스 설치)에 시각과 경로가 남는다. 설치 후 바로 삭제되는 패턴(서비스 깜빡임)이 BYOVD의 전형적 형태다.
  • Code Integrity 로그. 서명이 안 맞거나 정책을 못 넘는 드라이버가 로드를 시도하면 CodeIntegrity 채널에 3001·3033·3076·3077·3111 같은 이벤트가 남는다.
  • HVCI·메모리 무결성 상태. 켜져 있어야 할 보호가 꺼져 있으면 환경 가중치다.

한계 ​

서명된 정상 드라이버가 많다. RGB, 모니터링, 가상화 드라이버는 정상이므로 오탐 베이스라인을 먼저 본다. 숨김 탐지도 불완전하다. 도구 불일치가 없다는 것이 커널 개입이 없다는 증명은 아니다.

Ring0 단독으로는 Confirmed를 내리지 않는다. 반드시 Ring3 맥락이나 서비스·타임라인과 교차한다. 카탈로그 해시가 일치해도 Ring3 실행 흔적(로더·매퍼의 Prefetch·USN)과 맞물려야 한다.

절차는 Ring0 안전 깊이에 있다.

Layer 3 · DMA / L0 (외부 장치) ​

PCIe 슬롯의 별도 기기가 버스 마스터 DMA로 메모리를 직접 읽는다. 호스트 에이전트와 물리적으로 분리되므로 로컬 프로세스·파일·드라이버가 없을 수 있고, 그러면 Ring3·Ring0 흔적도 거의 없다.

영상 캡처와 외부 입력 장치를 묶은 구성(AI 픽셀봇)도 이 층의 호스트 밖 경로다. 캡처카드가 게임 PC의 HDMI 출력을 받고, 두 번째 PC의 영상 인식 모델이 화면 픽셀에서 적을 찾아 USB 입력 장치(Arduino·Makcu형)로 마우스를 움직인다. 게임 메모리를 읽지 않고 게임 PC 안에 설치하는 하드웨어도 없어서, 게임 PC에서 볼 수 있는 것은 USB HID 장치의 연결 이력(장치 목록, 장치별 설치·연결 시각, setupapi 기록) 정도다. 판정은 아래 "판정과 층" 표의 DMA/L0 줄을 따른다. 단독 Confirmed는 없고 Insufficient에서 출발한다. 확인 절차는 DMA / L0 안전 깊이의 HID 장치 확인에 있다.

왜 이 층이 마지막인가 ​

호스트에 남는 흔적이 극단적으로 적기 때문이다. "DMA라서 로컬에 없다"는 부분적으로 사실이다. 그러나 흔적이 적다는 사실 자체는 어느 쪽 근거도 아니다. 안 나왔다고 없었다는 뜻이 아니고, 안 나왔다는 이유로 있었다고 볼 수도 없다. 그래서 기본 출발점이 Insufficient다.

보는 것 ​

  • 알 수 없는 PCIe 장치. 장치 관리자와 pnputil /enum-devices(Win10 1903 이상)로 본다. 장치 관리자에서 "숨겨진 장치 표시"를 켜고 알 수 없는 시스템 장치·오류 상태 장치(Code 10 같은 드라이버 실패)를 찾는다. DMA 카드는 종종 잘못된 장치 ID나 제네릭 이름으로 보인다.
  • 하드웨어 ID(HWID). 장치 속성의 Hardware Ids가 불완전하거나 위장된 패턴이면 단서다. 서명 없는 장치도 스푸핑 후보다. 다만 HWID 숫자 불일치만으로는 확정이 아니다.
  • 원격·창 복제 프로세스. 퓨저(fuser, 두 PC의 영상 출력을 한 화면으로 합성하는 장치, 용어집)가 없는 2PC 구성은 원격 데스크톱·화면 복제 소프트웨어로 화면을 얹는다. Parsec·AnyDesk·TeamViewer·창 복제 도구의 실행 흔적과 캡처카드 흔적을 Ring3에서 본다.
  • PnP 설치 이력. 장치가 언제 처음 꽂혔는지는 setupapi 로그와 레지스트리 설치 흔적에 남는다. 제보 시각 직전의 장치 추가는 교차 재료다.
  • IOMMU · Kernel DMA Protection. msinfo32에서 켜짐 상태를 본다.
  • 환경 설정. Secure Boot·TPM 상태를 환경 노트에 기록한다.

한계 ​

알 수 없는 PCIe 장치 하나만으로는 증거가 되지 않는다. 장치 이상에 원격 접속·창 복제 패턴이 더해지고 제보·환경과 맞물릴 때 판정 재료가 된다. 정상 캡처카드나 원격지원 소프트웨어의 오탐이 흔하므로 OBS·TeamViewer·AnyDesk는 단독으로 신호가 아니다.

절차는 DMA / L0 안전 깊이에 있다.

층 사이의 관계 ​

흐름은 단방향이 아니다. Ring0를 보다가 발견물이 Ring3로 되돌아오기도 한다. 층은 격리된 구역이 아니라 검사 순서다.

  • Ring0에서 서명 없는 드라이버 발견 → Ring3 Prefetch에서 로더 실행 흔적을 다시 확인한다.
  • DMA 의심 → Ring3에서 창 복제 프로세스가 있는지 다시 확인한다.
  • Ring3에서 클리너 잔존물 발견 → 지워진 것이 커널 경로였는지 Ring0를 연다.

층을 이동하는 조건 ​

상황이동
Ring3 전체 정상, 제보 지속, 안티포렌식 없음Ring0 진입 검토
Ring3에서 .sys 관련 흔적 발견Ring0 즉시 진입
Ring3 공백 + 행동 제보 + "2PC"·숨김 장치·원격 프로세스·외부 입력 장치 정황DMA 진입 검토(Ring0 검사와 별개로 판단)
Ring3에서 Insufficient 결론증거 패키지 현황 기록 후 진행

판단 흐름 전체는 Ring3로 부족한 순간에 있다.

판정과 층 ​

층Confirmed 가능비고
Ring3가능루브릭 기준 충족 시
Ring0Ring3 교차 필수단독 Confirmed 금지
DMA/L0단독 불가Insufficient 기본. 환경·제보는 가중치. 영상 캡처·외부 입력 장치 경로도 같다

층이 깊어질수록 판정 임계가 높아진다. DMA/L0 소견만으로는 Confirmed를 내리지 않는다. 환경 상태와 제보는 축으로 세지 않고, Confirmed는 호스트에 남은 독립 아티팩트 축 두 개 이상이 제보 시간대에서 수렴할 때만 가능하다.

상황라벨 예시
Ring3에서 실행·삭제 교차, 제보 시간대 일치Confirmed 가능
Ring0 해시 일치 + Ring3 로더 흔적Confirmed 가능 (교차 충족)
Ring0 해시 일치만, Ring3 공백Suspicious
DMA 의심 + 숨김 장치 + 제보 정합Suspicious 또는 Insufficient
외부 입력 장치 이력 + 행동 제보, 게임 PC의 실행 흔적 없음Insufficient (최대 Suspicious)

흔한 실수 ​

  • 진입 조건 없이 아래층 체크를 돌린다. 오탐만 늘어난다.
  • 아래층 발견물 하나로 Confirmed를 발급한다.
  • "DMA 가능성이 있다"를 Clean 거부의 근거로 무한 확대한다. 기준은 진입 조건의 문서화다.
  • Ring3 공백을 아래층 우회의 증거로 쓴다. 공백은 공백이지 우회 증명이 아니다.

Sources ​

Next ​