디노텍의 최신 소식과 보안 인사이트를 전해드립니다.
2026년 9월 말부터 10월 초까지 국내 금융회사에서 침해사고가 잇따라 발생하며 개인정보 유출 피해가 확인됐습니다. 이번 사고에서는 핵심 뱅킹 시스템뿐 아니라 대출모집인 전용 서비스, 임직원 업무지원 등 외부와 연결된 업무 시스템의 보안 위험이 주목받았습니다.
특히 일부 공격 인프라에서 AI 기반 자율 침투 테스트 도구인 'ARTEX'의 흔적이 확인됐다는 분석이 나오면서, AI 에이전트를 활용한 공격 자동화 가능성에도 관심이 집중되고 있습니다.
이번 글에서는 금융권 침해사고와 관련된 주요 공격 기법을 살펴보고, 유사 사고 예방을 위한 핵심 보안 대응 방안까지 자세히 알아봅니다.
1. 금융권 침해사고의 배경: '아르텍스(ARTEX)'와 적응형 침투
이번 국내 금융회사 침해사고와 관련해 주목받은 기술적 단서 중 하나가 바로 '아르텍스(ARTEX)'입니다.
아르텍스는 중국 개발자가 GitHub에 오픈소스(AGPL-3.0)로 공개했던 LLM 기반 자율형 침투 테스트 도구입니다. 자체 AI 모델을 개발해 탑재하는 방식이 아니라 OpenAI GPT, Anthropic Claude, DeepSeek 등 외부 LLM API를 연동해 동작하는 구조로 알려져 있습니다.
특히 여러 에이전트가 역할을 분담해 정보 수집, 취약점 탐색, 공격 경로 계획, 보안 도구 실행, 결과 검증 등의 작업을 연결하고 자동화하도록 설계된 것이 특징입니다.
이 과정에서 기존 모의해킹 도구와 ARTEX형 AI 도구의 주요 차이는 작업 계획과 결과 해석, 후속 작업 선택을 얼마나 자동화할 수 있는지에 있습니다. 기존 도구도 설정과 자동화 수준에 따라 복합적인 취약점 검증을 수행할 수 있지만, LLM 기반 도구는 시스템의 맥락과 앞선 작업의 결과를 바탕으로 다음 작업을 조정할 수 있습니다.
비교 항목 |
기존 모의해킹 도구 |
ARTEX형 AI 도구 |
|---|---|---|
| 작동 방식 | 사전 정의된 규칙·검사 로직 기반의 네트워크·서비스 정보 수집 및 알려진 취약점 점검 | LLM 에이전트의 자율 작업 계획 및 도구 실행, 실행 결과 기반의 실시간 후속 작업 조정 |
| 공격의 연속성 | 단일 검사 및 스크립트 설정 범위 내 단계별 검증 | 취약점 탐색·공격 경로 분석·후속 검증 등 다단계 연계 작업의 자동화 |
| 결과 검증 | 고정 규칙 및 환경에 따른 오탐·미탐 발생 가능 | 결과 기반 추가 검증 수행 (AI 판단 오류에 따른 오탐·미탐 가능성 상존) |
| 대응 속도 및 탐색 범위 | 고정 규칙 및 사전에 지정된 정적 검사 범위에 국한 | 결과 분석에 따른 검사 방식·작업 순서의 동적 조정 (권한 및 도구 기능에 따라 가변적) |
공격자가 상용 LLM API와 외부 인프라를 연동해 공격 작업을 자동화했다면, 취약점 탐색과 후속 작업에 필요한 시간을 줄일 수 있습니다. 다만 실제 자동화 수준과 공격 효과는 개별 도구의 구현 방식 및 대상 시스템의 환경에 따라 달라집니다.
개발자는 2026년 10월 8일경 ARTEX 프로젝트의 업데이트를 중단하고 소스코드를 비공개로 전환하겠다는 방침을 밝혔습니다. 이후 로이터는 원본 GitHub 저장소에 접근할 수 없는 상태를 확인했다고 보도했습니다. 다만 저장소의 공개 중단이 기존 코드의 유통이나 별도 파생 프로젝트의 존재까지 의미하지는 않습니다. 실제로 한국어판을 표방하는 별도 저장소도 공개된 바 있어, 원본 저장소의 상태와 파생 코드의 상태는 구분해 살펴볼 필요가 있습니다.
2. 왜 코어뱅킹이 아닌 '외부 접점'이 문제가 된 이유
고도화된 침투 테스트 도구가 활용됐다면 금융회사의 핵심 시스템을 직접 공격했을 것이라고 생각하기 쉽습니다. 하지만 이번 사고와 관련해서는 금융사의 핵심 거래 시스템이 아닌, 점검 사각지대에 놓인 외부 접점인 대출모집인 전용 서비스, 임직원 업무지원 시스템, 외주 인력 관리 인터페이스 등을 주로 겨냥했습니다.
국내 금융회사는 코어뱅킹 시스템을 비롯한 주요 자산을 보호하기 위해 망분리와 접근 통제 등 다양한 보안 대책을 적용하고 있습니다. 그러나 핵심 시스템의 보호 수준이 높더라도 외부에 노출된 서비스나 업무 시스템의 취약점까지 자동으로 해결되는 것은 아닙니다.
따라서 비대면 서비스 확대와 외부 시스템 연계가 늘어날수록 포털, 연동 시스템, API 등 외부 접점의 접근 통제와 데이터 흐름을 함께 관리해야 합니다. 외부 시스템의 취약점이 고객정보 조회 권한이나 내부 시스템과의 연계 구조를 통해 더 큰 위험으로 이어지지 않도록 방어 체계를 설계하는 것이 중요합니다.
이러한 공격 흐름을 이해하기 위해 일반적인 침투 테스트 과정을 바탕으로 논리적 킬체인(Logical Kill Chain)을 4단계로 나누어 살펴보겠습니다. (아래 분류는 공격 흐름을 설명하기 위한 분석 모델이며, ARTEX의 공식 단계 명칭을 인용한 것이 아니고 이번 사고에서 모든 단계가 실제로 수행됐음을 의미하지 않습니다.)
대상 시스템과 네트워크의 자산, 외부에 노출된 서비스와 API 엔드포인트 등 공격 대상 정보를 수집하고 공격 표면을 파악합니다.
수집한 정보를 바탕으로 시스템 구조와 접근 통제 상태를 분석하고, 잠재적 취약점과 침투 가능성이 있는 경로를 검토합니다.
식별한 취약점이 실제 환경에서 악용 가능한지 검증하고, 허가된 테스트 범위 내에서 시스템 접근이나 권한 확보 가능성을 확인합니다.
확보한 접근 권한과 시스템 간 연결 관계를 바탕으로 다른 자산에 대한 접근 가능성을 검토합니다. 실제 측면 이동이나 내부망 확산 여부는 별도의 조사와 로그 분석을 통해 확인해야 합니다.
과거에는 보안 담당자가 다수의 API 파라미터와 접근 권한을 개별적으로 검증해야 했던 작업을, AI 에이전트가 자동화된 검사와 결과 분석을 통해 지원할 수 있습니다. 요청에 대한 시스템 응답을 분석하고 후속 작업을 조정하는 방식은 취약점 탐색과 검증에 필요한 시간을 줄이는 데 활용될 수 있습니다.
따라서 보안 실무자는 악성코드나 시스템 파괴 행위뿐 아니라 정상적인 업무 기능과 API 요청을 통해 발생할 수 있는 인가 오류, 과도한 데이터 조회 권한, 비정상적인 데이터 접근 행위까지 점검해야 합니다.
* 다만 특정 인가 취약점이 이번 사고의 실제 원인이었는지, AI가 공격의 각 단계를 자율적으로 수행했는지는 확인된 조사 결과에 따라 구분해야 합니다.
3. AI 공격 시대, 방어 체계의 전환점 7가지
이번 침해사고는 외부와 연결된 업무 시스템부터 고객정보에 이르는 접근 경로 전반을 점검해야 할 필요성을 보여줍니다. AI 기반 도구가 공격 대상 탐색부터 취약점 분석, 공격 시도 자동화까지 활용되는 환경에서는 기존 방어 체계의 재점검이 불가피합니다.
악성코드 탐지와 알려진 공격 패턴(시그니처) 차단은 여전히 중요한 기본 통제입니다. 그러나 정상적인 계정과 요청 형식을 이용한 공격, 권한 검증 오류를 악용한 정보 접근, 비정상적인 데이터 조회 행위까지 탐지하려면 기존 통제만으로는 한계가 있습니다.
특히 민감한 금융 데이터를 다루는 환경일수록 외 접점부터 핵심 DB까지의 경로를 종합적으로 관리하고, 인증·인가 검증과 데이터 통제, 행위 기반 탐지 체계를 유기적으로 연계해야 합니다. 이를 위해 실무에서 확인 해야할 7가지 핵심 방어 체계 전환점을 살펴보겠습니다.
직원·협력사용 시스템뿐만 아니라 과거 개발·테스트 목적으로 구축된 서브도메인, 레거시 모바일 API, 외부 연계 서비스까지 인터넷에 노출된 자산을 식별하고 관리 목록에 편입해야 합니다.
단순한 자산 목록 작성에 그치지 않고 자산 소유자, 운영 목적, 외부 노출 여부, 처리하는 데이터의 민감도, 인증·인가 방식 등을 함께 관리해야 합니다. 이를 통해 관리 주체가 불분명하거나 더 이상 사용하지 않는 자산을 식별하고, 불필요한 외부 노출을 줄일 수 있습니다.
외 시스템이 내부 고객 DB나 원장 정보에 불필요하게 직접 접근하지 못하도록 데이터 접근 구조를 점검해야 합니다. 필요한 데이터는 업무 목적에 따라 제한적으로 제공하고, 가능한 경우 마스킹된 조회용 데이터나 권한이 통제된 전용 API를 활용하는 것이 좋습니다.
이와 함께 서비스 계정별 최소 권한 원칙을 적용하고, 데이터베이스 접근 권한과 조회 범위를 제한해야 합니다. 중계 API를 도입하더라도 호출 주체와 조회 대상, 업무상 권한을 서버 측에서 검증해야 합니다.
MFA(다중인증)를 도입하더라도 정상적으로 로그인한 사용자가 자신의 권한을 넘어 다른 고객의 데이터를 조회할 수 있다면 정보 유출을 막지 못할 수 있습니다.
특히 객체 식별자를 변경해 다른 사용자의 데이터에 접근하는 BOLA/IDOR 유형의 취약점을 점검해야 합니다. 모든 데이터 요청 단계에서 요청 주체와 조회 대상 데이터의 소유권 및 업무상 접근 권한을 서버 측에서 검증해야 합니다.
화면에서 버튼이나 메뉴를 숨기는 방식만으로 접근을 통제해서는 안 됩니다. 실제 데이터에 접근하는 모든 API 요청에서 사용자 역할, 업무 범위, 위임 권한 등을 확인하고, 권한 검증 실패와 비정상적인 접근 시도를 기록해야 합니다.
ID와 비밀번호만으로 접근을 허용하기보다 사용자 신원, 단말기 보안 상태, 접속 맥락, 서비스별 권한을 종합적으로 평가해야 합니다.
ZTNA(제로 트러스트 네트워크 접근)를 적용해 보안 정책을 충족하는 단말기와 사용자에게 필요한 서비스만 허용하고, 관리자 및 모집인 포털의 접근 경로를 제한할 수 있습니다.
다만 신뢰 기기 기반 통제만으로 애플리케이션 내부의 인가 오류까지 해결되는 것은 아닙니다. 강력한 인증, 단말기 보안 상태 확인, 최소 권한 기반 접근 통제, 서버 측 인가 검증을 함께 적용해야 합니다.
비인가 대량 수집을 방지하기 위해 계정별, 토큰별, 세션별로 단위 시간당 호출 가능한 API 요청과 데이터 조회량을 제한해야 합니다.
단순히 요청 횟수만 확인하는 것이 아니라 순차적인 고객 번호 호출, 짧은 시간 내 광범위한 고객정보 조회, 업무 범위를 벗어난 반복 요청 등 비정상적인 패턴을 함께 분석해야 합니다.
임계치를 초과한 경우에는 위험도와 업무 영향을 고려해 요청 속도 제한, 추가 인증, 일시적인 접근 제한 등의 조치를 적용할 수 있습니다. 정상 업무에 대한 오탐을 줄이면서도 대량 데이터 수집을 조기에 식별할 수 있도록 정책을 지속적으로 조정해야 합니다.
외부 API나 웹 애플리케이션의 취약점이 악용될 경우, 연계 서버와 DMZ 서버가 추가 공격의 경유지로 사용될 가능성도 고려해야 합니다.
이를 방지하기 위해 EDR(엔드포인트 탐지·대응)을 활용해 비정상적인 프로세스 실행, 의심스러운 셸 동작, 비정상적인 시스템 명령 실행 등을 탐지하고 대응할 수 있어야 합니다.
다만 EDR만으로 정상적인 애플리케이션 요청을 이용한 인가 오류나 데이터 조회 남용을 모두 탐지하기는 어렵습니다. 웹 서버 및 API 접근 로그, 인증·인가 기록, 데이터베이스 접근 기록, 네트워크 보안 이벤트를 연계해 분석하는 체계가 필요합니다.
공격 IP 차단과 시그니처 기반 탐지는 여전히 유효하지만, 정상적인 계정과 요청 형식을 이용하는 공격까지 충분히 식별하려면 행위와 문맥을 함께 분석해야 합니다.
예를 들어 파라미터의 순차적인 변경, 단시간 내 광범위한 고객 번호 호출, 평소 업무 범위를 벗어난 데이터 조회, 비정상적인 다운로드 증가 등을 탐지 시나리오에 포함할 수 있습니다.
또한 사용자 계정, 세션, API 요청, 데이터 접근 기록을 연계해 단일 이벤트로는 확인하기 어려운 비정상 행위를 식별해야 합니다. 위험도가 높은 경우에는 추가 인증, 요청 제한, 세션 차단 등 자동 대응을 적용할 수 있습니다.
자동 차단 정책은 정상 업무에 미치는 영향과 오탐 가능성을 고려해 설계하고, 탐지 결과와 대응 효과를 지속적으로 검토해야 합니다.
결론적으로 이번 침해사고는 망분리 중심의 전통적 경계 보안만으로는 외부 접점을 파고드는 공격을 막기 어렵다는 점을 분명히 보여줍니다.
중요한 것은 특정 도구나 공격 패턴에 얽매이지 않고, 외부에 노출된 모든 자산의 가시성을 확보하며 정상 인증 뒤에 숨은 '인가 결함'과 '비정상 행위'를 선제적으로 검증·통제하는 것입니다.