서문

Elastic과 함께하는 AWS 탐지 엔지니어링 시리즈의 새로운 아티클을 소개합니다. 여기에서 STS AssumeRoot를 다룬 이전 편을 읽어 보실 수 있습니다.

이번 아티클에서는 위협 행위자가 랜섬/갈취 작업을 위해 Amazon S3의 고객 제공 키를 사용한 서버 측 암호화(SSE-C)를 활용하는 방법을 살펴봅니다. 이 최신 악용 전술은 공격자가 금전적 목표를 달성하기 위해 네이티브 클라우드 서비스를 창의적으로 악용할 수 있는 방법을 보여줍니다.

이 글을 읽고 계신 여러분은 S3, SSE-C 워크플로, 버킷 구성의 내부 작동 방식에 관한 인사이트를 얻을 수 있습니다. 당사는 이 기술의 단계들을 차례로 설명하고, S3 버킷 보안을 위한 모범 사례를 논의하며, 사용자 환경에서 SSE-C 악용을 탐지할 수 있도록 탐지 로직을 작성하는 데 도움이 되는 실행 가능한 지침을 제공합니다.

이 연구는 Halcyon 연구팀의 최근 발표를 기반으로 합니다. 이 발표에서는 랜섬웨어 활동을 위해 SSE-C를 악용한 최초로 공개적으로 알려진 ItW(in-the-wild, 실제 환경에서 발생한 공격) 사례를 문서화하였습니다. 이 새로운 위협에 대해 자세히 알아보고 적보다 한발 앞서 대응하는 방법을 알아보세요.

이 블로그에서 참조한 Terraform 코드와 에뮬레이션 스크립트를 포함한 gist를 게시하였습니다. 이 콘텐츠는 교육 및 연구 목적으로만 제공됩니다. 관련 법률 및 지침에 따라 책임감 있게 사용하시기 바랍니다. Elastic은 의도하지 않은 결과나 오용에 대해 어떠한 책임을 지지 않습니다.

즐겁게 읽어 보세요!

AWS S3 이해하기: 핵심 보안 개념 및 기능

에뮬레이션과 이러한 전술, 기술, 절차(TTP)에 대해 본격적으로 알아보기에 앞서, AWS S3에 포함된 내용을 간략히 살펴보겠습니다.

S3는 사용자가 모든 비정형 또는 정형 데이터를 '버킷'에 저장할 수 있는 AWS의 공통 저장 서비스입니다. 이 버킷은 컴퓨터 시스템에서 로컬로 찾을 수 있는 폴더와 유사합니다. 이 버킷에 저장된 데이터를 객체라고 하며, 각 객체는 파일 이름처럼 작동하는 객체 키로 고유하게 식별됩니다. S3는 JSON부터 미디어 파일 등에 이르는 여러 데이터 형식을 지원하므로, 조직의 다양한 사용 사례에 이상적입니다.

버킷은 다양한 AWS S3 서비스의 객체를 저장하도록 설정할 수 있지만, 사용 사례에 따라 수동으로 또는 프로그래밍 방식으로 채울 수도 있습니다. 또한 버킷은 버전 관리를 활용하여 여러 버전의 객체를 유지 관리할 수 있어, 실수로 삭제하거나 덮어쓴 경우에도 복원이 가능합니다. 그러나 버전 관리가 항상 기본적으로 활성화되어 않아, 랜섬웨어나 대량 삭제와 같은 특정 공격 유형에 데이터가 취약해질 수 있습니다. 버킷은 다양한 AWS S3 서비스의 객체를 저장하도록 설정할 수 있지만, 사용 사례에 따라 수동으로 또는 프로그래밍 방식으로 채울 수도 있습니다. 또한 버킷은 버전 관리를 활용하여 여러 버전의 객체를 유지 관리할 수 있어, 실수로 삭제하거나 덮어쓴 경우에도 복원이 가능합니다. 그러나 버전 관리가 항상 기본적으로 활성화되어 않아, 랜섬웨어나 대량 삭제와 같은 특정 공격 유형에 데이터가 취약해질 수 있습니다.

이러한 버킷에 대한 액세스는 일반적으로 생성 시 정의되는 액세스 정책에 따라 크게 달라집니다. 이러한 정책에는 버킷 콘텐츠의 의도치 않은 노출을 방지하도록 공개 액세스를 비활성화하는 등의 설정이 포함되어 있습니다. 그런데 구성은 여기서 끝나지 않습니다. 버킷에는 고유한 Amazon 리소스 이름(ARN)이 있어, ID 및 액세스 관리(IAM)역할이나 정책을 통해 더욱 세분화된 액세스 정책을 정의할 수 있습니다. 예를 들어 'Alice'라는 사용자가 버킷과 해당 개체에 액세스해야 하는 경우, s3:GetObject와 같은 특정 권한을 해당 IAM 역할에 할당해야 합니다. 이 역할은 권한 정책으로 Alice에게 직접 적용하거나 관련 소속 그룹에 적용할 수 있습니다.

이러한 메커니즘은 잘못될 염려가 없어 보이지만, 액세스 제어의 잘못된 구성(예: 지나치게 허용적인 버킷 정책 또는 액세스 제어 목록)은 보안 인시던트의 일반적인 원인입니다. 예를 들어, 이 글을 쓰는 현재 buckets.grayhatwarfare.com에 따르면 약 32만 5천 8백 개의 버킷이 공개되어 있습니다. Elastic Security Labs는 또한 2024년 Elastic 글로벌 위협 보고서에서 실패한 AWS 태세 점검 중 30%가 S3와 관련이 있다고 밝혔습니다.

S3의 서버 측 암호화
S3은 저장 데이터 보안을 위해 여러 암호화 옵션을 제공합니다. 여기에는 다음이 포함됩니다.

• SSE-S3: 암호화 키는 AWS에서 완전히 관리됩니다.
• SSE-KMS: 키는 AWS Key Management Service(KMS)를 통해 관리되며, 더 많은 사용자 지정 키 정책 및 액세스 제어가 가능합니다. 이러한 기능이 Elastic에서 어떻게 구현되는지 확인하세요.
• SSE-C: 고객이 추가 제어를 위해 자체 암호화 키를 제공합니다. 이 옵션은 규정 준수 또는 특정 보안 요구 사항을 위해 자주 사용되지만, 키를 안전하게 관리하고 저장하는 등 추가적인 운영 오버헤드가 발생합니다. 중요한 점은 AWS는 SSE-C 키를 저장하지 않으며, 대신 키의 HMAC(해시 기반 메시지 인증 코드)가 확인 목적으로 기록된다는 점입니다.

SSE-C의 경우, 암호화 키를 잘못 관리하거나 의도적으로 악용(예: 랜섬웨어)하면 데이터에 영구적으로 액세스할 수 없게 될 수 있습니다.

수명 주기 정책

S3 버킷은 또한 수명 주기 정책을 활용하여 객체를 더 저렴한 스토리지 클래스(예: Glacier)로 전환하거나 지정된 시간 후에 객체를 삭제하는 등의 작업을 자동화할 수 있습니다. 이러한 정책은 일반적으로 비용 최적화를 위해 사용되지만, 공격자가 중요한 데이터의 삭제를 예약하는 데 악용하여, 랜섬웨어 인시던트 발생 시 압력을 가중시킬 수 있습니다.

스토리지 클래스

Amazon S3는 다양한 액세스 패턴과 빈도 요구 사항에 맞게 설계된 여러 스토리지 클래스를 제공합니다. 스토리지 클래스는 일반적으로 비용 최적화를 위해 선택되지만, 암호화 및 보안이 데이터 저장 공간과 어떻게 상호 작용하는지를 고려할 때 이를 이해하는 것이 중요합니다.

예를 들어 S3 Standard 및 Intelligent-Tiering은 지연 시간을 최소화하면서 빈번한 액세스를 보장하여, 라이브 애플리케이션에 적합합니다. 반면, Glacier Flexible Retrieval 및 Deep Archive와 같은 보관 클래스는 데이터에 액세스하기 전에 지연이 발생하여, 보안 시나리오에서 인시던트 대응을 복잡하게 만들 수 있습니다.

이는 암호화가 도입될 때 특히 중요합니다. 서버 측 암호화(SSE)는 모든 스토리지 클래스에서 작동하지만, SSE-C(고객 제공 키)는 키 관리의 책임을 사용자 또는 공격자에게 전가합니다. AWS 관리형 암호화(SSE-S3, SSE-KMS)와 달리 SSE-C는 모든 검색 작업에 원본 암호화 키를 제공해야 하며, 공격자가 해당 키를 분실하거나 제공하지 않으면 데이터를 영구적으로 복구할 수 없습니다.

이러한 이해를 바탕으로 실제 환경에서 관찰되는 SSE-C 악용의 의미와 관련하여 중요한 의문이 제기됩니다. 공격자가 공개적으로 노출되거나 잘못 구성된 S3 버킷에 액세스하여, 스토리지 정책과 암호화 키를 모두 제어할 수 있게 된다면 어떤 일이 발생할까요?

그렇게 시작되는 '랜섬 작전을 위한 SSE-C 악용'

다음 섹션에서는 샌드박스 AWS 환경에서 이 동작을 에뮬레이션하는 실습 방법을 공유합니다. 방법은 다음과 같습니다.

1. 코드형 인프라(IaC) 제공 업체 Terraform을 통해 취약한 인프라를 배포합니다.
2. Python에서 SSE-C 요청을 작성하는 방법을 살펴봅니다.
3. Halcyon 블로그에 설명된 랜섬 동작을 에뮬레이션하기 위해 사용자 정의 스크립트를 실행합니다.

필수 조건

본 아티클에서는 탐지 엔지니어링을 위한 특정 시나리오를 재현하는 방법에 대해 설명합니다. 이를 목표로 하고 있다면 먼저 다음 사항을 설정해야 합니다.

• Terraform을 로컬에 설치해야 합니다.
• Python(3.9 버전 이상)도 가상 환경에 사용하고 에뮬레이션 스크립트를 실행하려면 로컬에 설치해야 합니다.
• AWS CLI 프로필은 인프라 배포 시 Terraform에서 사용하기 위해 관리자 권한으로 설정되어야 합니다.

취약한 인프라를 배포하기

화이트박스 에뮬레이션의 경우, 조직이 실제 시나리오에서 가질 수 있는 S3 구성을 복제하는 것이 중요합니다. 다음은 배포된 인프라에 관한 요약입니다.

• 리전: us-east-1(기본 배포 지역)
• S3 버킷: 민감한 데이터를 포함하고 공격자가 제어하는 암호화를 허용하는 고유한 이름의 급여 데이터 버킷입니다.
• 버킷 소유권 제어: ACL 기반 권한을 방지하기 위해 'BucketOwnerEnforced'를 적용합니다.
• 공개 액세스 제한: 우발적인 노출을 방지하기 위해 공개 액세스가 완전히 차단됩니다.
• IAM 사용자: 공격자가 제어하는 침해당한 IAM 사용자로, 과도한 S3 권한을 가지고 있습니다. 액세스 키 자격 증명이 자동화된 작업을 위해 다른 곳에서 프로그래밍 방식으로 사용되므로, 로그인 프로필이 할당되지 않습니다.
• IAM 정책: 버킷과 객체 수준 모두에서 공격자는 다음과 같은 권한을 가집니다.
  • s3:GetObject
  • s3:PutObject
  • s3:DeleteObject
  • s3:PutLifecycleConfiguration
  • s3:ListObjects
  • s3:ListBucket
• 버킷 및 객체 수준 모두에 적용됩니다.
• IAM 액세스 키: 공격자 사용자에 대한 액세스 키가 생성되어 프로그래밍 방식의 액세스를 허용합니다.
• 더미 데이터: 시뮬레이션된 민감한 데이터(customer_data.csv)가 버킷에 업로드됩니다.

인프라를 이해하는 것은 이러한 공격 유형이 어떻게 전개되는지를 평가하는 데 중요합니다. Halcyon 블로그는 공격 방법론을 설명하지만, 영향을 받은 조직의 특정 AWS 구성에 대한 세부 정보는 거의 제공하지 않습니다. 이 세부 정보는 그러한 공격의 실행 가능성과 성공적인 실행에 필요한 단계를 결정하는 데 필수적입니다.

버킷 접근성 및 노출

이러한 유형의 공격이 발생하려면 공격자는 다음 두 가지 주요 방법 중 하나를 통해 S3 버킷에 액세스해야 합니다.

공개적으로 액세스할 수 있는 버킷: 버킷이 공개 액세스 정책으로 잘못 구성된 경우, 버킷의 권한 정책이 s3:PutObject, s3:DeleteObject, s3:PutLifecycleConfiguration과 같은 작업을 허용하는 경우 공격자가 버킷과 직접 상호 작용할 수 있습니다. 이러한 권한은 와일드카드(*) 주체를 사용하여 실수로 할당되는 경우가 많아, 누구나 이러한 작업을 실행할 수 있습니다.

손상된 자격 증명: 공격자가 자격 증명 유출, 피싱 또는 멀웨어를 통해 AWS 자격 증명을 획득한 경우, 정당한 IAM 사용자로 인증하고 의도한 계정 소유자인 것처럼 S3와 상호 작용할 수 있습니다.

이 에뮬레이션에서는 버킷이 공개되지 않은 것으로 가정합니다. 즉, 공격은 손상된 자격 증명에 의존합니다. 이를 위해서는 공격자가 유효한 AWS 액세스 키를 확보하고 클라우드 인프라 검색을 수행하여 액세스 가능한 S3 버킷을 식별해야 합니다. 이는 일반적으로 s3:ListAllMyBuckets, s3:ListBuckets, s3:ListObjects와 같은 AWS API 호출을 사용하여 수행되며, 특정 리전에서 버킷과 해당 콘텐츠를 공개합니다.

공격 실행을 위한 필수 IAM 권한: SSE-C를 사용하여 파일을 암호화하고 삭제 정책을 성공적으로 적용하려면, 공격자는 적절한 IAM 권한을 보유해야 합니다. 이 에뮬레이션에서는 침해당한 IAM 사용자에 대한 명시적 권한을 구성했지만, 실제 시나리오에서는 여러 권한 모델을 통해 이 공격이 발생할 수 있습니다.

• 지나치게 허용적인 사용자 정의 정책: 조직은 엄격한 제약 없이 광범위한 S3 권한을 무의식적으로 부여할 수 있습니다.
• AWS 관리 정책: 공격자는 AmazonS3FullAccess 또는 AdministratorAccess를 가진 사용자나 역할에 연결된 자격 증명을 획득했을 수도 있습니다.
• 부분적인 객체 수준 권한: IAM 사용자에게 AllObjectActions이 있는 경우 객체 수준 작업만 허용되며, 객체를 검색하고 암호화 및 덮어쓰기를 반복하는 데 필요한 수명 주기 정책 수정이나 버킷 목록을 허용하지 않습니다.

Halcyon 블로그에는 어떤 권한이 남용되었는지 명시되어 있지 않지만, 화이트박스 에뮬레이션을 통해 공격이 설명된 대로 작동할 수 있도록 필요한 최소한의 권한이 설정되어 있음을 확인합니다.

침해당한 IAM 사용자의 역할
또 다른 중요한 요소는 자격 증명이 손상된 IAM 사용자의 유형입니다. AWS에서는 공격자가 인터랙티브 로그인 프로필이 있는 사용자에 대한 자격 증명이 반드시 필요하지 않습니다. 많은 IAM 사용자는 프로그래밍 방식의 액세스 전용으로 생성되며, 추가적인 보안 차단 역할을 할 수 있는 AWS Management Console 비밀번호나 다단계 인증(MFA)을 필요로 하지 않습니다.

즉, IAM 사용자의 탈취된 자격 증명이 자동화 또는 서비스 통합에 사용되는 경우, 공격자는 추가 인증 문제 없이 API 요청을 더 쉽게 실행할 수 있습니다.

Halcyon 블로그에는 이 공격에 사용된 기법이 효과적으로 설명되어 있지만, 피해자의 기본 AWS 구성에 대한 세부 정보는 포함되어 있지 않습니다. 공격의 배후에 있는 인프라, 예를 들어 버킷 액세스, IAM 권한, 사용자 역할 등을 이해하는 것은 이러한 랜섬 작전이 실제로 어떻게 전개되는지를 평가하는 데 필수적입니다. 이러한 세부 정보가 제공되지 않기 때문에, 공격이 성공할 수 있었던 조건을 더 잘 이해하기 위해서는 정보에 입각한 가정을 해야 합니다.

이 에뮬레이션은 이러한 공격 유형에 필요한 최소한의 조건을 재현하도록 설계되어, 방어 전략과 위협 탐지 기능을 현실적으로 평가할 수 있습니다. 인프라의 기술적 측면을 살펴봄으로써, 잠재적인 완화 방안과 조직이 유사한 위협을 선제적으로 방어할 수 있는 방법에 대한 심층적인 인사이트를 제공할 수 있습니다.

인프라 설정

우리는 인프라 배포를 위해 Terraform을 IaC 프레임워크로 활용합니다. 이 아티클의 내용이 너무 길어지지 않도록, 테라폼 구성과 원자적 에뮬레이션 스크립트를 모두 다운로드 가능한 요약본에 저장하여 쉽게 액세스할 수 있도록 했습니다. 이 파일을 다운로드한 후 예상되는 로컬 파일 구조는 아래에 나와 있습니다.

로컬에서 필요한 파일을 설정한 후, 이 시나리오를 위한 Python 가상 환경을 생성하고 필요한 종속성을 설치할 수 있습니다. 환경이 구성되면 다음 명령어로 Terraform을 초기화하고 인프라를 배포합니다.

Command: python3 s3\_sse\_c\_ransom.py deploy

배포가 완료되면 공격의 에뮬레이션 및 실행을 진행하기 위한 필요한 AWS 인프라가 준비됩니다. 공개 액세스는 차단되며, 보안상의 이유로 동적으로 생성된 IAM 사용자에게만 IAM 정책이 적용된다는 점에 유의하세요. 그러나 테스트가 완료되거나 필요한 데이터를 캡처한 후에는 인프라를 해체할 것을 강력히 권장합니다.

AWS 콘솔에 로그인하거나 CLI를 사용하는 경우, us-east-1 리전에 버킷이 존재하고, 다운로드 시 일반 텍스트로 표시되는 customer_data.csv,가 포함되어 있는지 확인할 수 있습니다. 또한 'ransom.note'도 존재하지 않는다는 점에 유의하세요.

Python에서 S3 SSE-C 요청을 작성하는 방법 살펴보기

원자적 에뮬레이션을 실행하기 전에 공격자가 실제 환경에서 이 공격을 성공적으로 수행할 수 있게 해 주는 기본 기술을 살펴보는 것이 중요합니다.

AWS에 익숙한 사용자라면 버킷 액세스, 객체 나열 또는 데이터 암호화와 같은 S3 작업은 일반적으로 AWS SDK 또는 AWS CLI를 사용할 때 간단합니다. 이러한 도구는 복잡성을 상당 부분 추상화하여, 사용자가 기본 API 메커니즘을 심층적으로 이해하고 있지 않아도 작업을 실행할 수 있게 해 줍니다. 또한 이러한 기능을 악용하려는 공격자의 지식 장벽도 낮출 수 있습니다.

그러나 Halcyon 블로그는 공격 실행에 관한 중요한 기술적 세부 사항을 언급합니다:

“공격자는 자신이 생성하여 로컬에 저장한 AES-256 암호화 키를 사용하여, x-amz-server-side-encryption-customer-algorithm 헤더를 호출함으로써 암호화 프로세스를 시작합니다.”

여기서 중요한 차이점은 이 공격에서 암호화 작업에 필요한 x-amz-server-side-encryption-customer-algorithm 헤더를 사용한다는 점입니다. AWS 설명서에 따르면, 이 SSE-C 헤더는 일반적으로 사전 서명된 URL을 생성하고 S3에서 SSE-C를 활용할 때 지정됩니다. 즉, 공격자는 피해자의 데이터를 암호화할 뿐만 아니라 AWS 자체에 암호화 키를 저장하지 않는 방식으로 암호화하여, 공격자의 협조 없이는 복구가 불가능하게 만듭니다.

사전 서명된 URL과 SSE-C 악용에서의 그 역할

사전 서명된 URL이란?
사전 서명된 URL은 사용자가 제한된 시간 동안 특정 S3 작업을 수행할 수 있도록 허용하는 서명된 API 요청입니다. 이 URL은 AWS 자격 증명을 노출하지 않고 객체를 안전하게 공유하는 데 일반적으로 사용됩니다. 사전 서명된 URL은 S3 객체에 대한 임시 액세스 권한을 부여하며, 브라우저를 통해 액세스하거나 API 요청에서 프로그래밍 방식으로 사용할 수 있습니다.

일반적인 AWS 환경에서는 사용자가 사전 서명된 URL을 위해 SDK 또는 CLI 래퍼를 활용합니다. 그러나 SSE-C를 사용할 때는 AWS에서 암호화 또는 복호화를 위해 추가 헤더를 요구합니다.

SSE-C 및 필수 HTTP 헤더
SSE-C 요청을 할 때 AWS SDK 또는 직접 S3 REST API 호출을 통해 다음 헤더를 포함해야 합니다:

• x-amz-server-side​-encryption​-customer-algorithm: 암호화 알고리즘을 지정하되, 반드시 AES256이어야 합니다(Halcyon의 보고서에 언급됨).
• x-amz-server-side​-encryption​-customer-key: S3가 데이터를 암호화하거나 해독하는 데 사용할 256비트, base64 인코딩된 암호화 키를 제공합니다.
• x-amz-server-side​-encryption​-customer-key-MD5: 암호화 키의 base64 인코딩된 128비트 MD5 다이제스트를 제공합니다. S3는 이 헤더를 메시지 무결성 검사에 사용하여 암호화 키가 오류나 변조 없이 전송되었는지 확인합니다.

탐지 기회를 찾을 때 이러한 세부 정보가 매우 중요합니다.

AWS Signature 버전 4 (SigV4) 및 그 역할

S3으로 보내는 요청은 인증된 요청이거나 익명 요청입니다. 사전 서명된 URL을 사용하는 SSE-C 암호화는 인증이 필요하므로, 모든 요청은 정당성을 증명하기 위해 암호화 방식으로 서명되어야 합니다. 바로 이것이 AWS Signature Version 4 (SigV4)가 중요한 이유입니다.

AWS SigV4는 AWS 서비스에 대한 API 요청이 서명되고 검증되도록 보장하는 인증 메커니즘입니다. 이것이 SSE-C 작업에서 특히 중요한 이유는 S3에서 개체를 수정하는 데 인증된 API 호출이 필요하기 때문입니다.

이 공격에서는 각 암호화 요청이 서명되어야 합니다:

1. AWS SigV4를 사용하여 암호화 서명 생성하기
2. 요청 헤더에 서명 포함하기
3. 필요한 SSE-C 암호화 헤더를 첨부합니다
4. 암호화된 버전으로 객체를 덮어쓰기 위해 S3에 요청 보내기

적절한 SigV4 서명이 없으면 AWS에서 이러한 요청을 거부합니다. Halcyon이 설명한 것과 같은 공격은 침해된 인증 정보를 사용하며, 테스트에서 요청이 거부되지 않았기 때문에 우리는 이를 확인할 수 있습니다. 이는 또한 공격자는 부적절한 서명 요구 사항과 같은 AWS S3의 잘못된 구성을 악용할 수 있다는 것을 알고 있으며, 버킷과 그에 따른 객체 액세스 제어의 세부 사항을 이해하고 있다는 것을 시사합니다. 이는 공격이 노출되고 공개적으로 액세스할 수 있는 S3 버킷이 아닌 손상된 AWS 자격 증명에 의존했으며, 공격자가 S3 버킷과 객체뿐 아니라 AWS의 인증 및 암호화와 관련된 미묘한 차이를 이해할 만큼 숙련되었다는 가정에 힘을 실어 줍니다.

원자적 에뮬레이션 실행하기

우리의 원자 에뮬레이션은 대상 버킷에 여러 S3 작업을 허용하는 권한 정책이 첨부된 IAM 사용자(로그인 프로필 없음)의 '침해된' 자격 증명을 사용합니다. 참고로 우리가 이 작업을 수행하는 인프라와 환경은 '인프라 설정' 섹션에서 공유한 요약본을 참조하여 배포되었습니다.

에뮬레이션의 단계별 워크플로우는 다음과 같습니다.

1. 탈취된 AWS 자격 증명을 로드합니다(환경 변수에서 가져오기).
2. 손상된 자격 증명으로 S3 클라이언트를 설정하십시오
3. S3 엔드포인트 URL을 생성합니다(버킷의 URL 구성하기).
4. S3 객체 나열 → s3:ListObjectsV2 (객체 목록 검색)
5. AES-256 암호화 키를 생성합니다(로컬에서 생성됨).
6. 루프를 시작합니다(버킷의 각 객체에 대해).
   1. GET 요청을 생성하고 AWS SigV4로 서명합니다(요청 인증하기).
   2. S3에서 객체를 가져옵니다 → s3:GetObject(암호화되지 않은 데이터 가져오기)
   3. PUT 요청을 생성하고 AWS SigV4로 서명합니다(SSE-C 헤더 첨부하기).
   4. S3에서 객체 암호화 및 덮어쓰기 → s3:PutObject (SSE-C로 암호화)
7. 루프 종료
8. 7일 삭제 정책 적용 → s3:PutLifecycleConfiguration (시간 제한 데이터 파기)
9. S3에 랜섬 노트를 업로드합니다 → s3:PutObject(피해자에게 남긴 협박 메시지)

아래는 이 에뮬레이션 워크플로우를 시각적으로 표현한 것입니다.

Python 스크립트에는 사용자가 이 스크립트를 악용하지 않겠다고 동의하는지 확인하고자, 사용자 상호 작용이 필요한 프롬프트를 의도적으로 추가했습니다. 실행 중 생성되는 또 다른 프롬프트는 사용자가 S3 객체를 삭제하기 전에 필요한 경우 AWS 조사를 위한 시간을 제공하기 위해 실행을 지연시킵니다. SSE-C가 사용되기 때문에 객체는 Terraform이 액세스할 수 없는 키로 암호화되어 실패하게 됩니다.

Command: python s3\_sse\_c\_ransom.py detonate

실행 후 S3 버킷의 객체는 SSE-C로 암호화되고, 랜섬 노트가 업로드되며, 만료 수명 주기가 추가됩니다.

customer_data.csv 객체에 액세스하려고 시도하면, 서버 측 암호화를 사용하여 저장되었기 때문에 AWS에서 요청을 거부합니다. 객체를 검색하려면 올바른 AES-256 암호화 키가 포함된 서명된 요청이 필요합니다.

정리

이 에뮬레이션을 정리하는 과정은 비교적 간단합니다. S3 객체를 유지하기로 한 경우, 1단계부터 시작하고, 그렇지 않으면 5단계로 바로 이동합니다.

1. us-east-1 지역으로 이동하십시오
2. S3으로 이동합니다.
3. 다음을 찾습니다: s3-sse-c-ransomware-payroll-XX bucket
4. 모든 객체를 제거합니다.
5. Command: python s3\_sse\_c\_ransom.py cleanup

완료되면 처음에 배포된 모든 항목이 제거됩니다.

탐지 및 헌팅 전략

원자적 에뮬레이션을 마친 후, AWS의 CloudTrail에서 제공하는 API 이벤트 로그를 기반으로, 이러한 랜섬웨어 행위를 효과적으로 탐지하는 방법을 공유하는 것이 중요합니다. 데이터 수집 및 초기 쿼리 개발을 위해 Elastic Stack을 활용할 예정입니다. 그러나 쿼리 로직과 컨텍스트는 자신이 선택한 SIEM에도 적용 가능해야 합니다. 또한 CloudTrail 구성에서 S3의 데이터 이벤트를 'Log all events(모든 이벤트 기록)'로 설정하는 것이 중요합니다.

SSE-C를 활용한 이례적인 AWS S3 객체 암호화

이 탐지 전략의 목표는 SSE-C를 활용하는 PutObject 요청을 식별하는 것입니다. 고객이 제공한 암호화 키는 이례적인 활동의 강력한 지표가 될 수 있기 때문입니다. 조직이 주로 KMS(SSE-KMS) 또는 S3의 기본 암호화(SSE-S3)를 통해 AWS 관리형 암호화를 사용하는 경우에 특히 그렇습니다.

우리 에뮬레이션에서 PutObject 요청은 x-amz-server-side-encryption-customer-algorithm 헤더를 AES256으로 설정하여, 고객이 제공한 키가 암호화(SSE-C)에 사용되었음을 AWS에 알립니다.

다행히도 AWS CloudTrail은 요청 매개변수 내에 이러한 암호화 세부 정보를 기록하므로, 보안 팀이 이례적인 SSE-C 사용을 감지할 수 있습니다. 모니터링해야 할 CloudTrail의 주요 속성은 다음과 같습니다.

• SignatureVersion: SigV4 → 이 요청이 서명되었음을 알립니다.
• SSEApplied: SSE_C → 서버 측 고객 키 암호화가 사용되었음을 알립니다.
• bucketName: s3-sse-c-ransomware-payroll-96 → 어느 버킷에서 이런 일이 발생했는지 알립니다.
• x-amz-server-side-encryption-customer-algorithm: AES256 → 고객 암호화 키에 어떤 알고리즘이 사용되었는지 알립니다.
• key: customer_data.csv → 적용된 객체의 이름을 나타냅니다.

이러한 세부 정보를 통해 우리는 이미 이러한 이벤트와 궁극적으로 기존 Halcyon 블로그에 보고된 위협과 일치하는 위협 탐지 쿼리를 만들 수 있습니다.

이 탐지 기능은 광범위하지만, 조직은 다음 질문을 통해 각자의 환경에 맞게 조정해야 합니다.

• S3 버킷 또는 객체 작업을 위해 SigV4로 사전 서명된 URL을 기대하십니까?
• S3 또는 이 특정 버킷의 PutObject 작업에 SSE-C가 사용될 것으로 예상하십니까?

새로운 용어 규칙 유형으로 오탐 줄이기
오탐(FP)을 최소화하기 위해 의심스러운 활동의 최초 발생을 탐지하는 데 도움이 되는 Elastic의 새로운 용어 규칙 유형을 활용할 수 있습니다. 모든 일치에 대해 경고를 보내는 대신, IAM 사용자와 영향을 받는 S3 버킷의 고유한 조합을 추적하여 설정된 기간 내에 이러한 동작이 처음 관찰될 때만 경고를 생성합니다. 우리가 주목하는 몇 가지 독특한 조합은 다음과 같습니다.

• S3에서 SSE-C 암호화를 수행하는 고유한 IAM 사용자(ARN).
• SSE-C가 적용된 특정 버킷.

이러한 알림은 이 활동이 지난 14 일 동안 처음으로 관찰된 경우에만 트리거됩니다.

이러한 적응형 접근 방식은 시간이 지남에 따라 합법적인 사용 사례를 학습하고, 예상되는 작업에 대한 반복적인 경고를 방지합니다. 동시에 S3에서 이례적인 SSE-C의 첫 발생을 플래그하여 조기 위협 탐지에 도움을 줍니다. 필요에 따라 특정 사용자 ID ARN, 버킷, 객체 또는 소스 IP에 대한 규칙 예외를 추가하여 탐지 로직을 구체화할 수 있습니다. 이 방법은 과거 컨텍스트와 행동 기준선을 통합함으로써 신호 충실도를 높여 탐지의 효과와 경고의 실행 가능성을 모두 개선합니다.

규칙 참고 자료

SSE-C를 활용한 이례적인 AWS S3 객체 암호화
과도한 AWS S3 객체 암호화(SSE-C 사용)

결론

소중한 시간에 본 아티클을 읽어 주신 데 진심으로 감사드립니다. 에뮬레이션을 직접 시도해 보신 분들께도 감사 말씀을 전합니다. 화이트박스 테스트는 클라우드 보안에서 중요한 역할을 하며, 실제 위협을 재현하고, 행동 패턴을 분석하며, 효과적인 탐지 전략을 세울 수 있게 해 줍니다. 클라우드 기반 공격이 점점 더 널리 퍼짐에 따라, 공격자의 전술 뒤에 숨어 있는 도구를 파악하고 광범위한 보안 커뮤니티와 연구 결과를 공유하는 것이 필수적입니다.

AWS 탐색 규칙 세트에 대한 자세한 내용은 Elastic AWS 탐지 규칙에서 확인하실 수 있습니다. 또한 당사에서는 규칙 세트를 개선하기 위한 여러분들의 기여를 환영합니다. 여러분의 노력은 집단 방어를 강화하는 데 도움이 되므로, 이를 매우 감사히 여기고 있습니다.

관심 있는 분이라면 Halcyon의 간행물을 검토해 보시길 바라며, 연구를 공유해 주신 분들께 미리 감사의 말씀을 전합니다!

그럼 다음에 뵙겠습니다.

중요 참고 자료

SSE-C ItW에 대한 Halcyon Research 블로그
AWS에서 SSE-C를 위한 Elastic 에뮬레이션 코드
Elastic 사전 구축 AWS 위협 탐지 규칙 세트
Elastic 사전 구축 탐지 규칙 리포지토리
규칙: 이례적인 AWS S3 객체 암호화(SSE-C 사용)
규칙: 과도한 AWS S3 객체 암호화(SSE-C 사용)