금융위원회는 2026년 10월 14일 은행·저축은행·상호금융·여전업·전금업·온투업·가상자산사업자 등 전 업권 16개사에서 침해사고를 파악했고, 유출 규모는 약 10만건(성명·연락처·주민등록번호·이메일 등)이며 계좌 비밀번호·카드번호처럼 바로 부정결제로 이어질 정보의 유출은 확인되지 않았다고 발표했다. 사례 사이의 연관성, 같은 주체인지 여부, AI 해킹 가능성은 아직 확인 중이다.
공격자가 AI 도구를 썼다는 구체적 근거는 정부 발표가 아니라 민간 위협 인텔리전스 분석에서 나왔다. CrowdStrike는 10월 7일 공격자 서버에서 중국에서 개발된 오픈소스 에이전트형 침투 테스트 도구 ARTEX의 인스턴스를 확인하고, 공개 디렉터리에 남은 AI 코딩 에이전트 세션 기록을 분석했다. Recorded Future는 10월 16일 이 행위자를 TAG-217로 추적해 8월 17일부터 인프라를 시험한 기록을 찾았지만, AI가 공격을 얼마나 가속했는지는 가용 증거로 확정할 수 없다고 적었다.
피해사별 보도 경과는 10월 6일 글 ARTEX 흔적이 나온 은행 연쇄 해킹에, 다른 AI 해킹 사고와의 비교는 AI 해킹 사고 사례 2026에 있다. 이 글은 그 뒤 나온 1차 자료로 공격 흐름을 나누고, 금융회사와 핀테크 보안팀이 어느 로그에서 무엇을 찾고 어떤 순서로 점검할지 정리한다.
한눈에 보기
| 항목 | 내용 |
|---|---|
| 언제 | 준비 정황 2026년 8월 17일부터(Recorded Future), 캠페인 9월 하순~10월 초(CrowdStrike), 신한은행 사고 접수 9월 30일(금융위원회) |
| 누가 | Recorded Future가 TAG-217로 추적하는 미상 행위자. CrowdStrike는 이름 붙은 그룹과 연결하지 않고, 중국어 사용자이며 금전 목적일 가능성이 높다고 봤다(중간 신뢰도). 16개사 전부의 소행인지는 확인되지 않았다 |
| 무엇이 뚫렸나 | 금융위원회가 파악한 16개사: 은행 4곳(신한·국민·부산·하나), 저축은행 4곳(예가람·웰컴·디비·오케이), 여신 2곳(현대캐피탈·산은캐피탈), 온투 2곳(PFCT·모우다), 전금 1곳(브라이트픽스), 가상자산 2곳(스트리미·프라뱅), 상호금융 1곳(새마을금고중앙회). 공개된 침투 지점은 서로 다른 두 은행의 금융 중개인용 대출 진행 조회 서비스와 직원 모바일 업무지원 시스템이다(CrowdStrike, 업계 보도 인용) |
| AI가 한 일 | 공격자 서버에 ARTEX 인스턴스(주 LLM은 DeepSeek v4.1-flash)와 AI 코딩 에이전트 세션 기록이 있었다. CrowdStrike는 이 인스턴스가 한국 공격을 수행했을 가능성이 높다고 평가했다(확정 아님) |
| 사람이 한 일 | 도구·모델 선택, 지시 파일에 둔 중국어 침투 테스트 지시, 유출 데이터 판매처 질문은 운영자 쪽에서 나왔다. 공개 디렉터리 방치도 운영자의 실수다 |
| 피해·영향 | 약 10만건, 계좌 비밀번호·카드번호 유출은 확인되지 않았다. 공격자가 판매처를 찾은 정황이 있고, 금융위원회도 보이스피싱·스미싱 같은 2차 피해 대비를 주문했다 |
| 지금 상태 | 금융위원회가 연관성·동일 주체·AI 해킹 가능성을 확인 중이며, 금융회사들이 공유 IP로 침해 여부를 계속 확인하고 있어 사고 기업은 늘 수 있다. 130개사 미흡 보고 뒤 4대 정책과제가 나왔다. 취약점 유형과 CVE는 공개되지 않았다 |
| 출처 신뢰도 | 피해사·규모는 정부 발표, AI 사용 정황은 민간 분석(공격자 서버 직접 분석, 귀속은 중간 신뢰도), 침투 지점은 업계 보도 인용이다. 피해 수치는 출처마다 시점·단위가 다르다 |
무슨 일이 있었나: 타임라인
- 2026-08-17~09-05: TAG-217이 원격 접속용 인프라 시험·인터넷 스캐닝(8월 17~22일, 피해 시스템 접속 성공 기록 없음)에 이어 YiiMP 채굴 플랫폼 공격 도구·리눅스 공격 도구(8월 22일까지), 아이폰·안드로이드 실험용 작업 공간(9월 5일까지)을 마련했다. 모바일 침해 성공은 나타나지 않았다(Recorded Future).
- 2026-09-26까지: 작업 환경에 AI 도구와 정찰·트래픽 프록시·페이로드 전달·결제 절차 검토 기록이 있었다(Recorded Future).
- 2026-09 하순~10 초: CrowdStrike가 세션 기록 등으로 파악한 캠페인 활동 기간이다.
- 2026-09-30: 신한은행 침해사고 접수, 금융위·금감원·금보원이 당일 현장조사에 착수했다(10월 6일 보도자료).
- 2026-10-02: 금융위원회 사무처장 주재 긴급 상황대응 회의. 국민은행 등의 추가 피해를 언급하고 인증 없이 내부정보에 접근할 수 있는 경로 점검과 공격 IP·수법 공유를 요청했다.
- 2026-10-04: 금융위원장 주재 전 금융권 긴급 점검회의(10월 6일 보도자료). 전면 재점검·결과 보고와 필수 외 외부 접근의 원칙적 차단을 요청했다.
- 2026-10-07: CrowdStrike가 공격자 서버 분석과 IP 지표 10개를, PLURA가 전달받은 '금융감독원 전파 의심 IP 목록'의 IP 19개를 공개했다. ARTEX 후보 User-Agent(UA) 3종은 PLURA가 10월 3일 1보로 냈다.
- 2026-10-08까지: 555개사 12개 항목 체크리스트 점검. 425개사 '적정', 130개사 미흡사항 보고(10월 14일 발표).
- 2026-10-14: 금융위원회가 16개사 파악과 4대 정책과제를 발표했다.
- 2026-10-16: Recorded Future가 TAG-217 분석을 공개했다.
공격 흐름 단계별 분석
출처별 사실을 공격 순서로 놓았다. ATT&CK 번호는 CrowdStrike 매핑(T1583.003, T1588.007, T1090) 외에는 작성자가 대응시킨 참고값이다.
1단계 사전 준비: 인프라 시험, 스캐닝, 보조 도구
Recorded Future는 공격자가 남긴 공개 디렉터리로 은행 공격이 알려지기 몇 주 전의 준비 과정을 재구성했다. 가상자산 지갑 파일 탈취, 리눅스 통제권 확대와 비밀번호 추출, 모바일 약점 시험용 도구가 있었지만 금융사 침해에 쓰였는지, 스캐닝 대상이 어디였는지는 나오지 않는다. 공개본에는 CVE와 지표도 없다.
- 기법: 능동 스캐닝(T1595, 작성자 대응), 도구 확보
- 방어자가 볼 흔적: 스캐닝 출발지와 대상은 공개되지 않아 대조할 지표가 없다. 8월 중순 이후 방화벽 차단 로그에서 출발지별 목적지 포트 수를 세는 일반 점검만 가능하다.
2단계 공격 인프라와 LLM: 홍콩 주 서버, ARTEX 호스트, 여러 모델
CrowdStrike는 세션 기록이 보여 준 2서버 구조에서 홍콩 기반 IP(주소 미공개)를 주 인프라로, 38.244.50[.]120을 한국 공격을 수행했을 가능성이 높은 ARTEX 인스턴스의 호스트로 봤다. 이 호스트의 18899 포트 공개 디렉터리에는 LLM의 침투 테스트 방식을 정한 중국어 지시문이 든 AI 코딩 에이전트용 지시 파일(마크다운)이 있었고, 홍콩 IP의 다른 공개 디렉터리에서는 세션 기록, ARTEX 설정 파일, 메모리 파일이 나왔다. 세션 기록에는 작전 중 쓴 프록시 IP 9개가 남아 있었다. Recorded Future는 TAG-217이 가정용 인터넷 회선으로 트래픽을 돌렸으며 탐지를 피하려는 목적이었을 가능성이 높다고 봤다.
ARTEX의 주 LLM 백엔드는 DeepSeek v4.1-flash였고, 공격자는 LLM API 중계·재판매 서비스로 보이는 xcai[.]pro를 거쳐 접속했을 가능성이 높다(CrowdStrike). 앤트로픽의 AI 코딩 에이전트 세션도 있었고 추가 세션에는 GLM-5.3(Zhipu AI)과 Grok 4.6을 붙였지만, 세션마다 어떤 모델이 돌았는지는 공개된 문장으로는 다 나뉘지 않는다.
- 기법: VPS 인프라 확보(T1583.003), AI 역량 확보(T1588.007), 프록시(T1090). 셋 다 CrowdStrike 매핑이다.
- 방어자가 볼 흔적: 웹·API 접근 로그의 출발지 IP와 사내에서 공격자 인프라로 나간 통신. 모델 이름은 남지 않고 출발지도 바뀌므로 IP 차단만으로는 끝나지 않는다.
3단계 정찰·API 탐색: 프런트엔드 JS에서 API 경로 추출
PLURA는 ARTEX 공개 소스(v0.3.14)로 웹 정찰 동작을 정리했다. 실제 공격 로그와 대조한 값은 아니다. 후보 UA는 artex-enrich/1.0(웹 자산 정보 확인), Mozilla/5.0 (spa-api-recon)(HTML·자바스크립트 수집), Mozilla/5.0 (spa-api-recon spider)(링크·폼 순회)다. 정적 분석 스크립트는 진입 HTML, 자바스크립트 참조, 번들·청크 파일을 차례로 받아 API 후보 경로를 뽑는다. 별도의 runtime_harvest.js는 Chromium 브라우저를 띄워 브라우저 요청 헤더를 복사하거나 쿠키를 적용하는 다른 경로라서, 세 문자열을 막았다고 ARTEX 전체를 막은 것은 아니라고 PLURA는 적었다. API 후보 경로 예시(/api/, /rest/, /graphql/ 등)도 ARTEX 전용 공격 URL 목록이 아니다.
- 기법: 능동 스캐닝·피해자 정보 수집(T1595·T1592, 작성자 대응)
- 방어자가 볼 흔적: 웹 접근 로그의 UA 필드, 그리고 같은 출발지나 세션이 JS 번들·청크를 몰아 받은 직후 여러 API 경로를 반복 호출하는 흐름.
4단계 초기 침투: 고객용이 아닌 두 채널
CrowdStrike는 업계 보도를 인용해, 한 피해 은행에서는 공격자가 금융 중개인이 쓰는 대출 진행 조회 서비스를 뚫은 것으로 전해졌고(원문 'reportedly') 다른 은행에서는 직원 모바일 업무지원 시스템을 침해했다고 적었다. 금융위원회도 10월 4일 회의에서 대출모집인·위탁업체 등 외부인력과 임직원이 쓰는 시스템을 '최근 침해사고의 원인이 된' 곳으로 짚고, 인증 절차가 누락되거나 우회될 수 있는 경로를 점검하라고 했다. 어느 은행인지, 어떤 취약점이었는지, CVE가 있는지는 공개되지 않았다.
- 기법: 외부 공개 애플리케이션 악용(T1190, 작성자 대응, 추정)
- 방어자가 볼 흔적: 중개인·협력사·직원용 서비스 로그에서 인증 없이 고객정보를 돌려받은 요청, 계정이 맡은 고객 범위를 벗어난 조회(조건은 다음 장 표).
5단계 정보 접근·유출
금융위원회가 10월 14일까지 확인한 유출은 16개사 약 10만건이다. Recorded Future는 공개 보도를 인용해 최소 7개 금융기관, 최소 6만8천 명의 개인정보 노출을 적었고, 기관마다 뚫린 시스템과 데이터가 달라 한 건은 외주 개발자 개인정보 노출, 다른 한 건은 고객 데이터 탈취였다고 설명했다. 두 수치는 시점과 단위(건, 명)가 달라 더하거나 비교하지 않는다. 측면 이동, 계정 탈취 방식, 체류 기간은 어느 1차 자료에도 없다.
- 방어자가 볼 흔적: 애플리케이션 감사 로그, DB 접근제어 로그, 개인정보 접속기록에 남은 계정·세션별 고유 고객 조회 수.
6단계 수익화 시도와 공격자의 실수
CrowdStrike에 따르면 공격자는 AI 코딩 에이전트에게 한국 유출 데이터를 보통 어디서 파는지 묻고 한국 텔레그램 데이터 판매방을 찾아 달라고 했으며, ARTEX 성과를 담은 '보안 연구자 이력서'도 만들게 했다. 실제로 팔았는지는 확인되지 않았다. 이 기록은 공격자가 방치한 공개 디렉터리에서 나왔다. Recorded Future는 이런 운영 보안 실수 덕분에 AI 사용 방식을 짜 맞출 수 있었다며, 경험 많은 공격자라면 잡았을 기본 실수와 큰 이득이 함께 나타나는 AI 기반 공격의 '들쭉날쭉한 경계(jagged edge)'라고 불렀다.
- 방어자가 볼 흔적: 피해 기관 로그에는 없다. 금융위원회는 10월 4일 회의에서 보이스피싱·스미싱 등 2차 피해에 대비해 이상금융거래 탐지와 소비자 안내를 강화하라고 했다. 유출 대상 고객을 이상거래탐지시스템(FDS) 강화 감시 대상에 올린다(작성자 제안).
AI는 정확히 무엇을 했나
출처가 확인한 AI의 몫. CrowdStrike는 38.244.50[.]120의 ARTEX 인스턴스가 한국 공격을 수행했을 가능성이 높다고 평가했을 뿐 확정하지 않았다. AI 코딩 에이전트 세션에는 작전 기록과 텔레그램 기반 NFT 선물 거래소를 노린 별도 취약점 연구가 남았다. Recorded Future는 작업 환경의 AI 도구와 서버 사이의 AI 작업 메모리 파일 복사를 확인했고, 기관마다 표적이 여러 갈래였던 점은 가치 있는 표적이 나올 때까지 약점을 대량으로 시험하는 AI의 이점을 보여 줄 가능성이 높다고도 평가했다. PLURA가 받은 금감원 전파 자료는 침투유형을 'AI Agent를 활용한 자동화 공격 추정'으로 적었다.
운영자가 정한 것. 도구·모델 선택, 지시 파일 배치, 판매처 질문은 운영자 쪽에서 나왔고 공개 디렉터리 방치는 사람의 실수다. 8월 준비 단계의 AI 사용 정도는 Recorded Future 공개본에 없다.
과장된 해석 바로잡기.
- '16개사 모두 AI 해킹'은 근거 없는 표현이다. 금융위원회는 10월 14일에도 AI 해킹 가능성을 확인 중이었고, CrowdStrike도 피해 기관 수를 확정하지 않았다.
- 'AI가 스스로 금융사를 뚫었다'는 근거도 없다. AI가 표적을 고르고 침투를 결정했다는 자료는 공개되지 않았다.
- 새로운 공격 기법이 쓰였다는 근거도 없다. Recorded Future는 TAG-217이 대체로 익숙한 기법을 썼고, 해결되지 않은 취약점과 약한 자격증명은 사람이 찾든 AI 보조 작업이 찾든 진입점이 될 수 있다고 썼다.
왜 뚫렸나: 원인
피해사별 원인은 공개되지 않았다. 공개된 침투 지점의 성격과 전체 점검의 공통 약점만 말할 수 있다.
- 기술 원인(공개 사례): 공개된 두 침투 지점은 고객용 홈페이지가 아니라 중개인용 조회 서비스와 직원용 모바일 시스템이었고, Recorded Future가 소개한 한 건은 외주 개발자 정보였다. 금융위원회도 외부인력·임직원용 시스템을 원인으로 짚었다.
- 기술 원인(전체 점검): 130개사가 보고한 미흡사항은 최신 보안패치 미적용, 제조사 기술지원 종료(EOS) 시스템 관리 미흡, 24시간 관제체계 미구축, 공격표면 관리 미흡(대외시스템 인증·인가 누락, 중요 서비스 MFA 미도입 등)이었다. 대부분 보안패치·관제 관련 1~2개 항목이었고 전금업·온투업에서 비교적 많았으며, 피해사 원인으로 특정되지는 않았다.
- 운영 원인: 신진창 사무처장은 여러 차례 전수 점검을 주문했는데도 기본이 잘 지켜지지 않은 사례가 발견됐다고 지적했다. 금감원·금보원 위협정보는 통합관제시스템(FIRST) 등으로 전파되지만 금융회사가 자체 관제에서 파악한 정보는 공유되지 않고 있었다. 전자금융거래법·전자금융감독규정이 의무화한 취약점 점검·평가(연 1회, 외부 홈페이지는 연 2회)도 더 정교해져야 한다는 지적이 나왔다.
금융위원회는 4대 정책과제로 보안체계 전수점검, 해킹위협 조기 포착·공동 대응(자체 위협정보 공유, AI 기반 취약점 점검 인프라), 상시 보안관리 제도(대형사 점검·평가 연 2회 이상, 중요한 외부접점 필수 점검), 중소형사 지원(공동 보안관제 검토, 블랙박스 점검)을 내놓았다.
우리 조직에서 찾아볼 흔적
PLURA 1보는 9월 하순 이후를 먼저 보고 공격 IP 관측 시각에 따라 범위를 조정하라고 권했다. 그다음 Recorded Future가 밝힌 가장 이른 활동일인 8월 17일까지 넓힌다(작성자 제안). 보관 기간이 짧아 빈 기간은 보고서에 적는다.
| 확인할 곳 | 볼 내용 | 예시 조건 |
|---|---|---|
| WAF, 리버스 프록시, 웹서버·API 게이트웨이 접근 로그, 방화벽, VPN(로드밸런서·IDS는 HTTP 정보가 남을 때) | 금감원 전파 의심 IP(PLURA 2보의 19개와 이후 받은 목록), CrowdStrike 공개 IP | 출발지 IP가 목록과 일치(CDN·프록시 뒤라면 신뢰 프록시 목록과 건너뛸 프록시마다의 헤더 처리 방식을 확인해 둔 웹서버 설정(NGINX set_real_ip_from 등)으로 복원한 주소를 쓴다. X-Forwarded-For 맨 앞 값은 클라이언트가 넣을 수 있어 그대로 믿지 않는다, 일반 점검). 현재 접속과 과거 이력을 보고, 일치하면 시각, Host, 메서드, URI·쿼리, 요청 본문, 인증·세션 정보, 응답 코드·크기와 내용을 뽑는다(PLURA) |
| 같은 로그의 파싱된 UA 필드 | 3단계의 ARTEX 후보 UA 3종(PLURA 1보) | 셋 중 하나와 값이 일치하거나 spa-api-recon을 포함(정규식은 표 아래) |
| 웹·API 게이트웨이 로그(경로, 쿼리, 세션 ID, 응답 크기) | 요청 흐름의 조합 | PLURA 조합 기준: 공격 IP 또는 후보 UA, 다수 URL·JS 자원 접근, 여러 API 반복 요청, 파라미터·조회 대상의 반복 변경, 로그인·세션·권한 맥락과 맞지 않는 데이터 조회 |
| 고객정보 조회 API의 게이트웨이 로그 | 인증 누락 의심 요청 | 인증 주체(사용자·토큰 ID) 필드가 로그에 남는지 먼저 확인하고, 2xx 응답인데 이 필드가 빈 요청을 후보로 뽑아 요청 ID로 애플리케이션의 인증 결과와 고객정보 반환 여부를 본다. 인증 없는 내부정보 접근 경로를 점검하라는 금융위원회 10월 2일 요청을 로그로 옮겼다(작성자 제안) |
| 애플리케이션 감사 로그, DB 접근제어 로그, 개인정보 접속기록 | 계정·세션별 서로 다른 고객 레코드 조회 수 | 중개인·협력사·직원 모바일 계정의 일별 고유 고객 ID 수가 평소 기준선을 크게 넘음(기준값은 각사 업무량으로, 일반 점검) |
| 사내 DNS 질의 로그, 프록시·방화벽 아웃바운드 로그 | 공격자 인프라와의 통신 | xcai[.]pro 질의, 38.244.50[.]120 18899 포트 접속. 나오면 해당 단말의 무단 설치 도구나 감염 여부를 조사(작성자 제안) |
UA 정규식은 PLURA 1보의 (?i)^(?:artex-enrich/1\.0|Mozilla/5\.0 \(spa-api-recon(?: spider)?\))$를 쓰되, 시작·끝 기준이 있으므로 로그 한 줄이 아니라 파싱된 UA 필드에 적용한다.
금감원 전파 의심 IP 19개(금감원 원본 PDF는 비공개라 PLURA 2보가 옮긴 목록): 38.244.50[.]120, 103.248.148[.]84, 129.212.181[.]253, 124.155.252[.]63, 134.185.91[.]25, 203.160.133[.]172, 23.158.220[.]98, 64.20.39[.]190, 209.209.85[.]38, 129.212.181[.]23, 101.53.80[.]20, 74.82.60[.]23, 34.175.107[.]233, 18.183.215[.]124, 104.28.162[.]188, 104.28.164[.]188, 104.28.164[.]196, 104.28.166[.]183, 104.28.155[.]179.
CrowdStrike가 공개한 10개(ARTEX 호스트 1개와 세션 기록의 프록시 9개) 가운데 7개는 위 목록과 겹치고, 나머지 3개는 205.214.59[.]31, 154.201.79[.]246, 23.248.249[.]90이다.
PLURA가 받은 금감원 자료에는 IP별 관측 시각과 ARTEX 사용 여부가 없고, 금감원·금보원은 이후 더 많은 IP를 전파하고 C-TAS에도 공유했다(PLURA). 받은 최신 목록 전체로 검색하되 19개를 모두 'ARTEX 확정 공격 IP'로 보거나 국가 표기를 실제 소재지로 읽지 않으며, 후보 UA가 없다고 ARTEX 활동을 배제하지도 않는다(PLURA). 19개 중 5개는 104.28.로 시작하는 같은 대역이다. Recorded Future는 공유 프록시 서비스 주소처럼 고객에게 영향을 줄 수 있는 차단은 추가 검토를 거치라고 권했으니 차단 전에 IP 소유 기관(ASN)을 확인한다.
ARTEX 설치 흔적(PLURA 1보의 컨테이너 이미지, 기본 포트 8787·8788, 배포본 해시 등)은 사내 서버의 무단 설치 조사용이라 WAF 차단 규칙에 넣지 않는다. 지표별 한계는 ARTEX 한국어판 탐지 규칙에 있고, 승인된 레드팀 장비는 예외로 둔다.
대응 순서
오늘
- 보안장비 담당: 이미 전파된 공격 IP가 WAF·방화벽 차단 정책에 실제로 들어갔는지 정책 화면에서 확인한다(금융위원회 10월 4일 회의 요청).
- 보안관제 담당: 받은 원본 목록과 CrowdStrike·PLURA 원문의 IP·UA로 위 표의 로그를 9월 하순부터, 이어 8월 17일까지 검색한다. 보관 기간이 짧은 WAF·게이트웨이 로그는 먼저 따로 보존한다.
- 보안관제·침해대응 담당: 일치 건을 곧바로 침해로 판정하지 않는다. 사내 승인 모의해킹 트래픽을 걸러 내고 PLURA 1보 순서대로 대상 Host·URI·요청 시각, 같은 세션·시간대 요청, 인증·권한과 응답 내용을 본 뒤 실제 공격 여부와 영향 범위를 판단한다. 핵심은 다른 고객의 레코드가 응답에 실렸는지다.
- 보안장비 담당: 새로 확인된 공격 인프라는 만료일을 붙여 임시 차단하고, 확정된 악성 세션은 세션 저장소에서 무효화한다. IP 대응은 행위 기반 탐지를 대체하지 않으므로(PLURA) 이번 주 4번의 행동 검색을 이어 간다.
- CISO·법무: 정보 노출이 확인되면 유출 범위와 소비자 피해 가능성을 파악하고 추가 유출·금전 피해를 막는 보호조치를 바로 시행한다(금융위원회 10월 4일 회의 요청). 신고·통지 기한은 법무와 확인한다(침해사고 대응 실무).
이번 주
- 인프라·개발 담당: 배포된 웹·모바일 클라이언트(프런트엔드 JS)의 API 후보, API 게이트웨이·로드밸런서 로그의 실제 호출 기록, 배포 정보와 OpenAPI 명세를 알고 있는 URL 목록과 비교하고, 트래픽은 있는데 명세나 소유자가 없는 API부터 담당자를 정한다(데일리시큐 CISO 칼럼). 중개인·대출모집인, 직원 모바일, 협력사·외주 개발자용 시스템을 반드시 넣는다(금융위원회 10월 4일 회의, Recorded Future).
- 서비스 책임자·CISO: 소비자 서비스나 업무에 필수불가결하지 않은 외부 접근은 닫고, 남기는 접점은 접근 권한과 조회 가능한 정보를 필요 최소한으로 줄인다. 외부인력·임직원 시스템에 개인신용정보가 불필요하게 보관·조회되지 않는지도 본다(금융위원회 10월 4일 회의).
- 보안·개발 담당: 고객정보·거래 API부터 허가된 환경에서 테스트 계정 A·B와 각자의 테스트 객체를 만들고, A가 B의 객체를 조회·변경할 수 없는지 응답 데이터와 실제 상태 변경까지 확인한다(데일리시큐 CISO 칼럼). 서버는 요청자에게 그 레코드 권한이 있는지 검증해야 하고(Recorded Future 권고), MFA로는 이런 인가 결함을 막지 못한다(API 보안 점검 가이드).
- 보안관제 담당: 출발지가 바뀌어도 이어지는 행동을 묶는 검색을 만든다. 공격자 인프라 정보에 비정상 로그인, 서로 다른 고객 레코드의 반복 요청, 예상하지 못한 원격 접속, 비정상 데이터 전송을 결합한다(Recorded Future).
- CISO: 체크리스트 미흡 네 갈래(최신 보안패치, EOS 시스템, 24시간 관제, 대외시스템 인증·인가와 MFA)를 자체 점검하고, 결과와 책임자를 CEO·CISO·CIO 보고선에 올린다(금융위원회 10월 14일).
이번 달
- 보안관제·SOAR 담당: FIRST 등으로 전파되는 공격 정보가 SIEM·SOAR에 자동으로 들어가 경보에 붙고 과거 로그 재검색이 돌게 연결한다(Recorded Future 권고). 우리가 찾은 공격 IP·수법·침해 시도도 관계기관과 공유하되(금융위원회 10월 2일), 외부 공유본에서는 고객정보와 인증정보를 가린다(PLURA 1보).
- CISO: 사람 승인 없이 실행할 자동 대응을 미리 승인해 둔다. Recorded Future가 든 예는 확정된 악성 세션 종료와 검증된 공격 인프라의 임시 차단이고, 증거가 불확실하거나 고객에게 영향이 갈 조치는 추가 검토로 남긴다.
- CISO·점검 담당: 내년 점검 계획에 금융위원회 추진 방향(대형사 연 2회 이상, 중요한 외부접점 필수 점검)을 반영하고, 완료 기준을 실제 호출되는 API 중 소유자가 확인된 비율, 명세와 운영 현황의 불일치 건수, 중요 API의 객체 단위 인가 검증 비율로 잡는다(데일리시큐 CISO 칼럼).
- 인프라 담당: 개발·테스트 서버의 웹 설정에서 디렉터리 목록 기능을 끄고, 밖에서 백업·설정 파일(.bak, .zip, .env 등)을 요청해 리다이렉트 도착지와 응답 본문에 실제 파일 내용이 나오지 않는지 확인한다(일반 점검).
자가점검
예/아니오로 답한다. '아니오'인 항목부터 손본다.
1. 전파받은 IP와 ARTEX 후보 UA로 9월 하순 이후, 이어 8월 17일 이후 로그를 검색했는가
로그가 남지 않은 기간도 함께 기록해야 결과를 믿을 수 있다.
2. 검색한 로그에 실제 클라이언트 IP와 UA가 남는가
CDN·프록시 뒤에서 연결 주소만 남기면 지표 대조가 아무것도 못 찾는다.
3. 금융 중개인·직원 모바일·협력사용 시스템이 외부 접점 목록에 있고 담당자가 정해져 있는가
공개된 두 침투 지점이 모두 고객용 홈페이지가 아니었다. 목록에 없는 접점은 점검과 로그 수집에서 함께 빠진다.
4. 고객정보 조회 API에서 A 계정으로 B 계정의 레코드가 열리지 않는 것을 시험했는가
로그인 여부만 보는 서버는 이 시험에서 드러난다.
5. 계정별 고유 고객 조회 수에 경보가 걸리는가
서로 다른 고객 레코드의 반복 요청은 출발지 IP가 바뀌어도 남는 신호다.
6. 필수가 아닌 외부 접근을 닫았는가
금융위원회가 10월 4일 요청한 사항이다. 남긴 접점은 이유와 담당자를 기록한다.
외부 접점 목록부터 만들기
보안 전문 기업 SENTRIX의 SENTRIX ASM은 밖에서 보이는 서버·서브도메인·관리 화면을 찾아 담당자와 조치 순서까지 관리한다. 금융위원회가 첫 과제로 든 외부 접점 목록화·현행화를 시작하거나, 밖에서 보이는 접점이 우리 목록과 맞는지 대조할 때 쓸 수 있다. 밖에서 관측되는 자산을 다루므로 로그인 뒤 권한 결함 검증이나 사내 로그의 지표 검색을 대신하지는 않는다. 외부 노출 자산 진단 문의하기
참고 자료
- 금융위원회, 최근 발생하는 금융권 침해위협에 면밀히 대응해 나가겠습니다(2026-10-02)
- 금융위원회, 全금융권이 비상한 경각심을 갖고 침해위협에 대응해 나가겠습니다(2026-10-06, 10월 4일 회의)
- 금융위원회, 금융권 침해사고 재발방지를 위해 금융보안 관리체계를 전면 강화하겠습니다(2026-10-14)
- CrowdStrike, Unknown Threat Actor Uses AI-Driven ARTEX to Target South Korean Finance(2026-10-07)
- Recorded Future(Insikt Group), TAG-217 Targets South Korean Financial Services with ARTEX(2026-10-16)
- PLURA, 금융권 해킹 공격 IOC 1보: ARTEX AI 관련 공개 지표와 즉시 점검 항목(2026-10-03)
- PLURA, 금융권 해킹 공격 IOC 2보: 공격자 IP 19개와 ARTEX User-Agent 3종(2026-10-07, 업체 정리)
- 데일리시큐 CISO 보안칼럼(필명 청람), 금융권 해킹공격 이후 우리는 제대로 대응하고 있을까?(2026-10-19)