[2026-01-02] Preventing Artificially Inflated SMS Attacks through Large-Scale Traffic Inspection

🦥 본문

AIT

많은 수 봇 계정으로 SMS 인증 요청으로 대규모 피크 트래픽을 발생 시킴. 웹 브라우저와 모바일 장치에 설치된 네이티브 앱을 사용하여 공격

• 기존의 속도 제한 정책의 한계 : 몇 차례의 실패 후 계정 잠그는 정책은 분산된 공격에 의해 회피
• 분산된 공격 전략
  1. 일회용 이메일 서비스를 통해 대량의 이메일 생성 후 봇에 등록.
  2. 공통된 접두사 값을 기반으로 가짜 전화번호와 IMEI를 생성.
     • IMEI : 국제 모바일 기기 식별 코드

Architecture

동작 흐름

1. 인증 단계 : 인증 요청을 인증 서버에 보냄
2. 피처 계산 단계
   • 피처 추출기를 작동 시켜 세 가지 수준의 feature set을 계산
     1. 사용자 정보 DB : 사용자 계정 및 장치 별 정보 수집
        • ex) SMS 요청 timestamp과 Email-domain 최초 등장 timestamp 사이의 시간 차 같은 단일 이벤트 feature를 계산
     2. SMS log DB : 다중 이벤트 feature와 국가 전체 feature를 계산하는 데이터
        • ex) 24시간 동안의 전화번호 접두사 패턴 재발 횟수를 세는 국가 전체 feature를 SMS log DB를 통해 계산
        • 실시간 검사를 위해 timestamp를 사용하여 24시간 트래픽을 선택
     3. Lookup table : 계산 효율성을 높이기 위해 네이티브 장치/클라이언트 출시일 같은 재사용 가능한 정적 정보 저장.
        • 추가적인 Lookup table : 다양한 OS, 네이티브 클라이언트, 장치 모델 버전의 최초 출시일 등등
3. 공격 추론 단계
   1. feature 벡터 전송 : feature 계산 후 feature 벡터를 AIT Attack Detector로 리턴
   2. 추론 점수 계산 : ML 서버에 전송 후 점수를 계산 하여 AIT Attack Detector로 리턴
      • 1에 가까우면 AIT, 0에 가까우면 정상
   3. 인증 결정 : 임계값과 비교하여 낮으면 SMS OTP 발송을 진행
   4. 로그 기록 : SMS 요청에 대한 정보는 SMS log DB에 기록

모델 학습 단계

• 데이터 라벨링
• 학습/검증/테스트로 분류
• 분류 알고리즘 : GBTs(경사 하강법 기반 부스팅 트리)
• 하이퍼파라미터
  • 웹 트래픽의 경우 : 최대 깊이 10과 트리 개수 200
  • 네이티브 모델의 경우 : 최대 깊이 5와 트리 개수 200

Dataset

AIT 공격이 발생한 상위 10개 국가를 기준으로 하였고 SMS 요금제가 비싼 아프리카와 남아시아가 많음.

Log data

웹인지 네이티브 앱인지에 따라 수집 feature가 다름

• 식별자 및 계정 정보
  • 익명화된 사용자 식별자
  • 이메일 도메인 이름
  • 전화번호
• 요청 상세 정보
  • 요청 시간
  • IP 주소
  • SMS 대상 국가
  • 액션 타입
• 장치 및 클라이언트 정
  • 장치 IMEI 번호
  • 장치 모델
  • 클라이언트 및 OS 버전
• 서비스 및 정책 정보
  • 인증 서비스 유형(계정 로그인, 2차 인증, )
  • 애플리케이션
  • SMS 요금 정보
• 추가 상태 정보
  • 계정 첫 등록 시 클라이언트 유형
  • 신뢰할 수 있는 장치를 등록했는 지 여부
  • 전화번호 소유권 확인 여부

전처리

• 전화번호 접두사 : 뒤 4자리를 제거하여 추출
• IMEI 접두사 : 뒤 7자리 제거

Labeling

• 정의
  • 정상 : 3개월 데이터 기반으로 25% 절사 평균과 표준 편차를 계산
    • 절사 평균 : 상위 25%를 제외하고 평균 계산
  • 피크 트래픽 검색 : 평균값보다 표준 편차 n% 더 큰 일일 트래픽 볼륨
  • 피크 트래픽 확인 : 일일 전환율이 정상 일일 트래픽을 기준으로 계산된 중앙값에 비해 비교하여 큰 수치만큼 하락하는 지 확인
    • 전환율 : 실제 사용자가 인증에 성공하는 비율. 공격 트래픽 대부분이 실패하므로 트래픽이 급증했음에도 불구하고 성공률은 급락하는 특징을 이용
  • 피크 트래픽 확인 후 라벨링 방법
    • 웹 트래픽 : 같은 날에 성공적인 인증 없이 4번 이상의 요청 제출. (속도 제한 정책 회피용) 또는 특정 국가. 날짜, 애플리케이션에 평소와의 차이가 임계값보다 큰 경우가 피크 볼륨의 일부로 온 경우에 공격으로 간주
    • 네이티브 클라이언트 : 전화번호나 IMEI를 전환하기 전에 1~2건의 요청만으로 제출하고 인증을 안하기 때문에 3개월 기간 동안 단 한 번도 인증되지 않은 전화번호-IMEI 쌍을 공격으로 간주. 악성 사용자, 전화번호, IMEI 번호 set을 식별 후 해당 set와 관련된 모든 샘플을 공격 샘플로 라벨링

피크 주기와 비피크 주기 전체에 걸쳐 일관되게 정상 트래픽이 존재함을 확인함.

Feature

Known Attack Characteristics

• 기존 대응책
  • 인증 속도 제한 정책
  • 과도하게 사용되는 계정, IP 식별
  • 단기 트래픽 급증 및 전환율의 극단적인 하락 모니터링
  • 가짜 전화번호 생성 시 사용되는 순차적인 번호 패턴 식별
• 기존 대응책 구현: 다중 이벤트 피처와 접두사 분석
  • 과도한 재사용 방지 feature
    • 24시간 내 제출된 요청 횟수 : user-sms-count, ph-sms-count
    • 시간 차이 기반
      • user-diff-avg : 24시간 동안 특정 사용자가 제출한 모든 인증 요청 중 연속된 두 요청 쌍 사이의 시간 차이의 평균
      • user-time-diff-std : 위의 평균에 대한 표준편차
      • user가 아닌 IMEI와 전화번호에 대한 feature도 있음
    • 전환율 : user-conv-rate, ph-conv-rate, imei-conv-rate
  • 전화번호의 순차적 번호 패턴
    • 공격의 대부분이 추적 가능한 정보를 한 번만 사용하고 전환.

    → 번호 간의 유사성을 측정하기 위해 동일한 주체가 여러 개의 의심스러운 번호를 연속적으로 사용하여 패턴을 비교해야 하지만 비교군이 없어서 힘듦

    • ph-prefix-count : 전화번호에서 접두사 값을 추출. 대상 국가의 전체 24시간 트래픽에서 접두사 반복 횟수를 셈
    • 접두사 : 주로 주나 통신사를 나타냄

웹 채널 공격 특성

4건 이하로 공격. 다중 이벤트 피처는 첫 번째나 두 번째 시도를 탐지하기 힘듦.

• 단기 이메일 서비스 탐지 feature
  • 임시 이메일 서비스는 첫 등장 날짜가 최근
  • em-domain-sms-diff : 단일 이벤트 feature. SMS 요청 timestamp와 이메일 도메인의 첫 등장 timestamp 사이의 차이를 계산. gmail 같은 경우는 첫 등장이 과거
• 잘 알려진 이메일 서비스 탐지 feature
  • 잘 알려진 이메일 도메인의 일일 사용률 모니터링
  • em-domain-prop-change : 대상 국가의 24시간 트래픽 내에서 특정 이메일 도메인에 의해 시작된 SMS 트래픽 비율을 계산 후 기준값을 빼서 변화량 측정.
• 전화번호 접두사 재사용
  • 공격자들이 대량의 번호 생성을 위해 접두사를 유지.
  • 동일한 번호는 ph-prefix-count에 한 번만 기여
• 성공적인 인증
  • 속도 제한 정책과 전환율 모니터링 규칙을 우회하기 위해 설계
  • 잘 알려진 도메인과 가짜 전화번호를 사용하기 때문에 em-domain-prop-change와 ph-prefix-count가 작동

네이티브 채널 공격 특성

• 전화번호 접두사 재사용
  • 네이티브 채널 공격에서 더욱 두드러지기 때문에 접두사 관련 피처를 추가
  • 최적화된 네이티브 모델에 전환율이 낮기 때문에 ph-prefix-conv-rate (24시가나 내 접두사 값에 대한 전환율)를 추가
• IMEI 접두사 재사용
  • IMEI는 마지막 7자리를 제외하면 변경이 불가
    • 첫 8자리 : 유형 할당 코드
    • 다음 7자리 : 시리얼 번호 6자리 + 체크 숫자 1자리
  • imei-prefix-sms-prop : 특정 국가에서 24시간 내 IMEI 접두사 제출 요청 비율
  • IMEI는 고정된 기기 설정(모델, OS, 클라이언트 버전)을 통해 생성
    • device-sms-prop : 특정 기기 설정에 의해 시작된 트래픽 비율
    • device-conv-rate : 특정 기기 모델에 대한 전환율
• 오래된 네이티브 클라이언트
  • 대체로 오래된 장치와 OS에서 수행
  • 요청 timestamp와 기기 모델, OS 버전, 클라이언트 장치 등의 출시일 사이의 시간 차이 feature
    • lookup table을 사용

종합

웹 모델 feature

• 예비 모델 : 다중 이벤트 feature + ph-prefix-count 등 총 10개
• 최적화 모델 : 새로운 단일 이벤트 및 국가 전체 feature 8개 추가
  • service-id, sms-cost, join-channel, is-same-contry, have-trusted-device. 새로운 5개 feature 사용
  • PRAUC 정확도 평균 감소 방법을 사용하여 feature 중요도 평가

네이티브 모델 feature

• 예비 모델 : 웹 모델 feature → IMEI 별 다중 이벤트 feature
• 최적화 모델 : is-ph-verified 추가
  • is-ph-verified : 특정 전화번호 소유권이 이전에 확인되었는 지 여부

평가

재현율을 보고하고, 예비 모델과 최적화된 모델 비교. GBT 분류기를 훈련

• 데이터셋 : 1~2달은 훈련 set, 3번째 달의 15일은 검증. 나머지는 테스트. 모든 샘플을 사용하는 것이 성능에 좋음
• TPR(정탐율)과 FPR(오탐율) 측정

검증 세트

• 임계값은 0.9일 때 오탐율 감소
• 네이티브 모델이 패턴적이라 정탐율이 높음
• 예비 vs 최적화 모델
  • 방글라데시는 Web-Short-Email과 Web-Phone-Prefix를 악용하여 em-domain-sms-diff가 필요
  • 아제르바이잔에서는 em-domain-prop-change 이 정탐율 증가에 기여
• 낮은 TPR
  • 우크라이나가 초반에는 높았으나 점점 떨어짐
  • em-domain-prop-change와 ph-prefix-count 때문
• 높은 FPR : 오탐은 짧은 피크 주기 동안 발생하지만 사용자 접근 거부는 일시적임
  • 쿠웨이트에서는 정상 사용자가 우연히 공격자의 접두사나 장치를 사용할 때 발생
  • 우즈벡의 경우에는 데이터 라벨링 잘못의 가능성이 큼

테스트 세트 성능

• 임계값은 0.9
• 웹 vs 네이티브의 경우 성능 비슷
• 낮은 TPR
  • 작지만 은밀한 일일한 트래픽 볼륨
  • 번호 당 한 건만 요청하는 극도로 산발적인 형태
  • 접두사 패턴이 없어서 탐지가 어려움
  • 위의 것이 정상이 아닌 이유가 이 번호가 과거의 피크에서 사용된 흔적이 발견됨.
• 높은 FPR
  • 데이터 라벨링 문제
• 시간 창은 24시간에서 최고 성능
• 일반화
  • 일반화를 위해 두 국가를 빼고 훈련 → 두 국가에 대해서 성능 측정
  • 공격의 유사성으로 인해 효과적인 완화

회피 공격에 대한 견고성

• 공격자는 회피를 위해 feature를 조작하려고 하고 정상 트래픽과 섞어서 보냄
• 실험
  • 정상 샘플(정상 행동을 복제하는 공격자) + 공격 샘플을 통해 실험

  • 웹 모델은 30%부터 성능 저하

    → 효율적이지 못한 공격

    • 회피 set까지 훈련할 경우에는 30%까지도 괜찮음
  • 네이티브 모델에서는 10%여도 견고

모델 크기 및 오버헤드

• 크기
  • 웹 모델은 7.6MB, 200개의 트리, 121,628개의 노드
  • 네이티브 모델은 0.5MB, 200개의 트리, 6170개의 노드
• 시간
  • 훈련 시간은 각각 617초와 326초
  • 실행 시간을 최소화하기 위해 과거 SMS 요청 로그가 메모리에 미리 로드
  • 캐싱 작업은 웹 트래픽은 31MB, 네이티브 트래픽은 253MB의 메모리 소모
    • 피처 계산 시간 + 모델 예측 함수 실행 시간
    • 웹 모델에서 공격 샘플과 정상 샘플을 예측하는 데 걸린 시간은 31.2ms. 17.0ms
    • 네이티브에서는 329.4ms, 63.4ms

    → 분석해야 할 전체 트래픽이 웹보다 많기 때문

    → 그리고 피크 공격은 일시적이므로 저하된 경험은 일시적임

모델 재훈련

3일마다 하는 것과 10일마다 하는 것이 미미하기 때문에 10일로 결정

Discussion

• 오탐 : 공격 시에 같은 접두사를 사용하는 사용자의 경우 → 모바일 앱 인증이나 다른 2단계 인증 수단 사용을 권장
• 미탐
  • 우크라이나 같은 경우 Web-Dominant-Email, Web-Phone-Prefix, Web-Validation이 혼합된 방식이 사용되어, 시간이 지나면서 탐지가 어려워짐 → 모델 재훈련
  • 저조한 피크 주기는 24시간 내에 접두사 횟수 누적에 의존하는 국가 전체 feature가 무쓸모가 되어 탐지가 어려워서 은밀하지만 제한적임. 하지만 장기적으로는 문제가 되기 때문에 더 긴 시간의 시간 창에 기반한 feature 탐색이 필요
• 한계
  • 데이터 라벨링의 한계
  • 비피크 공격에 대한 낮은 탐지율
• 실제 환경에서는 개인 정보 익명화를 위해 전화번호 접두사와 IMEI 접두사만 평문으로 저장하고 개별 발생 횟수는 암호화된 값을 사용하여 계산