Security Note

기본적으로 Windows OS에서 등록된 자동 실행 프로그램은 Run 레지스트리를 통해 확인할 수 있는 것으로 알고 있었다. 그리고 실제로 레지스트리를 통해 자동 실행이 되도록 설정된 프로그램을 확인할 수 있었다.

그러나 시스템이 등록된 것으로 인식하는 자동 실행 프로그램 중 레지스트리 내에서 확인할 수 없는 경우도 존재했다. 그리하여 왜 일부 프로그램만이 레지스트리에서 확인되며, 그렇기 않은 경우도 존재하는지에 대해 테스트를 통해 살펴봤다.

기본적으로 레지스트리 상에서 자동 실행 프로그램 리스트를 확인할 수 있는 위치는 아래와 같다.

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce

이 위치에는 아래와 같이 실행할 프로그램의 경로가 기록되어 있다. 여기에 기록된 프로그램들은 시스템 부팅 시 자동으로 실행된다.

이외에도 Windows 에는 [시작 프로그램] 폴더를 통해 자동 실행 프로그램으로 등록할 수도 있다. 이 경우 아래 경로의 폴더 내에 등록하고자 하는 프로그램의 바로가기(LNK) 파일을 넣어두면 이후 부팅 시부터 적용되어 자동으로 실행된다.

• C:\Users\{USER}\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

이후 진행한 테스트에서는 이 두 가지 아티팩트를 중심으로 어떤 식으로 남는지 확인하였고, Windows 7과 Windows 11 운영체제를 사용하여 테스트하였다.

대게 특정 프로그램을 자동 실행 프로그램으로 등록하기 위해, 프로그램 설치 단계에서 아래와 같은 체크박스 옵션을 사용하여 설정하고는 한다. 이러한 방식으로 자동 실행을 등록한 경우에는 어떤 식으로 아티팩트가 남을까?

Windows 7

Windows 7에서는 시스템 구성 창의 [시작 프로그램] 탭에서 설치한 프로그램에 대해 두 가지 항목을 기록하고 있는 것을 볼 수 있다. 

하나는 HKLM key 하위에 있는 Run 레지스트리를 가리키는 항목이고, 다른 하나는 [시작 프로그램] 폴더를 가리키는 항목이다. 각각의 위치를 직접 확인하여 실제로 존재하는지도 확인하였다.

Windows 11

Windows 11에서는 자동 실행 프로그램을 확인하기 위해 시스템 구성 창이 아닌 작업 관리자로 가야한다. 이 곳에서 시작 프로그램으로 등록된 Everything을 확인할 수 있다. 

그러나 Windows 11에서는 Windows 7에서와는 다르게 [시작 프로그램] 폴더 내에서 등록된 프로그램의 LNK 파일을 찾을 수 없었으며, Run 레지스트리에만 등록되어 있는 것을 볼 수 있었다.

정리

• Windows 7: Run 레지스트리와 [시작 프로그램] 폴더 모두 남는다.
• Windows 11: Run 레지스트리에는 남지만 [시작 프로그램] 폴더에는 남지 않는다.

그렇다면 설치 프로그램을 이용하지 않고 Run 레지스트리에 직접 기록할 경우, 이것이 시스템에 어떻게 인식이 되며 [시작 프로그램] 폴더와는 어떤 관계를 가질까?

Windows 7

Windows 7의 Run 레지스트리에 직접 등록하고자 하는 프로그램의 실행 경로를 등록하였다.

그러자 곧바로 시스템 구성 창에서 이를 확인할 수 있었다. 이 경우에는 레지스트리에만 등록한 것대로 레지스트리 경로에 대해서만 등록되어 있으며, [시작 프로그램] 폴더 내 LNK 파일과 이를 참조하는 시스템 구성 항목은 없었다.

그러나 이렇게만 등록되어 있어도 부팅 시 자동으로 프로그램이 실행되는데에는 문제가 없었다.

Windows 11

Windows 11에서도 Run 레지스트리에 직접 등록하고자 하는 프로그램의 실행 경로를 등록하였다.

이 경우에도 [시작 프로그램] 폴더는 빈 폴더인 상태 그대로였으나, 작업 관리자 내 등록된 시작 프로그램 목록 상에서는 레지스트리에 등록한 프로그램이 정상적으로 확인이 되었고, 부팅 시에도 이것이 적용되어 자동 실행되었다.

정리

Windows 7과 Windows 11에서 모두 직접 추가한 레지스트리만 유지되고 [시작 프로그램] 폴더 내 항목에는 변화가 없었다. 그럼에도 시스템에서 해당 프로그램을 자동 실행 프로그램으로 인식하는데에는 문제가 없었으며, 실제 부팅 시에도 정상적으로 자동 실행이 이루어졌다.

이번에는 [시작 프로그램] 폴더에만 LNK 파일을 추가하고 레지스트리는 수정하지 않는 방법으로 테스트하였다.

Windows 7

설치 프로그램에서 자동으로 추가한 LNK 파일과 같이 [시작 프로그램] 폴더 내에 이를 넣었다.

그러자 시스템 구성 창에서 이를 정상적으로 인식하고 참조하고 있음을 확인할 수 있었다.

그러나 Run 레지스트리에는 변화가 없었다. 그럼에도 불구하고 부팅 시 해당 프로그램이 자동으로 실행되는데에는 문제없었다.

Windows 11

Windows 7에서와 같이, 추가하고자 하는 프로그램의 LNK 파일을 [시작 프로그램] 폴더 내에 넣었다.

그러자 Windows 7에서와 마찬가지로, Run 레지스터에는 변화없이 시스템의 작업 관리자에서만 이를 인식하고 등록되어 있는 것을 확인할 수 있었다.

정리

Windows 7과 Windows 11에서 모두 직접 추가한 [시작 프로그램] 내 LNK 파일만 유지되고, Run 레지스트리 내 항목에는 변화가 없었다. 그럼에도 시스템에서 해당 프로그램을 자동 실행 프로그램으로 인식하는데에는 문제가 없었으며, 실제 부팅 시에도 정상적으로 자동 실행이 이루어졌다.

결과

자동 실행 프로그램을 등록하기 위해서는 프로그램 설치 단계에서 옵션을 설정하는 방법과 Run 레지스트리에 추가하는 방법, 그리고 [시작 프로그램] 폴더 내에 LNK 파일을 추가하는 방법을 사용할 수 있다.

설치 단계에서 옵션을 사용하여 설정하는 경우에는
Windows 7의 경우 Run 레지스트리와 [시작 프로그램] 폴더 모두에 흔적이 남았다.
그러나 Windows 11에서는 Run 레지스트리에만 흔적이 남고 [시작 프로그램] 폴더 내에는 흔적이 남지 않았다.

Run 레지스트리나 [시작 프로그램] 폴더 내에 직접 참조를 등록하는 방식으로 자동 실행 프로그램을 등록할 경우에는
어떠한 경우를 사용하더라도 이를 시스템에서 정상적으로 인식하고 동작하는데 문제가 없었다.
그러나 Run 레지스트리와 [시작 프로그램] 폴더 내 항목은 각각 독립적으로 작동하여, 서로의 위치에 자동으로 추가된 항목을 동기화하지 않는다. 따라서 수동으로 등록한 위치에만 흔적이 남고 그렇지 않은 위치에는 흔적이 남지 않는다.

이러한 이유로 사고 분석 시 자동 실행 프로그램 항목을 살피기 위해서, 레지스트리만 확인할 것이 아니라 [시작 프로그램] 폴더 수동 등록과 같은 다른 방법의 아티팩트도 함께 확인하고 교차검증 하는 것이 바람직해 보인다.

침해 이미지를 분석할 때 시스템이나 사용자에 대한 정보를 조사하기 위해 항상 레지스트리를 살피고는 했다.

그리고는 그 때마다 필요한 레지스트리만을 검색하여 보는게 다였는데, 이 참에 한번 정리해야겠다 싶어 글을 작성하였다.

Registry 란?

Registry는 Windows 운영체제에서 응용 프로그램과 시스템이 설정 데이터를 쉽게 저장하고 검색할 수 있도록 하기 위한 계층형 데이터베이스이다.

Registry는 계층형 데이터베이스인만큼 트리 형태로 구성되어 있다.
트리의 각 노드는 key라고 하고, 각 key는 subkey를 가질 수도 있고 value라는 데이터를 가질 수도 있다.

이를 레지스트리 편집기 상에서 보면 아래 이미지와 같다.
HKEY_LOCAL_MACHINE key는 HARDWARE, SOFTWARE 등과 같은 subkey를 가질 수 있으며, 이 중 SOFTWARE key는 다시 Bandizip 이라는 subkey를 가진다. 이 subkey는 AutoReport, Edition 등과 같은 value를 가지면서 동시에 Capabilities와 같은 subkey를 가진다.

Predefined Keys

이렇듯 레지스트리 내에는 수많은 key들이 존재하는데, 이 중 운영체제에 의해 미리 정의된 key가 있다. Microsoft 공식 문서에 의하면 미리 정의된 key의 종류는 Windows 버전에 따라 다를 수 있다고 한다. 확인해본 버전 중 Windows XP 부터 11까지는 다음의 5개의 predefined key를 가진다.

1. HKEY_CLASSES_ROOT (HKCR)
2. HKEY_CURRENT_USER (HKCU)
3. HKEY_LOCAL_MACHINE (HKLM)
4. HKEY_USERS (HKU)
5. HKEY_CURRENT_CONFIG (HKCC)

HKEY_CLASSES_ROOT

ProgID, CLSID, IID와 같은 파일 이름 확장자 정보와 COM 클래스 등록 정보를 가지는 key이다. HKLM과 HKCU에도 이 정보가 담겨져 있으나, 두 군데에 저장된 정보의 병합된 결과가 이 key의 하위에 저장한다.

• HKLM\Software\Classes: 로컬 컴퓨터 내 모든 사용자에게 적용될 수 있는 정보
• HKCU\Software\Classes: 로컬 컴퓨터 내 현재 사용자에게만 적용될 수 있는 정보

HKEY_CURRENT_USER

현재 로그인한 사용자의 기본 설정 정보를 가지는 key이다. HKU key의 현재 사용자 정보와 동일한 정보를 가진다.

• 설정 정보: 환경 변수 설정, 프로그램 그룹에 대한 데이터, 테마, 프린터, 네트워크 연결, 응용 프로그램 기본 설정 등

HKEY_LOCAL_MACHINE

컴퓨터의 물리적 상태 정보를 가지는 key이다.

• 물리적 상태 정보: 버스 유형, 시스템 메모리, 설치된 하드웨어 및 소프트웨어 정보
  • Plug&Play 정보, 네트워크 로그온 기본 설정, 네트워크 보안 정보, 소프트웨어 관련 정보, 기타 시스템 정보

HKEY_USERS

로컬 컴퓨터 내 기본 사용자와 현재 사용자에 대한 사용자 설정 정보를 가지는 key이다.

HKEY_CURRENT_CONFIG

현재 하드웨어 프로필에 대한 정보를 가지는 key이다.

• HKLM과 달리, 현재 하드웨어 구성과 표준 하드웨어 구성 간의 차이점에 대한 정보만 가진다.

Registry Hive

앞서 보인 것과 같이 key, subkey, value의 논리적 집합을 hive(하이브)라고 부른다.
운영체제가 시작되거나 사용자가 로그인할 때 메모리에 로드되는 설정 파일 집합을 말한다. 새로운 사용자가 로그인할 때마다 해당 사용자에 대한 새 사용자 프로필 하이브가 HKU key의 하위에 생성된다.

로컬 컴퓨터 상에서 레지스트리 하이브 파일 경로: %SystemRoot%\System32\Config directory

주요 Key 경로

(계속 업데이트 중)

시스템 정보

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion
  • RegisterOwner
    • 윈도우 운영체제를 설치하는 과정에서 최초로 등록한 사용자의 계정명
    • 이후 또 다른 계정을 생성해도 변경되지 않고 최초 등록된 계정명으로 표시된다.
  • ProductName
    • Windows 11도 Windows 10으로 표시된다..
  • InstallDate
    • 운영체제 설치한 시각
    • InstallDate값이 변경될 경우, 이전 업데이트 날짜를 아래 경로에 저장한다.
      • HKLM\SYSTEM\Setup\Source OS (Updated on dd/mm/yyyy hh:mm:ss)

• HKLM\SYSTEM\ControlSet001\Services\Tcpip\Parameters
  • HostName
    • 컴퓨터 이름
    • Windows 10부터는 사용자가 직접 설정하지 않아도 윈도우 운영체제에서 자동으로 컴퓨터 이름을 설정하기도 한다.

• HKLM\SYSTEM\ControlSet001\Control\Windows
  • ShutdownTime
    • 마지막 종료 일시
    • 사용자가 시스템을 정상적으로 종료한 시각으로 기록된다.

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI
  • LastLoggedOnSAMUser
    • 마지막 로그아웃 일시
    • 비정상적 종료로 인해 데이터를 신뢰할 수 없을 경우가 있어 NTUSER.DAT key의 마지막 수정 시간과 일치하는지 확인해야 한다. 일치하지 않을 경우 마지막 로그인 일시로 판단해야 한다.

시스템 표준 시간

• HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
  • 시스템 표준 시간 관련 정보를 가지는 key
  • CurrentControlSet이 없는 경우 ControlSet001을 확인하면 된다.
  • 관련 포스트: https://note-ing.tistory.com/43

사용자 계정 정보

• LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
  • S-1-5-18: System profile
  • S-1-5-19: LocalService
  • S-1-5-20: NetworkService
  • S-1-5-21-{...}-{4자리숫자}
    • 500: Administrator
    • 1000이상: 실제 사용자 계정

• HKU\{SID}\Environment
  • 사용자의 환경 설정 정보

Autorun 자동 실행 프로그램 정보

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
  • Run: 시스템이 부팅될 때마다 실행
  • RunOnce: 한번만 실행
• 관련 포스트: https://note-ing.tistory.com/46

응용 프로그램 실행 흔적

• HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist
  • UserAssist
    • 최근에 실행된 프로그램 정보
    • Prefetch 파일과 연계하여 분석할 
    • 조사하고자 하는 프로그램의 GUID를 알아야 하며, Count 내 정보는 ROT13으로 난독화되어 있다.
      • AXIOM과 같은 프로그램을 이용하여 난독화된 내용을 손쉽게 확인할 수 있다.

참고 자료

• https://learn.microsoft.com/en-us/windows/win32/sysinfo/registry
• https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc781906(v=ws.10)

문제를 클릭하면 Easy_CrackMe.exe 라는 exe 파일 하나를 받을 수 있다.

다운로드 받은 파일을 실행해보면 아래와 같은 GUI 프로그램이 실행되는 것을 볼 수 있다. 문자열을 입력 후 확인 버튼을 누르면 Incorrect Password 라는 결과창을 보여준다. 이를 통해, 본 프로그램에서 "Incorrect password"라는 문자열이 쓰인다는 것을 알 수 있다.

이번에는 x32dbg를 사용하여 파일을 로드하고 실행하여 EntryPoint를 찾는다.

이 상태에서 문자열 검색을 누르면 아까 보았던 Incorrect Password 문자열을 볼 수 있고, 그 위쪽으로 Congratulation !! 이라는 문자열을 볼 수 있다. 올바른 비밀번호를 입력하면 이 문자열이 출력되는 것으로 추정된다.

임의의 문자열을 입력하게 되면 아래 부분으로 실행 지점이 이동하게 되며, 코드의 하단에서 성공 문자열도 볼 수 있다.

성공 문자열까지 무사히 실행 흐름을 유지하기 위해서 어떤 과정을 거치는지 살펴봐야겠다.

잘못된 문자열에 의해 실패 지점으로 가는 첫번째 분기문은 0x004010B5 지점이다.

이 위치에서 성공과 실패를 가르는 첫번째 조건은 byte ptr ss:[esp+5]와 61('a') 가 같아야 한다는 것이다.

byte ptr ss:[esp+5] 가 어떤 값을 가지는지를 보기 위해 esp가 가리키고 있는 콜스택의 값을 확인한다.

테스트로 입력해둔 값은 'aaaa' 인데, 마치 입력한 값을 가리키듯 스택에 들어있는 값 또한 61 61 61 61 (aaaa)을 가진다.

그리고 여기서 esp+5가 가리키는 값은 두번째 입력된 'a'가 된다.

이 값이 61인 a와 같아야 한다니, 정답인 password의 두번째 글자가 'a' 인 것을 알 수 있다.

다음으로, 두번째 분기문을 만나게 되는 지점은 0x004010CD 이다.

이 위치에서 성공과 실패를 가르는 기준은 eax의 값이 0이어야 한다는 것이다. (바로 윗 줄의 test eax, eax 때문에)

여기서 eax의 값은 0x004010C3에서 호출되는 easy_crackme.401150 의 return 값과 같게 된다. 그렇기 때문에 호출되는 함수가 어떤 결과를 반환하는지 알아야 한다. 이를 위해 우선 인자로 들어가는 값을 보자. 함수가 호출되기 직전에 스택에 push 되는 두 값이 있다. 하나는 프로그램 내에 하드코딩 되어 있는 문자열 "5y"이고, 다른 하나는 입력한 문자열인 dword ptr ss:[esp+A] 이다. esp+A가 가리키고 있는 값이 무엇인지 확인하기 위해 콜스택을 확인해도 되지만 이번에는 이 값이 ecx에 들어있으므로, ecx에 저장된 값을 통해 확인한다.

그러면, 그 값이 "aa"임을 알 수 있다. 그러나 앞서 테스트값 4글자가 모두 a 였으므로, 어느 자리의 a를 가리키는지 모호하여 서로 다른 글자를 가지는 테스트데이터 "!abc"를 사용하겠다.

이를 사용하여 다시 확인한 결과, 세번째와 네번째 자리의 문자인 "bc"가 ecx의 값이 되는 것을 알 수 있다. 

easy_crackme.401150 함수의 심볼이 혹시나 있는지 보기 위해 IDA를 사용하여 이 함수가 위치한 0x004010C3 주소로 이동하면 문자열의 일치 여부를 확인하는 함수인 strncmp임을 알 수 있다. 따라서 앞서 사용된 두 매개변수와 함께 고려하여 생각해볼 경우, 두 번째 분기문의 조건은 입력된 비밀번호의 3번째와 4번째 문자가 "5y"와 같아야만 함을 나타내는 것을 알 수 있다.

이제까지 알아낸 정보를 가지고 조합한 패스워드는 _a5y__ 이다. 이를 고려하여 !a5yasdf 라는 테스트데이터로 다시 이어서 테스트를 하였다.

이후 3번째 만나는 구간부터는 하드코딩 되어 있는 R3versing 이라는 문자열과 입력된 문자열 중 5번째에 위치한 문자열 전체를 한글자씩 비교하여, 같은지 아닌지 살핀다. 언제라도 다른 문자열을 발견할 경우 실패 지점으로 분기된다. 그렇기 때문에 5번째부터는 R3versing 이라는 문자열을 입력하는 것이 실패로 가지 않는 길이다.

현재까지 조합된 패스워드는 _a5yR3versing 이다. 첫번째 자리의 문자가 미정인 상태이다. 이를 확정짓기 위해서는 네번째 분기 지점인 0x00401112를 확인하면 된다.

그리고 이 곳에서 첫번째 자리 문자를 가리키는 esp+4의 값이 45('E')와 같은지 비교한다. 이것으로 첫번째 자리 문자가 'E'임을 알 수 있다.

결과적으로, 이것들을 조합한 패스워드인 Ea5yR3versing을 입력하면 다음과 같은 축하 메세지를 얻을 수 있다.

Windows Registry 내에서 시스템의 Timezone을 확인하기 위해서는 다음과 같은 키의 값을 확인하면 된다.

HKLM\SYSTEM\CurrentControlSet\Control\TimezoneInformation [TimeZoneKeyName]

그러나 간혹 레지스트리 경로 내 CurrentControlSet 을 찾을 수 없는 경우를 발견한 적이 있었다.
이런 경우 CurrentControlSet 대신 ControlSet001과 ControlSet002만을 가지고 있는 경우도 있었다.

이름이 비슷하게 생긴 것을 힌트 삼아 이 두 경로가 CurrentControlSet을 대신할 수 있을까 라는 생각을 하게 되었다. 그리고 실제로 각각의 경로를 탐색한 결과 두 경로 모두 현재 시스템의 시간대 정보를 가지고 있는 것을 확인할 수 있었다.

이들 간에 어떠한 차이가 있는지 알아보기 위해 우선 관련 정보를 인터넷에 검색하였다.

stackoverflow 내 답변에 의하면 ControlSet001과 ControlSet002는 CurrentControlSet의 백업으로 사용하는 key라고 한다.여기서 궁금했던 점은 백업용이면 한개만 있으면 될텐데 왜 굳이 2개의 백업용 key를 두었을까? 하는 부분이었다.  이를 확인하기 위해 몇가지 테스트를 진행하였다.

실습을 위해 사용한 운영체제는 Windows 7 이며 VMware 를 이용한 가상환경에서 테스트하였다.

테스트한 case는 다음과 같다.

1. 시간대 변경 이후 재부팅하지 않을 경우
2. 시간대 변경 후 시스템을 정상적으로 종료하는 경우
3. 시간대 변경 후 시스템을 비정상적으로 종료하는 경우

case 1: 시간대 변경 이후 재부팅하지 않을 경우

초기 실습용 OS의 표준시간대는 UTC+9 이다. 이를 UTC+7로 변경하였다.

그 후 차례로 CurrentControlSet과 ControlSet001, 그리고 ControlSet002의 표준시간대 반영 결과를 확인하였다.

결과는, CurrentControlSet과 ControlSet001에만 변경된 시간대가 적용이 되었고 ControlSet002에는 초기 UTC+9가 그대로 남아있었다.

이 상태에서 한번 더 시간대를 변경하였다. 이번에는 UTC+5로 변경하였다.

이번에도 변경된 사항은 CurrentControlSet과 ControlSet001에만 적용되었으며, ControlSet002에는 처음의 UTC+9 시간대가 그대로 남아있었다.

case 2: 시간대 변경 후 시스템을 정상적으로 종료하는 경우

이제 시스템을 롤백시켜 시간대 변경을 할 때마다 시스템을 정상적으로 종료 후 부팅하는 방식을 테스트해보려고 한다.

초기 상태인 UTC+9에서 UTC+7로 변경하였다.

시간대 변경 직후, 재부팅을 안한 상태에서는 앞선 결과와 마찬가지로 CurrentControlSet과 ControlSet001만 변경되고 ControlSet002는 여전히 원래 시간대인 UTC+9로 기록되어 있는 것을 볼 수 있다.

위 상태에서 정상적으로 재부팅을 한 후 다시 각 결과를 확인하였을 때, ControlSet001 외에 ControlSet002 까지도 모두 같은 시간대 정보를 가지고 있는 것을 확인할 수 있었다.

case 3: 시간대 변경 후 시스템을 비정상적으로 종료하는 경우

case 2에와 마찬가지로 시스템을 초기 환경으로 롤백 후 다시 테스트하였다.

시간대를 변경한 후 비정상적 종료를 유발하기 위해 간단한 스크립트를 작성하여 일부 시스템 프로세스를 강제종료 시켰다...ㅎ

그 후 안전 모드로 접속하여 확인했을 때, ControlSet001과 CurrentControlSet은 변경한 시각을 가지고 있었지만, ControlSet002의 경우 정상적인 상태일때 저장된 상태값인 UTC+9를 그대로 가지고 있었다.

비정상적으로 종료된 케이스에서도 정상적으로 재부팅을 한다면, ControlSet002의 시간대도 다시 시스템의 표준 시간대와 동일한 값을 가지는 것을 확인하였다.

여기서 만약 안전 모드가 아닌 표준 모드로 재부팅을 한다면?

테스트를 위해 이번에는 ControlSet001과 CurrentControlSet의 시간대를 UTC+9로 설정하고, ControlSet002만 UTC+7로 설정되어 있는 상태에서 시스템의 비정상 종료를 유발했다.

그 결과, ControlSet001과 CurrentControlSet의 표준 시간대가 모두 ControlSet002의 표준 시간대와 동일한 상태로 부팅이 되었다.

물론 CurrentControlSet 에 설정된 UTC+7 대로 라면 가상머신의 시간이 현재 한국 시간보다 2시간 느려야하는데 호스트 컴퓨터의 시간과 동일하게 표시되는 것으로 봐서 어딘가 문제가 생긴건 맞는 것 같다.ㅎㅎ.. 이런 현상은 재부팅을 해도 마찬가지였고, 

각 케이스의 결과를 비교하였을 때,

대체로 ControlSet001은 CurrentControlSet과 동일한 값을 가지며

ControlSet002은 가장 최근에 정상적으로 종료된 Control값을 가지는 것을 알 수 있다.

그리고 비정상적 상태로 종료하였을 경우 ControlSet002는 가장 최근에 저장된 정상 Control 상태를 저장하였다가 복구 시 시스템의 상태를 이 ControlSet002에 저장된 상태로 설정한다.

그렇다면 CurrentControlSet을 사용하지 않고 ControlSet001을 사용하면 되는것 아닌가? 라는 의문이 들 수 있다.

이러한 의문에 대한 답은 아래 링크를 통해 해결할 수 있었다.

위 내용에 따르면

CurrentControlSet, ControlSet001, ControlSet002 간의 관계를 정의하는 레지스트리가 존재한다.

그것은 바로 HKLM/SYSTEM/Select subkey 내에 있는 key들이다.

여기에는 Current, Default, Failed, LastKnownGood 과 같이, 총 4개의 서로 다른 상태를 저장할 수 있는 key가 있으며 각각은 다음과 같은 의미를 가진다.

● Current는 현재 CurrentControlSet이 가리키고 있는 ControlSet의 번호를 나타낸다. Current key의 값이 0x01 일 경우 CurrentControlSet의 값은 ControlSet001과 같게 된다.

● Default는 기본적으로 CurrentControlSet이 가리키고 있는 ControlSet의 번호를 나타낸다. Default key의 값이 0x01 일 경우 CurrentControlSet의 값은 ControlSet001과 같게 된다.

● Failed는 정상적으로 사용하기 어려운 ControlSet의 번호를 가리키게 된다. Failed key의 값이 0x00일 경우 모든 ControlSet 을 정상적으로 사용할 수 있다는 것을 가리킨다.

● LastKnownGood는 Current key에서 가리키고 있는 번호의 ControlSet이 설정되기 이전으로부터 가장 최근에 설정된 정상 ControlSet의 번호를 나타낸다.

결과적으로 현재 시스템의 Control 정보를 보고자 한다면 CurrentControlSet의 내용을 보는 것이 맞으며, 이는 Current key가 가리키고 있는 ControlSet001로부터 가져온 정보를 가진다. 만약 복구가 필요할 경우 LastKnownGood key가 가리키고 있는 ControlSet002로부터 가져온 정보를 사용하게 된다.

시작은 Timezone 분석으로 하였지만, 이외에도 시스템 내에 있는 다른 정보들의 백업을 위해 총 3개의 Set(CurrentControlSet, ControlSet001, ControlSet002)이 사용되고 있는 것을 알게 되었다. 

또한 글의 초입에서 언급했던 상황과 같이, CurrentControlSet을 확인할 수 없는 경우에는 Select subkey 설정값을 확인하여 CurrentControlSet과 같은 값을 가지는 백업 Set이 어느것인지 확인하고 CurrentControlSet을 대신하여 참고할 수 있을 것으로 생각된다.

침해사고 분석 관련 공부를 하면서 처음 접하게된 개념인 MITRE ATT&CK은 솔직히 처음부터 중요하게 느껴졌던 개념은 아니었다. 그저 하나의 형식으로 사용된다라고, 머리로만 이해되었을 뿐이었다. 그러나 이러한 생각은 침해사고 분석 보고서들을 읽어보기 시작하면서 달라졌다.

공격자들은 침해 사고를 일으킨다. 그리고 한번 일어난 침해사고는 거기에서 그치지 않고 비슷한 체계나 취약점을 가진 다른 대상에게 또 다시 일어나곤 한다. 혹은 처음부터 불특정 다수를 대상으로 유포되는 바이러스에 의해 동시다발적으로 침해 사고가 일어나기도 한다. 따라서 방어하고자 하는 자들은 침해사고 발생 시 이를 분석하고 공유하여 공격에 대응할 수 있도록 서로 협력한다. 이러한 과정을 효율적으로 처리하기 위해 ATT&CK Framework를 사용한다.

ATT&CK은 Adversarial Tactics, Techniques and Common Knowledge의 앞 글자로 이루어진 단어이다. 여기에서 사용하는 가장 중요한 개념은 TTP이다. TTP의 각 글자는 Tactics, Techniques, Procedures를 의미한다. 이는 공격자나 악성코드의 행위를 설명하기 위해 표현하는 방식이다. TTP와 함께 사용되는 개념인 IOC는 침해 사고 발생 시 시스템 내 공격을 분석하는데 도움을 주는 증거 데이터들을 가리킨다. 이들은 TTP와는 다르게 단편적인 정보를 가지고 있으며 시그니처 기반 분석 시 사용되는 정보이다. IOC의 예시로는 IP 주소, 비정상적인 네트워크 트래픽 패턴, 악성 프로그램, 무단 액세스 기록 등이 있다. 

각각에 대해 조금 더 정리하자면,

Tactics는 "why"를 담당한다. 공격의 목적이자, 공격 수행 단계에 대해 묘사하는 부분이다. MITRE ATT&CK framework의 Enterprise를 기준으로 현재 14개의 tactics가 정의되어 있으며 각각의 tactic은 고유한 ID를 가진다.

Techniques는 "how"를 담당한다. 각 Tactics 별로 해당 단계에서 발생할 수 있는 공격 techniques 유형에 대해 정의되어 있다. 아래는 Initial Access 단계에 정의되어 있는 techniques 목록이며 9개의 techniques가 정의되어있는 것을 볼 수 있다. Tactics와 마찬가지로 각 technique도 고유한 ID를 가진다.

Procedures는 tactics와 techniques 이외에 기술할 추가적인 행위 정보를 가진다. 따라서 이에 대해서는 ATT&CK framework에서 정의해두고 있지 않다. 그렇기 때문에 분석 보고서 작성 시 ATT&CK framework 외에 procedure에 대한 내용도 함께 기술하여 분석 결과를 정확하게 전달하곤 한다.

MITRE ATT&CK 홈페이지에서는 이러한 framework에 기반하여 정의된 TTP를 시각화할 수 있는 툴을 제공한다. 이를 이용하면 시각화된 결과를 볼 수 있을 뿐 아니라, 특정 TTP 항목을 선택하였을 때 다른 tactics 파트에서 이와 관련지어 나타날 수 있는 공격에 대해 표시된다. 이를 이용하여 공격자의 다음 행동에 대해 예측할 수 있으며, 분석 과정에서는 놓치고 지나갈 수 있는 부분에 대해 다시 한번 체크하도록 한다.

실제 침해사고 분석 보고서 또는 악성코드 분석 보고서에서도 이를 적용하여 보고서를 작성하고 있다.

금융보안원의 Masscan 랜섬웨어 위협 분석 보고서의 경우 TTP를 기준으로 공격자가 사용한 전략과 전술을 정리해 제공하고 있으며, 하루 전 공개된 KISA의 블랙캣 랜섬웨어 침해사고 기술보고서에서도 TTP에 따른 MITRE ATT&CK Framework를 사용하여 공격자들의 전략을 공유하고 사전에 예방할 수 있도록 하고 있다.

참고자료

- https://www.aquasec.com/cloud-native-academy/vulnerability-management/indicators-of-compromise/

다음은 Volatility Wiki의 Memory Samples 리스트에 있는 Malware - Cridex 파일에 대한 분석이다.

먼저 주어진 파일에 대한 프로파일 분석을 위해 imageinfo를 사용하였고, WinXPSP2x86 인 것으로 파악할 수 있었다.

이 후, 메모리 내 프로세스 리스트와 구조, 그리고 네트워크 상태를 파악하기 위해 아래의 명령어를 사용하여 추출하였다.

pstree 를 통해 확인한 리스트에서 가장 의심이 되게끔 생긴 explorer.exe 프로세스와 이것의 하위 프로세스인 reader_sl.exe를 우선적으로 분석하려고 한다. reader_sl.exe는 Adobe Acrobat Reader의 실행파일인데, 대게 PDF 열람 시 사용한다. 게다가 PDF는 악성코드가 심어져있을 확률이 높은 경로이므로 이를 통한 감염도 의심해볼 수 있다.

앞서 함께 추출했던 정보인 connections를 확인하니 유일하게 적힌 connections 정보를 확인할 수 있는데,
여기에 사용된 pid 1484가 현재 의심되는 프로세스인 explorer.exe의 pid와 일치하였다. 파일 탐색기가 외부 IP와 네트워크 연결을 맺고 있는 경우가 흔하지 않으므로 분석해볼 만하겠다는 생각이 들었다.

이외에도 추출 가능한 다른 요소인 filescan에서 의심대상 파일을 검색해본 결과 reader_sl.exe 파일에 대한 덤프가 가능할 것으로 보여 이를 추출하고 VirusTotal을 통해 이 파일에 대한 검사를 진행했다.

그러자 이 파일이 매우 높은 확률로 악성코드일 것이라 생각될만한 결과가 나왔다.

어떠한 경로로 침해사고가 발생하였는지 확인하기 위해 reader_sl.exe의 부모 프로세스인 explorer.exe를 조사하였다.

여기에 connections에서 얻은 IP 주소를 활용해보고자 검색을 수행하였는데, 이 IP 주소가 사용된 곳 중 아래와 같은 부분을 발견할 수 있었다. 여기에는 서로 다른 IP 주소에 같은 경로를 사용한 많은 URL들이 있었다. 따라서 이 공통되는 path를 중심으로 다시 한번 검색했다.

그러자 이 문자열로도 많은 검색 결과를 얻을 수 있었는데, 그 중 경로의 끝부분이 .php로 끝나는 부분을 따라가봤다. 검색된 결과의 위쪽으로는 은행 사이트로 추정되는 많은 도메인명이 있었고, 아래로는 웹페이지 소스코드로 추정되는 코드가 있었다. 이 중 아래의 웹페이지 소스코드의 추출하고 브라우저를 이용해 확인하였다.

추출한 HTML 파일의 내용에서는 보안이 철저하다는 말을 앞세워 온갖 개인정보를 요구하고 있는 것을 알 수 있었다.

이것으로 초기 접근은 은행사이트 피싱을 이용한 것으로 추측할 수 있다.
그러나 여기에서 어떻게 Adobe Acrobat reader의 reader_sl.exe를 실행되게 할 수 있었는지가 확실하지 않은 상황이다.

여기까지 내용을 정리하면 다음과 같다.

1. explorer.exe 프로세스가 41.168.5[.]140:8080 과 커넥션을 맺고 있다.
explorer.exe는 파일 탐색기의 프로세스명으로, 파일 탐색기가 외부 IP와 커넥션을 맺을만한 일이 있을지를 고려하여 의심 프로세스로 선정하였다.

2. explorer.exe 프로세스의 자식 프로세스인 reader_sl.exe 프로세스의 덤프 파일을 VT를 통해 검사한 결과, 바이러스로 탐지된 정황이 발견되었다. 따라서 본 덤프 파일에 대한 악성 행위 파악을 위해 추가적인 분석이 필요할 것으로 보인다.

3. explorer.exe 프로세스 내에서 발견된 IP 주소(188.40.0[.]138:8080)로 Chase[.]com에 대한 피싱 사이트 접근 정황이 발견되었다.
이에 대한 상세 경위를 파악하기 위해서는 explorer.exe에 대한 분석도 진행되어야할 것으로 보인다.
분석 과정에서 explorer.exe 프로세스 자체 실행 메커니즘 상의 특이점이 발견될 경우 프로세스를 변조시킨 경로에 대한 조사도 이루어져야할 것이다.

+ Windows 8 이상부터 윈도우 시작 메뉴에 있는 라이브 타일의 네트워크 사용으로 인해 explorer.exe가 네트워크에 연결되어 있을 수도 있다고 한다.