eBPF 기반 악성코드 분석: Azazel 단일 바이너리로 Docker 샌드박스 런타임 행위 추적하기(방어 중심)

eBPF 기반 악성코드 분석이 필요한 조직(보안관제/SOC, IR, 악성코드 분석팀)이라면, 최근 공개된 오픈소스 프로젝트 Azazel을 주목할 만합니다. Azazel은 “샌드박스에서 샘플을 실행했을 때 무슨 일이 일어났는지”를 에이전트/데몬 없이 단일 바이너리로 수집하고, 결과를 NDJSON(JSON Lines) 형태로 내보내는 eBPF 기반 런타임 트레이서입니다.

이 글은 취약점 공지(패치 안내)가 아니라, 방어/대응 목적의 분석 인프라 관점에서 Azazel이 무엇인지, 왜 중요한지, 그리고 팀이 당장 어떤 준비/검증/연동을 해야 하는지에 초점을 맞춥니다. (작성 시각: 2026-02-15 10:00 KST)

TL;DR (요약)

Azazel은 eBPF 기반 런타임 보안 트레이서로, 악성코드 분석 샌드박스(특히 컨테이너 기반)에서 syscall/파일/네트워크/보안 이벤트를 수집해 NDJSON으로 출력합니다.
설계 포인트는 “샌드박스 포렌식”: 일반 런타임 보안 제품이 아니라, 샘플 실행 중 발생한 행위를 정밀하게 기록/파이프라인화하는 데 초점을 둡니다.
요구사항이 명확합니다: Linux kernel 5.8+, BTF(CONFIG_DEBUG_INFO_BTF) 필요. 런타임에서 eBPF를 로드/부착하려면 권한이 필요합니다(운영 환경 적용 시 권한/격리를 최우선으로 설계해야 함).
SOC/IR 실무 팁: NDJSON 필드를 그대로 SIEM/데이터레이크로 적재하고, W+X mmap, ptrace, 커널 모듈 로드, 민감 파일 접근 같은 이벤트를 우선 알림/헌팅 포인트로 삼을 수 있습니다(프로젝트 내장 휴리스틱도 제공).

배경: Azazel은 무엇이며 어떤 문제를 푸나

GitHub 리포지토리 설명에 따르면 Azazel은 “악성코드 분석 샌드박스를 위해 설계된 경량 eBPF 기반 런타임 보안 트레이서”입니다. 격리된 컨테이너에 샘플을 두고 실행하면, Azazel이 syscall, 파일 접근(읽기/쓰기/삭제/이름변경), 네트워크 연결/전송, 그리고 일부 보안 관련 행위를 수집하고, “무슨 일이 있었는지”를 정돈된 JSON 스트림으로 제공하는 방식입니다.

프로젝트가 내세우는 핵심 방향성은 다음과 같습니다.

Sandbox-first: cgroup 기반 필터링으로 “분석 대상 컨테이너”의 이벤트만 추려 수집하는 데 초점을 둠
Zero dependencies at runtime: 단일 정적 Go 바이너리, 별도 에이전트/데몬 불필요
CO-RE(Compile Once, Run Everywhere): BTF와 vmlinux.h 기반으로 커널 버전 간 재컴파일 부담을 줄이는 방향
JSON-native: NDJSON(이벤트 1개 = JSON 1줄)로 출력해 jq/Elasticsearch/Splunk 등 파이프라인에 바로 올리기 용이
Built-in heuristics: 샌드박스에서 자주 의미 있는 행위를 휴리스틱 알림으로 표기(예: /tmp 실행, 민감 파일 접근, ptrace, W+X mmap, 커널 모듈 로드 등)

핵심 포인트: eBPF 기반 악성코드 분석이 왜 중요한가

“샘플이 실제로 무엇을 했는지”를 빠르게 파악하는 능력은, 단순한 악성 여부 판정(benign/malicious)을 넘어 IOC 도출, TTP 분류, 2차 확산 방지, 탐지 로직 개선에 직결됩니다. 특히 컨테이너 기반 샌드박스에서는 ‘컨테이너 내부’에서만 보이는 흔적과 ‘호스트 관점’에서 보이는 흔적이 다르게 남을 수 있는데, Azazel은 eBPF를 통해 커널 레벨에서 이벤트를 수집한다는 점을 장점으로 내세웁니다(프로젝트 README 기준).

또한 Azazel은 출력 포맷을 NDJSON으로 고정해, 분석 결과를 “보고서”로만 소비하는 것이 아니라 데이터로 축적해 재현/비교/집계(예: 샘플 패밀리별 네트워크 행위 통계, 실행 트리 패턴, 민감 파일 접근 빈도)를 하기에 유리한 구조를 제공합니다.

영향/리스크(운영 관점): 무엇을 기대할 수 있고, 무엇을 조심해야 하나

1) 수집 범위(프로젝트에 명시된 이벤트 타입)

README에 정리된 캡처 범주는 크게 프로세스/파일/네트워크/보안 이벤트로 나뉩니다. 예시로 다음 이벤트 타입이 명시되어 있습니다.

Process: process_exec, process_exit, process_clone
File: file_open, file_write, file_read, file_unlink, file_rename
Network: net_connect, net_bind, net_listen, net_accept, net_sendto, net_dns
Security: mmap_exec, ptrace, module_load

또한 “총 19개 후킹 포인트(시스템콜 엔트리 tracepoints + DNS 탐지를 위한 kprobe 1개)”라고 설명합니다(README 기준).

2) 내장 휴리스틱 알림(분석 우선순위에 도움)

Azazel은 샌드박스에서 자주 ‘의미 있는’ 행위를 자동으로 플래그합니다. README에 명시된 예시는 다음과 같습니다.

/tmp, /dev/shm, /var/tmp에서의 실행(“Suspicious exec path”, Medium)
민감 파일 접근(예: /etc/passwd, /etc/shadow, /etc/sudoers, /etc/ssh/, /proc/self/maps, /proc/self/mem, /etc/ld.so.preload 등, Medium)
ptrace 호출(High)
finit_module 기반 커널 모듈 로드(High)
W+X mmap(WRITE+EXEC 동시 매핑, Critical)

중요한 점은, 이런 휴리스틱은 “악성 확정”이 아니라 분석의 첫 관문을 빠르게 만들어주는 힌트라는 것입니다. 운영 파이프라인에서는 알림을 그대로 결론으로 쓰기보다, 해당 이벤트 주변(직전/직후 프로세스 트리, 연결 대상, 파일 쓰기)을 함께 묶어 triage 해야 합니다.

3) 요구사항/제약(사실로 확인되는 부분만)

Linux kernel 5.8+ 필요(README에 명시)
BTF 지원 필요: CONFIG_DEBUG_INFO_BTF=y 및 /sys/kernel/btf/vmlinux 존재 여부를 확인하도록 안내(README에 명시)
일부 tracepoint는 커널/환경에 따라 없을 수 있으며, 이 경우 경고를 남기고 계속 동작한다고 설명(README의 Troubleshooting 섹션)
eBPF 로드/부착은 권한이 필요하므로, 분석 환경은 격리(전용 호스트/VM), 권한 통제, 네트워크 통제가 전제되어야 합니다(권한 자체는 README의 실행/트러블슈팅에서 간접적으로 확인 가능).

탐지 포인트(로그/IOC): SOC/IR이 바로 써먹는 관점

Azazel은 이벤트를 NDJSON으로 출력합니다. README 예시에는 다음과 같은 필드들이 등장합니다(환경/버전에 따라 실제 필드는 달라질 수 있으므로, 현장에서는 스키마를 먼저 고정/버전관리하는 것을 권장합니다).

{
  "timestamp": "...",
  "event_type": "process_exec",
  "pid": 12345,
  "ppid": 12300,
  "uid": 0,
  "comm": "bash",
  "container_id": "...",
  "filename": "/tmp/...",
  "args": "..."
}

우선순위 높은 탐지/헌팅 포인트(Azazel 이벤트 기준):

W+X 관련: event_type이 mmap_exec이거나, “W+X mmap” 휴리스틱 알림이 발생한 샘플은 우선 분석(패킹/언패킹/인젝션 가능성과 연관될 수 있으나, 여기서는 기정사실로 단정하지 말고 정황으로만 활용)
ptrace: event_type=ptrace(프로세스 간 관찰/조작 가능성이 있어 우선순위 높음)
커널 모듈 로드: event_type=module_load 또는 finit_module 관련 알림(샌드박스에서 특히 위험 신호)
민감 파일 접근: /etc/shadow, /proc/self/mem, /etc/ld.so.preload 등 접근 시도(자격증명/프로세스 메모리/로더 설정 등과 연결될 수 있어 우선 확인)
네트워크: net_connect 및 net_dns(목적지 IP/포트, DNS 흔적을 IOC 후보로 추출하되, 샌드박스 NAT/프록시 구조라면 해석 시 주의)
프로세스 트리: process_exec/clone 기반으로 “부모-자식 체인”을 재구성해, 초기 실행부터 파생 행위를 묶어서 본다(단일 이벤트 단독 해석 금지)

운영 로그 관점(README 기준): 트레이서 종료 시 요약(Summary)과 “Security Alerts”가 stderr로 출력될 수 있다고 설명합니다. 이를 표준 출력(이벤트 스트림)과 분리해 수집하면, 원천 이벤트(NDJSON)와 요약/알림을 다른 인덱스로 저장하는 설계가 가능합니다.

대응 체크리스트(우선순위 포함): 오늘 당장 할 일

P0. 분석 환경 안전장치(필수)

전용 분석 호스트/VM 준비: 업무용/운영용과 물리적·논리적으로 분리(스냅샷/롤백 전제)
네트워크 통제: 기본은 egress 제한(필요 시 허용 목록 기반). 샘플이 외부와 통신해도 피해가 확산되지 않도록 설계
권한/격리 검토: eBPF 로드에는 권한이 필요하므로, Azazel 실행 권한을 최소화하고, 분석용 계정/호스트를 별도로 운영
증적 보존 정책: 원본 NDJSON, 요약, 샘플 해시(리포지토리의 analyze.sh는 “hash→trace→report” 자동화를 언급) 등 결과물 보존 범위를 사전에 정의

P0. 호환성 사전 점검(막히는 지점이 여기서 대부분 발생)

커널 버전: Linux kernel 5.8+인지 확인(README 요구사항)
BTF 지원: /sys/kernel/btf/vmlinux 존재 및 CONFIG_DEBUG_INFO_BTF 설정 확인(README 요구사항)
컨테이너 런타임: Docker 사용을 전제로 문서가 구성되어 있으므로, 사내 표준이 containerd/CRI-O라면 이식 계획을 별도로 수립(이 글에서는 README에 근거해 Docker 기준으로만 언급)

P1. SOC/IR 파이프라인 설계(“도구”에서 “운영”으로)

스키마 버전관리: event_type/필드 정의를 버전으로 고정하고(릴리스/커밋 기준), 파서/대시보드를 같이 관리
NDJSON 적재: Splunk/Elastic/데이터레이크에 그대로 적재 가능한지 PoC 수행(README가 jq/Elasticsearch/Splunk 파이프라인을 전제로 설명)
알림 우선순위 룰: W+X mmap, ptrace, module_load, 민감 파일 접근을 1차 triage 규칙으로 등록
컨테이너 단위 묶음: container_id/cgroup 기반으로 세션을 묶어 “샘플 1개 실행 = 1개 케이스”로 추적 가능하게 설계

P2. 품질/재현성 확보

테스트 스위트로 검증: README에 “악성 행위 시뮬레이터를 실행하고 기대 이벤트가 캡처되는지 검증”하는 테스트 흐름을 설명합니다. 사내 환경에서도 동일한 품질 게이트를 두는 것이 좋습니다.
커널별 차이 기록: tracepoint 부재/경고 발생 케이스를 커널 버전별로 문서화(향후 사건 대응 시 “왜 어떤 이벤트가 없었는지” 설명 가능)

FAQ

Q1. Azazel은 EDR/런타임 보안 제품을 대체하나요?

README 기준 Azazel은 “악성코드 분석 샌드박스 포렌식”에 목적을 둔 트레이서입니다. 운영 환경(프로덕션) 상시 방어를 위한 EDR/보안 에이전트와는 목표가 다릅니다. 가장 자연스러운 포지션은 “샘플 분석/리서치/IR 지원용 분석 도구”입니다.

Q2. 어떤 시스템에서 동작하나요?

README에 따르면 Linux kernel 5.8+ 및 BTF(CONFIG_DEBUG_INFO_BTF)가 필요합니다. 또한 CO-RE(BTF/vmlinux.h 기반)를 사용한다고 설명합니다. 그 외 커널/배포판별 제약은 실제 환경에서 검증이 필요하며, 이 글에서는 확인된 요구사항만 다룹니다.

Q3. “단일 바이너리”면 정말 설치가 쉬운가요?

런타임 의존성을 줄인 점(에이전트/데몬 없음, 단일 정적 Go 바이너리)은 운영 단순화에 도움이 됩니다. 다만 eBPF는 커널 기능과 권한에 민감하므로, 실제 난이도는 커널/BTF/권한/격리 설계에서 결정됩니다(README Troubleshooting에도 권한/커널 이슈가 주요 항목으로 등장).

Q4. 어떤 결과물을 SOC에서 바로 쓸 수 있나요?

Azazel은 이벤트를 NDJSON으로 내보내고, 종료 시 요약(Summary)과 Security Alerts를 출력할 수 있다고 설명합니다. 이를 기반으로 (1) 샘플별 실행 트리, (2) 파일 변경 흔적, (3) 연결 목적지, (4) 고위험 휴리스틱 알림을 표준화해 대시보드/룰로 만들 수 있습니다.

Q5. 라이선스는 무엇인가요?

README에는 GPL-2.0 라이선스라고 명시되어 있으며, eBPF 프로그램도 GPL-2.0(일부 eBPF 헬퍼 접근 요구사항)으로 설명합니다. 사내 도입/배포 형태에 따라 라이선스 검토가 필요합니다.