ARTEX 금융권 해킹, 우리는 무엇을 준비했나

Polestar SIEM의 Shadow IT·API 보안 대응 이야기

정상처럼 보이는 요청에도, 관제에서 확인해야 할 질문이 남습니다.

최근 금융권 연쇄 침해사고에서 ARTEX(아르텍스) 활용 흔적이 드러나며 AI 자동화 공격이 보안관제의 과제로 떠올랐습니다. 그런데 방어자가 주목할 지점은 도구 이름만이 아닙니다. 대출모집인 조회와 직원 업무지원처럼, 보안 관리에서 뒤로 밀린 서비스가 정보 접근의 통로가 됐다는 점입니다.[1][2]

서버는 정상적으로 응답하고 로그인도 성공합니다. 그런데 호출자에게 그 정보를 볼 권한이 있었을까요? 서비스가 동작한다는 사실과, 접근이 정당하다는 사실은 다릅니다.

우리는 이 간극을 줄이기 위해 외부 노출 관측, 웹·API 로그 분석, 근거 기반 판단과 승인형 대응을 준비해 왔습니다. 최근 사고의 교훈을 Polestar SIEM의 개발 이력과 연결해 보겠습니다.[4]

공격 도구의 이름을 쫓기보다,
그 도구가 악용할 수 있는 빈틈을 연결해 봅니다.

ARTEX가 드러낸 문제는 ‘잊힌 업무 서비스’에 있었습니다

지니언스 GSC가 정리한 공개 자료에서는 신한은행의 대출모집인 조회 서비스, KB국민은행의 직원용 모바일 업무지원시스템, 현대캐피탈의 모집인 조회페이지가 서로 다른 사례로 소개됩니다. 서비스는 달라도, 외부 접점의 인증·권한과 관제 범위를 다시 확인해야 한다는 질문은 이어집니다.[3]

그림 1. 공개 분석의 세 사례와 이 글에서 도출한 관제 질문. 날짜는 공격일이 아닌 언론 공개일입니다.[3]

AI가 바꾼 것은, 다음 시도로 이어지는 속도입니다

SK쉴더스의 가이드가 설명하는 ARTEX는 목표를 나누는 기능, 다음 행동을 결정하는 Planner, 실행을 맡는 여러 Worker를 연결합니다. 결과가 다음 판단에 반영되므로 탐색과 검증, 반복 조회가 연속해서 이어질 수 있습니다. 방어 측도 개별 IP의 경보만 확인하는 데서 멈출 수 없는 이유입니다.[1]

CrowdStrike는 10월 7일, 해당 캠페인과 연관된 공격자 인프라에서 ARTEX 설정 파일과 AI 도구의 세션 기록 등을 분석했다고 발표했습니다. 다만 이 자료만으로 모든 금융사의 사고를 동일한 도구·주체의 공격으로 확정할 수는 없습니다. 기관별 피해와 침투 경로는 조사 결과를 구분해 봐야 합니다.[2]

조회 기능이 열려 있는가?
그 조회를 누가, 어떤 권한으로 반복하는가?

우리는 경보보다 ‘연결’을 먼저 준비했습니다

준비의 출발점은 개별 기능이 아니라 연결이었습니다. 외부에서 보이는 서비스와 그 서비스가 남기는 로그를 잇고, 경보를 해석할 근거와 대응 권한까지 이어야 관제요원이 다음 행동을 결정할 수 있기 때문입니다.

그림 2. 소스 저장소에서 확인한 기능 추가 이력. 모든 기능이 사고 발생 전에 완성됐다는 뜻은 아닙니다.[4]

먼저, 밖에서 보이는 서비스부터 확인합니다

외부 도메인 모니터링은 등록한 자사 도메인과 명시적인 서브도메인의 공개 관측 정보를 조회하고, 서비스·CVE 후보와 변화 이력을 확인하도록 구현했습니다. InternetDB 또는 설정된 Shodan 연동을 사용하며, SIEM이 대상 서버를 직접 포트 스캔하는 방식은 아닙니다.[4]

여기서 중요한 것은 관측의 의미입니다. 수집이 실패했는데 “위험 0건”으로 보이거나, 이번 조회에 나타나지 않았다는 이유만으로 “서비스 폐쇄 완료”로 판단해서는 안 됩니다. 구현에서도 미수집·부분 수집·오류와 비교 가능한 변화 결과를 구분합니다.[4]

다만 이 기능은 모든 미등록 자산과 Shadow API를 자동으로 찾아내는 완성형 ASM을 뜻하지 않습니다. 자동 수집은 기본 비활성이며, 등록 범위·연동 환경을 확인해야 합니다. 별도 자산 조사와 API 목록을 대조하고 책임자와 로그 수집 대상을 정하는 과정이 함께 필요합니다.[1][4]

200 OK를, ‘안전하다’로 읽지 않도록

출입증이 있다고 모든 서랍을 열 수 있는 것은 아닙니다. API에서도 로그인 성공은 호출자의 신원을 확인했다는 뜻일 뿐, 요청한 데이터의 조회 권한까지 보증하지는 않습니다.[1]

그림 3. 본인 정보만 조회하는 서비스를 가정한 인증·인가 개념도. SIEM이 권한 검사를 대신하지는 않습니다.[1]

로그의 이름부터 맞추고, 같은 조건으로 비교합니다

우리는 웹·API·WAF 로그의 요청 방식과 경로, 응답 코드, 전송량, 세션 식별값을 상관분석에 사용할 수 있도록 보강했습니다. 예를 들어 서로 다른 표현의 응답 코드를 HTTP 문맥에서 정규화하고, 기존에 저장된 로그도 같은 상관 필드로 해석하도록 연결합니다.[4]

프록시 연결 상대인 srcIp와 클라이언트 주소인 clientIp도 같은 값으로 합치지 않습니다. 다만 헤더를 정규화했다고 그 값의 진위까지 검증된 것은 아닙니다. 적용 환경에서는 프록시의 헤더 신뢰 경계와 사용자·세션 값의 출처를 함께 검수해야 합니다.[4]

이 기반 위에서 “특정 조회 API의 성공 응답이 평소와 다르게 반복되는가”를 조사할 수 있습니다. 실제 테스트에도 API 경로·응답 코드 조건을 적용하고, 조건에 맞지 않는 요청과 다른 그룹을 구분하는 사례가 있습니다. 여러 IP의 동일 사용자 조회로 확장하려면 서비스 범위 안에서 검증된 사용자·세션 매핑과 정상 배치 예외를 추가로 확인해야 합니다.[4]

객체별 인가 결과와 실제 반환 정보는 애플리케이션 감사 로그에서 확보해야 합니다. 응답 코드나 요청 건수만으로 인가 위반·유출 규모를 확정하지 않습니다.[1]

Selene은 판단 근거를 모으고, 실행 권한은 넘겨받지 않습니다

하나의 API 경보만으로는 조사 우선순위를 정하기 어렵습니다. 같은 사용자나 자산의 다른 경보, 평소 행위와의 차이, 위협 인텔리전스와 자산 중요도를 함께 보면 “왜 지금 이 경보를 봐야 하는가”를 설명할 수 있습니다.

그림 4. 현재 구현을 바탕으로 재구성한 판단·설명·실행의 경계. 실제 제품 화면은 아닙니다.[4]

Selene은 저장된 경보를 출발점으로, 확인된 사용자·자산·호스트·IP와 시간창에 맞는 근거를 구성합니다. 관련 경보와 UEBA, CTI 등을 정리하고 판단 당시 읽은 입력을 보존합니다. 누락되거나 범위가 잘린 근거도 표시하므로, 나중에 판단 이유를 다시 확인할 수 있습니다.[4]

현재 기본 판단기는 CPU에서 동작하는 휴리스틱입니다. 외부 AI API나 GPU 없이 사용할 수 있지만, 이를 고객 데이터로 학습·검증된 SOC 모델이라고 부르지는 않습니다. 표시되는 신뢰도 역시 실제 정답률을 뜻하지 않습니다. 기본 모드는 관찰용 OBSERVE입니다. 현재 연결된 판단 방식은 고객 SOC 환경의 신뢰도 검증을 마치지 않았으므로, AI 판단만으로 자동 차단을 승인하지 않습니다.[4]

설명용 LLM은 저장된 판단을 이해하기 쉽게 풀어 주는 별도 요청 경로입니다. 앞으로 학습형 모델을 적용하더라도 고객 데이터 평가와 검증을 거쳐야 합니다. 판단을 돕는 기능과 대응을 실행할 권한을 분리하는 것, 이것이 우리가 준비한 안전장치입니다.[4]

같은 공격 징후가 보이면, 이렇게 조사하고 대응합니다

외부 협력사 조회 서비스에서 여러 IP의 반복 요청이 발견됐다고 가정해 보겠습니다. 다음은 구현된 기능을 활용하는 운영 적용 시나리오이며, 실제 금융사 사고를 재현하거나 차단한 실적은 아닙니다.

그림 5. Guided Response의 통제와 운영 절차를 연결한 예시. 외부 장비 연동은 환경별 검수가 필요합니다.[4]

먼저 서비스의 맥락을 확인합니다. 외부 노출 관측과 자산 목록을 대조합니다. 책임 부서와 웹 로그, 인증·조회 감사 기록의 수집 여부를 확인합니다. 기록이 없는 구간은 확인이 필요한 공백으로 남깁니다.[1][4]

다음으로 요청을 행위 단위로 살펴봅니다. 같은 서비스에서 서버가 확인한 사용자·세션을 기준으로 반복 조회와 IP 변화를 조사합니다. 정상 배치·상담 업무인지 확인한 뒤, 생성된 경보는 Selene의 관련 근거와 함께 검토합니다. 이름이 같거나 IP가 비슷하다는 이유만으로 서로 다른 사용자를 합치지 않습니다.

조치는 미리보기에서 시작합니다. 연결된 플레이북의 대상·커넥터·승인 조건과 dry-run 결과를 확인합니다. 명시적인 실행 요청은 기존 SOAR 통제 경로를 거칩니다. 대상이나 정의가 바뀌면 재확인을 요구하고, 중복 요청은 기존 실행을 반환합니다. 결과가 불명확하면 자동으로 재실행하지 않습니다.[4]

근본 원인은 서비스에서 고칩니다. 검수된 방화벽·EDR 연동과 별개로, API 호출 제한이나 세션 폐기는 Gateway·인증 시스템의 연계가 필요합니다. 객체별 인가 결함 수정도 애플리케이션의 책임입니다. SIEM은 그 판단에 필요한 근거와 대응 이력을 연결합니다.[1][4]

차단 이후에도, 질문은 이어져야 합니다

한 IP를 제한했다고 끝나지는 않습니다. 다른 경로의 재시도와 정상 업무 영향을 함께 확인하고, 반복 조회 억제와 인증·인가 결함 수정을 병행해야 합니다.[1]

자주 묻는 세 가지 질문

Polestar SIEM이 ARTEX를 자동으로 식별하나요?
현재 소개하는 기능은 ARTEX 전용 식별기가 아닙니다. 외부 노출 관측과 웹·API 상관분석으로 이상행위를 찾고, 연결된 근거를 판단에 활용합니다.[4]

HTTP 200이 반복되면 곧바로 차단하나요?
아닙니다. 호출자의 업무 범위, 인가 결과, 반환 기록과 정상 작업을 함께 확인합니다. 요청 성공만으로 비인가 조회를 확정하지 않습니다.[1]

AI가 금융 업무를 임의로 중단할 수 있나요?
Selene이 직접 플레이북을 실행하지 않습니다. 명시 요청과 기존 승인·보호 정책을 거치며, 조치 범위는 검수한 연동과 고객 운영 정책으로 정합니다.[4]

우리가 말하는 준비는, 확인 가능한 연결입니다

HTTP 정규화부터 미리보기 변경·중복 실행 통제까지 테스트를 준비했습니다. 실제 ARTEX 공격 재현과 고객 환경의 탐지·대응 성능은 별도 검증이 필요합니다.[4]

ARTEX라는 이름이 바뀌어도 남는 준비.
보이는 자산, 연결된 근거, 통제 가능한 대응입니다.

외부 조회 서비스 하나부터 시작해 보십시오. 담당자, 권한 검사, 조회 기록, 대응 권한까지 연결하는 것. Polestar SIEM의 Shadow IT 대응은 여기서 출발합니다.

참고 자료

[1] SK쉴더스, 「AI 자동화 공격 시대, Shadow IT를 노린 침해사고 분석 및 대응 가이드」. 2026.10.6 기준.

[2] CrowdStrike, 2026.10.7. Unknown Threat Actor Uses AI-Driven ARTEX to Target South Korean Finance

[3] Genians GSC, 2026.10.12 게시·10.7 분석 기준. 금융분야 침해사고 이슈 분석

작성자 : YW Jung | 정보보안팀