분석 보고서 2차 · Aside 브라우저 조사 + 원문 교차검증 · 2026년 10월 6일 업데이트
앞선 보고서(「은행권 AI 해킹 분석」)를 바탕으로, AI 브라우저 Aside로 국내 기사를 다시 조사하고 원문을 직접 대조해 회사별 사고 원인을 구체적으로 정리했습니다. 이어서 국제 보안 기준(NIST, OWASP)과 금융보안원 자료를 근거로 예방 방법을 정리했습니다. 10월 6일 개편판에서는 해킹 원인, AI 확인 범위, 원인별 추천 솔루션을 맨 앞으로 옮겼습니다. 글로벌 API 보안 솔루션은 Aside로 공식 문서를 조사한 뒤 다시 교차검증해 비교했습니다. 수사와 검사가 진행 중이라 내용은 바뀔 수 있습니다.
당국 분석(①~③), 보도 사실(④~⑥), 10월 4~6일 새로 확인된 공격 방식(⑦~⑧)을 묶었습니다. 원인마다 공격자가 실제로 무엇을 했는지(해킹 수법)를 함께 적었습니다.
| 원인 (뚫린 빈틈) | 해킹 수법 (공격자가 한 일) | 드러난 곳 | 근거 |
|---|---|---|---|
| ① 조회 서비스의 본인 인증 우회 | 무작위 입력값을 넣어 본인확인 절차를 건너뛰고, 휴대폰 인증만 있는 조회 화면에 들어감 | 신한(M신한 대출모집인용 조회), 현대캐피탈(모집인 조회 페이지) | 금융당국 분석 "정보조회 서비스 본인 인증 우회"(디지털타임스). "무작위로 입력값을 넣는 우회 접근"(MBC). "휴대폰 인증만으로 현황을 조회할 수 있어 이같은 방식이 용이"(머니투데이) |
| ② 직원·외부 협력자 시스템의 접근통제 미흡 | 직원·대출모집인·외주 인력이 업무 편의로 쓰는, 인터넷에 열린 시스템을 골라 침입 | 국민(직원용 모바일 업무지원), 하나(영업지원시스템 ODS), 부산(외주직원 정보 페이지) | 금융당국 분석 "직원 시스템 접근통제 미흡"(디지털타임스). 금융위 "대부분 대출모집인, 임직원 등이 업무상 편의를 위해 사용하는 외부 웹페이지, 서버 등 상대적으로 관리가 집중되지 않은 영역에서 공격"(서울경제) |
| ③ 웹페이지·외부 솔루션의 보안 취약점 | 세션 검증이 약한 웹페이지로 정보를 빼내고, 외부 납품 프로그램의 원격 취약점을 침입 경로로 씀(추정) | 부산(세션 검증 미흡), 예가람(외부 솔루션 원격 취약점 추정) | 금융당국 분석 "홈페이지 보안 취약점 악용"(디지털타임스). "세션 검증이 충분하지 않았던 일부 웹페이지"(머니투데이) |
| ④ 객체 수준 권한 확인 누락 해석 | 한 서비스에서 얻은 고객번호를 다른 서비스에 넣어 남의 정보를 조회 | 신한(대출모집인용 조회 → 개인고객용 서비스) | "여기서 확보한 고객번호로 개인고객용 서비스까지 접근"(뉴스핌). 국제 웹 보안 단체 OWASP의 API 보안 위험 1위 "BOLA"와 같은 유형이라는 것은 이 보고서의 해석 |
| ⑤ 반복 대입·대량 조회를 막지 못함 | 일회용 비밀번호를 임의로 만들어 반복 대입하고, 6개 서비스를 집중 조회해 대량으로 정보를 빼냄. 다른 곳에서 얻은 아이디·비밀번호를 대입하는 "크리덴셜 스터핑"으로 추정한 보도도 있음 | 국민(일회용 비밀번호 대입), 신한(6개 서비스 집중 조회) | YTN, MBC, 머니투데이·헤럴드경제(크리덴셜 스터핑 추정). 황석진 동국대 교수 "로그인시도와 정보 조회를 탐지하는데 미흡했다"(머니투데이) |
| ⑥ 탐지와 차단이 늦음 | 밤사이 공격을 이어 가며 은행이 알아채기 전에 정보를 빼냄 | 신한(인지까지 약 15시간 반, 차단까지 30시간), 국민(공격 종료 후 약 하루 뒤 인지) | MBC |
| ⑦ IP만으로는 막을 수 없는 공격 기반 10/6 추가 | 여러 나라를 거친 IP를 쓰고 "동일한 공격자 IP 주소를 수시로 바꿔가며 방화벽을 우회". 같은 IP로 몇 달 전부터 다른 금융사를 탐색함 | 7개사 전반. 신한 공격에 쓰인 미국 IP 2개가 올해 1월·7~8월 토스뱅크에 14차례 접근(차단됨) | 머니투데이(10.04), MBC, 디지털타임스, 마이데일리(10.06) |
| ⑧ AI 도구로 빨라진 동시다발 공격 10/6 추가 | AI 자율 침투테스트 도구 ARTEX로 취약점 탐색과 공격을 자동화해 여러 금융사를 한꺼번에 노린 것으로 추정 | 은행 공격 IP에서 흔적 확인 | 금융보안원 역추적(헤럴드경제·서울신문). 당국 "AI 도구를 활용해 공격 과정을 자동화하고 여러 금융회사를 대상으로 대량 공격을 시도했을 가능성에 무게"(디지털타임스) |
| (배경) 알려진 취약점의 장기 방치 | 이번 공격과 직접 연결이 확인된 것은 아니지만, 고치지 않은 빈틈이 공격 표적이 될 수 있는 환경 | 은행권 전반 | 국내 20개 은행이 2022년~2026년 8월 모의해킹 481회에서 유효 취약점 4777개 발견, 일부 장기 방치. 금감원 "시스템 중단이나 전면 교체가 필요해 즉각적인 조치가 어려운 상황"(파이낸셜뉴스) |
공격자는 관리가 덜 된 옆문(②③)을 찾아 약한 인증을 건너뛰고(①), 번호만 바꿔 남의 정보를 대량으로 조회(④⑤)했습니다. IP를 바꿔 가며(⑦) 공격하는 동안 은행은 늦게 알아챘고(⑥), AI 도구(⑧)는 이 과정을 빠르게 만든 가속기 역할을 한 것으로 보입니다.
④는 보도된 구조를 바탕으로 한 이 보고서의 해석이며, 은행이나 당국이 "BOLA"라는 용어로 발표한 것은 아닙니다. 요청에 들어온 번호가 "지금 로그인한 사람이 볼 수 있는 정보인지"를 서버가 매번 확인하지 않으면, 번호만 바꿔 넣어 남의 정보를 조회할 수 있게 됩니다.
| 근거 | 내용 | 상태 |
|---|---|---|
| 도구 흔적 | 금융보안원이 신한은행 로그와 공격자 IP를 역추적해 ARTEX 사용 흔적을 확인. 박상원 원장 "공통된 IP에 아르텍스 흔적이 있다"(헤럴드경제·서울신문, 10월 6일 업데이트). 공격에 얼마나 쓰였는지는 경찰이 수사 중 | 흔적 확인 |
| AI의 역할 | 당국 관계자: 해커가 AI 도구를 활용한 것이고, 사람 개입 없이 AI가 독자적으로 공격한 것은 아님(헤럴드경제). 금융위원장 "AI를 활용한 해킹공격의 가능성도 배제할 수 없다"(머니투데이) | 사람이 도구로 사용 |
| 당국 판단 | "AI 도구를 활용해 공격 과정을 자동화하고 여러 금융회사를 대상으로 대량 공격을 시도했을 가능성에 무게"(디지털타임스) | 가능성 |
| 은행 설명 | 부산은행 "AI 에이전트를 활용한 외부의 웹서버 공격 시도", 하나은행 "외부 해킹 에이전트" | 은행 자체 판단 |
| 동일 공격자 | 일부 공격에서 동일 IP. 은행과 2금융권 공격 IP는 달랐지만 방식·패턴 유사 | 부분 확인 |
| 배후·국적 | 공식 발표 없음 | 미확인 |
AI 자동화 가능성은 지난 보고서 때보다 근거가 늘었습니다. 하지만 원인 분석에서 더 중요한 점은 따로 있습니다. 1절의 원인 ①~⑦은 모두 AI가 없어도 공격할 수 있는 기본 통제의 빈틈이라는 점입니다. AI는 이 빈틈을 더 빨리, 더 많은 회사에서 동시에 찾게 해 준 "가속기"로 보는 것이 보도 내용과 가장 잘 맞습니다. 그래서 예방도 "AI 대응"이라는 새 장비보다 기본 통제를 빠짐없이 지키는 데서 시작해야 합니다.
1절의 해킹 원인 하나하나에 맞춰, 무엇을 우선 도입해야 하는지 정리했습니다. 글로벌 솔루션의 기능은 AI 브라우저 Aside로 각 회사 공식 문서를 조사하고, 그 결과를 별도로 공식 페이지에서 다시 확인해 대조했습니다.
| 해킹 원인 | 추천 솔루션 (우선순위) | 이 원인에 필요한 이유 | 국내 예시 | 글로벌 예시 (공식 문서로 기능 확인) |
|---|---|---|---|---|
| ① 조회 서비스의 본인 인증 우회 | 1 인증 로직 코드 수정 2 강한 인증(다중인증·FIDO) 2 API 스키마 검증 |
무작위 입력값으로 인증을 건너뛴 만큼, 서버가 정해진 형식 밖의 요청을 거부하고(스키마 검증), 문자 인증 하나로는 조회할 수 없게 해야 함 | (강한 인증 제품은 확인하지 않음) | 스키마 검증: Cloudflare API Shield, F5 Distributed Cloud API Security |
| ② 직원·외부 협력자 시스템의 접근통제 미흡 | 1 외부 접근 차단 + 공격표면관리(ASM) 2 API 자동 발견 3 제로트러스트 접근(ZTNA) |
금융위가 밝힌 공격 지점이 "관리가 집중되지 않은" 업무용 외부 웹·서버. 먼저 무엇이 열려 있는지 찾아 닫고, 남길 것은 확인된 사람·기기만 연결 | ASM: 금융보안원 아틀라스 ASM, 엔키화이트햇 Offen, AI스페라 Criminal IP ZTNA: 모니터랩 아이온클라우드 |
API 자동 발견: Akamai API Security, Cloudflare API Shield, F5, Imperva, Salt Security, Wallarm, Google Apigee |
| ③ 웹페이지·외부 솔루션 취약점 | 1 웹·API 보호(WAAP) 1 취약점·패치 관리 2 세션 검증 코드 보완 |
세션 검증이 약한 페이지(부산)와 외부 솔루션 취약점(예가람 추정)은 앞단 차단과 빠른 패치로 막아야 함 | WAAP: 펜타시큐리티 와플, 모니터랩 아이온클라우드, 파이오링크 웹프론트-K/KS | WAAP·WAF: Akamai App & API Protector, Cloudflare, F5, Imperva, AWS WAF, Google Cloud Armor |
| ④ 객체 수준 권한 확인 누락(BOLA) | 1 권한 확인 코드 수정 1 API 보안 점검·모의해킹 2 런타임 BOLA 탐지 |
번호만 바꿔 남의 정보를 본 구조는 코드에서 "이 사람이 이 기록을 볼 권한이 있는지"를 매번 확인해야 근본적으로 막힘. 탐지 솔루션은 보조 | 점검: 엔키화이트햇 Offen(ASM + 구독형 모의해킹) | BOLA 탐지: Cloudflare API Shield(BOLA 취약점·공격 탐지), Imperva(BOLA Detection & Response) 사전 시험: Akamai(200개 이상 API 보안 시험, OWASP API Top 10) |
| ⑤ 반복 대입·대량 조회 | 1 요청 횟수 제한·봇 관리 1 계정 탈취(ATO) 방어 2 민감 정보 응답 탐지·마스킹 |
일회용 비밀번호 반복 대입(국민), 6개 서비스 집중 조회(신한)를 횟수·패턴으로 끊고, 응답에 주민등록번호 같은 정보가 실려 나가는 것을 찾아 가림 | WAAP 제품군(봇 방어 포함): 펜타시큐리티 와플 등 | ATO 방어: AWS WAF ATP, Wallarm, Imperva, Akamai(Account Protector) 민감 정보: F5(가리기·차단 가능), Imperva, Salt, Wallarm, Akamai |
| ⑥ 탐지·차단 지연 | 1 기존 관제 규칙 점검 2 API 이상 행위 탐지 3 관제 자동 대응(SOAR)·24시간 관제 |
신한은 인지까지 약 15시간 반 걸림. 대량 조회가 시작되면 사람이 보기 전에 자동으로 막는 장치가 필요 | (관제 제품은 확인하지 않음) | 이상 행위 탐지: Cloudflare(Volumetric Abuse Detection), F5, Imperva, Salt, Wallarm, Google Apigee·Cloud Armor |
| ⑦ IP를 수시로 바꾸는 공격 | 1 위협 정보 자동 반영 2 행위·세션 기반 봇 탐지 |
공유받은 IP는 즉시 막되(토스뱅크 차단 사례), IP를 바꾸면 소용없으므로 세션·기기 지문·행동 패턴으로 같은 공격자를 묶어 막아야 함 | 금융보안원·금감원 공격 IP 공유(약 500개사 전파) | Wallarm(IP 풀을 쓰는 ATO 탐지, JA3 지문), Cloudflare(세션별 사용량 분석) |
| ⑧ AI 도구로 빨라진 공격 | 2 머신러닝 기반 이상 탐지 3 AI 기반 방어 |
공격 속도가 사람의 대응 속도를 넘으므로 자동화된 탐지·차단이 필요. 다만 ①~⑦의 기본 통제를 대신하지는 못함 | - | F5(머신러닝 기반 트래픽 기준선), Wallarm(머신러닝·통계 이상 탐지), Google Cloud Armor(Adaptive Protection) |
우선순위: 1 즉시~1개월 2 1~3개월 3 3~12개월. 추천과 우선순위는 이 보고서의 제안입니다.
이번 사고와 직접 관련된 8가지 기능을 기준으로 비교했습니다. 각 칸의 원인 번호는 1절의 해킹 원인입니다.
| 회사 (제품) | API 자동 발견 ② |
BOLA 탐지 ④ |
요청 횟수 제한 ⑤ |
봇 관리 ⑤⑦ |
계정 탈취 방어 ⑤ |
민감 정보 탐지 ⑤ |
스키마 검증 ① |
이상 행위 탐지 ⑥⑧ |
|---|---|---|---|---|---|---|---|---|
| Akamai App & API Protector, API Security | ● | ◐ | — | ● | ◐ | ● | — | ● |
| Cloudflare API Shield, Bot Management, Rate Limiting | ● | ● | ● | ● | — | — | ● | ● |
| F5 Distributed Cloud API Security | ● | ◐ | ◐ | — | — | ● | ● | ● |
| Imperva (Thales) API Security, Advanced Bot Protection | ● | ● | ◐ | ● | ◐ | ● | ◐ | ● |
| Salt Security | ● | ◐ | — | — | ◐ | ● | — | ● |
| Wallarm | ● | — | ◐ | ● | ● | ● | — | ● |
| AWS WAF Bot Control, ATP | — | — | ● | ● | ● | — | — | ◐ |
| Google Cloud Apigee Advanced API Security, Cloud Armor | ● | — | ● | ● | — | — | — | ● |
● 공식 제품 페이지·문서에서 기능 확인 ◐ 간접 확인(회사 블로그·학습 자료·제3자 자료, 또는 포괄적 표현) — 이번 조사에서 확인 못 함. "—"는 기능이 없다는 뜻이 아닙니다.
| 회사 | 확인한 내용 (원문) |
|---|---|
| Cloudflare | BOLA: "Cloudflare labels endpoints with BOLA risk when it detects two distinct signals common with attacks exploiting BOLA: Parameter pollution and Enumeration." 이상 탐지: "Volumetric Abuse Detection generates adaptive, per-session rate limit recommendations". 스키마: "Schema Validation compares incoming requests with an uploaded OpenAPI schema." 봇 관리는 엔터프라이즈 유료 추가 기능 |
| Imperva | "Continuous discovery of all public, private, and shadow APIs". "now features real-time BOLA Detection & Response". 민감 정보: "classifies APIs based on sensitivity, including categories such as government ID, credit card details, address information". 계정 탈취·요청 제한은 Imperva의 WAAP 설명 자료(learn) 기준 |
| F5 | 발견: "Detects and maps all APIs through ... code repository analysis, runtime traffic inspection". 민감 정보: "with capabilities to limit, mask or block APIs from exposing this data". 스키마: "enforce a positive security model with learned or existing OpenAPI specifications". OWASP API Top 10 공격 "detect and block"(포괄적 표현이라 BOLA는 ◐) |
| Akamai | 발견: "including shadow, zombie, unmanaged, MCP, and AI-linked APIs". 민감 정보: "identify APIs that access, process, or return sensitive data such as PII". 이상: "Analyze runtime behavior to identify API abuse, business logic risk". 시험: "Run 200+ API security tests in CI/CD ... OWASP API Security Top 10" |
| Wallarm | "API Abuse Prevention module ... detection and mitigation of bots performing API abuse like credential stuffing". 민감 정보: "API Discovery detects and highlights sensitive data ... PII, Login credentials, Financial data". 탐지된 출처를 1시간 차단 목록에 올림(실시간 즉시 차단은 아님) |
| AWS WAF | ATP: "checks email and password combinations against its stolen credential database", "can temporarily block client sessions or IP addresses that have too many login failures"(추가 요금). Bot Control: "monitor, block, or rate limit bots" |
| Google Cloud | Apigee 문서에 "Shadow API Discovery", "Abuse detection", "Security actions" 항목. Cloud Armor: 요청 횟수 제한(rate-based rules), reCAPTCHA 기반 봇 관리, Adaptive Protection(트래픽 패턴 급변 탐지) |
| Salt Security | 발견·민감 정보: "automatically and continuously discovering all internal, external and third-party APIs", "PII and other sensitive data can be exposed inadvertently through APIs". BOLA·계정 탈취 탐지는 회사 블로그·제3자 자료 기준(◐). 현재 공식 플랫폼 페이지는 AI 에이전트 보안 중심으로 바뀜 |
| 분야 | 예시 | 확인한 내용 |
|---|---|---|
| ASM | 금융보안원 아틀라스 ASM | 금융사의 외부 노출 자산과 취약점을 조회·관리하는 웹서비스. 2025년 12월 시작, 2026년 6월 기준 147개사 이용, 자산 27만 개 이상 관리. 200여 회원사 무료 제공 보도(보안뉴스·바이라인네트워크) |
| ASM + 모의해킹 | 엔키화이트햇 Offen | ASM과 구독형 모의해킹을 결합한 플랫폼, 금융권 도입 활발(보안뉴스) |
| ASM·위협 정보 | AI스페라 Criminal IP | 수요가 전년 대비 2배 이상 증가(보안뉴스) |
| WAAP | 펜타시큐리티 와플(WAPPLES) | 웹방화벽에 API 보호·봇 방어를 더한 WAAP. v7.0 출시(보안뉴스) |
| WAAP·ZTNA | 모니터랩 아이온클라우드(AIONCLOUD) | WAAP, ZTNA 등을 구독형으로 제공하는 클라우드 보안 플랫폼. 가트너 클라우드 WAAP 마켓 가이드 대표 벤더 2년 연속(바이라인네트워크) |
| WAAP | 파이오링크 웹프론트-K / 웹프론트-KS | 각각 구축형·클라우드형 WAAP. OWASP API 10대 취약점 대응을 내세움(파이오링크 공식 페이지) |
위 제품은 보도와 공식 자료로 존재와 기능 범주만 확인한 예시입니다. 추천이나 성능 비교가 아니며, 이번 사고를 막을 수 있었는지 검증된 것도 아닙니다. 이상 행위 탐지·관제, 강한 인증, 데이터 보호 분야는 제품을 따로 확인하지 않아 예시를 넣지 않았습니다. 도입할 때는 금융 보안 규정 준수 여부와 개념 검증(PoC)을 따로 거쳐야 합니다.
| 단계 | 할 일 |
|---|---|
| 즉시 1~2주 |
① 금융보안원·금감원이 공유한 공격 IP를 차단 장비에 반영 ② ASM으로 외부 노출 자산 전수 스캔(금융보안원 서비스 활용) ③ 필요 없는 직원·모집인용 외부 접속 경로 차단 ④ 기존 관제 규칙에 "대량 조회", "반복 실패" 탐지가 있는지와 실제로 작동하는지 확인 ⑤ 웹방화벽에 요청 횟수 제한 규칙 적용 |
| 단기 1~3개월 |
① 직원·모집인 계정에 다중인증 또는 FIDO 적용 ② 조회 API 전체를 대상으로 권한 확인 시험과 모의해킹 ③ 조회 화면·응답의 민감 정보 마스킹 ④ WAAP의 봇 관리·API 보호 기능 적용 ⑤ 모의해킹 지적 사항에 조치 기한 부여 |
| 중기 3~12개월 |
① 직원 시스템 접속을 제로트러스트(ZTNA) 방식으로 전환 ② 관제 자동 대응(SOAR)과 24시간 대응 체계 ③ AI 기반 이상 탐지 도입 ④ 구독형 모의해킹으로 상시 점검 |
기간 구분은 이 보고서의 제안이며, 당국이 정한 일정이 아닙니다. 당국이 정한 기한은 금감원 긴급 점검(은행·카드 10월 6일, 그 밖의 업권 10월 8일)입니다.
| 날짜 | 내용 | 출처 |
|---|---|---|
| 10/3~5 | 금융보안원, ARTEX 흔적 확인. "신한은행의 로그와 공격자 IP를 역추적한 결과 ARTEX를 활용한 흔적이 확인"됐습니다. 박상원 금융보안원장은 "공통된 IP에 아르텍스 흔적이 있다"고 밝혔습니다. 당국 관계자는 해커가 AI 도구를 활용한 것이고, 사람 개입 없이 AI가 독자적으로 공격한 것은 아니라고 설명했습니다. ARTEX는 중국어권 개발자가 깃허브에 공개한 오픈소스 LLM 기반 자율 침투테스트 도구입니다. | 헤럴드경제 단독(10.03), 서울신문 단독(10.05) |
| 10/4 | 금융위 전 금융권 긴급 점검회의. 이억원 금융위원장이 주재했고, 이찬진 금감원장, 박상원 금융보안원장, 전 업권 협회장, 피해 7개사 CEO가 참석했습니다. 당국은 공격 특성을 "대부분 대출모집인, 임직원 등이 업무상 편의를 위해 사용하는 외부 웹페이지, 서버 등 상대적으로 관리가 집중되지 않은 영역에서 공격"이라고 정리했습니다. 또 공격자가 "동일한 공격자 IP 주소를 수시로 바꿔가며 방화벽을 우회해 지속적인 침투를 시도"했다고 밝혔습니다. | 서울경제, 머니투데이(10.04) |
| 10/4 | 새 조치 3가지와 책임 경고. ① 외부 노출 IT 자산과 보안 취약점 전면 재점검 ② 소비자 서비스나 업무에 필수불가결한 경우를 빼고 외부 접근 원칙적 차단 ③ 접근 권한과 조회 정보 최소화. 이미 공유된 공격 정보를 반영하지 않은 금융사에는 "관련 법령에 따라 엄정히 책임을 묻기로" 했습니다. | 서울경제, 머니투데이(10.04) |
| 10/4~8 | 금감원, 약 500개 금융사 긴급 점검. 공격 IP와 보안 유의사항을 전파하고 12개 항목 점검표를 배포했습니다(공격 IP 차단과 피해조사, 외부 노출 전산자산 식별 등). 기한은 은행·카드사 10월 6일, 증권·보험·저축은행 등 10월 8일입니다. | 마이데일리(10.06), 시사저널e(10.05) |
| 10/6 | 토스뱅크도 같은 IP의 접근을 받았지만 막아 냈습니다. 신한은행 공격에 쓰인 미국 IP 2개가 올해 1월과 7~8월 토스뱅크 서버에 총 14차례 접근을 시도했으나 차단돼 피해가 없었습니다. 공격자가 몇 달 전부터 같은 기반으로 금융권을 탐색했다는 뜻입니다. | 마이데일리(10.06) |
| 10/6 | 경찰 정식 수사 착수. 경찰청 국가수사본부가 정보통신망법 위반 혐의로 정식 수사를 시작했습니다. 사이버테러대응과장을 팀장으로 4개 팀 28명 전담팀을 꾸렸고, 대상은 피해 7개사입니다. 경찰: "신속하고 엄정하게 수사를 진행해 나가겠다". | 파이낸셜포스트, 마이데일리(10.06) |
| 10/5~6 | 증권사·산업계 비상 점검. NH투자증권·삼성증권·미래에셋증권 등이 연휴 중 긴급 점검을 했고, 증권사 고객정보 유출은 확인되지 않았습니다. 한국거래소·코스콤·한국예탁결제원에서도 이상이 발견되지 않았습니다. | 시사저널e(10.05), 마이데일리(10.06) |
| 10/6~ | 국정감사 쟁점으로. 국회 정무위 국감은 10월 6일 시작해 금융위 10월 8일, 금감원 10월 19일 감사가 잡혀 있습니다. 박상혁 의원(정무위 여당 간사): "5대 은행장을 불러 사고 원인과 책임을 묻겠다". | 아주경제(10.05) |
| 10/6 | 저축은행 보안 투자 공개 부족. 저축은행 79곳 중 정보보호 투자·인력을 공시한 곳은 2곳(웰컴·신한저축은행)뿐입니다. | 뉴데일리(10.06) |
| 항목 | 지난 보고서(10월 3일) | 이번 확인(10월 4일) |
|---|---|---|
| 피해 금융사 | 은행 4곳 유출, 2곳 공격만 | 금융사 7곳 유출(예가람저축은행·현대캐피탈·웰컴저축은행 추가) |
| 신한은행 공격 시점 | "9월 30일"(발생인지 확인인지 불분명) | 공격 시작은 9월 28일 저녁 6시 4분. 9월 30일은 최종 차단 시점(MBC가 확보한 신한은행 정보보호본부 보고서) |
| 신한은행 피해 인원 | 약 2만5000명 | 2만5729명(헤럴드경제, 파이낸셜뉴스) |
| 부산은행 원인 | 보도 없음 | "세션 검증이 충분하지 않았던 일부 웹페이지"를 통해 노출(머니투데이) |
| 공격자 | 미확인 | 일부 공격에서 동일 IP 확인. 은행과 2금융권 공격 IP는 달랐지만 방식과 패턴이 유사(금융당국 분석) |
| AI 근거 | 공격 서버의 중국어 문구 하나, 사용 미확인 | 은행 공격 IP에서 ARTEX AI 관련 흔적. 경찰청 사이버수사국이 연관성 확인 중 |
| 금융사 | 규모 | 뚫린 곳 | 유출 항목(보도 기준) |
|---|---|---|---|
| 예가람저축은행 | 개인 약 4만명 | 고객 개인정보가 담긴 서버 | 성명, 생년월일, 연락처 |
| 신한은행 | 개인 2만5729명 | 모바일 홈페이지 "M신한"의 대출모집인용 조회 서비스 | 고객명, 전화번호, 연소득, 대출 산출한도, 주민등록번호 66건, 연계정보(CI) 97건 |
| 현대캐피탈 | 주택대출 모집인 146명 | 대출모집인 정보 조회 페이지 | 주민등록번호, 이름, 휴대전화번호, 이메일, 내부 모집인번호, 여신금융협회 등록번호. 일반 고객 정보는 유출 안 됨 |
| KB국민은행 | 119명 | 직원용 모바일 업무지원시스템 | 고객명, 전화번호, 주소, 암호화된 주민등록번호, 일부 신용등급 |
| 하나은행 | 고객 89명 | 영업지원시스템(ODS) | 주민등록번호, 이름, 주소, 이메일, 전화·휴대번호, 직장명 |
| BNK부산은행 | 외주 개발직원 11명 | 외부 공개 웹페이지 일부 | 성명, 전화번호, 생년월일 등 |
| 웰컴저축은행 | 법인 최대 2200건 | 확인 못 함 | 확인 못 함 |
| 우리·NH농협은행 | 유출 없음 | 공격 시도를 이상징후로 탐지해 차단(IT조선) | - |
출처: 파이낸셜뉴스 10.04(7개사 집계), 헤럴드경제 10.03, 뉴스핌 10.03, YTN 10.02, IT조선 10.02, 예가람·현대캐피탈 세부 항목은 경기일보·뉴스1 등 검색 요약 기준.
빨간 칸이 보안이 무너진 지점입니다. 보도에 나온 사실만 연결했습니다.
공격 IP는 일본·미국·홍콩·싱가포르 등을 경유(MBC). 디지털타임스는 한국·베트남·태국·영국까지 포함해 여러 나라에 분산됐다고 보도. 신한은행: "초기 대응 과정에서 일정 시간이 소요된 부분에 대해 무겁게 받아들인다".
국민은행 시스템은 "인터넷뱅킹, 모바일뱅킹 등 고객의 금융거래와는 관련이 없는 직원용 모바일 업무지원시스템"(연합인포맥스). 금감원은 국민은행 정기 검사가 진행 중이라 별도 현장조사에 착수하지 않음.
공격 시각과 구체적인 침투 방법(인증을 어떻게 넘었는지)은 보도에서 확인하지 못했습니다.
부산은행 재발 방지 계획: "AI 기반 공격에 대한 모니터링을 강화하고, 외부 공개용 웹 페이지 전반을 대상으로 공격표면관리(ASM) 방식의 추가 점검"(머니투데이).
뉴스핌은 두 회사 모두 "대출 신청 및 모집인 연동 서버"가 공격받았다고 보도했습니다.
| 은행 | 공격 시작 | 처음 알아챔 | 시간 차 | 출처 |
|---|---|---|---|---|
| 신한 | 9/28 18:04 | 9/29 09:30 (유출 인지는 19:03) | 약 15시간 26분 (유출 인지까지 약 25시간) | MBC |
| 국민 | 9/27 23:19 | 9/30 19:00쯤 | 약 68시간 (공격 종료 후 약 25시간) | MBC |
| 부산 | 10/1 21:00쯤 | 10/2 04:30께 유출 확인 | 약 7시간 30분 | 머니투데이, 한국경제 |
시간 차는 보도된 시각으로 이 보고서가 계산한 값입니다.
각 예방책을 이번 사고의 원인과 짝지어 정리했습니다. 근거 칸은 해당 기준 문서나 당국 지시입니다.
| 막을 원인 | 예방 방법 | 근거 |
|---|---|---|
| 직원용·모집인용 시스템이 사각지대 | 외부에 열린 IT 자산 전수 목록화와 상시 스캔. 고객용이 아닌 시스템도 외부에서 접근 가능하면 모두 점검 대상에 넣는다. | 금융위 지시: "대고객 서비스 여부나 서비스 종류에 상관없이 외부에서 접근할 수 있는 IT 자산과 서비스를 빠짐없이 파악"(뉴스핌). 금융보안원은 2025년 12월부터 금융권 공격표면관리(ASM) 서비스 제공(보안뉴스) |
| 업무 편의용 외부 웹·서버 10/6 추가 | 필요 없는 외부 연결은 끊기. 고객 서비스나 업무에 꼭 필요한 경우가 아니면 외부 접근을 원칙적으로 막고, 남기는 경로는 접근 권한과 조회 정보를 최소화한다. 직원·모집인용 시스템은 사내망이나 VPN 뒤로 옮기는 것을 우선 검토한다. | 금융위 10월 4일 조치: 필수불가결한 경우를 제외한 "외부 접근 원칙적 차단", "접근 권한 및 조회 정보 최소화"(서울경제) |
| 본인 인증 우회, 휴대폰 인증만으로 조회 | 모든 조회 경로에 서버 측 인증 적용. 인증 없이 내부 정보에 닿는 경로가 있는지 점검하고, 민감 정보 조회에는 더 강한 인증을 요구한다. | 금융위: "인증 없이 내부정보에 접근할 수 있는 경로가 있는지 점검하고 조회 과정에서 인증 절차가 미흡하게 적용되지 않도록"(YTN) |
| 고객번호로 다른 서비스 조회 | 요청마다 객체 단위 권한 재확인. 번호가 들어오면 "이 사용자가 이 기록을 볼 권한이 있는지" 서버가 매번 확인한다. 추측하기 어려운 식별자를 쓴다. | OWASP API Security Top 10 2023, API1: 클라이언트 입력으로 데이터를 조회하는 "모든 함수에서" 권한을 확인하고, 추측하기 어려운 무작위 식별자 사용을 권고 |
| 일회용 비밀번호 반복 대입, 무작위 입력값 | 실패 횟수 제한, 점점 늘어나는 대기 시간, 봇 탐지. 한 계정에 대한 연속 실패를 제한하고, 같은 출처의 반복 요청을 늦추거나 막는다. | NIST SP 800-63B 3.2.2: 한 인증 수단의 연속 실패를 "100회 이하"로 제한해야 함(SHALL). 일회용 비밀번호 검증에는 실패 횟수 제한 장치 필수 |
| 세션 검증 미흡(부산) | 세션은 서버에서 매 요청마다 검증. 유휴·절대 만료 시간을 서버 측에서 강제한다. | OWASP Session Management Cheat Sheet: 세션 ID는 다른 사용자 입력처럼 믿지 말고 검증해야 하며, 만료는 서버 측에서 강제 |
| 대량 조회를 늦게 알아챔 | 조회량 이상 실시간 탐지와 자동 차단. 한 출처나 계정이 짧은 시간에 많은 고객 정보를 조회하면 즉시 경보·차단하고, 야간에도 대응할 수 있게 관제 체계를 둔다. | 신한 인지 지연 15시간 반, 국민 공격 종료 후 하루(MBC). 황석진 교수 "로그인시도와 정보 조회를 탐지하는데 미흡"(머니투데이) |
| 외부 솔루션 취약점(예가람 추정) | 외부 납품 소프트웨어 목록 관리와 보안 업데이트 즉시 적용. | 예가람저축은행 추정 원인(검색 요약) |
| 알려진 취약점 방치 | 모의해킹 지적 사항에 조치 기한을 두고 추적. 당장 고치기 어려우면 차단 규칙·감시 강화 같은 임시 조치를 기록하고 기한을 관리한다. | 유효 취약점 4777개, 일부 장기 방치(파이낸셜뉴스) |
| 회사마다 따로 대응 | 공격 IP·수법 즉시 공유하고, 받은 정보는 바로 차단 규칙에 반영. 이번에도 신한은행 사고의 IP 공유 덕분에 다른 은행 피해가 드러났다. 공격자가 IP를 수시로 바꾸므로 IP 차단과 함께 공격 패턴(반복 대입, 대량 조회)도 공유해야 한다. | 한국경제(IP 공유 후 점검에서 국민·하나·부산 유출 확인), 금융위 "위협정보 신속 공유". 10월 6일 업데이트: 공유된 공격 정보를 반영하지 않은 금융사는 "엄정히 책임"(머니투데이), 같은 IP가 토스뱅크에 14차례 접근했으나 차단(마이데일리) |
| 조회 화면에 민감 정보 과다 노출 | 불필요한 정보 노출 최소화. 조회 화면·응답에 업무에 꼭 필요한 항목만 보여 주고, 주민등록번호 같은 정보는 가리거나 빼낸다. | 금융위 지시: "불필요한 정보 외부노출 최소화"(뉴스핌) |
위 표를 현장에서 바로 쓸 수 있게 질문 형태로 바꿨습니다.
은행 보안은 고객이 고칠 수 없지만, 유출된 정보로 생기는 2차 피해는 줄일 수 있습니다. 아래는 이 사건에 맞춘 일반 대처법입니다.
2~4번 서비스 정보는 하나은행·KB국민카드 안내문 등 검색 결과 기준입니다.