본문으로 건너뛰기

AI Agent(ARTEX) 동작 분석 — 공개 보고서 정리

Inseok Jeon
Inseok Jeon
Security Manager

ARTEX의 동작을 로컬 교육 환경에서 시험한 공개 보고서를 정리했다. 에이전트 구조, 시험 결과 집계, 대상 서버에 남는 네트워크 흔적, 그리고 관제에서 쓸 탐지·대응 시사점을 중심으로 본다.

정리 범위
  • 원 자료: ICTIS 법무부팀 CERT, 「ARTEX 동작 분석 보고서 — AI Agent 기반 웹 취약점 테스트」 (V1.6, 2026-10-15)
  • 성격: 단일 호스트의 로컬 Docker 교육 환경 관찰이다. 실제 운영 서비스 침해, 특정 공격자 귀속, 안전장치의 차단 성능을 입증하는 자료가 아니다.
  • 이 글의 범위: 보고서의 구조·결과·탐지 관점을 정리한다. 공격을 재현하는 요청·페이로드·실행 절차는 옮기지 않는다. 도구 자체의 소개는 ARTEX 도구 분석 문서를 참고한다.

배경​

2026년 9월 말부터 10월 초까지 국내 금융권을 겨냥한 침해 활동에서 ARTEX 활용 정황이 공개됐다. 이 보고서는 그 사고를 재현하려는 자료가 아니라, 공개된 AI 침투 테스트 도구가 웹 서비스를 어떻게 탐색하고 취약점을 보고하는지, 대상 서버에 어떤 흔적을 남기는지를 방어 관점에서 파악하기 위한 로컬 시험이다.

금융권 사고의 실제 요청이 이 시험 서버에서 재현됐다는 의미는 아니다. 사건 자체의 경과는 2026-W41 주간 브리핑에서 다뤘다.

ARTEX 동작 구조​

ARTEX는 사용자가 대상과 목표를 입력하면, 여러 에이전트가 역할을 나눠 자산을 조사하고 다음 행동을 스스로 정하는 자율 침투 테스트 도구다. 이전 작업 결과를 바탕으로 다음 작업을 정한다는 점이 특징이다. 보고서가 소스와 실제 UI에서 확인한 구성요소는 다음과 같다.

구성요소역할
Goals사용자 설명에서 목표와 허용 범위를 정리
Planner현재 그래프를 읽고 다음 작업 의도(intent)를 생성
Worker의도 하나를 받아 도구를 실행하고 결과를 증거로 기록
Mainagent진행 중 사용자 대화·지시를 반영 (소스상 역할만 확인)
Reporter / Retester보고서 정리와 재검증

동작은 순환 구조다. 엔진이 그래프 변경에 따라 Planner를 깨우고, Planner가 만든 의도를 Worker가 하나씩 실행한 뒤 사실·자산·발견 사항(finding)을 기록하면, 그 기록이 다시 Planner의 입력이 된다.

이때 두 가지 그래프가 쌓인다. 자산 그래프는 도메인·IP·서비스·엔드포인트 같은 대상 구조를 관리하고, 탐색 그래프는 목표·확인 사실·발견 취약점·후속 판단의 연결을 관리한다. 두 그래프가 연결돼 있어, 특정 finding이 어떤 엔드포인트의 어떤 시험에서 나왔는지 역추적할 수 있다. 중복 조사를 줄이고 선행조건이 필요한 시험을 순서대로 진행하는 데 쓰이는 설계다.

시험 환경​

구성설정목적
ARTEX v0.3.14Docker 컨테이너, 웹 콘솔작업 생성·오케스트레이션·결과 열람
PostgreSQLDocker 컨테이너ARTEX 상태 및 그래프 저장
OWASP Juice Shophost.docker.internal:3000기존 교육용 취약 쇼핑몰
ICTIS MOJCSC CERT Shop (artex-lab)artex-lab:8000직접 제작한 별도 시험 대상
artex-lab-capture대상과 네트워크 공간 공유대상 서버 측 패킷을 PCAP으로 저장

LLM은 에이전트의 계획·판단을 위해 연결하며, 이번 시험에는 OpenAI 계열 프로필을 사용했다. 대상 범위는 각 작업 설정에서 해당 쇼핑몰과 그 하위 경로로 제한했고, 타 호스트·외부 사이트는 제외했다. 시험 쇼핑몰의 주문은 실제 카드 청구·배송·외부 결제 API가 없는 모의 주문이다.

시험 결과​

OWASP Juice Shop​

ARTEX의 발견·보고 기능으로 취약점 23건이 집계됐다.

치명적높음중간낮음합계
3109123

치명적 3건은 모두 접근 통제와 인증 영역이었다.

  • 비로그인 사용자가 공개 상품의 가격·설명을 수정할 수 있는 접근 통제 실패
  • 회원가입 요청에 관리자 역할을 지정해 관리자 계정을 만드는 대량 할당(Mass Assignment)
  • 로그인 이메일의 SQL 삽입으로 비밀번호 검증을 우회하고 관리자 토큰을 얻는 인증 우회

높음 10건은 민감정보 노출, 보안 질문 기반 계정 재설정, 타인·존재하지 않는 주소·카드 수용, 타인 장바구니 수정, DOM XSS, 전체 사용자 목록 노출 등이었다. 중간 9건은 피드백 작성자 사칭, 주문 확인 PDF의 이메일 노출, 장바구니 ID 변경을 통한 조회, 파일 다운로드 제한 우회 등이며, 낮음 1건은 오류 응답의 내부 경로·스택 추적 노출이었다.

artex-lab (직접 제작 대상)​

artex-lab 작업에서는 5건이 대시보드에 표시됐다. 각 항목은 "무엇을 확인했고, 어디까지가 근거인가"를 함께 기록한다.

번호표시 항목심각도확인된 근거와 한계
1상품 검색 매개변수의 SQL 삽입높음검색 조건 조작에 따른 응답 변화를 시험한 흔적이 finding에 연결됨. DB 변경·유출 범위로는 확장하지 않음
2게시판의 저장형 XSS높음한 사용자가 작성한 내용이 다른 세션의 게시판 HTML에 이스케이프 없이 나타나는 재현 내용
3주문 내역의 IDOR중간한 세션에서 다른 실습 사용자의 주문·이메일을 읽는 시험이 표시됨. 실제 사용자 데이터 접근 사례로 확대하지 않음
4상품 검색의 반사형 XSS중간검색어가 HTML 속성에 안전하게 인코딩되지 않고 반영된 내용이 기록됨
5계정 전환 후 이전 관리자 세션 유효중간관리자에서 일반 사용자로 전환한 뒤에도 이전 관리자 쿠키가 남는 문제. 명시적 로그아웃 시험은 아니며, 세션 미폐기로 범위를 한정

주목할 점은 두 가지다. 시험 앱에 의도적으로 심어 둔 취약점 가운데 평문 암호 저장과 로그인 속도 제한 부재는 이 5건에 포함되지 않았다. 반대로 계정 전환 후 세션 미폐기 문제는 목록에 없던 것을 실행 중 추가로 찾은 항목이다. 즉 대시보드의 finding 수는 "심어 둔 취약점 수"와 일치하는 개념이 아니다.

노트

보고서는 "발견 건수는 항목별 재현과 영향 검증이 뒤따라야 하는 도구의 보고 결과"라고 선을 긋는다. 시험 당시 재검증 탭에는 완료 기록이 없었다. AI 에이전트의 출력은 그 자체로 확정된 취약점이 아니라, 사람이 재현·검증해야 할 후보로 다뤄야 한다는 뜻이다.

네트워크·User-Agent 관찰​

대상 서버 쪽에서 수집한 PCAP은 약 6,330패킷이었고, 이 가운데 ARTEX 측으로 분류한 HTTP 요청은 약 430건이었다.

  • 요청의 다수는 Python-urllib/3.12(약 346건)였고, 그 외 curl 계열이 확인됐다.
  • 작업명이 그대로 담긴 커스텀 User-Agent(AuthorizedLabValidation/1.0, Lab-SQLi-impact-test/1.0 등)도 관찰됐다. 이는 Worker가 특정 검증 작업에서 설정한 값으로 보인다.
  • 스캔 시작 단계에서는 ARTEX 고유 User-Agent인 artex-enrich/1.0과 Mozilla/5.0 (spa-api-recon) 계열이 발견됐다.
교차 관찰 시 유의

안랩 ASEC은 같은 도구를 분석하며 artex-enrich/1.0, Mozilla/5.0 (spa-api-recon)을 "코드·문서에만 있고 실제 통신에서는 확인되지 않은 값"으로 분류했다(ASEC 분석). 이번 보고서는 로컬 PCAP에서 이 값이 실제로 발생했다고 기록한다. 버전·설정·수집 지점에 따라 관찰 결과가 달라질 수 있다는 점을 보여준다. 특정 User-Agent의 존재 여부만으로 ARTEX 사용이나 침투 성공을 단정해서는 안 된다.

User-Agent가 헤더에 존재한다는 사실이 곧 "모든 스캔에서 그 모듈이 실행됐다"는 증거는 아니다. 또한 공격자가 값을 바꾸거나 제거할 수 있고, curl은 정상 관리 업무에도 쓰인다.

탐지·대응 시사점​

보고서가 제시한 방향은 기존 관제 원칙과 다르지 않다. 특정 문자열이나 개별 도구 탐지에 기대지 말고, 행위의 연쇄와 관계를 전체 흐름으로 보라는 것이다.

  • 단일 User-Agent 규칙은 참고 신호로만. 헤더 하나로 도구 사용이나 공격자 귀속을 판단하지 않는다.
  • 연쇄적인 요청을 탐지. 같은 범위에서 짧은 시간에 상품 검색 조건 조작, 게시판 입력, 다른 계정의 주문 조회, 관리자 경로 접근이 이어지면 세션·출발지·경로·응답 코드·상관관계를 묶어 분석한다.
  • 서버 로그와 PCAP을 연결. 관찰 시간, HTTP 메서드·경로·쿼리, 세션 전후 상태를 대조하면 자동 생성된 보고의 범위를 검증할 수 있다. 상세 절차는 SOC 탐지 파이프라인 문서와 이어진다.
  • 취약점 유형별 방어를 우선. SQL 매개변수화, 출력 위치별 HTML 인코딩, 주문·객체 소유권 검사, 계정 전환·로그아웃 시 세션 폐기, 최소 권한 검증을 적용한다. 이는 artex-lab에서 관찰한 문제와 직접 대응한다.
  • 결과 재검증. 저장형·반사형 XSS는 실제 브라우저 실행을, IDOR는 본인·타인 계정의 같은 요청 비교를 통해 확인한다. 수정 후에는 재발 여부를 다시 시험한다.

기존 도구 문서와 달라진 점​

사이트의 ARTEX 도구 분석 문서는 "소스 비공개, 세부 아키텍처는 범위 밖"으로 기술돼 있다. 이번 보고서는 공개된 Global Edition 포크 저장소와 Docker 이미지(autumn27/artex 계열)를 로컬에서 띄워 구조와 동작을 직접 관찰했다는 점에서 차이가 있다. 즉 원 저장소는 비공개로 전환됐지만, 파생본과 컨테이너 이미지 형태로는 여전히 구동·분석이 가능한 상태다. 이 사실은 도구 문서에도 반영할 예정이다.

한계​

이번 결과는 단일 호스트의 로컬 Docker 교육 환경에 한정된다. 전체 인터넷 자산 수나 모든 경로를 의미하지 않으며, 실제 운영 서비스의 침해를 입증하지 않는다. 실습은 반드시 격리된 환경에서만 하며, 원칙은 AI 취약점 진단 실습 — 접근과 윤리를 따른다.

참고 자료​