단 한 줄의 Telegram 명령어가 인터넷에 노출된 인프라를 대상으로 한 자율적인 취약점 공격(exploitation) 실행을 촉발했습니다. 하지만 이 모든 작전은 AI 에이전트가 실수로 자신의 도구 호출(tool calls)과 로그를 방송하는 공개 웹 서버를 구축하면서 발각되었습니다. 이러한 조합, 즉 실제적인 자율성(autonomy)과 초보 수준의 작전 보안(OPSEC) 실패는 현재 AI 기반 공격이 실제로 어느 단계에 와 있는지를 모두 말해줍니다.

배경: 이는 이미 예견된 일이었습니다

누군가가 LLM을 공격 프레임워크(offensive framework)에 연결하여 Langflow, n8n, 그리고 Marimo 인스턴스를 겨냥하도록 설정했다는 사실에 보안 전문가 중 누구도 놀라지 않을 것입니다. Hermes와 같은 에이전트 프레임워크(Agent frameworks)는 모델에게 목표와 도구 세트(toolset)를 부여하고, 매 단계마다 인간의 개입(human in the loop) 없이도 의사결정을 체인 형태로 연결할 수 있는 충분한 자율성을 부여하는 것을 매우 쉽게 만들었습니다. 우리는 지난 2년 동안 "AI 지원 정찰(AI-assisted recon)"과 "AI 지원 피싱(AI-assisted phishing)" 사례들을 지켜봐 왔습니다. 이것은 다음 단계의 논리적 흐름입니다. 즉, 모델이 타겟을 선정하고, 익스플로잇(exploit)을 선택하며, 이를 시도하고, 실패하면 다음으로 넘어가는 "AI 지원 취약점 공격(AI-assisted exploitation)" 단계입니다.

이것이 진정으로 새로운 것일까요? 어느 정도는 그렇습니다. 자동화된 취약점 공격 프레임워크와 스스로 전파되는 웜(worms)은 전혀 새로운 것이 아닙니다. Blaster와 Slammer 시절부터 존재해 왔습니다. 새로운 점은 의사결정 계층(decision-making layer)입니다. 하드코딩된 익스플로잇 체인(exploit chain) 대신, 모델이 심각도와 배포 가능성을 즉석에서 추론하며, 타겟이 예상과 일치하지 않을 때 적응하는 방식을 취합니다. 이는 방어자들이 고려해야 할 의미 있게 다른 형태의 실패 모드(failure mode)입니다.

과장 확인: 흥미로운 점은 자율성이 아니라 무능함입니다

보고서들에서 과장될 부분은 바로 이것입니다: "AI가 이제 인터넷을 자율적으로 해킹한다." 이러한 프레임은 잘 팔리겠지만, 요약 내용 자체는 그 주장을 약화시킵니다. 대부분의 시도는 설정 불일치(configuration mismatches)로 인해 실패했기 때문입니다. 이것은 정교한 메스(scalpel)가 아니었습니다. 그것은 노출된 인스턴스에 알려진 익스플로잇을 던지며 적중하기를 바라는 에이전트였으며, 자신의 인프라를 잘못 설정하여 도구와 로그를 공개 HTTP 서버에 그대로 남겨두는 바람에 발각된 것이었습니다.

그것은 정교한 기술 (tradecraft)이 아닙니다. 그것은 주니어 침투 테스트 전문가 (pentester)가 첫 단독 프로젝트에서 저지를 법한 종류의 실수입니다. 사람들이 이야기해야 할 서사는 "Skynet이 당신의 n8n 인스턴스를 스캔하고 있다"가 아니라, "공격자들이 이제 취약점 공격 (exploitation)의 지루하고 오류가 발생하기 쉬운 부분들을 그 자체로 오류를 범하기 쉬운 모델에 위임하고 있으며, 때때로 그 모델이 전체 작전을 노출시키는 방식으로 실수를 저지른다"에 더 가깝습니다.

더 무서운 프레임(framing)을 통해 누가 이득을 보나요? "AI 위협 탐지 (AI threat detection)"를 하나의 카테고리로 판매하는 사람이라면 누구든 위협이 실존적(existential)인 것처럼 들려야 합니다. 저는 차라리 실패율에 대한 정직한 보고를 보고 싶습니다. 왜냐하면 그것이 실행 가능한 신호 (actionable signal)이기 때문입니다. 대부분의 경우 실패하지만, 가끔 패치되지 않고 노출된 자동화 도구를 대상으로 타격을 입히는 에이전트는 실제적인 문제이긴 하지만, 공상 과학 영화(sci-fi) 속의 문제는 아닙니다.

시사점: AI보다 노출 표면 (exposure surface)이 더 중요하다

여기서의 실제 교훈은 DeepSeek나 Hermes에 관한 것이 아닙니다. Langflow, n8n, 그리고 Marimo 인스턴스들이 스캔할 가치가 있을 만큼 충분히 많은 수로 인터넷에 노출된 채 방치되어 있다는 사실입니다. 이는 언제나 그래왔던 이야기와 같습니다. 내부 자동화 및 개발 도구 (dev tooling)는 빠르게 구축되고, 보안 검토 (security review)는 나중에 이루어지거나 아예 이루어지지 않으며, 이제는 무언가(인간 또는 에이전트)가 이를 대규모로 자동 점검하고 있습니다.

어느 쪽이든, 자율 에이전트 (autonomous agents)는 공격 목록과 약간의 스크립팅 기술을 가진 지루해하는 인간이 이미 할 수 있었던 일들의 비용을 낮춥니다. "수천 개의 호스트를 대상으로 반지능적인 스캔 및 공격 루프 (scan-and-exploit loop)를 실행"하는 데 필요한 장벽이 낮아진 것입니다. "우리 내부 도구의 설정 오류(misconfig) 세 개를 아무도 수동으로 찾아내어 연쇄 공격(chain)하지 못할 것이다"를 보안 통제 수단으로 의존해 온 팀들은 이제 그 의존을 멈춰야 합니다. 왜냐하면 그 가정은 이미 불안정했으며, 점점 더 빠르게 흔들리고 있기 때문입니다.

스스로 초래한 노출(로그를 유출한 공개 HTTP 서버)은 에이전트 툴링(agent tooling) 자체가 공격 표면(attack surface)이라는 점을 상기시켜 줍니다. 위협 행위자(threat actor)의 에이전트가 자신의 운영을 노출할 정도로 심각하게 무언가를 잘못 설정할 수 있다면, 방어자의 AI 툴링 또한 방어자에게 똑같은 일을 저지를 수 있습니다. 아직 아무도 내부 에이전트의 로깅(logging) 동작에 대해 위협 모델링(threat modeling)을 수행하고 있지 않습니다. 아마도 시작해야 할 것입니다.

열린 질문 (Open question)

만약 자율 에이전트(autonomous agents)가 공격(exploitation) 비용을 낮추기는 하지만 반드시 공격의 질을 높이는 것은 아니라면, 방어자의 우선순위는 "AI 특화" 공격 패턴을 탐지하는 데 투자하는 것보다 노출된 공격 표면(attack surface)을 줄이는 쪽으로 이동해야 할까요?

— Cor, Skyblue Soft

출처 (Sources)

• Chinese Hacker Commands DeepSeek via Telegram to Launch Autonomous Attacks