Microsoft Threat Intelligence는 AI 운영과 관련된 세 환경을 겨냥한 공격을 폭넓게 분석한다. 대상은 LiteLLM 게이트웨이, 문서 처리 및 검색 증강 생성 기능을 위한 RAGFlow 플랫폼, 워크플로 오케스트레이션 환경인 Kestra였다. 침해 경로는 서로 달랐지만 목표는 거의 동일하게 반복되었다. 인증 자격 증명 탈취, 지속적인 접근 메커니즘 설치, 암호화폐 채굴을 위한 컴퓨팅 자원 접근이었다.
이 세 사례가 중요한 이유는 공격자들이 이러한 도구를 단순히 별개의 애플리케이션으로만 다루지 않고, 자격 증명, 모델 제공업체 연결, 명령 실행 기능, 데이터베이스 또는 컨테이너 접근 권한이 집결되는 제어 지점으로 표적 삼았기 때문이다. Microsoft에 따르면 이러한 집중성 때문에 AI 게이트웨이와 관리 및 오케스트레이션 플랫폼은 기업 환경에서 고가치 표적이 된다.
세 가지 침해 경로, 하나의 결과 패턴
LiteLLM 사례에서 Microsoft는 초기 접근이 인터넷에 노출된 게이트웨이 인터페이스의 악용을 통해 이루어졌을 가능성이 매우 높다고 판단한다. 보고서는 CVE-2026-42271을 비롯한 공개 취약점 경로를 언급한다. 이 취약점은 LiteLLM MCP stdio 테스트 엔드포인트에서 인증된 명령 실행과 관련되어 있으며, 연구 경로에서는 이를 Starlette의 호스트 헤더 검증 우회 취약점인 CVE-2026-48710과 연결한다. 영향을 받는 설정에서는 이 연결로 인해 올바른 자격 증명 없이 원격 명령 실행이 가능해질 수 있다.
침해 이후 악성 페이로드는 컨테이너 내부의 주 프로세스 환경을 읽었으며, 여기에는 /proc/1/environ도 포함되었다. 목적은 모델 제공업체 키, LiteLLM 마스터 키, 데이터베이스 연결 문자열, 비밀번호 및 토큰을 찾는 것이었다. 이후 Linux 서비스로 위장한 실행 파일이 다운로드되었고, 호스트, 포트 및 프로세스를 조사했으며, XMRig 또는 RandomX 기반 채굴을 준비했다. 또한 PostgreSQL 연결 문자열을 사용해 LiteLLM 테이블에 접근했는데, 이 테이블에는 모델 설정, 제공업체 키, 에이전트가 발급한 기본 키가 포함되어 있을 수 있다. 지속성 메커니즘으로는 서비스 계정의 authorized_keys 파일 수정, cron 작업 변경, 숨김 파일 및 위장한 서비스 이름 사용이 포함되었다.
RAGFlow의 경우 관찰된 활동은 테넌트가 추가하거나 수정하는 대규모 언어 모델 자격 증명을 가로채는 데 집중되었다. Microsoft는 먼저 SSRF 요청과 유사한 동작을 관찰한 뒤, Flask 서비스 컨텍스트 내에서 명령이 실행되고 숨겨진 후크를 로드하도록 애플리케이션 시작 경로가 수정된 것을 확인했다. 이 후크는 제공업체 유형, 모델 이름, API 키 값 및 엔드포인트 정보를 수집해 외부로 전송했다. 보고서는 실행을 유발한 취약점을 Microsoft가 높은 신뢰도로 특정하지 못했다고 강조한다. CVE-2026-45312, CVE-2026-28797, CVE-2026-24770 및 CVE-2025-68700은 가능한 기술적 맥락으로 언급된 것이며, 이 사례의 확정적인 원인으로 제시된 것은 아니다.
Kestra의 경우 Microsoft는 악용이 인증 우회를 허용할 수 있는 치명적 취약점 CVE-2026-49869와 관련되었을 가능성이 매우 높다고 판단한다. 공격자는 Process runner를 사용하는 악성 워크플로를 정의한 뒤 워커에서 셸 명령을 실행할 수 있었다. 이 경로는 Docker 소켓에 접근하고, 컨테이너 환경을 조사하며, 채굴기를 배포하고, 파일을 숨기는 작업을 실행하는 데 사용되었다. 이후 워크플로 작업을 통해 원격 스크립트를 가져와 직접 실행했으며, Kestra의 키-값 인터페이스를 이용해 암호화된 출력을 저장하기도 했다.
방어 팀에 실질적으로 달라지는 점은 무엇인가?
가장 중요한 결론은 위험 평가가 조직 내 AI 환경의 기능에서 출발해야 한다는 것이다. 게이트웨이는 모델 제공업체 키와 가상 키 데이터베이스를 보관하는 저장소일 수 있고, RAG 플랫폼에는 테넌트 설정이 포함될 수 있으며, 워크플로 엔진은 명령 실행 및 외부 서비스와의 상호작용 권한을 보유할 수 있다. 따라서 각 제품에 특화된 탐지 지표를 서로 분리해 적용하는 것만으로는 충분하지 않다.
Microsoft는 AI 게이트웨이를 최고 수준의 비밀정보 저장소로 취급하고, LiteLLM 및 유사 도구를 업데이트하며, API와 관리 인터페이스에 인증을 강제하고, 관리 포트를 제한하며, 인터넷에 직접 노출하지 말 것을 권고한다. 또한 팀별로 분리된 가상 키와 지출 한도를 사용하고, 제공업체 키를 프로세스 환경 변수 대신 관리형 비밀정보 저장소에 보관하며, 노출되었을 가능성이 있는 키를 교체할 것을 권고한다.
그 밖의 통제로는 게이트웨이와 데이터베이스에 최소 권한을 적용하고, 데이터베이스를 제한된 방화벽이 적용된 프라이빗 엔드포인트 뒤에 배치하며, 기본적으로 연결을 거부하고 필요한 엔드포인트만 허용하는 네트워크 송신 규칙을 적용하는 것이 있다. 또한 /proc/1/environ에 대한 접근, 게이트웨이 프로세스에서 shell이나 Python 또는 다운로드 도구를 실행하는 행위, cron 또는 SSH 파일 수정, Docker 소켓 사용, 쓰기가 가능한 임시 경로에서의 실행을 모니터링해야 한다.
추론의 한계와 검토 질문
세 사례가 LiteLLM, RAGFlow 또는 Kestra의 모든 배포 환경이 동일한 방식으로 노출된다는 것을 입증하는 것은 아니다. 또한 Microsoft는 일부 경로에서 확인된 취약점과 RAGFlow 사례에서 가능한 취약점을 명확히 구분한다. 일부 페이로드에 보조 도구나 생성 도구의 사용을 시사하는 특성이 존재하더라도, 이는 그 출처나 개발자의 신원을 입증하지 않는다. 따라서 이러한 결과는 탐지 가설을 세우고 설정을 검토하는 데 사용해야 하며, 특정 공격 주체에 공격을 귀속하는 근거로 사용해서는 안 된다.
Microsoft는 게이트웨이가 인터프리터나 다운로드 도구를 실행하는 행위, 주 프로세스의 환경 변수를 읽는 행위, LiteLLM 테이블에 접근하는 행위, 쓰기가 활성화된 상태에서 MSR 모듈을 로드하려는 시도, SSH 키 또는 cron을 수정하는 행위 등 행동 흐름을 탐지하기 위한 Advanced hunting 쿼리를 제공한다. 이러한 쿼리의 실질적인 가치는 이를 하나의 타임라인으로 연결할 때 나타난다. 단독으로 발생한 shell 프로세스는 관리 작업일 수 있지만, 비밀정보 읽기, 외부 연결, 임시 경로의 파일 실행이 함께 나타나면 의심 수준이 크게 높아진다.