“정문 열고 들어온 해커” AWS 자격증명 탈취해 악성 메일 살포한 트러플넷

“정문 열고 들어온 해커”… AWS 자격증명 탈취해 악성 메일 살포한 트러플넷 주의보

클라우드 환경에서 가장 무서운 공격은 때로는 취약점 익스플로잇이 아니라 단순한 “정상 로그인”입니다. 최근 연구에 따르면 사이버 공격자들이 노출된 AWS 자격증명을 훔쳐, 아마존의 공식 메일 전송 서비스인 SES(Simple Email Service)를 이용해 대규모 피싱·스팸 메일을 발송하는 사례가 포착됐습니다. 공격 인프라는 ‘트러플넷(TruffleNet)’이라는 이름으로 불리고 있습니다. 0

1. 트러플넷이 노린 것: 합법 서비스 안에 숨기

포티넷(Fortinet) 산하 포티가드 랩스(FortiGuard Labs)는 최근 보고서를 통해, 공격자들이 트러플넷이라는 인프라를 구축하고 AWS SES를 악용해 피싱·스팸 메일을 대량 발송하는 캠페인을 분석했습니다. 이 인프라는 전 세계 800개 이상 호스트, 50여 개 이상의 네트워크에 걸쳐 운영되는 대규모 구조로 파악됐습니다. 1

핵심 포인트는 다음 한 줄로 요약됩니다. “악성 SMTP 서버를 만드는 대신, 이미 신뢰받는 AWS 메일 인프라 안으로 들어가 버린 것”입니다. 공격자는 훔친 AWS 키로 SES를 설정하고, 정상 도메인에서 발송된 것처럼 보이는 이메일을 대량으로 살포합니다.

2. 훔친 것은 서버가 아니라 ‘열쇠’… IAM API 키 탈취

이번 공격에서 사용된 것은 AWS 계정의 IAM API 키(Access Key)입니다. 이 키는 AWS 리소스에 접근하기 위한 디지털 열쇠 역할을 합니다. 키가 노출되면 공격자는 별도의 악성 서버 구축 없이도, 피해자의 AWS 계정 안에서 정식 사용자로 위장할 수 있습니다. 2

포티넷에 따르면 트러플넷 운영자는 노출된 키를 활용해 다음과 같은 과정을 수행했습니다.

• 오픈소스 도구 트러플호그(TruffleHog)로 인터넷 전반에서 유출된 AWS 키 자동 스캔
• 유효한 키인지 확인하기 위해 GetCallerIdentity API 호출
• SES 발송 한도를 확인하기 위해 GetSendQuota 요청 수행
• 이후 SES 설정을 통해 피싱·스팸 메일 발송 인프라 구축

즉, 공격자는 “어디를 공격할지”보다 먼저 “어떤 키가 살아 있는지”부터 자동으로 검사하며, 쓸 수 있는 계정들을 골라내 인프라로 편입하고 있습니다.

3. AWS SES를 악용한 대규모 악성 이메일 캠페인

트러플넷은 도난된 AWS 계정을 SES에 연결해 다음과 같은 방식으로 메일을 살포합니다. 3

• 피해자 계정의 SES를 ‘프로덕션’ 모드로 전환해, 임의의 수신자에게 대량 발송 가능 상태로 변경
• 도메인키(DKIM)를 설정해, SPF·DKIM 검증을 통과하는 “정상 이메일”처럼 보이도록 위장
• 침해된 워드프레스(WordPress) 사이트 등에서 훔친 도메인을 발신 도메인으로 사용
• 피싱 링크, 암호화폐 지갑 탈취 페이지, 악성 스크립트 등을 메일 본문에 삽입
• 경우에 따라 일반 마케팅 메일 레이아웃을 모방해 수신자의 의심을 최소화

수신자나 보안 게이트웨이 입장에서는 메일이 “AWS 공식 SES 인프라에서 발송된 정상 메일”로 보이기 쉽습니다. 전통적인 IP 평판 기반 차단이나 “수상한 SMTP 서버 차단” 전략만으로는 탐지가 어려운 이유입니다.

4. IP 차단이 통하지 않는 이유: 평판은 정상, 행동은 악성

포티가드 랩스 분석에 따르면, 트러플넷에서 사용된 상당수 IP는 악성 평판이 없는 클린 IP였습니다. VPN, TOR, 알려진 스팸 발송 서버가 아니라, 신규로 세팅된 클라우드 호스트 위주였기 때문입니다. 4

또한 공격자들은 Portainer 같은 합법적인 컨테이너 관리 도구까지 활용해, 수백 개의 호스트를 한 번에 관리하고 업데이트하는 “클라우드형 C2 인프라”를 구성했습니다. 이처럼 합법 서비스·합법 도구를 적극적으로 재활용하기 때문에, 단순 IP 차단과 시그니처 기반 탐지로는 한계가 분명합니다.

5. 기업이 당장 점검해야 할 자격증명 보안 체크리스트

트러플넷 사례가 보여주는 메시지는 명확합니다. “합법적인 키가 곧 공격 인프라”라는 점입니다. 보안 담당자 입장에서 바로 점검해 볼 수 있는 항목들을 정리하면 다음과 같습니다.

• IAM 키 노출 여부 상시 스캔 – GitHub·GitLab·사내 코드 저장소·CI/CD 로그에 키가 남아 있지 않은지 비주기적이 아닌 상시 점검이 필요합니다. TruffleHog 같은 도구를 공격자보다 먼저, 수비 측에서 활용하는 접근이 중요합니다. 5
• 키 주기적 교체와 최소 권한 원칙 – 장기간 사용되는 루트 키, 광범위한 권한을 가진 액세스 키는 즉시 분리·축소하고, 역할 기반 접근 제어(RBAC)를 적용해야 합니다.
• 비정상 API 호출 모니터링 – GetCallerIdentity, GetSendQuota, PutAccountDetails 등 SES 관련 API 호출이 짧은 시간 안에 여러 리전에서 반복된다면 강력한 의심 신호입니다. 6
• MFA와 조건부 액세스 정책 – 콘솔 로그인뿐 아니라, 중요 운영 계정에는 가능한 한 MFA를 요구하고, 필요 시 IP·리전 기반 제약을 함께 두는 것이 좋습니다.
• 행위 기반 이상 탐지(Behavior Analytics) – “악성 파일”만 찾는 것이 아니라, 계정 사용 패턴 변화(발송량 급증, 새로운 리전 사용, 갑작스러운 SES 설정 변경 등)를 탐지하는 보안 분석 체계가 필요합니다. 7

6. 클라우드 보안 관점 전환: 외부 공격보다 ‘내부 행위’ 주시

이번 트러플넷 사례는 공격자가 더 이상 기업 경계 밖에서만 움직이지 않는다는 사실을 잘 보여줍니다. 계정만 탈취하면, 공격 인프라·발송 서버·호스팅까지 모두 피해자의 클라우드 환경으로 대체할 수 있습니다.

따라서 보안 전략도 단순히 “외부에서 들어오는 공격을 막는 것”에서, “클라우드 안에서 일어나는 계정·API 사용 행위 자체를 분석하는 것”으로 바뀌어야 합니다.

• 클라우드 계정·역할·API 호출 로그를 중앙에서 수집하고, AI/ML 기반으로 이상 패턴 분석
• BEC(기업 이메일 탈취) 공격을 염두에 두고, 이메일 보안 솔루션과 클라우드 로그를 연계 분석
• 조직 내에서 실제로 사용하지 않는 클라우드 서비스·권한은 과감하게 제거

결국 “해킹을 막는 것”만큼이나, “이미 탈취됐을지도 모를 계정이 무엇을 하고 있는지 보는 것”이 중요해진 시대입니다.

7. 마무리 – 자격증명은 더 이상 단순한 비밀번호가 아니다

트러플넷 캠페인은 “악성 코드도, 제로데이도 필요 없다. 살아 있는 키 하나면 충분하다”는 현실을 보여줍니다. 열쇠를 잃어버린 상태에서 출입문 잠금장치를 강화하는 것만으로는 충분하지 않습니다.

클라우드 환경에서 IAM 키와 API 자격증명 관리는 더 이상 선택이 아니라 필수입니다. 키를 어디에 저장하고 있는지, 누가 언제 어떤 목적으로 사용하는지, 비정상적인 행위가 없는지에 대한 상시 가시성을 확보하지 못하면, 어느 순간 우리 조직도 트러플넷과 같은 인프라에 “조용히 편입”될 수 있습니다.

지금 이 순간, 코드 저장소와 클라우드 콘솔을 열어 “우리 조직의 열쇠는 어디에, 어떻게 보관되고 있는가”부터 점검해 보는 것이 가장 현실적인 첫 번째 방어선일 것입니다.