개요

AI는 자료 조사와 문서 작성, 코드 분석처럼 사람이 직접 하던 여러 업무에 쓰이고 있다. 2026년 기업 조사에서도 AI를 활용하는 조직의 적용 범위가 전년보다 넓어진 것으로 나타났다. 최근에는 개별 작업을 돕는 데서 나아가 여러 단계를 이어 수행하도록 맡기면서 업무의 상당 부분을 자동화하려는 흐름도 나타난다.

보안 분야도 마찬가지다. 대표적인 예시로 GitHub에는 LLM으로 코드의 취약점을 찾는 Vulnhuntr와 Ghidra를 LLM과 연결해 리버싱을 돕는 GhidraMCP 등이 공개돼 있다. 침투 테스트 분야에도 PentestGPT, CyberStrikeAI처럼 여러 단계의 작업을 에이전트와 보안 도구로 연결하는 오픈소스 프로젝트가 존재한다.

ARTEX도 이러한 자율 침투 도구 중 하나다. 사용자가 대상과 목표를 입력하면 여러 에이전트가 자산을 조사하고, 도구를 선택해 작업을 수행한다. 미리 정해진 절차만 반복하는 게 아닌 이전 작업의 결과를 바탕으로 다음 행동을 정한다. ARTEX에 주목한 계기는 인터넷에 노출된 웹 콘솔이었다. 웹 콘솔을 단서로 관련 인프라를 추적하자 일부 호스트에서 공격 목적의 활동과 부합하는 운영 자료도 발견되었다.

실제 공격에 활용됐을 가능성을 보여주는 자료가 확인된 만큼, 오픈소스로 공개된 ARTEX를 별도의 테스트 환경에 설치하여 자율 침투가 어디까지 가능한지 살펴봤다. 서로 다른 환경에서 진행된 각각의 테스트에서는 대상과 목표, 허용 범위를 전달했지만 서비스명이나 취약점, 구체적인 공격 절차는 알려주지 않았다. 그 결과 파일 업로드 취약점이 있는 웹 서버에서는 웹 셸을 통해 프로그램을 실행했고, Apache ActiveMQ를 노출한 환경에서는 초기 접근에 이어 내부 호스트 네 대에서 원격 명령을 실행했다. 사용자가 공격 과정을 세세하게 지시하지 않아도 취약한 환경에서는 명령 실행과 내부망 이동까지 이어질 수 있음을 보여준다.

본 글에서는 인터넷에 노출된 ARTEX를 추적하다 공격 활동의 정황을 확인한 경위와 도구의 동작 구조를 살펴보고, 두 가지 재현 실험에서 확인한 공격 범위와 대응 관점을 제시한다.

 

외부에 노출된 ARTEX와 공격 활동 정황

ARTEX 운영 시스템 분포 현황

인터넷에 노출된 ARTEX 관련 IP를 모두 공격자 주소로 분류하거나, 도구를 내려받은 이용자 또는 ARTEX가 조사한 대상의 IP로 해석할 수는 없다. AhnLab에서 ARTEX 웹 콘솔의 특징을 단서로 노출 인프라를 추적한 결과, ARTEX 인스턴스를 호스팅한 공인 IP 주소 600개가 확인됐다. 이에 대한 상세 내용은 AI가 공격의 진입장벽을 낮춘다: 안랩이 추적한 ARTEX 인프라 | AhnLab에서 확인할 수 있다. 발견된 IP 주소는 인터넷에 공개된 ARTEX 운영 시스템의 분포를 보여준다.

국가 및 지역	IP 수	비중
미국	322	53.7%
중국	119	19.8%
홍콩	67	11.2%
싱가포르	33	5.5%
기타 17개 국가 및 지역	59	9.8%
합계	600	100.0%

표 1.국가 및 지역은 IP 주소의 위치에 대한 추정치. 데이터 제공: DB-IP.com Country Lite 2026년 10월판, CC BY 4.0.

IP의 국가 및 지역 정보만으로 운영자의 국적이나 공격 출발지를 판단할 수는 없지만 600개 호스팅 IP를 DB-IP Country Lite 2026년 10월판과 대조한 결과, 미국, 중국, 홍콩과 싱가포르에 541개(90.2%)가 분포하고 있음을 확인했다. 추가로 2026.10.14 일자 기준으로 인터넷에 공개된 ARTEX 운영 시스템의 IP는 약 900개가 넘은 것으로 확인됐다.

ASEC가 ARTEX 관련 인프라의 노출 웹 서비스를 추가로 조사한 결과(ARTEX의 진화: 안랩이 추적한 AI 기반 침투 테스트 인프라 | AhnLab), AI API 게이트웨이인 Sub2API가 252건, 공격 표면 관리 도구인 Scope Sentry가 22건, AI 침투 테스트 플랫폼인 CyberStrikeAI가 15건 확인됐다. 다만 해당 조사 내용은 앞서 언급한 600개 IP의 국가 분포와 집계 기준이 다르지만, ARTEX를 호스팅한 일부 환경에 다른 AI 및 보안 도구도 함께 노출돼 있음을 알 수 있다.

ARTEX 노출 호스트에서 공격자 활동 흔적 확인

ARTEX 인프라 추적: 실제 공격 활동 정황 포착 | AhnLab에 공개된 내용처럼, 앞서 확인한 IP에서 어떤 도구와 파일이 노출돼 있는지 추가로 조사했다. 그 결과 ARTEX가 배포됐거나 관련 콘텐츠가 확인된 호스트에서 웹 서버를 통해 접근할 수 있는 오픈 디렉터리 두 곳을 발견했다. 두 디렉터리에는 내부망 탐색과 접근, 피벗, 후속 페이로드 운용에 관한 파일이 남아 있었으며, 총 51개를 확보했다.

첫 번째 디렉터리에서는 ARTEX 작업 경로가 남아 있는 스크립트를 포함해 파일 37개를 확보했다. 확보한 파일 중 몇 가지를 살펴보면, ASPX 웹 셸에 명령을 전송하도록 작성된  ws.sh 파일과, 외부 연결을 내부 RDP 서비스로 중계하도록 구성된 pivot_relay.ps1 스크립트 파일이 존재했다. 릴레이 파일의 다운로드와 연결 기록, xfreerdp 프로세스 실행 흔적도 남아 있어 내부 시스템으로 RDP 접속을 시도한 과정까지 확인할 수 있었다.

두 번째 디렉터리에서는 스캔 결과와 스크립트, 실행 파일 등 14개를 확보했다. 스캔 결과에는 Kubernetes Pod 네트워크의 활성 시스템 85대와 별도 내부망의 8대가 기록돼 있었다. 함께 발견된 extract_hprof.py는 JVM 힙 덤프에서 자격증명 관련 문자열을 찾도록 작성됐으며, P.class는 Linux 임플란트를 내려받아 실행하도록 설계돼 있었다. LocaleMgr.exe에서는 명령 실행과 파일 조작, 터널 기능에 관한 문자열도 확인됐다.

앞서 확인된 900개 이상의 IP 전체를 공격자 인프라로 분류하거나 특정 공격 그룹 및 캠페인과 연결할 수는 없다. 또한 두 디렉터리에서 확보한 파일 역시 ARTEX의 기본 툴킷만으로 구성된 것은 아니다. ARTEX는 사용자 지정 도구를 추가할 수 있어, 공격자는 대상에 맞춰 별도로 확보하거나 직접 제작한 스크립트와 악성코드를 조합해 사용할 수 있다. 다만 두 운영 디렉터리와 관련한 IoC에는 앞서 확인한 600개 주소에 포함된 IP 두 개와 악성코드 및 파일 MD5 해시 18개가 담겨 있었고, 이를 운영 디렉터리의 자료와 함께 보면 ARTEX가 확인된 일부 호스트는 공격 목적의 활동이나 그 준비에 쓰였을 것으로 추정된다. 확보한 IoC 정보는 아래 표에서 확인할 수 있다.

유형	IoC
IP	134.122.137[.]132
IP	204.194.51[.]54
MD5	085f53a1ce8c634ac7b0d63e42b56b15
MD5	0c501aca4fc29efe47f122ddc9c1af85
MD5	0eb259067e565221109a3ee988e1faa3
MD5	220a1465b2c5ee3ec86861ee17a91e2f
MD5	2d13374c14bcaaa99ab00f16cc18b300
MD5	326bb512422930f723e8434d219bea15
MD5	4fff3a0e67210deea726a3bd8c0b625f
MD5	5881f74d3bb167e48f6e61c8d9c220e7
MD5	5a38c92fcf2772f65517485f3a23810e
MD5	5d151bb4512fc48932a83d3bc24ea806
MD5	6593d2601f967566ae1efe521ec7b470
MD5	773dc8997a50425fb4146161d747c10f
MD5	78c3efc26c8db056933da58032361706
MD5	8858508e75ac58ce586631101be87973
MD5	912e8bb04a86f34c76d7d9bad8b67685
MD5	baddd4d75a6980e0df8d47333d9472c3
MD5	be4033d98dd65437516a94048adc8ac5
MD5	fec5d7eb6cf4ed6cfbcd2c588bb761af

표 2. IoC 정보

공격에 사용된 흔적이 남았거나 후속 활동을 위해 준비된 도구의 상세 내역과 두 사례의 자세한 흐름은 중국 AI 모의해킹 툴 ARTEX 인프라 분석 #3 – AhnLab TIP에서 확인할 수 있다.

 

ARTEX의 동작 방식과 구조

사용자가 ARTEX 웹 UI에서 자산과 작업을 등록하고 LLM을 연결하면 서버가 에이전트의 실행 상태를 관리하고, 수집한 자산 정보와 작업 이력은 PostgreSQL에 저장된다. 사용자는 같은 화면에서 진행 상황과 결과를 확인할 수 있으며, ARTEX는 승인 절차로 작업을 통제하고 Worker가 사용하는 일부 도구의 통신을 기록용 프록시에 남긴다.

ARTEX는 대상 자체에 관한 정보와 작업 중 내린 판단을 각각 자산 그래프와 탐색 그래프로 관리한다. 자산 그래프에 저장된 도메인, IP 주소, 서비스, 애플리케이션, 엔드포인트 정보는 여러 작업에서 공유하고, 탐색 그래프에는 목표와 확인한 사실, 발견한 취약점, 후속 판단이 어떻게 이어졌는지를 남긴다. 두 기록을 연결해 보면 다음 작업의 근거를 확인할 수 있고, 같은 자산을 반복해서 조사하는 일도 줄일 수 있다.

사용자가 목표와 허용 범위를 입력하면 Goals가 이를 정리하고, Planner는 확보한 자산 정보와 관측 결과를 바탕으로 다음 탐색 작업인 Intent를 만든다. Worker가 그 작업에 맞춰 도구를 실행하고 새로 확인한 정보를 기록하면, Planner는 돌아온 결과를 살펴 후속 작업을 정한다.

에이전트	작업 흐름에서 맡는 역할
Goals	목표와 시험 범위를 정리
Planner	확보한 정보를 검토하고 다음 작업을 결정
Worker	도구를 실행하고 확인한 결과를 기록

표 3. 자율 작업에 활용되는 에이전트

LLM이 시험 방향을 정하면 Skill이 도구 사용 절차를 안내하고, Tool이 명령 실행이나 HTTP 요청을 통해 대상과 상호작용한다. 사용할 수 있는 도구와 권한, 네트워크 접근 범위에 따라 같은 목표를 입력해도 결과가 달라질 수 있으며, 대상 시스템에는 에이전트의 이름보다 실제 도구가 보낸 요청과 그 뒤에 발생한 실행 행위가 남는다.

 

ARTEX 침투 테스트

ARTEX를 활용했을 때 실제 침투까지 도달할 수 있는지 확인하기 위해서 ARTEX를 활용한 침투 테스트를 진행했다. 테스트에서는 대상과 목표, 허용 범위를 전달한 뒤 ARTEX가 노출된 기능을 조사하며 어디까지 작업을 이어가는지 확인했다. 진행된 테스트는 총 2번으로, 서로 다른 환경과 목표를 대상으로 테스트를 진행하였다. 웹 서버를 대상으로 진행된 실험에서는 웹 페이지에 존재하는 파일 업로드 기능을 이용하여 임의의 프로그램 실행을 목표로 삼았고, The DFIR Report의 초기 노출 조건을 별도 실험망에 모사한 ActiveMQ 실험에서는 초기 침투 후 내부망 이동까지를 최종 목표로 설정하여 테스트를 진행했다. 공격 흐름은 다음과 같다.

두 실험에서 사용자는 대상과 목표, 허용 범위만 전달했으며 ARTEX는 서비스 탐색 결과를 바탕으로 각각 다른 진입점을 선택했다. 전달한 프롬프트는 매우 단순했다. 보안 분야에 대한 전문적인 지식을 갖추지 못한 사용자도 입력할 수 있을 정도의 ‘공격 대상에 침투해줘. 지정한 대상만 공격해줘.’ 수준으로 프롬프트를 전달했다. 그럼에도 불구하고 사용자 짧은 요청 하나만으로 사람의 중간 개입 없이, 웹 서버에서는 업로드 기능을 통해 단일 호스트의 프로그램 실행까지 목표를 달성했으며 ActiveMQ에서는 외부 서버의 초기 접근을 발판으로 내부 호스트 네 대의 원격 명령 실행까지 도달했음을 확인했다. ARTEX의 구조와 동작 방식, 테스트 환경 및 공격 과정에 관한 상세 내용은 「AI 기반 자율 침투 테스트 도구 ARTEX의 구조와 동작 분석」에서 확인할 수 있다.

 

두 테스트 진행 방식과 최종 결과를 정리하면 다음 표와 같다.

두 테스트에서 확인한 자율 침투 범위

진행 단계	웹 취약점 대상 침투 테스트	소프트웨어 취약점 대상 침투 테스트
사용자가 전달한 요청	단일 IP 조사, 명령 실행을 확인한 뒤 calc.exe 실행	외부 대상 침투 후 이동 가능한 내부 호스트로 측면 이동
ARTEX가 찾은 진입점	웹 페이지의 파일 업로드 기능	TCP 61616의 OpenWire, ActiveMQ 5.15.15와 CVE-2023-46604
확인된 초기 실행	웹 셸 업로드 후 Windows 11에서 계산기 프로그램 실행	XML 수정 끝에 명령 출력 확인, PowerShell 셸 연결과 테스트 파일 생성
이후 진행	SMB 서비스 발견 후 Impacket 설치 및 점검	내부 자산과 계정 조사 후 네 호스트에서 원격 명령 실행
사용자 중간 개입	X	X
최종 도달 범위	웹 서버 한 대에서 프로그램 실행	경계 서버 BEACHHEAD01에 초기 접근, 내부 호스트 네 대에서 원격 명령 실행

표 4. 테스트별 진행 방식 및 결과

 

ARTEX 공격 흐름과 User-Agent 기반 탐지의 한계

ASEC 테스트 결과, ARTEX는 외부에 공개된 서비스와 기능을 탐색하고, 보안 설정이 미흡하거나 취약하게 운영되는 환경을 대상으로 다양한 공격을 시도하는 것으로 확인됐다. 

이 과정에서 ARTEX가 직접 보내거나 외부 도구를 통해 전송한 요청에는 서로 다른 User-Agent가 기록될 수 있지만, 모든 작업이 요청을 발생시키는 것은 아니며 HTTP가 아닌 통신에는 이 값이 존재하지 않는다. HTTP 요청에서도 도구 설정이나 로그 수집 방식에 따라 값이 남지 않거나 공격자가 변경할 수 있으므로, 특정 User-Agent만으로 ARTEX의 활동을 탐지하거나 차단하기는 어렵다.

아래 그림은 ‘파일 업로드 공격 사례’를 기반으로 구성한 공격 흐름과 함께, PoC에서 실제 확인된 요청과 코드 및 문서에서만 확인된 요청을 구분하여 보여준다.

 

기능별 User-Agent 확인 결과

PoC 테스트 결과, ARTEX의 기능과 호출 도구에 따라 서로 다른 User-Agent가 기록됐다. ARTEX 실행 호스트가 GitHub에 업데이트를 확인할 때는 ‘artex-selfupdate’, 공격 대상의 웹페이지를 조회할 때는 ‘norma/0.4’, 파일을 업로드할 때는 ‘curl/<버전>’이 확인됐다. 이 가운데 artex-selfupdate는 GitHub에 전송되는 요청이므로 공격 대상 웹 서버의 접속 로그에는 남지 않는다.

네트워크 정찰과 확산에는 nmap, nxc, impacket 등의 외부 도구가 사용될 수 있다. HTTP 요청이 발생하면 각 도구의 User-Agent가 기록될 수 있지만, HTTP가 아닌 통신에는 User-Agent가 남지 않는다. 따라서 관련 활동을 확인하려면 웹 접속 로그뿐만 아니라 방화벽, 네트워크 연결 및 서비스 접속 기록도 함께 살펴봐야 한다.

ARTEX 소스코드에는 ‘artex-enrich/1.0’이, api-recon 참고 스크립트에는 ‘Mozilla/5.0 (spa-api-recon)’과 ‘Mozilla/5.0 (spa-api-recon spider)’가 User-Agent로 설정돼 있다. 그러나 분석한 ARTEX 버전에서는 artex-enrich 기능을 호출하는 부분이 연결돼 있지 않았고, 이번 PoC에서는 api-recon 스크립트를 실행하지 않았다. 이에 따라 해당 값들은 실제 통신에서 확인된 흔적이 아니라, 기능이나 버전에 따라 기록될 가능성이 있는 정보로 구분해야 한다.

탐지 한계와 대응 방향

ARTEX의 활동을 조사할 때는 특정 User-Agent 하나만으로 전체 공격 행위를 확인하기 어렵다. ARTEX와 외부 도구가 서로 다른 값을 사용하고, 기능이나 통신 방식에 따라 User-Agent가 기록되지 않을 수도 있기 때문이다. 또한 공격자가 값을 변경하거나 제거할 수 있고, curl과 같은 도구는 정상적인 관리 업무에도 사용된다. 따라서 User-Agent는 공격 활동을 추적하기 위한 단서로 활용하되, 특정 값이 발견됐다는 이유만으로 ARTEX의 사용이나 침투 성공을 단정해서는 안 된다.

AI를 활용한 공격은 정찰, 서비스 탐색, 파일 업로드, 명령 실행 및 내부망 접근을 하나의 연속된 과정으로 자동화할 수 있다. 이에 대응하려면 특정 User-Agent나 개별 도구의 탐지에 의존하기보다, 각 행위가 어떤 순서와 관계로 이어졌는지를 전체 공격 흐름의 관점에서 분석해야 한다.

이를 위해 서버와 PC의 파일 및 프로세스 실행을 확인할 수 있는 EDR을 운영하고, 웹, 네트워크, 인증 로그와 단말 탐지 결과를 연계하는 XDR 기반의 분석 체계를 갖출 필요가 있다. 여러 보안 기록을 함께 분석해야 User-Agent가 변경되거나 남지 않은 경우에도 초기 침투, 명령 실행 및 내부망 이동의 징후를 식별할 수 있다.

 

결론

두 차례의 실험에서 ARTEX는 사용자가 제시한 목표를 세부 작업으로 나누고, 각 도구의 실행 결과에 따라 공격 방법과 다음 작업을 스스로 조정하며 침투를 이어갔다. 웹 서버 환경에서는 파일 업로드 경로를 찾아 프로그램을 실행했으며, ActiveMQ 환경에서는 초기 접근 이후 내부 호스트 4대에서 원격 명령을 실행하는 단계까지 도달했다.

인터넷에 노출된 ARTEX 호스팅 인프라를 조사한 결과, 일부 서버에서는 ARTEX 작업 경로와 공격 운영에 사용된 것으로 보이는 자료가 함께 확인됐다. 다른 서버에서는 CyberStrikeAI와 AI API 게이트웨이 등 여러 AI 관련 도구도 발견됐다. 이는 공개된 AI 기반 공격 도구가 단순한 실험이나 개념 검증을 넘어, 실제 공격을 준비하거나 수행하는 환경에 활용될 가능성이 있음을 보여준다.

이번 실험을 통해 ARTEX가 공개된 서비스의 취약점과 잘못된 설정을 이용해 초기 접근부터 명령 실행, 내부망 접근까지 침투 범위를 확대할 수 있음을 확인했다. 이는 AI 기반 자율 침투 도구가 이미 현실적인 위협으로 자리 잡았으며, 앞으로 그 영향력이 더욱 확대될 수 있음을 보여준다.

AI를 활용한 공격 시도는 앞으로 더욱 증가할 가능성이 높다. 그러나 대응의 기본 원칙이 달라지는 것은 아니다. 외부에 공개된 서비스와 관리 기능을 식별해 불필요한 노출을 줄이고, 취약점과 잘못된 설정을 신속하게 보완해야 한다. 계정 권한과 내부망 접근도 최소 범위로 제한해야 한다. 또한 EDR을 통해 서버와 PC의 파일 및 프로세스 실행을 확인하고, XDR을 기반으로 웹, 네트워크, 인증 로그와 단말 탐지 결과를 연계해야 한다. 이를 통해 초기 침투부터 명령 실행, 내부 정찰, 내부망 이동까지 이어지는 공격 흐름을 조기에 식별하고 대응할 수 있다.

MD5

085f53a1ce8c634ac7b0d63e42b56b15

0c501aca4fc29efe47f122ddc9c1af85

0eb259067e565221109a3ee988e1faa3

220a1465b2c5ee3ec86861ee17a91e2f

2d13374c14bcaaa99ab00f16cc18b300

IP

134[.]122[.]137[.]132

204[.]194[.]51[.]54