egkritsis/cve-2025-61301CVE-2025-61301 개념 증명으로, 재귀적 프로세스 포크를 통해 CAPEv2에서 분석 거부(denial-of-analysis)를 유발하며, MongoDB BSON 한도 및 orjson 직렬화 오류를 트리거하여 불완전한 악성코드 동작 보고서를 초래합니다.
CAPEv2(커밋 52e4b43, 2025-05-17)의 reporting/mongodb.py 및 reporting/jsondump.py에 영향을 미치는 고위험(High-Severity) 분석 거부(Denial-of-analysis) 취약점으로, 샘플을 제출할 수 있는 공격자가 샌드박스에서 샘플이 실행될 때 MongoDB BSON 한도 또는 orjson 재귀 오류를 트리거하는 심층 중첩 또는 과대한 동작 데이터를 생성하여 불완전하거나 누락된 동작 분석 보고서를 유발할 수 있습니다.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H이 취약점의 근본 원인은 동적 악성코드 분석 중 생성되는 크고 깊이 중첩된 동작 보고서를 CAPEv2가 처리하는 방식에 있습니다.
MongoDB BSON 문서 크기 한도:
CAPEv2는 16MB BSON 문서 크기 한도[1]가 있는 MongoDB를 사용하여 분석 보고서를 저장합니다.
보고서가 이 크기를 초과하면(대개 방대한 프로세스 트리, API 호출 또는 재귀 데이터로 인해) 데이터베이스가 삽입을 거부하여 보고서 생성이 실패합니다.
MongoDB 중첩 깊이 한도:
MongoDB는 또한 BSON 문서당 최대 100단계 중첩 깊이를 적용합니다.
재귀적 악성코드 동작은 이 한도를 쉽게 초과할 수 있으며, 문서 크기가 16MB 미만인 경우에도 삽입 실패로 이어집니다.
Python JSON 직렬화 한도:
CAPEv2는 결과를 JSON으로 직렬화하기 위해 Python의 orjson 라이브러리에 의존합니다.
깊게 중첩되거나 재귀적인 구조는 직렬화기가 Python의 재귀 한도에 도달하게 하여 직렬화 실패와 보고서 생성 중단을 초래합니다 [2].
가지치기 및 오류 처리:
CAPEv2는 보고서의 큰 부분을 점진적으로 가지치기(자식 노드 또는 전체 프로세스 하위 트리 제거)하여 이러한 문제를 완화하려고 시도합니다.
그러나 동작 복잡성이 가지치기 임계값을 초과하면 이는 충분하지 않으며, 보고서 저장 실패가 반복됩니다.
이것은 CAPEv2의 분석 거부 취약점으로, 동적 분석 엔진이 동작 활동을 캡처하거나 보고하지 못하게 할 수 있습니다. 악용 시 공격자는 동작 탐지를 우회하고 불완전하거나 누락된 분석 보고서를 생성할 수 있습니다.
트라이지(triage) 또는 위협 인텔리전스 강화를 위해 CAPEv2에 의존하는 파이프라인에서 이 결함은 다음을 초래할 수 있습니다:
CAPEv2 — 저장소: https://github.com/kevoreilly/CAPEv2
관련 커밋 / 빌드 정보
52e4b43a2cb508d3483819042cf8e4d8348f3a05[email protected])masterenzok/updates-01다음 표는 여러 분석 작업의 증거를 보여 주며, 복잡성과 지속 시간이 증가함에 따라 MongoDB 및 직렬화 실패가 발생하여 불완전하거나 누락된 동작 보고서가 생성되는 방식을 보여줍니다.
| 시간 제한(초) | 사용자 정의 설정 | 지속 시간(초) | 기록된 프로세스 수 | BSON 로그(파일 / 크기) | Report.json 크기(KB) | 오류 / 경고 | 동작 상태 |
|---|---|---|---|---|---|---|---|
| 60 | enforce-timeout | 413 | 24 | 25 / 126 KB | 613 | – | 동작 정상 |
| 60 | – | 252 | 38 | 39 / 200 KB | 923 | – | 동작 정상 |
| 60 | full-proc-memory-dumps, import-reconstruction-proc-dumps, enforce-timeout, syscall | 230 | 42 | 43 / 230 KB | 1054 | – | 동작 정상 |
| 100 | full-proc-memory-dumps, import-reconstruction-proc-dumps, enforce-timeout, syscall | 330 | 61 | 62 / 318 KB | 1482 | – | 동작 정상 |
| 100 | – | 277 | 81 | 82 / 493 KB | 2032 | – | 동작 정상 |
| 120 | full-proc-memory-dumps, import-reconstruction-proc-dumps, enforce-timeout, syscall | 340 | 72 | 73 / 383 KB | 1793 | – | 동작 정상 |
| 120 | – | – | 88 | 89 / 475 KB | 2228 | – | 동작 정상 |
| 180 | full-proc-memory-dumps, import-reconstruction-proc-dumps, enforce-timeout, syscall | 414 | 90 | 91 / 492 KB | 2356 | MongoDB Code 15 | 동작 없음 |
| 180 | – | 323 | 88 | 89 / 475 KB | 2228 | – | 동작 정상 |
| 200 | – | 413 | 119 | 120 / 645 KB | 3174 | MongoDB Code 15 | 동작 없음 |
| 200 | full-proc-memory-dumps, import-reconstruction-proc-dumps, enforce-timeout | – | – | 144 / 726 KB | – | 재귀 한도 도달, MongoDB Code 15 | 보고 실패 |
| 300 | – | 513 | 146 | 147 / 779 KB | 3676 | MongoDB Code 15 | 동작 없음 |
| 300 | full-proc-memory-dumps, import-reconstruction-proc-dumps, enforce-timeout, syscall | – | – | 167 / 892 KB | – | 재귀 한도 도달, MongoDB Code 15 | 보고 실패 |
표 1: 작업 복잡성, 보고서 크기 및 실패 조건 간의 상관관계를 보여주는 CAPEv2 분석 결과
5,000개의 프로세스를 생성하고 런타임에 다중 라운드 XOR 복호화를 수행하여 실제적인 우회를 에뮬레이션합니다. 맞춤형 빌드(다른 재귀 라운드, 키 길이 또는 프로세스 규모)가 필요한 경우 작성자에게 맞춤 버전을 문의하십시오.
데모 실행:
poc\vathos_demo.exe <IP> <PORT>
연결 시도를 관찰하려면 지정된 IP/PORT에서 리스너(예: nc, ncat, Metasploit 또는 모든 C2 리스너)가 실행 중인지 확인하십시오. 정상적으로 작동하는 샌드박스에서는 연결 시도가 표시되지만, 설명된 분석 거부 조건에서는 해당 연결이 CAPEv2 보고서에 나타나지 않을 수 있습니다.
180+초변경할 옵션:
full-proc-memory-dumps 사용 / 미사용import-reconstruction-proc-dumps 사용 / 미사용store_compressed = yes 및 store_compressed = no이 테스트에서는 MongoDB와 orjson이 기본 한도를 사용하고 있는지 확인하십시오.
프로세스 트리의 깊이와 복잡성이 증가함에 따라 다음과 같은 보고 실패가 발생할 수 있습니다:
orjson 재귀 한도 도달CAPEv2는 다음을 수행할 수 있습니다:
그림 1 - 백엔드 로그는 JSON 덤프 경고, orjson/직렬화 오류 및 MongoDB OperationFailure 항목을 보여줍니다.
그림 2 - 대시보드: failed_analysis
그림 3 - 동작 탭: "죄송합니다! 동작이 없습니다."
