정책 리스크를 파악하십시오. 정책에 대한 질문을 일상 언어로 하십시오. 데모 신청하기 →

Published:

AWS 랜섬웨어에 대해 알아야 할 사항

by FireMon

랜섬웨어가 데이터센터에서 심각한 문제이긴 하지만, 클라우드에서도 그 정도로 큰 문제인지에 대해서는 다소 회의적이었습니다. 개인적으로 관련 사고를 접한 적이 없었고, 이론적인 이야기에 가깝다고 생각하기 시작했습니다. 그런데 제 생각이 조금 틀렸습니다. 아니, 완전히 틀렸습니다. 제가 생각했던 것보다 훨씬 큰 문제일 뿐만 아니라, Amazon Web Services(AWS) 내에서의 공격 패턴도 예상과 달랐습니다.

AWS re:Inforce 콘퍼런스에서 Kyle Dickinson, Megan O’Neil, Karthik Ram이 진행한 훌륭한 세션에 참석했습니다. 자리가 꽉 차서 진행 요원이 수십 명을 돌려보낼 정도였습니다. 이 글은 해당 세션을 요약하고, 여기에 AWS 랜섬웨어에 관한 제 경험과 권고 사항을 더한 내용입니다. 오류나 누락이 있다면 이는 발표자들이 아니라 제 책임입니다.

주요 내용

  • 랜섬웨어 공격자들은 Amazon Web Services(AWS) 환경을 점점 더 표적으로 삼고 있으며, 주로 자격 증명 접근, 스토리지 구성, 서비스 전반의 가시성에서 발생하는 허점을 악용합니다.
  • Amazon S3 버킷은 흔한 진입 지점이며, 취약한 정책이나 암호화 적용 미비로 인해 공격자가 중요한 데이터를 암호화하거나 삭제합니다.
  • 클라우드에서 효과적인 랜섬웨어 방어를 위해서는 접근 제어, 실시간 모니터링, 신속한 대응 워크플로를 포함한 다층적 전략이 필요합니다.
  • FireMon은 잘못된 구성을 지속적으로 모니터링하고, 대규모로 정책을 적용하며, 팀이 클라우드 기반 랜섬웨어 위협에 더 빠르게 대응하도록 돕는 가시성을 제공함으로써 데이터 보안 태세를 강화합니다.

Amazon AWS 랜섬웨어는 실제 문제인가

그렇습니다. AWS 랜섬웨어는 제가 처음 생각했던 것보다 더 큰 문제로 드러났습니다. 실제 고객들이 피해를 입고 있으며, 단순히 이론적인 이야기가 아닙니다.

Amazon 랜섬웨어 공격은 어떻게 이루어지는가

최초 침투 경로는 다음 항목에서 다루겠지만, Amazon 랜섬웨어 공격 기법으로는 네 가지가 가능합니다.

  • 공격자가 인스턴스를 장악한 뒤(직접 침해보다는 사용자/관리자 대상 피싱인 경우가 많음) 멀웨어를 설치해 데이터를 암호화하고 접근 가능한 다른 인스턴스로 확산시킵니다. 클라우드 고유의 요소가 전혀 개입되지 않으므로 데이터센터의 랜섬웨어와 사실상 다르지 않습니다.
  • 공격자가 S3 버킷에서 데이터를 복사한 뒤 원본 데이터를 삭제합니다. 가장 흔히 관찰되는 클라우드 네이티브 Amazon 랜섬웨어입니다.
  • 공격자가 자신이 통제하는 KMS 키를 사용해 S3 데이터를 암호화합니다. 여러 요인으로 인해 실제보다는 이론에 가깝습니다. 객체나 버킷을 사후에 암호화하는 것보다 그냥 삭제하는 편이 훨씬 쉽습니다.
  • 공격자가 다른 스토리지 서비스의 데이터에 어떤 조치를 가해 데이터를 잠그거나 삭제합니다. 실제로 관찰되지 않았고, 해당 서비스 대부분이 랜섬웨어 실행을 어렵게 만드는 내부 제약과 내장 복원력을 갖추고 있기 때문에 모호하게 표현했습니다.

랜섬웨어는 AWS S3 버킷을 가장 흔하게 표적으로 삼으며, 공격자는 데이터를 복사한 뒤 삭제합니다. 인스턴스나 서버도 데이터센터 공격에 쓰이는 동일한 멀웨어의 표적이 될 수 있습니다. 실제 환경에서는 거의 관찰되지 않는 이론적 공격도 몇 가지 있습니다.

다만 새롭게 확산되고 있는 Amazon 랜섬웨어 공격이 하나 있습니다. 랜섬웨어 조직들이 고객 제공 키를 사용하는 AWS 서버 측 암호화(SSE-C)를 이용해 데이터를 제자리에서 암호화하기 시작한 것입니다. 이 기법을 사용하면 공격자는 파일을 옮기거나 일반적인 경보를 유발하지 않고도 S3 버킷 내 파일을 직접 암호화할 수 있으며, 공격자의 맞춤 암호화 키 없이는 복구가 불가능합니다.

위협 행위자는 어떻게 접근 권한을 얻어 Amazon Web Services 랜섬웨어 공격을 수행하는가

노출된 자격 증명입니다. 거의 항상 정적 액세스 키이며, 침해된 인스턴스에서(메타데이터 서비스를 통해) 획득한 키인 경우도 있습니다. 아시다시피 거의 모든 클라우드 기반 보안 공격이 이런 방식으로 이루어집니다.

S3 랜섬웨어 공격은 어떤 순서로 진행되는가

S3 버킷 랜섬웨어 시나리오가 우리가 주목해야 할 클라우드 네이티브 사례이므로 이에 집중하겠습니다.

  • 공격자가 자격 증명을 획득합니다.
  • 공격자가 해당 자격 증명으로 정찰을 수행해 허용된 API 호출을 파악하고 접근 가능한 리소스를 식별합니다.
  • 공격자가 S3 쓰기 권한과 버킷 식별을 위한 목록/읽기 권한을 보유하고 있음을 발견합니다. 공격자에게 List 권한이 없더라도 DNS, GitHub 등 다른 출처에서 버킷 이름을 얻을 수 있다는 점에 유의하십시오. 다만 그럴 가능성은 훨씬 낮습니다.
  • 공격자가 데이터를 다른 위치로 복사하거나 이동합니다. 이 위치가 반드시 AWS 내부일 필요는 없습니다.
  • 공격자가 원본 객체/파일을 삭제합니다.
  • 공격자가 협박문을 업로드하거나 이메일로 보냅니다.

최근 공격 캠페인에서는 공격자들이 S3 객체 수명 주기 관리 정책을 이용해 암호화된 파일을 7일 이내 삭제 대상으로 지정함으로써 몸값 지불을 더욱 압박하기도 합니다. 또한 영향을 받은 디렉터리에 비트코인 지갑 주소와 고유 피해자 ID가 담긴 warning.txt 파일을 남기는 경우가 많습니다.

이 모든 과정이 자동화되어 있기 때문에, 자격 증명이 노출된 지 1분 이내에 공격이 시작될 수 있습니다.

Amazon S3 랜섬웨어는 어떻게 탐지할 수 있는가

S3 랜섬웨어 예방으로 바로 넘어갈 수 없다면…

공격자는 대개 비트코인을 보낼 수 있도록 연락처가 담긴 협박문을 남기니 그 점은 편리합니다. 하지만 대부분은 그 전에 문제를 파악하고 싶어 하실 것입니다. Amazon S3 랜섬웨어 공격 순서를 따라가며 어느 지점에서 포착할 수 있는지 살펴보겠습니다.

먼저 민감한 버킷에 대해 보다 심층적인 모니터링을 활성화해야 합니다. 이 글이 이미 예상보다 길어지고 있으므로, 해당 버킷을 식별하고 관리하는 세부 사항은 생략하고 대신 고려할 만한 몇 가지 핵심 소스에 집중하겠습니다. 비용을 고려하면 모든 대상에 대해 이를 활성화하기는 어렵습니다.

  • 물론 CloudTrail입니다.
  • 중요하게 관리하는 모든 버킷에 대한 CloudTrail 데이터 이벤트. 추가 비용이 발생합니다.
  • GuardDuty.
  • 선택 사항: Security Hub. 모든 계정에 걸쳐 GuardDuty와 기타 AWS 보안 서비스를 집계하는 가장 좋은 방법입니다.
  • 선택적으로: S3 서버 액세스 로그. CloudTrail 데이터 이벤트가 있다면 필요한 정보 대부분을 얻을 수 있습니다. 다만 S3 로그는 생성 자체는 무료이며(스토리지 비용만 지불) CloudTrail이 놓칠 수 있는 일부 이벤트(예: 인증 실패)를 포착합니다. 반면 확인까지 몇 시간이 걸리므로 실시간 대응 상황에서는 유용하지 않습니다. 자세한 내용은 이 사용자 가이드를 참고하십시오.

모니터링을 살펴봤으니, 이제 탐지 과정의 7단계를 알아보겠습니다.

1. 노출된 자격 증명과 정찰 활동 탐지

탐지 과정은 공개적으로 노출되었거나 침해된 AWS 키, 그리고 의심스러운 활동을 자체적으로 또는 제3자를 통해 식별하는 데서 시작됩니다. 보통 GitHub 같은 일반 저장소를 스캔해 확인합니다. Amazon Web Services가 한번은 제 키를 발견하고 이메일을 보낸 적이 있습니다. 실수였죠.

이 단계에서는 계정 자격 증명 정찰 탐지가 효과를 발휘합니다. 몇 가지 방법은 다음과 같습니다.

  • 자격 증명 유출 등 GuardDuty 탐지 결과. 다만 약 20분의 지연이 있으며, 우회 기법도 존재합니다
  • GetCallerIdentity API 호출이 항상 악의적인 것은 아니지만, 프로덕션 계정에서 자주 관찰될 만한 호출은 아닙니다
  • GetAccountAuthorizationDetails는 발생할 때마다 경보를 발생시켜야 합니다
  • 단일 IAM 엔터티에서 발생한 다수의 실패한 API 호출

2. S3 열거 행위 감시

이제 공격자가 S3에 집중하고 있음을 보여주는 AWS 랜섬웨어 탐지에 초점을 맞추겠습니다. 노이즈로 인해 이 단계에서의 조기 탐지가 어려울 수 있다는 점을 느끼셨을 텐데, 사람의 접근이 제한된 CI/CD 기반 관리 프로덕션 계정과 같은 환경에서는 이러한 탐지가 더 실효성을 갖는다는 점을 기억하십시오. 이것이 클라우드 네이티브 패턴을 더 적극적으로 채택할 동기가 될 수도 있습니다.

Discovery 이벤트에 대한 GuardDuty S3 탐지 결과는 계정과 조직 구성 방식에 따라 GuardDuty를 켜는 것만으로는 부족하고 별도로 활성화해야 합니다. S3 서비스에서 실패한 Read 및 List 관리 이벤트와 데이터 이벤트를 필터링하십시오. 이를 통해 주변을 살피는 공격자를 포착할 수 있습니다. SIEM에서 수행할 수도 있지만, 이를 위한 CloudWatch 지표 필터를 구성하는 것도 간단합니다.

3. 객체 읽기 및 복사 모니터링

여기서는 지속적으로 모니터링하여 공격자가 객체를 읽고 복사본을 만들고 있는지 확인하십시오. 공격자가 각 객체를 읽은(복사한) 뒤 삭제한다면, 이는 다음 단계와 맞물릴 수 있습니다.

4. 대량 삭제 및 랜섬 노트 배치 탐지

이 단계가 바로 “아차” 하는 순간입니다. 공격자는 단순히 둘러보는 것이 아니라 공격을 실행하고 복사한 데이터를 삭제합니다. GuardDuty의 유출/영향 관련 S3 findings가 작동하기 시작합니다. 다만 트리거되기까지 최소 20분이 걸리며, 객체 수에 따라 뒤늦은 지표가 될 수 있다는 점을 기억하십시오. CloudTrail Insights를 사용한다면 데이터 이동에 사용된 다수의 Write 이벤트에 대해 알림을 제공합니다.

다수의 삭제 호출에 대해 자체 탐지 규칙을 구축할 수도 있습니다. 환경과 평소 활동 패턴에 따라 이 기준값은 낮게 설정될 수 있으며 GuardDuty보다 빠르게 트리거될 수 있습니다. SIEM과 CloudWatch Metrics Filters가 좋은 선택지입니다.

5. SSE-C 악용(무음 암호화) 식별

PutObject와 같은 API 호출에서 SSE-C 헤더가 갑자기 적용되는지 모니터링하십시오. 이는 공격자의 키로 데이터가 암호화되고 있다는 신호일 수 있습니다. AWS는 작업의 HMAC 해시만 기록하므로, 사전 모니터링 없이는 일반적인 포렌식 복구가 불가능합니다.

6. 카나리 버킷 및 KMS 탐지 활용

성숙한 조직은 계정에 카나리 버킷/객체를 배치하고 해당 버킷에 접근하는 모든 작업에 대해 알림을 설정할 수 있습니다. 비교적 드문 공격 패턴이기는 하지만, 계정 외부에서 KMS 키가 사용되는 경우에도 알림을 보낼 수 있습니다.

7. 에스컬레이션 및 인시던트 대응

이 단계에서 공격을 탐지했다면 이미 침해된 상태입니다. 대응해야 할 시점입니다. 사법 기관에 연락하고 AWS 고객 인시던트 대응 팀을 참여시키십시오.

AWS 랜섬웨어 방어: 기업을 안전하게 지키는 방법

AWS 랜섬웨어 공격을 성공시키려면 공격자에게 다음 세 가지 조건이 필요합니다:

랜섬웨어 예방의 첫 번째 계층은 IAM을 잠그고, 이어서 AWS의 내장 도구를 활용해 복원력을 확보하는 것입니다. 말하기는 쉽고 실행하기는 어렵지만, 여기 S3에 초점을 맞춘 체크리스트를 제시합니다. 일반적인 위생 관리/통제 항목은 대부분 제외하겠습니다:

  • 정적 액세스 키를 가진 IAM 사용자는 아예 허용하지 마십시오. 그것이 불가능하다면, 보유한 도구를 활용해 S3 삭제 권한이 있는 사용자를 반드시 식별하십시오.
  • SSO/페더레이션 사용자에게 MFA를 요구하십시오. 항상, 예외 없이 적용하십시오.
  • 관리자가 삭제 작업을 수행해야 할 때는 별도의 IAM 역할로 권한을 승격하도록 하십시오. 읽기 권한과 삭제 권한을 완전히 별개의 역할로 분리할 수도 있습니다.
  • 인스턴스가 S3에 접근해야 한다면, 최소한의 리소스에 대한 최소한의 필수 API 호출로 권한 범위를 최대한 좁게 설정하십시오.
  • 반드시 필요한 경우가 아니라면 SSE-C를 비활성화하십시오. 이는 복구 경로 없이 데이터에 대한 접근을 차단해 버리는 무음 암호화 공격을 예방하는 데 도움이 됩니다.
  • VPC 엔드포인트를 사용해 버킷에 접근하고, 소스 VPC에서만 삭제를 허용하는 리소스 정책을 함께 적용하십시오. 그러면 공격자는 해당 VPC 외부에서 자격 증명을 사용할 수 없습니다.
  • 버전 관리, AWS Backup, 버킷 복제 중 일부 또는 전부를 활성화하십시오. 이 모든 기능은 데이터에 대한 접근을 잃지 않도록 보장합니다. 물론 IAM 정책을 정말로 엉망으로 만들어 공격자가 마음대로 하도록 두지 않는 한 그렇습니다. 이 중 일부는 버킷 생성 시점에 활성화해야 하므로, 마이그레이션 작업이 필요할 수도 있습니다.

Block Public Access를 건너뛰었다는 점을 눈치채셨을 것입니다. 훌륭한 기능이지만, 많은 조직이 일부 공개 버킷을 필요로 하기 때문에 대규모로 구현하는 데 어려움을 겪으며, 노출된 자격 증명을 이용한 공격에는 도움이 되지 않습니다.

이 모든 작업에는 노력과 비용이 따르므로, 처음에는 정말 중요한 버킷에 집중하실 것을 권장합니다. 특히 대규모 환경을 운영하는 경우 더 발전된 전략들이 있지만 한 편의 글에 담기는 어렵습니다. 관련해 논의하고 싶으시다면 연락 주십시오.

Re:Inforce 세션에서 S3 랜섬웨어에 대해 새롭게 알게 된 점은 무엇입니까

저는 S3 랜섬웨어가 그렇게 흔한지 몰랐습니다. 또한 복사 후 삭제가 선호되는 공격 기법이라는 점도 몰랐습니다. KMS 암호화를 사용하는 것이라고 생각했는데, 그 방식이 왜 더 이론적이고 드문지 충분히 납득이 갑니다. 탐지 방법과 방어책 자체는 익숙했지만, AWS 발표자들이 이를 매우 명확하고 실용적으로 엮어낸 점이 훌륭했습니다. 이 발표는 확실히 제 기대를 뛰어넘었습니다.

FireMon은 S3 랜섬웨어 방어에서 기업을 어떻게 지원합니까

곧 출시될 예정인 Just in Time 권한을 위한 새로운 IAM 제품이 베타 단계에 있습니다. 또한 DisruptOps에서 위험한 버킷을 식별하고 랜섬웨어 공격과 같은 악성 활동에 대해 알림을 제공하는 태세 점검 및 위협 탐지 기능을 제공합니다. 이에 대해 논의하고 싶으시거나, 이 글에서 언급한 AWS 옵션에 대한 일반적인 조언이 필요하시다면 연락 주십시오.

지금 데모를 신청하시고, FireMon이 AWS 랜섬웨어로부터 기업을 어떻게 보호하는지 확인해 보십시오.

AWS 랜섬웨어에 대해 알아야 할 사항 | FireMon