아르텍스 흔적 4개 발견…AI 자율 침투도구가 금융 보안에 던진 경고

글쓴이 Haechi

2026년 10월 05일

AI를 활용하여 생성한 이미지입니다.

국내 금융기관을 겨냥한 공격 정황을 분석하는 과정에서 AI 기반 자율형 침투 테스트 도구인 ARTEX(아르텍스)와 관련한 흔적이 발견됐어요. 다만 특정 서버에서 도구 이름이 확인됐다는 사실과, 그 도구가 실제 신한은행 공격에 사용됐다는 사실은 같지 않아요. 현재 보도도 이 둘을 구분하고 있어요.[1]

도구 자체의 한국어판 공개 범위는 ARTEX 한국어판 소개 기사에서 따로 확인할 수 있어요. 도구의 공개·기능 소개는 금융권 공격에서 실제 사용됐다는 증거와는 별개예요.

이번 이슈의 핵심은 이름이 낯선 도구 하나가 아니라, LLM을 연결한 에이전트가 자산을 찾고 취약점을 분석하는 과정을 자동화할 수 있다는 점이에요. 보안 담당자가 허가한 환경에서 쓰면 침투 테스트를 빠르게 할 수 있지만, 공격자가 악용하면 정찰과 반복 조회의 비용을 낮출 수 있어요.

아르텍스에서 확인된 것은 무엇일까?

ZDNet 보도에 따르면 국내 금융권 공격 인프라에서 ARTEX 관련 문자열이 확인됐고, 오아시스시큐리티가 9월 23일부터 10월 3일까지 수집한 데이터를 분석했어요. 이 기간에 관련 인프라 관측 기록은 500건이었고, 중복을 제거한 고유 IP는 359개, IP와 서비스 포트 조합은 392개였어요.[1]

그중 334개 IP에서는 ARTEX가 기본 웹 서비스에 사용하는 것으로 알려진 TCP 8787 포트가 한 차례 이상 관측됐어요. 관측된 서버의 위치는 미국·중국·홍콩에 집중됐고 한국 IP는 4개였지만, 서버가 있는 국가가 공격자의 국적이나 실제 위치를 뜻하지는 않아요. 클라우드와 VPS를 거치면 공격자와 서버 위치가 달라질 수 있기 때문이에요.[1]

숫자가 크다고 해서 359개 서버가 모두 같은 공격에 쓰였다고 볼 수도 없어요. 같은 서버가 시점에 따라 재사용됐거나, 여러 서비스가 한 호스트에 함께 있었을 가능성이 있어 추가적인 시계열 분석이 필요해요. 이 부분은 보안 분석 결과의 한계이기도 해요.

왜 기존 방어가 흔들릴 수 있을까?

자동화된 공격은 사람이 브라우저를 열고 하나씩 확인하는 방식과 달라요. 에이전트가 자산을 찾고, 응답을 비교하고, 다음 요청을 고르는 과정을 반복할 수 있어요. 회사가 IP 차단과 단순 요청 횟수 제한만 두면 공격자가 주소나 요청 순서를 바꿔 우회할 가능성이 있어요.

그렇다고 AI가 들어간 모든 요청을 바로 악성으로 볼 수도 없어요. 검색봇, 접근성 도구, 테스트 자동화, 정상적인 앱 기능도 자동 요청을 사용해요. 보안팀은 모델 이름을 차단하는 것보다 인증 여부, 요청의 순서, 짧은 시간 동안의 대량 조회, 계정별 접근 범위, 응답에 포함되는 개인정보를 함께 봐야 해요.

금융권 대응과 연결되는 지점

같은 날 과기정통부와 KISA는 금융권 공격의 민간 확산을 막기 위해 KISC 대응을 강화하고, 기업 모니터링과 비상출동조를 운영한다고 밝혔어요.[2] 이 조치는 ARTEX 사용을 공식 확인했다는 뜻이 아니라, 자동화된 공격을 포함한 사이버 위협의 확산 가능성에 대응하기 위한 별도의 조치예요.

조직 입장에서는 두 가지 점검을 나눠야 해요. 첫째, 외부에 공개된 자산과 서비스 포트를 세어야 해요. 둘째, 조회 API와 관리자 기능이 로그인·추가 인증 없이 얼마나 많은 정보를 보여 주는지 확인해야 해요. 도구 이름을 알고 있는 것보다 이 두 가지가 실제 피해를 줄이는 데 더 직접적이에요.

보안팀이 확인할 항목

인터넷에 노출된 관리 포트와 테스트용 웹서비스를 자산 목록과 대조해요.
특정 번호를 바꿔가며 반복 조회할 수 있는 API에 계정·권한·속도 제한이 모두 있는지 확인해요.
정상 브라우저와 직접 API 호출을 구분할 수 있도록 요청·응답 로그를 남겨요.
고객·직원 개인정보를 조회하는 기능에는 목적과 범위에 맞는 추가 인증을 붙여요.
의심스러운 IP와 포트가 발견되면 차단 전에 로그와 시간대를 보존해 조사에 넘겨요.

확정된 사실과 아직 모르는 사실

확정된 것은 ARTEX 관련 문자열과 인프라 관측 정황이 있었다는 점, 그리고 국내 금융권에 대한 해킹 대응이 강화되고 있다는 점이에요.[1][2] 반면 특정 도구가 실제 공격에 사용됐는지, 발견된 인프라가 하나의 공격자에 속하는지, 모든 금융권 사고가 같은 방식인지까지는 이 자료만으로 확정할 수 없어요.

이 구분을 지켜야 보안 대응이 흔들리지 않아요. 도구 이름만 보고 공포를 키우면 정상적인 침투 테스트와 공격 인프라 분석을 혼동하게 되고, 반대로 정황을 가볍게 보면 외부 자산과 권한의 빈틈을 놓칠 수 있어요. 지금 필요한 대응은 AI라는 단어를 막는 것이 아니라, 자동화된 탐색과 대량 조회가 가능한 경로를 찾아 실제 권한과 함께 줄이는 일이에요.

아르텍스라는 이름보다 중요한 것

보안팀이 도구 이름을 IOC(침해지표)로 활용하는 것은 필요하지만, 이름 문자열만 차단하면 방어가 끝나지 않아요. 공격자가 도구를 수정하거나 다른 자동화 프레임워크로 바꾸면 문자열 차단은 바로 무력화될 수 있어요. 포트 8787 같은 특정 포트도 마찬가지예요. 정상 서비스가 같은 포트를 쓸 수 있고, 공격자는 포트를 바꿀 수 있어요.

따라서 관측된 IP와 포트는 출발점으로 사용해야 해요. 같은 주소에서 어떤 순서로 요청이 이어졌는지, 짧은 시간에 여러 호스트를 훑었는지, 응답에서 얻은 식별자를 다음 요청에 재사용했는지까지 로그를 묶어 보는 것이 중요해요. 이 정보가 있어야 자동화된 정찰과 일반적인 검색·모니터링 트래픽을 구분할 수 있어요.

AI 보안의 현실적인 대응선

조직이 해야 할 일은 AI가 만든 요청을 모두 막는 것이 아니에요. 외부 API에 계정별 속도 제한을 두고, 민감한 조회는 목적과 권한을 확인한 뒤 필요한 필드만 반환하도록 줄이는 것이 먼저예요. 같은 계정이 짧은 시간에 여러 고객번호를 조회하거나, 실패한 인증 뒤에 곧바로 다른 경로를 반복 호출한다면 모델 사용 여부와 관계없이 조사 대상으로 올려야 해요.

내부 침투 테스트에서 AI 도구를 사용할 때는 범위와 시간, 허용된 계정을 문서로 고정해야 해요. 테스트 서버와 운영 서버를 분리하고, 자동화 에이전트가 실제 개인정보를 읽지 못하도록 샘플 데이터를 사용해야 해요. 이번 관측 결과는 AI 도구 자체보다 자동화된 탐색이 실제 인터넷에 노출될 때 어떤 규모로 반복될 수 있는지를 보여주는 경고로 읽는 편이 정확해요.