클라우드 침해사고 분석 #5 - AWS Community AMI

hwup·2026년 4월 1일

클라우드 침해사고

목록 보기
6/10

사건 설명

보안 사고 대응 기업 Mitiga의 연구팀이 한 금융기관 인시던트 조사 중 AWS 커뮤니티 AMI에 크립토마이너 Monero(XMR)가 심어진 사실을 발견하게 된다.

해당 악성코드는 AWS Community AMI 마켓플레이스에 올라온 'Microsoft Windows Server 2008' AMI에 사전 삽입된 것으로 확인되었으며, 피해 기관은 이를 의심 없이 EC2 인스턴스 생성에 사용했다.

해당 기관은 이미 EC2에서 이 AMI 제거하여 더이상 쓰지 않고 있다고 밝혔지만, 암호화폐 채굴기는 여전히 남아있었다.


공격 흐름

AWS에서 사용할 수 있는 AMI는 크게 네 종류로 나뉜다.

유형제공 주체
AWS 소유 AMIAmazon 직접 관리
마켓플레이스 AMI검증된 파트너 벤더
Community AMI불특정 커뮤니티 사용자
Private AMI조직 내부 또는 외주 개발자

사실 이 케이스는 community ami를 아무 의심없이 사용했기 때문에 발생한 보안 사고에 속한다. visual studio code에서도 요즘 extension을 다운로드할 때 그 author을 신뢰할 수 있는지 물어보는 것처럼, 뭐든 적용할 때 이게 실제로 검증된 제공자에 의해 업로드되고 관리되고 있는 것이 맞는지 확인하는 것이 필요할 것 같다.

크립토마이너는 사실 가장 가벼운 피해에 해당하며, 공격자가 의도했다면 아래와 같은 심각한 공격도 가능했을 것이다.

  • 백도어 설치 → EC2 인프라 전체 접근 및 Lateral Movement
  • 랜섬웨어 지연 트리거 → 특정 시점에 데이터 암호화 및 협박
  • 자격증명 탈취 → IAM 키, DB 패스워드 등 민감 정보 수집
  • ec2를 기준점으로, VPC 내 다른 리소스로 침투

보안 고려 사항

AWS 공동 책임 모델의 경계

이 사건을 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 AMIVM 이미지없음

Community AMI는 수만 개가 존재하지만, 게시자 신원, 평점, 리뷰, 자동 스캔 결과 중 어느 것도 제공되지 않는다. 이것이 Mitiga가 "충분하지 않다"고 지적한 지점이다.

다만 명시적으로 AWS는 이에 대한 책임을 지지 않는다고 하고 있으므로 이에 대한 조직의 명확한 대응책, ami 검증과 지속적인 모니터링이 필요하다.

선제 대응

그럼 이런 AMI에서 비롯한 침해사고를 예방하기 위한 차원에서 어떤 것을 해야하는지 정리해보고자 한다.

1. 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 서버를 구동시킬 수 있다.

2. Golden AMI 파이프라인

Golden AMI란? EC2 인스턴스를 실행하기 위한 신뢰할 수 있는 기준선 역할을 하는 사전 구성, 테스트된 AMI를 말한다.

이렇게 ami가 안전한지 검증하고 이 테스트를 통과한 ami만을 사용하게 하는 것이다. aws에서도 golden ami 파이프라인을 구성하는 것을 권장하고 있다.

AWS EC2 Image Builder를 활용하면 이 파이프라인을 완전 자동화할 수 있다.

3. 런타임 탐지 시스템

ec2가 이미 탈취된 상태라면, 이 상황을 탐지하고 식별하기 위한 사전 시스템이 마련되어 있어야 한다. 보통 로그를 남겨 이상치가 발견되는 것 등으로 확인할 수 있을 것이다.

또한 이 사건에서 5년 간 이 크립토마이너의 활동을 눈치채지 못했는데 모니터링 체계가 잘 갖추어져 있었다면 검증되지 않은 ami를 사용하였더라도 ec2의 이상 행위를 통해 잡아낼 수 있었을 것이다.

서비스역할
GuardDuty크립토마이너, 비정상 네트워크 통신, 자격증명 탈취 탐지
InspectorEC2 인스턴스 및 컨테이너 이미지의 CVE 취약점 스캔
Security Hub보안 이벤트 통합 대시보드 및 자동 조치
CloudWatch Anomaly DetectionCPU/네트워크 사용량 이상 감지 자동 알림

4. 최소 권한 부여

EC2 자체가 탈취되었더라도 다음과 같은 조치로 추가적인 확산을 방지할 수 있다.

  • IAM Role 최소 권한: EC2 인스턴스에 필요 이상의 IAM 권한 부여 금지
  • VPC 세분화: 인스턴스별 Security Group 최소화, 불필요한 인터넷 직접 통신 차단
  • IMDSv2 강제 적용: 메타데이터 서비스 탈취를 통한 자격증명 탈취 방어
  • Private Subnet 운영: 인터넷 게이트웨이 직접 연결 최소화

참고:

profile
Level up!

0개의 댓글