시나리오 1-1
우선, 제공되는 방화벽 로그 사이트에서 필요 이상만큼의 네트워크 패킷 파일을 다운로드하고 합쳐줬다.
C2 Beacon을 찾아야하므로, Beacon Interval을 띌 것이고, 패킷 크기는 request가 짧고 response는 거의 없는 경우가 있을 것이다. 우선 그것을 염두해두고 분석하기 시작했다.

패킷 I/O 그래프를 그리면 다음과 같다.
하지만 여기는 큰 패킷에 length가 작은 패킷들은 많이 안 보이기에 fliter를 계속 바꿔가며 주기성이 있는 패킷들을 구분하였다.
또한 네트워크 패킷 로그에서 10.0.0.48 기준으로 외부 IP에 얼마나 자주 트래픽이 나가는지 conversations으로 목록을 뽑았다.
15.164.209.197, 15.169.254.169, 15.164.209.134 등 여러 아이피를 조회하다 10.0.0.48 → 15.164.209.134 에서 2151초 간격으로 MDNS 패킷을 쏘는 걸 확인했다.

I/O 그래프로 그리면 다음과 같다.

MDNS로 분류되어있고 5353/UDP를 사용하지만 송신대상이 15.164.209.13으로 날리기에 C2로 판별했다.
같은 방식으로 파일 업로드한 아이피만 잡으면 된다. ip.src==10.0.0.48로 출발지 잡고 conversations를 집계해보면 15.164.209.197(ssh), 169.254.169.123(ntp) 다음으로 43.202.71.135, 43.202.74.64, 43.202.70.20, 169.254.169.254(aws) 등이 식별됐다.

aws ssm이나 시스템 관련 패킷이 많이 식별되어서 필터를 거치고 이상 패킷을 확인해봤는데, 43.200.69.196에서 80포트로 http→웹소켓을 확인했다.

GET / HTTP/1.1Host: 43.200.69.196:80Upgrade: websocketConnection: UpgradeSec-WebSocket-Key: VKnSKBIY52neTsKA3YzA8Q==Sec-WebSocket-Version: 13해당 서버는 Python/3.11, websocket/12.0 헤더로 101 Switching Protocols 응답을 주고 클라이언트가 1349Byte WebSocket 프레임을 전송한다.
여러 스트림에서 동일하게 댜랭의 바이너리 데이터를 즉시 보내는 패턴이 반복됐고 inbound보다 outbound가 대다수인 것을 보아 업로더가 맞다고 판단했다.
정리하자면
Beacon 주기: 2151초
Beacon C2: 15.164.209.134
데이터 업로드 대상: 43.200.69.196
fiesta{2151_15.164.209.134_43.200.69.196}