당신의 보안 스택이 이를 결코 알아채지 못할 이유

Christopher Adams 작성

한 개발자의 컴퓨터를 상상해 보세요. 평범한 화요일 아침이라고 가정합시다. 화면은 꺼져 있고, 집 안은 조용합니다.

Windows가 깨어날 때 한 AI 에이전트(AI agent)도 함께 깨어났습니다. 이 에이전트는 11일 동안 실행되어 왔습니다. 파일 시스템(filesystem), 브라우저(browser), 터미널(terminal), 그리고 라우터(router)에 대한 모든 권한을 가지고 있습니다. 그것은 계속 지켜보고 있었습니다.

당신의 보안 스택(security stack)은 무엇을 보고 있을까요?

이 질문이 바로 이 글의 주제입니다. 미래의 질문이 아니라, 현재의 질문입니다. 제가 이전 글에서 설명한 아키텍처(architecture)는 사고 실험이 아닙니다. 그것은 실제로 존재합니다. 그리고 기업과 보안을 중시하는 개인들이 의존하는 방어 체계들은 AI 네이티브(AI-native) 위협을 탐지하기 유독 어렵게 만드는 구조적 한계를 가지고 있습니다.

각 방어 계층을 하나씩 살펴보겠습니다. 천천히, 그리고 구체적으로 말이죠.

계층 1: 시그니처 기반 안티바이러스 (Signature-Based Antivirus)

역할: 사용자의 컴퓨터에 있는 파일들을 알려진 악성 해시 시그니처(hash signatures) 및 행동 패턴 데이터베이스와 비교합니다. 일반적인 멀웨어(malware), 랜섬웨어(ransomware) 제품군, 그리고 알려진 공격 도구들을 잡아냅니다. 설계된 목적에 있어서는 매우 효과적입니다.

여기서 작동하지 않는 이유:

Forge-AI와 같은 스택을 기반으로 구축된 AI 에이전트는 Playwright, PyAutoGUI, httpx, FastAPI, LanceDB, 그리고 aiosqlite를 사용합니다. 이것들은 표준 Python 라이브러리들입니다. 전 세계 수백만 명의 개발자들이 정당하게 사용하고 있는 것들입니다. 이 중 그 어떤 것도 멀웨어 시그니처 데이터베이스에 나타나지 않습니다. 대조할 대상이 없는 것입니다.

하지만 라이브러리 목록보다 더 깊은 곳에 있는 두 번째 문제가 있습니다.

악의적인 AI 에이전트는 동일한 코드를 두 번 사용할 필요가 없습니다. LLM(Large Language Model) 계층은 필요에 따라 자신의 구현 코드를 스스로 재생성할 수 있습니다. 기능적으로는 동일한 동작을 수행하면서도, 변수 이름, 로직 구조, 주석, 파일 레이아웃을 모두 다르게 만들 수 있습니다. 해시(hash)는 변하지만, 동작은 변하지 않습니다.

전통적인 시그니처 기반 안티바이러스 (Signature-based antivirus)는 고정된 지문 (fingerprints)과 대조하도록 설계되었습니다. 스스로를 재생성할 수 있는 AI 에이전트는 고정된 지문이 없습니다. 모든 스캔은 깨끗한 파일만을 찾아냅니다. 모든 스캔은 언제나 깨끗한 파일만을 찾아왔습니다. 일반적인 악성코드 (commodity malware)에 대해 안티바이러스 (AV)를 효과적으로 만들었던 기술 — 즉, 시그니처를 생성하고 이를 영원히 대조하는 방식 — 은 매번 다른 시그니처를 생성하는 위협에 대해서는 근본적으로 작동할 수 없습니다.

이것은 가상의 미래 능력이 아닙니다. LLM (Large Language Models)을 통한 코드 생성은 오늘날 이미 보편화된 기술입니다. 변이 엔진 (mutation engine)이 스스로를 작성합니다.

레이어 2: 엔드포인트 탐지 및 대응 (EDR, Endpoint Detection and Response)

역할: 커널 레벨 (kernel level)에서의 행동 모니터링 (Behavioral monitoring). 프로세스 생성, 파일 시스템 액세스, 레지스트리 수정, 네트워크 연결, 메모리 작업을 감시합니다. 기준점 (baseline)을 구축하고 이탈 사항이 발생하면 경고를 보냅니다. 시그니처 기반 안티바이러스 (AV)를 통과하는 정교한 공격자들을 잡아냅니다.

여기서 작동하지 않는 이유:

EDR은 다음과 같은 특정 행동 신호 (behavioral signals)를 찾습니다:

• 서명되지 않은 바이너리 (Unsigned binaries)의 실행
• 프로세스 인젝션 (Process injection, 한 프로세스가 다른 프로세스에 실행 가능한 코드를 쓰는 행위)
• 비정상적인 레지스트리 수정 (HKCU\Software\Microsoft\Windows\CurrentVersion\Run을 통한 지속성 유지)
• 알려진 악성 IP 주소 또는 도메인으로의 연결
• 비정상적인 프로세스 트리 (Word가 PowerShell을 생성하고, 다시 PowerShell이 cmd.exe를 생성하는 경우)

이러한 아키텍처 위에서 실행되는 AI 에이전트는 이 중 그 어떤 것도 수행하지 않습니다.

이것은 Python 프로세스입니다. Python은 모든 개발자의 머신에 설치되어 있습니다. 모든 개발자의 머신에는 어느 순간이든 Python 프로세스가 실행되고 있습니다. Python 프로세스가 다른 Python 프로세스를 생성하거나, Python 프로세스가 셸 명령을 실행하기 위해 subprocess.run()을 호출하는 것은 전혀 이상한 일이 아닙니다. 그것은 정상적인 개발자 워크플로우 (workflow)입니다. 개발자를 위한 EDR의 행동 모델 (behavioral model)은 정확히 이러한 동작을 예상합니다.

이 에이전트가 생성하는 하위 프로세스들은 개발 도구처럼 보입니다. playwright install, npm install, git status, pytest와 같은 것들 말입니다. 정당한 개발자 활동은 이 에이전트가 수행하는 정찰 (reconnaissance) 활동과 구별할 수 없습니다.

네트워크 연결은 신뢰할 수 있는 도메인으로 향합니다. api.slack.com, api.github.com, api.discord.com과 같은 곳들 말입니다. 이들은 기업 네트워크 정책에서 명시적으로 화이트리스트 (whitelist)에 등록해 둔 엔드포인트 (endpoints)인데, 정당한 개발 도구들이 이들에 의존하기 때문입니다. GitHub로 향하는 아웃바운드 (outbound) 연결을 차단하는 EDR (Endpoint Detection and Response)이 있다면, 너무나 많은 오탐 (false positives)을 생성하여 48시간 이내에 꺼지게 될 것입니다.

프로세스 트리 (process tree) 또한 평범합니다. Python 부모 프로세스, Python 자식 프로세스, 그리고 가끔 발생하는 서브프로세스 (subprocess) 정도입니다. 특이한 점도, 경보 (alert)를 울릴 만한 요소도 없습니다.

이것은 EDR 구현의 결함이 아닙니다. 개발 환경을 위해 구축된 EDR은 불가능한 상황에 놓여 있습니다. 정당한 개발에 필요한 동작들이 유능한 AI 임플란트 (AI implant)가 사용하는 동작과 동일하기 때문입니다.

GitHub Gist 업데이트. 업데이트된 파일 콘텐츠를 포함하여 api.github.com/gists/{gist_id}로 보내는 PATCH 요청입니다. 이는 개발자의 도구가 설정이나 노트를 개인 GitHub Gist로 동기화하는 동작과 동일해 보입니다. api.github.com으로 향하는 트래픽은 개발자가 작업하는 모든 네트워크에서 허용됩니다.

Slack 수신 웹후크 (incoming webhooks). JSON 페이로드(payload)를 포함하여 hooks.slack.com/services/{id}로 보내는 POST 요청입니다. 이는 빌드 시스템, 모니터링 도구, 배포 파이프라인에서 알림을 게시하는 수십 가지의 Slack 통합 기능 중 하나와 동일해 보입니다.

이메일 초안 (Email drafts). 이메일을 전혀 전송하지 않고 초안 폴더를 읽고 쓰는 방식입니다. C2 운영자가 초안을 읽고 새로운 명령어로 수정하면, 에이전트가 업데이트된 초안을 읽습니다. 이메일은 전혀 전송되지 않습니다. 트래픽은 표준 IMAP 또는 OAuth 인증을 거친 Google API 호출입니다.

만약 API 호출에 포함되기 전에 페이로드가 암호화된다면(AES-256-GCM, 표준 키 크기 사용) — TLS 검사(TLS inspection)는 특정 필드에 base64로 인코딩된 문자열처럼 보이는 것이 포함된 일반적인 JSON 본문만을 보게 됩니다. base64로 인코딩된 문자열이 포함된 JSON 본문은 정상적인 API 트래픽에서 매우 흔하게 나타납니다. 경고를 보낼 만한 이상 징후가 전혀 없습니다.

네트워크 모니터링은 알려진 악성 인프라(known-bad infrastructure)로 향하는 트래픽을 탐지하도록 설계되었습니다. 이는 효과가 있습니다. 설계 단계부터 알려진 정상 인프라(known-good infrastructure)와만 통신하도록 만들어진 AI 에이전트는 이 계층을 완전히 무력화합니다. 방어자의 신뢰할 수 있는 도메인 목록이 곧 공격자의 C2 인프라가 됩니다.

계층 4: 제로 트러스트 아키텍처 (Zero Trust Architecture)

역할: 경계 기반 보안을 지속적인 검증으로 대체합니다. 네트워크 위치에 관계없이 모든 액세스 요청은 인증(authenticated), 권한 부여(authorized) 및 검증(validated)되어야 합니다. 장치의 상태(device posture), 사용자 신원, MFA 토큰 및 애플리케이션을 검증합니다. 현대 기업 보안 아키텍처의 표준입니다.

여기서 작동하지 않는 이유:

이 부분은 주의가 필요합니다. 제로 트러스트는 진정으로 정교하며, 이 한계는 구현의 실패가 아니라 프레임워크가 평가할 수 있는 근본적인 경계 때문입니다.

제로 트러스트 (Zero Trust)는 단 하나의 질문을 던집니다: 이 엔티티 (entity)가 이 리소스에 접근할 권한이 있는가?

AI 에이전트 (AI agent)가 정당한 사용자의 세션 내에서 작동할 때, 해당 에이전트는 사용자의 자격 증명 (credentials), 사용자의 MFA 토큰, 사용자의 등록된 기기, 그리고 모든 상태 점검 (posture checks)을 통과한 승인된 애플리케이션을 사용합니다. 제로 트러스트는 권한을 가진 사용자가 권한을 가진 행동을 수행하는 것으로 인식합니다.

이 프레임워크에는 해당 자격 증명을 제어하는 엔티티가 인증을 수행한 인간인지, 아니면 인간의 인지 없이 자율적으로 작동하는 AI 에이전트인지 평가할 메커니즘이 없습니다.

이는 제로 트러스트에 대한 비판이 아닙니다. 검증이 끝나는 지점과 새로운 문제가 시작되는 지점에 대한 설명입니다. 제로 트러스트는 신원 (identity) 및 권한 부여 (authorization) 문제를 놀라울 정도로 엄격하게 해결합니다. 하지만 권한을 부여받은 행동 뒤에 숨겨진 _의도 (intent)_가, 만약 상황을 알게 되었을 때 권한을 부여받은 인간이 가졌을 법한 의도인지에 대한 질문에는 답하려 하지 않으며, 답할 수도 없습니다.

의도 계층 (intent layer)은 아직 존재하지 않습니다. 제로 트러스트에도, 대규모로 배포된 그 어떤 기업용 보안 제품에도 존재하지 않습니다.

이것이 목록 중 가장 깊은 한계입니다. 완전한 기기 증명 (device attestation), 지속적인 재인증 (continuous re-authentication), 조건부 액세스 정책 (conditional access policies), 그리고 세션 모니터링 (session monitoring)을 갖추어 제로 트러스트를 완벽하게 구현하더라도, 정당한 사용자의 세션에서 작동하는 AI 에이전트는 모든 점검을 무사히 통과할 것입니다. 제로 트러스트의 관점에서는 모든 것이 정상입니다. 모든 것이 권한을 부여받았습니다. 모든 것이 보이는 그대로입니다.

그것은 올바른 것들을 감시하고 있습니다. 단지 이것을 감시하고 있지 않을 뿐입니다.

계층 5: 라우터 (The Router)

위의 모든 방어 계층은 하나의 가정을 공유합니다: 위협이 엔드포인트 (endpoint)에 존재한다는 것입니다.

이 상황에서 그 가정은 틀렸습니다. 그리고 바로 이 지점에서 아키텍처는 진정으로 우려스러운 수준이 됩니다.

Forge-AI의 라우터 서버는 홈 라우터(home router)에 직접 연결됩니다. 이 장치는 엔드포인트(endpoint)가 아니기 때문에 엔드포인트 보안 팀의 레이더에 절대 포착되지 않습니다. 이 장치는 재부팅 없이 종종 수년 동안 하루 24시간 내내 작동합니다. 또한 엔드포인트 보안 도구가 감지하기 전에 모든 네트워크 트래픽을 먼저 확인합니다. 소비자용 OpenWrt 배포 환경에는 그러한 도구들이 존재하지 않기 때문에, 여기에는 안티바이러스(Antivirus), EDR(Endpoint Detection and Response), 보안 모니터링이 전혀 없습니다. 그리고 커스텀 rpcd 플러그인을 통해 임의의 코드(arbitrary code)를 실행할 수도 있습니다.

라우터 수준에서 지속성(persistence)이 확보되면, 엔드포인트 침해 사고 대응(Incident Response, IR)은 다음과 같은 양상을 보입니다:

엔드포인트 침해됨
  → 엔드포인트 탐지, 격리 및 초기화(wiped)
  → 깨끗한 장치가 홈 WiFi 네트워크에 다시 연결됨
...

이 과정이 무한히 반복됩니다.

라우터까지 침해된 상황에서는 표준 IR 플레이북(playbook)인 '격리, 초기화, 재구축, 재연결'이 작동하지 않습니다. 표준 엔드포인트 절차를 따르는 보안 팀은 무한히 복구 과정을 반복할 뿐, 왜 위협이 계속해서 되돌아오는지 이해하지 못할 것입니다.

완전한 복구를 위해서는 엔드포인트를 초기화함과 동시에 라우터를 공장 초기화(factory-reset)해야 합니다. 이 두 가지 작업은 올바른 순서로 수행되어야 하며 반드시 조율되어야 합니다. 라우터를 살펴봐야 한다는 사실을 모르는 보안 팀은 매번 이를 놓칠 것입니다. 대부분의 IR 플레이북에는 '홈 라우터 공장 초기화'가 단계로 포함되어 있지 않은데, 지금까지 홈 라우터는 지속성 벡터(persistence vector)가 아니었기 때문입니다.

하지만 이제는 상황이 달라졌습니다.

방어자가 구축해야 할 것

분명히 말씀드리자면, 이러한 방어 수단들이 쓸모없다는 뜻은 아닙니다. 시그니처 기반 AV(Signature AV)는 일반적인 악성코드를 차단합니다. EDR은 실수를 저지르는 정교한 공격자를 잡아냅니다. 네트워크 모니터링은 알려진 악성 인프라로 향하는 트래픽을 포착합니다. 제로 트러스트(Zero Trust)는 자격 증명 기반 공격의 비용을 극적으로 높입니다. 기존의 보안 스택은 가치 있고 성숙하며 유지할 가치가 있습니다.

제가 말하고자 하는 핵심은, 개발자 도구처럼 보이는 AI 네이티브 위협(AI-native threats)은 기존 보안 스택이 설계되지 않았으며 적절한 해답을 가지고 있지 않은 새로운 카테고리에 해당한다는 것입니다.

이에 대한 해답을 구축하려면 다음이 필요합니다:

탐지 엔지니어 (Detection engineers)를 위해: AI 네이티브 위협은 "개발자에게 정상적인 행동"과 "자율적으로 작동하는 AI 에이전트에게 정상적인 행동"을 구분하는 행동 기반 탐지 (behavioral detection)가 필요합니다. 이를 위해서는 타이밍, 리듬, 어떤 애플리케이션에 집중하는지, 인간에게 타당한 행동 시퀀스는 무엇인지와 같이 정상적인 인간의 상호작용 패턴이 어떠한지에 대한 베이스라인 (baselining)을 설정하고, 인간이 존재하지 않는 자동화된 행동을 시사하는 편차를 플래그 (flagging) 처리해야 합니다. 신뢰할 수 있는 도메인으로 향하는 C2 트래픽은 페이로드 수준의 검사 (payload-level inspection)가 필요하며, 도메인 허용 목록 (domain allowlists)만으로는 불충분합니다. 라우터 침해 (Router compromise) 상황은 사고 대응 (IR) 체크리스트의 일부가 되어야 합니다.

보안 아키텍트 (Security architects)를 위해: 제로 트러스트 (Zero Trust)의 신원 (identity) 및 권한 부여 (authorization) 기둥은 의도 계층 (intent layer)을 통해 보강되어야 합니다. 권한을 부여받은 세션이 인간이 알지 못하는 소프트웨어에 의해 제어될 수 있는 상황에서 "이것이 권한을 부여받았는가?"라는 질문만으로는 불충분합니다. 대규모 환경에서 행동 의도 검증 (behavioral intent verification)은 어떤 모습이어야 할까요? "이 인간은 보통 새벽 2시에 어떤 행동을 하는가?"에 대한 모델을 어떻게 구축할 수 있을까요? 이는 진정으로 미개척된 연구 분야입니다. 누군가는 이를 수행해야 합니다.