C2는 침해 후 공격자가 기기를 계속 조종하는 데 쓰는 트래픽입니다. 작동 원리와 포착·차단 방법을 살펴봅니다(공격 도구나 운영 세부 사항은 다루지 않습니다).
공격 흐름에서의 위치
C2는 침해 자체가 아니라 그 이후에 옵니다.
중요한 점은 (2)의 아웃바운드 트래픽이 탐지하고 끊을 기회라는 것입니다. 침해를 100% 막기는 어렵지만, 아웃바운드 트래픽 단계에서 알아채고 멈출 여지는 있습니다.
C2, 백도어, 봇넷의 차이
이 용어들은 자주 섞여 쓰입니다. 역할별로 나누면 다음과 같습니다.
| 용어 | 뜻 | C2와의 관계 |
|---|---|---|
| C2(C&C) | 공격자와 감염된 기기 사이의 원격 제어 통로, 그리고 명령을 보내는 서버 | — |
| 백도어 | 정상적인 인증을 우회하도록 기기에 남겨진 출입구 | C2와 통신해 명령을 받는 경우가 많음 |
| 봇넷 | 같은 C2에서 한꺼번에 명령을 받는 대량의 탈취된 기기 집단 | C2가 한 곳에서 많은 기기를 조종 |
| RCE | 원격에서 임의의 코드를 실행할 수 있게 하는 취약점 | C2 이전 단계인 침해를 일으키는 수단 중 하나 |
| 비콘 | 기기가 일정한 간격으로 C2에 보내는 짧은 통신 | C2가 아직 활성 상태라는 징후 |
정상 트래픽에 섞여드는 이유
공격자의 기법을 정리한 MITRE ATT&CK은 C2를 독립된 단계(TA0011)로 다루며, 공격자가 감염된 시스템을 조종하기 위해 통신하려는 단계라고 정의합니다. 대표적인 기법으로는 웹이나 DNS 같은 일상적인 프로토콜을 써서 기존 트래픽에 섞여들고 탐지와 필터링을 피하는 방식을 들고 있습니다.
그래서 특정 포트 번호를 막는 것만으로는 부족합니다. ATT&CK이 제시하는 완화책은 네트워크 트래픽 필터링과 네트워크 침입 방지입니다. 실무에서는 두 가지 발상이 효과적입니다.
- 목적지로 제한한다: 서버가 접속해도 되는 목적지를 허용 목록으로 정하고, 그 밖의 아웃바운드 트래픽은 막는다
- 모양으로 알아챈다: 내용이 아니라 목적지, 간격, 양, 통신하는 프로그램을 본다
포착하는 법(단서)
| 단서 | 무엇을 볼 것인가 |
|---|---|
| 비콘(주기적 트래픽) | 같은 목적지로 일정 간격마다 나가는 규칙적인 아웃바운드 트래픽 |
| 낯선 목적지 | 의심스러운 도메인·IP(알려진 악성과 대조 = IOC) |
| 이상한 DNS | 낯선 도메인에 대한 질의, 비정상적으로 많은 DNS |
| 예상치 못한 경로 | 예상치 못한 포트·프로토콜로 나가는 트래픽 |
방어하는 법
애초에 침해당하지 않기(기본)
아웃바운드 트래픽 제한(이그레스)
DNS와 트래픽 로그 모니터링
알려진 악성 목적지 대조·차단
실제 사례: 아웃바운드 트래픽이 단서가 된 경우
이 사이트에서 다룬 Codecov 침해(2021년)에서는 CI에서 실행되는 배포 스크립트가 변조되어, 약 두 달 동안 고객의 CI 환경에서 비밀 정보가 외부 서버로 전송된 것으로 알려졌습니다. 변조된 코드는 고객 자신의 코드가 아니었기 때문에 자사 코드를 검토해서는 발견할 수 없었습니다.
사후에 확인할 수 있는 단서는 CI에서 낯선 목적지로 나간 아웃바운드 트래픽입니다. CI의 아웃바운드 트래픽을 필요한 목적지로만 제한하고 그 밖의 통신을 기록하고 있었다면, 전송을 막거나 더 일찍 알아챌 여지가 있었습니다. C2든 데이터 탈취든, 침해 이후의 공격은 목적을 이루려면 외부와 통신해야 합니다.
자신의 환경에서 확인하는 방법
- 현재의 외부 연결 목록 보기: Windows에서는
Get-NetTCPConnection -State Established로 연결마다 목적지와OwningProcess(통신 중인 프로그램의 ID)를 볼 수 있고,Get-Process -Id <ID>로 프로그램 이름을 알 수 있습니다. Linux에서는ss -tunp가 같은 역할을 합니다 - 클라우드의 아웃바운드 규칙 점검: 예를 들어 AWS의 기본 보안 그룹은 모든 아웃바운드 트래픽을 허용합니다. 서버가 실제로 접속해야 하는 곳(OS 업데이트, 결제·메일 API 등)을 적고 나머지는 제한합니다
- DNS 질의 이력 확인: 라우터나 DNS 서비스의 로그에서 낯선 도메인에 대한 질의가 일정한 간격으로 반복되는지 봅니다
- 목적지별로 집계: 프록시나 방화벽 로그를 목적지별로 모아, 하루 종일 같은 간격으로 적은 양의 통신이 이어지는 곳을 찾습니다. 찾으면 목적지의 소유자를 확인해 정상적인 업데이트 확인인지 구별합니다
- 공개된 목적지와 대조: 당국이나 보안 업체가 공개한 C2 목적지(IOC)로 로그를 검색합니다
이 사이트의 관점: 아웃바운드 트래픽도 지키고, 'C2 없음' 확인도 조사의 일부로 삼는다
C2 개념이 주는 가장 큰 교훈은 방어가 침해 예방에만 있는 것이 아니라는 점입니다. 완벽한 예방이 어렵더라도, 아웃바운드 트래픽을 제한하고 의심스러운 콜백을 알아챌 여지가 있습니다. 이 사이트는 '침해당하지 않는 설계(패치, 최소 권한, MFA)'를 주된 목표로 두면서, 이그레스 제어와 트래픽 모니터링을 마지막 방어 계층으로 함께 유지합니다. 침해가 의심될 때는 잔존 C2(백도어나 정체불명의 주기적 트래픽)가 없는지 확인하는 것이 핵심 단계입니다. '영향은 제한적이었다'고 결론짓기 위해서는 아웃바운드 트래픽 점검을 건너뛸 수 없습니다.
출처(1차 자료)
- MITRE ATT&CK, "Command and Control (TA0011)" — attack.mitre.org(C2 단계의 정의)
- MITRE ATT&CK, "Application Layer Protocol (T1071)" — attack.mitre.org(기존 트래픽에 섞여들기, 트래픽 필터링 등의 완화책)
- AWS, "Default security groups for your VPCs" — docs.aws.amazon.com(기본 아웃바운드 규칙)
- Codecov의 출처는 사례 기사에 실려 있습니다
다음으로 읽기
- 사례: Codecov 침해(2021년) · Capital One 유출(2019년)
- 용어집: EDR이란 · 백도어란(C2와 통신하는 거점) · RCE란 · IOC란 · IOA란 · 랜섬웨어란 · 악성코드란