2026년 9월 말부터 발생한 국내 시중은행 및 금융기관의 외곽 시스템(대출 정보 조회 서비스, 직원 업무 지원 서비스 등) 침해 사고에서 오픈 소스 AI 보안 도구인 ARTEX를 활용한 흔적이 확인되어 보안 업계의 큰 주목을 받고 있습니다.
공격자가 AI의 속도로 진화하며 공격 속도를 끌어올린 지금, 방어 조직은 AI 공격 도구의 동작 메커니즘과 위협 실체를 정확히 이해하고 이에 맞춘 선제적·상시적 대응 체계를 마련해야 합니다. 이에 Xint Research 팀에서 ARTEX를 비롯한 AI 보안 도구의 동작 방식, 위협 분석, 실증 실험 결과 및 대응 가이드를 담은 백서를 발간했습니다.
본 아티클에서는 해당 백서에서 다룬 핵심 분석 내용과 현장에서 활용할 수 있는 탐지 지표 및 무료 공개 룰셋을 요약하여 정리해 봅니다.
ARTEX는 LLM을 연결해 침투 테스트를 자율적으로 수행하는 오픈 소스 AI 보안 도구입니다. 사람이 목표를 정해주면 AI 에이전트가 계획을 세워 여러 AI 에이전트에게 맡기고, 각 에이전트는 어떤 도구를 어떤 순서로 실행할지 스스로 정합니다.
연구팀이 기본 설정을 살펴보며 주목한 점은 두 가지입니다.
스스로 멈추지 않습니다: 기본 설정에서는 작업 전체 시간이나 요청 속도에 상한이 없어 목표를 달성할 때까지 계속 돌아갑니다.
기본값으로는 요청, 응답 원문이 저장되지 않습니다: HTTP 요청, 응답도 AI 모델과 주고받은 내용도 저장되지 않습니다.
개발자는 지난 10월 8일 악용을 이유로 프로젝트를 비공개로 돌렸습니다.
하지만 복제본과 비슷한 구조의 도구는 이미 여러 개가 존재합니다.
단순히 금융권만의 이야기가 아닙니다.
AI 침투 테스트 도구가 실제 공격에 쓰인 사례는 2025년 하반기부터 확인되기 시작했습니다.
FortiGate 캠페인(2026년 1-2월): 55개국 이상에서 FortiGate 장비 600대 이상이 침해되었고 공격 서버에서 오픈 소스 도구 CyberStrikeAI의 흔적이 확인됐습니다.
미국 리테일 캠페인(2026년 7-9월): 보안 기업 Gambit Security의 분석에 따르면 공격자 한 명이 오픈 소스 도구 여러 개를 역할별로 엮어 최소 27곳을 침해했습니다. 그중 두 곳에서 유효한 카드 정보 60만 건 이상이 유출됐죠.
FortiGate 캠페인의 공격 입구는 소프트웨어 취약점이 아니라 인터넷에 노출된 관리 화면과 약한 인증이었습니다. 국내 금융권에서도 공격은 주력 서비스가 아닌 외곽 시스템에 집중됐습니다.
업종보다는 관리 우선순위에서 밀린 자산이 표적이 된 셈입니다.
티오리는 통제된 환경에서 ARTEX와 CyberStrikeAI에 같은 AI 모델을 연결해 20분씩 실행하고, 대상 서버와 네트워크에 남는 흔적을 측정했습니다.
ARTEX(기본 설정): 요청 2,843건
ARTEX(설정 조정): 요청 111건
CyberStrikeAI: 요청 약 32,600건
같은 모델, 같은 시간인데도 요청량은 최대 약 290배 차이가 났습니다. 같은 ARTEX끼리도 설정에 따라 25배가 달랐죠. 요청량은 도구의 종류보다 AI가 어떤 명령과 스캐너를 고르느냐에 따라 달라집니다. 그래서 '요청이 많다'는 것만으로는 AI 도구를 가려낼 수 없습니다.
💡
연구팀이 주목한 건 AI 기반 도구에서 공통으로 나타나는 행동 패턴입니다.
침묵 뒤의 폭주: AI가 판단하는 동안에는 요청이 멈추고, 판단이 끝나면 한꺼번에 몰립니다.
없는 페이지 두드리기: 후보 경로를 무차별로 확인하면서 404 응답이 쏟아집니다. 60초 동안 정상 이용자의 404는 2건이었지만, 기본 설정의 ARTEX는 2,021건, CyberStrikeAI는 약 1만 6천 건이었습니다.
섞이는 User-Agent: AI가 도구를 바꿀 때마다 User-Agent도 함께 바뀝니다.
요청이 많은 도구는 IP 별 요청 수만 세어도 의심 대상으로 추려낼 수 있습니다. 하지만 설정을 조정한 ARTEX는 10초에 22건으로, 정상 이용자(17건)와 거의 구분되지 않았습니다. 조용하게 움직이는 AI 도구는 웹 로그 하나로 잡기 어렵다는 뜻입니다. 외부에서 들어온 공격이라면 의심 IP에 AI 도구의 관리 화면이 열려 있는지, 내부 서버가 이미 침해됐다면 그 서버가 외부 AI 모델을 호출하고 있는지까지 함께 확인해야 합니다.
공격자가 쓰는 도구라면 우리가 먼저 돌려봐도 되지 않을까요? 연구팀은 이 질문에 대해서도 실험으로 확인했습니다.
인증 절차가 없는 테스트 API에 가짜 데이터를 넣고 ARTEX에 ‘취약점을 찾아줘’ 한 줄만 지시했습니다. 삭제하라는 말은 없었죠. 하지만 AI는 서버가 어떤 기능을 지원하는지 확인하려고 여러 요청을 한꺼번에 보냈고 그 과정에서 관리자 계정과 주문 1건이 삭제됐습니다. 삭제를 알아차렸지만 멈추지 않았고 이를 취약점의 증거로 기록한 뒤 다음 검사로 넘어갔습니다.
“DELETE works! It likely deleted user 1?! Oh no.”
– 실험 당시 AI가 남긴 기록
ARTEX에 내장된 안전장치도 이를 막지 못했습니다. 기본으로는 꺼져 있는 판정 에이전트를 켜고 다시 돌려도 23회의 판정 중 거부는 한 번도 없었고 관리자 계정은 똑같이 지워졌습니다.
연구팀이 오픈 소스 도구들의 코드를 함께 살펴본 결과 자사 점검에 그대로 쓰기 어려운 지점은 이것만이 아니었습니다.
데이터 유출: 점검하며 수집한 정보와 자격 증명이 외부 AI 모델로 그대로 전달됩니다.
범위 이탈: 점검 범위는 프롬프트에만 있고 대부분의 도구에서 코드로 막는 장치는 없습니다.
부하 통제 부재: 한 번의 명령이 대역 전체를 스캔할 수 있어 서비스에 도달하는 요청 수를 제한하지 못합니다.
기록 부재: 대부분의 도구는 점검 중 장애가 나도 어떤 요청이 원인이었는지 확인하기 어렵습니다.
특정 도구의 결함이라기보다 오픈 소스 기반 AI 보안 도구 전반의 특징에 가깝습니다.
ARTEX는 다른 도구가 흉내 낼 수 없는 특별한 기술을 가진 도구가 아닙니다. 도구 이름을 하나씩 쫓는 것만으로는 다음 공격에 대비하기 어렵습니다.
더 큰 문제는 속도입니다. CrowdStrike에 따르면 금전 목적 공격자가 침투 후 내부로 움직이기까지는 평균 29분이 걸리지만 IBM에 따르면 침해를 찾아 막기까지는 평균 247일이 걸립니다. 사람의 속도로 대응하는 한 이 격차는 줄어들지 않습니다. 방어자에게 필요한 건 두 가지입니다.
흔적을 잡고 빠르게 대응하는 체계
AI 공격 도구가 로그에 남기는 흔적을 탐지 규칙으로 갖추고 경보가 울리면 정해진 절차에 따라 바로 대응합니다.
공격자보다 먼저 점검하는 체계
공격자가 자산을 훑는 주기보다 짧게 점검하되 서비스와 데이터를 해치지 않도록 통제된 도구를 사용합니다.
지금까지 소개한 내용은 연구의 일부입니다. 백서 전문에서 아래 내용을 모두 확인해 보세요!
ARTEX 및 오픈 소스 AI 보안 도구의 실제 동작 메커니즘 분석
로그 위치별 확인 항목과 의심 기준
현장 관제 및 사고 조사에 즉시 적용 가능한 공개 탐지 룰셋 (Suricata, Sigma, YARA, ModSecurity)
AI 침투 테스트 도구 11종 비교와 도입 전 검토 항목 7가지
Xint 팀이 분석한 취약점 연구와 최신 보안 인사이트를 이메일로 가장 먼저 받아보세요.
문의: contact@xint.io
웹사이트: xint.io