Offensive Cloud Security에 대한 공부를 진행하며 CloudGoat를 처음 접하게 되었고, 단순 문제풀이만 진행하던 중 더 의미있는 공부 방법에 대한 고민을 하게 되었습니다.
공격자가 공격을 할 때 보안 담당자의 눈을 피하는 것이 목적일테고, 그렇다면 '공격이 탐지되는 환경을 직접 공격해보며 우회 및 대응을 해보자' 라는 생각을 갖게 되었습니다.
그렇게 발견한 서비스는 AWS에서 제공하는 위협 탐지 서비스 GuardDuty 입니다.
GuardDuty는 공격자의 동작을 모두 탐지할 수 있을까요?
GuardDuty란?
GuardDuty는 AWS 환경의 데이터 소스 및 로그를 지속적으로 모니터링, 분석 및 처리하는 위협 탐지 서비스입니다.
기본적으로 AWS CloudTrail Management Events, Amazon VPC Flow Logs, Amazon Route53 Resolver DNS Query Logs와 같은 기본 데이터 소스를 모니터링하며, 기본 데이터 소스들은 별도의 활성화 없이 GuardDuty에서 내부적으로 수집하게 됩니다.
이 외에도 GuardDuty에 기록된 탐지와 같은 이벤트를 수집하여 위협 탐지를 진행하며, S3, EKS 등의 서비스를 대상으로 탐지를 유료로 활성화 할 수 있습니다.
GuardDuty의 기본 데이터 소스
1. AWS CloudTrail Management Events
AWS Management Console, AWS SDK, CLI 및 일부 AWS 서비스에서 이루어진 AWS API 호출 내역을 기록하여 계정의 활동 이력을 제공하는 서비스입니다. 각 리전별로 GuardDuty가 CloudTrail의 이벤트를 처리하며, IAM과 같은 글로벌 서비스는 전역적으로 사용되어 리전에 자동 복제됩니다.
2. Amazon VPC Flow Logs
Amazon VPC의 VPC Flow Logs는 AWS 환경 내 Amazon EC2 인스턴스에 연결된 네트워크 인터페이스로 오가는 IP 트래픽 정보를 캡처하는 서비스입니다. GuardDuty 활성화 시 계정 내 EC2 인스턴스의 VPC Flolw Log를 분석하며, GuardDuty의 선택적 옵션인 Lambda Protection을 통해 VPC 네트워크를 사용하지 않는 Lambda 함수의 로그를 VPC Flow Log에 포함시킬 수 있습니다.
3. Amazon Route53 Resolver DNS Query Logs
AWS의 VPC 안에서 발생하는 DNS Query Log 입니다. AWS의 기본 설정인 AWS DNS Resolver를 Amazon EC2 인스턴스에서 사용하고 있다면, GuardDuty는 내부 Resolver를 통해 Route53 Resolver DNS Query Log의 요청과 응답을 접근하고 처리할 수 있습니다.
GuardDuty 기본 데이터 소스 - Amazon GuardDuty
이러한 글로벌 서비스 이벤트에서 생성된 결과의 경우 결과의 리전 값은 GuardDuty가 감지를 생성하는 리전과 다를 수 있습니다. 예를 들어 GuardDuty가 다른 리전에서 탐지를 생성하더라도 조사 결
docs.aws.amazon.com
GuardDuty 탐지 실습
저는 실습이 진행될 미국 버지니아 북부(us-east-1) 리전에서 GuardDuty를 활성화 해주었습니다.
GuardDuty가 활성화 된 상태에서 CloudGoat 인프라를 생성하여 다양한 경로로 공격을 진행해보았습니다.
codebuild_secrets (Hard) Write up
문제에서 제공받은 Access Key와 Secret Key를 통해 Profile을 생성하고, sts get-caller-identity 명령을 사용하여 User에 대한 정보를 확인한다.profile의 이름을 GuardDuty로 설정한 이유는, 해당 시나리오를 풀며
beaver-dam.tistory.com
위의 문제를 풀어보면서 탐지된 동작은 단 하나입니다.
EC2 내부에서 메타데이터에 접근하여 Instance Profile의 임시 자격 증명을 발급받으면 EC2 외부에서 해당 자격 증명을 사용할 수 있게됩니다.
이때, EC2 내에서 사용되어야 할 역할의 자격 증명이 외부 IP에서 사용되었다는 탐지가 발견된 것을 확인할 수 있었습니다.
이렇게만 보면 CloudGoat 문제를 풀며 결국 GuardDuty가 잘 탐지했구나 라고 생각할 수 있지만, 사실 공격자가 진행한 동작은 이 하나가 끝이 아닙니다.
아래의 Graph는 제가 문제를 풀며 진행한 동작과 접근한 경로입니다. 그 중에서 GuardDuty가 탐지한 시점은 매우 일부임을 알 수 있고,
공격자가 이 동작에 대해 GuardDuty가 탐지함을 알고있었다면 EC2 내부에서 AWS CLI를 설치하고 Lambda 함수 조회, RDS 데이터베이스 접근을 진행하여 GuardDuty의 탐지 없이 공격에 성공할 수 있었을 것 입니다.
해당 문제에서는 이 공격 경로 외에도 총 3개의 공격 경로가 존재했으며 다양한 동작을 할 수 있는 공격들이 존재했지만, GuardDuty는 하나도 탐지하지 못하였습니다. 심지어 공격 과정에서 IAM 자격 증명에 대한 권한 확인을 진행하는 pacu, cloudfox 등의 Tool을 사용한 것도 탐지하지 못하였습니다.
왜 탐지가 진행되지 않은 것일까요?
GuardDuty가 공격 탐지를 왜 못했을까
GuardDuty는 위협이라고 판단된 동작을 탐지하게 됩니다. 예를 들어 앞에서 탐지된 외부에서 Role이 사용된 경우는 명백히 내부에서 사용되어야 할 역할이 외부에서 사용되었기에 공격임을 확신할 수 있습니다. 하지만 실습에서 사용된 명령어들과 호출들을 해당 User에게 부여된 권한을 통해 실행한 정상적인 명령과 호출로 판단을 하고, 비정상적인 동작으로 간주하지 않았기에 탐지하지 못한 것 입니다.
추가적으로 GuardDuty가 모니터링 하는 CloudTrail을 확인해보니 실습 때 호출된 API 동작들이 모두 기록되지 않았음을 확인할 수 있었습니다. CloudTrail에서 Events 로깅을 추가로 진행하지 않으면 기록되는 API 동작은 제한적임을 알 수 있습니다.
Insights Events, Network Activity Events, Data Events와 같은 기능으로 추가적인 동작 및 비정상 행동 탐지가 가능하지만, 이 또한 추가적인 비용을 지불해야 사용 가능한 상태입니다. 관련 내용은 공식 문서에서 확인할 수 있습니다.
Understanding CloudTrail events - AWS CloudTrail
Understanding CloudTrail events An event in CloudTrail is the record of an activity in an AWS account. This activity can be an action taken by an IAM identity, or service that is monitorable by CloudTrail. CloudTrail events provide a history of both API an
docs.aws.amazon.com
이렇게 CloudTrail에서 Data Evnets를 활성화 하게되면 GuardDuty에서도 Data Events 모니터링을 통해 추가적인 공격 탐지가 가능합니다. 하지만, 이 또한 추가적인 비용을 지불해야 활성화 가능하기에 CloudTrail에서 Data Events를 활성화하는 것에 더불어 GuardDuty까지 활성화 하려면 더 많은 비용을 추가적으로 지불해야 합니다.
CloudTrail이 모든 API 호출을 실시간으로 기록하지 못하고, GuardDuty가 공격과 정상 동작의 차이를 인지하지 못한다는 점에서 위와 같이 많은 비용을 지불하여 보안을 챙겨야 한다는 것을 알 수 있습니다. 하지만, 이 모든 것을 활성화 하여도 자격 증명이 탈취 당했을 때 일어나는 정상적인 동작과 비정상적인 동작을 완벽히 구분하고 탐지할 수 없습니다.
탐지 기반의 보안으로는 이처럼 정확한 공격을 탐지하기 어렵습니다. 또한 이미 진행된 공격에 대하여 나중에 탐지를 하더라도 이미 피해는 발생했기에 사전에 공격을 예방하는 방법이 필요합니다. IAM Access Analyzer 등을 통해 자격 증명에 대한 보안을 강화하거나, Offensive 관점에서 주기적인 모의 침투 테스트로 탈취 이후에 큰 피해가 발생하지 않도록 하는 등의 추가적인 보안 대책이 필요합니다.
이번 실습을 진행하며 AWS CloudTrail과 GuardDuty 만으로는 CloudGoat의 실습 시나리오 하나도 제대로 잡지 못한다는 것을 확인할 수 있었습니다. 추가적인 기능을 통해 탐지할 수도 있지만, 분명 모든 공격을 완벽히 탐지하지는 못한다고 생각합니다. 때문에 지속적인 대응과 보안이 필요하다고 생각하며, Offensive Cloud Security는 이러한 위협 탐지의 허점을 발견하여 보안 강화로 이어질 수 있도록 공부하고 학습하는 분야입니다. 이러한 관점과 방법이 앞으로 더욱 활성화되어 보안 사고를 예방할 수 있기를 바랍니다.
Beaver Dam 팀은 공격자의 시선에서 바라보는 Cloud 보안인, Offensive Cloud Security 분야를 연구하고 학습하고 있는 팀입니다.
매월 무료 세미나를 개최하며, 다양한 정보 아래 링크들에서 공유드리고 있으니 많은 관심을 부탁드립니다.
- LinkedIn : https://www.linkedin.com/groups/14865006/
- Kakao Open Chat : https://open.kakao.com/o/gVh8CYYh
'AWS' 카테고리의 다른 글
| IAM의 이중성: 중복 권한이 만드는 보안 착시 (0) | 2026.01.27 |
|---|---|
| ECS Shawshank Redemption : 컨테이너의 벽을 넘어서 (0) | 2025.11.05 |
| 템플릿 속에 숨어든 스파이: Bedrock 프롬프트 인젝션 (0) | 2025.11.05 |
| Bucket monopoly : 간단한 S3 이름의 함정 (1) | 2025.10.19 |
