Skip to content

Latest commit

 

History

History
183 lines (102 loc) · 7.09 KB

File metadata and controls

183 lines (102 loc) · 7.09 KB

현대 EDR 환경을 고려한 Custom Stage-0 Loader 아키텍처 설계 (V6)

1. 서론: 변화하는 엔드포인트 방어 환경

현대의 엔드포인트 탐지 및 대응(EDR) 솔루션은 단순한 파일 시그니처 기반 탐지를 넘어, 프로세스 메모리 상태, 실행 흐름, 호출 스택, 모듈 로딩 이력, API 호출 패턴 등 다양한 런타임 정보를 종합적으로 분석한다.

이와 같은 환경에서 로더(Loader)의 역할은 단순한 코드 실행을 넘어, 초기 실행 단계에서 발생하는 관측 가능 정보(Observable Artifacts)를 어떻게 관리할 것인가의 문제로 확장되고 있다.

V6 Loader는 이러한 관점에서 설계된 연구 프로젝트로, 초기 실행 단계에서 노출될 수 있는 탐지 신호를 줄이고 실행 흐름의 일관성을 유지하는 것을 주요 목표로 삼았다.

본 문서는 로더의 실행 라이프사이클을 기준으로 주요 설계 요소를 설명하고, 기존 방식과 비교하여 어떠한 엔지니어링적 판단이 이루어졌는지 정리한다.


2. Phase 1: 정적 분석 대응 및 API 해석 구조

설계 목표

정적 분석 단계에서 노출되는 실행 의도와 기능적 단서를 최소화한다.

설계 방식

V6 Loader는 운영체제가 제공하는 일반적인 API 해석 방식에 대한 의존도를 줄이고, 런타임 시점에 필요한 정보를 해석하는 구조를 연구하였다.

또한 문자열 노출을 최소화하여 정적 분석 시 수집 가능한 정보를 줄이는 방향으로 설계를 진행하였다.

기존 방식과의 비교

주로 다음과 같은 일반적인 API 기반 구조가 사용된다.

  • LoadLibrary
  • LoadLibraryEx
  • GetProcAddress

설계 배경

표준 API 기반 해석 방식은 구현이 단순하고 유지보수가 용이하다는 장점이 있다.

반면, 임포트 정보나 특정 문자열 정보는 정적 분석 과정에서 프로그램의 동작을 추론하는 단서로 활용될 수 있다.

따라서 본 프로젝트는 실행 전 단계에서 노출되는 정보를 최소화하는 방향에 초점을 두었다.


3. Phase 2: 런타임 모니터링 환경 고려

설계 목표

사용자 영역(User Mode)에서 수집되는 실행 정보를 최소화한다.

설계 방식

시스템 수준 동작을 수행하는 과정에서 특정 인터페이스에 대한 의존도를 줄이고, 실행 문맥(Context) 자체를 고려한 구조를 연구하였다.

기존 방식과의 비교

일반적으로 다음과 같은 접근 방식이 활용된다.

  • 운영체제가 제공하는 표준 API 호출 경로
  • 직접적인 시스템 서비스 호출 방식

설계 배경

현대 EDR은 단순히 어떤 API가 호출되었는가뿐만 아니라, 해당 호출이 어떤 실행 흐름과 메모리 문맥에서 발생했는지도 함께 분석한다.

따라서 호출 자체보다 호출이 발생하는 실행 환경과 흐름을 함께 고려하는 것이 중요하다고 판단하였다.


4. Phase 3: 초기 실행 단계와 프로세스 텔레메트리

설계 목표

초기 실행 단계에서 발생하는 불필요한 프로세스 및 스레드 이벤트를 줄인다.

설계 방식

초기화 단계에서 수행되는 동작을 최소화하고, 프로세스가 원래 수행하던 실행 흐름을 최대한 활용하는 구조를 채택하였다.

기존 방식과의 비교

초기 실행 단계에서는 일반적으로 다음과 같은 API가 사용된다.

  • CreateThread
  • CreateRemoteThread
  • NtCreateThreadEx
  • APC 기반 실행 기법

설계 배경

스레드 생성이나 프로세스 간 실행 흐름 제어는 운영체제 및 보안 솔루션이 쉽게 관찰할 수 있는 이벤트 중 하나이다.

따라서 본 프로젝트는 추가적인 실행 흐름 생성에 대한 의존도를 줄이고, 기존 프로세스의 실행 컨텍스트를 활용하는 방향을 검토하였다.


5. Phase 4: 메모리 상주 구조와 메모리 분석 관점

설계 목표

실행 코드가 위치하는 메모리 구조를 고려하여 분석 표면을 최소화한다.

설계 방식

실행 코드가 배치되는 메모리 영역의 특성과 프로세스 내 기존 모듈 구조를 함께 고려하는 방향으로 설계를 진행하였다.

기존 방식과의 비교

일반적으로 다음과 같은 방식이 널리 사용된다.

  • VirtualAlloc
  • VirtualAllocEx
  • Reflective Loading 기반 구조

설계 배경

실행 가능한 메모리 영역의 생성, 권한 변경, 모듈과의 관계 등은 메모리 분석 과정에서 중요한 관찰 대상이 될 수 있다.

따라서 단순히 코드를 실행하는 것이 아니라, 실행 코드가 어떠한 메모리 특성을 가지는지까지 함께 고려하였다.


6. Phase 5: 호출 스택과 실행 문맥 관리

설계 목표

호출 스택(Call Stack) 상에서 발생하는 비정상적인 실행 흔적을 줄인다.

설계 방식

민감한 시스템 동작 수행 시 호출 흐름과 실행 문맥이 분석 과정에서 어떠한 형태로 관찰될 수 있는지를 고려하였다.

기존 방식과의 비교

일반적으로 다음과 같은 형태가 사용된다.

  • 직접 함수 호출
  • 일반적인 API 호출 체인

설계 배경

현대 EDR은 호출 스택을 통해 실행 기원과 호출 관계를 분석할 수 있다.

따라서 단순한 기능 구현뿐 아니라 실행 흐름의 일관성과 문맥 정보 역시 중요한 설계 요소로 판단하였다.


Architecture Summary

Phase 1 PEB/EAT Resolver Jenkins Hash Resolver

Phase 2 Halo's Gate

Phase 3 Deferred Threadless Execution

Phase 4 Module Stomping

Phase 5 SpookStack

7. 결론: 설계 범위와 아키텍처 철학

V6 Loader는 초기 실행 단계(Initial Execution Phase)에 초점을 맞춘 연구 프로젝트이다.

본 프로젝트의 목적은 특정 보안 제품을 대상으로 한 우회 기법을 구현하는 것이 아니라, 현대 EDR이 활용하는 다양한 관찰 지점을 분석하고 이에 따른 설계 선택을 검토하는 데 있다.

이를 위해 다음과 같은 설계 요소들을 단계별로 적용하였다.

  • PEB/EAT 기반 API Resolver
  • Hash 기반 Import Resolution
  • Dynamic Indirect Syscall (Halo's Gate)
  • Deferred Threadless Execution
  • Module-Backed Memory Staging (Module Stomping)
  • Call Stack Context Management (Stack Spoofing)

각 설계 요소는 정적 분석, 런타임 모니터링, 프로세스 텔레메트리, 메모리 분석, 호출 스택 분석 등 서로 다른 관점에서 발생하는 탐지 신호를 고려하여 선택되었다.

궁극적으로 본 프로젝트는 로더를 하나의 엔지니어링 문제로 바라보고, 변화하는 방어 환경 속에서 실행 흐름, 메모리 구조, API 호출 문맥을 어떻게 설계할 수 있는지 탐구하기 위한 사례 연구(Case Study)의 성격을 가진다.