마이크로소프트가 공개한 AI 게이트웨이 공격 보고서 분석. LiteLLM·RAGFlow·Kestra 세 워크로드에서 PID 1 환경변수 탈취부터 XMRig 채굴까지 이어진 6단계 침투 체인과 탐지 지표를 정리했다.
2026년 8월 26일 마이크로소프트가 공개한 위협 인텔리전스 보고서에 따르면, 공격자들은 AI 게이트웨이 컨테이너의 1번 프로세스(PID 1)가 가진 환경변수 파일을 읽어냈다. 이 파일 하나로 마스터키와 데이터베이스 접속 정보가 그대로 빠져나갔다. AI 인프라를 관리하는 도구 자체가 이제 공격자에게 매력적인 표적이 됐다는 뜻이다.
이번 보고서가 다룬 세 워크로드는 성격이 다르지만 공통점이 있다. LiteLLM은 여러 LLM 공급자를 하나의 API로 묶어주는 프록시 게이트웨이, RAGFlow는 검색 증강 생성(RAG) 파이프라인 도구, Kestra는 워크플로 오케스트레이션 플랫폼이다. 셋 다 API 키·DB 접속 정보·내부 서비스 접근 권한을 한곳에 모아 관리한다.
문제는 이런 도구들이 사실상 "Tier-0" 수준의 민감한 비밀 저장소 역할을 하면서도, 보안 관점에서는 일반 애플리케이션 서버 취급을 받는 경우가 많다는 점이다. 마이크로소프트는 이번 보고서에서 "AI 게이트웨이를 Tier-0 보안 저장소로 취급하라"고 명시적으로 권고했는데, 거꾸로 말하면 지금까지는 그렇지 않았다는 뜻이다.
가장 상세히 분석된 사례는 LiteLLM 게이트웨이를 겨냥한 공격이다. 마이크로소프트는 이 공격을 특정 위협 그룹에 귀속하지 않았지만, 취약점 두 개가 연계된 정황은 확인했다. 하나는 MCP stdio 테스트 엔드포인트의 인증된 명령 실행 결함(), 다른 하나는 Starlette 프레임워크의 호스트 헤더 검증 우회()다. 두 취약점을 엮으면 인증 절차 자체를 건너뛴 원격코드실행이 가능해진다.
침투 이후 흐름은 크게 여섯 단계로 나뉜다. 먼저 공격자는 컨테이너 안에서 PID 1 프로세스의 환경변수 파일을 읽어 마스터키·API 키·토큰·비밀번호를 걸러냈다. 이 데이터를 빼낼 때는 여러 전송 경로를 시도했는데, 파이썬 표준 라이브러리와 curl·wget 같은 명령줄 도구를 번갈아 사용했다. 이렇게 확보한 값 중 데이터베이스 접속 문자열(DATABASE_URL)을 파싱해 PostgreSQL 접속 정보를 얻어냈다. 이어 PostgreSQL 네이티브 확장 기능을 통해 LiteLLM 모델 설정 테이블과 인증 토큰 테이블 같은 실제 Azure PostgreSQL 테이블에 접근했다. 유출한 데이터는 Base64로 인코딩한 뒤 청크 단위로 나눠 외부로 내보냈다.
RAGFlow와 Kestra를 겨냥한 공격도 각각 네 단계로 확인됐지만, 핵심 수법은 같았다 — 워크로드가 신뢰하는 내부 자격증명을 탈취해 그 권한으로 더 깊이 들어가는 방식이다.
탈취한 자격증명을 확보한 뒤 공격자가 향한 곳은 결국 암호화폐 채굴이었다. 서비스 계정의 SSH 인가 키를 조작하고 크론 항목을 다시 써 경쟁 채굴 프로그램을 몰아냈다. 여기에 더해 리눅스 chattr +i 명령으로 파일을 변경 불가능 속성으로 만들어 관리자가 쉽게 지우지 못하게 했다.
배포된 채굴 프로그램은 XMRig v6.26.0으로, 리눅스 모델별 레지스터(MSR) 모듈까지 로드해 RandomX 알고리즘에 맞춰 CPU를 튜닝했다. 채굴 수익은 Monero 채굴 풀(auto.c3pool.org)로 흘러갔다. 마이크로소프트는 이번 침입을 특정 단일 위협 그룹에 귀속하지는 않았지만, 세 워크로드에서 공통된 기법·인프라가 관측됐다고 밝혔다.
마이크로소프트가 공개한 지표는 구체적이다.
행위 기반 지표 중 신뢰도가 높은 것은 네 가지다. 컨테이너 안 환경변수 파일에 대한 비정상 읽기 시도, PostgreSQL 네이티브 확장 로딩, 리눅스 파일 속성을 변경 불가능으로 바꾸는 시도, 그리고 예상치 못한 크론탭 재작성이다. MITRE ATT&CK 관점에서는 자격증명 접근(T1552, 환경변수·설정파일 노출)과 자원 하이재킹(T1496, 암호화폐 채굴)에 해당하는 전형적 패턴이다.
마이크로소프트는 세 가지 방어책을 권고했다. AI 게이트웨이에는 지출 한도가 걸린 가상 키를 발급하고, PostgreSQL 권한은 꼭 필요한 객체로만 제한해야 한다. 아웃바운드 트래픽도 모델 공급자만 화이트리스트에 올리는 "거부 우선" 이그레스 규칙으로 좁혀야 한다.
AI 게이트웨이·오케스트레이션 도구는 편의성을 앞세워 빠르게 도입되는 경향이 있다. 한국에서도 LiteLLM 같은 오픈소스 AI 게이트웨이나 RAG 파이프라인을 사내 AI 서비스에 접목하는 기업이 늘고 있다. 이런 도구가 API 키·DB 자격증명 같은 민감 정보를 한곳에 모아둔다는 사실 자체는 도입 단계에서 종종 간과된다.
이번 사건의 핵심 교훈은 AI 인프라 보안을 애플리케이션 보안과 분리해서 생각하면 안 된다는 점이다. 게이트웨이 하나가 뚫리면 그 뒤에 연결된 모든 모델 접근권·데이터베이스·내부 서비스가 함께 노출된다.
AI 활용 안내 이 글은 AI(Claude)의 도움을 받아 작성되었습니다. 인용된 통계와 사례는 참고 자료에 명시된 출처에 근거하며, 설명을 위한 일부 표현은 각색되었습니다.
면책 조항 본 글은 보안 인식 제고를 위한 교육 목적으로 작성되었습니다. 언급된 공격 기법을 실제로 시도하는 행위는 「정보통신망법」, 「형법」 등에 따라 처벌받을 수 있으며, 본 블로그는 이에 대한 법적 책임을 지지 않습니다.