[2026-06-30] Beyond RTT An Adversarially Robust Two-Tiered Approach for Residential Proxy Detection

Background

Residential IP proxy : 일반 가정용 기기를 프록시 노드로 변환하여 사용자의 인터넷 연결을 통해 외부 트래픽을 라우팅. 클라이언트는 RESIP (주거용 IP) 주소를 사용하여 인터넷 트래픽을 우회함.

• 동작 흐름

  

  1. 일반 사용자의 기기가 켜지면 프록시 업체의 중앙 제어 서버 및 Gateway 서버와 연결을 맺고 대기
  2. 클라이언트가 타겟 서버로 접속하기 위해 중앙 Gateway 서버로 트래픽을 보냄
  3. Gateway는 터널링이 연결되어 일반 기기 중 하나를 선택하여 트래픽을 밀어 넣음
  4. 일반 기기는 타겟 서버와 TCP 핸드셰이크
  5. 클라이언트는 프록시 노드에 TLS Client Hello를 보내 타겟 서버와 TLS handshake를 진행
     • 프록시 노드는 키가 없기 때문에 Relay만 가능

• RESIP 확보 방법

  1. 프록시 업체에서 사용자에게 돈을 주고 프록시 노드 변환 앱 설치를 유도
  2. 모바일 앱 개발자가 프록시 SDK를 자신의 애플리케이션에 통합하여 무료 앱을 수익화 가능하게 함
     • SDK : Software Development Kit. 코드 라이브러리, API, 디버거 등을 제공하는 패키지
  3. 악성 코드에 감염되어 프록시 노드로 참여

Threat Model & Motivation

Defender

• ISP :트래픽에 대한 Full visibility가 있음. 어떤 기기가 Proxyware를 실행 중인지 (어떤 기기가 프록시 노드인지)와 해당 기기에서 프록시 기기 소유자의 배경 트래픽과 중계 트래픽을 구분할 수 있는 지가 목표
  • 공격자들의 공격 통로로 사용되면 IP 대역의 평판이 하락됨.
  • 프록시는 대규모 크롤링이나 DDoS에 사용되는 데, 이와 같은 경우 네트워크 비용이 증가하며 서비스 장애도 생길 수 있음
• Content Provider : 서버에 들어오는 패킷만 관찰 가능. 들어오는 연결이 합법적인 트래픽인지 중계 트래픽인지 판단하는 것이 목표
  • 조회수나 좋아요 부풀리기, 가짜 참여, 웹 스크래핑 같은 공격 탐지를 위해 프록시 식별

기존 연구: Cross-layer RTT discrepancies

• TCP handshake는 node-server와 한 후 클라이언트와 server 사이에 TLS handshake
• 물리적인 거리로 인해 초반 몇 개의 패킷의 RTT로 구분 가능

• Scheduling attack

  트래픽 스케쥴링을 통해서 RTT 불일치 패턴을 없앰. 예를 들어, TLS ClientHello를 Node에 버퍼에 저장하여 TCP 연결이 설립되면 발송

  • 위와 같은 방식만 사용해도 초반 8개가 아닌 64개를 보는 분류기에 대해서도 성능이 99% → 8%로 저하

→ RTT와 같은 Superficial Feature (피상적인 특징)은 임의로 조작하기 쉽기 때문에 공격자가 조작하기 어려운 새로운 핑거프린트 기반 탐지 방법이 필요

EarnApp

새로운 핑거프린트를 찾기 위해서 데이터를 수집하고 분석

Experimental Setup and Data Collection

• Testbed : Android 에뮬레이터로 구성
• Python script를 활용하여 웹사이트 방문 및 사용자 상호작용
• Challenge
  • 기존 연구에서는 데이터셋에 배경 데이터의 주입하는 방식으로 프록시 트래픽과 정상 트래픽 사이의 네트워크 상태, 기기 환경 등의 불일치 문제 발생
  • 동일한 환경에서 프록시 트래픽과 배경 트래픽을 동시에 캡처하는 환경을 구축
• 사용자 행동 시뮬레이션
  • Tranco 리스트에서 도메인 목록 선별
  • User profile
    • Light : 페이지 로드 간격을 20초 ~5분
    • Medium : 페이지 로드 간격을 20초 ~1.5분
    • Heavy : 2초 ~ 20초 간격
    • 각 웹페이지에서 간단한 스크롤 동작을 수행 후 다른 사이트 링크를 무작위로 클릭
  • 업로드 비중 설정
    • 프록시는 외부 요청을 받아 데이터를 전달하기 때문에 업로드의 비중이 높음
      • 사용자 시뮬레이션 중 단순 웹사이트 반복은 다운로드만 하기 때문에 모델이 업로드 비중이라는 feature에 의존할 수 있음
      • 이는 업로드 비중이 높은 사용자가 오인될 수 있음
    • 업로드 트래픽의 비율을 실제 인터넷 트래픽 통계에 따라 설정 (6~8%)
      • 에뮬레이터가 업로드 전용 사이트를 해당 퍼센트 확률로 접속
    • 업로드 콘텐츠 역시 이미지, 비디오, 텍스트 등으로 다변화
  • Limitation
    • 실제 데이터가 아닌 에뮬레이션을 통해 생성된 합성 데이터.
    • 다양한 기종(이기종)이 아닌 정해진 기기 모델만 사용
    • 실제 트래픽은 웹 서핑보다도 더 많은 Background application traffic이 있음.
• 트래픽 분류
  • Gateway Traffic : 프록시 서버 - 프록시 노드
    • Zeek의 ssl.log를 통해 서버의 도메인 이름을 시그니처로 삼아 식별
  • Relayed Traffic : 프록시 노드로부터 나가는 데이터
  • Background Traffic : 기기 주인이 만드는 트래픽
    • PCAPdroid의 루트 캡처 기능을 통해 발신 애플리케이션의 정보 추출로 구분

EarnApp의 특성

데이터셋을 통해 프록시에 대한 특성 확인

• Proxy Gateway : 두 가지 유형의 Gateway 연결로 분류
  • 단기 연결 : 데이터 전송량이 적고 지속 시간이 짧음. 앱이 켜졌을 때 네트워크 관리와 bootstrapping을 위한 트래픽
    • bootstrapping : 시스템 작동 전 초기화 및 환경 구축 과정. 서버 위치 확인 및 인증 등을 함.
  • 장기 연결 : 데이터 전송량이 높고 긴 지속시간. 프록시 노드가 클라이언트에게 데이터를 중계할 때 발생하는 트래픽
  • PCAP 파일에서 단기 연결은 중앙 서버 식별 및 동기화의 신뢰성 확보를 위해 고정형 도메인을 사용하고 장기 연결은 데이터를 load balancing 해야 하므로 도메인에 IP가 포함된 동적형 도메인을 사용
    • 장기 연결은 [IP].brdtnet.com 형태로, ISP가 식별은 가능하나 차단을 해도 새로운 IP로 할당하여 모든 IP를 차단할수 없음.

    

    • 대부분 10분에서 종료된 것으로 보아, 시간 기반 정책에 의해 세션이 종료되고 IP를 교체하는 전략을 사용. 보안 시스템에서 특정 IP를 프록시 gateway로 판단하기 전에 IP를 바꿔버림

    

    • Gateway의 IP는 균일하게 분배하는 게 아니라 비균일하게 사용.
  • 통신 idle 상태에도 60초마다 작은 크기의 암호화된 패킷이 교환됨
    • 표준 하트비트나 keep-alive 패킷이 아니었음
    • 해당 서비스에서 독자적으로 사용하는 하트비트 프로토콜일 가능성이 높음

  • 여러 개의 Gateway와 연결하며 모든 Gateway를 사용하는 것이 아닌 일부만 사용

    

    • 3~6개 정도의 gateway에 0.05초 내에 burst하게 연결
    • 처음에 파이프라인을 여러 개 뚫고 일부만 사용. 차단 당했을 때나 대량으로 몰려올 때 핸드셰이크 없이 사용할 수 있음.
• Relayed Connection
  • 소셜 미디어나 쇼핑, 뉴스 웹사이트에 주로 사용
  • 평균 연결 지속 시간은 약 28초지만 중앙값은 9초인 것을 보면 대부분 단발성 통신
  • 데이터의 양도 62.89KB로 매우 작음
  • 짧은 시간과 적은 데이터 양을 보았을 때, 단순 페이지 요청이나 웹 스크리핑 시도임을 추측
• Relayed Domain
  • VirusTotal이라는 도구를 사용하여 방문한 도메인을 검사
  • 3% 정도가 의심스러운 도메인이었으며 1%는 악성 사이트임을 확인

CLASSIFICATION APPROACHES

Light-weight detection

제한된 자원으로 빠른 탐지를 위한 방법. 프록시웨어 기기를 식별하기 위해 설계. 첫 20개의 패킷에서만

• 통계적 특성 : 시간 기반, 볼륨 기반, 구조적 특성 등을 이용
  • 구조적 특성 : 패킷이 한 방향으로 쏟아지는 지 주고 받는지 구조 파악
• 프록시를 관리하는 게이트웨이 통신과 릴레이 통신 사이의 상관 관계 특성
  • 프록시 노드가 타겟 서버에서 다운 받은 만큼(릴레이) 게이트웨이 서버에 업로드해야 함
  • 게이트웨이 트래픽의 패킷과 릴레이 트래픽의 패킷을 매칭시키려고 했으나 프록시 앱이 데이터를 split하기 때문에 크키가 맞지 않아 상관 관계가 낮음
  • Time-bin : 시간 구간 단위로 트래픽의 총량을 비교

    • 알고리즘

      

    1. 릴레이 트래픽과 게이트웨이 트래픽을 Time-bin 단위로 자름
    2. 각 구간 별 트래픽 볼륨을 합산
    3. 데이터 크기 단위가 다를 수 있으므로 정규화
       • Split 할 때 생기는 오버 헤드 및 하트 비트 같은 노이즈가 생성됨
       • Z-score를 사용하여 데이터의 크기를 직접적으로 보기보다는 평균에 비해 얼마나 커졌는 지 확인하는 작업을 함. 즉, 패턴을 봄
    4. 같은 구간끼리 볼륨 값을 곱하여 유사도 벡터를 생성
       • 위와 같이 정규화가 진행되면 평균보다 높으면 양수, 낮으면 음수가 되버림.
       • 예시
         1. 릴레이 통신의 트래픽이 적을 때, 게이트 웨이의 통신도 적을 것임.
            • 둘 다 평균 미만의 트래픽이므로 음수값 -1, -2라고 가정
            • 곱하면 2로 유사도 점수가 2점
         2. 릴레이 통신의 트래픽이 클 때, 게이트 웨이의 통신도 클 것임
            • 둘 다 평균 미만의 트래픽이므로 음수값 3, 4라고 가정
            • 곱하면 2로 유사도 점수가 12점
         3. 전제가 잘못되어 상관 관계가 없다면
            • 하나는 평균보다 크고 하나는 평균보다 작음 -1, 5라고가정
            • 곱하면 -5로 유사도 점수가 -5점
    5. 유사도 값들의 평균과 중앙값을 특징으로 추출
       • 각 통신마다 시간이 다르기 때문에 고정된 길이가 아님. 평균과 중앙값으로 압축함.
       • 평균이 클 수록 유사한 트래픽 양이 왔다 갔다 했음을 의미
       • 중앙값은 이상치로 인해 평균이 높아진 상황을 제거하기 위해 사용
         • 상관 관계가 없어서 대체로 -였는 데, 하나가 유사도 점수가 1000인 경우 평균이 커짐
• XGBoost를 사용하여 F1 Score 81.2%, FPR(오탐지율) 2.1%
  • 트래픽 분석이나 흐름 상관관계 특징이 사용되는 분류 작업의 경우, 효율성, 해석 가능성 및 네트워크 트래픽 특징에 대한 강력한 성능
  • 콘텐츠 제공자와 같은 경우 제한적인 정보(통계적 특징만을 사용)를 받기 때문에 AutoGluon의 앙상블 기법을 사용
• 양 트래픽 간의 약간의 지연이 있을 수 있기 때문에 약간은 도움이 됐지만 전체적으로 미미함.

Heavy-weight detection: CorrTransform

경량 탐지 방식은 특징 기반 탐지로 공격자가 특징을 알면 무력화될 수 있음. 그렇기에 초기 패킷 50개의 패턴을 식별하는 딥러닝을 사용

• Input Representation : 패킷 크기, 도착 간 시간, 패킷 방향.
  • 각 패킷은 128차원으로 임베딩 후 위치 인코딩을 거침
• CorrTransform Architecture : [CLS] [중계 트래픽] [SEP] [게이트웨이 트래픽] 형태
  • 정규화 기법
    1. Stochastic Depth : 학습 중에 트랜스포머의 특정 층(Layer)을 무작위로 건너뛰어 특정 층에 의존하지 않음.
    2. TokenDrop : 입력으로 들어온 패킷 중 일부를 무작위로 제거하여 전체 맥락을 학습

Attack

• Scheduling : RTT 기반 탐지를 무력화. 사용자에 미치는 영향은 거의 없음
• Target Padding : 패딩을 추가하여 패킷 크기 분포를 변경하는 공격. 데이터 사용량 증가와 더미 데이터로 인한 사용자의 유효 처리량(goodput)을 감소시킴. 업링크 (업로드 시 사용) 병목
• Packet Reshaping : 패킷을 분할하여 크기, 개수 및 시퀀스 기반 특징을 무효화. 패킷 수와 헤더 처리를 증가시켜 오버헤드 증가 및 goodput 감소
• 패킷 간 지연 지터 : 패킷 간의 무작위 지연을 도입. 사용자 경험 저하

Experiment

RQ1: ISP의 RESIP 활동 장치 탐지

• 이진 분류 접근 방식 : 게이트웨이 연결과 나머지 트래픽과 구분
  • 게이트웨이 연결의 높은 업로드 볼륨, 긴 지속 시간을 통해 식별
  • 여러 Attack으로 숨길 수 없음
• 다중 클래스 분류 : 배경, 게이트웨이, 릴레이 연결을 구분
• Training : XGBoost 모델을 사용하고 초기 패킷 20개만 보고 확인
  • RESIP 활동 장치 탐지하는 단계이므로 상관 관계 feature는 사용할 수 없음.
  • 실제 네트워크 환경에 맞게 게이트웨이 연결은 2%로 설정
• 결과
  • 이진 분류기 : 0.01%의 FPR에서 99.42%의 정밀도와 98.08%의 재현율로 게이트웨이 연결을 식별
  • 다중 클래스 분류기 : 99.35%의 정밀도와 97.86%의 재현율
    • 릴레이 클래스 탐지의 경우에는 97.00%의 정밀도와 93.84%의 재현율
    • 스케쥴링 공격에서는 재현율은 65.83%, FPR은 4.22%
  • 분석 결과 (순열 기반 분석) 업로드된 볼륨과 연결의 지속 시간이 탐지에 가장 관련 있는 특징 → Gateway 연결 횟수에 임계값을 설정하여 신뢰도를 높임

RQ2: ISP의 릴레이 연결 식별

RQ1에서 RESIP 활동 장치를 탐지하면 배경과 릴레이 트래픽을 구분

• 경량 접근 방식 : 패킷 특징(TA)과 상관 관계 특징(Corr) 기반 XGBoost 모델
• 중량 접근 방식 : CorrTransform과 DeepCoFFEA 베이스라인을 사용
  • DeepCoFFEA는 Tor 트래픽을 추적 시 사용되는 CNN 기반 모델
• 결과
  • TA + Corr 모델 : 97.08%의 F1 score
    • 스케쥴링 공격 시 : 74.03% (TA만 사용 시 44.55%)
    • Packet Reshaping : 63.70% (TA만 사용시 17.3%)
  • CorrTransform : 99.62%
    • 스케쥴링 공격 시 92.01%
    • 좀 더 전체적인 문맥을 통해 확인하며 rebundant한 feature들에 의해 공격에 의해 한 feature가 오염되도 교차 검증이 가능
  • DeepCoFFEA : 93.46%
    • 스케쥴링 공격 시 84.94%
  • Scheduling + Packet Reshaping 복합 공격에서 77.24%로 DeepCoFFEA 보다 성능이 떨어짐.
    • 우회 전략이 있음을 의미
    • CorrTransform는 긴 패킷 시퀀스에 걸친 복잡한 패턴을 포착하는 데 그 점을 교란. DeepCoFFEA는 local 접근 방식으로 이 공격에서 더 견고. 하지만 CorrTransform가 일관성과 탐지 성능을 제공
    • 경량 모델이 어떤 부분에서는 DeepCoFFEA보다 성능이 좋음

RQ3: 서버의 릴레이 연결 구분

서버에게 들어오는 단방향(Single-ended) 트래픽만 볼 수 있음. 패킷의 타이밍 정보와 누적된 플로우 통계에 의존. 공격자는 이를 우회하기 위해 Traffic Shaping을 사용

• DataSet : 악성 도메인을 제외한 데이터와 똑같은 테스트베드에서 만든 데이터를 이용
• Training : AutoGluon 분류기로 통계적 특징을 통해서만 학습.
  • 정밀도 98.76%, 재현율 98.15%, FPR은 0.2%
  • 특징 중요도를 보면 평균 IAT, 아웃바운드 패킷의 25%가 교환되는 시간, 인바운드 트래픽에 소요되는 시간
  • 프록시 트래픽의 비율을 0.5 ~ 5%로 해도 재현율은 100%였지만 낮출 수록 정밀도는 0.5%에서 71.42%까지 하락
    • 오탐율은 고정이지만 정탐의 횟수 자체가 줄어들어 비율이 떨어지는 것임.

Limitation and Future Work

1. 데이터 수집 제한 : Bright Data에 대해서만 제한하지만 이는 구현 방식의 차이일 뿐 본질은 변하지 않으므로 통할 것임
2. 비용에 대한 연구 부족 : 공격자의 공격이 프록시 노드에 가하는 비용에 대해 연구 부족.
3. 지리적 한계 : 데이터셋이 지리적으로 국한되어 있어서 글로벌 네트워크 조건에서는 타이밍 특징의 성능에 영향을 미칠 수 있음
4. 프록시 앱의 사용자인지 Proxyjacking의 피해자인지 구분할 수 없음
5. 프록시 서비스 업체도 업체의 망을 통해 공격을 막고 싶어하기 때문에 업체에서 악성 트래픽을 잡아내는 연구 필요
6. Concept drift : 네트워크 트렌드나 프록시 앱의 버전이 업데이트 될 수 있음.

생각

다른 트래픽 우회 방법과의 차이점

• 장점
  • 잘 잡히지 않고 지역 우회가 자유로움
    • VPN을 쓰면 목적지 서버 입장에서 출발지 IP가 AWS, Digital Ocean 같은 데이터센터 IP. IP 평판 DB에 이미 “proxy/hosting” 으로 등록돼 있어서 서버가 바로 식별 가능
    • Tor는 출구 노드(Exit Node) IP 목록이 공개. 대부분의 서비스가 이 목록으로 차단.
    • RESIP은 출발지 IP가 KT, SKT, Comcast 같은 실제 ISP의 가정용 IP. IP 평판 DB에 일반 사용자로 등록.
  • 지역 우회가 자유로움
    • VPN은 제공자가 보유한 서버 수만큼만 국가 선택이 가능. 그 서버 IP들은 이미 넷플릭스 같은 서비스에 등록돼서 막혀 있는 경우가 많음
    • RESIP은 실제 그 나라 가정집 IP라 넷플릭스 입장에서 정상적인 해당 국가 사용자. 다 막는 건 사실상 해당 국가 사용자 전체를 막는 거라 불가능해요.
• 단점
  • 비용이 많이 듦
    • VPN은 전용 서버를 운영하는 구조라 월정액으로 무제한 제공이 가능. 서버 증설 비용이 선형적으로 증가
    • RESIP은 프록시 노드 사용자에게 대역폭 사용 비용을 지불.

  • 중간자 공격의 위험성??

    TLS 세션이 구독자 ↔ 목적지 서버 간 end-to-end로 맺어지고, 프록시 노드는 암호화된 패킷을 그냥 포워딩이 되기 때문에 TLS 레이어에서 MitM 공격은 불가능하지만 TLS 밖의 메타 데이터는 모니터링 가능

문제가 된다고 생각하는 점

1. 기기를 식별할 때, 고유한 서버 도메인, 높은 업로드 볼륨, 고정된 세션 지속 시간(약 10분 등)이라는 명확한 핑거프린트가 있어 탐지가 매우 쉽다는 데. 10분이나 고유한 서버 도메인 같은 경우에는 서비스가 조절 할 수 있지 않나 또한 ECH되면 볼 수 조차 없는데
2. 본 논문에서는 프록시 트래픽 자체가 ‘악의적(Malicious)’이거나 ‘강제적(Proxyjacking)’인지 직접적으로 알아내는 방법은 다루지 않았음. 방어 방법 역시 다루지 않았음
   • 결국 ISP나 서버나 프록시 트래픽 자체가 문제가 아니라 그것을 통한 악성 행위가 문제인데, 이를 식별하는 것은 다루지 않음.