Scanner — 스캐너(단서 생성기)
스캐너는 규칙·시그니처·휴리스틱으로 파일·프로세스·경로·레지스트리·서비스를 훑어 의심 후보를 뽑는다. SS에서 스캐너는 판정 축이 아니라 단서 생성기다.
왜 중요한가
시간이 제한된 세션에서 스캐너는 "어디서부터 볼 것인가"의 답이다. Prefetch·USN·BAM이 수만 건의 레코드를 쏟아낼 때, 스캐너 히트가 검색할 이름과 경로의 목록을 준다.
단, 히트 자체는 증거가 아니다. 모든 히트는 독립 축(PF·USN·BAM·서명·경로)에서 교차 확인이 필요하고, 스캐너가 말한 것을 스캐너 자체로 검증하지 않는다. 스캐너 화면이 비어 있어도 세션은 멈추지 않는다. 스캐너 무히트는 Clean의 근거가 아니고, 나머지 Ring3 축은 그대로 진행한다.
무엇인가
| 항목 | 설명 |
|---|---|
| 역할 | 규칙·시그니처·휴리스틱으로 의심 후보를 추출한다. 추출물은 재검증 전 단서(리드)다 |
| 대상 | 실행 파일, 실행 중 프로세스·모듈, 파일 경로, 레지스트리 키·값, 서비스·계획 작업 |
| 대표 도구 | Echo·Ocean 계열 커뮤니티 SS 스캐너, 스캐너 내장 아티팩트 뷰어, 승인된 정적 분석기 |
| 출력 | 경로 + 규칙·히트 이름 + 심각도(제공되는 경우) |
| 한계 | 시그니처 DB는 유지보수 상태에 따라 낡거나 FP를 낸다. 히트는 "봐야 할 곳"이지 판정이 아니다 |
SS에서 어떻게 쓰나
- T+5에 스캐너를 실행하고 결과 export 전체를
01-scanner/에 보존한다. 경로·규칙·심각도가 다 들어 있어야 한다. 나중에 FP로 기각된 히트도 삭제하지 않고 남긴다. - 각 히트에 대해 네 질문을 던진다. 파일이 지금 존재하는가 → 서명 상태는 무엇인가 → PF·BAM·USN 중 서로 다른 둘 이상에서 실행·파일 증거가 있는가 → 사용자 진술과 일치하는가.
- 히트 경로가 지금 실행 중인 프로세스나 로드된 모듈과 맞물리면 그 히트부터 Process / Module 카드로 검증한다. 라이브 상태는 세션이 끝나면 사라지고 디스크 축은 남는다.
- 나머지 히트는 뒤 축에서 하나씩 독립 검증한다. 검증이 안 된 히트는 "미검증 리드"로만 남는다.
- 히트가 없으면 결과를 "없음"으로 남기고 Ring3 축으로 계속 진행한다.
- 히트가 가리킨 파일·실행이 디스크 축(PF·BAM·USN)에서 모두 깨끗하게 나와도 조용히 Clean(조건부)로 닫지 않는다. 히트가 디스크에 없는 이유(메모리 전용 실행, 와이프, FP)를 적고, 에스컬레이션 게이트 진입 여부와 그 이유를 판정 파일에 남긴다.
우회 기법과 남는 흔적
공격자는 스캐너가 잡지 못하게 하거나, 스캐너가 볼 흔적을 지우는 방향으로 대응한다. 각 기법은 다른 축에 파생 흔적을 남긴다.
| 기법 | 공격자가 하는 일 | 남는 흔적 |
|---|---|---|
| 이름·확장자 위장 | 치트를 무해해 보이는 이름·확장자로 바꿔 이름 기반 규칙을 회피 | USN RENAME_OLD→NEW 체인, LNK의 실제 대상 경로, PF·BAM에 남은 실제 실행명 |
| 회피용 유니코드 명명 | 폴더·파일명에 빈 문자(U+3164 계열)나 유니코드 작은 대문자(ᴀʙᴄ…) 같은 비ASCII 코드포인트를 써 이름 정규식·육안 검색을 회피 | 회피용 명명 자체가 정상 베이스라인에 없는 강한 시그니처다. 검사자는 스캔·열거 출력에서 비ASCII·공백류 문자를 플래그하고, 이름이 빈 것처럼 보이는 항목을 문자 코드 수준에서 확인한다 |
| 정상 드라이버 이름 위장 | 치트 DLL을 GPU 드라이버 이름(atig6pxx.dll·aticfx64.dll 등)으로 바꿔 모듈 목록에서 정상처럼 보이게 한다 | 이름만 정상이면 이름 스캔은 통과하므로 검사자는 모듈의 실제 경로·서명·로드 위치를 확인한다. 정품은 System32에서만 로드되고 서명이 있으며, NVIDIA·Intel GPU 환경에서 ATI 이름의 DLL은 성립 자체가 안 된다 |
| 패킹·빌드 변형 | 매번 다른 바이너리로 배포해 해시·시그니처를 무력화 | 시그니처는 피해도 경로·서명·실행 패턴이 남는다. 서명 없음 + 사용자 쓰기 경로 + 실행 축 조합 |
| 파일리스·간접 실행 | 스크립트·인터프리터·로더 경유로 실행 파일 흔적을 최소화 | wscript·powershell·java 등 인터프리터의 PF·BAM 실행, 프로세스 트리의 비정상 부모-자식, 명령줄 기록. 명령행에 -w hidden·-nop·-ep 조합이 함께 있으면 그 자체로 강한 시그니처다 |
| 실행 후 자기 삭제 | 치트가 실행 직후 자신을 지워 스캐너 스캔 시점에 파일을 없앤다 | USN의 FILE_DELETE, 깨진 LNK, BAM의 Deleted 표기 실행 기록. 스캐너에 안 잡혀도 다른 축이 본다 |
| 검색 도구 제외 목록 | Everything 같은 검색 도구의 제외 폴더·제외 규칙에 치트 경로를 넣어 검색에 안 걸리게 한다 | Everything.ini의 제외 목록 설정과, 제외 전에 인덱싱된 everything.db 잔재. 검사자는 도구 설정 파일의 제외 목록을 읽고 db 잔여 인덱스와 대조한다 |
| 스캔 경로 ACL 거부 | 스캐너가 볼 경로에 deny ACL을 걸어 읽기를 차단한다 | 경로의 Deny 항목 자체가 흔적이고, 스캐너가 특정 경로만 접근 거부로 건너뛰는 패턴으로 드러난다. 검사자는 건너뛴 경로의 보안 탭을 연다 |
| 스캐너 실행 방해 | 스캐너를 차단·종료하거나 결과를 조작한다 | 스캐너가 안 돌아가는 것 자체가 R3-AF 리드다. 도구 실행 실패 로그와 재시도 시각을 기록한다 |
| 정상 SW 남용(LOLBins) | 정상 서명 바이너리·런처·스크립트 호스트로 치트를 구동 | 서명된 바이너리라도 비정상 경로·비정상 부모·제보 시간대와 정렬된 실행 시각이 남는다 |
정상 vs 이상
| 구분 | 정상 | 이상 |
|---|---|---|
| 히트 수 | 0건 또는 FP 패턴 | 제보 시간대와 정렬되는 히트 |
| 히트 내용 | 알려진 정상 SW(GPU·RGB, OBS, 런처, 오버레이) | 알 수 없는 경로·이름, 치트명 규칙 |
| 교차 결과 | 모든 히트가 독립 축에서 기각됨 | 히트가 PF·BAM·USN과 정렬됨 |
| 무히트 해석 | 스캔 완료 + 다른 축 진행 | 무히트를 곧바로 Clean 근거로 씀 |
오탐
Echo·Ocean 계열 스캐너가 반복적으로 히트시키는 정상 소프트웨어 패턴이 있다. 히트를 보기 전에 이 목록을 먼저 안다.
- GPU·RGB·쿨링 유틸리티(벤더 제어 소프트웨어)
- 캡처카드·OBS 계열 방송·녹화 도구
- Discord·NVIDIA·게임 오버레이
- 게임 런처·업데이터
- 개발 툴체인(디버거·컴파일러·HEX 편집기)
- 보안 도구·백신 구성 요소
- 클라우드 싱크 유틸리티
- 포터블·언팩된 정상 앱
교차 검증
| 교차 카드 | 확인 내용 |
|---|---|
| R3-PF·R3-BAM | 히트 경로의 실행 증거 |
| R3-USN | 히트 경로의 생성·삭제·이름변경 |
| R3-SIG | 히트 파일의 서명·경로 위생 |
| R3-REC | 히트 대상을 가리키는 LNK |
| R3-PROC | 히트 경로가 실행 중인 프로세스·로드된 모듈과 맞물리는지 |
스캐너 히트는 이 축들의 입력이다. 스캐너 히트만으로는 Suspicious도 과하다. 판정은 교차된 축으로 내리고, 스캐너는 "무엇을 검증했는가"의 목록으로만 증거 패키지에 남는다.
증거 캡처
- 스캔 결과 export 원본(도구 이름·버전·스캔 시각 포함)
- 히트별 경로·규칙명·심각도가 보이는 화면
- FP로 기각한 항목의 기각 근거 메모(어떤 축에서 왜 기각했는지)
- 무히트인 경우 스캔 완료 화면과 도구 버전
흔한 실수
- 스캐너 히트를 그대로 Suspicious·Confirmed로 둔다.
- 스캐너 무히트를 Clean 근거로 쓴다. 스캐너 통과는 "리드 없음"이지 "정상"이 아니다.
- FP 목록을 모르고 정상 소프트웨어를 리드로 취급한다.
- 기각한 히트의 근거를 남기지 않는다. 기각도 재현 가능한 결정이어야 한다.
- 스캐너 결과만으로 판정 파일을 쓴다.
Community. SS 현장에서는 스캐너 히트가 뜨면 먼저 정상 소프트웨어 베이스라인과 대조하는 것이 공통 관행이다.
유니코드 빈 문자 폴더·드라이버 이름 위장·검색 도구 제외 목록처럼 "스캐너를 피하는" 우회가 반복 보고되는데, 회피에 쓴 명명·설정 자체가 정상 베이스라인에 없는 패턴이라 되려 시그니처가 된다.
Sources
Next
- 첫 실행 축 → Prefetch
- 파일 변경 추적 → USN Journal