웹방화벽에 ARTEX User-Agent 차단 규칙을 넣으면 충분한가요?

초기 대응으로는 의미가 있지만 충분하지 않습니다. 공개된 세 값은 공개 소스 기준 후보이고, 코드 한 줄로 바뀌며, 실제 Chromium 브라우저를 구동해 정상 브라우저 헤더를 쓰는 수집 경로도 있습니다. User-Agent와 IP는 과거 접속 이력 조사와 이상 탐지에 쓰고, 접근 허용 여부는 위조할 수 없는 인증서 기반 신원으로 판정하는 편이 안전합니다.

클라이언트 인증서만 발급하면 보안 브라우저 없이도 되지 않나요?

인증서는 등록된 단말이라는 사실을 증명하지만, 그 단말에서 어떤 프로그램이 요청을 보내는지까지 보장하기는 어렵습니다. 또 접속 이후의 붙여넣기, 업로드, 화면 캡처 같은 작업은 인증서로 통제할 수 없습니다. 브라우젠은 브라우젠과 등록 단말의 조합에만 접속을 허용하고, 접속 이후의 작업까지 사용자별 정책으로 통제합니다.

모든 금융 시스템에 브라우젠 접속 강제를 적용할 수 있나요?

아닙니다. 고객용 공개 서비스와 모바일 앱은 대상이 아닙니다. 고객에게 특정 브라우저를 요구할 수 없고, 브라우젠 v1.0은 Windows를 지원하며, 모바일은 로드맵에 반영되어 있습니다. 직원과 협력사가 PC에서 쓰는 웹 업무 시스템이 적용 대상이며, 고객용 서비스는 서버 측 권한 검증과 조회 제한으로 보호해야 합니다.

User-Agent는 신분증이 아니다 - 금융권 AI 해킹과 브라우저 강제

사고 개요 - 코어가 아니라 주변이 뚫렸다

2026년 9월 말부터 10월 초까지 국내 금융권에서 고객·임직원 정보 유출 사고가 잇따라 확인됐습니다. 10월 4일 언론 집계에 따르면 은행 4곳, 저축은행 2곳, 캐피탈 1곳 등 금융사 7곳에서 개인 약 6만6천 명과 법인 최대 약 2,200건의 정보가 유출됐습니다.

공격자가 노린 곳은 코어뱅킹이 아니었습니다. 공격은 직원·대출모집인용 부가 시스템에 집중됐습니다. 대출모집인용 조회 서비스, 임직원용 업무지원 시스템, 영업지원 시스템처럼 업무 편의를 위해 외부에 열어 둔 주변 시스템입니다. 금융위원회도 대출모집인·위탁업체 등 외부 인력과 임직원이 쓰는 시스템을 이번 침해사고의 원인으로 지목했습니다.

당국의 요구도 같은 방향입니다. 금융위원회는 10월 2일 긴급 상황대응 회의에서 외부에 노출된 IT 자산과 접근통제 현황 점검, 인증 없이 내부 정보에 접근할 수 있는 경로 차단, 공격 IP와 수법 공유를 요청했습니다. 이어 10월 4일 전 금융권 긴급 점검회의에서는 필수적인 경우를 제외한 외부 접근을 원칙적으로 모두 차단하고, 외부 접근이 불가피한 경우에도 접근 권한과 조회 가능한 정보를 최소한으로 제한하라고 요구했습니다. 한국인터넷진흥원(KISA)도 10월 3일 기업 보안강화 권고에서 외부 노출 자산 확인, 웹·API 접근 권한 검증, 계정과 인증정보 보호를 우선 과제로 꼽았습니다.

공개된 보도를 종합하면 공격은 다음 흐름으로 진행됐습니다.

단계	공격 수법	드러난 약점
정찰	인터넷에 노출된 모집인·임직원용 웹페이지와 서버를 자동으로 탐색	외부 노출 주변 시스템의 관리 소홀
인증 우회	고객번호 같은 값을 무작위로 대입하며 인증 절차 우회를 시도	시도 횟수 제한과 강한 인증 미적용
정보 수집	고객번호 같은 입력값을 바꿔 가며 조회 API를 반복 호출	서버 측 권한 검증 누락(IDOR)
회피	여러 나라 IP를 쓰고, 차단되면 다른 경로로 조회를 이어감	IP 차단 목록 위주 대응의 한계
자동화	LLM 기반 오픈소스 침투 도구 ARTEX 활용 정황	사람의 대응 속도를 앞지르는 자동화 공격

같은 시기 피해를 피한 은행들의 사례도 보도됐습니다. 한 은행은 아이디와 비밀번호만으로는 업무 시스템에 접속할 수 없도록 별도 인증서와 생체 인증을 요구했고, 다른 은행은 대출모집인에게 내부망 접속 경로 자체를 주지 않았습니다. 접속할 자격을 계정 하나가 아니라 별도의 증명으로 판정했다는 점이 공통점이었습니다.

AI 침투 도구가 남긴 흔적, 고정 User-Agent

ARTEX는 중국어권을 중심으로 GitHub에 공개된 오픈소스 AI 자율 침투테스트 도구입니다. 대규모 언어 모델(LLM)이 목표를 분석하고 공격 경로를 계획한 뒤 보안 도구를 실행합니다. 보도에 따르면 금융보안원은 처음 신고된 은행의 로그와 공격 IP를 역추적하다 ARTEX 활용 흔적을 확인했고, 공격 IP가 바뀌어도 도구가 보내는 데이터에 공통 특징이 남아 있어 공격자를 특정할 수 있었다고 설명했습니다.

ARTEX 공개 소스에는 공격 대상 웹 시스템으로 전달될 수 있는 User-Agent 문자열이 고정값으로 정의돼 있습니다. PLURA 블로그의 분석은 이 값을 웹방화벽 우선 검색용 후보 침해지표(IOC)로 정리했습니다.

User-Agent 고정값	공개 소스상 용도
`artex-enrich/1.0`	웹 자산 정보를 확인하는 요청
`Mozilla/5.0 (spa-api-recon)`	HTML·JavaScript 파일을 모아 API 경로를 찾는 스크립트
`Mozilla/5.0 (spa-api-recon spider)`	웹페이지를 순회하며 링크와 입력 폼을 모으는 스크립트

해석에는 주의가 필요합니다. 이 세 값은 공개 소스에서 확인한 후보이며, 이번 사고의 실제 공격 로그에서 관측된 값으로 검증된 것은 아닙니다. ARTEX에는 실제 Chromium 브라우저를 구동해 브라우저의 요청 헤더를 그대로 쓰는 수집 경로도 있습니다. 세 문자열을 막았다고 도구 전체를 막은 것은 아닙니다.

고정값의 양면 - 탐지 단서이자 우회 수단

방어자에게는 일시적인 탐지 단서

공격 도구가 고정 User-Agent를 쓰면 웹방화벽이나 접근 로그에서 그 문자열을 검색해 과거 접속 이력을 찾고, 지금 들어오는 요청을 막을 수 있습니다. 초기 대응으로는 의미가 있습니다.

그러나 이 값은 코드 한 줄을 고치면 바뀝니다. 탐지 규칙이 공개되는 순간 공격자도 그 사실을 압니다. IP 차단 목록이 다국적 IP 순환 앞에서 한계를 드러낸 것과 같은 구조입니다. 공격자가 정하는 값을 기준으로 한 차단은 뒤따라가는 대응이 되기 쉽습니다.

공격자에게는 복사 한 번이면 되는 문자열

반대 방향의 문제도 있습니다. HTTP 표준인 RFC 9110에서 User-Agent는 요청을 보내는 소프트웨어가 스스로를 소개하는 헤더입니다. 서버가 그 소개가 사실인지 확인하는 수단은 표준에 없습니다. 브라우저 개발자 도구, 명령행 도구, 스크립트 어디서든 원하는 값을 적어 보낼 수 있습니다.

따라서 접근 허용 여부를 User-Agent로 판정하면 통제가 성립하지 않습니다. “전용 앱에서만 접속 허용”이나 “보안 브라우저에서만 접속 허용”을 User-Agent에 들어 있는 고정 문자열로 판별하고 있다면, 공격자는 정상 단말의 User-Agent를 한 번 확인해 그대로 복사하는 것만으로 그 판별을 통과합니다. 자동화 도구는 이런 헤더 조합을 지치지 않고 바꿔 가며 시도합니다.

식별 수단	값을 정하는 쪽	바꾸는 데 드는 노력	이번 사고에서	알맞은 쓰임
User-Agent	클라이언트가 직접 적음	코드 한 줄	도구 고정값이 후보 지표로 공개됐지만 교체 가능	탐지 보조 지표
IP 주소	접속 경로	프록시·해외 서버로 교체	차단 후 다른 나라 IP로 재공격	탐지와 후행 차단
아이디·비밀번호	사용자	유출·추측 값 대입	무작위 대입으로 인증 우회 시도	다른 요소와 결합
클라이언트 인증서	기관이 발급, 개인키는 단말에 보관	개인키 없이는 연결 불가	피해를 피한 은행은 계정 외 인증서를 추가로 요구	접근 판정의 기준

필요한 방어 - 문자열이 아니라 증명으로

국민일보 보도처럼 접속 기기와 이용자의 신원을 실제로 확인하지 않으면 외부인의 접근을 막기 어렵습니다. 원칙은 네 가지입니다.

접속 판정은 위조할 수 없는 신원으로 합니다. 기관이 발급한 클라이언트 인증서와 단말 밖으로 꺼낼 수 없게 보관한 개인키가 그 기준입니다. 개인키를 가진 단말만 연결을 완성할 수 있으므로 User-Agent나 IP를 어떻게 바꾸어도 판정은 달라지지 않습니다.
판정은 HTTP 요청보다 먼저 합니다. 상호 인증 TLS(mTLS)는 TLS 표준(RFC 8446)의 클라이언트 인증 절차를 이용해 암호화 연결을 맺는 단계에서 클라이언트 인증서를 검증합니다. 검증에 실패한 클라이언트의 요청은 웹 애플리케이션에 도달하지 못합니다. 서버에 아직 찾지 못한 권한 검증 결함이 남아 있더라도, 외부 자동화 도구가 그 결함까지 닿는 경로가 끊깁니다.
User-Agent와 IP는 탐지 지표로 씁니다. 버릴 필요는 없습니다. 공유된 침해지표로 과거 이력을 조사하고, 인증서 검증을 통과한 뒤에도 남는 이상 징후를 찾는 보조 신호로 활용합니다.
서버 측 권한 검증은 별도로 고칩니다. 요청한 사용자가 그 고객번호를 볼 권한이 있는지 서버가 매번 확인해야 합니다. OWASP API Security Top 10은 이 결함을 첫 번째 위험인 객체 수준 권한 검증 실패(API1)로 꼽습니다. 대량·순차 조회에 대한 속도 제한도 함께 둡니다.

브라우젠은 어떤 부분으로 대응하나

브라우젠(BrowZen)은 직원 PC에 설치해 쓰는 Chromium 기반 보안 브라우저입니다. 금융당국이 요구한 “외부 접근은 원칙적으로 차단하고, 불가피하면 최소한으로”를 업무 시스템 입구에서 구현하는 방법 가운데 하나입니다. 이번 사고와 관련된 기능은 두 가지입니다. 업무 시스템으로 들어오는 문을 브라우젠으로 한정하는 접속 강제, 그리고 들어온 뒤의 작업을 사용자별로 통제하는 정책 적용입니다.

1. 클라이언트 인증서 기반 접속 강제

브라우젠은 클라이언트 인증서(mTLS)를 이용해 브라우젠과 등록된 단말의 조합에만 업무 시스템 접속을 허용합니다. 인증서 검증은 암호화 연결을 맺는 단계에서 이루어지므로 판정에 User-Agent 문자열이 쓰이지 않습니다. 공격 단계별로 보면 다음과 같습니다.

공격 단계	접속 강제를 적용했을 때
외부 노출 시스템 정찰	인증서가 없는 스캐너와 스크립트는 연결 단계에서 끊겨 페이지와 API 구조를 수집하지 못합니다
User-Agent 위조	정상 단말의 User-Agent를 그대로 복사해도 인증서와 개인키가 없으면 연결되지 않습니다
다국적 IP 순환	판정 기준이 IP가 아니므로 어느 나라 IP로 바꿔도 결과가 같습니다
계정·인증 우회 시도	계정이 맞아도 등록 단말의 브라우젠이 아니면 로그인 화면에 도달하지 못합니다
입력값 대입 조회(IDOR)	외부 도구가 조회 API에 닿지 못합니다. 다만 결함 자체는 서버에서 고쳐야 합니다

2. 접속 이후의 정책 적용

정상 단말로 들어온 사용자라도 통제는 필요합니다. 계정이 탈취됐거나 내부자가 정보를 모으는 경우입니다.

사용자·그룹 정책: 로그인한 사람과 소속에 맞는 정책이 자동으로 적용됩니다
업로드·다운로드 정책: 사이트와 부서별로 파일의 업로드·다운로드를 허용하거나 차단합니다
캡처·화면 공유 차단과 사용자 워터마크: 업무 화면의 캡처를 막고, 화면에 사용자 ID·접속 IP·시각을 새겨 유출 경로를 추적할 수 있게 합니다

적용 범위와 한계

대상: 직원과 협력사가 PC에서 쓰는 웹 업무 시스템입니다. 모집인이나 외주 인력처럼 외부에서 접속해야 하는 사용자도 등록 단말을 기준으로 같은 원칙을 적용할 수 있습니다
대상 아님: 고객용 공개 서비스와 모바일 앱입니다. 고객에게 특정 브라우저를 요구할 수 없고, 브라우젠 v1.0은 Windows를 지원하며, 모바일은 로드맵에 반영되어 있습니다. 이번 사고의 표적 가운데 모바일 업무 시스템도 있었던 만큼 모바일은 별도 통제가 필요합니다
서버 결함은 서버에서: 접속 강제는 공격 표면을 줄이지만 권한 검증 결함을 고쳐 주지는 않습니다. 정상 사용자가 같은 결함을 악용하는 경로는 서버 측 검증으로 막아야 합니다

지금 점검할 것

외부에 노출된 직원·협력사·모집인용 시스템 목록을 빠짐없이 작성합니다
접근 판별 코드와 웹방화벽 설정에서 User-Agent나 IP 문자열 비교로 “전용 앱”이나 “전용 브라우저”를 판정하는 부분을 찾습니다
조회 API에 객체 수준 권한 검증과 대량·순차 조회 제한이 있는지 확인합니다
공유된 공격 IP와 후보 User-Agent로 9월 하순 이후 접속 로그를 조사합니다
외부 접속이 꼭 필요한 업무 시스템은 인증서 기반의 단말·브라우저 확인으로 전환합니다

마치며

이번 사고에서 공격자는 IP를 바꾸고, 계정을 바꾸고, 필요하면 User-Agent도 바꿀 수 있었습니다. 바꿀 수 없는 것은 등록된 단말에만 있는 개인키입니다. 접근 통제의 기준을 공격자가 바꿀 수 있는 값에서 바꿀 수 없는 증명으로 옮기는 것, 그것이 AI가 공격 속도를 끌어올린 시대에 방어가 따라잡는 방법입니다.

브라우젠의 기능과 구축 환경은 BrowZen 제품 페이지에서, 보안 브라우저의 기본 개념과 VDI·RBI와의 차이는 보안 브라우저(SEB)란 무엇인가에서 확인하실 수 있습니다.

참고 자료

공공기관 발표와 표준 문서

금융위원회, 「최근 발생하는 금융권 침해위협에 면밀히 대응해 나가겠습니다」 보도자료 (2026-10-02)
금융위원회, 「全금융권이 비상한 경각심을 갖고 침해위협에 대응해 나가겠습니다」 보도자료 (2026-10-04 회의, 10-06 게시)
한국인터넷진흥원 KISA 보호나라, 최근 사이버공격 대비 기업 보안강화 권고 (2026-10-03)
IETF, RFC 9110 HTTP Semantics, 10.1.5 User-Agent
IETF, RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3
OWASP, API Security Top 10 2023, API1 Broken Object Level Authorization

언론 보도

파이낸셜뉴스, 금융사 7곳 뚫렸다… 개인 6만6천명·법인 2200건 정보 유출 (2026-10-04)
국민일보, [단독] ‘고객용’ 보안만 살피다가…’직원·협력사’시스템서 뚫렸다 (2026-10-05)
한국일보, ‘2만5000명 대 0명’ 해킹 피해 왜 달랐나… 은행별 보안 격차 주목 (2026-10-05)
헤럴드경제, [단독] 은행 연쇄 해킹 도구는 중국 ‘아르텍스 AI’…해커가 사용했다 (2026-10-03)

보안 업계 분석

PLURA 블로그, [1보] 금융권 해킹 공격 IOC: ARTEX AI 관련 공개 지표와 즉시 점검 항목 (2026-10-03)