금융사 7곳 연쇄 해킹, 정말 AI가 털었을까: ARTEX 흔적과 뚫린 기본기를 원문으로 확인했습니다

핵심 요약

• AI가 혼자 턴 사건이 아닙니다. 금융보안원 관계자는 "AI를 활용해 공격한 것은 맞지만, 사람의 개입 없이 AI가 독자적으로 공격하지는 않았다"고 했습니다. 크라우드스트라이크도 공격자가 중국어 기반 오픈소스 침투 테스트 도구 ARTEX와 여러 LLM을 함께 쓴 정황을 찾았을 뿐, 특정 조직이나 인물로 확정하지 않았습니다.
• 뚫린 곳은 오래된 약점이었습니다. 공격은 고객용 뱅킹 앱이 아니라 대출모집인 조회 서비스와 직원용 업무지원 시스템을 노렸습니다. 보도된 신한은행 사례에서는 다른 곳에서 샌 계정을 대입하는 크리덴셜 스터핑, 고객 번호를 바꿔 남의 정보를 조회하는 인가 결함, 반복 호출을 막지 못한 속도 제한 부재가 겹친 것으로 보입니다.
• 같은 공격을 막은 은행도 있습니다. 우리은행과 NH농협은행은 공격을 받았지만 다중 인증 등 기본 보안으로 유출을 막았다고 보도됐습니다.
• 탐지는 느렸습니다. 의원실이 확보한 보고서에 따르면 신한은행은 첫 공격 IP 유입 뒤 15시간 26분, KB국민은행은 67시간 41분이 지나서야 이상을 알아챘습니다.
• AI가 바꾼 것은 속도와 규모입니다. 보안업계 분석은 AI가 새 공격 기법을 만든 것이 아니라 기존 절차를 자동화해 여러 기관에 동시에 증폭시켰다고 봅니다. 방어 쪽 처방도 새 기술보다 외부 노출 자산 목록, 서버 측 권한 검사, 속도 제한, 이상 탐지라는 기본기입니다.

목차

• 무슨 일이 있었나: 시간순 정리
• 피해 규모는 출처마다 다릅니다
• ARTEX는 무엇이고, 어떻게 이름이 나왔나
• 크라우드스트라이크가 본 공격자의 작업대
• "AI가 해킹했다"를 확인된 것과 추정으로 나누면
• 실제로 열린 창문 세 개
• 해외에서는 이미 본 장면입니다
• AI가 바꾼 것은 기법이 아니라 속도와 규모
• 개발자와 보안 담당자가 지금 점검할 것
• 고객이라면: 2차 피해부터 막기
• 이 글의 한계
• 자주 묻는 질문
• 마치며
• 출처

무슨 일이 있었나: 시간순 정리

2026년 9월 말부터 10월 초까지, 같은 공격자로 보이는 누군가가 여러 금융사의 외부 노출 시스템을 동시에 두드렸고 적어도 7곳에서 개인정보가 빠져나갔습니다. 금융당국은 동일한 공격자 IP가 신한은행, KB국민은행, 하나은행, BNK부산은행, 예가람저축은행, 웰컴저축은행, 현대캐피탈의 침해 사고에서 발견됐다고 밝혔습니다(주간경향, 2026-10-12).

시간 순서로 정리하면 이렇습니다.

• 9월 27일 23시 19분: KB국민은행의 외부에서 접근 가능한 업무지원 시스템에 첫 공격이 들어왔습니다. 공격은 9월 29일 18시께까지 42시간 41분 동안 이어졌습니다(뉴스1, 2026-10-05, 박민규 의원실 확보 침해사고 보고서).
• 9월 28일 18시 4분: 신한은행에 공격자 IP가 처음 들어왔습니다. 신한은행은 15시간 26분 뒤인 29일 오전 9시 30분께 이를 알아챘고, 차단 뒤 29일 오후 8시 30분부터 2차 공격이 이어졌습니다(같은 보고서).
• 10월 초: 신한은행 고객 약 2만 5천 명의 대출 관련 정보 유출이 알려졌고(보안뉴스, 2026-10-02), 이어 KB국민, 하나, BNK부산은행의 유출이 확인됐습니다.
• 10월 2일: 지니언스 시큐리티센터 문종현 센터장이 링크드인에 공격 접근에 사용된 것으로 지목된 웹 서버의 HTML 타이틀에서 "ARTEX"와 "自主渗透测试控制台"(자율 침투 테스트 콘솔)가 함께 적힌 문자열을 확인했다고 공개했습니다(세계일보, 2026-10-02). 같은 날 금융위원회는 긴급 상황 대응회의를 열었습니다(서울신문, 2026-10-04).
• 10월 3일: 금융보안원 관계자가 "신한은행의 로그와 공격자 IP 등을 역추적해 보니 아르텍스를 활용한 흔적들이 나왔다"고 밝혔습니다(헤럴드경제, 2026-10-03).
• 10월 4일: 금융당국이 전 금융권 긴급 점검에 나서 외부 노출 IT 자산과 서비스 점검, 외부 접근 원칙적 차단, 유출 범위 신속 파악을 지시했습니다(뉴스1, 2026-10-04).
• 10월 6일: 금융감독원은 해킹을 시도한 IP 33개(중복을 빼면 28개)를 금융사 약 500곳에 공유하고 12개 항목의 긴급 보안 점검을 지시했습니다. 대통령은 국무회의에서 "AI가 활용된 정황이 드러나 국민 우려와 불안이 매우 큰 상황"이라고 말했습니다(YTN, 2026-10-06).
• 10월 7일: 크라우드스트라이크가 이 캠페인을 분석한 보고서를 공개했습니다(CrowdStrike, 2026-10-07).
• 10월 8일: ARTEX 개발자 Autumn-27이 GitHub에서 악용 사실을 인정하고 새 버전 공개 중단, 소스 비공개 전환, 유지보수 중단을 알렸습니다(EBN, 2026-10-10). 필자가 10월 13일 GitHub API로 원본 저장소를 조회했을 때 응답은 404였습니다.

조코딩의 쇼츠 「은행권을 터는 데 사용된게 AI라고??」(2026-10-08)는 확인된 곳만 일곱 곳이고, "부가 웹서비스의 기본적인 인증 인가 검증이 부족했다 아니면 알려진 취약점이 방치된 것이 핵심"이며, AI 자율 침투 테스트 콘솔이 발견돼 ARTEX가 의심받는다고 짧게 정리했습니다. 큰 줄기는 위 보도들과 맞습니다. 다만 쇼츠만 보면 "AI가 은행을 털었다"로 읽히기 쉬워서, 이 글은 그 문장을 확인된 사실과 추정으로 쪼개 보는 데 초점을 맞췄습니다.

피해 규모는 출처마다 다릅니다

피해 기관 수는 보도에 따라 6곳, 7곳, 9곳으로 갈리고, 유출 건수도 조사가 진행되며 계속 바뀌었습니다. 이 차이는 대부분 무엇을 셌는지에서 나옵니다.

• 6곳: 서울신문은 같은 해커가 은행 최소 6곳(신한, 하나, KB국민, 부산, NH농협, 우리)을 공격했다고 보도했습니다. 여기에는 유출이 없었던 농협과 우리은행이 들어 있습니다(서울신문, 2026-10-04).
• 7곳: 금융당국이 같은 공격자 IP를 확인했다고 밝힌 유출 기관 수입니다. 은행 4곳에 저축은행 2곳과 캐피탈 1곳이 더해진 숫자입니다.
• 9곳 이상: 해외 보도 일부는 공격 시도가 있었던 기관까지 넣은 것으로 보이는 "최소 9곳"이라는 숫자를 씁니다(Forkast, 2026-10-11). 크라우드스트라이크 보고서는 피해 기관 수를 "확인되지 않았다"고 적었습니다.

유출 규모는 주간경향 기준 6만 8천여 건이며, 조사가 진행되면서 늘 수 있다고 했습니다. 보도된 기관별 숫자를 모으면 아래와 같습니다.

신한은행 숫자는 의원실 보고서를 인용한 뉴스1 기준 2만 5,727명이고 다른 보도는 대부분 "약 2만 5천 명"으로 적어, 이 글도 약 2만 5천 명으로 씁니다. 공통점은 계좌 잔액이나 결제망이 아니라 조회 화면에서 볼 수 있는 개인정보와 대출 정보가 나갔다는 점입니다. 금융보안원 관계자는 "시스템을 장악한 것이 아니라 들어와서 조회하는 방식으로 정보를 가져간 것"이라고 설명했습니다(헤럴드경제).

ARTEX는 무엇이고, 어떻게 이름이 나왔나

ARTEX는 LLM을 연결해 정보 수집, 취약점 탐색, 공격 경로 계획, 보안 도구 실행, 취약점 검증을 자동으로 돌리는 중국어 기반 오픈소스 침투 테스트 프레임워크입니다(BleepingComputer, 2026-10-05). 원래 목적은 허가받은 환경에서 보안 점검을 자동화하는 것입니다. GitHub에 공개돼 있었고, 바이두 보안 대회에서 우승한 프로젝트로 소개되기도 했습니다(세계일보).

구조는 요즘 코딩 에이전트와 닮았습니다. 안랩이 확인한 ARTEX v2는 중앙의 Planner가 여러 Worker 에이전트에게 일을 나눠 주고, 탐색 경로, 찾은 자산, 수집한 증거와 트래픽, 도구 실행 기록을 따로 관리합니다. MCP 연동과 재사용 가능한 Skills, 에이전트 설정 기능도 있습니다(안랩, 2026-10-07). 코딩 에이전트에 기능을 덧붙이는 방식과 비슷한데, 그런 확장이 샌드박스 없이 사용자 권한으로 돈다는 위험은 Claude Code Mods 글에서도 다뤘습니다. 보안뉴스는 자산 그래프와 탐색 그래프를 연결한 이중 그래프 구조, Go 백엔드와 Next.js 프런트엔드, PostgreSQL로 이뤄졌다고 설명했습니다(보안뉴스, 2026-10-07). 연결할 수 있는 모델로는 DeepSeek, OpenAI, Anthropic이 거론됩니다(Korea Times, 2026-10-07).

이름이 처음 나온 경로는 단순했습니다. 공격 접근에 사용된 것으로 지목된 웹 서버가 콘솔 페이지를 인터넷에 열어 두고 있었고, 그 페이지 제목에 도구 이름이 그대로 적혀 있었습니다. 이 단서는 "공격자 서버에 ARTEX가 설치돼 있었다"까지만 말해 줍니다. 그래서 초기 보도들은 실제 공격에 쓰였는지는 확인되지 않았다는 단서를 함께 달았습니다.

도구가 얼마나 퍼져 있는지도 따로 봐야 합니다. 오아시스시큐리티는 9월 23일부터 10월 3일까지 ARTEX 관련 인프라를 고유 IP 기준 359개 찾았고, 그중 한국 소재는 4개였습니다(지디넷코리아, 2026-10-04). 안랩은 ARTEX 콘솔이 식별된 시스템을 394개로 셌습니다. 안랩은 연구자나 침투 테스트 수행자의 서버일 수도 있다며 도구가 설치돼 있다는 사실만으로 악성이라 판단하지 말라고 했고, 오아시스시큐리티 김근용 대표도 중요한 것은 "ARTEX 서버가 몇 대 발견됐느냐는 숫자 자체가 아니다"라고 했습니다.

크라우드스트라이크가 본 공격자의 작업대

크라우드스트라이크 보고서의 핵심은 공격자가 자기 작업 기록을 인터넷에 열어 둔 채 일했다는 점입니다. 공격자가 통제하는 서버의 열린 디렉터리에서 Claude Code 세션 기록, ARTEX 설정 파일, Claude의 메모리 파일이 나왔고, ARTEX가 설치된 서버에는 LLM이 침투 테스트를 어떻게 수행할지 적은 중국어 프롬프트 문서가 있었습니다(CrowdStrike, 2026-10-07).

보고서에서 확인한 내용은 다음과 같습니다.

• 두 서버 구조: 홍콩 IP의 주 서버와 ARTEX를 띄운 보조 서버로 나뉘어 있었고, 활동 중에 프록시 IP 9개가 쓰였습니다.
• 여러 모델의 조합: ARTEX의 주 LLM은 DeepSeek였고, API 프록시나 재판매 업체를 거쳐 쓴 것으로 보입니다. 다른 세션에서는 GLM-5.3과 Grok 4.6을 썼습니다. 여기에 Claude Code가 작업 도구로 함께 쓰였습니다. 세션 기록과 메모리 파일이 남는 Claude Code의 작동 방식은 Claude Code 팁 11가지에서 정리했습니다.
• 노린 시스템: 보고서는 업계 보도를 인용해 대출 중개인이 쓰는 대출 조회 서비스와 직원용 모바일 업무지원 시스템을 침해 사례로 들었습니다.
• 돈이 목적인 흔적: 공격자는 Claude에게 훔친 한국 개인정보를 어디서 파는지, 이를 거래하는 텔레그램 그룹을 어떻게 찾는지 물었습니다.
• 귀속은 중간 신뢰도: 도구와 중국어 프롬프트를 근거로 "중국어 사용자이며 금전 동기일 가능성"을 중간 신뢰도로 평가했습니다. 세션에서 개인 정보가 담긴 기록도 나왔지만, 공격자와 확정적으로 연결하기는 어렵다고 적었습니다. 특정 국가나 조직의 소행으로 보지도 않았습니다.

한국경제는 이 보고서를 인용해 공격자가 Claude Code에 "보안 연구자 이력서"를 써 달라며 개인 정보를 입력한 기록이 있었다고 전했습니다(한국경제, 2026-10-08). 크라우드스트라이크는 이 정보를 공격자와 확정적으로 연결하지는 않았습니다. AI 에이전트가 남긴 대화와 메모리가 거꾸로 수사 단서가 된 셈입니다.

보고서를 읽으며 눈여겨볼 점이 하나 더 있습니다. 크라우드스트라이크는 이 작업이 사람 없이 돌아갔는지, 사람이 지휘했는지를 직접 단정하지 않았습니다. 보고서를 정리한 Forkast는 사람 운영자가 여러 LLM을 지휘하고 AI를 정찰과 취약점 탐색의 "force multiplier"(힘을 몇 배로 키우는 도구)로 쓴 "human-led" 공격으로 읽었습니다(Forkast, 2026-10-11). 국내 금융보안원의 설명도 같은 방향입니다.

"AI가 해킹했다"를 확인된 것과 추정으로 나누면

지금까지 나온 자료로 말할 수 있는 것은 "사람 공격자가 ARTEX와 여러 LLM을 도구로 썼다"까지이고, "AI가 스스로 은행을 털었다"는 어느 공식 자료도 말하지 않습니다. 주장별로 근거를 정리하면 아래와 같습니다.

법학박사 이주호 씨는 블로그에서 도구가 서버에 있었다는 사실, 실제 공격에 쓰였다는 판단, 그 공격으로 정보가 유출됐다는 결론에는 각각 다른 증거가 필요하다고 짚었습니다(디지털 세상보기, 2026-10-09). 위 표가 칸을 나눈 기준도 이것입니다.

정리하면 AI가 맡은 역할은 "누가 해도 할 수 있었던 일을 훨씬 빨리, 여러 곳에 동시에" 하게 만든 쪽입니다. 고려대 임종인 교수는 "사람이 이 속도로 공격을 수행하기는 어려울 것"이라며 AI가 쓰였을 가능성이 "높다"고 봤고(영문 인터뷰 번역), 동시에 도구가 중국어라는 이유만으로 중국 소행으로 단정하면 안 된다고 했습니다(Korea Times).

실제로 열린 창문 세 개

공격자는 정문인 고객용 뱅킹 앱이 아니라, 보안 점검 목록에서 밀려 있던 옆 창문으로 들어왔습니다. 동국대 황석진 교수는 이를 정문이 아니라 "창문으로" 들어온 공격이라고 표현했고(Korea Times, 영문 인터뷰 번역), 이억원 금융위원장은 은행들의 대응이 "아주 기본적인 부분도 굉장히 미흡했다"고 질타했습니다(주간경향). 보도된 내용을 모으면 창문은 세 개였습니다.

창문 1. 외부에 열린 보조 시스템

뚫린 곳은 대출모집인이 고객의 대출 진행 여부를 조회하는 모바일 서비스와 직원용 영업·업무지원 시스템이었고, BNK부산은행에서는 외주 개발 직원의 정보가 나갔습니다. 서울신문은 이 시스템들이 금융감독원과 과학기술정보통신부의 취약점 점검 대상에서 빠져 있어 금융사가 자체 점검해 왔다고 보도했습니다(서울신문). 필자는 이런 곳을 보안 조직의 관리 목록에서 빠지거나 점검 순위에서 밀린 시스템, 이른바 섀도 IT로 봅니다. 주간경향은 작년 대형 카드사 유출 뒤 금융권이 IT 시스템 1,600여 개를 점검했는데도 1년이 안 돼 비슷한 사고가 났다고 지적했습니다(주간경향).

창문 2. 계정 대입과 인가 결함

보안뉴스가 정리한 신한은행 사례의 흐름은 두 단계입니다(보안뉴스, 2026-10-02).

1. 크리덴셜 스터핑: 다른 곳에서 유출된 계정 정보를 대입해 본인 인증을 통과했습니다. 로그인 시도 횟수 제한이나 계정 잠금은 없었던 것으로 보입니다.
2. 인가 결함: 들어간 뒤에는 요청에 담긴 고객 번호를 바꿔 가며 조회 API를 반복 호출했습니다. 로그인한 계정이 그 고객의 정보를 볼 권한이 있는지 서버가 확인하지 않았다는 뜻입니다.

뉴스1이 인용한 의원실 보고서도 "고객번호 등 입력값을 무작위로 대입해 서비스 조회를 반복"하고 휴대전화 인증 우회를 시도했다고 적었습니다(뉴스1). 두 번째 단계는 OWASP API Security Top 10의 첫 번째 항목인 BOLA(Broken Object Level Authorization)와 같은 모양입니다. OWASP는 이를 "요청에 담긴 객체 ID를 조작해" 남의 데이터에 접근하는 취약점으로 설명합니다(OWASP API1:2023). 보안뉴스가 인용한 한 금융 보안 전문가는 이번 사고를 "기본 중의 기본인 API 요청 변조 및 권한 검증 미흡으로 발생한 명백한 애플리케이션 보안 실패"라고 했습니다.

같은 공격을 받고도 막은 곳이 있다는 점이 이 해석을 뒷받침합니다. 주간경향에 따르면 우리은행과 NH농협은행은 다중 인증 등 기본 보안을 갖춰 방어에 성공했고, 피해 은행들은 본인 확인 없이 대출 신청 내역을 조회할 수 있거나 직원용 모바일 서비스에 타인이 접속할 수 있는 허점이 있었습니다. 서울여대 김명주 교수는 "은행서 지금 뚫리는 부분은 AI가 없었던 과거에도 계속 뚫렸던 부분"이라고 했습니다.

창문 3. 늦은 탐지

세 번째 창문은 시간입니다. 공격자가 IP를 바꿔 가며 반복 조회를 수십 시간 이어 갔는데도 알아채는 데 오래 걸렸습니다.

공격자는 IP가 막히면 다른 IP로 갈아탔습니다. 신한은행 공격에만 8개국 IP가 쓰였고(뉴스1), 금융보안원 관계자는 "IP 차단은 응급조치 외에는 별 의미가 없다"고 했습니다. 그래도 공격을 묶어 낸 단서는 있었습니다. IP가 바뀌어도 공격 수법과 노리는 취약점이 같았고, 은행마다 2~3개의 IP가 겹쳤으며, ARTEX에서 발신되는 특정 데이터가 공통으로 나왔다는 것입니다(헤럴드경제). IP 목록보다 행동 패턴으로 탐지해야 한다는 뜻입니다.

해외에서는 이미 본 장면입니다

AI 에이전트가 공격 작업의 상당 부분을 맡은 사례는 이번이 처음이 아닙니다. 이번 사건에서 국내 금융권이 처음 겪은 일은, 해외 보안 업계가 1년 전부터 경고해 온 흐름이 실제 피해로 이어진 장면에 가깝습니다.

Anthropic의 GTG-1002 보고(2025년 11월). Anthropic은 중국 국가 지원으로 추정되는 그룹이 Claude Code를 써서 대형 IT 기업, 금융기관, 화학 기업, 정부 기관 등 약 30곳을 노렸고 소수에서 침투에 성공했다고 공개했습니다. 공격자는 캠페인의 80~90%를 AI에게 맡겼고, 사람은 캠페인마다 4~6번의 결정 지점에서만 개입했습니다. 작업을 무해해 보이는 작은 단위로 쪼개고 정상 보안 회사 직원인 것처럼 속여 안전장치를 피했습니다(Anthropic, 2025-11-13).

같은 보고서에는 이번 사건을 읽을 때 쓸모 있는 단서도 있습니다. Claude가 가끔 자격 증명을 지어내거나, 실제로는 공개된 정보를 비밀을 빼냈다고 보고하는 환각을 보였다는 것입니다. AI 공격 도구는 빠르지만 정확하지는 않아서, 공격자도 결과를 사람이 확인해야 합니다. 이번 공격자가 작업 기록을 열린 디렉터리에 둔 것은 도구를 다루는 사람의 운영도 허술했음을 보여 줍니다.

HexStrike AI(2025년 9월). Check Point는 Claude, GPT, Copilot 같은 모델이 150개 이상의 보안 도구를 부리게 해 주는 오픈소스 프레임워크 HexStrike AI를 범죄자들이 Citrix NetScaler 취약점 공략에 쓰려 한다고 경고했습니다. 취약점 공개 몇 시간 만에 지하 포럼에서 논의가 시작됐고, 공격자들은 공략 시간이 "며칠에서 10분 미만으로" 줄었다고 주장했습니다. Check Point는 이 수치를 공격자의 주장으로 소개했습니다(Check Point, 2025-09-02).

이번 공격자의 작업 방식도 이 게시글과 닮았습니다. 금융보안원의 설명과 Forkast의 해석을 따르면 에이전트가 정찰과 취약점 탐색을 맡았고, 사람이 여러 LLM을 지휘했습니다. 크라우드스트라이크 보고서에 따르면 훔친 정보의 판매처도 AI에게 물었습니다. 차이가 있다면 이번에는 대상이 한국 금융사였고, 뚫린 지점이 제로데이가 아니라 인증과 인가였다는 것입니다.

AI가 바꾼 것은 기법이 아니라 속도와 규모

보안업계의 분석은 대체로 같은 결론입니다. AI가 공격자에게 준 것은 새 무기가 아니라 손과 시간입니다. SK쉴더스는 이번 사고를 "기존에 존재하던 공격 절차를 자동화하고 고도화해 대규모로 증폭시킨 사례에 가깝다"고 평가했습니다(주간경향). 오아시스시큐리티 김근용 대표도 공격자의 가장 큰 이점은 새로운 기술보다 속도와 규모가 될 가능성이 높다고 했습니다(지디넷코리아).

이 변화가 방어 쪽에 뜻하는 바는 분명합니다. 사람이 한 금융사의 조회 화면에 값을 하나씩 넣어 보던 시절에는 공격자가 여러 기관을 동시에 훑기 어려웠습니다. 에이전트가 이 반복을 맡으면 한 사람이 여러 금융사의 보조 시스템을 동시에 두드리고, 막히면 IP를 바꿔 다시 시도할 수 있습니다. 이번 사건에서 증권, 카드, 보험사에도 공격 시도가 있었고(서울신문) 일부 증권사에서 사전 스캐닝 정황이 나온 것(YTN)도 같은 맥락입니다.

도구 자체는 이미 널리 퍼져 있습니다. 오아시스시큐리티가 찾은 ARTEX 인프라 359개의 위치는 아래와 같습니다.

개발자가 소스를 닫았지만, 이미 내려받은 사본은 회수할 수 없습니다(EBN). 방어자 학습용이라며 GitHub에 한국어판 포크도 공개됐습니다(보안뉴스). 주간경향은 공개된 AI 모의해킹 도구가 80여 개라고 전했습니다. 금융보안원 관계자의 말대로 "아르텍스 같은 오픈소스 AI 도구는 굉장히 많다"는 것이 현실입니다. 크리밋 김동현 대표의 말처럼 "중요한 건 어떤 도구를 악용했느냐가 아니라 사태의 본질"입니다(보안뉴스). 도구 하나를 막는 것으로는 이 흐름을 멈출 수 없고, 방어는 결국 "어떤 도구로 와도 막히는 시스템"을 만드는 쪽이어야 합니다.

개발자와 보안 담당자가 지금 점검할 것

당국이 내린 지시와 이번에 열린 창문 세 개를 겹쳐 보면, 점검할 순서가 나옵니다. 금융감독원은 외부 노출 IT 자산의 취약점, 대외 시스템의 인증, 인가, 검증 기능, 공유된 공격 IP 차단 여부, 실시간 보안관제 운영 여부 등 12개 항목을 점검하게 했습니다(YTN). 금융사가 아니어도 고객 정보를 다루는 서비스라면 같은 순서로 볼 만합니다.

1. 외부 노출 자산 목록부터 다시 만듭니다. 고객용 앱만이 아니라 대출모집인, 협력사, 직원용 모바일 페이지, 관리자 도구, 오래된 이벤트 페이지까지 인터넷에서 닿는 모든 주소를 적습니다. 이번에 뚫린 곳도 당국 점검 대상에서 빠져 있던 보조 시스템이었습니다. 외부에서 쓸 필요가 없는 시스템은 금융당국 지시처럼 외부 접근을 원칙적으로 막습니다.
2. 로그인에는 속도 제한과 다중 인증을 겁니다. 크리덴셜 스터핑은 남의 사이트에서 샌 비밀번호로 들어옵니다. 계정별, IP별 시도 횟수 제한과 잠금, 직원과 협력사 계정의 다중 인증이 있었다면 첫 단계에서 멈췄을 가능성이 큽니다. 우리은행과 농협은행도 다중 인증 등으로 막았다고 보도됐습니다.
3. 객체마다 서버에서 권한을 검사합니다. 요청에 고객 번호나 주문 번호가 들어오면, 로그인한 사용자가 그 객체를 볼 수 있는지 서버가 매번 확인해야 합니다. 화면에서 버튼을 숨기는 것은 권한 검사가 아닙니다. OWASP는 클라이언트 입력으로 레코드에 접근하는 모든 함수에서 이 검사를 하고, 예측하기 어려운 ID를 쓰고, 권한 테스트가 실패하면 배포하지 말라고 권합니다(OWASP API1:2023).
4. 조회 API에도 속도 제한을 둡니다. 로그인한 계정 하나가 짧은 시간에 서로 다른 고객 수백 명을 조회하는 것은 대출모집인의 정상 업무가 아닙니다. 계정당 조회 건수와 서로 다른 대상 수에 상한을 두면, 인가 검사가 하나 빠져도 피해 규모가 줄어듭니다.
5. IP가 아니라 행동으로 탐지합니다. 이번 공격자는 IP를 바꿔 가며 들어왔지만 수법과 노리는 경로는 같았습니다. 인증 실패율, 계정당 조회 대상 수, 순차적이거나 무작위인 ID 접근 같은 행동 지표에 알림을 걸어야 15시간, 67시간이라는 공백이 줄어듭니다.
6. 사고 뒤의 점검을 상시 점검으로 바꿉니다. 1,600여 개 시스템을 한 번 점검하고도 1년 안에 다시 뚫렸다는 사실은 일회성 점검의 한계를 보여 줍니다. 방어자도 같은 종류의 AI 침투 도구를 허가된 범위에서 자기 시스템에 돌려, 공격자보다 먼저 창문을 찾는 편이 낫습니다. 고려대 임종인 교수도 방어자가 AI로 약점을 먼저 찾아야 한다고 했습니다(Korea Times 영문 인터뷰).

3번과 4번을 코드로 옮기면 아래 정도입니다. Express 예시이고, 핵심은 클라이언트가 보낸 고객 번호를 믿지 않고 로그인한 사용자와의 관계를 서버가 다시 확인하는 줄입니다.

// 대출모집인이 자기 고객의 대출 진행 상태만 조회하도록 서버에서 확인한다
app.get("/api/loans/:customerId/status", requireLogin, rateLimitPerUser, async (req, res) => {
  const agentId = req.user.id;
  const customerId = req.params.customerId;

  // 객체 수준 인가: 이 모집인이 접수한 고객인지 DB에서 확인
  const owned = await db.loanApplications.exists({ agentId, customerId });
  if (!owned) {
    audit.warn("bola_denied", { agentId, customerId, ip: req.ip });
    return res.status(404).end(); // 존재 여부도 알려 주지 않는다
  }

  const status = await db.loanApplications.statusOf({ agentId, customerId }); // 조회도 같은 범위로 묶는다
  res.json({ status }); // 소득, 대출 한도 같은 필드는 화면에 필요할 때만 내보낸다
});

rateLimitPerUser는 계정당 분당 조회 수와 하루에 조회한 서로 다른 고객 수를 함께 세는 미들웨어로 두고, bola_denied 로그가 한 계정에서 몰리면 관제 알림이 가게 연결합니다. 이 세 가지(인가 확인, 계정당 속도 제한, 거부 로그 알림)만 있었어도 이번 공격의 두 번째 단계는 몇 건 만에 멈췄을 가능성이 큽니다.

고객이라면: 2차 피해부터 막기

이번에 나간 정보는 비밀번호나 계좌가 아니라, 일부 주민등록번호를 포함해 사기 전화를 그럴듯하게 만드는 정보입니다. 이름, 연락처, 연소득, 대출 한도를 아는 사람이 "고객님 조건이면 더 낮은 금리로 대환이 됩니다"라고 전화하면 속기 쉽습니다. 보안뉴스도 보이스피싱과 대출 상담을 가장한 스피어 피싱 같은 2차 금융 사기를 우려했습니다(보안뉴스).

• 유출 안내나 보상 문자가 와도 문자 속 링크와 번호를 쓰지 말고, 거래 금융사의 공식 앱이나 대표번호로 직접 확인합니다.
• 여러 사이트에 같은 비밀번호를 쓰고 있다면 바꾸고, 2단계 인증을 켭니다. 보도된 신한은행 사례의 첫 단계도 다른 곳에서 샌 계정 정보를 대입하는 방식이었습니다.
• 대출 상담을 먼저 걸어 오는 전화, 원격제어 앱 설치를 요구하는 연락은 끊고 금융사에 직접 확인합니다.

이 글의 한계

• 금융당국과 경찰의 공식 조사 결론은 아직 나오지 않았습니다. ARTEX가 각 금융사 침해에서 정확히 어떤 역할을 했는지, 공격자가 한 명인지는 확정되지 않았고, 조사 결과에 따라 이 글의 해석이 바뀔 수 있습니다.
• 공격 경로는 보안뉴스, 뉴스1, 주간경향 등 보도와 의원실이 확보한 보고서를 인용한 기사로 재구성했습니다. 필자가 금융사 로그나 공격 도구를 직접 분석하지는 않았습니다.
• 크라우드스트라이크 보고서는 원문을 읽었지만, 보고서가 다룬 인적 사항과 침해지표는 이 글에 옮기지 않았습니다.
• 유출 인원은 보도 시점마다 달라, 2026년 10월 13일까지 확인한 숫자를 썼습니다.

자주 묻는 질문

그래서 이번 해킹은 AI가 한 건가요, 사람이 한 건가요?

사람이 AI 도구를 써서 한 것으로 보는 것이 지금까지 나온 자료와 맞습니다. 금융보안원 관계자는 "사람의 개입 없이 AI가 독자적으로 공격하지는 않았다"고 했고, 크라우드스트라이크는 공격자가 ARTEX와 DeepSeek, GLM, Grok, Claude Code를 함께 쓴 기록을 찾았습니다. AI는 반복 조회와 탐색을 빠르게 돌리는 역할을 하고, 사람이 결정 지점을 쥔 것으로 보입니다. 공격자는 훔친 정보의 판매처를 찾을 때도 Claude에게 물었습니다.

ARTEX는 해킹 도구인가요?

허가받은 환경에서 보안 점검을 자동화하려고 만든 오픈소스 침투 테스트 프레임워크입니다. 같은 기능이 허가 없이 쓰이면 공격 도구가 됩니다. 안랩은 ARTEX가 설치돼 있다는 사실만으로 그 서버를 악성으로 판단하지 말라고 했습니다. 개발자는 10월 8일 소스를 닫았지만 이미 퍼진 사본과 비슷한 도구가 많아, 도구 하나를 막는 것보다 시스템의 기본 방어를 갖추는 쪽이 현실적입니다.

내 계좌의 돈이 빠져나갈 수도 있나요?

보도된 범위에서는 고객용 인터넷뱅킹이 뚫린 사건이 아니며, 핵심 결제망과 예금계좌도 뚫리지 않았고 고객 자금이 빠져나간 사례도 보고되지 않았습니다(한국경제). 다만 나간 정보가 피싱과 대출 사기에 쓰일 수 있으니, 금융사를 사칭한 문자와 전화는 공식 경로로 다시 확인하세요.

중국 해커의 소행인가요?

확정된 것은 없습니다. 크라우드스트라이크는 도구와 중국어 프롬프트를 근거로 "중국어 사용자일 가능성"을 중간 신뢰도로 평가했을 뿐, 중국 정부나 특정 조직의 소행으로 보지 않았습니다. 공격 IP는 미국, 일본, 독일 등 여러 나라에 흩어져 있었고, 금융감독원도 IP만으로 국가를 특정할 수 없다고 했습니다.

우리 회사 서비스는 무엇부터 봐야 하나요?

인터넷에서 닿는 시스템 목록을 먼저 만들고, 그중 개인정보를 조회하는 API가 객체마다 서버에서 권한을 확인하는지 봅니다. 그다음 로그인과 조회에 계정별 속도 제한이 있는지, 한 계정이 짧은 시간에 많은 대상을 조회하면 알림이 오는지 확인합니다. 보도된 신한은행 사례는 권한 확인과 속도 제한이, KB국민은행 사례는 빠른 탐지가 빠져 있었습니다.

마치며

"AI가 은행을 털었다"는 문장은 절반만 맞습니다. 정확히 쓰면 사람 공격자가 오픈소스 AI 침투 도구와 여러 LLM으로 반복 작업을 자동화해, 점검 목록에서 밀려 있던 보조 시스템의 오래된 빈틈을 여러 금융사에서 동시에 찾아냈다는 이야기입니다.

• AI가 바꾼 것은 기법이 아니라 속도와 규모입니다. 한 사람이 여러 기관을 동시에 두드릴 수 있게 됐습니다.
• 보도로 드러난 빈틈은 크리덴셜 스터핑, 객체 수준 인가 결함, 속도 제한과 탐지의 부재였습니다. 다중 인증을 갖춘 은행은 같은 공격을 막았다고 보도됐습니다.
• 방어도 같은 기본기에서 시작합니다. 외부 노출 자산 목록, 객체마다 서버에서 하는 권한 검사, 계정당 속도 제한, IP가 아닌 행동 기반 탐지입니다.

이번 사고와 관련한 국정감사 증인 출석은 10월 19일로 잡혀 있습니다(주간경향). 금융당국의 공식 조사 결과나 국정감사에서 새 사실이 나오면 이 글을 갱신하겠습니다.

출처

1. 주간경향, 2026-10-12: weekly.khan.co.kr/article/202610120600021
2. 뉴스1, 박민규 의원실 확보 침해사고 보고서, 2026-10-05: v.daum.net/v/4iLFNRZvHq
3. 보안뉴스, 2026-10-02: boannews.com/news/articleView.html?idxno=146174
4. 세계일보, 2026-10-02: segye.com/newsView/20261002506727
5. 서울신문, 2026-10-04: seoul.co.kr/news/economy/2026/10/04/20261004500025
6. 헤럴드경제, 2026-10-03: v.daum.net/v/uJkyV2OctK
7. 뉴스1, 2026-10-04: news1.kr/finance/general-finance/6310143
8. YTN, 2026-10-06: ytn.co.kr/_ln/0102_202610061547542191
9. CrowdStrike, 2026-10-07: crowdstrike.com/en-us/blog/unknown-threat-actor-uses-artex-to-target-so…
10. EBN, 2026-10-10: ebn.co.kr/news/articleView.html?idxno=1727302
11. 은행권을 터는 데 사용된게 AI라고??: youtube.com/shorts/dPV6YZPry-4
12. Forkast, 2026-10-11: forkast.news/south-korean-banks-hit-by-an-autonomous-ai-pentesting-agen…
13. Korea Times, 2026-10-07: koreatimes.co.kr/business/banking-finance/20261007/explainer-how-ai-eme…
14. BleepingComputer, 2026-10-05: bleepingcomputer.com/news/security/south-korea-probes-bank-breaches-ami…
15. 안랩, ARTEX의 진화: 안랩이 추적한 AI 기반 침투 테스트 인프라, 2026-10-07: ahnlab.com/ko/contents/content-center/36300
16. 보안뉴스, 2026-10-07: boannews.com/news/articleView.html?idxno=146220
17. 지디넷코리아, 오아시스시큐리티 AGATHA 분석, 2026-10-04: zdnet.co.kr/view/?no=20261004170058
18. 한국경제, 2026-10-08: hankyung.com/article/2026100897787
19. 디지털 세상보기, 2026-10-09: blog.naver.com/khcl99/224436152182
20. OWASP API1:2023: api-security.owasp.org/editions/2023/en/0xa1-broken-object-level-author…
21. Anthropic, Disrupting the first reported AI-orchestrated cyber espionage campaign, 2025-11-13: anthropic.com/news/disrupting-AI-espionage
22. Check Point, Hexstrike-AI: When LLMs Meet Zero-Day Exploitation, 2025-09-02: blog.checkpoint.com/executive-insights/hexstrike-ai-when-llms-meet-zero…