90. 정상 포트로 위장한 통신 — 443을 쓰는 비정상 트래픽

changseop lee·5일 전
C2JA3TLSsni보안관제비커닝

네트워크 · 패킷 분석

목록 보기
90/300

📚 네트워크 · 패킷 분석 › 02. 포트 · 프로토콜 분석 — 90편
이전 글: 89. 비표준 포트에서 동작하는 서비스 식별 · 다음 글: 91. IP + Port 분석
참고(리눅스 시스템 기초): 38. 비정상 네트워크 연결 탐지 — 호스트에서 수상한 ESTABLISHED 연결을 찾는 방법

1. 왜 알아야 하는가

20편이 "낯선 포트에서 무엇이 동작하는가"였다면, 이번 글은 반대 상황입니다. 포트는 아주 익숙한데(443) 그 안의 통신이 정상이 아닌 경우입니다.

감염된 호스트가 공격자 서버(C2, Command and Control)와 통신할 때 443을 선호하는 이유는 단순합니다.

  • 대부분의 조직에서 443 아웃바운드는 업무상 허용되어 있습니다.
  • 443 트래픽은 양이 많아 묻히기 쉽습니다.
  • TLS로 암호화하면 내용 검사가 어렵습니다.

그래서 관제에서 "443이니까 웹 브라우징"이라고 넘기면 가장 중요한 신호를 놓칠 수 있습니다. 이 글의 질문은 "443에서 정말로 웹 브라우징(HTTPS)이 통신하고 있는가"이며, 내용을 복호화하지 않고도 볼 수 있는 단서들을 정리합니다. 공격 도구의 구성·실행 방법은 다루지 않습니다.

2. 핵심 개념

2-1. 443 위장 통신의 유형

유형설명관찰 가능한 단서
TLS 기반 C2정상 HTTPS처럼 TLS로 통신연결 주기, 목적지 평판, 인증서, 클라이언트 지문
비TLS 프로토콜 on 443443을 쓰지만 TLS가 아닌 자체 프로토콜첫 바이트가 TLS(0x16)가 아님, IDS app_proto 판정 실패
정상 서비스 악용클라우드 스토리지·협업 도구·CDN을 중계로 사용도메인은 정상, 대신 사용 주체·양·시간대가 이상
암호화된 DNS(DoH)DNS 질의를 HTTPS로 전송내부 DNS 서버를 거치지 않는 이름 해석

2-2. 비커닝(Beaconing)

감염된 호스트가 C2 서버에 주기적으로 "명령 있나요?"라고 확인하는 통신을 비커닝이라고 합니다.

특징정상 웹 브라우징비커닝
연결 간격사용자 행동에 따라 불규칙일정(예: 60초마다), 또는 일정 간격에 무작위 편차(jitter) 추가
시간대업무 시간 중심야간·주말에도 계속
요청·응답 크기페이지마다 다양작고 비슷한 크기의 반복
목적지다수 사용자가 공통으로 방문조직 내 소수 호스트만 접속하는 드문 목적지

단, 정상 소프트웨어도 비커닝처럼 보입니다. 업데이트 확인, 백신 클라우드 조회, 메신저·메일 동기화, 텔레메트리가 대표적입니다. 그래서 주기성은 단독 판정 근거가 아니라 우선순위를 높이는 신호로 사용합니다.

2-3. 암호화돼도 보이는 것 (06편 복습)

06편에서 정리한 것처럼 TLS Handshake 일부는 평문입니다.

항목TLS 1.2TLS 1.3
SNI(접속하려는 도메인)보임보임 (ECH를 쓰면 숨겨짐, 아직 제한적으로 사용)
서버 인증서보임암호화됨 (패킷만으로 확인 어려움)
ClientHello의 암호 스위트·확장 목록보임보임
연결 시각·크기·지속 시간보임보임

2-4. TLS 클라이언트 지문: JA3와 JA4

같은 프로그램은 ClientHello를 항상 비슷한 모양으로 보냅니다. 이 모양을 요약한 값이 클라이언트 지문입니다.

구분내용주의점
JA3ClientHello의 TLS 버전·암호 스위트·확장·타원곡선·포인트 형식을 이어 붙여 MD5 해시같은 TLS 라이브러리를 쓰는 정상 프로그램과 값이 겹칠 수 있음. 확장 순서를 무작위로 바꾸는 브라우저가 늘면서 값이 불안정해짐
JA4프로토콜·버전·SNI 유무·개수·ALPN 등을 사람이 읽을 수 있는 앞부분과, 정렬된 목록의 해시로 구성(예: t13d1516h2_... 형태)순서 변화에 강하도록 설계됐지만 역시 단독 판정 근거는 아님

지문은 "이 연결을 만든 프로그램이 평소와 같은 종류인가"를 보는 보조 지표입니다. 공격자가 정상 브라우저의 지문을 흉내낼 수도 있으므로 지문 일치 = 정상, 불일치 = 악성으로 판단하지 않습니다.

3. 동작 원리

443 연결 하나를 복호화 없이 판단하는 흐름입니다.

비컨 간격 비교
그림 1. 443 포트라도 접속 간격이 지나치게 규칙적이면 추가 확인 대상입니다

 호스트 A → 203.0.113.50:443 연결 발견
      ↓
 ① 프로토콜: 첫 바이트가 TLS Handshake(0x16)인가?  ── 아니오 → 포트-프로토콜 불일치 (우선 조사)
      ↓ 예
 ② SNI: 도메인이 있는가? 평판·등록 시점·조직 내 방문 빈도는?
      ↓
 ③ 인증서(볼 수 있는 경우): 자체 서명? SNI와 이름 불일치? 발급 직후? 비정상적 발급자·유효기간?
      ↓
 ④ 클라이언트 지문(JA3/JA4): 이 호스트의 평소 브라우저·앱 지문과 다른가?
      ↓
 ⑤ 행위: 연결 간격이 규칙적인가? 야간에도 지속되는가? 크기가 일정한가? 연결이 매우 길게 유지되는가?
      ↓
 ⑥ 호스트: 이 연결을 만든 프로세스는 무엇인가? (브라우저인가, 알 수 없는 실행 파일인가)
      ↓
 여러 신호가 겹치면 → 우선순위 상향 → 호스트 조사·차단 검토

①~⑤는 네트워크 데이터로, ⑥은 호스트 데이터로 확인합니다. 네트워크 신호만으로 단정하지 않고 ⑥으로 확정하는 것이 핵심입니다.

4. 실제 명령어 / 실습

실습 환경: 본인 소유 Linux VM (Rocky Linux 또는 Ubuntu). 인터페이스 ens33은 예시입니다. 이 실습은 정상 HTTPS 통신을 관찰하고, curl 반복 실행으로 "규칙적인 연결"이 어떻게 보이는지 확인하는 것으로, 악성 코드나 C2 도구는 사용하지 않습니다.

4-1. 도구 설치

# Rocky Linux
sudo dnf install -y tcpdump curl openssl
# Ubuntu
sudo apt update && sudo apt install -y tcpdump curl openssl

4-2. 443 연결과 프로세스 연결 짓기

sudo ss -tnp state established '( dport = :443 )'

4-3. 목적지 인증서 확인 (SNI 지정)

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

-servername으로 SNI를 지정하지 않으면 다른 인증서(기본 인증서)가 돌아올 수 있습니다. SNI와 인증서의 관계를 이해하는 데 좋은 비교입니다.

4-4. 규칙적인 연결이 어떻게 보이는지 관찰

# 터미널 1: 443으로 나가는 새 연결(SYN)의 시각과 직전 연결과의 간격 출력
sudo tcpdump -ni ens33 -tt -l 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0 and dst port 443' \
  | awk '{ if (p) printf "%s  간격=%.1f초  %s\n", $1, $1-p, $5; fflush(); p=$1 }'
# 터미널 2: 30초마다 한 번씩 HTTPS 요청 (10회, 정상 사이트 대상)
for i in $(seq 1 10); do curl -s -o /dev/null https://example.com; sleep 30; done

다른 443 통신이 섞이면 간격이 흐트러지므로, 실습 중에는 브라우저 등 다른 프로그램을 꺼 둡니다.

📷 [실습 화면 삽입] openssl s_client로 확인한 인증서 subject·issuer·SAN·유효기간

📷 [실습 화면 삽입] tcpdump + awk로 출력한 443 연결 간격(약 30초 간격이 반복되는 모습)

5. 결과 확인

연결 간격 출력 형식 예시(값은 환경마다 다름)

1790000031.402113  간격=30.4초  203.0.113.50.443:
1790000061.815920  간격=30.4초  203.0.113.50.443:
1790000092.230551  간격=30.4초  203.0.113.50.443:

curl 실행 시간이 더해져 정확히 30초가 아니라 30초 남짓의 거의 일정한 간격이 나타납니다. 실제 비커닝 분석에서는 이런 간격의 분포(평균·표준편차)를 목적지별로 계산해 규칙성을 봅니다.

인증서 확인 결과 형식 예시(값은 환경마다 다름)

subject=CN = example.com
issuer=C = US, O = Example CA, CN = Example CA R1
notBefore=Aug 10 00:00:00 2026 GMT
notAfter=Nov  8 23:59:59 2026 GMT
X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com

점검 체크리스트

  • 443 연결마다 이를 만든 프로세스를 확인할 수 있는가(ss -tnp)
  • SNI와 인증서의 subject/SAN이 일치하는지 확인했는가
  • 규칙적인 연결 간격이 tcpdump 출력에서 어떻게 보이는지 확인했는가
  • 실습용 반복 요청을 종료했는가

6. 패킷 / 로그 분석

6-1. 정상일 수 있는 경우 vs 의심해야 하는 경우

관찰 내용정상일 수 있는 경우의심해야 하는 경우
규칙적인 443 연결업데이트 확인, 백신·EDR 클라우드 조회, 메일·메신저 동기화조직 내 다른 호스트는 접속하지 않는 드문 목적지로의 규칙적 연결
자체 서명 인증서내부 관리 콘솔, 개발 서버외부 IP·신규 도메인에서 자체 서명 또는 기본값 형태의 인증서
SNI 없음IP로 직접 접속하는 일부 장비·API일반 PC가 IP로 직접 443 연결을 반복
SNI와 인증서 불일치CDN·공유 호스팅의 설정 오류정상 서비스 도메인을 SNI로 쓰면서 전혀 다른 인증서를 받음
443인데 TLS 아님일부 VPN·터널 제품, 포트 다중화 설정알 수 없는 프로세스가 비TLS 프로토콜로 443 통신
드문 JA3/JA4 지문새 앱 설치, 브라우저 업데이트서버·PC에 설치되지 않은 클라이언트 유형의 지문이 등장
장시간 유지되는 연결웹소켓·스트리밍·원격 회의알 수 없는 프로세스의 수 시간 이상 유지되는 저용량 연결

6-2. IDS·NSM 로그에서의 모습

Suricata eve.json tls 이벤트 일부 형식 예시(값은 환경마다 다름)

{"event_type":"tls","src_ip":"192.168.10.50","dest_ip":"203.0.113.50","dest_port":443,
 "tls":{"sni":"update-check.example.net","subject":"CN=localhost","issuerdn":"CN=localhost",
        "version":"TLS 1.2","ja3":{"hash":"<32자리 해시>"}}}

이 예시에서는 SNI(update-check.example.net)와 인증서 subject(CN=localhost)가 맞지 않고 발급자도 자기 자신입니다. 단독으로 악성이라 할 수는 없지만 호스트 조사로 넘길 근거가 됩니다. (JA3 필드 기록은 Suricata 설정에 따라 활성화가 필요할 수 있습니다.)

6-3. 호스트에서 확정하기

# 의심 목적지와 연결된 프로세스 확인
sudo ss -tnp dst 203.0.113.50
# 해당 PID의 실행 파일 확인 (20편 절차)
sudo readlink -f /proc/<PID>/exe

7. 보안관제 관점

  • 흔적 위치: 프록시 로그(도메인·URL·User-Agent, 복호화 정책 적용 시 내용), 방화벽 세션 로그(목적지·바이트·지속 시간), IDS/NSM TLS 로그(SNI·인증서·지문), DNS 로그(해당 도메인 질의 이력), EDR의 프로세스-네트워크 이벤트.
  • 분석 순서: 목적지 드문도(조직 내 몇 대가 접속하는가) → 주기성 → TLS 속성 → 프로세스 확인. 하나의 신호보다 신호의 겹침을 봅니다.
  • 한계: TLS 1.3에서는 인증서가 암호화되어 패킷만으로 확인하기 어렵고, ECH가 확산되면 SNI도 보이지 않을 수 있습니다. 정상 클라우드 서비스를 중계로 쓰는 경우 목적지 평판도 도움이 되지 않습니다. 결국 호스트 데이터와의 결합이 필요합니다.
  • 오탐 주의: 규칙적 연결, 드문 지문, 자체 서명 인증서 모두 정상 소프트웨어에서 흔합니다. 화이트리스트(업데이트 서버, 보안 솔루션)를 관리하지 않으면 경보가 넘쳐 실제 신호가 묻힙니다.
  • 주기성 분석·상관분석 규칙 설계는 07. 네트워크 보안관제 통합 분석 시리즈, TLS 필드 단위 패킷 해석은 03. Wireshark 패킷 분석 시리즈, IDS의 TLS 룰 작성은 06. 방화벽 · IDS/IPS 분석 시리즈에서 다룹니다.

8. 핵심 정리

  • 443은 허용되어 있고 양이 많으며 암호화되어 있어 위장 통신이 선호하는 포트입니다.
  • 복호화 없이도 프로토콜 일치 여부, SNI, 인증서(볼 수 있을 때), 클라이언트 지문, 연결 주기·크기·지속 시간을 볼 수 있습니다.
  • 비커닝은 규칙적인 연결이 특징이지만 정상 소프트웨어도 같은 모양을 보이므로 단독 판정 근거가 아닙니다.
  • JA3·JA4 같은 클라이언트 지문은 보조 지표이며, 값이 겹치거나 흉내낼 수 있다는 한계가 있습니다.
  • 네트워크 신호로 우선순위를 정하고, 연결을 만든 프로세스를 확인해 확정합니다.

다음 글: 22. 내부망 필수 포트와 외부 노출 금지 포트

profile
changseop lee
코드에 숨겨진 위협을 읽고 AI로 보안의 미래를 설계합니다. 프론트엔드 개발 경험을 자산 삼아 더 견고하고 지능적인 보안 운영 시스템을 구축해 나가는 과정을 기록합니다
이전 포스트

89. 비표준 포트에서 동작하는 서비스 식별

다음 포스트

91. IP + Port 분석

0개의 댓글