2026년 9월 말부터 10월 초 사이, 신한은행과 KB국민은행에서 잇따라 고객 정보 유출이 확인됐다고 보도됐습니다. 두 사고는 규모도 경로도 다르지만 한 가지가 같습니다 — 공격자가 들어온 곳이 고객에게 공개되지 않은 내부용·협력사용 시스템이었다는 점입니다. 이 글은 보도된 사실만으로 공격 흐름을 단계별로 나누고, 각 단계에서 운영자가 먼저 볼 수 있었던 신호를 정리합니다.
무슨 일이 있었나 — 보도 기준
| 구분 | 신한은행 | KB국민은행 |
|---|---|---|
| 확인 시점 | 2026년 9월 30일 확인 발표 | 2026년 10월 초 확인 보도 |
| 뚫린 곳 | 대출 모집인의 고객정보 조회 서비스 — 본인 확인 절차가 우회됨 | 직원용 모바일 업무 지원 시스템 — 외부 침입 |
| 규모 | 고객 약 2만5천 명의 개인·신용정보 | 고객 정보 100여 건 |
| 은행 설명 | 행장 명의 사과문 게시, 금융당국 현장조사 | 인터넷·모바일뱅킹 등 고객 거래와 무관, 서버와 접근 경로 즉시 차단 |
| 보안업계 지적 | 공격 추정 웹서버의 페이지 제목에서 「AI 자율 침투테스트 콘솔」을 뜻하는 중국어 문구 발견, 크리덴셜 스터핑 정황 | — |
출처: 연합뉴스(2026-10-02) 「신한은행 해킹에 AI 동원됐나…서버서 '중국어 침투도구' 흔적」, 이데일리(2026-10-02) KB국민은행 고객정보 유출 보도. 아래 분석은 이 보도 내용에 한정합니다.
아직 확인되지 않은 것
- AI 자율 침투 도구(오픈소스 「ARTEX AI」로 추정)가 실제 공격에 쓰였는지는 금융당국이나 은행이 공식 확인하지 않았습니다. 정황입니다.
- 본인 확인이 어떤 방식으로 우회됐는지, 직원용 시스템에 어떤 경로로 들어왔는지는 공개되지 않았습니다.
- 두 사고가 같은 공격자의 소행인지도 알려지지 않았습니다.
그래서 이 글은 「이렇게 뚫렸다」고 단정하지 않습니다. 보도된 흔적 — 자동화 도구, 크리덴셜 스터핑, 본인 확인 우회, 내부용 시스템 — 이 일반적으로 어떤 순서로 이어지는지와, 그 순서마다 남는 신호를 다룹니다.
왜 하필 내부용 시스템인가
고객용 인터넷뱅킹은 수년간 모의 해킹·감사·웹방화벽이 집중된 곳입니다. 반면 대출 모집인·대리점·협력사 포털, 직원 모바일 업무 앱의 서버는 「사용자가 내부 사람」이라는 이유로 점검 우선순위가 밀리기 쉽습니다. 그런데 이 시스템들도 대개 인터넷에서 닿습니다. 공격자, 특히 사람 대신 끈기 있게 탐색하는 AI 도구에게는 가장 먼저 찾는 옆문입니다.
공격 4단계와 단계별로 먼저 보이는 신호
| 단계 | 공격자가 하는 일 | 운영자 쪽에 남는 신호 |
|---|---|---|
| ① 정찰 | 공개 인증서 기록·검색으로 서브도메인을 모으고, partner·agent·staging·m-api 같은 내부용 호스트를 고른다 | 공격자와 같은 목록을 운영자도 볼 수 있다 — 로그인 화면이 인터넷에 열린 내부용 호스트 |
| ② 시험 | 경로를 대량으로 두드리고(404 폭주), SQL 인젝션·관리 도구·.env 를 시험한다 | 짧은 시간의 오류 응답 급증, SQL 구문이 실린 요청, 서버가 5xx 로 답한 경로 |
| ③ 침입 | 다른 곳에서 유출된 아이디·비밀번호를 수십~수백 개 출발지로 나눠 대입하거나, 본인 확인 단계를 건너뛴다 | 출발지를 나눈 로그인 시도, 실패를 거듭한 끝의 성공, 429(속도 제한)가 한 번도 없음 |
| ④ 반출 | 고객번호를 바꿔 가며 정보를 받아 간다 — 1씩 늘리는 순차 대입이 흔하다 | 한 출발지가 같은 꼴의 주소에서 서로 다른 고객번호를 대량으로 2xx 로 받아 감 |
핵심은 ①~③의 신호는 ④보다 먼저 나타난다는 것입니다. 마지막 단계에서야 알아채면 이미 정보가 나간 뒤입니다.
운영자가 오늘 할 일
- 옆문 목록 만들기 — 인터넷에서 닿는 내부용·협력사용 호스트를 전부 적고, 고객용과 같은 기준(모의 해킹·강한 인증·조회량 상한)을 적용합니다. 가능하면 VPN·제로 트러스트 접근 뒤로 옮깁니다.
- 본인 확인은 서버가 다시 검증 — 화면에서 「확인 완료」 값을 보내오는 것을 믿지 말고, 서버가 그 세션에서 확인을 마쳤는지 기록으로 확인합니다. 단계 순서도 서버가 강제합니다.
- 조회 대상 권한을 매 요청마다 — 주소의 고객번호만 바꿔서 남의 정보가 보이면 안 됩니다(IDOR).
- 속도 제한은 IP 만으로는 부족 — 계정 기준·전체 실패율 기준을 함께 겁니다. 크리덴셜 스터핑은 출발지를 나눠 옵니다. 크리덴셜 스터핑 대응
- 유출 비밀번호 거절 — 가입·변경 때 이미 유출 목록에 있는 비밀번호를 받지 않습니다.
- 미끼를 심기 — 실제로는 쓰지 않는 가짜 고객번호·로그인 아이디·API 키를 시스템에 넣어 둡니다. 정상 사용자는 모르는 값이라, 닿는 순간 추정이 아니라 확정입니다.
고객이라면
유출 통지를 받았다면 그 서비스뿐 아니라 같은 비밀번호를 쓰던 다른 계정부터 바꾸고, 「보상」·「본인 확인」을 내세운 문자와 원격 제어 앱 설치 요구는 받지 마세요. 순서는 유출 소식을 받았을 때 할 일에 정리했습니다.
울타리 NEO 가 하는 것과 하지 않는 것
| 단계 | 울타리가 먼저 알리는 것 |
|---|---|
| ① 정찰 | 「내 사이트」 외부 노출 지도 — 인증서 기록에서 내부용 꼴 호스트를 찾아 로그인 화면 노출 여부를 표시 |
| ② 시험 | 웹 로그·센서에서 SQL 인젝션 시도(서버 오류로 답한 경로 따로), 비밀 파일·관리 도구 탐침, 공격 도구 이름표, 그리고 한 출발지가 정찰→시험→침입→접근으로 단계를 옮겨 가는 흐름(빌드 90) |
| ③ 침입 | 출발지를 나눈 로그인 대입·실패 폭주·실패 뒤 성공, 유출 비밀번호 거절 코드 조각(회사 도메인 계정 유출 확인은 서버에 조회 키가 설정된 경우) |
| ④ 반출 | 고객번호를 바꿔 가며 조회한 흐름(순차 대입 표시), 미끼 고객번호·아이디·API 키 접촉 — 확정 |
울타리는 차단하지 않고, 웹방화벽·DB 접근제어·본인 확인 로직을 대신하지 않습니다. 공격이 반드시 지나가는 네 길목에서 근거와 함께 먼저 알려, 운영자가 마지막 단계 전에 움직일 시간을 버는 도구입니다. 판정은 운영자의 PC·서버 안에서 이루어지고, 고객번호·IP 원문은 요약에 남기지 않습니다. 이 글의 사고 경위는 보도에 근거하며, 울타리가 해당 은행의 시스템을 점검하거나 사고를 분석한 것은 아닙니다.