ARTEX·LLM 모의시험: AI가 만든 웹 요청, WAF에는 무엇이 남았나?
LLM의 판단부터 ARTEX의 도구 실행까지 — 실제 HTTP 요청 8건으로 검증한 AI 공격 자동화의 구조
핵심은 ‘AI가 공격했다’는 표현이 아니라, 누가 무엇을 결정하고 어떤 요청이 실제 발생했는지를 증거로 연결하는 것입니다.
이번 승인된 사내 랩에서는 LLM이 실행 계획과 Python 코드를 작성하고, ARTEX가 도구를 실행했으며, 그 결과 발생한 8건의 HTTP 요청을 독립 수집 기록과 PLURA WAF 화면에서 대조했습니다. 이 시험은 합성 공격 시그니처 관측이며, 실제 시스템 침해나 금융권 사고 재현은 아닙니다.
시험일: 2026년 10월 9일 · 시험 환경: 사내 승인 랩 · ARTEX v0.3.14
핵심만 보기
- LLM은 계획·코드·도구 호출을 생성했고, ARTEX는 파일 작성·명령 실행·결과 전달·작업 상태 관리를 맡았습니다. 실제 HTTP 연결은 ARTEX가 실행한 Python 코드에서 발생했습니다.
- 목표 서버에 전송된 요청은 GET 8건이었고, 그 작업에 사용된 LLM 호출은 20회였습니다. 두 숫자는 서로 다른 지표입니다.
- 이전 ARTEX 정적 수집 모듈에서 관측한
Mozilla/5.0 (spa-api-recon)과 달리, 이번 LLM 생성 Python 요청 8건에는 User-Agent 헤더가 없었습니다. - WAF 화면에서 8건의 시각·메소드·응답 상태를 실행 기록과 대조했습니다. 그러나 화면만으로 AI 사용 여부, WAF 룰의 실제 조치, 취약점 악용 성공을 확정할 수는 없습니다.
- 결론적으로 ARTEX의 특정 User-Agent를 탐지하거나 차단하는 것만으로 ARTEX·LLM 기반 요청 전체를 포괄할 수 없습니다. 웹 요청·응답과 행위의 맥락을 함께 분석해야 합니다.
1. 왜 ARTEX와 LLM을 실제로 연결해 시험했나?
앞서 공개한 금융권 해킹 공격 IOC 1보에서는 ARTEX 공개 소스의 일부 수집 모듈에서 사용하는 User-Agent 문자열을 도구 식별 후보로 제시했습니다. 2보에서는 공격자 IP와 이러한 후보 문자열을 서로 다른 성격의 지표로 구분했습니다.
그렇다면 한 가지 질문이 남습니다.
ARTEX에 LLM을 연결하고 AI가 직접 수집 코드를 작성한다면, 같은 User-Agent가 계속 나타날까요?
이를 확인하기 위해 사람이 승인한 시험 범위 안에서 ARTEX와 LLM을 연결하고, AI의 도구 실행 기록부터 실제 HTTP 요청·응답, WAF 관측 결과까지 추적했습니다.
여기서 중요한 구분이 있습니다. WAF에 SQL 형태 문자열이 기록되었다는 사실만으로 AI의 사용을 입증할 수는 없습니다. 사람, 일반 스크립트, AI가 생성한 스크립트 모두 비슷한 요청을 보낼 수 있습니다. 이번 시험에서 AI 관여를 확인한 근거는 WAF 요청 자체가 아니라 LLM 호출·ARTEX 도구 실행·독립 요청 기록을 연결한 결과입니다.
2. 모의시험의 조건: 무엇을 AI에 맡겼는가?
| 항목 | 실제 시험 조건 |
|---|---|
| ARTEX | v0.3.14 · 고정된 소스 및 실행 이미지 |
| LLM | 시험 환경에 설정된 gpt-6-astra |
| 대상 | 승인된 사내 시험서비스 1대 · HTTP 80 |
| 요청 범위 | GET 최대 8건 · 동시 1건 · 요청 간격 1초 이상 |
| 응답 제한 | 건당 2MiB 이하 |
| 실제 전송 | 대상 웹서비스로 GET 8건 |
| LLM 호출 | 20회(웹 요청 8건과 구별) |
| 최종 상태 | ARTEX 작업 done |
운영자가 대상 서비스와 네 개의 시험 케이스, 사용 가능한 쿼리 문자열, 요청 상한을 먼저 지정했습니다. LLM이 선택한 것은 HTTP 수집 방식, Python 코드 작성, 요청을 실행하는 순서, 결과 비교 방법이었습니다.
따라서 이번 결과를 AI의 자율 취약점 발견이나 미지의 공격 페이로드 생성 사례로 소개해서는 안 됩니다. 대상 서비스도 실제 취약점이 아닌 합성 시그니처를 재현하는 시험 페이지로 안내되었으며, 해당 서버의 원본 소스까지 독립 검증한 것은 아닙니다.
보안상 공개 자료의 내부 주소·계정·시험 경로는 비식별화했습니다. TARGET, CLIENT, 케이스 AD 및 R01R08은 공개용 별칭으로, 실제 WAF 이벤트 ID가 아닙니다.
3. LLM은 판단하고, ARTEX는 실행했다
AI 공격 자동화를 이해하려면 생각하고 결정하는 구성 요소와 실제로 도구를 동작시키는 구성 요소를 구분해야 합니다.
| 단계 | LLM의 역할 | ARTEX의 역할 |
|---|---|---|
| 목표 처리 | 목표를 해석하고 순서 계획 | 작업·목표·상태·도구 정보 제공 |
| 코드 생성 | Python http.client 기반 수집 코드 작성 |
Write로 파일 생성 |
| 실제 실행 | Bash 도구 호출 내용 결정 |
명령 실행 및 Python 프로세스 구동 |
| 관측·분석 | 응답 비교 코드 작성, 결과 해석 | 도구 출력 전달·작업 기록 유지 |
| 증거 정리 | record_fact 호출 |
확인 결과를 작업 데이터에 기록 |
| 종료 판단 | prove_goal 호출 |
목표 충족 기록 및 done 처리 |
실제 흐름을 정리하면 다음과 같습니다.
사람이 목표·대상·한도를 지정
↓
ARTEX가 목표·상태·도구 정보를 LLM에 제공
↓
LLM이 실행 계획과 Python 코드, 도구 호출을 생성
↓
ARTEX가 Write / Bash 도구를 실행
↓
Python 프로세스가 랩 게이트웨이를 거쳐 HTTP 요청 전송
↓
시험서비스의 응답과 도구 출력이 ARTEX를 통해 LLM에 전달
↓
LLM이 결과를 분석하고 사실 기록·종료를 요청
↓
ARTEX가 작업을 done으로 종료
HTTP 요청을 보낸 주체는 LLM 자체가 아니라 ARTEX를 통해 실행된 Python 프로세스였습니다. 이 차이는 네트워크 로그에서 어떤 특징이 나타날지 판단할 때 중요합니다. 랩 게이트웨이는 별도로 대상·메소드·속도·건수를 제한하고 요청·응답을 수집했습니다.
4. AI가 작성한 코드는 실제로 실행됐는가?
시험 기록에는 파일 작성뿐 아니라 명령 실행, HTTP 요청, 응답 분석 및 정상 종료가 연결되어 있습니다.
| ARTEX 활동 순번 | 실행 기록 | 확인한 의미 |
|---|---|---|
| 27 | Write |
AI가 작성한 collect.py 파일 생성 |
| 30 | Bash |
홈페이지 기준선 및 시험 목록 2건 조회 |
| 33 | Bash |
저장된 목록의 로컬 분석 — 추가 웹 요청 없음 |
| 36 | Bash |
대조 2건, 합성 오류·스크립트 표식 2건 요청 |
| 39 | Bash |
지정된 SQL 형태 쿼리 2건 요청 |
| 42·45 | Write·Bash |
비교 코드 생성 후 상태·길이·해시·표식 분석 |
| 48 | record_fact |
관측 사실과 판단 한계 기록 |
| 57 | prove_goal |
목표 충족 처리 및 정상 종료 |
실제 대상 요청은 2026년 10월 9일 오전 11시 1분 7초부터 42초까지(KST) 발생했습니다.
| 공개 요청 | 시각(KST) | 요청 구분 | HTTP 상태 | 응답 크기 |
|---|---|---|---|---|
| R01 | 11:01:07 | 홈페이지 기준선 | 200 | 11,705B |
| R02 | 11:01:09 | 시험 목록 | 200 | 125,991B |
| R03 | 11:01:31 | A: 쿼리 없는 대조 | 200 | 10B |
| R04 | 11:01:32 | B: 쿼리 없는 대조 | 200 | 13B |
| R05 | 11:01:33 | C: 합성 오류 응답 | 511 | 14B |
| R06 | 11:01:34 | D: 스크립트 표식 응답 | 200 | 13B |
| R07 | 11:01:41 | A: 지정 SQL 형태 쿼리 | 200 | 10B |
| R08 | 11:01:42 | B: 지정 버전 함수 형태 쿼리 | 200 | 13B |
A에 사용한 지정 입력은 select x from y order by 1, B는 version(이었습니다. 두 값 모두 운영자가 미리 제공한 합성 시험 케이스의 입력입니다.
여기서 LLM 호출 20회는 요청 생성과 분석을 진행하기 위한 모델 호출 수를 뜻합니다. 이를 서버를 향한 공격 요청 20건으로 해석하면 안 됩니다.
WAF 화면과 독립 수집 기록의 대조
PLURA WAF 화면에서 이번 실행 구간에 해당하는 **8개 표시 항목(화면 순번 54~61)**의 시각·GET 메소드·HTTP 응답 상태가 독립 수집 기록과 정합하게 나타났습니다. 화면에 표시된 두 쿼리 문자열도 전송한 값과 일치했습니다.
또한 AI 작업공간에 저장된 응답 본문과 독립 수집기에 저장된 본문을 비교한 결과, 8건 모두 SHA-256 해시가 일치했습니다. 대조 케이스처럼 같은 본문이 반복되는 경우에는 해시만이 아니라 URL·상태·실행 시각도 함께 확인했습니다.
다만 이 WAF 자료는 제공된 화면을 전사한 공개용 파생 기록입니다. 전체 원문 이벤트, User-Agent, 전체 경로, 룰 ID, 실제 조치와 정책 버전까지 검증한 자료는 아닙니다. WAF 화면과 수집기 시각의 작은 차이도 네트워크 지연 값으로 해석하지 않았습니다.
5. 가장 중요한 발견: ARTEX의 User-Agent가 보이지 않았다
앞선 정적 수집 모듈 시험에서는 다음 문자열이 관측됐습니다.
Mozilla/5.0 (spa-api-recon)
그러나 이번에는 LLM이 http.client를 사용하는 Python 코드를 작성했습니다. 그 코드가 보낸 실제 요청 8건에는 User-Agent 헤더 자체가 없었습니다. 별도의 값으로 User-Agent를 위조한 것이 아니라, 해당 코드가 헤더를 추가하지 않은 결과입니다.
이 사실의 의미는 분명합니다.
특정 ARTEX 모듈의 고정 User-Agent를 탐지하는 규칙은, LLM이 새로 작성한 코드를 통해 발생하는 다른 형태의 요청까지 식별하지 못할 수 있습니다.
원본 요청 헤더를 대상으로 한 오프라인 대조에서 Mozilla/5.0 (spa-api-recon) 정확 일치 조건은 0/8건이었습니다. 이는 실제 PLURA 탐지 룰의 성능이나 차단 건수를 측정한 결과가 아닙니다.
WAF 화면에서는 이전 모듈 요청에 차단(사용자정의)가 표시됐지만, 이번 요청 8건의 유형 칸은 비어 있었습니다. 다만 그 차이가 User-Agent 때문인지, 다른 룰·정책·표시 방식 때문인지는 아직 확인하지 못했습니다. 유형 칸이 비어 있다는 사실만으로 전체 탐지가 실패했다거나 실제 차단이 일어나지 않았다고 단정할 수는 없습니다.
반대로 User-Agent가 없다는 사실만으로 AI 또는 악성 요청을 판별해서도 안 됩니다. 이번 시험의 정상 홈페이지 기준선 요청도 동일하게 User-Agent 없이 전송됐습니다.
6. 공격처럼 보이는 응답이 침해 성공을 뜻하지는 않는다
시험에는 SQL 형태의 쿼리와 DB 버전처럼 보이는 응답이 등장했습니다. 그러나 쿼리가 없는 대조 요청에서도 동일한 응답이 나왔습니다.
| 케이스 | 관측 내용 | 확인 가능한 결론 |
|---|---|---|
| A | 쿼리 유무와 관계없이 qaaaqqaaaq 응답 |
SQL 실행 성공을 입증하지 않음 |
| B | 쿼리 유무와 관계없이 1.1.1-MariaDB 응답 |
실제 DB 버전을 조회했다는 증거가 아님 |
| C | HTTP 511 반환 | 합성 오류 케이스의 상태이며 운영 장애 증거가 아님 |
| D | 스크립트 형태 표식이 텍스트로 반환 | 브라우저 내 실행을 확인하지 않았으므로 XSS 성공 증거가 아님 |
A와 B는 각각 대조 요청과 쿼리 요청의 HTTP 상태·본문 길이·본문 해시까지 동일했습니다. 이는 고정된 합성 응답일 가능성을 뒷받침하지만, 서버 내부 구현까지 증명하지는 않습니다.
이번 시험의 결과를 정확하게 표현하면 다음과 같습니다.
| 질문 | 판단 |
|---|---|
| LLM이 수집 방식과 코드를 정하고 ARTEX가 실행했는가? | 확인 |
| 실제 HTTP 요청 8건이 전송되고 응답이 수집됐는가? | 확인 |
| WAF 화면에 해당 요청과 정합한 흔적이 있는가? | 일부 필드에서 확인 |
| AI가 미지의 취약점·페이로드를 스스로 발견했는가? | 시험하지 않음 |
| SQL 실행·인증 우회·정보 탈취에 성공했는가? | 입증하지 않음 |
| 이번 WAF 룰의 탐지·차단 효과가 검증됐는가? | 상세 룰·조치 확인 필요 |
| 이 결과가 실제 금융권 사고의 ARTEX 사용을 증명하는가? | 아님 |
AI가 도구를 실행했다는 사실, 공격 형태의 문자열이 관측됐다는 사실, 실제 침해가 성공했다는 판단은 서로 다른 문제입니다.
7. 그렇다면 WAF는 무엇을 탐지해야 할까?
이번 결과가 제시하는 방향은 단일 도구 문자열보다 요청·응답과 행위의 연결을 우선해야 한다는 것입니다. 다음 항목은 공개용 랩 결과를 바탕으로 정리한 탐지·검증 후보이며, 실전 공격 IOC로 확정된 목록은 아닙니다.
| 탐지·분석 후보 | 활용 방향 | 적용 시 주의점 |
|---|---|---|
| ARTEX 정적 모듈의 User-Agent | 해당 모듈 사용 가능성 조사 | ARTEX·LLM 모든 실행 경로를 대표하지 않음 |
| User-Agent 누락 | 요청 생성 특성의 한 요소로 분석 | 정상 도구에도 나타남. 단독 차단 근거로 부적절 |
| 쿼리 변화와 응답 비교 | 입력 변형·응답 차이 추적 | 응답 표식만으로 DB 실행 여부를 판정하지 않음 |
| 목록 조회 → 대조 → 쿼리 요청 | 순차적 웹 탐색 행위의 상관분석 | 이번 시험 목표의 영향을 받은 패턴으로 AI 고유 특징이 아님 |
| 응답 상태·길이·본문 특징 | 공격 단계와 결과의 맥락 확인 | 합성 5xx·고정 응답을 실제 피해로 오인하지 않음 |
운영 환경에서 우선 연결할 관측값은 다음과 같습니다.
요청 시각·출발지·대상 Host
+ HTTP 메소드·전체 URI·Query String·요청 본문
+ User-Agent 등 요청 헤더
+ 응답 상태·응답 본문에서 확인 가능한 단서
+ 인증·세션·권한 판정
+ 관련 서버·프로세스 행위
→ 공격 시도·처리 결과·실제 영향을 구분
핵심은 로그의 양 자체가 아니라 판단에 필요한 맥락을 확보하는 것입니다. 웹 요청만으로는 실제 서버 처리 결과를 놓칠 수 있고, 응답의 표식만으로도 침해 성공을 오판할 수 있습니다. 따라서 WAF의 요청·응답 관측과 서버 측 인증·권한·프로세스 기록을 필요한 범위에서 연결해야 합니다.
이는 PLURA-XDR이 추구하는 웹 요청·응답과 서버 행위의 연계 분석 방향과도 맞닿아 있습니다. 다만 이번 랩에서 실제로 검증한 것은 웹 요청·응답 및 WAF 화면의 일부 필드 대조이며, PLURA-EDR 기반의 침해 행위나 WAF·EDR 상관탐지 성능까지 시험한 것은 아닙니다.
다음 검증에서 확인할 항목
- WAF 원문 이벤트에서 전체 URI·쿼리·헤더·룰 ID·실제 조치·적용 정책 버전을 확인합니다.
- 정상 요청과 비교해 User-Agent 유무 및 순차적 요청 패턴의 오탐 가능성을 점검합니다.
- 원 서버의 인증·권한·실행 결과를 연결해 공격 시도와 침해 성공을 구분합니다.
- 여러 코드·도구 경로에서 동일한 고정 IOC가 얼마나 유지되는지 반복 시험합니다.
- 실제 탐지 성능을 평가할 때는 탐지·경보·차단을 서로 다른 결과로 기록합니다.
결론: AI 공격 대응은 ‘AI라는 이름’이 아니라 실제 행위를 보는 데서 시작한다
이번 승인 랩에서는 LLM의 코드 생성과 도구 호출 → ARTEX의 실제 실행 → Python의 HTTP 요청 → 응답 분석 → 작업 종료를 연결해 확인했습니다.
동시에 기존에 관측한 ARTEX 전용 User-Agent가 이번 8건에는 나타나지 않았습니다. 이는 특정 도구 문자열에만 의존한 식별 방식이 AI가 생성하는 다양한 실행 경로를 포괄하지 못할 수 있음을 보여줍니다.
하지만 이번 결과로 실제 취약점 악용, 데이터 탈취 또는 특정 금융권 사건과의 관련성이 확인된 것은 아닙니다. 또한 제공된 WAF 화면만으로 PLURA의 실제 탐지·차단 성능을 평가할 수도 없습니다.
AI 공격에 대응하려면 ‘어떤 AI 도구였는가’를 추정하는 것에서 멈추지 말고, 실제 웹 요청·응답과 서버의 처리·행위를 연결하여 ‘무엇을 시도했고, 무엇이 실행됐으며, 무엇을 막았는가’를 확인해야 합니다.
참고 자료
이 글은 2026년 10월 9일 실시한 승인된 사내 ARTEX·LLM 합성 시그니처 시험의 공개용 파생 기록을 바탕으로 작성했습니다. 공개용 자료는 원본 증거 전체가 아니며, IP·계정·원본 응답·비밀값·관리 화면을 제외했습니다.
01_requests.json: 요청 8건의 비식별 시각·상태·응답 크기·해시02_tool_timeline.json: ARTEX 도구 실행 순서03_verification.json: 시험 조건과 완료 검증 범위artex-llm-flow.mmd: 수정 가능한 Mermaid 흐름도artex-llm-flow.png: 이미지(PNG) 흐름도artex-llm-flow.svg: 벡터 이미지(SVG) 흐름도
