ARTEX 한국어판(artex-ko)은 LLM이 조종하는 여러 에이전트가 목표를 쪼개고 실제 도구를 실행하며 침투 테스트를 스스로 이어 가는 오픈소스 도구 ARTEX를 한국어로 현지화하고, 탐지 규칙 같은 방어 자료를 함께 공개한 판본이다.
원본 저장소(Autumn-27/ARTEX)는 10월 13일 GitHub API 조회에서 '찾을 수 없음(404)'을 돌려줬다. 지니언스 시큐리티 센터는 10월 12일 분석에서, 10월 11일 현재 원본 저장소가 삭제돼 접속할 수 없고 Docker Hub 이미지도 내려갔지만 소스를 복제한 포크·미러와 한국어 현지화판은 계속 유통되고 있다고 적었다. 삭제 이유는 확인되지 않았다. 10월 3일 만들어진 한국어판 jiwoochris/artex-ko는 10월 13일 기준 별 1,389개, 포크 1,645개다. 관심 표시인 별보다 사본인 포크가 더 많다. 이 글은 한국어판 README가 밝힌 구조를 방어자 관점으로 읽고, 저장소가 함께 낸 탐지 규칙을 기업의 SIEM·WAF·인증 로그에 어떻게 적용하고 검증할지, 무엇은 잡지 못하는지 정리한다. 설치와 실행 방법은 다루지 않는다.
왜 지금 중요한가
ARTEX는 9월 말부터 이어진 국내 금융권 연쇄 유출 사고에서 흔적이 나온 도구다. 지니언스는 같은 분석에서 공격 추정 서버에 ARTEX가 구축된 것은 '확인된 사실'로, ARTEX가 공격 전 과정의 실제 실행에 쓰였는지는 '정황'으로 나눴다. 한국어판 README도 경고문에 원본 ARTEX가 국내 금융기관 대상 개인정보 유출 공격에 사용된 정황이 조사 당국에 포착됐다는 언론 보도를 적고, 수사가 진행 중이라고 밝혔다. 사고 경과와 피해 규모는 ARTEX 흔적이 나온 은행 연쇄 해킹에 따로 정리했다.
코드의 갈래도 늘고 있다. 10월 9일 만들어진 파생 저장소 bdg9412/artex-ko-plus('AegisLoop: ARTEX 기반 공격·방어 검증')도 10월 13일 기준 별 166개, 포크 143개다. 누구나 띄울 수 있는 도구라면 방어자에게 남는 질문은 '누가 썼나'보다 '우리 로그에 보이나, 보이면 막히나'다. 지니언스도 대응의 출발점은 공격자 귀속이 아니라 노출 면 축소와 인증 강화라고 정리했다.
한국어판이 방어자에게 쓸모 있는 이유는 공격 기능과 함께 탐지 규칙, 침해지표, 호스트 분류 스크립트를 공개했기 때문이다. 다만 그 규칙이 잡는 범위는 좁고, 저장소가 한계를 직접 적어 두었다. 둘을 같이 알아야 제대로 쓴다.
artex-ko는 어떻게 구현돼 있나
README에 따르면 ARTEX는 Go 단일 백엔드에 Next.js 프런트엔드를 내장하고 데이터를 PostgreSQL에 저장한다. 에이전트 기능은 norma라는 SDK가 맡고, 판단은 LLM API를 호출해 얻는다. 지니언스는 자체 AI 모델이 없다고 설명했다. 한국어판은 에이전트 판단을 좌우하는 내부 추론 프롬프트를 원문 그대로 두고, 사람에게 보이는 탐지 결과·요약·리포트·대화 응답만 한국어로 내도록 지시한다. 원문으로 벤치마크된 동작을 유지해 번역에서 오는 품질 저하를 피하려는 방침이라고 README는 설명한다. 10월 12일 첫 릴리스(0.3.15-ko.1)도 상류 0.3.15를 바탕으로 했다. 구성 요소를 방어자 관점으로 옮기면 다음과 같다.
| 구성 요소 | 하는 일(README 기준) | 방어자에게 남는 것 |
|---|---|---|
| goals·planner | 목표를 쪼개고, 그래프를 읽어 아직 안 본 방향만 '의도'로 배정한다. 주입점 발견 → 인증 정보 획득 → 측면 이동 → 권한 상승 같은 순서를 공유 할 일 목록에 적고, 앞 단계가 사실로 확인되면 다음 단계를 배정한다 | 공격이 순서를 지키며 깊어진다. 단건 경보보다 같은 출처의 단계 연쇄를 봐야 한다 |
| worker | 의도 하나를 맡아 실제 도구(Bash·HTTP)를 실행하고 결과를 그래프에 쓴다. 작업당 기본 3개가 병렬로 돌고, 다른 worker의 실행 과정을 검색해 재사용한다 | 한 대상에 여러 각도의 요청이 동시에 온다. 공격 요청의 User-Agent(UA)는 실행된 도구의 기본값이다 |
| 자산 그래프·탐색 그래프 | 도메인·서비스·엔드포인트(무엇이 있나)와 목표·의도·사실·취약점(어디까지 시험했나)을 따로 쌓고 서로 연결한다 | 같은 자산을 다른 각도로 다시 찾아온다. 도구가 돈 DB에는 이 테이블들이 남는다 |
| enrich(보강) | 발견한 자산을 DNS·HTTP로 자동 확인한다 | 단발 GET과 고유 UA artex-enrich/1.0이 대상 쪽 로그에 남는다 |
| 기록 프록시·가드 | worker 트래픽을 자체 CA로 복호화해 전부 기록하고, 도구 호출을 승인 규칙으로 검사한다 | 도구가 돈 호스트에 루프백 프록시, 자체 CA 인증서, 차단 감사 기록이 남는다 |
여기에 사람이 실행 도중 대화로 끼어들어 힌트를 주는 mainagent가 붙는다. 완전 무인 실행만이 아니라 사람이 방향을 잡아 주는 운용도 되는 구조다.
한국어판의 방어 가이드는 이 구조가 탐지를 어렵게 하는 이유를 세 가지로 든다. LLM이 맥락마다 명령과 페이로드를 새로 만들어, 알려진 문자열을 맞추는 WAF 시그니처가 비껴가기 쉽다. 라운드 사이에 쉬며 방향을 바꾸므로 '짧은 시간에 많은 요청'만 보는 탐지는 놓칠 수 있다. 정찰과 침투가 한 흐름으로 이어져 첫 접촉부터 자료 반출까지의 간격이 짧아진다. 반대로 한 출처가 정찰, 엔드포인트 열거, 파라미터 탐침, 인증 시도를 짧은 간격으로 잇고, 401·403·429 응답을 받은 뒤에도 변형을 멈추지 않는 행동은 숨기기 어렵다고 본다. 이 글의 탐지 전략도 여기서 출발한다.
도구 자체도 공격 표면이다. 한국어판 첫 릴리스는 비밀번호가 아직 없는 인스턴스에 먼저 닿은 사람이 관리자 계정을 차지할 수 있던 문제를 고쳤고, 모든 인터페이스에 열리던 기본 바인딩을 127.0.0.1로, 모든 출처를 허용하던 CORS를 허용 목록으로 바꿨다. 지니언스는 공격 추정 서버에서 외부에 열려 있던 ARTEX 로그인 화면을 직접 캡처했고, 지니언스가 인용한 언론 보도에 따르면 전 세계 약 600개 IP에서 ARTEX 인스턴스가 관찰됐다. 이들이 모두 공격용인지는 확인되지 않았다. 우리 외부 자산에 누군가 시험 삼아 띄운 콘솔이 없는지도 확인할 일이다(공격표면 관리 자가점검 5단계).
함께 공개된 방어 자료
- 방어·탐지 가이드(docs/defense-ko.md, 영어판 별도): 기존 스캐너와의 차이, 대상 관점과 포렌식 관점의 지문, 하드닝 체크리스트, 사고 대응, 국내 신고 채널을 담았다.
- Sigma 규칙 9개: 원자 규칙 5개(보강 조회 UA, 자가 업데이트 송신 UA, 가드 차단 감사 기록, 기록 프록시 CA 파일, 파괴적 명령 헌팅)와 상관 규칙 4개(보강 조회 속도, 여러 호스트로 퍼지는 폭, 가드 차단 반복, 가드 기록과 파괴적 명령의 동시 발생)다.
- Suricata 규칙 3개: 네트워크에서 보이는 ARTEX 관련 UA 두 가지를 겨냥한다.
- ATT&CK 레이어: 규칙이 태그한 6개 전술, 8개 기법을 Navigator 형식으로 정리했다.
- 침해지표: CSV 7행과 같은 내용의 MISP 이벤트다.
- 호스트 분류 스크립트: SIEM 없이 의심 호스트 한 대의 셸에서 읽기 전용으로 도는 점검 도구다.
- 테스트: 규칙 테스트 여덟 종을 CI 머지 게이트로 묶었다.
저장소는 모든 지표가 추정이 아니라 소스에서 확인한 문자열에 근거한다고 밝힌다. 예외는 하나로, 워커의 웹 조회 UA norma/0.4는 ARTEX가 아니라 의존 SDK에 하드코딩된 값이다. 원칙도 분명하다. README의 표현으로 '돌려 볼 수 없는 탐지 규칙은 주장일 뿐'이다. 다만 테스트는 합성 캡처와 표본 이벤트로 돈다. 증명하는 범위는 규칙이 걸려야 할 표본에 걸리고 정상 표본에 침묵한다는 데까지다. 우리 환경의 탐지율은 우리 로그로 따로 확인해야 한다.
어디서 잡고, 무엇은 못 잡나
| 계층 | 공개 자료 | 잡는 것 | 못 잡거나 주의할 것 |
|---|---|---|---|
| 네트워크(IPS) | Suricata 3개 | artex-enrich/1.0 요청과 그 고속 반복, 워커 웹 조회 UA norma/ |
종단 간 TLS 안에서는 UA가 안 보인다. norma/는 같은 SDK를 쓰는 다른 도구도 낸다 |
| 웹·WAF 로그 | Sigma 원자 1개, 상관 2개 | 보강 조회 단건, 속도, 여러 호스트로 퍼지는 폭 | Bash로 실행한 도구(curl·nmap 등)의 공격 요청에는 ARTEX 지문이 없다 |
| 웹 행동 | 방어 가이드 4.2절 일반 템플릿 | 한 클라이언트가 일정 시간 창 안에 열거·탐침·인증 신호를 모두 보이는 패턴 | ARTEX 전용이 아니다. 허가된 스캐너·QA가 오탐을 낸다 |
| 인증 로그 | 방어 가이드 4.3절 의사 규칙 | 실패율 급변, 저속 분산 시도, 본인확인·일회성 코드 엔드포인트 열거 | 배포용 규칙이 없어 직접 써야 한다 |
| 호스트·포렌식 | Sigma 원자 4개·상관 2개, 침해지표, 분류 스크립트 | 자가 업데이트 송신 UA artex-selfupdate, 기본 포트 8787과 127.0.0.1:8788, 가드 차단 기록, 기록 프록시 CA, 탐색 그래프 테이블, 프록시·CA 환경변수 조합 |
공격받은 서비스가 아니라 도구가 돈 호스트(경유지·내부 악용)를 조사할 때 쓴다. 이름·포트·경로를 바꾸면 빠진다 |
배포 전에 알아야 할 한계는 저장소가 직접 적은 것만 추려도 다섯 가지다.
- 부재는 안전이 아니다. UA, 포트, 경로는 운영자가 바꿀 수 있다. 걸리지 않았다고 ARTEX가 없다는 뜻이 아니다.
- 본 공격 트래픽에는 ARTEX 고유 지문이 없다. ARTEX는 공격 요청에 고유 UA를 강제하지 않는다. worker가 실행한 도구의 기본값이 남고, 운영자가 바꾸면 정상 브라우저처럼 보일 수도 있다.
- UA는 평문에서만 보인다. 종단 간 TLS 구간에서는 네트워크 센서가 UA를 볼 수 없다.
- 보조 단서에 그치는 지표가 있다.
norma/UA는 같은 SDK를 쓰는 다른 도구도 내고, 파괴적 명령은 정상 관리자도 쓴다. 저장소는 이 둘을 가져오기용 침해지표 목록에서 일부러 뺐다. - 커버리지는 완전성이 아니다. ATT&CK 레이어의 점수는 그 기법을 태그한 규칙이 있다는 뜻이지, 모든 변형을 잡는다는 뜻이 아니다.
IP 차단도 같은 맥락이다. 방어 가이드는 출처가 불분명한 비공식 IP 목록을 그대로 차단 규칙에 넣지 말라고 권한다. 자율 에이전트는 출발 IP를 수시로 바꾸고, 목록에 공유 대역이 섞이면 정상 고객까지 막힌다. 이번 금융권 사고에서도 금융감독원이 특정한 공격 IP 28개(중복 제외)는 12개국을 경유했고, 경찰은 상당수가 추적 회피용 세탁 IP라고 확인했다(지니언스 정리). 공식 침해지표를 받아 유효 기간과 오차단 위험을 검토한 뒤 적용할 때만 의미가 있다.
우리 SIEM·WAF·인증 로그에 적용하는 순서
- 로그 필드부터 확인한다. UA, 실제 클라이언트 IP, 응답 코드, URI와 쿼리 문자열, 호스트 이름이 남아야 규칙이 걸린다. 프록시·CDN 뒤라면 X-Forwarded-For로 복원한 주소나 세션 식별자를 쓴다.
- 네트워크 규칙은 HTTP가 보이는 자리에 둔다. Suricata 규칙은 센서가 실제 HTTP 요청을 볼 수 있는 트래픽 구간에 적용한다. TLS를 종단하는 WAF·리버스 프록시·로드밸런서의 접근 로그는 Sigma 또는 해당 SIEM의 로그 규칙으로 분석한다.
- SIEM이 상관 규칙을 받는지 본다. 저장소 실측(sigma-cli 3.1.0)에서 Splunk, Elasticsearch EQL, Grafana Loki는 상관 규칙까지 변환됐지만 Microsoft Sentinel·Defender XDR(kusto 백엔드), Elasticsearch Lucene, OpenSearch는 원자 규칙만 변환됐다. 이때는 시간 창 상관을 제품 규칙으로 다시 써야 한다. 규칙의 일반 필드 이름도 우리 스키마와 대상 테이블에 맞게 매핑한다. 필드 이름이 다르면 질의는 아무것도 찾지 못한다.
- 표본 이벤트로 발화를 확인한다. 규칙마다 걸려야 할 표본과 걸리면 안 될 정상 표본을 시험 인덱스에 넣고 경보 수를 센다. 저장소 테스트와 같은 방식이다. 운영 서비스에 공격 도구를 돌려 확인하지 않는다.
- 웹 다단계 상관은 우리 기준선으로 만든다. 방어 가이드 4.2절 템플릿은 404·400 응답, 주입·경로 순회 표식이 든 쿼리, 로그인·본인확인 경로 요청이나 401·403이라는 세 종류의 신호가 같은 클라이언트에서 일정 시간 창 안에 관측되면 높은 등급 경보를 낸다. 다만 공개 템플릿에는 404·400 응답의 발생 건수를 세는 조건이 없으므로, 반복 열거를 판정하려면 별도 집계 조건을 추가하고 시간 창과 함께 우리 기준선에 맞춰 검증해야 한다. 일반 행동 규칙이라 허가된 취약점 스캐너와 QA 출발지는 허용 목록에 넣고, 셋을 모두 요구해 놓치는 사례가 있으면 둘로 완화하라고 가이드는 적었다.
- 인증 로그 규칙은 직접 쓴다. 가이드 4.3절은 의사 규칙만 준다. 계정·IP당 로그인 실패율 급변, 여러 계정에 걸친 저속 분산 시도, 실패에서 성공으로 넘어가는 비정상 속도, 본인확인·일회성 코드 엔드포인트의 열거성 접근이다.
- 침해지표는 표시대로 가져온다. MISP 이벤트는 규칙에 근거한 지표에만 탐지·차단용 표시(to_ids)를 달고, 포트와 DB 테이블 이름은 분류 힌트로 남겼다. 흔한 포트 번호를 방화벽 차단 목록에 넣지 않는다.
- 경보 뒤 조치를 미리 정한다. 가이드는 사람 승인만 기다리면 자율 공격 속도를 못 따라간다며 의심 출처 격리와 세션 무효화의 자동 발동을 권한다. 오차단 범위를 따져 자동 조치 대상을 고르고, 인증·접근·송신 로그와 DNS 질의를 보존한다. 침해가 의심되면 KISA(보호나라, 국번 없이 118)에 신고하고, 정보통신서비스 제공자는 침해사고를 알게 된 때부터 24시간 안에 신고해야 한다(정보통신망법 제48조의3). 첫 1시간의 대응 순서는 침해사고 1시간 골든타임에 정리했다.
KISA 10월 3일 권고로 막을 곳을 정한다
탐지는 공격을 알아차리게 할 뿐이다. 막는 일은 공격 표면과 인증에서 한다. ARTEX의 행동을 KISA '최근 사이버공격 대비 기업 보안강화 권고'(10월 3일)의 점검 구분에 대응시키면 다음과 같다.
- 자산을 자동으로 열거한다 → ① 외부 노출 시스템. 자산 그래프는 도메인에서 서브도메인, 서비스, 엔드포인트로 노출면을 쌓는다. 미사용 서비스를 차단하고, 관리자 페이지·DB·관리용 접속 기능은 업무상 필요한 대상과 지정된 접속 경로에서만 열리게 한다. 방어 가이드는 공개 PoC가 도는 알려진 취약점이 1순위 표적이라며 CISA KEV를 패치 우선순위 기준으로 삼으라고 권한다(노출·KEV 기준 패치 우선순위).
- 응답을 보며 식별자를 바꿔 조회한다 → ② 웹·API. 요청마다 서버에서 데이터·기능별 권한을 검증하고 조회 범위를 제한한다. KISA가 모니터링 대상으로 꼽은 '식별자를 변경한 연속 조회'는 방어 가이드가 경고한 식별자 증감 대량 시도와, '접근 거부 이후 다른 경로를 통한 조회'는 실패 후 우회 변형과 겹치는 행동이다(API 보안 점검 가이드).
- 인증 정보 획득을 다음 단계로 잇는다 → ③ 계정·인증정보. 관리자 계정에 다중인증을 적용하고, 노출된 키·토큰은 삭제에 그치지 말고 폐기·교체한 뒤 사용 이력을 조사한다. 방어 가이드는 제휴·모집·직원용 보조 경로의 본인확인을 본 서비스와 같은 강도로 맞추라고 덧붙인다(크리덴셜 스터핑 대응).
- 측면 이동과 권한 상승을 노린다 → ④ 서버·내부망. 서비스 계정 권한을 줄이고, 시스템 간 통신을 필요한 대상·포트로 제한하고, 웹서버의 비정상 명령 실행에 경보를 건다.
- 쉬지 않고 오래 진행한다 → ⑤ 중요정보·대응체계. 웹·API, 인증, 서버, DB 로그의 시간을 맞춰 통합하고, 단시간 탐지와 장시간 누적 분석을 함께 돌린다. 소량 조회가 반복돼 쌓이는 접근도 잡으라는 것이 KISA 권고다.
직접 시험해 보려는 조직이 갖출 통제 조건
공개 도구를 우리 자산에 직접 돌려 보려는 보안팀도 있을 것이다. 방법이 아니라 갖춰야 할 조건만 적는다.
먼저 법이다. README는 '허가 없는 사용은 그 자체로 범죄가 됩니다'라고 경고한다. 정보통신망법 제48조 제1항은 정당한 접근권한 없이 또는 허용된 접근권한을 넘어 정보통신망에 침입하는 것을 금지하고, 제71조 제1항 제11호는 이를 5년 이하의 징역 또는 5천만원 이하의 벌금으로 처벌한다. 같은 조 제2항은 미수범도 처벌한다. 허가를 받았더라도 허용된 범위를 넘으면 같은 조항에 걸릴 수 있다는 뜻이다. 개인정보가 결부되면 개인정보 보호법도 적용된다(README). README는 AGPL-3.0 라이선스 자체가 사용 용도를 제한하지 않는다고 밝히고, 지니언스는 ARTEX README의 사용 제한·면책 조항이 선언적 조치에 그친다는 평가를 전했다. 라이선스가 사용을 합법으로 만들어 주지는 않는다.
- 서면 허가와 범위: 대상(도메인·IP), 기간과 시간창, 제외 대상, 승인자를 문서로 남긴다. 클라우드·위탁사처럼 남이 운영하는 자산이 섞이면 그 운영자의 점검 정책과 허가 조건을 따로 확인한다(모의해킹 범위 산정과 RFP 작성법).
- 격리망: README는 본인이 소유한 로컬 격리 환경, 곧 OWASP Juice Shop·DVWA처럼 일부러 취약하게 만든 환경에서만 검증하라고 한다. 관리 콘솔은 인터넷에 열지 않는다.
- 운영 데이터 금지: 도구 실행 결과가 다시 LLM에 입력되는 구조라(지니언스 설명) 운영 데이터가 섞이면 LLM 공급자에게 넘어갈 수 있고, 기록 프록시는 요청·응답 본문을 도구 호스트에 저장한다. 합성 데이터와 시험 계정만 쓴다.
- 전용 API 키와 비용 한도: 시험 전용 LLM 키를 따로 발급해 공급자 쪽 사용 한도를 걸고, 끝나면 폐기한다.
- 사람이 검토한 차단 규칙: 지니언스는 ARTEX의 차단 규칙과 승인 절차가 운영자가 직접 설정하는 구조라고 평가했다. 기본값을 믿지 말고 허가 범위에 맞는지 사람이 확인한다.
- 기록 보존과 관제 통보: 시험 시간창, 출발지, 작업 기록을 보존하고 보안관제에 미리 알려 실제 공격과 구분한다.
- 결과 검증: AI가 낸 취약점은 후보다. 재현 여부와 영향을 사람이 확인하고, 같은 시간창에 우리 경보가 울렸는지도 대조한다. 파생 저장소 AegisLoop는 이 공격·방어 검증 고리를 붙여 별도 실습(AWS Windows·Splunk)에서 정상 업무 오탐이 1건에서 0건으로 줄었다고 적었다. 다만 제한된 실습 표본의 판정 건수일 뿐 운영 환경 전체의 정확도·오탐률을 뜻하지 않고, 모의 Splunk 테스트도 실제 기업 Splunk 연결이나 탐지 정확도를 입증한 것은 아니라고 스스로 밝혔다.
ARTEX 대응 자가점검 10문항
'아니오'가 나온 항목부터 손본다.
- WAF·웹서버 로그에 UA, 실제 클라이언트 IP, 응답 코드, 쿼리 문자열이 모두 남는가?
- 네트워크 시그니처를 TLS가 풀린 HTTP를 볼 수 있는 자리에 두었는가?
- 우리 SIEM이 Sigma 상관 규칙을 변환하는지 확인했고, 안 되면 시간 창 상관을 제품 규칙으로 다시 썼는가?
- 변환한 규칙을 걸려야 할 표본과 정상 표본으로 시험해 발화와 무발화를 모두 확인했는가?
- UA와 무관하게, 한 출처가 짧은 시간에 열거·탐침·인증을 모두 하는 행동에 경보가 울리는가?
- 허가된 스캐너·QA·외부 점검 업체의 출발지를 허용 목록과 사전 통보 절차로 실제 공격과 구분하는가?
- 본인확인·일회성 코드·모집인 조회 같은 보조 인증 경로가 본 서비스와 같은 인증 강도와 계정·토큰 단위 조회 제한을 갖췄는가?
- 관리 기능이 업무상 필요한 대상과 지정된 경로에서만 열리고, 관리자 계정에 다중인증이 있는가?
- 내부 서버에서 낯선 관리 화면(기본 8787 포트), 루프백 기록 프록시, 출처 모를 MITM CA 인증서를 찾는 분류 절차가 있는가?
- 자율 침투 도구를 직접 시험한다면 서면 허가 범위, 격리망, 합성 데이터, 전용 키와 비용 한도, 기록 보존을 모두 갖췄는가?
점검을 맡길 때
공개 규칙을 SIEM에 넣고 표본으로 시험하는 일은 내부에서 시작할 수 있다. 다만 경보가 울리기 전에 닫아야 할 곳, 곧 보조 인증 경로의 우회, 식별자만 바꾸면 열리는 조회, 인증 정보 획득에서 권한 상승으로 이어지는 경로는 공격자 관점에서 직접 재현해 봐야 안다. 보안 전문 기업 SENTRIX의 AI 심화 취약점 진단은 합의한 대상·계정·시나리오 안에서 AI 점검 도구로 공격면을 매핑하고 취약점 후보를 넓게 모은 뒤, 레드팀이 권한 우회와 연쇄 공격 경로(인증 우회→권한 상승→유출)의 재현 여부와 영향을 검토해 재현 근거와 수정 방향을 제시하고, 합의한 범위에서 재점검한다. 웹서비스의 인증서·보안 헤더 같은 항목은 CodeScan 무료 스캔으로 먼저 볼 수 있지만, 외부 관측만 하며 SQL 인젝션·XSS·인증 우회·프롬프트 인젝션 공격 테스트는 하지 않는다. 확인된 위험을 방화벽·WAF·IPS 정책과 오탐 조정에 반영하는 일은 보안장비 운영에서, 외부에 열린 자산과 담당자부터 정리해야 한다면 SENTRIX ASM에서 시작한다.
자율 AI 공격이 노릴 인증 우회와 권한 경로, 공격자보다 먼저 재현해 확인하세요. AI 심화 취약점 진단 문의하기
참고 자료
- jiwoochris/artex-ko(2026-10-03 생성, 2026-10-13 확인), ARTEX 한국어판 README
- jiwoochris/artex-ko(2026-10-13 확인), 자율 AI 공격 방어·탐지 가이드(docs/defense-ko.md)
- jiwoochris/artex-ko(2026-10-13 확인), ARTEX 탐지 규칙(detections/README.ko.md)
- jiwoochris/artex-ko(2026-10-13 확인), ARTEX 탐지 규칙: Suricata
- jiwoochris/artex-ko(2026-10-13 확인), ARTEX 침해지표
- jiwoochris/artex-ko(2026-10-13 확인), ARTEX ATT&CK 커버리지
- jiwoochris/artex-ko(2026-10-12), 변경 이력: 0.3.15-ko.1 한국어판 첫 릴리스
- bdg9412/artex-ko-plus(2026-10-09 생성, 2026-10-13 확인), AegisLoop: ARTEX 기반 공격·방어 검증
- GitHub REST API(2026-10-13 조회), Autumn-27/ARTEX 저장소 조회 결과(Not Found)
- 지니언스 시큐리티 센터(2026-10-12), 금융분야 침해사고 이슈 분석
- KISA 보호나라(2026-10-03), 최근 사이버공격 대비 기업 보안강화 권고
- 국가법령정보센터(2026-10-02 시행), 정보통신망 이용촉진 및 정보보호 등에 관한 법률(법률 제21988호)