GuardDuty 이벤트 분석으로 살펴보는 침해대응 아키텍처 고도화 사례

갈수록 정교해지는 보안 위협은 고도화된 보안 아키텍처를 설계하고 구현하는 능력을 더욱 중요하게 만들고 있습니다. 이러한 보안 위협에 대응하기 위해 우아한형제들에서는 적절한 보안 서비스 모니터링 환경을 구축하고 위협 인텔리전스를 적극적으로 활용하고 있습니다. 본 글은 AWS GuardDuty에서 탐지된 아웃바운드 통신 이벤트를 중심으로, 위협 탐지 가시성 확보, 대응 자동화, 잠재적 위협 가시화 등 침해 대응 체계 고도화 과정을 설명합니다. 위협 인텔리전스, 보안 운영, 보안 분석에 관심이 있는 보안 엔지니어, DevSecOps 엔지니어께 유익한 정보가 되길 바랍니다.

AWS GuardDuty를 활용한 위협 탐지

[GuardDuty 위협 모니터링 데이터 소스]

GuardDuty는 클라우드 보안을 잘 모르는 사람도 AWS의 다양한 보안 위협을 쉽게 모니터링할 수 있도록 도와주는 서비스입니다. GuardDuty는 다양한 AWS Log를 기반으로 보안 위협을 탐지해줍니다. 특히 클라우드의 모든 네트워크 통신을 모니터링하기 힘든 상황에서 자동으로 VPC Flow Log를 모니터링해 주는 GuardDuty는 위협 탐지 관점에서는 매우 효율적입니다. 사용자 정의(Custom) 기능은 제한적이지만, "위협 목록"에 직접 등록한 위협 인텔리전스(Threat Intelligence, TI)를 바탕으로 워크로드가 통신하는 IP를 탐지할 수 있습니다. GuardDuty 위협 목록은 단일 목록에 최대 25만 개의 IP 주소와 CIDR 범위를 포함할 수 있으며, 최대 6개의 위협 목록을 등록하여 활용할 수 있습니다. 이 목록은 신뢰할 수 있는 벤더의 위협 인텔리전스 데이터를 기반으로 생성하거나, 조직에 맞게 직접 제작할 수도 있습니다.
우아한형제들에서도 위협 인텔리전스 플랫폼(Threat Intelligence Platform, TIP)에 수집된 다양한 위협 인텔리전스를 GuardDuty 위협 목록에 등록하여 사용하고 있습니다.
공격 중 탐지된 이벤트에 대응하는 것은 중요하지만, 많은 이벤트를 우선순위 없이 처리하면 오히려 비효율적일 수 있습니다. 따라서 높은 위험 등급의 보안 위협을 빠르게 탐지하고 분석하기 위해 워크로드의 아웃바운드 통신 이벤트에 집중한 모니터링을 시작했습니다.

[감염 서버 GuardDuty Outbound 이벤트 탐지 케이스]

Threat Intelligence (TI)를 모든 경우에 100% 신뢰할 수 없지만, 고위험도로 분류된 TI는 일반적으로 정탐률(True Negative)이 높은 편입니다. 정보의 최신성이나 최소 3개 이상의 소스에서 검증된 TI라면 고위험도, 즉 신뢰도가 높은 TI로 분류할 수 있습니다.

GuardDuty에서 높은 신뢰도를 가진 고위험 등급(Score, Severity) TI만 사용할 경우 오탐률(False Positive)을 줄일 수는 있지만, 탐지율(False Negative) 역시 낮아질 수 있습니다. 따라서, TI 데이터를 적절히 선별하고 조정하는 것은 이 시나리오의 유효성을 강화하는 핵심 과제입니다.

위협 탐지 신뢰도를 높이기 위한 보조지표 플레이북 개발

GuardDuty 이벤트에서 탐지된 Outbound 통신 IP가 GuardDuty 위협 목록에 포함된 경우 EC2/MaliciousIPCaller.Custom 이름의 이벤트가 탐지되는 것을 알 수 있습니다. 이러한 이벤트를 보다 효율적으로 모니터링하기 위해, 아래와 같은 템플릿으로 Slack 알림을 개발하여 사용하고 있습니다.

*GuardDuty -> Amazon EventBridge(Rule) -> Lambda -> S3 -> SIEM -> SOAR(보안 오케스트레이션, 자동화 및 대응) -> Slack*

[GuardDuty 로그 수집 및 알람 구성도]

[GuardDuty Event]

그림과 같이 이벤트의 기초 정보를 판단하기 위한 “언제(Timestamp)”, “어디서(Account, Region, EC2-ID)”, “누구(IPAddress)”와 “왜(Type, TI Name in Description)” 정보를 한눈에 알 수 있습니다.
이벤트 대응 담당자(분석가)는 해당 이벤트의 정오탐 여부를 빠르게 판단하고 즉각적으로 대응할 수 있습니다. 높은 등급의 이벤트는 탐지와 동시에 자동 IP 차단을 고려할 수 있지만, 앞서 언급한 것처럼 GuardDuty 탐지 이벤트의 신뢰성과 오탐 발생 가능성으로 차단 시 장애 위험이 존재합니다. 숙련된 분석가는 경험과 노하우를 활용해 신속하게 정, 오탐 여부를 판단할 수 있겠지만, 모든 이벤트 대응 담당자가 동일하고 빠른 결론에 도달하려면 객관적인 보조 데이터와 판단 근거가 필수입니다.

[평판조회 플레이북 흐름도]

이를 보완하기 위해, 평판(Reputation)도구에 IP 정보를 조회하여 Score 및 악성 유무를 판단하는 SOAR 플레이북(Playbook)을 개발하였습니다. 이 플레이북은 SIEM에서 발생한 이벤트를 전달받은 SOAR가 시나리오에 따라 악성 의심 IP를 각종 Reputation 및 TI 도구에 조회하여 Slack 댓글에 기록하는 플레이북입니다.

[IP 기본 정보, TIP 정보, IP Reputation 정보]

확인할 수 있는 정보

• IP 기본 정보: Geolocation, ASN, ISP 등
• TIP 정보: Score, Comment, Category 등
• IP Reputation 정보: 악성 여부, 신뢰도 등

이 플레이북은 다양한 API를 호출해 필요한 데이터를 자동으로 수집하여 분석가가 보다 객관적인 판단을 내릴 수 있도록 지원합니다.
하지만 이러한 정보만으로는 일부 케이스에서 판단에 도움되는 지표가 부족하다는 한계가 있었습니다. 예를 들어, GuardDuty가 모니터링하는 위협 목록에는 IP 기준으로 저장되어 있어 GuardDuty에서는 IP 정보만 확인 가능하지만, 실제 공격자는 Remote Control Execution(RCE)공격 유형에서 공격 구문 안에 C&C 통신 정보로 IP가 아닌 DNS 값을 넣는 경우나 실제 서버를 장악한 공격자가 이미 악성코드 유포지로 활용되고 있는 웹 사이트에 접근하여 악성코드를 다운로드할 수도 있기 때문입니다. 이 점을 보완하기 위해, SIEM에 수집된 DNS Logs를 추가로 조회하여 의심 IP와 통신 당시 DNS 정보를 확인하여 EC2의 활동 이력을 확인할 수 있는 새로운 플레이북을 개발하였습니다.

*Route53 -> Query Logging -> S3 -> SIEM*

[DNS Log 수집 구성도]

먼저, SIEM에서 DNS Log에 대한 별도 수집이 필요했고 모든 계정에서의 Route 53 서비스에서 쿼리 로깅 기능을 활용해 S3로 수집하여 SIEM에 쌓고 있습니다.

[SIEM에 수집된 DNS Log 조회 결과]

이 플레이북은 GuardDuty 이벤트에 포함된 정보(시간, IP, ec2정보)를 기반으로 SIEM의 Search Job API(로그 검색)를 호출하여, 알람이 발생한 EC2의 활동 정보와 IP와 관련된 도메인 쿼리 내역 등을 제공합니다. 분석가는 GuardDuty EC2/MaliciousIPCaller.Custom 이벤트에서 확인할 수 없었던 실제 통신된 DNS 정보와 사건의 전후 맥락을 보다 명확히 파악할 수 있습니다. 이 플레이북으로 DNS 로그를 조회했을 때 기록이 없다면 서버는 IP와 직접 통신한 것으로 판단할 수도 있습니다. 결과적으로 이러한 추가 정보를 바탕으로 신뢰도 높은 분석 결론을 도출할 수 있도록 지원합니다.

빠르고 효율적인 침해대응을 위한 자동화 개발

MTTD(평균 탐지 시간), MTTA(평균 인지 시간), MTTR(평균 대응 시간)과 같은 침해 대응 시간 관리 지표에서 강조하듯이, 신속한 탐지와 판단 이후에는 즉각적인 대응이 중요합니다.
클라우드 환경은 동적인 특성과 모호한 네트워크 경계 등으로 인해 온프레미스 환경과 같이 물리적 방화벽을 구축하기 어렵습니다. 따라서, 온프레미스 환경처럼 IP 차단과 같이 기본적인 침해대응 활동이 어렵습니다. 우아한형제들 보안팀에서는 이러한 문제를 보완하기 위해 Network Access Control List(NACL) 서비스를 적극 활용하고 있습니다.

[NACL 차단 자동화 도구 아키텍처]

멀티 계정(Multi Account)를 운영하는 환경에서 빠르고 효율적인 침해대응을 위해 위 그림과 같은 아키텍처와 자동화 도구를 개발하였습니다. 안정성을 높이고자 SQS와 sqs의 in-out을 관리하는 lambda(sqs-consumer)를 구성하였고 멀티계정에 최대한 동시간 레벨로 NACL Item을 업데이트하기 위해 운영(NACL-IR)과 베타(NACL-BETA-IR)를 나누어서 관리하도록 구성하였습니다. 이는 NACL 업데이트 하는 대상 계정만 다를 뿐 동일한 코드의 Lambda입니다.
NACL-IR 도구의 기능 모듈은 크게 다음과 같이 구성됩니다.

• update(ingress/egress) 모듈
  • 전체 계정의 NACL과 DDB에 IP를 업데이트한다.
• delete(ingress/egress) 모듈
  • 전체 계정의 NACL과 DDB에서 특정 IP를 삭제한다.
• alldelete(ingress/egress) 모듈
  • 전체 계정의 NACL과 DDB에서 모든 객체를 삭제한다.
• check(ingress/egress) 모듈
  • 현재 모든 계정의 NACL의 정상 등록 여부와 무결성을 검증한다.

NACL은 Ingress/Egress 각각 20개씩, 총 40개의 규칙을 등록할 수 있으며, AWS와의 협의를 통해 각 40개까지 확장이 가능합니다. 따라서, NACL은 단기 차단 용도로 활용됩니다. 위 개발한 자동화 도구에서는 NACL이 가득 찼을 때, 이를 감지하여 가장 오래된 Item을 제거하고 새로운 Item을 등록합니다.
개발한 NACL-IR 도구의 차단 아키텍처는 자동과 수동이 있습니다. 자동은 SIEM에서 설정한 임계치 및 조건 경보를 활용해 자동으로 차단하는 로직입니다. 수동은 담당자의 판단이 필요한 이벤트에 대해서 즉시 대응이 가능하도록 구현한 로직입니다. 예를 들어, 이 글에서 다루고 있는 GuardDuty EC2/MaliciousIPCaller 이벤트가 발생했을 때, SOAR에서 Slack으로 이벤트 정보를 아래와 같이 전송합니다.

[수동 차단 요청 알림]

일반적인 Slack 메시지와 다르게 버튼이 구현되어 있는 것을 확인 가능합니다. 이벤트 분석 담당자가 수동으로 버튼을 클릭하면 Slack으로 NACL-IR에 차단 요청이 전송되고 전체 계정의 NACL에 차단 등록되게 됩니다. 이러한 상호작용을 위해 Slack 인터랙티브(Interactive) 메시지로 구현했습니다.

[수동 차단 수행 알림]

Slack 채널에 여러 위협 모니터링 담당자가 참여하고 있지만 차단은 중요한 작업이기 때문에 Slack으로부터 SOAR가 받은 응답 정보 내에 사용자 정보를 검증하여 권한 있는 담당자의 클릭에만 동작할 수 있도록 하여 장애 및 사고 위험을 낮추었습니다.

[실시간 차단 등록 알림]

[NACL-IR 등록 일일보고 알림, 주간보고 알림]

또한, NACL-IR의 DB(ddb)를 별도 관리하여 동작 시마다 모든 계정에 동일한 Item이 들어가 있는지 무결성을 검증하고 이 DB를 기준으로 실시간, 일별, 주별, 보고서를 생성하여 가시성을 제공합니다. 주간 보고 내용을 기준으로 반복 위협이 되는 고위험 IP를 확인할 수 있고 해당 IP들은 TIP에 등록하여 높은 위협 레벨에서 모니터링하고 일부는 장기 차단 아이템으로 관리합니다.
결과적으로 자동화 도구와 아키텍처로 빠르고 효율적으로 대응할 수 있게 되었습니다. 특히 24/365 대응이 필요한 침해대응 특성상 자동으로 대응하는 아키텍처는 필수라고 볼 수 있습니다. SIEM-SOAR구성으로 다양한 시나리오와 임계치를 조정해가며 단기차단이더라도 적절한 차단 시간을 유지하고 효과적으로 방어할 수 있도록 다양한 연구와 테스트를 진행하고 있습니다.

잠재적인 위협 대응

침해대응의 핵심 중 하나는 단순히 발생한 사고를 처리하는 것을 넘어, 미래의 위협을 예측하고 사전에 차단하는 선제적 대응 능력이라고 생각합니다. 고도화된 침해대응 체계는 사고 발생 가능성을 최소화하고 조직의 전반적인 보안 태세를 강화하는 방향으로 진화해야 합니다.

[GuardDuty Event]

이 글에서 다루고 있는 199.x.x.226 IP와 통신하여 탐지된 EC2/MaliciousIPCaller.Custom 이벤트는 GuardDuty 위협 목록에 등록되어 있던 악성 IP와 내부 워크로드(EC2)가 Outbound 통신을 한 이벤트이며, 실제 워크로드가 통신한 DNS 로그와 보조지표 데이터를 보니 악성 도메인은 아니었습니다. 다만, 하나의 IP는 여러 도메인과 매핑될 수 있는 특징이 있고 이 IP가 GuardDuty 위협 목록에 등록되어 있다는 것은 보안팀의 위협 인텔리전스 관리 구성상 과거에 악성으로 활용됐던 도메인에 연결되어 있었을 가능성이 높습니다.
그럼 이 IP 정보를 역으로 조회하여 과거 연결되었던 악성 도메인들을 추출하고 이 도메인들을 DNS Firewall에 미리 등록한다면 침해대응 시나리오상 이후 다른 서버가 감염되더라도 최소한 이 IP와 연결된 악성 도메인과의 통신은 선 차단할 수 있다는 아이디어를 도출해냈습니다.
일각에서는 “하나의 IP와 연결되었던 과거 악성 도메인과의 통신 확률이 얼마나 되겠느냐”와 같은 의문을 제기할 수 있습니다.
물론, 확률은 낮을 수 있지만 선제적인 침해대응의 시나리오는 특정 사건의 발생 확률보단 잠재적인 위협 제거에 초점을 맞추어 논의하는 것이 더 중요하다고 생각합니다. 이는 결과적으로 모든 잠재적 위협에 대비해야 한다는 보안 원칙과도 부합합니다.

[악성 DNS 추출 및 DNS FW차단 플레이북 아키텍처]

이 아키텍처는 평판 도구(Reputation Tool)의 Passive DNS 형태의 TI를 활용해 악성 IP와 연관된 도메인을 추출하고, 잠재적인 보안 위협을 조기에 식별하여 대응할 수 있도록 설계되었습니다.

Passive DNS는 DNS 요청 및 응답 데이터를 수집하고 이를 데이터베이스에 저장하여 과거의 DNS 해석 기록(히스토리)을 분석할 수 있도록 제공하는 기술입니다.

위 그림에서 extract-rdns-ir lambda의 동작은 GuardDuty가 탐지한 Outbound IP와 매핑되었던 과거 도메인 정보를 TI 도구에서 조회하여 가져오고 이 정보 중에서도 악성 점수 이력이 있는 DNS 정보를 추출합니다. extract-rdns-ir lambda는 다음 모듈로 개발 구성되어 있습니다.

• API 통신 모듈:
  • Reputation Tool API에 도메인 및 IP 스캔 요청을 보냅니다. 각 도메인의 위험 점수를 가져오고, 이를 기반으로 도메인을 분류합니다.
• 도메인 정보 추출:
  • API로부터 해당 IP와 연결된 도메인 리스트와 각 도메인 정보를 추출합니다.
• 스코어 계산 및 필터링:
  • 도메인에 대해 Score를 조회하고 중요도(Critical)에 해당하는 도메인만 선별합니다.
• 멀티스레딩 모듈:
  • ThreadPoolExecutor를 이용한 멀티스레딩을 통해 여러 도메인에 대한 데이터를 병렬로 처리합니다. 각 도메인의 스코어를 계산하고 위험 수준이 높은 도메인을 식별합니다.
• TIP 연동 모듈 :
  • 분석 결과를 Lambda(to-tip)로 전달하여 TIP에 등록합니다.

• 메시지 전송 모듈:

  • 분석된 도메인 정보를 바탕으로 Slack Webhook을 사용하여 알림을 전송합니다.

  

  [도출된 악성 Critical DNS 정보 보고 알림]

to-tip lambda의 동작은 TIP에 악성 도메인 정보를 등록하고 TIP에서 제공하는 Critical Score 도메인 정보는 DNS Firewall에 등록하여 전체 계정의 VPC 레벨에서 차단 등록됩니다.

정리

본 글에서는 GuardDuty에 대한 이해로 시작하여 특정 이벤트에 대한 면밀한 분석을 통해 도출된 인사이트를 바탕으로 효율적인 모니터링과 GuardDuty 한계 확인, 신뢰도 향상을 위한 TI, TIP를 활용한 보조지표 그리고 자동 차단 플레이북 개발 과정을 다뤘습니다. 또한, 악성 IP와 연관된 도메인 정보를 활용하여 잠재적 위협 정보를 도출하고 선제적으로 차단하는 침해 대응 전략, 아키텍처를 제시하였습니다.
공격자가 정교해지는 만큼 반대로 다양한 위협 요소를 분석하고 도출된 인사이트를 기반으로 선제적인 대응 전략과 아키텍처를 수립하는 것이 중요하다는 이야기와 함께 누군가에게 도움이 되기를 바라며 이 글을 마무리합니다.