2026년 가을, 일본에서는 기업이나 단체의 웹 시스템에서 정보 유출 공표가 잇따랐습니다. '공격에 AI가 사용되고 있는 것이 아닌가?'라는 이야기도 자주 듣게 되었습니다.
이러한 가운데, 10월 27일 The Hacker News가 일본의 조직을 주요 표적으로 한 세 가지 공격 인프라 분석 결과를 보도했습니다. 그중 한 건에서는 오픈 소스 침투 테스트 도구인 CyberStrikeAI가 악용되었고, 이 과정에서 44개의 AI 에이전트가 정찰부터 데이터 유출, 리포트 작성까지 역할을 분담했다고 합니다.
다만, 이 보고서에는 공격에 사용된 CVE 번호나 표적이 된 제품의 버전 정보가 기재되어 있지 않습니다. IOC(Indicators of Compromise) 역시 비공개입니다. 즉, '우리 장비는 대상인가?'를 버전을 통해 판단할 수 없습니다.
그렇다고 해서 지켜만 봐도 되는 것인지에 대해서는 그렇지 않습니다.
보고서를 읽어보면 침입의 시발점은 새로운 취약점이 아니라, 외부에 노출된 관리 화면, VPN 장비, 설정 미흡 시스템이었습니다. 게다가 AI 관련 시스템 역시 공격 대상에 포함되어 있었습니다.
이에 이번 글에서는 공격자들이 노린 '진입점'을 종류별로 정리하고, Criminal IP IT 자산 검색을 통해 일본 국내에서 얼마나 외부로 노출되어 있는지를 실제로 확인해 보았습니다.
연구자들은 공격자들이 공개 디렉터리에 남긴 도구나 스크립트, 표적 목록, 로그, 명령어 기록 등을 분석했습니다.
세 건 모두 2026년에 활동했으며 작업 언어는 간체 중국어였지만, 동일한 공격자인지는 알 수 없습니다. 또한 국내에서 보고된 ARTEX 관련 인프라와도 별개입니다.
가장 큰 차이점은 AI가 공격의 어느 단계까지 담당했는지 여부였습니다.
| 항목 | Case A | Case B | Case C |
|---|
| AI의 역할 | CyberStrikeAI로 공격 전체를 자율 실행 | 사람이 주도하며, 계획과 도구 개발에 LLM을 활용 | 도구나 스크립트 개발만 (추정) |
| ... | | | |
각 포인트별로 간략하게 정리합니다.
- Case A: 44개의 에이전트가 분업하여 일본어 입력 폼이나 위장 로그인 화면까지 자동 생성했습니다. 또한, 조직당 통신량을 줄여 탐지를 피하고 있었습니다.
- Case B: '정규 진단 업무입니다'라고 위장하여 LLM에게 공격 계획을 만들게 하여 보안 대책을 우회했습니다. AI 워크플로우 시스템이나 추론 서비스도 표적 목록에 포함되어 있었습니다.
- Case C: AI 사용은 '가능성이 높다'는 평가에 그칩니다 (프롬프트나 API 키 등의 직접적인 증거는 없음). 공격자 본인은 자동화와 증거 관리 절차가 갖춰진 숙련자였던 것으로 보입니다.
보고서에서는 AI의 영향을 다음과 같이 정리하고 있습니다.
| 구분 | 내용 |
|---|
| 달라진 점 | 병렬로 처리 가능한 표적 수, 시도 속도, 표적 국가 언어에 대한 적응력, 기록 및 리포트 자동화 |
| 변하지 않은 점 | 악용되는 취약점의 종류, 진입점의 성격 (외부 공개된 오래된 시스템이나 초기 설정) |
Case A에서 가장 깊이 침투한 사례 역시 기점은 인증 없이 공개되어 있던 오래된 웹 시스템의 관리 화면이었습니다.
새로운 취약점은 사용되지 않았습니다. 연구자들은 이를, AI로 인해 공격자의 '인력'은 늘었지만, 하는 일 자체는 여전히 잠겨 있지 않은 문을 찾는 것과 같다고 표현했습니다.
즉, CVE를 알 수 없다는 것이 점검을 미룰 이유가 되지 않습니다. 공격자가 AI로 수천 개의 후보를 한 번에 시도할 수 있다면, 방어하는 측 역시 '무엇이 외부에서 보이는지'를 먼저 알아야 합니다.
이번 보도는 일회성 뉴스가 아닙니다. 10월 이후의 주요 발표들을 나열해 보면 흐름을 잘 알 수 있습니다.
| 공표일 | 발표원 | 내용 |
|---|
| 10월 27일 | The Hacker News | 세 가지 공격 인프라(CyberStrikeAI 등) 분석 보도 |
| ... | | |
ARTEX와 CyberStrikeAI는 별개의 도구이며, 발견된 인프라도 다릅니다. 일본을 노리는 AI 관련 공격 인프라가 복수 동시에 작동하고 있다고 판단됩니다.
또 하나 주목할 점은 10월 21일의 LiteLLM 사례입니다. 일본을 겨냥한 것은 아니지만, 릴리스 파이프라인이 탈취되어 악성 litellm==1.107.0가 PyPI 등에서 배포되었습니다.
기점은 지난 5월 공개 리포지토리에 실수로 커밋되었고, 만료되지 않은 채 남아있던 마스터 키였습니다.
Case B에서 AI 관련 시스템이 표적이 된 점과 종합해 볼 때, AI 게이트웨이나 에이전트의 실행 환경 자체가 ‘매력적인 표적’이 되고 있음을 알 수 있습니다.
여기서는 실제로 Criminal IP를 검색했습니다.
아래 건수는 2026년 11월 2일~3일 기준입니다. 이는 검색 조건에 일치하는 건수이며, 실제 침해되거나 취약한 자산의 수는 아닙니다. 또한, 확인은 화면 열람에 그쳤으며 로그인 등은 진행하지 않았습니다.
Case C 공격자는 최소 6개의 캠페인을 병행했으며, VPN 장비를 여기저기서 노렸습니다. Cisco SD-WAN, Citrix NetScaler, F5 BIG-IP에서는 공개된 취약점이나 관리 기능의 악용이 시도되었고, Yamaha RTX1210에서는 설정 파일 내 인증 정보가 사용되었습니다.
보고서에서 이름이 언급된 것은 Cisco SD-WAN이지만, 여기서는 원격 접속에 자주 사용되는 ASA(AnyConnect/WebVPN)의 로그인 화면을 찾아보겠습니다. /+CSCOE+/logon.html은 ASA의 WebVPN 로그인 페이지 경로입니다.
IT 자산 검색 쿼리 ▶ country: JP "/+CSCOE+/logon.html"
결과는 2,740건이었습니다. 포트는 443번이 2,713건으로 거의 전부였고, 80번이 18건, 8443번이 3건이었습니다. 응답에는 webvpn, webvpnc, webvpn_portal 등 WebVPN 특유의 쿠키가 포함되어 있었습니다.
흥미로웠던 점은 인증서였습니다. 공통 이름(Common Name)이 vpn.sse.cisco[.]com의 서브도메인으로 되어 있는 사례가 있었습니다.
이는 Cisco의 클라우드형 서비스 VPN 연결 지점일 가능성이 있으며, 자체적으로 운영하는 ASA와 관리 주체가 다릅니다.
자사 자산과 대조할 때는 인증서의 CN이나 IP 소유주를 확인하여, 자사 장비와 클라우드의 연결 지점을 구분하는 것이 중요합니다.
NetScaler는 Citrix ADC, Citrix Gateway로 이름이 바뀐 제품입니다. 장비마다 페이지 제목이 다르므로, 두 가지 모두 검색했습니다.
IT 자산 검색 쿼리 ▶ title: "NetScaler Gateway" country: JP
IT 자산 검색 쿼리 ▶ title: "Citrix Gateway" country: JP
| 쿼리 | 건수 | 경향 |
|---|
| NetScaler Gateway (신규 명칭) | 54건 | 443번은 절반 이하. 비표준 포트에 분산되어 있으며, 클라우드 상의 자산이 많음 |
| Citrix Gateway (구 명칭) | 79건 | 대부분 443번. 국내 통신 사업자의 회선이 상위권 |
구 명칭 쪽 결과가 더 많다는 결과를 얻었습니다. Citrix Gateway 결과에는 국내 기업명이 포함된 인증서가 많아, 기업이 자체 회선으로 운영하는 원격 접속 진입점이라고 생각됩니다.
중간에는 로그인 페이지의 Last-Modified 날짜가 2022년 3월에 머물러 있는 사례도 있었습니다. 제목이나 Last-Modified만으로는 취약하다고 단정할 수 없지만, 구 명칭이 표시된 자사 장비는 펌웨어와 지원 상황을 우선적으로 확인해 볼 필요가 있습니다.
반면, NetScaler Gateway 결과에는 수백 개의 포트가 동시에 열려 있고 Critical 판정이 난 클라우드 자산도 섞여 있었습니다. 이는 실제 게이트웨이가 아닐 가능성, 즉 허니팟일 수 있습니다.
일본 특유의 표적은 Yamaha의 라우터입니다. RTX 시리즈는 중소기업이나 지점에서 폭넓게 사용되고 있으며, 연구자들은 노려진 RTX1210 대수를 통해 “공격자가 일본의 도입 현황을 잘 알고 있었다”고 분석했습니다.
IT 자산 검색 쿼리 ▶ product: YAMAHA country: JP
결과는 25,575건이었습니다. 모두 국내였으며, 포트는 1723번(PPTP) 이었습니다. PPTP 응답에 포함된 벤더명(YAMAHA Corporation)과 펌웨어 식별 값으로 Yamaha 라우터로 판정되었습니다.
같은 IP에서 500번(IPsec)이나 8080번, 7547번이 열려 있는 사례도 있었습니다. 회선은 국내 법인용 및 개인용에 걸쳐 폭넓게 분포되어 있어, 본사나 지점, 매장의 라우터가 VPN의 진입점으로 외부에 노출된 상황임을 짐작할 수 있습니다.
참고로, 이는 PPTP로 식별된 부분만 해당하므로, 실제로 공개된 Yamaha 라우터는 더 많을 것입니다.
여기서 중요한 것은 공격에 제품의 취약점이 사용되지 않았다는 점입니다. PPTP는 사용자 이름과 비밀번호로 연결하는 방식이므로, 설정 파일이 유출되거나 인증 정보를 거점 간에 재사용하고 있다면 펌웨어가 최신 버전이라도 일반적인 로그인 시도가 가능합니다.
PPTP 자체도 오래된 프로토콜이므로, IPsec이나 IKEv2 등으로의 전환이 권장됩니다.
Oracle WebLogic Server는 Java/Jakarta EE 애플리케이션을 구동하는 미들웨어입니다. 업무 시스템에서 오랫동안 사용되어 왔기 때문에, 오래된 환경이 남아있기 쉬운 제품이기도 합니다.
Case C의 공격자들은 WebLogic 후보를 1,300건 이상 리스트화하고 있었습니다. 목록에 올라 있다고 해서 침해되었다는 의미는 아니지만, **목록에 오르는 조건은 '외부에서 노출되어 보이는 것'**입니다.
IT 자산 검색 쿼리 ▶ title: WebLogic country: JP
결과는 4건으로 적었습니다. 국가 조건을 제외하면 214건이며, 중국, 한국, 미국이 상위에 있습니다. 다만, 제목 검색으로는 초기 화면 등이 남아있는 자산만 발견되므로 실제로는 더 많다고 생각됩니다.
여기에 4건을 하나씩 살펴보니, 진짜 WebLogic처럼 보이는 것은 단 1건뿐이었습니다. 나머지는 수십 개의 포트가 열려 있거나, WebLogic과는 다른 서버 정보를 반환하는 등 허니팟(honeypot) 같은 자산들입니다.
진짜로 보이는 1건은 국내 ISP의 회선상에 있었고, 접속하자 WebLogic Server 14.1.1의 초기 화면이 그대로 표시되었습니다.
image-2026-11-3_11-29-17.png
설치 직후 나오는 샘플의 메인 페이지이며, 오른쪽 상단에는 관리 콘솔을 실행하는 버튼까지 보입니다.
초기 화면이 남아있다는 것은 샘플 삭제나 공개 범위 재검토가 이루어지지 않았을 가능성이 있습니다.
관리 콘솔이 외부에서 접근 가능한 상태는 취약점 유무와 관계없이 개선해야 할 지점입니다.
Case B에서는 AI 워크플로우 시스템, LLM 전처리 시스템, 추론 서비스가 표적 목록에 올라 있었습니다.
타인의 AI 서비스 접속을 가로채 조합하는 방식도 있으며, 목적은 대량의 추론 능력을 저렴하게 확보하는 것으로 추정됩니다.
AI 게이트웨이나 LLM 프록시에는 여러 AI 서비스의 API 키가 모아서 등록되는 경우가 많아, 한 곳이 뚫리면 피해가 확산될 수 있습니다.
- 비용 부정 이용: 사용료는 정식 소유자가 지불하고, AI는 공격자가 사용하는 경우 -
- 공격 인프라화: 도난당한 추론 능력이 다른 조직에 대한 공격 자동화에 사용되는 경우 -
- 인증 정보 연쇄 유출: LiteLLM 사례처럼, AI 관련 시스템이 가진 개발자 토큰에서 리포지토리나 릴리스 파이프라인까지 침해가 확산되는 경우
LiteLLM은 100개 이상의 LLM을 OpenAI와 호환되는 단일 API로 처리할 수 있는 오픈소스 AI 게이트웨이입니다.
IT 자산 검색 쿼리 ▶ title: LiteLLM country: JP
결과는 2,779건...이라고 생각했지만, 그중 2,749건이 AWS 상의 자산이었고, 수십 개의 포트가 열린 Critical 판정의 자산들이 줄지어 있었습니다. WebLogic과 마찬가지로, 허니팟 등이 대량으로 포함된 것으로 보여 이 숫자를 그대로 '공개 수'라고 할 수는 없습니다.
그래서 LiteLLM 프록시의 기본 포트인 4000번에 한정했습니다.
IT 자산 검색 쿼리 ▶ title: LiteLLM AND port: 4000 country: JP
결과는 10건이었고, 모두 LiteLLM의 API 문서(Swagger UI)를 열람할 수 있는 상태였습니다. 그중 클라우드 상의 1건에서는 화면 상단에 **버전 (1.98.0)**이 표시되어 있었고, 관리 패널(/ui)로 가는 링크도 보였습니다.
국내 교육기관 네트워크상에서 구동되는 LiteLLM에서도 마찬가지로 API 문서를 열람할 수 있었습니다.
Swagger UI의 자물쇠 아이콘은 API 정의상의 인증 설정을 알 수 있는 단서가 되지만, 실제로 인증이 걸려있는지는 알 수 없습니다. 하지만 WebLogic 초기 화면과 마찬가지로, 관리 화면으로 가는 링크나 API 구성이 로그인 전에 노출된 사례입니다. 관리 UI나 API 문서에 대한 접근은 사내 네트워크로 제한해야 합니다.
이번 조사에서는 NetScaler, WebLogic, LiteLLM 모두에서 진짜 같지 않은 자산들이 많이 섞여 있었습니다. 공격자의 움직임을 관측하기 위한 허니팟 등으로 보입니다. 검색 결과를 자체 점검에 사용할 때는 다음과 같은 점들을 체크하면 구분하기 쉽습니다.
| 점검 항목 | 의심스러운 징후 |
|---|
| 개방 포트 수 | 수십~수백 개의 포트가 동시에 열려 있음 |
| 반대로, 자사 조직명이나 도메인이 포함된 인증서로 필요한 포트만 열려 있는 자산은 실제 장비일 가능성이 높다고 할 수 있습니다. 점검 시에는 우선 이쪽을 진행하는 것이 좋습니다. | |
CVE를 시작점으로 삼을 수 없을 때는, 자산을 시작점으로 하여 점검합니다. 보고서에서 제시된 대응 우선순위에 따라 당장 할 수 있는 것들을 정리했습니다.
외부에서 보이는 자산 파악: 본 기사의 쿼리에 자사 IP 대역이나 도메인 조건을 추가하여 검색하고, 자산 목록과 대조합니다.
관리 화면 및 로그인 진입점 우선 처리: 관리 화면, VPN 로그인 페이지, AI 게이트웨이 관리 UI가 외부에서 접근 가능하다면, 사내 네트워크나 VPN 경유로만 제한합니다.
인증 정보 재고 조사: 초기 비밀번호, 지점 간 공통 인증 정보, 퇴사자나 위탁업체 계정이 남아있지 않은지 확인합니다.
API 키는 '삭제'만 할 것이 아니라 '폐기(Invalidate)'해야 합니다: LiteLLM 사례에서는, 기록에서 삭제했음에도 폐기되지 않은 키가 약 5개월 후에 악용되었습니다.
개별 IP 리포트로 주변까지 확인: 동일한 IP로 SSH나 데이터베이스 등이 열려 있지 않은지 확인합니다.
정기적으로 재점검: 한 번 닫았던 자산이라도, 설정 변경이나 테스트 환경 방치로 인해 다시 열릴 수 있습니다.
AI 에이전트가 활동했던 Case A에서도 가장 깊은 침투 진입점은 인증 없는 관리 화면이었습니다. AI가 바꾼 것은 공격의 규모와 속도이지, 공격자가 찾는 취약점의 종류는 아닙니다.
이번 보고서에는 CVE나 버전 정보가 기재되어 있지 않지만, 이는 '자사와 무관하다'는 의미가 아닙니다. 공격자 목록에 오를 조건은 우선 외부에서 보이는 것입니다.
CVE가 발표되기를 기다리기보다는, 자사 무엇이 외부에서 보이는지를 먼저 파악하는 것이 AI로 가속화되는 공격에 대한 현실적인 대비책입니다.
Criminal IP는 무료 계정으로도 검색할 수 있으니, 우선 자사의 도메인이나 IP 대역으로 검색해 보세요.
- The Hacker News: CyberStrikeAI Uses 44 AI Agents to Automate Hacking Operations Against Japan Targets
- LiteLLM: The attack chain behind the v1.107.0 LiteLLM release
- JPCERT/CC: 국내 조직에서 발생한 일련의 부정 접근에 대한 주의 환기
- 국가사이버통괄실: 부정 접근으로 인한 정보 유출 사안 대응에 관하여
- 연이은 부정 접근 공격 출처의 상당수가 AI임을 확인 | 보안 블로그 | 취약점 진단(보안 진단) GMO 사이버시큐리티 by 이에라에