"Silk Typhoon Exploits Cloud Trust Relationships to Spy on North American Organizations"

🌩️ Silk Typhoon, 클라우드 신뢰 관계를 이용한 첩보 작전

중국 국가안전부(MSS)와 연계된 것으로 알려진 Silk Typhoon(Hafnium, Murky Panda)이 다시 움직이고 있습니다.
이번에는 전통적인 서버 취약점 공격이 아니라,
클라우드 신뢰 관계(Trusted Relationships in the Cloud)를 악용하는 새로운 형태의 공격이 포착되었어요.

이들은 북미 지역의 정부 기관, 첨단 기술 기업, 대학, 법률·전문 서비스 조직 등을 대상으로
간접적이고 교묘한 접근법을 사용했습니다.
단일 피해자를 정면으로 공격하는 대신,
SaaS 공급자나 클라우드 서비스 파트너 같은 제3자를 먼저 침해한 뒤,
그 관계를 발판 삼아 진짜 목표에 접근하는 방식입니다.

---

🕵️ Silk Typhoon의 진화: Exchange 해킹에서 클라우드 스파이로

Silk Typhoon은 2021년, 전 세계적으로 큰 충격을 줬던 Microsoft Exchange 제로데이 공격으로 이름을 떨쳤습니다.
당시 수많은 글로벌 조직이 웹셸(web shell)과 백도어에 감염됐죠.

하지만 시간이 지나면서 이들은 공격 초점을 클라우드와 공급망으로 옮겼습니다.

• SOHO(소규모 사무실/가정용) 장비 취약점 활용
• Citrix NetScaler ADC 취약점(CVE-2023-3519) 악용 → 인증 없는 원격 코드 실행(RCE) 가능
• SaaS 제공업체 환경 침투 → 공급자 권한 탈취 후 고객사 공격

특히 CVE-2023-3519처럼 9.8 CVSS 치명도 취약점도 한동안 패치되지 않은 상태로 남아 있었는데,
이런 지점을 Silk Typhoon이 놓칠 리 없었습니다.

---

☁️ 클라우드 신뢰 관계 공격이란?

클라우드 환경은 편리하지만, “신뢰(Trust)”라는 보안 허점이 존재합니다.

• 앱 등록(App Registration), 서비스 프린시펄(Service Principal),
  크로스 테넌트 권한 등은 통합을 쉽게 하기 위해 설계됐습니다.
• 하지만 이런 권한이 과도하거나 관리되지 않으면,
  한 번의 침해로 여러 환경이 줄줄이 뚫리는 “도미노 효과”가 발생합니다.

Silk Typhoon은 바로 이 점을 노린 겁니다.

📌 공격 사례 1: SaaS 공급자 침해

공격자는 SaaS 업체의 애플리케이션 등록 비밀(App Registration Secret)을 훔쳐,
고객사의 클라우드 계정에 애플리케이션 자체로 인증할 수 있었습니다.
즉, 고객은 정상적인 앱이 로그인한 줄 알았지만, 사실상 공격자가 침투한 상황이었죠.

📌 공격 사례 2: Microsoft 클라우드 솔루션 제공업체 침해

Silk Typhoon은 한 CSP(Cloud Solution Provider)의 Admin Agent 계정을 해킹했습니다.
이 계정은 고객들의 Entra ID(구 Azure AD) 테넌트에 대해 전역 관리자(Global Admin) 권한을 가질 수 있었어요.
이론적으로 수백, 수천 고객사를 동시에 공격할 수 있는 권한이었지만,
이들은 한 고객에 집중해 다층적 지속성을 구축하고 이메일을 빼돌렸습니다.

---

🐍 CloudedHope: 맞춤형 스파이웨어

Silk Typhoon이 사용한 무기는 CloudedHope라는 맞춤형 악성코드였습니다.

• Golang 기반 RAT(Remote Access Trojan)
• 리눅스 시스템 전용
• 안티-분석 기능 내장 → 분석 시 위장(decoy) 동작 수행
• API 호출과 클라우드 자격 증명 탈취에 최적화

즉, 단순한 백도어가 아니라 클라우드 환경에서 은밀하게 활동하도록 설계된 정찰·스파이 툴입니다.

---

🔍 클라우드 보안의 딜레마

전문가들은 클라우드가 본질적으로 가진 이중성을 지적합니다.

• 장점:
  • 공급업체들이 제로데이를 빠르게 패치
  • 멀티 테넌트 환경이라 로그와 추적 데이터가 풍부 → 공격 흔적을 잡을 기회 多
• 단점:
  • 클라우드의 신뢰 모델은 기본적으로 “기본 신뢰(Default Trust)”에 의존
  • 한번 신뢰를 얻으면 정상 관리 활동처럼 위장 가능
  • 공격자가 SaaS 공급자 하나를 뚫으면 수많은 고객사로 확산 가능

즉, 클라우드 보안은 빠른 패치와 모니터링에서는 유리하지만, 구조적 신뢰 문제에서는 취약하다는 겁니다.

---

🛡️ 방어 전략: Zero Trust at Identity Layer

Silk Typhoon의 사례에서 교훈을 얻자면, “아이덴티티 보안이 곧 클라우드 보안”이라는 점입니다.

조직이 취할 수 있는 대응책은 다음과 같습니다.

1. Zero Trust 적용
   • 서비스 프린시펄, 앱 등록, 크로스 테넌트 권한에 대해 기본 거부(Default Deny) 원칙 채택
2. 공급망 위험 관리
   • SaaS 및 클라우드 공급자의 보안 인증·로그 관리 수준 점검
3. 행위 기반 탐지
   • 글로벌 관리자 권한 사용, API 호출 패턴 등에서 비정상 행위 감지
4. 로그 상관 분석
   • IAM, 클라우드 제공자, 테넌트 로그를 연계 분석해 공격 흐름 파악

---

✨ 정리하며

Silk Typhoon은 단순한 제로데이 해커 집단이 아닙니다.
클라우드 신뢰 구조 자체를 악용하는 전략적 플레이어입니다.
이번 사례는 “내 회사는 클라우드 공급자를 믿으면 된다”는 안일한 생각이 얼마나 위험한지 보여줍니다.

• 클라우드는 편리하지만, 공급자-고객 간 신뢰 관계가 곧 공격 표면이 됩니다.
• Zero Trust 원칙이 말뿐이 아닌 아이덴티티 보안 차원에서 구현돼야 할 때입니다.

앞으로도 국가 주도형 위협 그룹들은 SaaS 공급자와 클라우드 MSP를 노려,
훨씬 더 은밀하고 체계적인 첩보 작전을 벌일 가능성이 큽니다. 🚨