본 내용은 2026년 10월 24일 기준의 공개 정보를 바탕으로 작성되었으며, 추측이 포함된 부분도 있습니다.
2026년 10월, AI를 활용한 침투 테스트 도구가 실제 공격에 사용되었다는 보고가 CrowdStrike, Microsoft, 그리고 국내 보안 기업들로부터 연이어 나왔습니다. 같은 시기 국내에서는 9월 하순부터 약 한 달 동안 수십 개의 조직이 부정 접근으로 인한 정보 유출을 공표했으며, JPCERT/CC를 비롯한 각 기관들이 주의 환기를 하고 있습니다.
본 기사에서는 최근 3개월(2026년 7월 하순 ~ 10월)간 발생한 인시던트를 정리하고, 공격 측면에서 무엇이 바뀌었는지, 그리고 방어 측면에서는 개발부터 운영까지 어느 단계에서 무엇을 해야 할지를 정리합니다. 후반부에서는 AWS를 활용한 구축 방법과 기술 외적인 조직의 판단 및 훈련에 대해서도 다룹니다.
참고로, 여기서 다루는 사례들은 공개 자료나 보도를 기반으로 한 것입니다.
지자체 등에서 사용하는 방재 정보 일괄 전송 서비스인 'SpeeCAN RAIDEN'을 제공하는 Arcadia가 2026년 10월 11일 부정 접근을 당했습니다. 동사는 10월 19일과 23일에 경과를 정리한 보고서를 공표했습니다.
보고서에 따르면, 침입의 시발점은 첨부 파일을 공개하는 미디어 서버의 디렉터리 경로 순회(directory path traversal) 취약점이었습니다. 이를 통해 설정 파일이 읽히면서 내부에 있던 서비스 간 로그인용 시크릿 키가 유출되었습니다. 그 키를 이용해 계정 로그인이 성립되었고, 내부 정보가 탈취되었습니다. 이후 CMS(WordPress)에 부정 플러그인이 심어졌고, 이를 경유하여 대량의 스팸 메일이 외부로 전송되었습니다.
| 항목 | 내용 |
|---|
| 공표일 | 2026년 10월 19일 · 23일 (경과 보고) |
| ... | |
| 이 사례를 통해 읽어낼 수 있는 점은 세 가지가 있습니다. | |
- 원인은 제품의 CVE가 아닌 자체 코드와 설정에 있었다. 디렉터리 경로 순회라는 고전적인 취약점과, 설정 파일에 놓인 비밀 정보입니다. 취약점 스캐너로 제품의 알려진 CVE만 추적해서는 발견할 수 없습니다.
- 공격 시작부터 17시간 동안 탐지하지 못했다. 그 사이에 탐색이 진행되었습니다. 알려진 공격 패턴뿐 아니라 행동의 이상을 보는 것이 필요합니다.
- 복구 대응 자체가 장애를 만들었다. 침입 경로를 차단한 후 DB 비밀번호를 변경했을 때, 어떤 서비스가 해당 인증 정보에 의존하고 있는지 파악하지 못하여 외부 연동 등이 중단되었습니다.
참고로, 보고서에는 공격에 AI 도구가 사용되었다는 언급은 없습니다. 다만, 공개 서버의 취약점에서 설정 파일 및 인증 정보로 순차적으로 이어지는 흐름은 후술할 AI 침투 도구가 자동화하는 움직임과 매우 유사합니다. 동사는 재발 방지책으로 전 서비스에 사내 LLM을 활용한 취약점 진단과 코드 리뷰를 실시했다고 밝혔으며, 10월 23일 기자회견에서는 AI를 활용한 방어 도입을 검토할 것이라고 언급했습니다.
2026년 9월 하순부터 국내에서는 다수의 조직이 부정 접근으로 인한 정보 유출을 공표했습니다. 주요 사례는 다음과 같습니다 (건수는 각 사의 공표 시점 기준이며, '유출 가능성'을 포함합니다).
| 공표일 | 조직 | 건수 | 대상 · 경로 (공표 범위) |
|---|---|
| 9/28 | 타임즈카(Park24) | 약 660만 계정 (본인 확인 서류 이미지 약 160만) | 웹 시스템에 대한 부정 접근 |
| ... |
건수와 원인은 각 사의 공표 자료 및 보도를 기반으로 합니다. 여기서 읽어낼 수 있는 경향은 두 가지입니다.
- 공식 앱의 회원 관리 시스템이 많다. 스마트폰 앱 뒤에 있는 API나 데이터베이스가 목표가 되고 있습니다.
- 위탁사나 공통 인프라를 거친 파급 효과가 눈에 띈다. 문의 시스템 제공처(Scala Communications), 클라우드 인프라(IDC Frontier), 메일 전송 인프라(Yumilink) 등에 대한 공격이 이를 사용하는 여러 기업으로 확산되었습니다.
이러한 흐름을 받아 각 기관들이 주의 환기를 하고 있습니다.
JPCERT/CC는 (2026년 10월 8일 발표, 23일 업데이트) 공격 수법을 5가지 유형으로 정리했습니다. 여기에는 알려진 취약점 탐색, 공개 앱 분석을 통한 API 공격 수법, Metabase의 취약점(CVE-2026-72898), 웹셸 설치, 그리고 'AI 침투 테스트 기반 악용'이 포함됩니다. 마지막 유형에서는 추후 언급할 Cairn, CyberStrikeAI, ARTEX가 이름으로 거론되었습니다.
NICT는 (2026년 10월 13일) 공개된 Android 앱을 분석하여 API 구조를 파악하고, 그 이면의 서버를 공격하는 수법을 'A2B 공격(App-to-Backend Attack)'이라 명명하며 주의를 당부했습니다. 앱 자체에 결함이 없더라도, 서버 측 인증 미비(IDOR/BOLA)나 SSRF, RCE, SQL 인젝션 등의 문제가 있다면 피해로 이어질 수 있다고 지적했습니다.
이 외에도 개인정보보호위원회, 경찰청, 국가사이버통괄실, 과학기술정보통신부, 산업통상자원부, 한국인터넷진흥원(IPA), 금융감독원이 10월 초에 연이어 주의를 당부했습니다. IPA는 10월 16일에 부정 접근 특별 상담 창구를 개설했습니다.
또한, GMO 사이버보안 by 이에라에(Ierare)는 10월 19일 일본 기업을 노린 공격 인프라 중 하나에서 ARTEX 사용이 확인되었다고 발표했습니다. 이 인프라의 표적은 약 20개 일본 기업이며, 별도로 AI를 사용하는 공격 인프라도 6대가 발견된 것으로 알려졌습니다(표적 수는 침해에 성공한 수와는 다릅니다).
정부 공통 업무 기반인 '가버먼트 솔루션 서비스(GSS)'가 부정 접근을 당하면서, 디지털청은 2026년 9월 11일 약 24만 6천 건의 개인정보가 유출되었을 가능성이 있다고 공개했습니다. 침입 경로는 유지보수 운영에 사용되던 VPN 장비의 취약점이었으며, 침투 후에는 유지보수 담당자의 계정으로 서버상의 대량 파일에 접근한 것으로 파악되었습니다.
이 사건은 악용된 취약점의 심각도가 공개 당시 '중(Medium)'이었다는 점이 중요하므로, 패치 우선순위 논의에서 4.8을 통해 자세히 다루겠습니다.
최근 3개월 동안 해외에서도 AI 침투 테스트 도구를 사용한 공격이 보고되었습니다.
- 한국 금융기관: CrowdStrike가 2026년 10월 7일에 보고했습니다. 9월 하순부터 10월 초에 걸쳐 ARTEX를 이용해 여러 금융기관이 공격받았으며, 약 6만 8천 명 분의 개인정보가 유출되었을 가능성이 있습니다. 침입 경로는 인증이 취약한 공개 시스템이었습니다.
- ConnectWise (공급망 공격): Microsoft가 10월 21일에 공개했습니다. 중국 국가 계열로 추정되는 Storm-0940이 ARTEX를 사용해 9월 초부터 전 세계 수백 개 조직을 표적으로 삼았습니다. 클라우드 앱의 신뢰 관계를 악용하여 2,250개가 넘는 테넌트에 로그인(Sign In)을 시도했습니다. 표적화된 후 중요한 권한을 얻기까지 3시간이 걸리지 않은 사례가 보고되었습니다.
- Cairn (웹사이트 대량 침해): 보안 기업 NorForge가 발견하고 로이터가 10월 19일경 보도했습니다. 한 공격자가 오픈소스 AI 에이전트 기반인 Cairn을 사용하여 1,200개가 넘는 사이트를 공격하여 100개 이상의 기업에 침투한 것으로 알려졌습니다. 비용은 토큰 값으로 약 5,000달러, 침입 건당 약 50달러로 추정됩니다.
Anthropic이 2026년 9월 10일에 공개한 위협 인텔리전스 보고서(2025년 12월~2026년 8월에 차단된 악용 사례를 요약)는 공격자가 AI를 채팅 상담 상대로 사용하는 단계에서, 공격의 여러 단계를 연결하는 오케스트레이터로 사용되는 단계로 이동하고 있다고 언급합니다. 정찰(Reconnaissance), 취약점 악용, 데이터 절도 등을 병행하여 진행하는 자율적인 운영 사례도 제시되었습니다. 한편, 표적 선정, 성과 현금화, 결과 확인 등의 판단은 여전히 사람이 담당하고 있다고 합니다.
Verizon의 2026년 DBIR 역시 공격자가 표적 선정, 초기 침투, 취약점 조사, 악성코드 개발에 생성형 AI를 사용하고 있다고 보고했습니다. AI 등장으로 무엇이 근본적으로 바뀌었다기보다는, 기존의 공격 방식들이 더 저렴하게, 빠르게, 대량으로 수행 가능해졌다는 해석이 각 보고서에 공통적으로 나타납니다.
2026년 10월 보고에서 이름이 거론된 도구 중 대표적인 것이 ARTEX입니다. CrowdStrike나 Microsoft, CSA(Cloud Security Alliance)의 자료에 따르면 다음과 같습니다.
- 2026년 7월 26일에 AGPL-3.0 오픈 소스로 공개된
여러 AI 에이전트가 정찰부터 취약점 발견, 공격 경로 검토까지 진행하는 침투 테스트 자동화 기반입니다.
그 자체는 AI 모델이 아니며, 외부 LLM과 도구를 호출하여 조합하는 '지휘자' 역할을 합니다.
한국 금융기관, 일본 기업, ConnectWise를 통한 공급망 공격에서 실제로 사용된 것으로 보고되었습니다.
개발자는 악용을 이유로 2026년 10월 8일에 소스 코드를 비공개 처리했습니다. 하지만 그전까지 유포된 복사본이나 포크(파생 버전)는 남아 있어 여전히 공격에 사용될 수 있는 상태입니다. AhnLab은 전 세계 약 600개의 IP 주소에서 ARTEX 인스턴스를 확인했다고 밝혔습니다.
원작자가 막더라도, 파생 버전에 기능이 추가되는 것이 이 도구의 문제입니다. 보도에 따르면, 포크 버전 중 하나(개발자 계정명으로부터 'RUBAT-B'라고 불림)에는 공개 서버에서 DMZ, 내부 네트워크, Active Directory (AD)로 단계적으로 침투하는 기능이 추가되었다고 전해졌습니다. 방어적인 목적으로 개조된 파생 버전도 있어 같은 메커니즘을 보호 측에서도 사용할 수 있습니다.
공격의 자동화는 단순히 '외부에 공개된 서버를 뚫는 것'을 넘어, '그 너머 내부까지 침투하는 것'으로 확장되었습니다.
기존의 '인터넷에 노출된 부분을 단단히 막으면 내부는 안전하다'는 전제만으로는 부족합니다. 공개 서버가 한 번 뚫리면, 그 서버에 허용된 내부 통신이나 내부에 남아있는 오래된 취약점이 다음 발판이 됩니다. 대책은 '외부에서 차단하는 것'과 '침입당해도 확산시키지 않는 것'의 이중 구조로 고민해야 합니다 (구체적인 대책은 4.7에서 다룹니다).
일련의 사안들에서 노려진 것은 특별한 미지의 취약점(제로데이)이 아니라, 다음과 같은 기존에 존재하는 약점이었습니다.
- 인증이 취약한 공개 시스템
- 설정 파일에 놓인 비밀 정보
- API 권한 부여(Authorization)의 결함
- 공개된 후 방치된 알려진 취약점
GMO 인터넷의 FX용 VPS 무단 접근(제6장에서 후술)에서도, 회사 스스로가 사전에 내부적으로 파악 및 지적했던 보안상의 과제를 공격당했다고 설명했습니다. 미지의 취약점에 당했다기보다, 자사에서 인지하고 있던 약점이 남아있었던 패턴입니다.
변화한 것은 공격의 '비용'과 '속도'입니다. 과거에는 이러한 약점을 하나하나 찾는 데 많은 시간이 걸려 수익성이 낮은 표적은 놓치곤 했습니다. AI 에이전트는 그 탐색을 저렴하게(Cairn 사례에서는 건당 약 50달러) 대량으로, 쉬지 않고 수행할 수 있습니다. CrowdStrike는 공개 PoC가 있는 취약점 악용의 88%가 PoC 공개 후 48시간 이내에 발생하고 있다고 보고했습니다.
즉, 해야 할 일의 대부분은 이전부터 알려진 기본적 대책입니다. 달라진 것은 그 기본을 매번, 빠르게 반복하지 않으면 따라잡기 어려워졌다는 점입니다.
많은 조직의 대책은 다음 세 가지 조합이라고 생각합니다.
- 취약점 스캐너나 벤더 정보에 의한 취약점 탐지
- 정기 유지보수 등에서의 수동 패치 적용
- 출시 전 또는 연 1회 외부 침투 테스트
이 모든 것은 필요한 대책입니다. 다만, 최근의 공격과 비교했을 때, 이것만으로는 잡아낼 수 없는 부분이 네 가지 있습니다.
| 공격 주체 | 방어 주체 | |
|---|
| 취약점이 공개된 이후 | PoC가 있는 취약점 악용의 88%가 PoC 공개 후 48시간 이내 (CrowdStrike, 2026년 1~6월). 악용까지의 평균은 추정 -7일로, 패치보다 먼저 악용이 시작됨 (Mandiant M-Trends 2026) | 악용이 확인된 취약점(CISA KEV)이라도 완전히 수정된 것은 26%. 수정까지의 중앙값은 43일 (Verizon DBIR 2026) |
| ... | | |
| 연 1회 침투 테스트는 그 시점의 상태만을 볼 수 있습니다. 다음 출시로 들어온 취약점이나, 테스트 다음 주에 공개된 CVE는 다음 검사까지 남아있습니다. | | |
취약점 스캐너가 잘하는 것은 CVE가 할당된 제품이나 라이브러리입니다. Arcadia 사례의 원인은 자사의 미디어 서버 디렉토리 경로 순회(Directory Path Traversal)와 설정 파일에 놓인 서비스 간 시크릿 키였습니다. JPCERT/CC의 주의 환기 역시 API 접근 제어 결함이나 환경 설정 파일·백업 파일 방치 등을 언급했습니다. 이들 모두 제품의 CVE로는 나오지 않습니다.
국내 사례에서는 문의 시스템 제공업체, 클라우드 인프라 기반, 이메일 배포 기반 등에 대한 공격이 이를 사용하는 여러 기업으로 파급되었습니다. Verizon DBIR 2026에서도 제3자가 관련된 침해 사고가 전체의 48%를 차지하며, 전년 대비 60% 증가했습니다. 자체 시스템만 보고 있으면 이러한 경로를 놓치기 쉽습니다.
'인터넷에 노출된 부분을 단단히 막으면 내부에는 안전하다'는 생각은 여전히 자주 볼 수 있습니다. 내부 서버의 패치를 미루는 운영 방식도 드물지 않습니다. 그러나 최근 사례에서는 외부가 뚫린 후에 내부로 침투하는 경우가 발생하고 있습니다.
- 디지털청 GSS의 경우, VPN 장비의 취약점을 통해 침입하여 유지보수 담당자의 계정으로 서버상의 대량 파일에 접근한 사례
- ConnectWise의 경우, 침입 후 앱 자격 증명 추가 및 특권 역할 변경이 이루어졌습니다 (Microsoft)
- ARTEX의 파생 버전에는 공개 서버에서 DMZ, 내부망, AD로 단계적으로 이동하는 기능이 추가되었다고 보도되었습니다.
외부가 한 번 뚫리면, 내부에 남아있는 오래된 취약점이나 너무 광범위한 권한 자체가 다음 발판이 됩니다.
공격이 저렴하고 빨라진 이상, 방어 측 역시 같은 속도로 돌아가는 메커니즘이 필요합니다. 하지만 우선 기본 대책을 확립하는 것이 최우선입니다. 여기서 AI는 기본 대책을 커밋(commit)이나 배포(deploy)할 때마다 실행하기 위한 수단으로 활용됩니다.
| 공정 | 수행 내용 | AI에 맡기는 부분 | 사람이 담당하는 부분 |
|---|
| 설계/코딩 | 위협 모델링, 취약점 검사, 정적 분석(SAST), 시크릿 탐지 | 위협 모델 생성, PR별 코드 리뷰 | 모델 및 지적 사항 확인 |
| ... | | | |
AI를 이용한 코드 취약성 진단은 2026년에 들어와 제품화가 진행되었습니다. Claude Security (Anthropic), Codex Security (OpenAI), GitHub Copilot Autofix, Amazon Inspector Code Security, AWS Continuum 등이 있습니다. Arcadia 역시 재발 방지책으로 모든 서비스에서 사내 LLM을 이용한 취약성 진단 및 코드 리뷰를 실시하고 있습니다.
사용 시 주의할 점은 다음 세 가지입니다.
- 연 1회가 아닌, PR(Pull Request)마다 실행해야 합니다.
- 기존 SAST, 의존성 스캔, 시크릿 탐지 등과 병행해야 하며, AI 리뷰로 대체해서는 안 됩니다.
- 지적 사항은 사람이 확인해야 합니다. CERT-EU 역시 AI를 사용한 테스트는 사람이 결과를 검증한다는 전제하에 사용할 것을 권고하고 있습니다.
SBOM(Software Bill of Materials, 소프트웨어 부품 명세서)은 소프트웨어에 포함된 OSS나 라이브러리의 목록입니다. 이것이 있으면 새로운 CVE가 나왔을 때 '어떤 서비스의 어떤 이미지에 그 부품이 들어 있는지'를 즉시 파악할 수 있습니다. 악용까지 48시간이라는 상황에서는 영향 범위 조사에 하루를 쓸 여유가 없습니다.
- SBOM 기록 표준 포맷으로는 CycloneDX와 SPDX 두 가지가 있으며, 광범위하게 사용됩니다. 제작 방법이나 운영 진행 방식은 경제산업성의 'SBOM 도입 관련 수첩' 등에 정리되어 있습니다. 우선 주요 서비스에서 SBOM을 출력하고 취약성 정보와 대조하는 운영부터 시작하는 것이 좋습니다.
- 의존하는 OSS 자체가 공격 대상이 되는 공급망 공격에도 대비해야 합니다. 정식 라이브러리나 배포 경로가 탈취되어 이용자가 모르는 사이에 악성 코드가 포함되는 공격입니다. 2026년에는 광범위하게 사용되는 npm 패키지가 침해된 사례(AWS가 북한 관련 연루를 특정)가 있었습니다. 대책 중 하나가 '쿨다운'으로, 공개 직후의 오염된 버전을 피하기 위해 새로운 패키지는 일정 시간이 지난 후에만 가져옵니다 (AWS는 Amazon Linux에서 공개 후 24시간 이내의 npm/pip 패키지를 회피하는 설정을 소개했습니다).
- 컨테이너 이미지는 OS 패키지 및 언어 라이브러리의 취약점 외에도 설정값(root 권한 실행, 불필요한 패키지, 이미지 내 시크릿)도 확인해야 합니다.
공격 측이 AI 침투 도구를 사용하고 있는 이상, 방어 측 역시 같은 종류의 도구로 릴리스 전에 테스트해 볼 의미가 있습니다. 관리형 서비스(AWS Security Agent. 현재는 AWS Continuum의 침투 테스트), 상용 서비스, OSS 등 선택지는 늘어나고 있습니다.
운영 시 다음 사항에 유의합니다 (CSA 권장사항을 참고했습니다).
- 허가된 범위 내에서, 분리된 검증 환경에서, 규칙을 문서화한 후 실행한다.
- 도구를 구동하는 호스트, 테스트용 인증 정보, 실행 로그를 관리한다.
- OSS를 사용할 경우, 출처가 확인된 것에 한정한다. 공격에 사용된 도구의 포크(fork)에는 관리 화면을 숨기는 기능 등이 추가되기도 한다.
전문가의 진단을 없애겠다는 것이 아니라, AI 침투 테스트(penetration test)는 릴리스마다 수행하는 검사로 위치시킵니다.
AI가 수정 PR(Pull Request)을 생성하는 기능은 AWS Continuum, GitHub Copilot Autofix, Claude Security 등에 있습니다. 자동화 범위는 단계적으로 넓혀가는 것이 현실적입니다. AWS Continuum은 처음에는 사람이 수정을 승인하는 모드로 시작하며, 테스트 커버리지(coverage)나 적용 범위 등의 조건을 충족한 종류의 수정만 자동 적용으로 전환할 수 있도록 설계되었습니다. 해당 서비스 콘솔에도 패치가 생성되었다고 해서 수정이 완료된 것을 의미하지 않는다는 취지의 주석이 있습니다.
수정 후 동일한 검사를 재실행하여 막혔는지 확인하는 과정까지를 파이프라인에 포함시킵니다.
- 중대한 취약점이 남아있다면 배포(deploy)를 멈추는 게이트를 설정한다.
- 시크릿(secret)은 코드나 설정 파일에 작성하지 않고, 시크릿 관리 서비스에 보관한다. 서비스별로 분리하고 로테이션(rotation)을 전제로 한다. 아르카디아(Arcadia) 사례에서는 설정 파일에 있던 서비스 간의 시크릿 키가 침입의 발판이 되었습니다.
- IaC(Infrastructure as Code)와 배포 대상의 설정값을 점검한다.
아르카디아 사례에서는 공격자가 약 10시간에 걸쳐 탐색하던 단계에서는 인지하지 못했으며, 감지의 계기는 DB의 비정상적인 부하였습니다. 탐색 단계에서 알아내기 위해서는 알려진 공격 패턴뿐만 아니라 행위(behavior)를 살펴봐야 합니다.
- Mandiant는 엣지 장비(edge device)에 대한 무단 접근, API의 대량 조작, SaaS 연동 토큰의 의심스러운 사용을 행위로 감지할 것을 권고합니다.
- AI 에이전트에 의한 탐색은 단시간에 대량의 체계적인 요청, 오류에 대한 빠른 반복, 다양한 공격 시도로 나타납니다(CSA). WAF와 봇 방지책을 이러한 움직임에 맞춰 조정합니다.
- JPCERT/CC는 API 요청 수 제한, 로그인/비밀번호 재설정/SMS 전송/검색과 같은 고위험 기능에 대한 개별 제한, 이용 지역이 한정되는 서비스에서의 지역 제한을 언급했습니다.
- SBOM과 결합하여 운영 중인 이미지에 새로운 CVE가 발생하면 통지합니다.
- 로그는 90일보다 길게 보관합니다(Mandiant).
- 탐지 결과의 1차 조사는 AI에 맡길 수 있게 되었습니다(예: Amazon GuardDuty investigation agent, 2026년 10월 기준 프리뷰). 대응 판단은 사람이 합니다.
2.3에서 언급된 '외부에서 막기'와 '들어와도 확산시키지 않기'의 이중 구조(앞서 제시된 그림) 중 후자에 해당하는 대책입니다.
사고방식의 핵심은 '경계 내부라면 신뢰한다'는 개념을 버리는 것입니다. 경계형 방어는 외곽을 넘어가는 순간 내부가 무방비 상태가 됩니다. 대신, 통신 및 접근 시마다 '누가・어떤 단말기로・무엇에'를 확인하고 필요한 만큼만 허용합니다. 이것이 제로 트러스트(Zero Trust)의 기본입니다. '한 번 들어왔으니 신뢰한다'가 아니라, 요청마다 인증(authentication)과 인가(authorization)를 다시 수행한다고 생각하면 이해하기 쉽습니다.
구체적으로는 다음과 같은 것들이 있습니다.
- 공개 측에서 내부로의 통신 허용을 재고한다. DMZ와 같이 공개 측 서버가 탈취되면, 해당 서버에 허용된 내부 통신이 다음 발판이 됩니다. 허가는 업무상 필요한 것에만 국한합니다.
- 관리자 및 유지보수 운영 계정에 MFA(Multi-Factor Authentication)와 최소 권한을 적용한다. 평소 사용하지 않는 권한은 필요한 때에만 부여합니다.
- 인증 정보는 서비스별로 분리한다. 아르카디아 역시 재발 방지책으로 시행하고 있습니다.
- AD(Active Directory) 및 인증 기반 설정을 점검한다. Mandiant는 AD 인증서 서비스 템플릿 설정 오류로 관리자 계정이 생성된 사례를 들었습니다.
- 내부 자산에도 패치를 적용합니다. 우선순위가 낮더라도 대상에서 제외하지 않습니다.
- 내부 통신과 계정의 행위를 감시합니다. GSS에서는 유지보수 운영 계정에 의한 대량 파일 접근이 감지의 계기가 되었습니다.
- 외부 연결은 VPN으로 네트워크에 접속시키는 방식에서, 이용자와 단말기를 접근할 때마다 확인하는 방식(제로 트러스트)으로 전환합니다.
참고로, 디지털청의 Q&A에 따르면 GSS는 제로 트러스트 아키텍처를 채택하고 있었습니다. 그럼에도 불구하고 유지보수 운영을 위한 VPN 장비가 입구 역할을 하고 있습니다. 제로 트러스트는 도입했다고 끝이 아닙니다. 유지보수 경로와 같은 예외적인 경로도 동일한 기준으로 다루어야 합니다.
패치 우선순위를 'CVSS가 높은지'와 '인터넷에 공개되었는지'로 결정하는 운영 방식이 많다고 생각합니다. 하지만 디지털청(デジタル庁)의 사례는 그것만으로는 충분하지 않다는 것을 보여주고 있습니다.
디지털청의 Q&A (2026년 9월 12일 업데이트)에서는 다음과 같이 설명하고 있습니다.
- 악용된 취약점은 공개 당시 평가로는 '중(CVSS 값 Medium 레벨)'이었습니다.
- 평가에 따른 일반적인 대응보다 빠르게 조치를 진행했지만, 수정 프로그램 적용 전에 악용되었습니다.
- 앞으로는 보다 실질적인 리스크를 기반으로 신속하고 선제적으로 대응할 수 있도록 취약점 관리를 강화할 것입니다.
디지털청은 제품명이나 CVE 번호를 공개하지 않았습니다. 보안 블로그 piyolog는 Palo Alto Networks의 VPN 제품 인증 우회 취약점인 CVE-2026-0257에 해당할 가능성을 제기하고 있습니다. 이는 추측이며, 디지털청은 이를 인정하지 않고 있습니다. 이 취약점의 경과는 다음과 같습니다.
| 날짜 (2026년) | 사건 |
|---|
| 5월 13일 | 공개. CVSS 4.7 (Medium) |
| ... | |
만약 이 CVE였다고 가정한다면, 공개 후 4일 만에 악용이 시작되었고 점수가 높아진 것은 16일 뒤였습니다. 만약 공개 당시의 점수로 기한을 정했다면, 점수가 오르기 전에 공격이 이미 시작된 것입니다. VPN이 인터넷에 노출되어 있다는 사실은 처음부터 알고 있었으므로, '외부 공개 여부'만으로는 판단할 수 없습니다.
점수와 외부 공개 여부 외에도 다음 순서로 살펴보는 것이 좋습니다.
- 악용되고 있는가. 벤더나 위협 정보 보고, KEV(Known Exploited Vulnerabilities), 자동화하기 쉬운지, 공격 코드가 유통되는지 등을 확인합니다. KEV 등록을 기다리다 보면 늦을 수도 있습니다.
- 돌파당하면 무엇을 얻게 되는가. VPN이나 에지 장비는 내부로의 진입점이며, 유지보수 계정이나 인증 기반 시설에 연결되어 있습니다.
- 어디서 오는가. 인터넷에서 오는 것이 먼저입니다. 다만 내부 자산 역시 외부가 뚫리면 도달할 수 있습니다.
- 우리 회사 구성에서 해당되는가. 특정 설정일 때만 영향을 받는 취약점도 있습니다.
- 심각도 (CVSS). 점수는 나중에 바뀔 수 있으므로, 공개 후에도 추적해야 합니다.
- 공격이 성공한 후에, 이미 침입하지 않았는지 확인합니다.
공적인 프레임워크 역시 같은 방향으로 변화하고 있습니다.
- CISA는 2026년 6월 10일의 BOD 26-04에서 KEV에 등재된 취약점에 일률적인 기한을 부여하는 방식을 폐지했습니다. 외부 공개 여부, KEV 등재 여부, 악용 자동화 가능성, 악용 시 시스템 완전 제어 가능성 네 가지 조합으로 기한을 정합니다. 가장 급하게 처리해야 하는 구분은 3일 이내 수정 외에 침해되지 않았는지 확인하는 것을 요구합니다. 리스크가 낮은 것은 다음 정기 업데이트까지 기다릴 수 있습니다. 조건이 바뀌면 기한도 바뀝니다. 이는 미국 연방 정부 기관을 위한 지침이지만, 민간에서도 생각할 거리를 얻을 수 있습니다.
- 국가사이버통괄실은 6월 12일에 정부 기관용 가이드라인을 개정하여 취약점 대책을 강화했습니다. PwC의 해설에 따르면, 대응을 서두를지 판단하는 데 악용 실적(KEV), 악용 가능성(EPSS), 심각도(CVSS), 자산 중요도를 사용하고, 패치를 즉시 적용할 수 없을 때는 피해가 발생하기 전에 시스템을 중단하는 것도 검토하며, 그 판단 기준을 사전에 정해두는 것이 제시되었습니다.
2026년 3월, 컨테이너 스캐너 Trivy의 GitHub Action이 침해되어 거의 모든 버전 태그에 악성 코드가 삽입되었습니다. CI/CD 시크릿을 훔친 후 일반적인 스캔을 실행했기 때문에 파이프라인은 정상적으로 작동하는 것처럼 보였습니다. 원인은 2월에 발생한 다른 침해 이후 인증 정보의 로테이션(rotation)이 불완전했기 때문이라고 보고되었습니다.
- GitHub Actions는 태그가 아닌 커밋 해시로 고정해야 합니다.
- 보안 도구나 AI 도구도 다른 의존성(dependency)과 마찬가지로 관리해야 합니다.
- AI 도구에 전달하는 권한과 인증 정보는 최소화해야 합니다.
2026년 10월 시점의 서비스로 4가지 공정을 구성하면 다음과 같습니다.
| 공정 | 서비스/기능 | 상황 |
|---|
| 코딩 | Amazon Inspector Code Security (GitHub・GitLab과 연동하여 SAST, 의존성, IaC 검사) | 제공 중 |
| ... | | |
4.7의 '넣어도 퍼지지 않게'와 API 권한 미비(1.2의 A2B 공격)는 권한 및 접근 제어 설계에서 효과를 발휘합니다. 이는 특정 공정이 아니라 전체에 걸쳐 적용되는 것입니다.
<table><thead><tr><th>역할</th><th>서비스/기능</th></tr></thead><tbody><tr><td>최소 권한 접근 관리</td><td>AWS IAM, IAM Identity Center</td></tr></tbody></table>
<p>API의 인가(Authorization)는 진입점에서 '누가, 무엇에' 접근할 수 있는지 명시적으로 결정하고, 비공개 엔드포인트를 포함하여 검사하는 것이 기본입니다 (이는 JPCERT/CC의 권고 사항과도 일치합니다). 유지보수 및 운영 접근은 VPN으로 내부 네트워크 전체를 통하게 하는 방식이 아니라, Verified Access처럼 사용자와 단말기를 매번 확인하는 방식으로 전환하면, 1.3의 GSS 같은 유지보수 경로를 통한 침입을 막을 수 있습니다.</p>
<p>API의 인증(Authentication) 및 인가 흐름을 조금 더 자세히 살펴보겠습니다.</p>
<p>핵심은, 인증(누구인지)과 인가(무엇에 접근할 수 있는지)는 별개라는 것입니다. 로그인이 성공했더라도 인가가 허술하면 요청 ID를 조작하여 타인의 데이터에 접근할 수 있습니다. 이것이 인가 미비(IDOR / BOLA)이며, 1.2에서 언급된 NICT의 'A2B 공격' 역시 이 부분을 노린 것입니다. 인증 단계에서 막지 않고, 인가 단계에서 '해당 요청의 주체가 해당 리소스의 소유자인가'를 반드시 확인해야 합니다. AWS에서는 API Gateway의 오소라이저(Authorizer) (Cognito / Lambda)로 인증을 담당하고, Verified Permissions (Cedar)로 세밀한 인가를 맡길 수 있습니다.</p>
<p>참고로, 알카디아 사건에서 원인이 된 점을 AWS의 어떤 기능으로 막거나 발견할 수 있는지에 대입하면 다음과 같습니다. 알카디아가 AWS를 사용했는지는 알 수 없습니다. 동일한 구성을 AWS로 만든다고 가정했을 때의 이야기입니다.</p>
<table><thead><tr><th>원인이 된 점</th><th>막거나 발견할 수 있는 수단</th></tr></thead><tbody><tr><td>미디어 서버의 경로 탐색(Path Traversal)</td><td>Inspector Code Security, Continuum의 코드 검사 및 침투 테스트</td></tr></tbody></table>
<p>기술적인 대책을 갖추더라도, 중대한 취약점이 공표된 후 몇 시간 만에 판단을 강요받는 상황은 사라지지 않습니다. 이때 효과적인 것은 판단 기준과 절차를 평시에 미리 정해두는 것입니다. 2026년 10월의 PHP 취약점 건에서 그것이 잘 작동했던 사례가 있었습니다.</p>
