Day 2 — 나가는 트래픽 분석과 로깅¶
2일차 한눈에
1일차가 "들어오는 것을 막는" 이야기였다면, 2일차는 이미 들어온 공격자를 어떻게 찾는가입니다. 핵심은 밖으로 나가는 트래픽(egress) — 감염된 PC가 C2 서버와 주고받는 통신입니다. 내용은 암호화돼 못 봐도 행동 패턴(규칙적 간격 + 일정한 크기 = 비컨)은 보입니다. Zeek로 트래픽을 일관된 메타데이터 로그로 만들고, RITA/AC-Hunter로 그 로그에서 비컨을 찾습니다. 후반부는 UEBA(여러 로그를 묶어 평소 행동에서 벗어난 것 찾기)와 로깅의 품질 — Windows 기본 로그의 한계와 그 해결책인 Sysmon — 을 다룹니다.
표기 규칙
💡 보충 (강의 외) = 강의에 없던 제 추가 설명. (재구성) = 강사가 화면으로만 보여 줘 제가 복원한 명령어이므로 실제 실습 안내문 기준으로 쓰세요.
1. 왜 "나가는 트래픽(Egress)"인가?¶
공격자가 PC를 장악하면 그 PC는 공격자의 C2 서버(명령·제어 서버)와 계속 통신합니다. 이 통신은 안에서 밖으로 나갑니다(1일차의 reverse connection). 그래서 나가는 트래픽을 보면 감염된 내부 PC를 찾을 수 있습니다. MITRE ATT&CK에서 C2·흔한 포트 사용·데이터 반출은 많은 조직이 놓치는 영역입니다.
놓치는 이유는 암호화입니다. 요즘 트래픽은 대부분 TLS/SSL이라 내용을 못 봅니다. TLS를 중간에서 복호화하는 장비도 있지만 사생활·GDPR 문제가 생깁니다.
"암호화돼서 못 본다"는 변명은 통하지 않는다. 내용을 못 봐도 행동 패턴(behavior)은 볼 수 있다.
2. NetFlow — 연결 통계¶
내용을 못 봐도 "누가·누구와·언제·얼마나" 연결했는지는 볼 수 있습니다. 이것이 NetFlow(Cisco가 만든 연결 통계)입니다.
- Exporter(내보내는 장치) — 연결 데이터를 보내는 장비(라우터·방화벽)
- Importer/Collector(수집기) — 그 데이터를 모으는 곳
- Analysis engine(분석 엔진) — 모인 데이터를 분석해 의미를 뽑는 곳
NetFlow가 표준이 되자 sFlow·jFlow·NetStream 등 비슷한 것들이 쏟아졌습니다 — 모두 "연결 통계를 다루는 서로 다른 방식"입니다.
3. 실습 — Cisco ASA 방화벽 로그를 손으로 분석¶
John은 먼저 "손으로 하면 얼마나 괴로운지"를 보여 줍니다. 전제: 어떤 내부 IP가 감염됐다고 가정합니다(여기서는 192.168.1.6).
grep <문자열>= 특정 문자열이 든 줄만 골라내는 명령.
로그는 지저분합니다(John 표현으로 "악몽"). 데이터를 조금씩 다듬어 통계를 뽑을 형태로 만든 뒤, R tools라는 도구 모음으로 수학 분석을 해 비컨을 찾습니다. 요점은 "손으로도 되지만 너무 힘들다 → 그래서 Zeek·RITA가 필요하다".
4. AI로 로그 분석 — 맥락이 핵심¶
같은 ASA 로그를 ChatGPT에 넣어 봅니다.
① 그냥 "나쁜 트래픽 찾아줘"라고 하면 → AI가 엉뚱한 것(포트 스캔처럼 보이는 것, Telnet, ACL 차단 등)을 지목하고 진짜 악성 비컨은 못 찾습니다. 맥락(context)을 모르면 헛다리(hallucination)를 짚기 쉽습니다.
② 맥락을 주면 (내부/외부 IP, 제외할 주소, 완료된 연결만 — 백도어가 두 외부 IP를 번갈아 씀) → 훨씬 가까워지지만 "정상 같다"고 잘못 결론내기도 합니다. 결정적 단서는 시각입니다.
원격 터미널·keep-alive가 아닌 이상, 매초 완전한 TCP 연결·종료를 반복하는 정상 서비스는 거의 없다 → 악성 비컨.
R tools로 확인하면:
표준편차(standard deviation) 12는 아주 작습니다 — 데이터 크기가 거의 일정하다는 뜻으로, 비컨의 전형적 특징입니다.
AI 시대의 핵심 역량
"나쁜 것 찾아줘"는 잘 안 통합니다. 배운 지식으로 질문을 좁혀 줘야 좋은 답이 나옵니다. "로그를 어떻게 분석할지 아는 것"과 "올바른 질문을 던지는 것"이 핵심입니다.
5. Zeek — 일관되게, 작게¶
손 분석이 괴로우니 Zeek(예전 이름 Bro)를 씁니다. 빠르고, 사용자 기반이 크고, 타임스탬프가 완벽히 일관적입니다(장비마다 시각을 제각각 다루는데 Zeek는 흔들림 없음).
여기서 사고의 전환이 있습니다. 1일차 백신은 실행 파일 안 문자열(어셈블리)을 찾는 시그니처 방식이었지만, 트래픽은 암호화돼 문자열을 못 봅니다. 대신 로그의 행동 패턴을 보면 공격자를 능동적으로 사냥(hunting)할 수 있습니다. 앞으로 더 중요해지는 이유는 AI — 악성코드·새 C2·난독화를 AI가 만들 수 있으니, 사람이 AI를 써서 트래픽 패턴을 사냥해야 합니다.
Zeek vs 전체 패킷(full PCAP)
| 전체 PCAP | Zeek | |
|---|---|---|
| 장점 | 모든 내용, 모든 도구 지원(이식성 최고) | 크기 약 1/10 |
| 단점 | 너무 큼 | 원본 패킷 내용 없음(메타데이터) |
Zeek는 패킷을 압축하는 게 아니라 메타데이터로 바꿔 크기를 1/10로 줄입니다.
NAT 앞단(pre-NAT)에서 잡아라
방화벽 바깥(인터넷 쪽)에서 보면 모든 내부 PC가 방화벽 하나의 IP로 보여 감염된 PC를 특정할 수 없습니다. NAT 앞(내부 쪽)에서 잡아야 감염된 내부 사설 IP를 알 수 있습니다.
Zeek 로그 자체(conn.log, dns.log, http.log, ssl.log 등)는 네트워크 → Zeek에 정리되어 있습니다.
6. 비컨(Beaconing)이란?¶
John의 비유: 아이가 "엄마, 엄마, 엄마…" 하고 일정하게 반복하는 것이 비컨입니다. 감염된 PC가 C2에게 "저 여기 있어요, 명령 주세요"를 규칙적으로 반복하는 것. 세 가지로 분석합니다.
- 간격(interval) — 심장박동처럼 규칙적인가
- 데이터 크기 — 매번 거의 같은가(표준편차가 작은가)
- 연결 시각 — 완료·재시작이 좁은 간격으로 반복되는가
지터(Jitter) — 영리한 공격자는 간격을 일부러 흔듭니다(예: 7초 ±2초 → 5~9초 랜덤). 완벽히 규칙적이진 않아도 여전히 비컨의 특성(7초를 중심으로 대칭적으로 모임)을 가집니다. 간격이 완벽할 필요는 없고, 비컨의 특성만 있으면 됩니다.
롱 커넥션(Long Connection) — 비컨 말고, 연결 하나를 아주 오래 붙잡는 방식도 있습니다. John의 스파게티 비유: 긴 한 가닥(긴 연결)을 뚝뚝 부러뜨리면 조각들이 되지만(쪼개진 연결), 다 모으면 원래 하루치가 됩니다. 쪼개서 숨겨도 총합을 보면 드러납니다.
전체 비컨·C2 탐지 정리는 네트워크 → 비컨 & C2.
7. RITA — 비컨 탐지 엔진¶
이 분석의 수학은 RITA(Real Intelligence Threat Analytics)에 들어 있습니다. BHIS가 만든 무료 도구이며, 특허로 오픈소스를 유지합니다. 하는 일은 둘 — 비컨 찾기와 차단 목록(deny list) 대조(알려진 나쁜 IP와 비교, 3부에서 자세히).
어떤 수학을 쓰나
- K-means 클러스터링 — 데이터에서 패턴(일관성)을 찾는 알고리즘. CAPTCHA가 "신호등/자전거를 모두 고르세요"를 반복시켜 패턴 인식을 학습시키는 것과 같은 원리로, 일정한 간격·크기로 뭉친 덩어리를 찾습니다.
- MADM (평균 절대 편차) — 비슷하게 분포의 일관성을 봅니다.
비컨 점수(score) — 각 연결에 0~1 점수를 매기고, 1에 가까울수록 완벽한 비컨입니다. 연결 수도 함께 봅니다(예: 완벽한 간격으로 108,000번 연결).
비컨 = 꼭 악성은 아니다 (정상 비컨들)
규칙적으로 비컨하는 것이 악성코드만은 아닙니다 — TeamViewer(직원이 필터 우회용으로 쓸 수 있음), RDP, Nuance/Dragon(원격 제어 기능 내장 사례), LAN Turtle(USB-이더넷 모양 소형 리눅스). 전부 악성은 아니지만 전부 조사할 가치가 있습니다.
그 밖에 볼 수 있는 것 — User-Agent 문자열(내부 시스템이 자신을 어떻게 소개하는지), MIME 타입(오가는 데이터 종류 — 3부 "MIME 불일치"로 재등장), JA3/JA4(TLS client hello로 클라이언트 지문 인식; JA3는 브라우저 랜덤화로 깨져 지금은 JA4).
롱테일 분석(Long-tail analysis) — 정상 vs 비정상을 정렬하면 드문 꼬리(long tail) 쪽에 이상 징후가 모입니다. 사람 트래픽은 지저분하고 불규칙한데 비컨은 유난히 일관적이라 꼬리에서 튀어 보입니다.
강의에서 RITA를 직접 실습하나?¶
2일차에는 RITA를 명령줄로 직접 돌리는 독립 실습은 없습니다. RITA는 "엔진(원리)"으로 설명하고, 실제 손으로 하는 비컨 분석은 그 엔진을 얹은 AC-Hunter의 GUI로 합니다(3부). 즉 RITA = 무료 명령줄 엔진, AC-Hunter = 그 위의 유료 GUI(커뮤니티 에디션 있음). 처음 ASA 로그 실습의 비컨 수학은 RITA가 아니라 R tools로 했습니다.
💡 보충 (강의 외) — RITA 직접 돌려 보기
RITA는 무료이므로 홈 랩의 Zeek 로그로 직접 돌려 볼 수 있습니다(개념 흐름).
# Zeek 로그를 RITA 데이터베이스로 가져오기
rita import /opt/zeek/logs/2026-10-17 mydataset
# 비컨 분석 결과 보기 (점수 높은 순)
rita show-beacons mydataset
# 차단 목록 매칭 등
rita show-exploded-dns mydataset
rita import <Zeek 로그 폴더> <이름>으로 로그를 적재하고, rita show-beacons <이름>으로 비컨 점수(0~1)와 연결 수를 봅니다. 최신 RITA(v5+)는 설정이 조금 다르니 공식 문서를 확인하세요. 실제 강의 실습과는 별개인 보충 실습입니다.
8. ASN — "인터넷의 우편번호"¶
RITA의 두 번째 일인 차단 목록 대조를 John은 ASN 단위로 확장합니다. ASN(Autonomous System Number)은 IP 주소 덩어리를 관리하는 조직(통신사·클라우드 업체 등)의 번호로, John의 비유로는 인터넷의 우편번호입니다. 좋은 동네도, 나쁜 동네도 있습니다.
실습 — 나쁜 IP는 어느 동네에 몰려 있나¶
- GitHub에서 계속 갱신되는 나쁜 IP 목록을 내려받습니다.
- 각 IP를 Team Cymru(IP → ASN 조회 서비스)에 넣어 ASN을 알아냅니다(데이터가 많아 시간이 걸림).
- ASN별 나쁜 IP 개수를 세어 정렬합니다.
💡 보충 (강의 외)
이런 집계는 리눅스에서 흔히 sort | uniq -c | sort -rn 조합으로 합니다. uniq -c는 같은 값의 개수를 세고, sort -rn은 큰 숫자부터 정렬합니다. 정확한 명령은 실습 안내문을 따르세요.
결과는 첫 열이 나쁜 IP 수, 둘째 열이 ASN입니다.
아래로 넘겨 보면 숫자가 아주 빨리 떨어집니다(몇 번 넘기면 39개 수준). 인터넷 전체 ASN은 약 8만~9만 개인데, 나쁜 IP의 대부분은 극히 일부 ASN에 몰려 있습니다.
핵심
차단 목록 검사는 IP 단위만이 아니라 ASN 단위로도 보세요. 내 환경이 "나쁜 IP가 몰린 몇 안 되는 동네"와 얼마나 통신하는지가 좋은 단서입니다. RITA와 AC-Hunter는 Security Onion 안에도 설치할 수 있습니다 — Security Onion이 이미 Zeek를 쓰기 때문입니다.
9. AC-Hunter 실습 — 진짜 악성코드로 비컨 보기¶
AC-Hunter는 RITA 엔진 위의 GUI입니다. 이 실습은 클라우드 랩 없이 웹에서 바로 하며, 데모 계정으로 로그인하면 화면 왼쪽 위에 데이터셋(악성코드 샘플별 트래픽)이 있습니다. 질문 다섯 개와 John의 풀이입니다.
① AsyncRAT — 교과서 같은 비컨¶
질문: 192.168.0.136의 연결 간격과 분산은? → John 왈 "비컨의 거의 완벽한 정의".
- 연결 간격 분포: 약 7초를 중심으로 5~9초에 좌우 대칭 — 7초 ±2초 지터. "간격이 완벽할 필요는 없다, 비컨의 특성만 있으면 된다"의 실례입니다.
- 데이터 크기 분포: 한 곳에 강하게 몰림 — 매번 크기가 거의 같음.
- 지속성: 히스토그램이 평평 — 하루 내내 꾸준히 연결.
실무 포인트는 크기 분포의 튀는 값(outlier)입니다. 공격자는 보통 비컨만 시키다 가끔 실제 명령을 내리므로, 그때만 크기가 튑니다. 그래서 헌터는 CEO에게 이렇게 답할 수 있습니다.
CEO: "우리 뚫렸나?" → "네." CEO: "데이터가 빠져나갔나?" → "데이터상으로는 그렇게 보이지 않습니다." 대량 전송이 있었다면 거대한 튀는 값이 보였을 것이기 때문.
② ZenoRAT — 비컨을 안 하는 백도어¶
질문: 172.208.51.75의 연결 간격은? → 연결 단 4개에 약 7MB. 비컨이 아니라 연결 하나를 붙잡아 두는 롱 커넥션입니다. 공격자들은 원래 이렇게 하다가 → 탐지되자 비컨으로 옮겼고 → 비컨이 탐지되자 다시 연결 붙잡기로 돌아왔습니다. 그래서 둘 다 봐야 합니다.
③ dnscat2 — DNS 백도어¶
질문: 조회 수가 가장 많은 도메인은? 무작위 문자열은 무엇에 쓰이나? → dnscat2는 DNS 질의 자체를 통신 채널로 씁니다. 가장 많이 조회된 도메인 아래에 무작위 하위 도메인이 수없이 붙어 있습니다.
왜 무작위일까요? DNS 캐시 때문입니다. 매번 같은 이름이면 첫 결과가 내부 DNS 서버에 캐시되어, 다음 질의는 공격자 서버까지 가지 않습니다. 하위 도메인을 매번 다르게 하면 캐시가 없으니 질의가 매번 공격자의 DNS 서버까지 가고, 그 문자열에 데이터를 실어 나릅니다.
💡 보충 (강의 외)
Zeek dns.log에서 볼 단서: 한 도메인 아래 고유 하위 도메인 수가 비정상적으로 많음, 하위 도메인 이름이 길고 무작위(엔트로피 높음).
④ WhatTime — 정상인 척하는 이름¶
질문: C2의 FQDN은? 왜 이런 이름을? → 약간의 지터, 아주 작은 크기 분산, 강한 지속성. 시간당으로 묶으면 평균 약 168회/시간. 진짜 포인트는 도메인 timeserversync.com — "시간 서버 동기화"처럼 들려서 관리자가 이렇게 생각하게 만듭니다.
"정상 같은데… 막으면 뭔가 고장 날 것 같아."
조직에 섞여 들어가려고 고른 이름입니다. 이름이 그럴듯하다고 안심하면 안 됩니다.
⑤ FireStack2 — MIME 불일치¶
질문: MIME 데이터의 문제는? → "응답의 MIME 타입과 URI가 맞지 않는다"는 MIME 불일치가 가득합니다. MIME 타입은 "이 데이터는 이런 종류다"라는 꼬리표(예: image/jpeg)인데, 꼬리표와 실제 내용이 다르면 악성코드를 의심할 수 있습니다. 불일치가 2,868번 반복 — 한두 번이면 설정 실수일 수 있지만 이만큼 꾸준하면 의도된 위장 통신일 가능성이 큽니다.
RITA는 무료, AC-Hunter는 커뮤니티 에디션이 있습니다.
10. UEBA — 로그 여러 개를 묶어 "행동"을 본다¶
UEBA(User and Entity Behavior Analytics)는 사용자·시스템의 평소 행동을 배워 두고 거기서 벗어난 것을 찾습니다. John은 이 카드를 그냥 "AI"로 부를까 생각 중이며, EDR과 동급의 탐지 수단으로 봅니다. Back Doors & Breaches에서 이 카드가 3 리소스 포인트로 비싼 이유는 소셜 엔지니어링, 자격 증명 탈취, 신뢰 관계 침해, 내부자 위협, 피싱, 자격 증명 수집 등 잡는 공격이 많아서입니다.
왜 로그를 묶어야 하나 — JPCERT의 연구¶
일본 JPCERT는 공격자가 LOLBins·레지스트리 변경·PsExec을 쓸 때 실제로 무엇이 남는지 로그·Prefetch·레지스트리를 한꺼번에 추적했습니다. 결론:
로그 하나만 봐서는 전체 이야기를 알 수 없다.
그래서 UEBA는 여러 로그를 연결해 하나의 이야기로 만듭니다. 대표 예가 내부 패스워드 스프레이이고, 결국 잡으려는 것은 횡적 이동입니다. JPCERT의 LogonTracer는 SVC_WhiteNoise 계정이 여러 IP에 로그인한 모습을 그래프로 보여 주며, 위쪽에 4624(로그온 성공)·4625(로그온 실패) 같은 핵심 이벤트를 씁니다.
💡 보충 (강의 외)
LogonTracer는 4768(Kerberos TGT 요청), 4769(서비스 티켓 요청), 4776(NTLM 자격 증명 확인)도 씁니다. 모두 "누가 어디에 어떻게 로그인했나"를 보여 주는 이벤트이고, 계정–호스트를 잇는 그래프로 이상한 연결을 찾습니다. 이벤트 ID 전반: Windows 이벤트 ID.
"오탐은 없다" — 탐지 튜닝 기회¶
"오탐은 존재하지 않는다."
원래 오탐은 "참 조건이 아닌데 규칙이 울렸다"는 뜻이었지만, 사람들은 기대와 조금만 달라도 "오탐"이라며 규칙을 꺼 버리게 되었습니다. John의 제안은 이름을 "탐지 튜닝 기회(detection tuning opportunity)"로 바꾸는 것. 여러 시스템에 로그인하는 정상 서비스 계정 때문에 알림이 울린다면, 규칙을 끄지 말고 그 계정과 그 특성에 대한 예외를 넣어 다듬으세요. "그게 말 그대로 우리 일"입니다.
UEBA는 어떻게 동작하나¶
① 스태킹(Stacking) — 로그온 +1, 로그오프 −1, 기준값(예: 6)을 정합니다. 누군가 수천 대에 스프레이하면 숫자가 2,000을 넘겨 알림이 울립니다.
② AI — 정상을 배우고 내리막을 따라간다. John은 3D 지형도로 설명합니다. AI는 늘 가장 쉬운 길(내리막)로 갑니다.
- "John이 자기 계정에 로그인했다" → 아주 흔함. 정상을 뒷받침하는 데이터가 많으니 악성 판단은 오르막 — 가지 않음.
- "John이 갑자기 10대에 더 로그인했다. 평소 일인가?" → 아님. 판단이 내리막을 탐.
정상에서 벗어나는 데이터가 쌓이면 점점 내려가다 결정 기준선에서 "아마 악성"이라고 판단합니다. AI는 정상을 기준선(baseline)으로 삼고, John 표현으로 "게으르게" 가장 쉬운 길을 따라갈 뿐입니다. 예: Bob은 평소 30~40대에 로그인(기준선) — 그런데 갑자기 3GB를 끌어온다면? "블랙홀로 굴러떨어지는 내리막"입니다.
💡 보충 (강의 외)
지형도 비유는 머신러닝의 경사 하강법(gradient descent)과 이상 탐지(anomaly detection)를 쉽게 푼 것입니다. 실제 UEBA 제품은 사용자·그룹별 기준선을 만들고, 거기서 얼마나 벗어났는지(예: 표준편차 몇 배)를 점수로 매기는 방식이 많습니다.
11. Deep Blue CLI 실습¶
Deep Blue CLI는 Windows 이벤트 로그(.evtx)를 읽어 공격처럼 보이는 패턴을 찾는 PowerShell 스크립트입니다. 진짜 AI 도구는 아니지만, AI가 찾아볼 법한 비정상 패턴을 잘 보여 주는 대역입니다.
cd C:\Introlabs\DeepBlueCLI-master # (재구성) 실습 폴더로 이동
Set-ExecutionPolicy Unrestricted # 서명 안 된 스크립트 실행 허용
.\DeepBlue.ps1 .\evtx\new-user-security.evtx # (재구성) 샘플 로그 분석
Set-ExecutionPolicy Unrestricted— 기본 설정에서는 서명되지 않은 스크립트가 실행되지 않으므로 실습용으로 풉니다. 실무에서는 권장하지 않습니다..\DeepBlue.ps1 <evtx 파일>— 지정한 이벤트 로그를 분석합니다.
사례 ① 새 사용자 — SID는 같은데 이름이 다르다¶
사람은 긴 숫자·문자열을 무시하는 경향이 있습니다. 결과를 보면 아주 긴 SID(계정마다 붙는 고유 번호)가 두 항목에서 똑같은데, 이름은 하나가 -(대시), 다른 하나가 IEUser입니다. 그리고 대시 이름 계정이 로컬 Administrators에 추가되었습니다 — 반드시 조사할 신호입니다.
💡 보충 (강의 외)
관련 이벤트: 4720(사용자 계정 생성), 4732(보안 로컬 그룹에 구성원 추가 — 예: Administrators), 4781(계정 이름 변경). 이름이 바뀌어도 SID는 남으므로, 계정 추적은 이름보다 SID 기준이 안전합니다.
사례 ② 패스워드 게싱 — 관리자 계정은 잠기지 않는다¶
게싱은 보통 계정 잠금으로 막히는데, 여기서는 로그온 실패가 3,560번입니다. 대상이 로컬 Administrator이고, 기본 설정에서 로컬 관리자는 잠기지 않기 때문입니다. John의 추론:
"이건 SMB를 통한 원격 공격은 아닐 것이다."
기본 설정에서 로컬 Administrator로는 원격(SMB) 로그인을 할 수 없기 때문입니다. 그러니 RDP, 키보드 앞의 사람, 또는 정책 오설정일 가능성이 높습니다.
💡 보충 (강의 외)
게싱은 4625(로그온 실패)가 한 계정에 쌓이는 모양입니다. 4625의 로그온 유형으로 John의 추론을 바로 확인할 수 있습니다 — 10 = RDP(원격 대화형), 3 = 네트워크(SMB 등), 2 = 키보드 앞(대화형).
사례 ③ 패스워드 스프레이 — 한 출처에서 여러 계정으로¶
한 출처(Josh Wright 계정)가 아주 많은 다른 계정에 로그인을 시도했습니다.
게싱 = 한 계정에 실패가 몰림 / 스프레이 = 여러 계정에 실패가 퍼짐.
사례 ④ 난독화된 명령 — AI가 빛나는 곳¶
로그 속 난독화된 PowerShell 명령을 ChatGPT에 "이거 악성코드처럼 보이나요?"라고 넣으면 금방 풀어 줍니다(스크린샷 속 글자도 읽음).
| 난독화 종류 | AI가 알아낸 것 |
|---|---|
문자열 조립 + IEX |
조각을 이어 붙여 Invoke-Expression으로 실행하는 고전 기법 |
| Base64 | Base64 인코딩된 명령 |
| 0과 1의 나열 | 이진수 → 문자 변환, 쓰레기 문자 제거 후 정수→문자 → "매우 의심스러움" |
| 기호투성이 변수명 | 합법적 PowerShell 문법이지만 이상한 변수명·괄호로 분석을 고통스럽게 만듦 |
💡 보충 (강의 외)
이런 명령이 로그에 남으려면 PowerShell 로깅이 필요합니다. 4104(스크립트 블록 로깅)는 난독화가 풀린 실제 실행 내용까지 기록하는 핵심 이벤트입니다. 관련: PowerShell 크래들.
"이런 데에 AI를 써야 한다." — 우리 일을 쉽게 하고, 실제로 무슨 일이 일어나는지 이해하는 데.
로그 분석 실전 팁¶
- AD 로그가 접착제 — 특히 인증 쪽에서 모든 것을 잇습니다. 여러 포리스트·클러스터 AD·전이적 신뢰가 있을수록 UEBA로 묶어야 이해됩니다.
- 공격 경로를 그림으로, Top Talker(가장 활발한 워크스테이션·사용자·관리자 계정), 시간 분석(히트맵에서 15시 근처에 로그온이 튐).
- John의 실제 사용법: Deep Blue CLI로 스프레이 대상(예:
Bertha Schultz)을 찾고 → PowerShell로 그 계정 로그만 뽑아 → 아주 짧은 간격의 시도 패턴을 확인. - 후속 도구 DeepWhite CLI는 Sysmon 로그까지 분석합니다.
탐지 로직은 로그가 주는 데이터만큼만 좋다.
12. Windows 로그의 문제와 Sysmon¶
Windows 기본 로그는 왜 엉망인가¶
보안 로그: 로그인 기록처럼 유용한 것도 있지만 "새 로그온에 특수 권한 할당 — SYSTEM, NT AUTHORITY" 같은 항목이 넘쳐, 누가 로그인하려 했는지가 바로 안 보입니다. 게다가 John이 그룹 정책 보안 설정을 바꿔도 로그에는 "SYSTEM 계정이 바꿨다"로 남고, John의 특권 사용과 SYSTEM의 변경을 이어 주는 로그가 없습니다.
응용 프로그램 로그: "어떤 프로그램이 시작됐나"가 아니라 "타사 루트 목록 자동 업데이트 성공", "오프라인 다운레벨 마이그레이션 성공" 같은 것들뿐입니다. ESENT 항목을 AI에 넣으면 Extensible Storage Engine이라고 설명해 주지만, 정작 어떤 서비스가 붙었는지는 여전히 모릅니다.
"사용자가 Skype를 실행했다" 같은 보안에 정말 필요한 기록은 기본 로그에 없다.
로그의 90~95%는 쓰레기 — 로깅의 경제학¶
대부분의 조직에서 수집 로그 중 탐지 규칙·알림이 연결된 것은 5%도 안 됩니다. 그런데도 "전부 수집하라"는 이유는?
"벤더가 그렇게 말하기 때문이다. 많이 수집할수록 그들이 돈을 더 번다." — 대부분 수집량 기준 요금.
그래도 핵심 로그는 켭니다 — 4624/4634(로그온/로그오프), 객체 접근(ACL), 프로세스 생성과 사용. 다만 John은 Windows 방화벽 로그는 켜지 말라고 합니다(너무 시끄러움).
💡 보충 (강의 외)
4634는 로그오프, 4647은 사용자가 직접 로그오프 시작. 4624와 짝을 맞추면 세션 길이를 계산할 수 있습니다.
명령줄 로깅을 켜는 게 얼마나 어려운가¶
John은 외우라는 게 아니라 얼마나 황당한지 보여 주려고 절차를 읽습니다: ① 프로세스 생성 감사 켜기 → ② "프로세스 생성 이벤트에 명령줄 포함" 켜기 → ③ 고급 감사 정책이 기본 정책에 덮어쓰이지 않는지 확인 → ④ 로그 크기 늘리기 → ⑤ 관리 템플릿에서 켜기 → ⑥ 고급 감사 → 세부 추적에서 켜기 → ⑦ 덮어쓰기 방지용 세 번째 설정까지.
"그리고 모두가 기뻐했다(And there was much rejoicing)."
PowerShell 로깅도 설정이 필요하지만 스크립트로 묶어 한 번에 할 수 있어 그나마 낫습니다. 결론은 "몇 초 만에 다 되면 좋지 않을까? → Sysmon".
💡 보충 (강의 외)
명령줄 로깅을 켜면 4688(새 프로세스 생성)에 명령줄 전체가 기록됩니다. PowerShell은 4104(스크립트 블록)·4103(모듈 로깅).
Sysmon — "여러분이 찾던 바로 그 로그"¶
Sysmon은 Sysinternals의 마크 러시노비치가 만든 도구입니다. 아이러니는 2014년에 이미 우리가 원하던 것(어떤 프로그램이 시작됐나, 누가 시작했나, 네트워크 연결, 부모 프로세스)을 다 담고 있었는데, Microsoft가 이제야 최신 Windows에 기본 포함하기 시작했다는 점입니다.
로그 위치: 이벤트 뷰어 → 응용 프로그램 및 서비스 로그 → Microsoft → Windows → Sysmon → Operational
프로세스 생성 예 — Metasploit으로 만든 파일이 Sysmon에 찍힌 모습
| 필드 | 값 (예시) | 의미 |
|---|---|---|
| Image | C:\trustme.exe |
실행 파일과 전체 경로 |
| OriginalFileName | ab.exe |
파일 안에 기록된 원래 이름 |
| Product / Company | Apache HTTP Server / Apache | 만든 곳 |
| Hashes | (MD5/SHA256 등) | 파일 해시 |
| ParentImage | cmd.exe |
부모 프로세스 |
OriginalFileName이 ab.exe인 이유: Metasploit은 악성코드를 Apache Bench(ab.exe)라는 정상 유틸리티에 넣습니다. 그래서 이름은 trustme.exe인데 원래 이름은 ab.exe, 제작사는 Apache로 찍힙니다.
핵심 단서
파일 이름 ≠ OriginalFileName 자체가 강력한 단서입니다. 공격자가 이름을 바꿔도 파일 안의 원래 이름은 남습니다.
배포와 활용: 그룹 정책(GPO)으로 쉽게 배포, Winlogbeat로 로그 반출, 분석 도구 예 SOC Prime, 그리고 Sigma — 탐지 규칙을 한 번 쓰면 거의 모든 SIEM용으로 변환할 수 있는 공용 언어. (덤: Exchange 로깅도 기본으로 꺼져 있음.)
💡 보충 (강의 외) — 자주 쓰는 Sysmon 이벤트 ID
1 프로세스 생성 · 3 네트워크 연결 · 7 이미지(DLL) 로드 · 8 CreateRemoteThread(다른 프로세스에 스레드 주입) · 10 프로세스 접근(예: LSASS 접근 → 자격 증명 덤프 단서) · 11 파일 생성 · 13 레지스트리 값 설정 · 22 DNS 질의. 무엇을 기록할지는 설정 파일로 정하며, SwiftOnSecurity나 Olaf Hartong(sysmon-modular)의 공개 설정으로 시작하는 경우가 많습니다. 관련: LSASS 덤프 · 프로세스 인젝션.
Sysmon 실습 (개요)¶
목표는 악성코드를 Sysmon의 눈으로 보는 것 — 그래서 "Sysmon을 쓰고, 설정을 만들고, 환경에 배포해야 한다"는 결론에 이르게 하는 것입니다. 흐름은 1일차 AppLocker 실습과 비슷합니다: Windows에서 실시간 보호·방화벽을 끄고 관리자 패스워드를 바꾼 뒤, Kali에서 테스트 파일을 만들어 옮기고, 실행 전에 Windows에 Sysmon을 설치한 다음 실행해 Sysmon 로그를 확인합니다.
이번에도 브라우저 새로고침 금지(관리자 패스워드 변경 후 Guacamole 재로그인 실패 → VM Destroy 후 재시작).
John은 실습 해설을 3일차 시작 때 하겠다고 미뤘습니다. 실제 Sysmon 로그 해설(악성 파일이 LSASS에 스레드를 만들며 해시를 뽑는 모습, Pass-the-Hash가 Sysmon에 어떻게 보이는지)은 3일차에서 이어집니다. 마지막 AMA는 수강생들과 Back Doors & Breaches 경쟁 모드 게임을 하며 진행되어 따로 정리하지 않았습니다.
2일차 정리¶
| 주제 | 핵심 |
|---|---|
| Egress 분석 | 내용은 암호화돼도 행동 패턴은 보인다 |
| NetFlow / ASA 로그 | 손으로 하면 괴롭다, AI는 맥락을 줘야 쓸모 있다 |
| Zeek | 일관된 메타데이터 로그(PCAP 약 1/10), NAT 앞단 수집 |
| 비컨 / 롱 커넥션 | 규칙적 간격 + 일정한 크기, 지터·쪼개기도 총합으로 드러남 |
| RITA / AC-Hunter | 비컨 수학(K-means), 점수, 정상 비컨도 조사 |
| ASN | 나쁜 IP는 소수 ASN에 몰려 있다 |
| UEBA | 로그를 묶어서 평소에서 벗어난 것을 찾는다, 오탐은 튜닝 기회 |
| Deep Blue CLI | 게싱(한 계정) vs 스프레이(여러 계정), 난독화는 AI로 분석 |
| Windows 로그 / Sysmon | 기본 로그는 엉망·90%는 쓰레기, Sysmon이 필요한 정보를 준다 |
이미 들어온 공격자는 "나가는 트래픽의 행동"(Zeek + RITA)과 "여러 로그를 묶은 행동"(UEBA)으로 찾는다. 그리고 그 탐지는 로그 품질만큼만 좋으므로, 쓸모없는 로그를 줄이고 Sysmon처럼 정말 필요한 로그를 갖춰라.