핵심 요약
AI 요약
기사 목차 펼치기 / 접기
AI가 다음 행동을 고르고 도구가 실행한다. 아르텍스가 보여주는 변화는 그 사이를 연결한 구조로, 국내 공격 분석과 공개 코드를 대조하면 자동화의 작동 방식을 살필 수 있다. 실제로 사람의 손이 얼마나 줄었는지는 아직 계산하기 어렵다.
앞선 1편이 사건 날짜를 대조했다면, 이번 2편은 공개 코드에서 계획과 실행이 어떻게 나뉘는지 따진다.
모델과 실행 환경은 역할이 다르다
언어모델은 입력을 읽고 다음 출력을 만들지만, 명령을 제안했다고 서버에서 저절로 실행되지는 않는다. 실행 환경이 도구 호출을 받아 처리해야 한다. 결과를 다시 모델에 전달하는 경로도 필요하다.
아르텍스의 공개 파생 저장소에는 Planner와 Worker를 나누고, 모델 호출에 도구를 연결하는 구조가 담겨 있다.
보안 도구가 수행하는 요청과 AI가 내리는 판단은 구별해야 한다. 탐색이나 명령 실행 자체는 기존 도구도 하지만, 에이전트는 그 결과를 읽어 다음 작업을 정하는 자리에 들어온다. 자동화의 범위를 보려면 호출 전후의 기록이 함께 있어야 한다.
Planner는 나누고 Worker는 실행한다
공개 코드의 Planner는 목표와 현재 상태를 받아 작업을 계획한다. Worker 쪽에는 작업 도구와 모델 실행을 연결하는 코드가 있다. 계획을 세우는 역할과 실제 도구를 호출하는 역할이 갈리며, 서로 독립된 탐색은 여러 Worker에 나눌 수 있는 구조다.
Worker는 발견한 내용을 통지할 수 있고, Planner는 완료 결과와 새 발견을 다음 계획의 입력으로 받는다. Planner의 상태 입력에는 어떤 작업에서 무엇이 달라졌는지가 포함된다. 앞 작업을 잊고 새로 질문하는 방식과 다르다. 작업 결과가 다음 판단으로 이어진다.
| 단계 | 공개 소스에서 대조한 기능 | 자동화되는 작업 |
|---|---|---|
| 계획 | Planner의 Plan | 목표·상태를 바탕으로 다음 작업 선택 |
| 실행 | Worker의 execute | 도구 호출과 응답 수집 |
| 결과 전달 | SetNotifyFinding | 발견 내용 통지 |
| 재계획 | renderTriggers | 완료·발견을 계획 입력에 반영 |
| 개입 | ExecuteWithMessage, steer·kill 경로 | 사람이 메시지를 보내거나 작업 방향 변경·중단 |
계획과 실행이 갈리면 일을 나눠 돌릴 수 있다.
실패도 다음 판단의 입력이 된다
정해진 요청을 반복하는 프로그램과 달리, 에이전트는 응답을 읽고 다음 작업을 바꿀 수 있다. 다만 오류에 따라 분기하거나 재시도하는 기능은 기존 스크립트에도 넣을 수 있다. 차이는 요청이 바뀌었느냐만으로 판정할 수 없다. 결과를 읽고 다음 작업을 고른 주체를 확인해야 한다.
결과를 전달하는 기능만으로 올바른 판단이 보장되지는 않는다. 오류 메시지를 잘못 읽으면 엉뚱한 작업을 이어갈 수도 있다. 새 요청의 실행과 목표 달성은 다르므로, 성공 판정에는 대상 시스템에서 나온 증거가 필요하다.
실패 뒤 55초 사이에 무엇이 바뀌었나
55초 사이에 달라진 것은 재시도 방식이었다.
헌트리스(Huntress)는 커넥트와이즈(ConnectWise) 관련 침해를 관찰한 고객 환경에서, 10월 15일 인증서 등록 실패 뒤 실행 방식이 바뀐 경과를 공개했다. 인증서 식별값이 맞지 않아 실패한 뒤, 다음 실행에는 재시도가 나타났다. 그 사이의 간격은 55초였다. 바뀐 방식은 다른 고객 환경에서도 관측됐다는 설명이다.
| 관측 순서 | 헌트리스가 공개한 경과 | 여기서 알 수 없는 것 |
|---|---|---|
| 실패 | 인증서 식별값 불일치, 해당 실행에서 재시도 없음 | 누가 오류 응답을 읽었는가 |
| 55초 뒤 | 다음 실행에서 같은 오류에 재시도 발생 | 코드를 고쳤는가, 기존 옵션을 켰는가 |
| 후속 실행 | 다른 고객 환경에서도 재시도 방식 사용 | 사람·모델 중 누가 변경을 지시했는가 |
헌트리스는 공격자 시스템을 볼 수 없어 모델 연결을 확인하지 못했으며, 자체 관측만으로는 LLM 개입의 확신을 낮음~중간으로 평가했다. 실패를 반영한 변화는 관측됐지만, 그 변화를 만든 주체는 남아 있다. 이번에 인용한 헌트리스 자료는 공격자의 AI 대화 원본을 제공하는 문서가 아니다. 이 사례를 AI가 스스로 코드를 수정한 확정 장면으로 쓰지는 않는다.
코드의 기능과 사건의 관측을 나눴다
안랩은 10월 7일 인터넷에 노출된 아르텍스 v2 환경에서 중앙 Planner가 여러 Worker를 조율하는 모습을 관찰했다고 밝혔다. 도구 실행과 증거, 트래픽을 관리하는 화면도 분석했다. 운영 환경의 구조를 관찰한 결과다.
빗썸 사고를 분석한 보고서가 아니다.
| 근거 | 확인한 내용 | 사건에 적용할 때의 한계 |
|---|---|---|
| 공개 파생 코드 | 계획·도구 실행·발견 통지의 연결 | 피해기관에서 같은 버전을 실행했는지 미확인 |
| 안랩의 운영환경 관찰 | 중앙 Planner와 여러 Worker | 빗썸 사용 도구·버전을 특정한 자료가 아님 |
| 클라우드스트라이크(CrowdStrike)의 국내 공격 분석 | 설정과 작업 세션을 확보·분석했다는 발표 | 전체 세션을 직접 재집계하지 못함 |
| 헌트리스의 고객 측 기록 | 실패 뒤 후속 실행의 재시도 방식 변화 | 변경 주체와 모델 호출은 보이지 않음 |
실제 공격 기록에서는 무엇이 보였나
클라우드스트라이크는 국내 금융권 공격 관련 인프라에서 아르텍스 설정과 클로드코드(Claude Code) 작업 세션 등을 분석했다고 밝혔다. 실제 침해 인프라에서 아르텍스의 주 모델 연결은 딥시크(DeepSeek) v4.1-flash였고, 추가 클로드코드 세션에는 GLM-5.3과 그록(Grok) 4.6도 쓰였다. 프로그램 이름과 모델 이름이 일치하지 않는 사례다. 클로드코드 기록이라는 이유만으로 모든 실행을 클로드(Claude) 모델 사용으로 집계할 수 없다.
마이크로소프트(Microsoft)는 10월 21일 Storm-0940이 아르텍스를 사용해 커넥트와이즈 관련 침해 뒤 2250개 넘는 테넌트에 로그인을 시도했다고 보고했다. 테넌트는 고객 조직의 계정과 자원을 관리하는 클라우드 환경이다. 일부 환경에서는 인증 이후 정보 탐색과 자격증명 변경도 관측했다. 기존에 부여된 애플리케이션 권한을 악용하는 후속 활동으로, 대상 수가 곧 침해 성공 수는 아니다.
같은 보고서의 10월 10~14일 비밀번호 대입 구간에서는 15만1000회 넘는 실패가 기록됐다. 분당 최대 실패는 2900회였으나, 이 구간에서 인증 성공은 관측되지 않았다. 실패가 많이 발생한 구간과 이후 애플리케이션 접근을 한 숫자로 합치면 공격의 결과가 달라진다. 빠른 실행과 성공은 따로 확인해야 한다.
그러면 완전 자율 해킹인가
공개 Worker 코드에는 사람이 작성한 메시지를 받아 작업을 이어가는 경로가 있다. Planner에는 방향 변경과 중단을 연결하는 코드도 담겼다. 사람이 개입할 수 있는 설계지만, 실제 공격에서 어느 시점에 개입했는지는 별도 기록이 있어야 안다.
자동화율을 계산하려면 전체 작업의 분모부터 정해야 한다. 명령 개수인지, 판단 횟수인지, 걸린 시간인지에 따라 값이 달라진다. 원본 세션과 사람의 입력, 모델 호출 기록이 필요하다. 공개 보고서만으로는 그 분모를 재구성할 수 없으며, 여러 작업을 병렬로 돌릴 수 있다는 기능 설명을 사람 한 명의 노동시간 절감으로 환산해서도 안 된다.
실제 사건에서 사람이 그 순환을 몇 번 멈추고 다시 돌렸는지는 공개되지 않았다.
