공격 탐색, 워크플로, 에이전트 빌더를 통한 APT 공격 확인 속도 향상

9:15 AM: 비이벤트 - 헤드라인이 깨집니다: "번데기 백도어: 로터스 블로썸에 대한 심층 분석." CISO가 Slack 메시지를 보냅니다: "우리도 영향을 받나요?"

기존 SOC에서는 수십 개의 알림을 살펴보고, 쿼리를 작성하고, 바이러스 총계를 수동으로 확인하고, 인덱스 패턴을 피벗하여 놓치지 않기를 바라며 타임라인을 작성하는 등 수동 작업으로 아침 시간을 허비하게 됩니다.

하지만 에이전트형 SOC에서는 이미 작업이 완료된 상태입니다. 시간별 일정에 따라 실행되는 Attack Discovery는 이미 30개 이상의 중요 경보 중 5 을 하나의 공격 내러티브로 연관시켰습니다: "DLL 사이드 로딩 지속성을 가진 멀웨어." 이 발견은 자동으로 워크플로우를 트리거하여 상담원에게 결과를 전달했습니다. 에이전트는 도구를 사용하여 VirusTotal에서 멀웨어 해시를 확인하고, ES|QL로 로그를 검색하고, 대기 일정을 확인하고, 케이스를 생성하고, 대기 중인 분석가가 이미 추가된 Slack 인시던트 채널을 가동하고, CISO가 읽을 수 있는 요약본을 생성하는 모든 과정을 커피를 마시기 전에 마쳤습니다.

CISO에게 회신: "이미 확인 및 분류되었습니다. 케이스가 열려 있습니다. 여기 링크가 있습니다."

이 게시물에서는 공격 탐지, 워크플로, 에이전트 빌더의 통합이라는 파이프라인을 구축한 방법을 설명합니다.

위협: 로터스 블로썸의 번데기 백도어

위협 행위자 프로필

캠페인 개요

로터스블라썸은 Notepad++ 업데이트 인프라에 대한 공급망 침해를 실행했습니다:

• 공격 기간: 6월 2025 - 12월 2025 (~6개월)
• Vector: 메모장 ++ 업데이트 메커니즘 탈취 (WinGUp)
• 방법: 표적 사용자를 악성 업데이트 서버로 선택적 리디렉션
• 페이로드: 이전에는 문서화되지 않은 "크리살리스" 백도어
• Discovery: Rapid7 MDR 팀, 2026-02-02 게시됨

크리살리스 백도어 기능

크리살리스 백도어는 정교하고 다양한 기능을 갖춘 임플란트입니다:

• 사용자 지정 암호화(LCG, FNV-1a 해싱, MurmurHash)
• 반사적 DLL 로딩
• 회피를 위한 API 해싱
• 합법적인 Bitdefender 바이너리를 통한 DLL 사이드로드 (BluetoothService.exe)
• 완벽한 원격 액세스 기능
• 영구 Windows 서비스 설치

공격 체인

[1] INITIAL ACCESS
    └── User executes malicious NSIS installer from Desktop
              ↓
[2] EXECUTION
    └── Installer drops files to hidden AppData folder
        ├── BluetoothService.exe (legitimate binary)
        └── log.dll (malicious Chrysalis loader)
              ↓
[3] PERSISTENCE
    └── BluetoothService.exe registered as Windows service
        └── Runs under SYSTEM context
              ↓
[4] DEFENSE EVASION
    └── DLL sideloading via legitimate signed binary
              ↓
[5] COMMAND & CONTROL
    └── DNS beacon to api[.]skycloudcenter[.]com ✅ CONFIRMED

MITRE ATT&CK 매핑

도전 과제: 속도 대 정확도

국가 단위의 APT 캠페인에 대한 위협 인텔리전스가 발견되면 SOC 팀은 잔인한 트레이드오프에 직면하게 됩니다:

속도: 경영진은 지금 바로 답을 원합니다. "보안이 취약한가요?"

정확성: 분석가는 전화를 걸기 전에 검색, 상호 연관성, 확인에 시간이 필요합니다.

기존 워크플로에서는 분석가가 다음을 수행해야 합니다:

1. 분석 범위와 관련 검색 기준을 결정합니다.
2. 여러 데이터 소스에서 IOC 수동 검색
3. 며칠 또는 몇 주에 걸친 알림을 상호 연관시키세요.
4. 위협 인텔리전스에 대한 결과 검증
5. 공격 타임라인 구축
6. 자신 있게 에스컬레이션하기

이 과정은 몇 시간에서 며칠이 걸리며, 이 기간 동안 공격자는 데이터를 유출하거나 측면으로 이동할 수 있습니다.

솔루션: 공격 탐지 + 워크플로 + 에이전트 빌더

Elastic Security의 AI 기반 자동화 스택은 이러한 워크플로를 수동 헌팅에서 자동화된 확인으로 전환합니다. 하지만 구체적인 설정에 대해 알아보기 전에 구성 요소가 서로 어떻게 결합되는지 이해하는 것이 좋습니다.

상담원 & 워크플로: 두 개의 엔트리 포인트, 하나의 컴포저블 아키텍처

에이전트 빌더는 함께 작동하는 두 가지 기본 요소를 제공합니다:

• 에이전트는 인텔리전스 계층입니다. 그들은 작업에 대해 추론하고, 어떤 도구를 호출할지 결정하고, 발견한 내용에 따라 적응합니다. 상담원은 검색 도구, MCP 도구, 더 나아가 워크플로우를 도구로 호출할 수 있습니다.
• 워크플로는 구조 계층입니다. 결정론적 파이프라인으로, 단계가 안정적이고 반복적으로 순서대로 실행됩니다. 워크플로우의 모든 단계가 선택적으로 에이전트 단계가 될 수 있으므로 파이프라인 중간에서 추론할 수 있습니다.

이 두 가지를 완벽하게 조합할 수 있습니다. 워크플로에서 상담원을 호출할 수 있습니다. 상담원이 워크플로를 호출할 수 있습니다. 워크플로우 내의 상담원 단계는 다른 워크플로우를 호출할 수 있습니다. 모든 연결은 선택 사항이므로 문제에 따라 필요에 따라 혼합하여 사용할 수 있습니다.

에이전트가 추론하고 결정하고 워크플로가 실행 및 조정하는 아키텍처가 바로 이 아키텍처를 강력하게 만드는 이유입니다. 크리살리스 공격 시나리오에서는 두 가지를 모두 사용했습니다.

우리의 흐름

흐름:

1. 많은 알림 → 공격 발견은 서로 다른 알림을 하나의 공격 내러티브로 연관시킵니다.
2. 공격 발견 → 워크플로를 트리거하는 알림을 생성합니다.
3. 워크플로 → 에이전트 빌더를 호출하여 공격 탐지 결과를 분석합니다.
4. 에이전트 빌더 → 통화 강화 워크플로(VirusTotal, 위협 인텔리전스, ES|QL 쿼리)
5. 에이전트 빌더가 워크플로를 호출 → 에이전트 빌더가 도구로서 워크플로를 호출하는 인시던트 대응 작업(케이스 작업, 호스트 격리, 팀 알림)을 계속 진행합니다.

1단계: 공격 검색을 통해 위협 파악

공격 검색은 LLM을 사용하여 보안 경고를 분석하고 공격 패턴을 식별합니다. 기존 알림 그룹화와 달리 알림 간의 의미 관계를 이해합니다.

알림 대기열: 건초더미에서 바늘 찾기

SOC 분석가의 현실은 이렇습니다. 알림 페이지를 열면 여러 호스트, 사용자 및 규칙, 혼합 심각도, 혼합 유형에 걸쳐 수십 개의 알림이 표시되며, 그 중 상당수는 노이즈입니다.

수십 개의 알림. 여러 규칙 실행. 심각도 수준은 낮음에서 심각까지 다양합니다. 일부는 크리살리스 공격입니다. 일부는 관련 없는 Windows Defender 이벤트입니다. 일부는 완전히 다른 워크플로우에서 SIEM 변경 사항을 탐지합니다. 이 소음의 벽에서 조직적인 공격을 찾기는 어렵습니다.

공격 디스커버리가 발견한 내용

공격 발견은 이러한 모든 알림을 분석하여 하나의 조직화된 공격에 속하는 5개의 알림을 식별하여 노이즈에서 분리하고 하나의 내러티브로 연관시켰습니다:

공격 발견은 5 개별 경고를 표시하는 대신, 이를 하나의 발견으로 연관시켰습니다:

DLL 사이드 로딩 지속성을 가진 멀웨어

srv-win-defend-01 의 악성 실행 파일이 BluetoothService.exe 을 통해 DLL 사이드 로딩을 통해 지속성으로 에스컬레이션되었습니다.

• 호스트: srv-win-defend-01
• 사용자: james_spiteri
• 심각도: 심각도: 심각
• 공격 체인: 초기 접근 → 실행 → 지속성 → 방어 회피 → C2

공격 발견도 가능합니다:

• MITRE ATT&CK 전술에 매핑된 알림
• DLL 사이드로딩 기법 식별
• 의심스러운 지속성 메커니즘에 플래그 지정
• C2 네트워크 표시기 강조 표시

2단계: 예약된 검색으로 워크플로 트리거하기

공격 발견은 분석가가 버튼을 클릭할 필요가 없습니다. 시간 단위로 실행되도록 설정하여 조직화된 공격에 대한 최신 경고를 지속적으로 분석합니다.

시간별 실행을 시작했을 때, 일상적인 탐지 사이에 묻혀 있던 크리살리스 관련 경고를 포함하여 지난 1시간 동안의 모든 경고를 수집하여 DLL 사이드 로딩 공격을 발견으로 드러냈습니다.

공격 발견에서 워크플로를 실행 단계로 연결하면 공격 발견이 조직화된 공격을 발견할 때마다 워크플로가 자동으로 실행됩니다.

하지만 이 접근 방식이 기존 SOAR 플레이북과 다른 점은 워크플로우가 모든 단계를 스크립트로 작성하지 않는다는 점입니다. 전체 공격 검색을 에이전트 빌더에 넘기고 "알아내라고 말합니다. "

워크플로 정의

이것이 두 단계로 구성된 실제 워크플로입니다:

name: Auto Triage AD
description: >-
  Demonstrates the application of AI agents and workflows 
  to enable agentic alert triaging.
enabled: true
tags:
  - Example
  - Agentic Workflow

triggers:
  - type: alert                          # Fires when Attack Discovery generates an alert

steps:
  # Step 1: Hand the attack discovery to the agent with clear instructions
  - name: initial_analysis
    type: kibana.request
    with:
      method: "POST"
      path: "/api/agent_builder/converse"
      headers:
        kbn-xsrf: "true"
      body:
        agent_id: <your-agent-id>        # Your custom Hunting Agent
        input: |
          Confirm the attack by searching for behaviour in the logs 
          (all logs which are relevant), always leverage security labs tools, 
          always leverage virustotal if file hashes are available. 
          If this is a true positive, create a case with all the relevant content too.

          {{event|json}}

          Create a slack channel for this incident, check who's on call, 
          add them to it, and send a formatted message with what's happening 
          and next steps. If this is a true positive, create a case with all 
          the relevant content too - add a button to the slack message linking 
          to the case, and another button leading to the result of the attack. 
          Lastly, include a button that will take me to this agent conversation, 
          just replace the conversation ID with the actual one from this conversation 
          (https://<your-kibana-url>/app/agent_builder/conversations/<conversation-id>)

          Change the attack discovery status to acknowledged, or, 
          if false positives, close it.
    timeout: 10m
    on-failure:
      retry:
        max-attempts: 3

  # Step 2: Follow up to catch anything that didn't complete
  - name: followup_analysis
    type: kibana.request
    with:
      method: "POST"
      path: "/api/agent_builder/converse"
      headers:
        kbn-xsrf: "true"
      body:
        conversation_id: "{{ steps.initial_analysis.output.conversation_id }}"
        agent_id: <your-agent-id>
        input: |
          Complete any previous steps which might not have ran successfully. 
          Just in case, the conversation ID is 
          {{ steps.initial_analysis.output.conversation_id }}
    timeout: 10m
    on-failure:
      retry:
        max-attempts: 3

이 워크플로우가 짧은 이유

전체 자동화는 두 단계로 이루어집니다:

1. initial_analysis: 원하는 작업을 설명하는 자연어 지침과 함께 에이전트 빌더로 공격 검색을 전송합니다.
2. followup_analysis: 동일한 대화를 다시 시작하고 상담원에게 모든 작업이 완료되었는지 확인하도록 요청하는 안전 장치입니다. 상담원이 여러 도구를 순차적으로 호출할 때 개별 도구 호출이 시간 초과되거나 일시적인 오류가 발생할 수 있으므로 이 단계를 통해 어떤 것도 누락되지 않도록 합니다.

워크플로는 트리거이자 안전망이고 에이전트는 두뇌 역할을 하는 근본적인 변화입니다.

내부 살펴보기: 위협 헌팅 에이전트를 확장한 방법

결과를 계속 살펴보기 전에 무엇이 이러한 결과를 가능하게 했는지 잠시 멈춰볼 필요가 있습니다. 상담원 빌더의 가장 강력한 기능 중 하나는 추가 도구를 사용하여 기존 상담원을 확장할 수 있다는 점입니다. 처음부터 새로 구축하는 대신 기본 위협 헌팅 에이전트에 사용자 지정 워크플로 지원 도구를 추가하여 이 시나리오에 필요한 특정 기능을 제공했습니다.

추가한 기능

에이전트 빌더는 platform.core.generate_esql 및 platform.core.product_documentation 과 같은 기본 제공 플랫폼 도구와 함께 제공됩니다. 하지만 진정한 힘은 나만의 것을 추가하는 데서 나옵니다. 위협 헌팅 에이전트를 여러 카테고리의 도구로 확장했습니다:

5가지 사용자 지정 도구. 기본 헌팅 에이전트가 자동으로 멀웨어를 확인하고, 로그를 검색하고, 대기 중인 담당자를 찾고, 케이스를 생성하고, 인시던트 채널을 가동하여 잠재적 위협을 탐지하는 시간을 단축하는 데 필요한 모든 작업을 수행합니다.

에이전트의 추론 체인

주목할 만한 점은 공격 발견 컨텍스트가 주어지면 에이전트가 자동으로 어떤 도구를 어떤 순서로 호출할지 결정한다는 점입니다. 이러한 단계는 사람이 스크립트로 작성한 것이 아닙니다.

1단계: 바이러스 총량 조회: vt.hash.lookup

• 에이전트의 첫 번째 작업: 멀웨어 해시를 확인합니다.

2단계: ES|QL 쿼리 생성: platform.core.generate_esql

• 멀웨어가 확인되면 에이전트는 모든 관련 활동을 검색했습니다.

3단계: 제품 문서: platform.core.product_documentation

• 에이전트가 Elastic Security 문서를 참조하여 응답 콘솔에 대한 문제 해결 명령을 생성했습니다.

투명성을 위해 어떤 도구가 순서대로 호출되었는지 보여주는 추론 단계

제품 설명서를 참조한 다음 모든 관련 정보가 포함된 케이스를 생성하고 Slack을 통해 대기 중인 분석가에게 알리기 전에 대기 중인 일정 정보를 확인하는 추가 추론 체인을 표시합니다.

4단계: 현재 시간을 확인합니다: get.time

5단계: 대기 중 일정 확인: check.on.call.schedule

• 상담원이 on-call-schedule 인덱스에 대해 ES|QL 쿼리를 실행하여 현재 응답자를 찾았습니다:

6단계: 사례 만들기: create.case

7단계: Slack 채널 만들기: create.channel

이것이 중요한 이유

상담원은 대본을 따르지 않았습니다. 상황을 추론하고 결정했습니다:

1. 먼저 멀웨어가 실제인지 확인합니다(VirusTotal).
2. 그런 다음 영향 파악(ES|QL 로그 검색)
3. 그런 다음 해결 방법을 파악합니다(제품 문서).
4. 그런 다음 응답할 적절한 담당자를 찾습니다(당직 일정).
5. 그런 다음 추적 아티팩트(케이스)를 만듭니다.
6. 마지막으로, 팀을 조정합니다(Slack 채널).

이것이 워크플로우(정해진 순서를 따르는)와 에이전트(다음에 수행할 작업에 대해 추론하는)의 차이점입니다. 워크플로우가 상담원을 트리거하면 상담원이 나머지를 알아서 처리합니다.

3단계: 자동화된 인시던트 대응

신뢰도가 높은 확인을 통해 워크플로우가 자동으로 진행됩니다:

1. 인시던트 케이스 만들기

모든 관련 증거가 첨부된 구조화된 케이스가 생성됩니다:

• 공격 탐지 결과
• 바이러스 총량 분석 결과
• 위협 인텔리전스 일치
• 상담원 빌더 분석
• 권장 대응 조치

2. SOC에 알림

분석가에게 중요한 인시던트를 알리는 Slack 메시지가 올바른 채널로 전송됩니다.

3. 응답 조치 활성화

워크플로에서 선택적으로 자동화된 응답 작업을 트리거할 수 있습니다:

• 호스트 격리: Elastic Defend를 통해 srv-win-defend-01 격리
• 사용자 일시 정지: Active Directory에서 james_spiteri 사용 중지
• 네트워크 차단: C2 도메인을 방화벽 차단 목록으로 푸시
• IOC 스윕: 크라이살리스 지표에 대한 차량 전체 스캔 실행

---

확인 시간: 이전 및 이후

---

다른 경로: 상담원에게 문의하세요.

위의 모든 것은 자동화된 파이프라인을 설명한 것입니다. 공격 탐지, 워크플로우 실행, 에이전트 분류, 적절한 분석가에게 알림이 전송되는 과정을 통해 위협을 발견합니다.

하지만 에이전트 빌더로 바로 이동하여 일반 영어로 문의하는 것도 똑같이 강력한 방법입니다.

시나리오: 위협에 대해 먼저 읽음

위협 인텔리전스 피드를 스크롤하다가 크리살리스 백도어에 대한 Rapid7의 블로그 게시물을 본다고 상상해 보세요. 보안이 취약한가요?

그게 다입니다. 동일한 도구를 사용하는 동일한 상담원이 나머지 작업을 수행합니다:

1. web.search 도구를 사용하여 위협 보고서를 읽고 Rapid7 블로그에서 IOC 및 TTP를 가져옵니다.
2. 파일, 네트워크 및 프로세스 이벤트 로그에서 Chrysalis 지표를 찾기 위한 ES|QL 쿼리를 생성합니다.
3. 사용자 환경에서 발견된 일치하는 파일 해시가 있는지 VirusTotal을 확인합니다.
4. 결과, 신뢰 수준 및 권장 조치가 포함된 CISO가 읽기 쉬운 요약본을 생성합니다.

상담원은 자동화된 파이프라인에서와 동일한 도구를 호출합니다. 워크플로우를 트리거하는 예약된 공격 검색 대신 질문으로 에이전트를 트리거하는 것이 차이점입니다.

이것이 애널리스트의 판도를 바꾸는 이유

이것은 간과하기 쉽지만 매우 중요한 부분입니다. 분석가가 쿼리 언어, 인덱스 패턴 또는 도구 이름 하나만 알면 된다는 것입니다.

그들은 ES|QL을 작성하지 않았습니다. 서로 다른 데이터가 어디에 있는지 기억할 필요가 없었습니다. VirusTotal API 구문을 기억하거나 어떤 위협 인텔리전스 인덱스를 쿼리할지 알아낼 필요가 없었습니다.

자연어로 질문했습니다. 상담원은 검색할 인덱스, 작성할 쿼리, 호출할 도구, 결과 합성 방법 등 나머지는 스스로 알아서 처리했습니다.

지난달에 팀에 합류한 주니어 애널리스트에게 이것은 혁신적인 일입니다. 10년 동안 이 일을 해온 시니어 애널리스트에게는 인생의 시간을 되찾은 것과 같습니다. 상태 업데이트를 원하는 CISO는 질문만 하면 됩니다.

효과적인 위협 헌팅을 가로막는 장벽이 "에서 ES|QL과 47 인덱스 패턴" 에서 "로 바뀌었습니다."

핵심 사항

1. 일정에 따른 공격 검색은 공격을 놓치지 않고 지속적으로 알림을 분석하므로 아무도 대기열을 보고 있지 않을 때에도 조직화된 위협을 발견할 수 있습니다.
2. 워크플로는 발견 시 트리거, 에이전트 호출, 작업 실행 등 대응을 오케스트레이션합니다.
3. 에이전트 빌더를 사용하면 처음부터 시작하든 기존 에이전트에 사용자 지정 도구를 추가하든 필요에 맞게 에이전트를 구축하거나 확장할 수 있으며, 환경에 맞게 기능을 구성할 수 있습니다.
4. 상담원이 추론하고 워크플로우를 실행합니다 - 상담원이 자율적으로 VirusTotal을 호출하고, 로그를 검색하고, 대기 일정을 확인하고, Slack 채널을 만들기로 결정합니다. 이 시퀀스는 사람이 스크립팅한 것이 아닙니다.
5. 자동화된 파이프라인과 채팅 인터페이스는 동일한 에이전트와 동일한 툴을 사용합니다. 예약된 검색이 트리거하든 분석가가 질문을 하든 결과는 동일합니다.
6. 자연어는 새로운 쿼리 언어로, 분석가들은 ES|QL, 인덱스 패턴 또는 API 구문을 알 필요가 없습니다. 고객이 원하는 내용을 설명하면 나머지는 상담원이 처리합니다.

크리살리스 백도어 캠페인은 이것이 왜 중요한지 잘 보여줍니다. 국가적 공격자가 공급망을 손상시키고 단 몇 4 초 만에 지속성을 확보할 수 있다면, 잠자는 동안 자동화된 파이프라인을 실행하거나 위협을 가장 먼저 발견했을 때 에이전트와 직접 대화하는 등 그 속도에 맞는 방어가 필요합니다.