Security Note

[Windows] Session 0 isolation

Yuta — Tue, 23 Jan 2024 21:04:18 +0900

Session 0 Isolation 적용 전과 후

Windows XP, 2003 이하의 운영체제의 경우 처음으로 로그인하는 사용자의 user-mode 애플리케이션과 함께 서비스들이 모두 세션 0에서 실행되었다. 그 중에는 상승된 권한으로 실행되는 서비스들도 존재하였고 이 서비스들은 권한 상승을 노리는 공격자들의 타겟이 되었다.

이러한 문제를 해결하고자,그리고 세션 0에서 실행되는 서비스들은 상호작용 대상에서 제외시켰다. 이로 인해 더이상 서비스들은 다른 세션에서 실행되는 사용자 애플리케이션과 상호작용 할 수 없게 되었으며, 동시에 사용자 애플리케이션에 포함된 악성 코드로부터 보호되었다. 모든 서비스들과 user-mode 드라이버들은 세션 0에서 실행되도록 분리시키고, 사용자 세션은 세션 1 이후의 세션에서 실행되도록 하였다.

적용 대상

Windows Kernel 6 이상이 탑재되는 Windows 7 이후 운영체제부터 적용

영향

Session 0에서 실행되는 서비스가 UI와 같은 상호작용 기능을 수행할 경우, 서비스는 사용자의 Windows 세션과 다른 세션에서 독립적으로 실행되고 있기 때문에 정상적으로 서비스의 동작을 확인할 수 없다.
Window 메세지 기능을 이용하여 서비스와 애플리케이션 간의 통신을 수행하는 경우, 서비스와 애플리케이션이 서로 다른 메세지 큐를 갖게 되어 정상적으로 메세지 전달이 안된다.

Mitigation

Windows Vista에 내장된 mitigation을 사용할 경우,
특수 desktop 내에서 세션 0과 사용자 간의 상호작용 가능
Windows XP compatibility mode를 사용할 경우,
전역으로 생성된 오브젝트를 이용해 세션 0에서 실행되는 서비스와 사용자 애플리케이션 간의 작업 수행

해결 방안

Client - Server 모델을 적용하여 RPC나 명명된 파이프를 사용해서 서비스와 애플리케이션 간 통신하기
CreateProcessAsUser API를 사용하여 사용자의 세션에서 프로세스를 생성하고 상호작용 하기
간단한 메세지 박스의 경우 WTSSendMessage API를 사용하여 사용자 세션에 알림 전달하기
오브젝트에 명시적으로 Local\이나 Global\ 네임스페이스를 적용하여 서비스에서 사용할 수 있도록 하기

참고자료

리버싱 핵심원리 42장
microsoft.com 웹페이지 본문

Application Compatibility - Session 0 Isolation

First published on TECHNET on Apr 27, 2007 In Windows XP, Windows Server 2003, and earlier versions of the Windows operating system, all services run in the..

techcommunity.microsoft.com

Interacting with Services

Table of contents Interacting with Services Article 09/14/2005 In this article --> In the comments for my first services post, someone asked about the SERVICE_INTERACTIVE_PROCESS flag that can be specified for the CreateService API. This flag allows the us

learn.microsoft.com

[Windows] Process 생성 및 종료 과정

Yuta — Thu, 28 Dec 2023 17:13:51 +0900

Process

MSDN에서는 프로세스를 간단히 말해 “실행 중인 프로그램”으로 정의하고 있다. 하나의 프로세스는 하나 이상의 스레드(thread)를 갖는데, 이 중 첫 번째로 실행된 스레드를 primary 스레드라고 부른다. 프로세스의 주소 공간에 저장된 코드가 실제로 실행되기 위해서는 이를 실행하기 위한 스레드가 필요하다. 따라서 프로세스가 실행되면 주 스레드가 생성되고, 프로세스 내 모든 스레드가 종료될 경우 프로세스도 종료된다.

Process 구성 요소

프로세스는 크게 두 개의 컴포넌트로 구성된다.

프로세스 커널 오브젝트
사용할 코드와 데이터를 수용하기 위한 주소 공간

프로세스 커널 오브젝트는 프로세스 자체가 아니다. 프로세스를 관리하기 위한 목적으로 운영체제에서 사용되는 커널 오브젝트이며, 프로세스에 대한 통계 정보를 가지는 메모리 블록이다. 따라서 프로세스 생성과 종료 과정 시 가장 처음으로 생성되고, 가장 마지막으로 삭제된다.

각 프로세스는 프로세스 별 주소 공간을 가진다. 이 주소 공간에는 프로세스의 실행에 필요한 코드와 데이터가 저장될 공간이 있으며, 실행에 사용되는 Thread Stack이나 Heap 할당을 위한 메모리 공간도 포함된다.

Process 생성 과정

프로세스 생성 시 CreateProcess API를 이용하여 새로운 프로세스를 생성할 수 있다.

BOOL CreateProcess(
  [in, optional]      LPCTSTR               lpApplicationName,
  [in, out, optional] LPTSTR                lpCommandLine,
  [in, optional]      LPSECURITY_ATTRIBUTES lpProcessAttributes,
  [in, optional]      LPSECURITY_ATTRIBUTES lpThreadAttributes,
  [in]                BOOL                  bInheritHandles,
  [in]                DWORD                 dwCreationFlags,
  [in, optional]      LPVOID                lpEnvironment,
  [in, optional]      LPCTSTR               lpCurrentDirectory,
  [in]                LPSTARTUPINFOT        lpStartupInfo,
  [out]               LPPROCESS_INFORMATION lpProcessInformation
);
// T는 사용되는 문자 타입에 따라 None(ANSI)나 W(Unicode)가 될 수 있다.

이 API는 다음의 과정으로 Process를 생성한다.

프로세스 커널 오브젝트 생성
새 프로세스를 위한 가상 주소 공간 생성
생성된 가상 주소 공간에 실행 파일 코드와 데이터, 사용되는 DLL 파일 로드
새 프로세스의 primary 스레드에 대한 스레드 커널 오브젝트 생성
primary 스레드에 의해 C/C++ 런타임 시작 함수 실행

여기서 5번 단계를 거쳐 실행된 C/C++ 런타임 시작 함수는 다음의 작업을 수행한다.

C/C++ 런타임 라이브러리 초기화: 전역변수와 Heap 초기화
코드 상에서 선언된 전역 오브젝트, static 클래스 오브젝트 생성자 호출

이렇게 초기화 과정을 모두 완료하고 난 후 애플리케이션의 진입점 함수를 호출해 본 프로그램을 시작한다.

참고. Linker와 Loader

Linker와 Loader는 운영체제의 구성 요소로 프로그램을 개발하고 실행할 때 사용되는 요소이다. Linker는 프로그램 개발 시 컴파일 단계에서 생성된 여러 오브젝트 파일과 라이브러리 파일들을 하나의 실행 파일로 결합하기 위해 사용된다. Loader는 실행 파일의 코드와 데이터 등을 프로세스의 가상 주소 공간에 로드하기 위해 사용된다.

앞서 언급된 프로세스 생성 과정 중 Linker와 Loader가 기여하는 파트는 다음과 같다.

Linker는 프로세스 생성 과정 중 5번 단계에 사용되는 C/C++ 런타임 시작 함수를 결정한다. 이 때 결정의 기준이 되는 정보가 개발된 프로그램에 대한 Subsystem 링커 스위치이다. 이 링커 스위치는 실행 파일의 형태에 따른 필요 서브시스템 정보를 가지는데, CUI 프로그램일 경우 /SUBSYSTEM:CONSOLE 링커 스위치를 가지고 GUI 프로그램일 경우 /SUBSYSTEM:WINDOWS 링커 스위치를 가진다.

프로그램 빌드 단계에서 Linker는 이 서브시스템 정보를 확인한 후 CONSOLE 링커 스위치가 설정된 경우 프로그램 내 구현된 main이나 wmain 함수를 찾고, 이 함수가 존재하는 경우 mainCRTStartup이나 wmainCRTStartup 함수를 런타임 시작 함수로 설정한다. 만일 서브시스템 정보가 WINDOWS 링커 스위치로 설정된 경우 프로그램 내 WinMain이나 wWinMain 함수가 구현되었는지 확인하고, WinMainCRTStartup이나 wWinMainCRTStartup 함수를 런타임 시작 함수로 설정한다. 이렇게 설정된 런타임 시작 함수가 프로세스 생성 단계 5번에서 실행된다.

Loader는 3번 단계를 수행하는데 핵심적인 역할을 하며, 5번 단계에서 C/C++ 런타임 시작 함수가 실행되기 전 프로그램 실행에 필요한 환경을 구성하는 역할을 한다.

이 때에도 마찬가지로 프로그램의 서브시스템 정보를 확인한다. Windows의 PE 파일 헤더의 필드 중 subsystem 정보를 얻을 수 있는데, 이를 이용하여 실행에 필요한 서브시스템 정보를 얻을 수 있다. 그리하여 서브시스템 정보가 CONSOLE일 경우 프로그램 실행 전에 콘솔 윈도우를 생성하거나 기존에 열려있던 콘솔 윈도우를 사용하여 실행에 필요한 환경을 구성한다. 서브시스템 정보가 WINDOWS라면 곧바로 애플리케이션을 로드한다.

Process 종료 과정

프로세스는 여러 요인에 의해 종료될 수 있다. 정상적으로 프로그램이 시작하고 끝나면서 종료되는 경우도 있겠지만, 프로그램 내에서 호출된 ExitProcess 함수에 의해 종료될 수도 있고 다른 프로세스에서 호출된 TerminateProcess 함수에 의해서도 종료될 수 있다. 이 중 프로그램의 진입점 함수가 반환되면서 프로그램이 graceful 종료되는 상황에 대해 설명한다.

프로세스의 실행 과정을 보면 프로세스가 생성된 후 런타임 시작 함수가 호출되고, 런타임 시작 함수의 실행 과정에서 프로그램의 진입점 함수가 호출되며 프로그램이 실행되는 것을 알 수 있다. 그렇기에 함수의 실행 과정을 고려했을 때 진입점 함수가 반환 된 뒤 프로그램의 제어가 다시 런타임 시작 함수로 돌아올 것임을 알 수 있다. 그렇기에 진입점 함수가 반환 된 후 런타임 시작 함수로 제어가 돌아간 이후 단계부터 정리하였다.

진입점 함수가 반환되면 진입점 함수의 반환값을 인자로 갖는 C/C++ 런타임 라이브러리의 exit 함수를 호출한다. exit 함수는 다음의 작업을 수행한다.

_onexit 함수를 통해 프로그램 종료 시 호출되도록 등록해둔 루틴 수행
모든 전역 클래스 오브젝트와 static C++ 클래스 오브젝트의 파괴자 호출
진입점 함수의 반환값(종료 코드)을 인자로 갖는 ExitProcess 함수 호출

마지막 과정인 ExitProcess 함수를 호출하고 나면 운영체제에 의해 프로세스가 종료된다.

프로세스가 종료된 뒤에는 다음의 작업이 수행된다.

프로세스 내에 남아있는 스레드 종료
프로세스에 의해 할당되었던 모든 사용자 오브젝트와 GDI 오브젝트 삭제
프로세스에서 사용된 모든 커널 오브젝트에 대한 사용 카운트 1 감소
프로세스의 종료 코드를 STILL_ALIVE에서 반환된 종료 코드로 변경
프로세스 커널 오브젝트의 상태를 시그널 상태로 변경
프로세스 커널 오브젝트의 사용 카운트 1 감소

여기서 6번 단계 이후 프로세스 커널 오브젝트의 사용 카운트가 0이 되어야 프로세스의 커널 오브젝트까지 삭제되면서 프로세스의 모든 정보가 온전히 파괴된다. 만약 여전히 다른 프로세스에서 해당 프로세스의 정보를 이용하고자 프로세스 커널 오브젝트에 대한 핸들을 사용 중이라면 사용 카운트가 0이 되지 않아 곧바로 파괴되지 않을 것이다.

- 참고: 제프리 리처의 Windows via C/C++

[Windows] Kernel Object

Yuta — Wed, 27 Dec 2023 17:00:55 +0900

Kernel Object

커널 오브젝트는 커널에 의해 할당된 메모리 블록으로, 커널에 의해서만 접근 가능한 객체이다. 이를 이용하여 시스템에서 사용되는 여러 자원들을 효과적으로 관리할 수 있다.

커널 오브젝트는 파일 오브젝트, Mutex 오브젝트, Process 오브젝트 등 여러 종류의 형태로 존재한다. 각 오브젝트는 보안과 안정성을 위해 커널에 의해서만 접근 가능하며, 이를 생성 및 조작하기 위해서는 Windows에서 제공하는 API를 이용해야 한다.

각 커널 오브젝트는 형태에 따라 서로 다른 정보를 가진다. 그럼에도 불구하고 다음의 두 정보는 커널 오브젝트 마다 공통적으로 사용된다.

1. 사용 카운트

: 해당 커널 오브젝트를 사용 중인 프로세스의 수. 0 이상의 정수값을 갖는다.

커널 오브젝트를 최초 생성할 경우 사용 카운트값으로 1을 갖는다.
커널 오브젝트를 사용하는 프로세스의 수가 증가할 때마다 사용 카운트값이 1씩 증가한다.
커널 오브젝트의 사용을 종료(프로세스의 종료 또는 CloseHandle(hObj) 호출)할 때마다 사용 카운트 값이 1씩 감소한다.
커널 오브젝트의 사용 카운트값이 0이 되면 해당 오브젝트가 삭제된다. (해당 커널 오브젝트에 대한 사용이 모두 종료되어야 삭제된다.)

2. 보안 디스크립터(SECURITY_ATTRIBUTES 구조체)

: 커널 오브젝트에 대한 소유자, 접근 권한에 대한 정보

커널 오브젝트와 유저 오브젝트/GDI 오브젝트를 구분하는 팁으로, 오브젝트 생성 API에 보안 특성을 지정하는 매개변수가 존재하는지를 확인하는 방법이 있다고 한다.

Handle & Process Handle Table

Windows API를 이용해 커널 오브젝트를 생성하는 데 성공하면 커널 오브젝트를 조작하는 데 사용 가능한 핸들(handle) 값을 얻을 수 있다. 이 핸들값을 다른 Windows API 매개변수로 전달하여 커널 오브젝트를 사용할 수 있다.

생성된 커널 오브젝트에 대한 핸들값은 각 프로세스마다 고유하다. 각 프로세스는 자신만의 독립된 프로세스 핸들 테이블을 갖기 때문에, 프로세스 내에서 생성된 핸들값은 해당 프로세스 내에서 생성된 모든 스레드에서 사용 가능하지만 다른 프로세스에서는 사용할 수 없다. 다음은 프로세스 핸들 테이블의 구조이다.

Process Handle Table

커널 오브젝트에 대한 핸들값은 프로세스 핸들 테이블에 매핑된 인덱스값과도 관련이 있는데, 가령 프로세스 A에서 프로세스 핸들 테이블 내 인덱스 2번을 가리키는 핸들값을 프로세스 B에서 동일하게 사용할 경우 프로세스 B의 프로세스 핸들 테이블 내 인덱스 2번에 다른 타입의 커널 오브젝트가 참조되어 있으면 잘못된 오브젝트를 참조하게 된다.

How to share Handles

앞서 설명한 바와 같이 두 프로세스 간 커널 오브젝트를 공유해야 할 경우 단순히 핸들값을 공유하는 방법은 옳지 않다. 그렇기에 이후 내용에서 서로 다른 두 프로세스 간에 커널 오브젝트를 공유하기 위한 방안을 정리하였다.

1. Kernel Object Handle 상속

이 방법은 커널 오브젝트를 공유하고자 하는 두 프로세스가 Parent - Child 관계일 경우 사용 가능하다. 이 방법은 크게 다음과 같은 단계로 진행된다.

Parent process에서 상속하고자 하는 핸들 설정: 핸들 생성 또는 핸들 속성 변경 시
Child process 생성 시 child process에게 핸들을 상속할 것인지 유무 설정

위 두 단계를 거치고 나면 Parent process의 process handle table 내 상속된 핸들에 대한 레코드가 새로 생성된 Child process의 process handle table 내 동일한 인덱스로 복사된다.

이러한 메커니즘으로 인해 핸들 상속 후 Parent process에서 대상 커널 오브젝트에 대해 사용 중이던 핸들의 사용을 종료하더라도, Child process의 process handle table 내에 커널 오브젝트에 대한 정보가 남아있으므로 Child process에서 상속된 핸들을 통해 여전히 커널 오브젝트에 접근할 수 있다. 또한 상속을 통해 대상 커널 오브젝트를 사용하는 프로세스의 수가 1 증가하였으므로 대상 커널 오브젝트의 사용 카운트값도 1 증가하게 된다.

2. Kernel Object의 이름 이용

이 방법은 커널 오브젝트 생성 시 고유한 이름을 부여하여, 다른 프로세스에서 커널 오브젝트의 이름을 이용해 대상 오브젝트에 대한 핸들을 얻는 방식이다. 이 방식이 가능한 이유는 커널에 의해 할당된 커널 오브젝트들은 타입에 상관없이 동일한 네임스페이스를 공유하기 때문에 서로 다른 프로세스라 하더라도 공유 중인 네임스페이스 내 정의된 커널 오브젝트의 이름을 이용하여 공유할 수 있다. 따라서 하나의 네임스페이스 내에서 명명되는 커널 오브젝트들은 고유한 이름을 가져야 하며, 다른 타입의 커널 오브젝트라 하더라도 서로 다른 이름을 가져야 한다.

만일 명명하고자 하는 커널 오브젝트의 이름이 이미 네임스페이스 내에서 사용 중인 경우 커널 오브젝트의 생성은 실패할 것이다. 이러한 메커니즘을 악용하면, 공유 중인 네임스페이스를 통해 공격 대상 프로세스에서 사용할 커널 오브젝트의 이름을 수집한 후 미리 해당 이름을 갖는 커널 오브젝트를 생성하여 공격 대상 프로세스의 정상 구동을 방해하는 공격(DoS 공격의 일종)에 취약해진다.

따라서 이를 막고자 Private 네임스페이스를 사용하여, 다른 프로세스에서 사용 중인 이름과 충돌되거나 사용되는 이름이 탈취되는 것으로부터 안전해질 수 있다. 이 때 Boundary descriptor를 함께 사용하여 private 네임스페이스에 대한 접근 권한을 설정하는 것으로 private 네임스페이스 자체에 대한 보안을 강화할 수 있다.

추가로, 터미널 서비스를 사용하는 경우에는 모든 클라이언트 세션으로부터 접근 가능한 Global 네임스페이스가 있고, 각 클라이언트 세션별 고유 네임스페이스(Local)가 존재한다. 기본적으로 터미널 서비스에서 사용되는 커널 오브젝트는 Global 네임스페이스 내 명명되고, 각 터미널 서비스 내 애플리케이션에서 사용되는 커널 오브젝트는 Local 네임스페이스에 명명된다. 그렇기 때문에 서로 다른 클라이언트 세션에서 동일한 애플리케이션을 실행하여도 충돌이 발생하지 않을 수 있다.

3. Kernel Object Handle 복사

이 방법은 source process의 process handle table 내에 기록된 커널 오브젝트에 대한 참조를 target process의 process handle table로 복사하는 것이다. 이를 위해 DuplicateHandle API를 사용하면 간편하게 복사할 수 있다.

BOOL DuplicateHandle(
  [in]  HANDLE   hSourceProcessHandle,
  [in]  HANDLE   hSourceHandle,
  [in]  HANDLE   hTargetProcessHandle,
  [out] LPHANDLE lpTargetHandle,
  [in]  DWORD    dwDesiredAccess,
  [in]  BOOL     bInheritHandle,
  [in]  DWORD    dwOptions
);

이 함수를 호출하면 공유하고자 하는 target process에서 사용 가능한 커널 오브젝트의 핸들값을 얻을 수 있다. 만일 source process에서 위 함수를 사용하여 target process를 위한 핸들값을 구했다면 IPC와 같은 프로세스 간 통신 방법으로 target process에 핸들값을 전달하여 커널 오브젝트를 사용하도록 할 수 있다.

- 참고: 제프리 리처의 Windows via C/C++

Frida를 이용한 모바일 악성 애플리케이션 실행 환경 Detection Bypass

Yuta — Wed, 29 Nov 2023 17:20:03 +0900

Frida는 Dynamic Binary Instrumentation(DBI) 프레임워크이며, Windows, mac OS, iOS, Android 애플리케이션을 동적으로 분석할 수 있게 해주는 도구이다. Frida는 함수를 후킹하여 해당 함수의 동작을 분석하거나, 다른 동작을 수행하도록 코드를 덮는 등의 작업을 할 수 있게 해준다. Frida는 크게 두 가지 구성 요소로 이루어진다. 안드로이드 기기 내에 설치 후 열어두어야하는 Frida Server와, Local host에 설치하여 후킹 코드를 전달하고 후킹 결과를 확인할 수 있도록 하기 위한 Frida 클라이언트로 구성된다.

Frida의 상세 사용법 등에 대해서는 아래 링크에 정리해두었다.

Tools: Android Frida

Frida Overview

yutaa.notion.site

이를 이용하여 분석하고자 했던 악성 애플리케이션 내에 존재하는 환경 탐지 메커니즘을 찾고 우회할 수 있는 스크립트를 작성해보았다. 이 스크립트를 사용하면 에뮬레이터에서의 실행을 방해하는 코드를 우회하여 정상적으로 애플리케이션을 실행할 수 있게 된다.

다음은 이러한 과정을 별도로 정리해두었던 보고서의 내용을 가져온 것이다.

1. Sample APK

Sample Hash (SHA256): 82D644A1F3BBA120327E7EB6029F6B986C95C35F0C40CD43001F2DBEDEE2EE6F

이번 샘플로 사용한 악성 앱의 경우 MobSF와 같은 악성 애플리케이션 분석 프로그램으로 분석할 경우 악성 행위가 제대로 탐지되지 않는 특징을 가진다. multidex 애플리케이션의 특징을 이용하여 악성 코드를 별도의 파일로 분리하고 암호화 시켜두었기 때문이다.

그 후 암호화되지 않은 classes.dex 파일을 이용하여 애플리케이션을 실행하고, 실행된 dex를 이용하여 암호화된 dex 파일의 내용을 복호화해 실행한다. 복호화된 dex 파일을 분석할 경우 곧바로 확인할 수 있겠지만 이러한 특징을 가지고 있기 때문에 복호화된 dex 파일의 내용을 획득하지 못하면 실제로 어떤 악성 행위를 행하는지 파악하기 어렵다.

그렇다면 이를 해결하기 위해 실제 모바일 기기에 설치 후 행위 기반의 동적 분석을 진행하면 되지 않느냐라고 말할 수 있다. 그러나 이 샘플을 기기에서 실행할 경우 Root 탐지, Emulator 탐지, ADB 탐지 등 다양한 탐지 메커니즘에 의해 곧바로 프로그램이 종료된다. 그렇기에 동적 분석을 위해서는 이러한 탐지 메커니즘을 우회하는 작업을 선행해야만 한다.

2. Frida

탐지 메커니즘을 우회하기 위해 유명한 동적 분석 도구인 Frida를 사용할 것이다. 이를 사용하면 코드 내 특정 함수를 원하는 대로 변경하여 실행 흐름을 조작할 수 있다. 도구의 이러한 특징을 이용하여, 프로그램 내에서 동적 분석 탐지를 위해 사용되는 코드를 확인하고 실행 흐름에 영향을 미치는 핵심 코드를 조작한다면 프로그램이 종료되지 않도록 만들 수 있다.

샘플 APK는 안드로이드 환경에서 실행되는 애플리케이션이기 때문에 Frida에서 제공하는 Java 관련 API을 주로 사용할 것이다. 그 중 Java.use()를 사용하면 현재 로딩된 클래스의 wrapper를 얻을 수 있어 매우 손쉬운 후킹이 가능하다. 여기서 로딩된 클래스에만 접근할 수 있다는 부분이 핵심인데, 이번 샘플의 경우 앱이 실행된 후 복호화 작업이 끝나야 앱의 구성 요소가 로드되기 때문에 처음부터 앱의 구성 요소에 접근할 수 없다. 현재 초점을 두고 있는 탐지 메커니즘 역시 이 암호화된 dex 파일 내에 위치해있다. 따라서 어느 시점에 복호화 작업이 끝나는 지를 파악하여 이 시점을 먼저 가로챈 다음, 후킹하고자 하는 탐지 메커니즘에 접근하는 방식을 사용할 것이다. -> 보고서 작성 당시 이렇게 생각하고 3번의 과정을 분석하였는데, 막상 분석하고 난 후 frida 스크립트를 작성하려고 하니 jadx 상에서 보이는 클래스나 메서드의 이름이 jadx에서 임의로 붙여둔 이름이라 이를 명확히 가리켜 해당되는 wrapper를 가져올 수 없었다. 따라서 범용적으로 사용되는 Java나 android 라이브러리가 detection code에서 사용되는 시점을 후킹하여 원하는 작업을 하도록 하였다. (이 부분에 대한 분석은 이어지는 4번에서 확인할 수 있다.)

3. Detailed Analysis: Decryption Process

프로그램이 시작되는 파일을 찾기 위해 AndroidManifest.xml 파일을 확인하면, application 태그의 name 속성으로 com.lzsEsq.dykSgp.jhvqZx.pupsPVlBod라는 이름의 클래스가 적혀있는 것을 확인할 수 있다.

이를 통해 com.lzsEsq.dykSgp.jhvqZx.pupsPVlBod 클래스부터 분석을 시작하면 될 것이라는 것을 알 수 있다. 이 파일에서 한 가지 더 확인할 수 있는 부분은 entry 클래스가 속한 패키지명은 com.lzsEsq.dykSgp.jhvqZx 인데, AndroidManifest.xml 파일에 기록된 패키지명은 com.ldjSxw.heBbQd 로 차이를 보인다는 것이다.

암호화되어있지 않은 classes.dex의 소스 코드는 jadx를 이용하여 곧바로 확인할 수 있다. 파일 내용을 확인하면 앞서 AndroidManifest.xml 파일에서 보았던 entry 클래스 pupsPVlBod를 찾을 수 있다.

이 클래스는 메세지 수신을 위한 handler를 가진다.

본격적인 분석 시작을 위해 이 클래스의 onCreate 메서드를 확인하였다.

onCreate 메서드에서는 3개의 서로 다른 함수를 호출한다. 분석 결과, 이 중 첫 번째로 호출되는 함수 m19a가 주된 실행을 담당하였다.

m19a 함수는 base context와 com.ldjSxw.heBbQd.MainApplication 클래스에 대한 인스턴스를 인자로 하는 attach 메서드를 호출한다. 이로 인해 본 클래스 내에 정의된 attachBaseContext 메서드가 호출된다. 그리고 이 attachBaseContext 메서드에서 대부분의 작업이 진행된다.

attachBaseContext 메서드는 크게 다음과 같은 작업을 수행한다.

복호화된 파일이 저장될 폴더 초기화
암호화된 파일 복호화
신규 폴더로 apk 파일 복사

이 과정에서 신규로 저장될 파일들은 com.ldjSxw.heBbQd.MainApplication_{appVersion}/app 폴더에 위치하게 될 것임을 알 수 있으며, 실제 디바이스 내에서 확인했을 때에도 /data/data/com.ldjSxw.heBbQd.MainApplication_null/app 폴더 내에 위치하였다.

위 과정에서 dexDir 경로가 존재하지 않을 경우 m9k 함수를 실행시키는데, 이 과정에서 암호화된 dex 파일에 대한 복호화 과정을 확인할 수 있다.

m9k 함수에서 주로 수행하는 작업은 다음과 같다.

새롭게 애플리케이션 파일이 위치할 경로 내에 있는 폴더 및 파일들을 모두 삭제한다.
프로그램이 실행될 때 실제로 사용될 경로이기 때문에 다른 파일의 간섭을 최소화하기 위한 조치로 보인다.
인증서 관련 파일을 제외한 나머지 파일들 중, classes.dex 파일이 아닌 dex 파일을 복호화하여 신규 위치에 저장한다. (m10j method)
classes.dex 파일과 인증서 관련 파일이 아닌 나머지 파일을 신규 위치에 저장한다.

여기서 복호화에 사용되는 m10j 메서드를 따라가면, pupsPVlBod 클래스와 함께 존재하던 ymcBssEDD 클래스의 decrypt 메서드가 사용되는 것을 확인할 수 있다.

decrypt 함수의 세부 구조는 libset.so 파일에 native 라이브러리로 구현되어 있어 별도의 분석이 필요하다. 이 라이브러리를 분석할 경우 복호화 키를 얻을 수 있는데, 이 부분은 2.3.1 파트에서 다뤘기 때문에 넘어간다.

이러한 일련의 과정으로 암호화된 dex 파일을 복호화하고 apk 파일 내 나머지 파일들을 신규 위치로 이동하여 실행할 준비를 마치게 된다.

다시 m19a 메서드로 돌아오면, 앞서 정리한 과정을 수행하고 기타 Field의 값을 획득한 후 마지막에 f1302m으로 빈 메시지를 전송한다. f1302m은 분석 초기에 확인하고 넘어갔던 메세지 수신 handler이다.

f1302m으로 메시지를 전송하면 정의해둔 handleMessage 메서드가 실행된다. 이 코드에서는 handleMessage 메서드를 다음과 같이 정의하여 메세지를 수신할 경우 f1304o의 onCreate 메서드가 호출되도록 하였다. f1304o은 m19a 메서드의 초반에서 정의한 대로 com.ldjSxw.heBbQd.MainApplication 의 클래스 인스턴스를 가진다. 결과적으로 m19a 메서드에서 메세지를 보내는 행위는 com.ldjSxw.heBbQd.MainApplication 클래스가 실행되게 만드는 결과를 낳는다.

앞서 AndroidManifest.xml 파일을 확인하며 entry 클래스의 패키지명과 본 apk 파일의 패키지명이 달랐던 것을 기억하는가? 그 때 확인하였던 apk 파일의 패키지명은 메세지를 보내 실행되도록 만드는 클래스의 패키지명과 일치하며, 이러한 점들을 미루어 생각했을때 본격적으로 앱의 구성 요소가 로드될 것임을 짐작할 수 있다. 따라서 MainApplication으로 메세지를 보내는 sendEmptyMessage 함수가 호출되는 시점이 dex 파일의 복호화가 완료된 지점일 것이다.

4. Detailed Analysis: Detection Process

AndroidManifest.xml 파일 내 기재된 바에 의하면 샘플 APK는 IntroActivity에서 시작한다.

이 IntroActivity는 BaseActivity를 상속받는데, 이러한 이유로 프로그램이 시작하면 BaseActivity의 onCreate 메서드가 실행되고, 그 후에 IntroActivity의 onCreate 메서드가 실행된다.

아래는 BaseActivity의 onCreate 메서드이다. 이 메서드는 실행되자마자 m47k 메서드를 실행하고 그 결과값에 따라 프로그램을 종료시킨다. 종료 시 반환하는 문자열로 Rooted가 사용되는 것을 통해 루트 탐지 부분일 것으로 생각할 수 있다. 실제로 앱을 에뮬레이터 상에서 실행하였을 때 루트 상태의 에뮬레이터를 사용할 경우 곧바로 종료된다.

이에 따라 탐지 우회 방안을 찾기 위해 m47k 메서드에서 사용되는 각 함수를 하나씩 분석하였다.

Locale Detection: 시스템 언어 설정을 확인하여 한국어를 사용하는 기기에서만 앱이 실행되도록 하는 코드이다. 이를 통해 한국어 사용자를 대상으로 악성 행위를 수행하도록 하고 있음을 알 수 있다.

Root Detection: 다음의 두 함수를 이용하여 루팅된 기기에서 실행되고 있는지 확인한다. 이를 위해 루팅된 기기에서 주로 발견되는 Build Tag 내 test-keys 키워드가 포함되어있거나, Superuser.apk 패키지가 설치되었는지 여부를 확인하고 있다.

Emulator Detection: 에뮬레이터 상에서 앱이 실행되고 있는지를 확인하기 위해 앱이 실행중인 기기 내 /proc/tty/drivers 파일 내용을 확인한다. 그 중에서도 QEMU 기반의 Android 가상 환경에서 사용되는 goldfish kernel을 사용하는 에뮬레이터를 대상으로 탐지하고 있다.

ADB Detection: Android의 Secure system setting 내 속성 중 adb_enabled 속성값을 확인하여 adb 사용중인지에 대해 확인한다.

VPN Detection: 에뮬레이터에서 사용 중인 네트워크 인터페이스 중 tun0이나 ppp0과 같은 VPN에서 주로 사용되는 인터페이스명이 존재하는지 확인한다.

HTTP Proxy Detection: Proxy를 사용할 경우 http.proxyHost와 http.proxyPort 속성에 각각 proxy 설정값이 부여된다. 그렇기 때문에 이 값이 설정되었는지 여부를 이용하여 proxy 사용 여부를 확인한다.

5. Detection Bypass

앞서 확인한 각 탐지 메커니즘에 대해 다음과 같은 Frida 스크립트를 작성하였다. Frida에서 API로 지원하는 언어 중 Javascript를 사용하였으며, 후킹하고자 하는 대상인 Android 앱이 Java를 기반으로 작성된 프로그램이기 때문에 Frida API 중 Java Instrumentation을 주로 사용하였다.

스크립트 작성 시 decompile 특성 상, 프로그램 작성자에 의해 명명된 함수의 원본 함수명을 찾는데 어려움이 있다. 따라서 주로 android나 java 라이브러리에 정의된 함수의 이름을 이용하여 이를 후킹하는 방식을 사용하였다.

Locale Detection: getLanguage 함수는 String 타입으로 현재 시스템에 설정된 언어를 반환한다. 그렇기 때문에 이를 hooking하여 어떤 시스템에서도 한글 설정이 되어 있는 것과 같이 인식하도록 반환값을 “ko”로 고정되게 만들었다.

Root Detection 1: java 라이브러리 method인 contains의 반환값을 hooking하여 탐지하고자 하는 값이 포함되지 않은 것으로 처리되도록 하였다. 이 때 루트 탐지에 사용된 값이 test-keys이므로, 이 값으로 비교할 경우에만 우회 코드가 동작하도록 하기 위한 조건을 함께 설정하였다.

Root Detection 2: Superuser.apk 가 존재하는지를 검사하기 위해 File 클래스의 생성자를 이용하여 검사할 경로의 파일을 불러온다. 이를 특징으로 삼아, /system/app/Superuser.apk 경로를 File 생성자의 인자로 넘기며 호출하는 순간을 hooking하였다. 여기서는 탐지할 경로를 없을 만한 파일의 경로로 설정하여, File 클래스가 존재하지 않는 파일의 경로를 조사하도록 하였다.

Emulator Detection: indexOf method 사용 중 비교 대상 문자열로 goldfish를 사용하는 경우에만 해당 문자열이 포함되지 않았음을 나타내는 결과인 -1을 반환하도록 하였다.

ADB Detection: Settings.Secure 클래스 내 getInt 메서드를 사용하여 adb_enabled 속성값을 조회하는 경우는 탐지를 위한 과정 중 사용하는 경우가 유일할 것으로 생각되어, adb_enabled 속성값 조회 시 항상 0을 반환값으로 가지도록 하였다.

VPN Detection: tun0과 ppp0 문자열과 비교하는 경우가 흔히 존재하지 않을 것으로 생각되어, 이를 다른 문자열과 비교하기 위해 equals 메서드의 인자로 사용하는 경우를 후킹하여 일치하지 않음을 나타내는 false를 반환값으로 가지도록 하였다.

Proxy Detection: System.getProperty 메서드를 이용해 http.proxyHost나 http.proxyPort 속성값을 조회하는 경우를 후킹하여 두 경우에 대해 null을 반환값으로 가지도록 하였다. 이를 통해 실제 proxy를 사용중이더라도 정상적인 속성값을 조회하지 못해 proxy가 사용중인지 알 수 없도록 하였다.

[Dreamhack] Inject Me!! write-up

Yuta — Thu, 26 Oct 2023 00:27:11 +0900

Inject ME!!!

Description 드림이가 수상한 DLL 파일을 획득하였습니다. DLL 파일과 함께 있던 TXT 파일에는 조건을 맞춰서 DLL을 로드시키면 플래그를 얻을 수 있다고만 쓰여 있었습니다. 어떻게 해야 DLL 파일을 로

dreamhack.io

문제 파일로 dll 파일 하나만 달랑 주어진다.

문제 설명을 읽어보면 DLL 파일을 조건에 맞춰서 로드시켜야한다고 하는데… 조건이 무엇인지는 안알려준다.

조건을 어떻게 찾아야할지 감을 못잡고 있다가 무작정 hex editor를 켜서 flag 문자열에 대해 검색해보았다.

그랬더니 아래와 같이 flag 문자열 주변에 dreamhack.exe라는 문자열이 있는 것을 발견하였다.

DLL은 자체적으로 로드되기보단 실행 파일에 기생(?)하여 실행되어야 할 것인데, Windows에서 사용되는 대표적인 실행 파일은 exe 확장자를 가진 파일이다.

그런데 마침 dreamhack.exe 라는 .exe 확장자를 가진 문자열을 발견하였고, dreamhack.exe 파일이 뭔지는 모르겠지만 일단 주어진 DLL을 로드하는 코드를 다음과 같이 만들었다.

#include "stdio.h"
#include "windows.h"
#include "conio.h"

void main() {
	HMODULE			hDll = NULL;

	hDll = LoadLibraryA("prob_rev.dll");
	if (hDll == NULL) {
		printf("Failed to load dll");
		return;
	}

	printf("Success to load library");
	while (_getch() != 'q');

	FreeLibrary(hDll);
}

여기서 dreamhack.exe 라는 문자열을 활용할 수 있는 방안은 실행할 exe 파일의 이름을 동일하게 맞춰주는 것이라고 생각되었기에, 이 코드를 빌드한 결과로 얻은 exe 파일의 이름을 dreamhack으로 변경한 후 실행하였다.

이걸 운이 좋았다고 표현하는게 맞는건지… 바로 flag를 얻을 수 있었다.

이렇게 풀어놓고 안찝찝할 수가 없다. 그래서 다른 풀이자분들의 풀이를 보았고, x64dbg를 이용해서 직접 dll의 행위를 리버싱할 수 있는 것을 알았다. 그렇기에 나도 직접 디버깅을 해보았다.

먼저 확인 가능한 문자열을 확인해보았고 다음과 같은 결과를 얻었다.

여기서도 dreamhack.exe는 매우 수상한 문자열로 느껴지므로 이것이 사용되는 위치로 이동해서 분석을 시작하였다.

이 부근을 디버깅해보면 dreamhack.exe 문자열이 strncmp 함수에 의해 rcx에 저장된 어떤 문자열과 비교되는 것을 알 수 있다.
그리고 문자열 비교 전 File명을 가져오는 함수가 사용되는데, 이 때 사용되는 파일의 경로가...

주어진 dll을 로드하고 있는 파일의 경로이다.

이를 계속 실행시켜보면 결국 현재 dll을 로드하고 있는 파일의 이름과 dreamhack.exe 문자열을 비교하고 있다.

따라서 실제로 파일명을 가져오는 함수의 결과를 담는 rax의 값을 dreamhack.exe로 바꿔주면 이 부분을 정상적으로 통과해 flag를 얻을 수 있다.

[Dreamhack] rev-basic-8 write-up

Yuta — Wed, 18 Oct 2023 11:43:06 +0900

rev-basic-8

Reversing Basic Challenge #8 이 문제는 사용자에게 문자열 입력을 받아 정해진 방법으로 입력값을 검증하여 correct 또는 wrong을 출력하는 프로그램이 주어집니다. 해당 바이너리를 분석하여 correct를 출

dreamhack.io

이 문제도 여타 다른 문제와 마찬가지로 입력값을 넣고 일련의 연산을 취한다음 이것이 특정한 값과 일치하는지를 비교하여 Correct / Wrong을 출력하는 문제이다. 역시나 Correct가 나올 수 있는 입력값을 찾아야 한다.

아래는 프로그램의 main 코드이다. 이중 일부 부분의 직접 변수명이나 타입을 바꾸어준 상태이다.

보면 uVar1의 값을 가지고 Correct / Wrong 결과를 가르는데 이 값을 결정짓는게 FUN_140001000 함수이다. 이 함수의 인자로 입력값이 들어가는걸 보면 이 함수가 핵심인게 분명하다.

아래 코드는 FUN_140001000 함수의 decompile 결과이며, 미리 각 변수의 이름을 해석하기 편리하도록 고쳐둔 상태이다.

코드를 보면 20개의 문자를 하나씩 비교하는데, 이 때 입력값에 대해 일련의 연산을 취한 후 이 값이 문제 속 데이터와 일치하는지 검사한다.

DAT_140003000 위치를 가보면 정확히 20개의 16진수 데이터가 위치해있음을 알 수 있다.

그러나 위 코드에서 입력값에 -5가 곱해지는 것도 그렇고 좀 더 자세한 분석이 필요할 것으로 보여 어셈 코드로 다시 살펴보았다.

입력값에 대한 연산은 140001031과 140001037 이렇게 두 부분이 핵심이다.

14000102d: 입력값에 대해 byte 단위로 가져온 후
140001031: 이에 대해 FB를 곱하고
140001037: 그 결과에서 하위 1바이트만 남기고 지운다.

여기서 연산 결과에 대해 하위 1바이트만 남기고 지우기 때문에, 곱셈 결과가 어떻게 나오든 문제 속 하드코딩되어 있는 각각의 바이트와 하나씩 비교가 가능한 것으로 보인다.

이 문제를 풀기 위해 처음에는 곱셈의 반대인 나눗셈으로 시도해보려고 했지만, 아무래도 AND 연산으로 하위 바이트를 자르고 비교하는 형태이기 때문에 역연산으로 정답인 입력값을 찾기 어려울 것 같았다. 그래서 결국 가능한 입력 범위 안에서 브루트포스 코드를 작성하였다.

answer = [0xAC, 0xF3, 0x0C, 0x25, 0xA3, 0x10, 0xB7, 0x25, 0x16, 0xC6, 0xB7, 0xBC, 0x07, 0x25, 0x02, 0xD5, 0xC6, 0x11, 0x07, 0xC5]
input_data = []

for i in range(20):
	for num in range(0x20, 0x7E):
		if (num * -5) & 0xFF == answer[i]:
			print(chr(num), end='')
			break

이를 실행하면 플래그를 얻을 수 있으며, 뜨끔하는 문장을 얻을 수 있다.ㅋㅋ

[Dreamhack] patch write-up

Yuta — Sun, 15 Oct 2023 20:06:32 +0900

patch

flag를 그리는 루틴을 분석하고 가려진 flag를 보이게 해주세요. Reference GDI+ - Win32 apps | Microsoft Docs Graphics Functions - Win32 apps | Microsoft Docs File — x64dbg documentation

dreamhack.io

이 문제는 실행하면 아래와 같이 딱 중요한 부분만을 가려놓은 윈도우 GUI 프로그램을 제공한다.

문제 설명을 토대로 유추하면.. Graphic 함수를 이용하여 flag를 그리는데, 이 루틴 중 flag를 가리는 부분을 패치하여 플래그를 얻어내는 문제인 것으로 추정된다.

IDA를 통해 문제 파일을 열어보면 Windows GUI 프로그램 국룰 시작 지점인 WinMain 함수를 확인할 수 있다. 그런데 내 IDA는 서버와의 오류 때문에 hex-ray가 되지 않으니 IDA가 찾아준 WinMain의 위치를 이용하여 Ghidra에서 WinMain의 hex-ray 결과를 볼 것이다.

아래는 Ghidra에서 분석해준 WinMain 함수의 hex-ray 결과이다.

MSDN의 API 문서에서 검색하면 알 수 있겠지만..

32줄의 CreateWindowExW 함수를 이용하여 윈도우 창을 실행하고,

이에 앞서 30줄의 RegisterClassExW 함수를 이용하여 CreateWindowEx 함수에서 사용할 창 클래스를 등록한다. 그렇기에 RegisterClassExW의 매개인자로 들어가는 WNDCLASSEXW 타입의 local_a8 변수의 속성을 18~29줄에서 정의하고 있는 것을 알 수 있다.

처음에는 이렇게 창 클래스 정의하는 부분은 단순 속성이라 생각하고 CreateWindowExW 함수를 이용하여 창을 생성하고 난 이후 if 문 안에서 이루어지는 작업이 그래픽 작업을 하는 부분인줄 알고 헤맸던 것 같다. 그런데 원하는 그래픽 작업 흔적이 명확하게 발견되지 않아 찾는 방식을 바꿨다.

Ghidra의 Symbol Tree 부분을 보면 GDIPLUS.DLL 이라고 그래픽 작업 관련 함수를 포함하는 DLL를 발견할 수 있다. 본 프로그램에서 사용되는 dll과 함수라고 생각하고 이 부분이 참조되고 있는 부분을 찾아나갔다.

다 사용되는 것 같긴 했지만, 이 중 GdipDrawLineI 함수에 대한 Reference 내역을 먼저 조회했다.

많은 결과가 나오지만 이 중 가장 첫 번째 항목을 따라갔다.

추적 결과 FUN_140001240 함수에서 사용되고 있었으며,

이 부분의 Call Tree를 따라가보면

다음과 같이 윈도우 창 클래스를 정의하던 부분의 lpfnWndProc 속성에 정의되는 FUN_1400032f0 함수를 통해 Pen 작업이 이루어지고 있음을 알 수 있다.

WNDCLASSEXW클래스의 lpfnWndProc 속성의 경우 창 클래스에 대한 프로시저 포인터를 가진다. 여기에 들어가는 함수는 콜백 함수 형태를 가지며, 윈도우 창에서 사용자에 의한 상호작용이 발생할 경우 이를 어떻게 처리할 것인지를 정의한다. 그렇기 때문에 이 부분에서 창에 보여질 행위 중 하나인 draw 작업이 이루어진 것으로 생각한다.

FUN_1400032f0 함수 내부를 살펴보면

BeginPaint 함수와 EndPaint 함수가 있으며, 이 사이에서 GdipAlloc 후 어떤 작업을 수행하고 GdipFree까지 하고 있다. 그 과정에서 FUN_140002c40 함수가 호출되는데, 이 함수의 내부를 살펴보면

다음과 같이 반복적으로 특정 함수가 호출하는 작업이 이루어짐을 확인할 수 있다.

아래 코드를 보면 초반에는 FUN_140002b80 함수가 반복적으로 사용되고 있고, 그 이후에 서로 다른 함수가 호출되고 있다.

우선 FUN_140002b80 함수의 역할에 대해 보기 위해 내부를 분석했다.

이 함수에서는 GdipCreatePen1 함수 호출 이후 GdipDrawLineI 함수를 이용하여 한번의 직선을 그리고 GdipDeletePen 함수를 이용하여 Pen 작업을 끝낸다.

즉, FUN_140002b80 함수가 한번 실행될 때마다 이 param으로 들어온 값에 따라 한 개의 직선을 그리고 있는 것으로 생각된다.

FUN_140002b80 함수 이후에 차례로 나타나는 여러 함수들의 경우는 조금 다른 코드 패턴을 가진다.

그 중 FUN_140002b80 함수 이후로 가장 처음 나타나는 FUN_1400017a0 함수는 다음과 같이 여러 차례의 GdipCreatePen1 - GdipDrawLineI - GdipDeletePen 과정을 가지며, 여러 선을 그리고 있는 것으로 추정된다.

FUN_1400017a0 함수 이후에 나타나는 여러 함수들도 FUN_1400017a0 함수와 같이 여러 개의 선을 그리는 코드를 가진다.

따라서 FUN_140002b80 함수와 그 이후에 위치하는 FUN_1400017a0 함수와 같은 함수들이 각각 어떤 선을 그리는지 보기 위해 다시 IDA를 이용하여 해당 위치를 동적 분석하였다.

FUN_140002b80 함수와 FUN_1400017a0 함수에 각각 bp를 걸고 실행시켰다.

먼저 처음 호출된 FUN_140002b80 함수의 경우 아래와 같은 선을 그린다.

그리고 그 다음에 호출된 FUN_140002b80 함수 역시 다음과 같은 선을 그린다.

여러 차례 진행되는 FUN_140002b80 함수를 모두 호출하고 나면 다음과 같은 선들이 그려진다.

이 선들이 그려진 곳은 분명 플래그를 가리는 위치이다. 따라서 FUN_140002b80 함수는 플래그를 가릴 때 사용하는 함수로 여길 수 있다.

그리고 그 이후에 bp를 걸었던 FUN_1400017a0 함수를 실행하면 다음과 같이 플래그의 첫글자가 그려진 것을 확인할 수 있다.

이후의 함수들을 모두 호출하면 다음과 같이 모든 플래그가 그려지게 되는 것을 알 수 있다. (비록 가려져 있긴 하지만…)

이를 통해 플래그를 가리는 함수인 FUN_140002b80 함수가 실행되지 않도록 막으면 정상적으로 플래그를 확인할 수 있을 것임을 알았다.

패치를 하기 위해 다음과 같은 방안을 생각해보았다.

FUN_140002b80 함수 시작 위치 어셈을 ret로 패치
FUN_140002b80 함수를 call 하는 위치 어셈을 nop으로 패치

IDA로 패치하려니 계속 권한 오류가 떠서 x64dbg로 패치했다.
x64dbg에서 패치하려고 하는 주소로 이동한 후 고안한 방법대로 패치를 진행한다.

1. FUN_140002b80 함수 시작 위치 어셈을 ret로 패치

→ 잘 된다.

2. FUN_140002b80 함수를 call 하는 위치 어셈을 nop으로 패치

→ 잘된다.

사실 두 방법 모두 FUN_140002b80 함수의 실행을 방해한다는 측면에서 같은 방식이긴 하다.

그러나 두번째 방법을 사용할 경우 FUN_140002b80 함수가 실행되는 모든 곳에 대해 패치를 해야하니 더 번거롭기 때문에 굳이 이렇게 할거면 첫 번째 방법이 좀 더 나은 선택지인 것 같다는 생각을 했다.

이렇게 패치를 해도 괜찮은 이유는 다음과 같다.

본 프로그램이 레지스터를 이용하여 인자를 전달하는 x64 프로그램이고, FUN_140002b80 함수 역시 함수 내에서 스택을 정리하는 fastcall 호출 규약을 사용한다. 그렇기 때문에 함수 실행과 관련하여 스택을 직접 손봐줘야할 필요가 없다.
다만 함수 내에서 ret를 이용하여 함수를 종료할 경우 함수 내에서 스택을 사용하기 전에 ret를 넣어줘야 가장 최근에 스택에 넣었던 ret 값을 그대로 다시 가져와 원래 위치로 돌아갈 수 있을 것이다.
FUN_140002b80 함수의 리턴값이 코드의 다른 부분에 사용되지 않기 때문에, 별도로 리턴값을 관리해줄 필요 없이 함수 실행만 막으면 된다.

1번과 관련하여 잘못 패치를 하는 상황을 재현해보았다.

여기에서는 FUN_140002b80 함수의 프롤로그 이후 사용할 스택 메모리를 확보한 상황에서 스택 정리 없이 곧바로 ret를 넣은 경우이다.

FUN_140002b80 함수의 프롤로그 실행 시 ret 값에 의하면 본 함수 종료 후 rip는 7FF63BC22C71 값을 가지며 함수를 call 했던 코드의 다음 코드로 돌아가야 한다.

그러나 지금과 같이 스택 프레임 확보를 위해 rsp값을 조정해주고 난 상황에서 ret를 이용하여 곧바로 pop rip를 수행하게 될 경우 dummy 값이 rip로 들어가 이후 정상적인 프로그램 실행에 문제를 일으키게 된다.

[Storage] 저장 장치 구조와 MBR, GPT

Yuta — Sat, 30 Sep 2023 14:54:51 +0900

대게 사용 중인 저장 장치를 덤프 떠보게 되면 다음과 같은 이미지 파일을 획득할 수 있을 것이다.

그리고 이를 FTK Imager와 같은 이미지 분석 도구를 이용하여 확인할 경우 아래와 같은 광경을 보게 될 것이다.

이 중 실제 USB 내 데이터를 확인할 수 있는 위치는 Partition 1의 [root] 폴더이다. 그런데 이 이미지 파일에는 실제 저장된 데이터에 대한 정보 이외에 FAT32 파일 시스템과 관련된 것으로 추측되는 파일들도 있었고, 아래 사진과 같이 File List로는 확인되는 것이 없으나 이미지 파일 자체의 시작 오프셋 위치에서 별도의 hex값도 확인할 수 있었다.

여러 차례 이미지 파일 분석을 돌려보는 과정에서 대체 이 내부의 구조가 어떻게 되어 있길래 이러한 구성을 갖게 되는 것일지 궁금했다. 그리고 이러한 궁금증을 해결하기 위한 리서칭 중 답은 저장 장치의 구조와 관련이 있을 것으로 파악하고 이를 공부하고자 이번 포스트를 작성하게 되었다.

Storage Structure

저장 장치는 기본적으로 다음과 같은 형태를 가진다.

이 구조는 파티션 관리를 위해 MBR을 사용하는 경우에 해당하는 구조이지만, 후반부에 정리된 GPT를 사용하는 구조에서는 조금 다른 형태의 구조를 볼 수 있다. 그럼에도 크게 “저장장치 구조” 라는 범주로 보았을 때, 저장장치 부트 과정에 관여하면서 파티션에 대한 정보를 저장하는 파트와 각 파티션 별로 데이터를 저장하는 파트로 구성되는 점은 공통적으로 확인되었다.

MBR(Master Boot Record)

MBR은 저장장치 단위로 제일 앞에 한번 위치한다. MBR에서는 저장장치가 사용되기 위해 필요한 정보들이 저장되어 있는데, 크게 Boot Code와 Partition Table로 이루어져 있다.

MBR의 파티션 테이블의 경우 최대 4개의 primary partition만 생성 가능한 구조로 이루어져 있다는 점에서 MBR이 GPT로 대체된 이유를 알 수 있다.

MBR의 세부적인 구조는 글의 중반부에서 별도로 다루어진다.

MBR Slack

MBR과 파티션의 VBR이 존재하는 위치 사이에 있는 여유 공간을 가리킨다. 이 공간은 말그대로 여유 공간이기 때문에 악성 코드에 의해 악용되기도 하는 공간이다.

VBR(Volume Boot Record)

VBR은 각 볼륨이 시작될 때 한번씩 위치하는 부분이다. VBR은 해당 볼륨에 액세스 하기 위한 정보를 가지고 있는데, 여기에는 파일 시스템 타입, 부트 코드, 에러 메세지 등이 포함된다. MBR의 파티션 테이블을 통해 부팅 가능한 파티션에 접근하게 되고, 그 후 VBR이 실행된다.

Volume Data

각 볼륨의 데이터가 저장되는 부분이다. 각 볼륨 마다 지정된 파일 시스템 형태로 포맷되어 있으며, 이에 저장된 각 파일은 메타 데이터와 파일 데이터 정보를 가진다. 이러한 구조에 따라, directory 탐색 시에는 메타 데이터 정보를 사용하고, 파일 내용에 접근하면서 파일 데이터 정보가 사용된다.

MBR(Master Boot Record)

초기의 저장 장치에서는 정상적인 부팅을 위해 매 저장 장치의 맨 앞에 위치한 MBR을 사용하였다. 이를 이용하여 장치의 부팅 뿐만 아니라 실제 데이터가 저장되어 있는 볼륨에 접근하기 위한 정보도 관리한다.

MBR Structure Overview

MBR은 다음과 같은 구조로 이루어져 있다.

가장 처음에 부트 코드가 위치해있고, 그 후에는 장치 내 할당된 파티션의 정보를 가진 Partition Table이 위치한다. 이러한 구조를 이용하여 BIOS의 POST(Power On Self Test) 단계 이후 Bootstrap 실행 시 MBR 내 저장된 부트 코드를 읽어올 수 있다.

부트 코드를 위해 할당된 446 바이트 이후에는 곧바로 파티션 테이블이 위치한다. MBR에서 파티션 테이블이 차지하는 크기는 총 64바이트인데, 각 테이블에 대한 정보를 16바이트 크기로 저장한다. 이에 따라 MBR을 채용한 저장 장치의 경우에는 최대 4개의 테이블만을 가질 수 있게 된다.

부트 코드와 파티션 테이블에 이어 2바이트 크기의 Signature를 확인할 수 있다. 이 값은 16진수로 55 AA 값을 가지며 MBR의 끝을 가리킨다.

Partition Table entry

각 파티션을 가리키기 위해 사용되는 파티션 테이블의 entry는 다음과 같은 구조로 이루어져 있다.

Offset 0x0 에 위치하는 Boot Flag는 1바이트의 크기를 가지는 필드이며, 해당 파티션에 할당된 볼륨이 부팅 가능한 상태인지 불가능한 상태인지를 나타낸다. 이 값이 0x80일 경우에는 부팅 가능 상태, 0x00일 경우에는 부팅 불가능한 상태를 가리킨다.

Offset 0x1과 0x5에 위치하며 총 3바이트의 크기로 각각 시작 CHS 주소와 끝 CHS 주소를 가지는 필드가 있다. 이들은 파티션의 위치를 CHS 주소 지정 방식을 사용하여 나타낼 경우에 파티션이 위치하는 처음과 끝 주소를 나타낸다.

Offset 0x4 위치에는 1바이트의 크기를 사용하여 파티션의 유형을 나타내는 필드가 있다. 각 파티션 유형에 따른 값은 아래 링크를 참조하여 알 수 있다.

Partition type - Wikipedia

From Wikipedia, the free encyclopedia Table inside a master boot record The partition type (or partition ID) in a partition's entry in the partition table inside a master boot record (MBR) is a byte value intended to specify the file system the partition c

en.wikipedia.org

Offset 0x8 위치에는 4바이트의 크기로 시작 LBA 주소를 가지는 필드가 있다. 이 필드는 CHS 주소 지정 방식과는 다른 LBA 주소 지정 방식을 사용할 경우의 파티션 시작 위치 주소를 가진다.

이 필드를 사용하여 파티션의 위치를 참조할 경우 파티션의 끝 위치는 Offset 0xC에 있는 필드값을 사용하여 알 수 있다. 이 필드는 해당 파티션에 할당된 크기를 나타내는 필드로 활용될 수 있는데, 정확히는 해당 파티션 내에서 사용 가능한 sector의 개수를 의미하는 필드이다.

이 필드는 4바이트로 표현됨에 따라 한 파티션에서 사용 가능한 sector의 최대 개수가 2^32 개가 되며, 한 sector는 512바이트의 크기를 갖는 것에 따라 계산해보면… 한 파티션 당 최대 2TB의 크기만을 가질 수 있게 된다.

GPT(GUID Partition Table)

GPT는 MBR의 한계를 해결하고자 등장한 구조이다. 최근의 대부분 PC에서는 GPT를 지원하고 있고 BIOS의 개선된 펌웨어인 EFI에서도 GPT를 지원하고 있다. MBR의 한계는 MBR 파트를 통해서도 설명했지만 이를 다시 한번 정리하면 다음과 같다.

최대 4개의 primary partition 생성 가능
각 파티션 당 최대 2TB의 크기 할당 가능

이러한 한계를 GPT는 다음과 같이 개선하였다.

최대 128개의 primary partition 생성 가능
각 파티션 당 최대 8ZB의 크기 할당 가능

뿐만 아니라 GPT는 MBR과는 달리 파티션 정보 이외에 디스크에 대한 다양한 정보들도 함께 저장한다는 특징을 가진다.

GPT Structure Overview

GPT를 채용한 저장 장치의 경우 다음과 같은 구조를 가진다. 앞서 MBR 사용 시 구조에서 몇 가지 사항이 추가된 것을 확인할 수 있다.

https://en.wikipedia.org/wiki/GUID_Partition_Table

GPT는 각 부분을 sector(512바이트) 단위로 할당하여 사용한다.

GPT의 본격적인 구조는 Primary GPT Header 부터 이며, 그 전에 위치한 Protective MBR은 GPT를 지원하지 않는 장치에서 파티션을 접근할 수 있도록 하기 위해 사용된다. 뿐만 아니라 MBR 기반의 legacy 디스크에 의해 GPT 영역이 훼손되는 것을 막기 위한 기능으로도 활용된다. 이 Protective MBR의 경우 항상 LBA0의 위치에 존재한다.

GPT 구조의 하단에서 볼 수 있는 Secondary GPT는 Primary GPT에 문제가 생기는 등의 이슈로 Primary GPT를 사용할 수 없을 때 backup 용으로 사용하기 위한 부분이다.

Primary GPT Header

LBA1에 위치한 Primary GPT Header는 Signature 값을 시작으로 각 파티션의 정보만이 아닌 Disk GUID나 파티션 개수, entry 크기 등의 정보를 함께 관리한다.

Primary GPT Header의 세부 구조는 아래와 같다. Primary GPT Header의 크기는 0x5B에 불과하지만 이를 위해 할당된 크기는 0x200이기 때문에 나머지 부분은 0으로 채워져 있다.

Partition Table array

Primary GPT Header의 offset 0x48에 위치한 주소를 참조하면 partition table array의 시작 위치를 찾을 수 있다. 각 entry별로 일정한 크기를 가지고 있어 순차적으로 각 파티션의 정보를 조회할 수 있다.

Partition Table array의 각 entry의 세부 구조는 아래와 같다.

GPT의 이름이 가진 의미를 여기서 확인할 수 있다. GPT는 파티션 유형 별 GUID를 사전에 정해두고 각 파티션에 해당하는 GUID를 entry에 기입한다. 파티션 유형별로 구분짓기 때문에 같은 유형의 서로 다른 파티션이라고 하더라도 Partition Type GUID 필드는 같은 값을 가지게 된다.

물론 GPT에는 Partition Type GUID와는 별도로 각 Partition에 고유한 GUID도 부여한다. 이를 통해 같은 유형의 파티션이라고 하더라도 각각의 파티션을 구분할 수 있게 된다.

Partition type GUID에 기록될 수 있는 유형의 파티션과 이에 매칭되는 GUID는 아래 링크에서 확인할 수 있다.

GUID Partition Table - Wikipedia

From Wikipedia, the free encyclopedia Computer disk partitioning standard The layout of a disk with the GUID Partition Table. In this example, each logical block is 512 bytes in size and each entry has 128 bytes. The corresponding partition entries are ass

en.wikipedia.org

이외에 Partition Table의 entry 내에 존재하는 Attribute flags라는 필드의 경우, 파티션의 세부 속성을 비트 플래그 형태로 표현하고자 하는 필드이다. 이 필드에서 주로 쓰이는 비트 플래그는 다음과 같다.

Bits	Name	Description
0	Platform required	시스템에 의해 사용되는 파티션. 삭제 또는 수정 시 주의를 요함
1	No Block IO Protocol	UEFI에서 이 파티션에 대한 파일 시스템 매핑 작업을 무시하도록 함.
2	Legacy BIOS bootable
3-47	Reserved	이후 UEFI specification 버전에서 사용될 수 있음을 고려하여 예약된 영역
48-63	Partition type에 따라 다르게 사용	PartitionTypeGUID의 소유자만이 사용할 수 있도록 할당해둔 영역

이 중 Bit 48-63이 일부 type에서 활용되는 예시는 다음과 같다.

Microsoft 사의 Basic Data Partition

Bits	Name
60	Read-only
61	Shadow copy
62	Hidden
63	No drive letter (not automount)

ChromeOS kernel Partition

Bits	Name
48-51	Priority 0: not bootable, 1~15(highest)
52-55	Tries remaining
56	Successful boot flag

Windows Prefetch 개요와 File Format

Yuta — Mon, 18 Sep 2023 17:28:10 +0900

Prefetch 개요

프리패치는 Windows 운영체제에서 소프트웨어 활동과 관련된 정보를 저장하기 위해 사용하는 메모리 관리 기법 중 하나이다. 이를 사용할 경우 자주 사용될 프로그램들을 미리 메모리에 로드해두기 때문에 더 빠른 실행이 가능하다.

프리패치는 파일 형태로 데이터를 저장하는데, 이렇게 저장된 파일은 다음의 용도로 활용될 수 있다.

Windows 및 응용 프로그램 시작 성능 향상
응용 프로그램(바이러스)의 행위 연구, 포렌식 분석

물론 prefetch의 동작 방식 때문에 오히려 불필요하게 RAM을 사용하게 될 수 있어 이미 PC 성능이 좋거나 SSD를 사용하고 있는 경우에는 RAM 공간 확보를 위해 비활성화를 추천하기도 한다.

그렇기에 prefetch는 무조건 활성화되어 있지 않을 수 있으며 다음의 레지스트리 경로를 이용하여 prefetch 활성화 여부를 확인할 수 있다.

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters [EnablePrefetcher]

EnablePrefetcher의 값은 0~3 중 하나로 설정할 수 있으며, 각각의 값은 다음과 같은 의미를 가진다.

0: Prefetch 사용 안함
1: ALP만 사용
2: BP만 사용
3 (기본값): ALP와 BP 모두 사용

여기에서 확인할 수 있듯이 prefetch에는 다음의 두 가지 유형이 존재한다. 기본적으로 두 가지를 모두 사용하도록 설정되어 있으나, 필요에 따라 레지스트리의 값을 변경하여 원하는 옵션으로 사용할 수 있다.

ALP(Application-Launch Prefetching): 사용자가 자주 사용하는 응용프로그램의 정보를 prefetching 하는 것으로, 응용 프로그램의 실행 속도를 높일 수 있다.
BP(Boot Prefetching): 부팅 시 사용하는 파일이나 프로그램의 정보를 prefetching 하는 것으로, 부팅 속도를 높일 수 있다.

Prefetching된 데이터는 파일 형태로 저장되어 있다가, 부팅 시 저장해둔 prefetch 파일을 메모리에 로드해두고, 실제 프로그램 사용 시 메모리에서 해당 데이터를 불러와 사용할 수 있게 한다. 저장된 프리패치 파일은 %SystemRoot%\Prefetch 폴더에서 확인할 수 있다.

(Windows 10 기준) Prefetch 폴더 내 저장된 파일 및 폴더 유형은 다음과 같다.

ReadyBoot
Layout.ini
Prefetch Files (.pf)

ReadyBoot 폴더는 Boot Prefetch에 필요한 파일들을 저장하는데 사용된다. 매 부팅 시 Trace#.fx 이름으로 부팅에 필요한 파일 및 데이터 정보가 포함된 파일이 생성된다. 이 파일은 ReadyBoot 폴더 내에 생성되며 가장 최근에 생성된 파일을 기준으로 최대 5개까지 저장된다. 이외에도 1개의 rblayout.xin 파일이 ReadyBoot 폴더 내에 저장되는데, 이 파일을 이용하여 ReadyBoot 시 필요한 정보 및 캐시 파일을 관리한다.

Layout.ini 파일에서는 프리패치 버전과 프리패치 파일의 목록을 확인할 수 있다. Layout.ini 파일은 부팅이나 응용 프로그램 시 참조되는 순서대로 파일의 경로가 기록되며, 약 3일 마다 내용이 업데이트된다. 그렇기 때문에 실제 Prefetch 폴더에 저장된 prefetch 파일의 저장 여부와 일치하지 않을 수 있으며, 오래전에 실행된 적 있는 파일에 대한 항목도 존재할 수 있다.

Prefetch 파일은 한번 이상 실행된 적 있는 응용 프로그램에 대한 데이터가 저장된다. 이러한 점을 이용하여 PC에서 사용자의 응용 프로그램 사용 흔적 또는 악성 프로그램 실행 기록을 추적할 수 있다.

각 프리패치 파일에 포함되는 정보는 다음과 같다.

프리패치 파일의 MAC 타임스탬프
프리패치 파일의 크기
프리패치 파일에 해당하는 프로세스
파일이 실행된 volume 또는 논리 드라이브 경로
프로그램 실행 횟수
프로그램의 마지막 실행 시간에 대한 타임스탬프
프리패치 파일에 의해 로드된 추가 파일

여기에서 파일의 생성 시각과 수정 시각 정보는 각각 다음과 같은 의미로 해석될 수 있다.

파일의 생성 시각: exe 프로그램 최초 실행 시각
파일의 수정 시각: exe 프로그램의 마지막 실행 시각

프리패치 파일은 Prefetch 폴더 내에 모두 존재하며, prefetch 파일의 개수가 운영체제 별 최대 제한 개수에 도달하면 가장 오래전에 실행된 순으로 파일을 삭제한다. 운영체제별로 유지하는 최대 prefetch 파일 개수는 다음과 같다.

Windows XP, 7: 128개
Windows 8, 10: 1024개

Prefetch File Format

Prefetch 파일의 file format은 파일의 압축 여부에 따라 두 가지 형태를 가진다.

먼저 압축되어 있는 prefetch 파일의 구조는 다음과 같다.

Offset 0x00 (4bytes): File Signature (4D 41 4D 04)
Offset 0x04 (4bytes): Uncompressed Data Size
Offset 0x08 ~: Compressed Data

Prefetch 파일의 자세한 정보를 얻기 위해서는 압축된 내용을 풀어야 한다. Windows prefetch 압축에는 LZXPRESS Huffman 압축 방식이 사용되며, 원본 내용을 보기 위해 Github에서 공유되고 있는 압축 해제 코드를 이용하여 해제하였다.

압축되지 않은 prefetch 파일의 형식은 크게 File Header와 File Body로 구분할 수 있다. File Header는 운영체제에 관계없이 공통된 구조를 가지지만 Body의 경우 운영체제 버전에 따라 서로 다른 형식을 가진다.

File Header: offset 0x00 (84bytes)
File Body: offset 0x54 ~

먼저, 버전에 관계없이 공통되는 부분인 File Header는 다음과 같은 구조를 가진다.

Offset 0x00 (4bytes): Format Version (Little-Endian)
Offset 0x04 (4bytes): File Signature (53 43 43 41)
Offset 0x0C (4bytes): File Size (Little-Endian)
Offset 0x10 (60bytes): File Name (실행 파일 이름)
Offset 0x4C (4bytes): Prefetch Hash (Prefetch 파일 이름에 기재된 해시값)
- Prefetch Hash는 실행 파일 경로에 대한 해시값을 가지며 Windows 버전에 따라 서로 다른 해시 함수를 사용한다.
  - Windows XP, 2003: SCCA XP hash function
  - Windows Vista, 10: SCCA Vista hash function
  - Windows 2008, 7, 2012, 8: SCCA 2008 hash function

Format Version으로 사용되는 값의 종류는 총 4가지이며, 각각은 다음과 같은 정보를 가리킨다.

0x11: Windows XP, Windows 2003
0x17: Windows Vista, Windows 7
0x1A: Windows 8.1
0x1E: Windows 10

Prefetch 파일은 기재된 format version에 따라 서로 다른 구조를 가진다. Windows 11도 Windows 10 비슷한 부분이 많은 운영체제임에 따라 0x1E version을 사용한다. 다음은 각 버전에 따른 전체 Format 구조이다.

0x11: Windows XP, Windows 2003

0x17: Windows Vista, Windows 7

0x1A: Windows 8.1

0x1E: Windows 10

위 format을 통해 알 수 있는 것과 같이, Windows 10과 8.1의 경우는 최근 실행 시간을 가장 최근 시간을 기준으로 8개까지 저장한다는 특징을 가진다.

여기까지가 각 운영체제별로 가지는 기본적인 prefetch의 파일 포맷이었다. 이후의 내용은 포맷 내 각 필드가 가리키는 값을 추적하는 과정을 정리하였다.

File metrics array

각 프리패치 파일별로, 해당 파일을 실행시키기 위해 필요한 다른 파일들을 함께 기록해두는데 이에 대한 내용은 File metrics array로 관리된다. File metrics array 내에 있는 각 entry를 탐색하기 위해서는 File metrics array offset과 Filename strings offset을 필요로 한다.

File metrics array는 File metrics array offset 필드에 정의된 offset 위치에서 시작한다. File metrics array의 각 entry는 일정한 형식을 갖추고 있는데, 이 형식은 운영체제에 따라 약간의 차이를 가진다.

0x11: Windows XP, Windows 2003

0x17, 0x1A, 0x1E: Windows Vista, Windows 7, Windows 8.1, Windows 10

Unknown의 경우는 확실하지 않은 값이므로 그 쓰임을 명시해두지 못했지만
Windows 7, 8, 10에서의 Unknown 간에는 다음과 같은 규칙을 가지고 있음을 확인하였다.

Unknown1은 초기값 0에서 시작하여 다음 entry로 넘어갈 때마다 Unknown2 만큼 더해진 값을 갖는다.
2번째 필드와 3번째 필드는 매 entry 내에서 서로 동일한 값을 갖는다.

이러한 필드를 제외한 채, Filename string offset과 Filename string number 필드값을 이용하면 각 entry에 해당하는 파일명을 찾을 수 있다. 다음은 Windows 10 환경의 프리패치 파일에서 직접 entry 내 파일명을 확인하기까지의 과정이다.

Volumes information

Prefetch 파일을 통해 이 실행 파일이 어느 볼륨에서 실행된 것인지 확인할 수 있으며, 파일에 할당된 file reference를 실행된 볼륨의 데이터와 매핑시켜볼 수 있다.

Volumes information 데이터 추적도 기본 file format의 필드로부터 시작한다. 파일의 시작 지점으로부터 offset 0x6C 위치에서 4바이트 크기의 volume information offset 정보를 확인할 수 있다. 이 offset을 따라가면 volume information entry를 찾을 수 있는데, 여기서의 entry 구조 역시 운영체제 버전에 따라 다르다.

0x11: Windows XP, Windows 2003

0x17, 0x1A: Windows Vista, Windows 7, Windows 8.1

0x1E: Windows 10

다음은 Windows 10 환경의 프리패치 파일에서 직접 entry 내 볼륨 정보를 확인하기까지의 과정이다.

요약

Windows의 Prefetch는 자주 사용될 프로그램들을 미리 메모리에 로드해두어 빠른 실행을 가능하게 하는 메모리 관리 기법 중 하나
실행된 적 있는 프로그램은 프리패치 파일로 남기 때문에 응용 프로그램(바이러스)에 대한 행위 연구, 포렌식 분석 활용 가능
Prefetch는 비활성화 설정도 가능하기 때문에 무조건 남는 아티팩트가 아니며, 안티 포렌식 목적으로 실행 후 프리패치 파일을 삭제할 수도 있음
최근 운영체제의 prefetch 파일의 경우 LZXPRESS Huffman 압축이 되어있는 경우가 많아 내용 확인 시 압축 해제 또는 전용 도구 필요

참고 자료

Prefetch Files in Windows, geeksforgeeks, 2020.10, https://www.geeksforgeeks.org/prefetch-files-in-windows/
Prefetch는 무슨 서비스일까? 켜고 끄는 방법은?, tistory, 2019.12, https://gbworld.tistory.com/1236
Windows Prefetch File (PF) format, Github, 2023.07, https://github.com/libyal/libscca/blob/main/documentation/Windows%20Prefetch%20File%20(PF)%20format.asciidoc
Inside the Windows Vista Kernel: Part 2, Microsoft TechNet Magazine 2007, 2007.03, https://learn.microsoft.com/en-us/pr\evious-versions/technet-magazine/cc162480(v=msdn.10)?redirectedfrom=MSDN#s5
Thoughts (and questions) on prefetch and layout.ini, trapframe.github.io, 2014.09, https://trapframe.github.io/thoughts-and-questions-on-prefetch-and-layout-ini/
w10pfdecomp.py, Github, 2015, https://gist.github.com/dfirfpi/113ff71274a97b489dfd

제2회 랜섬웨어 레질리언스 컨퍼런스 후기 및 정리

Yuta — Wed, 13 Sep 2023 03:09:05 +0900

이번으로 2회차를 맞이하는 랜섬웨어 레질리언스 컨퍼런스에 다녀왔다.
과학기술정보통신부에서 주최하고 한국인터넷진흥원에서 주관하는 컨퍼런스였으며, 9월 12일 화요일 낮에 진행되었다.

보통 평일 낮시간은 교육이나 다른 활동을 하느라 바쁘기 마련인데, 갑자기 왜 다녀오겠다는 생각을 했을까?

이유는 생각보다 간단했다.

평소 랜섬웨어에 대한 사전 대응책으로는 데이터 백업을, 사후 대응책으로는 랜선 뽑기만을 알고 있었다. 그런데 이것으로 컨퍼런스를 개최한다는 부분에서 내가 모르는 다른 기막힌 대응책이 있는 것일지에 대한 궁금증이 생겼다.

이에 더해 프로그램 목록에서 발견한 랜섬웨어 무력화 부분과 데이터 복구 전략 파트가 호기심을 자극하였고, 결국 사전등록 첫날 바로 등록 신청을 하게 되었다.

후기라면..

호기심으로 참석한 컨퍼런스였기에 사전에 랜섬웨어에 대한 많은 정보를 가지고 있었던 상태가 아니었다.

그러나 이번 컨퍼런스를 통해 랜섬웨어의 동작 방식과 암호화 과정 같은 기본적인 내용부터,
랜섬웨어 공격에 의해 암호화된 파일을 랜섬 지불 없이 자체적으로 복구하기 위한 여러 흥미로운 관점들,
그리고 랜섬웨어에 대응하기 위한 정책까지 한 번에 알아갈 수 있었던 유익한 시간이었다.

또한 컨퍼런스에 참석하기 전에 가졌던 호기심과 같이, 결과적으로는 백업을 이중, 삼중으로 해두고 망분리까지 시키는 등... 이미 알고 있는 기본적인 방법부터 충실히 하는 것이 현재로서는 랜섬웨어로부터 자산을 보호할 수 있는 방법이라는 생각을 하게 되었다. 랜섬웨어에 감염되었을 때 이를 자체적으로 복구하기 위한 기술들은 연구가 활발히 이루어지고 있으나 아직 연구 초기 단계이고 한계를 가지는 부분들도 존재한다. 또한 공격자들은 항상 방어자들의 한발 앞에서 새로운 공격 기법, 암호화 기법 등을 시도하기 때문에 좋은 도구를 만들더라도 이것이 안정화되기까지는 사전 방어에 계속 힘쓰는 것이 중요할 것이라 느꼈다.

이번 컨퍼런스를 통해 랜섬웨어에 대한 관심도가 높아져, 향후에 리버싱 공부를 더 하고... 악성코드 분석을 학습하게 된다면 랜섬웨어도 분석해보고 싶다는 생각을 하게 되었다 :)

+ 덧붙이자면.. 랜섬웨어 공격자들의 행태를 보다 보니 단순히 랜섬웨어 공격만 하고 끝나는 게 아니라, 랜섬웨어 공격 이후 시스템에 백도어를 심어 피해자가 공격에 어떻게 대응하는지 지켜보는 경우도 있었다. 피해자가 만일 돈을 지불하려 하지 않고 복구를 하려고 하는 등의 조짐이 보이면 2차 공격을 하기도 한다는데... 이러한 경우도 있기 때문에 보다 더 은밀하고 안전한 방법으로 랜섬웨어에 대응하기 위한 방안이 필요해 보였다. 이렇게 생각하니 레질리언스에 관한 컨퍼런스를 열어 함께 논의하는 장을 만들만한 것 같다는 생각이 들었다!

이후 내용은 각 강연 마다 들으면서 메모해 둔 내용들이니, 진행된 내용이 궁금하다면 참고해도 좋을 것 같다. 현장에서는 발표자료를 책자형태로 제작하여 배부해 주었는데 이를 별도로 웹 상에도 게시해 줄지는 잘 모르겠다..

[세션A] 랜섬웨어 공격에 대한 국내외 대응 동향

랜섬웨어 공격 동향

RaaS형 랜섬웨어 생태계
크로스 플랫폼 랜섬웨어 다수 발견
주로 GoLang, Rust 언어로 개발
사회 기반 시설, 일상 생활과 밀접한 서비스(콜택시)를 대상으로 공격 타겟 변화

랜섬웨어 대응 정책

국외
- 악의적으로 사용되는 가상회폐 거래소에 대한 제재
- 랜섬웨어 공격 그룹 자체 무력화
- 랜섬웨어 관련 범죄자 검거 및 제재

국내
- 국가중요시설-기업-국민 수요자별 선제적 예방
  : 백업 지원, 대응 역량 체크 서비스 지원 등
- 정보공유-피해지원-수사 등 사고 대응 지원
- 진화하는 랜섬웨어에 대한 대응 역량 제고
  : 랜섬웨어 공격 형태 분석, 대응 기술력 확보

랜섬웨어 복구 방안

랜섬웨어의 주된 특징이 암호 기술을 이용한다는 것에서 착안하여, 암호 기술의 암호학적 취약점에 기반한 분석 진행

Magniber, LooCipher, Immuni, Hive v1~v4에 대한 랜섬웨어 복구 분석 사례 소개
이 중 Hive v1 ~ v4의 경우 KISA에서 최초로 복구 도구 개발
KISA에서 랜섬웨어 국제 협력 프로젝트인 노모어랜섬(NoMoreRansom, NMR)에 약 160여종의 랜섬웨어 복구 도구 배포 중
KISA에서 복구 도구 개발 여부에 대한 검색 서비스 지원 예정

앞으로의 방향

매년 400개 이상의 신/변종 랜섬웨어가 발견되고 있어 분석량이 한계치에 도달함
-> 기존 랜섬웨어와의 유사도 분석을 통해 복구, 분석 자동화 도구 개발
사용자 중심의 피해 복구 지원
랜섬웨어 복구 협력 체계 구축 (레질리언스 확보)

[세션A] 산업계 랜섬웨어 침해동향과 레질리언스 전략

디지털 환경의 경영 리스크 분석

랜섬웨어 공격 시 문서 유실 문제 뿐만 아니라 문서 유출 문제도 함께 발생
중요 문서가 유출될 경우 이로 인한 리스크가 심각함
향후의 모든 악성코드가 랜섬웨어 형태로 변화할 것이라 전망

해킹형 랜섬웨어 공격대상 분석

주공격 대상: 코스피 & 코스닥 상장사
업종별 해킹형 랜섬웨어 공격 대상(2년간): 제조업, 병원, 제약사, 특허, 로펌
해커의 최종 목적: 금전 취득, 사이버 테러

2023년 랜섬웨어 공격기법 분석

해킹형 랜섬웨어 공격 프로세스

악성 메일 / 특정 WEB
백도어 감염
내부 공격
데이터 탈취
백업 삭제 (RDP를 경유하고, 보안 SW를 제거하여 서버에 접근)
암호화
데이터 탈취
탈취한 데이터를 다크웹에 게시
탈취된 데이터 구매

해킹형 랜섬웨어 공격기법의 기술적 진화

RaaS 형태의 플랫폼을 통해 쉽게 랜섬웨어를 구매할 수 있어 일반 해커들도 랜섬웨어 공격을 수행할 수 있다.
서비스 플랫폼을 제작하고 운영하기 위해 그룹형태로 조직을 운영한다. (ex. Conti, LockBit)

3단계 랜섬웨어 레질리언스 전략

1단계

보안 백업 체계 구축
랜섬웨어 전용백신 구축
개인사용자 보안수칙 및 주기적 교육

2단계

회사 정보시스템 보안 취약점 점검
해킹 시 회사 피해 범위와 법적 문제 시뮬레이션
: 정보자산 보유현황 실사
전사 데이터 거버넌스 정책수립 및 시스템 도입
: 데이터 자산 보유현황 실사

3단계

제로트러스트 보안전략 방어

[세션B] 랜섬웨어 무력화를 통한 신속한 감염파일 복구 기술

랜섬웨어의 파일 감염과 협상 과정

1단계: 파일 암호화

대칭키 암호화 기법을 사용하여 파일 암호화

2단계: 파일 키 암호화

비대칭키 암호화 기법을 사용하여 파일 암호화에 사용된 키 암호화
복호화를 위한 키 획득을 위해 공격자의 개인키 확보 필요

3단계: 협상과 복구

랜섬 지불
공격자의 개인키 내장된 복호화 툴 확보
공격자의 개인키를 이용하여 파일 키 복호화
복호화된 파일 키를 이용하여 파일 복구

복제 키를 이용한 감염파일 복구 기술

Key Idea: 랜섬웨어의 파일 암호화 시 사용되는 파일 키를 가로채자

단계

시스템에 Nubeva Key Sensor 설치
: 시스템에서 발생하는 신뢰할 수 없는 암호화 작업을 실시간으로 탐지
- NUBEVA SKI (대칭키 복사 기술) 사용
파일 키를 식별하고 가로채기
: 메모리 상에서 파일 암호화 시 사용되는 키 식별 및 가로챔
랜섬 비용 지불 없이 감염 파일 복구

-> 아직 기술적, 상황적 제약 상황이 있어 특허만 있는 상태라고 한다.

[세션B] 랜섬웨어와 딥/다크웹의 연관성 분석 및 추적

IAB(Initial Access Broker): RaaS 형태의 랜섬웨어 생태계에서 랜섬웨어 구매자 겸 미래의 공격자인 Affiliates가 공격의 첫발을 내딛을 수 있게 해주는 인물

접근 권한 획득 방법

다크웹에서 구매
Stealer campaign
취약점 이용(ex. Conti, Groove 유출 사이트)
Phishing campaign
내부자 위협

RaaS(Ransomware-as-a-Service)

정의와 개념

랜섬웨어를 개발하고 배포하기 위한 서비스 모델
랜섬웨어 개발에 필요한 도구와 인프라 제공
웹 플랫폼 형태로 제공되어, 쉽게 랜섬웨어 구매 및 사용 가능

제공 기능

RaaS 플랫폼
- 랜섬웨어 개발 및 배포에 필요한 모든 도구와 기능 제공
- 배포 시 스팸 메일, 악성 링크, exploit kit 등 다양한 공격벡터 사용
- 결제 처리 및 금전 거래 관리, 해독 키 관리, 복호화 서비스 등의 기능 제공

구독자
- 랜섬웨어의 설정, 암호화 방법, 대상 시스템 및 암호 해독 키 관리 등 설정 가능

[세션B] 블록체인(가상자산)을 통해 바라본 랜섬웨어 생태계와 온체인 분석의 중요성

블록체인 데이터를 통한 랜섬웨어 동향

Big game hunting 형태로 변화, 랜섬웨어 지불액 증가
랜섬웨어 종류의 증가, 수명 감소

블록체인 인텔리전스와 식별

가상자산 주소 자체에는 대상을 특정할 수 있는 어떠한 정보도 없다.
오로지 일련의 트랜잭션 단계를 이용하여 식별해야 한다.
이러한 이유로 온체인과 오프체인 정보를 조합하여 온-오프체인 간의 공통 pivot을 추려내 활용해야 한다.
(온체인 중간에 위치한 정보로는 공격자 식별이 어렵다. 이를 현금화 하는 과정에서 사용된 계정 정보 등을 이용하여 대상을 특정할 수 있다.)

블록체인과 사이버 킬체인

암호화폐 중심의 사이버 범죄가 증가함에 따라 공격자들은 가상 자산을 이용하여 킬체인의 각 단계를 수행한다.
온체인에서의 사이버 범죄 TTPs
온체인에서 식별 가능한 랜섬웨어 리브랜딩
Initial Access Broker를 식별 가능하게 하는 트랜잭션 형태

[세션C] 매그니베르 랜섬웨어 분석 사례 및 동향

매그니베르 랜섬웨어의 변종 발생 과정 (매그니베르 역사..?)

매그니베르 랜섬웨어에서 백신 우회를 위해 사용하는 기술
- NTFS 파일 시스템 내 데이터 스트림을 추가하는 방식으로 악성 파일 은폐
- 파일리스 기법: 정상 프로세스 실행 및 기존 실행되고 있는 프로세스에 악성 DLL 삽입
  -> 취약점 자체에 대한 행위 기반 탐지로 효과적인 탐지 가능
- 지속성 탐지 우회: 악성 행위 랜덤화 (행위 기반 탐지 우회)

[세션C] 손실에서 회복까지: 랜섬웨어 공격 이후 데이터 복구 전략

랜섬웨어 감염 후 데이터 특징

전체 암호화 수행
- 암호화된 파일의 엔트로피 측정 시 원본 파일과 불일치하는 경우가 많아 비교 및 분류 가능
간헐적 암호화 수행
- 암호화된 파일의 엔트로피 측정 시 원본 파일과 엔트로피가 유사
- 전체 암호화를 진행한 것보다 데이터 암호화 속도가 빠름
- 최근 랜섬웨어에서 자주 사용되는 암호화 방법 (ex. Black Basta, Hive)
- 파일 내에서 암호화 영역과 비암호화 영역이 번갈아가며 존재한다. 비암호화 영역의 크기는 해당 파일의 전체 크기와 관계된다.

암호학적 데이터 복호화 방안

개인키 획득
고정된 암호키 사용
메모리 내 잔여 데이터 이용
잘못된 알고리즘 사용
취약한 암호 알고리즘 사용

시스템적 데이터 복구 방안

백업 기반 데이터 복구
- 백업이 되어 있던 부분의 데이터만 복구 가능
- 백업을 했다고 하더라도 공격자에 의해 볼륨 복사본 VSC가 파괴된 경우 복구 불가능

파일 시스템 기반 데이터 복구
- 원본 파일을 덮어씌우는 식으로 암호화하는 방식 -> 복구 불가능
- 원본 파일을 유지한 채 이를 읽어 암호화한 새로운 파일을 생성하고 원본 파일을 삭제하는 경우 -> 경우에 따라 복구 가능
  : TRIM 또는 삭제 영역의 디스크가 사용되어 다른 데이터로 덮어씌워진 경우 복구 불가
- 원본 파일을 읽고 암호화한 상태로 덮어씌운 후 원본 파일 삭제 -> 복구 불가능

파일 구조 기반 데이터 복구
- 간헐적 암호화 방식에서 일부 데이터는 암호화되지 않은 상태로 존재함. 이 부분만 추출하여 최대한.. 원본 파일 복구 시도
  : CyberArk 업체의 White Phoenix 도구
- 복구 가능 범위: word, excel, ppt, zip, pdf
  -> 하나의 파일 내에 여러 파일 데이터가 담긴 형태
  - 온전히 복구되는 것은 아닐테고, 간헐적 암호화 방식 중 비암호화 영역에 운좋게 위치한 데이터에 한해 복구 가능하다.