MITRE ATT&CK: T1059.013 (Container(컨테이너) CLI/API) | 전술: Execution | 플랫폼: Containers
도입: 왜 이 공격이 중요한가
2022년 TeamTNT 그룹이 AWS와 알리바바 클라우드를 대상으로 한 공격에서 가장 주목받은 것은 컨테이너 CLI 도구를 악용한 방식이었습니다. 이들은 Docker와 Kubernetes 명령어를 마치 정상적인 관리자처럼 사용하여 시스템을 장악했고, 보안팀은 이를 정상적인 관리 작업으로 오인했습니다.
Container CLI/API 공격은 Docker CLI, Kubernetes API, 또는 관련 SDK를 악용하여 컨테이너 환경에서 악성 명령을 실행하는 기법입니다. 공격자는 정상적인 관리 도구를 사용하기 때문에 탐지가 매우 어렵습니다.
💡 쉬운 비유: 마치 가짜 관리자가 진짜 마스터키를 사용해 건물을 돌아다니는 것과 같습니다. 도구 자체는 정상이지만 사용하는 사람의 의도가 악의적입니다.
1. 공격자 관점
왜 이 기법을 사용하는가
- 정상 도구 악용: Docker CLI나 kubectl 같은 정상적인 관리 도구를 사용하므로 보안 솔루션이 악성 활동으로 인식하지 못함
- 강력한 권한: 컨테이너 관리 도구는 시스템 전체에 대한 광범위한 접근 권한을 제공
- 은밀성: 일반적인 관리 작업과 구분하기 어려워 오랜 기간 발각되지 않음
동작 흐름
공격자는 먼저 노출된 Docker API나 잘못 구성된 Kubernetes 클러스터를 찾습니다. 접근 권한을 얻으면 docker exec로 실행 중인 컨테이너에 침투하거나, kubectl을 사용해 새로운 Pod을 생성합니다. 그 후 docker ps나 kubectl get pods 같은 명령으로 환경을 정찰하고, 악성 이미지를 배포하여 지속적인 접근을 확보합니다.
2. 실제 공격 사례
📌 TeamTNT - AWS/알리바바 클라우드 공격 (2022년)
배경: TeamTNT는 잘못 구성된 컨테이너 환경을 표적으로 삼는 사이버 범죄 그룹으로, 주로 암호화폐 채굴을 목적으로 AWS와 알리바바 클라우드 인프라를 공격했습니다.
공격 과정:
- 초기 침투: 노출된 Docker API 엔드포인트나 잘못 구성된 Kubernetes 클러스터를 스캔하여 접근점 확보
- 컨테이너 CLI 악용:
docker exec명령으로 실행 중인 컨테이너에 침투하고,kubectl명령으로 모든 Kubernetes Pod에 배포하여 측면 이동 수행 - 지속성 확보: 정상적인 컨테이너 관리 명령을 사용하여 크립토마이닝 소프트웨어를 설치하고, 알리바바의 aegis 클라우드 보안 에이전트를 비활성화
피해 규모: 수백 개의 클라우드 인스턴스가 암호화폐 채굴에 악용되었으며, 피해 기업들은 막대한 클라우드 사용료를 지불해야 했습니다.
출처: TeamTNT Targeting AWS, Alibaba
3. 왜 탐지가 어려운가?
공식 탐지 방법
[DET0083] Container CLI and API Abuse via Docker/Kubernetes (T1059.013) - AN0233: 승인되지 않은 호스트나 비표준 사용자 컨텍스트에서 컨테이너 오케스트레이션 명령(예: docker exec, kubectl exec) 실행 또는 실행 중인 컨테이너와의 API 기반 상호작용을 탐지합니다. 방어자는 예상되는 CI/CD 도구나 자동화 프레임워크 외부에서 컨테이너 내 프로그래밍 방식 또는 대화형 명령 실행을 확인할 수 있으며, 이는 종종 파일 쓰기, 권한 상승 또는 측면 정찰 활동이 뒤따릅니다.
공격자가 이 기법을 선호하는 이유
- 정상 도구의 오남용: Docker CLI나 kubectl은 정상적인 관리 도구이므로 보안 솔루션이 기본적으로 차단하지 않음
- 높은 권한: 컨테이너 관리 도구는 시스템 전체에 대한 광범위한 접근 권한을 제공하여 한 번의 침투로 큰 피해 가능
- 로그 혼재: 정상적인 관리 작업과 악성 활동이 같은 로그에 기록되어 구분이 어려움
탐지의 현실적 한계
컨테이너 환경에서는 수많은 자동화 도구와 CI/CD 파이프라인이 지속적으로 컨테이너 CLI를 사용합니다. 이로 인해 정상적인 활동과 악성 활동을 구분하는 것이 매우 어렵고, 오탐률이 높아 실무에서는 많은 알림을 무시하게 됩니다. 또한 컨테이너 환경의 동적 특성상 로그 분석을 위한 충분한 컨텍스트 정보를 수집하기 어렵습니다.
4. 나도 위험할까? 자가 진단
이 공격이 나와 관련 있는지 확인해보세요.
이런 환경이라면 주의가 필요합니다
- Docker API가 인터넷에 노출되어 있거나 인증 없이 접근 가능한 환경
- Kubernetes 클러스터에서 과도한 권한을 가진 서비스 계정이나 사용자가 존재
- 컨테이너 이미지를 공개 레지스트리에서 검증 없이 다운로드하여 사용
- 클라우드 환경에서 기본 보안 설정을 변경하지 않고 컨테이너 서비스를 운영
공식 대응 방안
[M1038] Execution Prevention (실행 방지): 적절한 곳에서 스크립팅을 거부합니다. Python이나 Go 같은 도구들은 클라이언트 라이브러리 내에서 Kubernetes와 Docker를 활용하고 애플리케이션 내에서 명령을 실행할 수 있습니다.
[M1026] Privileged Account Management (특권 계정 관리): API 접근에 대한 권한을 제한합니다. Kubernetes의 RBAC는 부가적인 권한을 포함하며, 명시적인 "거부" 규칙이 없습니다. 이러한 권한은 특정 네임스페이스 내에서나 클러스터 범위 리소스 내에서 정의될 수 있습니다. Docker 데몬 보안은 인증서 인증과 함께 SSH나 TLS를 사용하여 수행할 수 있습니다. Docker나 Podman 같은 컨테이너 관리 도구는 컨테이너를 rootless로 실행하는 방법을 제공하여 특권 권한으로 실행되는 것을 방지할 수 있습니다.
당장 할 수 있는 것
- 개인 PC에서 Docker Desktop을 사용할 때 불필요한 컨테이너는 삭제하기
- 컨테이너 관련 이상한 네트워크 활동 발견 시 전문가에게 문의하기
- 🏢 보안 담당자: Docker API를 TLS로 보호하고, Kubernetes RBAC 정책을 최소 권한 원칙으로 설정하기
5. 관련 기술
| 기법 | 어떤 상황에서 함께 사용되나 |
|---|---|
| T1610 Deploy Container | 컨테이너 CLI로 악성 이미지를 pull한 후, 새로운 컨테이너를 배포하여 공격 기반을 확장할 때 |
| T1613 Container and Resource Discovery | docker ps나 kubectl get pods로 실행 중인 컨테이너를 발견한 후, 추가 정찰을 수행할 때 |
| T1609 Container Administration Command | 컨테이너에 침투한 후, docker exec나 kubectl exec로 관리 명령을 실행하여 시스템을 조작할 때 |
참고 자료
📌 이 글은 AI(Claude) 를 활용하여 작성되었으며, MITRE ATT&CK v18.0 기준 (2025-10-28) 을 기준으로 합니다. 본 콘텐츠는 보안 교육 및 방어 목적으로만 제공되며, 이를 악용한 불법 행위에 대한 책임은 전적으로 행위자 본인에게 있습니다.
?뱛 ??湲? [?ㅽ겕由쏀듃 ?ㅽ뻾(T1059) ?쒕━利?(/blog/t1059-command-and-scripting-interpreter)???쇰??낅땲??
COMMENTS (0)
댓글은 익명으로 작성되며, 삭제 비밀번호를 설정하면 본인만 삭제할 수 있습니다. 비밀번호를 설정하지 않은 댓글은 누구나 삭제할 수 있습니다.