보안 사고 대응 기업 Mitiga의 연구팀이 한 금융기관 인시던트 조사 중 AWS 커뮤니티 AMI에 크립토마이너 Monero(XMR)가 심어진 사실을 발견하게 된다.
해당 악성코드는 AWS Community AMI 마켓플레이스에 올라온 'Microsoft Windows Server 2008' AMI에 사전 삽입된 것으로 확인되었으며, 피해 기관은 이를 의심 없이 EC2 인스턴스 생성에 사용했다.
해당 기관은 이미 EC2에서 이 AMI 제거하여 더이상 쓰지 않고 있다고 밝혔지만, 암호화폐 채굴기는 여전히 남아있었다.

AWS에서 사용할 수 있는 AMI는 크게 네 종류로 나뉜다.
| 유형 | 제공 주체 |
|---|---|
| AWS 소유 AMI | Amazon 직접 관리 |
| 마켓플레이스 AMI | 검증된 파트너 벤더 |
| Community AMI | 불특정 커뮤니티 사용자 |
| Private AMI | 조직 내부 또는 외주 개발자 |
사실 이 케이스는 community ami를 아무 의심없이 사용했기 때문에 발생한 보안 사고에 속한다. visual studio code에서도 요즘 extension을 다운로드할 때 그 author을 신뢰할 수 있는지 물어보는 것처럼, 뭐든 적용할 때 이게 실제로 검증된 제공자에 의해 업로드되고 관리되고 있는 것이 맞는지 확인하는 것이 필요할 것 같다.
크립토마이너는 사실 가장 가벼운 피해에 해당하며, 공격자가 의도했다면 아래와 같은 심각한 공격도 가능했을 것이다.
이 사건을 AWS가 책임져야 할까? community ami라도 aws가 제공하는 이미지에서 비롯된 취약점이니 이것을 누구의 책임으로 나누어야할지 논쟁의 여지가 있었다고 한다.
AWS는 이에 대해 다음과 같이 밝히고 있다.
You use a shared AMI at your own risk. Amazon can't vouch for the integrity or security of AMIs shared by other Amazon EC2 users. Understand shared AMI usage in Amazon EC2
따라서 이런 community ami를 사용함으로써 발생하는 문제에 대한 책임은 사용자에게 있다. 그러나 이런 문제에 대해 AWS가 아닌 다른 공개 플랫폼들이 유사한 문제를 어떻게 다루는지 보면 차이가 명확하다.
| 플랫폼 | 콘텐츠 유형 | 안전장치 |
|---|---|---|
| GitHub | 오픈소스 코드 | 자동 취약점 스캔, 사용자 신고, 스타·포크 기반 평판 |
| Docker Hub | 컨테이너 이미지 | Official Image 인증, 스캔 결과 공개, 다운로드 수·평점PyPI / npm패키지악성코드 자동 탐지, 사용자 신고 시스템, 다운로드 통계 |
| AWS Community AMI | VM 이미지 | 없음 |
Community AMI는 수만 개가 존재하지만, 게시자 신원, 평점, 리뷰, 자동 스캔 결과 중 어느 것도 제공되지 않는다. 이것이 Mitiga가 "충분하지 않다"고 지적한 지점이다.
다만 명시적으로 AWS는 이에 대한 책임을 지지 않는다고 하고 있으므로 이에 대한 조직의 명확한 대응책, ami 검증과 지속적인 모니터링이 필요하다.
그럼 이런 AMI에서 비롯한 침해사고를 예방하기 위한 차원에서 어떤 것을 해야하는지 정리해보고자 한다.
SCP를 활용하여 허용된 AMI만 사용 가능하도록 강제할 수 있을 것이다.
{
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:image/*",
"Condition": {
"StringNotEquals": {
"ec2:Owner": [
"amazon",
"aws-marketplace",
"YOUR_TRUSTED_ACCOUNT_ID"
]
}
}
}
이 룰을 통해 검증된 소유자가 올린 ami를 사용해야만 ec2 서버를 구동시킬 수 있다.
Golden AMI란? EC2 인스턴스를 실행하기 위한 신뢰할 수 있는 기준선 역할을 하는 사전 구성, 테스트된 AMI를 말한다.

이렇게 ami가 안전한지 검증하고 이 테스트를 통과한 ami만을 사용하게 하는 것이다. aws에서도 golden ami 파이프라인을 구성하는 것을 권장하고 있다.
AWS EC2 Image Builder를 활용하면 이 파이프라인을 완전 자동화할 수 있다.
ec2가 이미 탈취된 상태라면, 이 상황을 탐지하고 식별하기 위한 사전 시스템이 마련되어 있어야 한다. 보통 로그를 남겨 이상치가 발견되는 것 등으로 확인할 수 있을 것이다.
또한 이 사건에서 5년 간 이 크립토마이너의 활동을 눈치채지 못했는데 모니터링 체계가 잘 갖추어져 있었다면 검증되지 않은 ami를 사용하였더라도 ec2의 이상 행위를 통해 잡아낼 수 있었을 것이다.
| 서비스 | 역할 |
|---|---|
| GuardDuty | 크립토마이너, 비정상 네트워크 통신, 자격증명 탈취 탐지 |
| Inspector | EC2 인스턴스 및 컨테이너 이미지의 CVE 취약점 스캔 |
| Security Hub | 보안 이벤트 통합 대시보드 및 자동 조치 |
| CloudWatch Anomaly Detection | CPU/네트워크 사용량 이상 감지 자동 알림 |
EC2 자체가 탈취되었더라도 다음과 같은 조치로 추가적인 확산을 방지할 수 있다.
참고: