가짜 결제 SDK 사칭 npm·PyPI 공급망 공격 (Paysafe·Skrill·Neteller 사칭)

‍

가짜 결제 SDK 사칭 npm·PyPI 공급망 공격 (Paysafe·Skrill·Neteller 사칭)

‍

■ 개요

‍

npm과 PyPI는 각각 자바스크립트와 파이썬 개발자가 공개 코드 묶음을 내려받아 쓰는 오픈소스 패키지 저장소입니다. 보안 업체 Socket은 2026년 7월 7일 이 두 곳에서 Paysafe·Skrill·Neteller(온라인 결제·송금 서비스)의 공식 SDK(개발 도구 모음)를 사칭한 악성 패키지 17종을 발견했습니다. 정식 이름과 비슷하게 지어 오타나 혼동을 노리는 타이포스쿼트(typosquatting) 방식입니다.

이름 혼동으로 설치된 이들 패키지는 정상 SDK처럼 payments.create나 customers.get 같은 메서드를 그대로 노출합니다. 그러나 실제 결제 서버와는 통신하지 않고 { success: true } 가짜 성공 응답만 반환합니다. 개발자는 정상 동작으로 착각하지만, 그 사이 코드는 환경변수에 담긴 자격증명을 몰래 수집해 외부로 빼돌립니다. 인증이나 별도 조건 없이 패키지를 설치·사용하는 것만으로 실행되는 구조입니다.

실행 조건은 생태계별로 다릅니다. npm 버전은 가짜 SDK 메서드를 호출하고 PAYSAFE_API_KEY가 존재할 때 탈취를 실행하며, 탐지 회피를 위해 11~12초의 지연을 둡니다. 반면 PyPI 버전은 조건 없이 import(초기화) 시점에 자동 실행돼 노출 범위가 더 넓습니다. Socket의 AI 스캐너는 게시 6분 만에 이 패키지들을 악성으로 분류했습니다. 다만 결제 연동은 국내 핀테크·커머스 개발 환경에 보편적이라, 짧은 노출 시간에도 CI/CD(빌드·배포 자동화 파이프라인) 시크릿이 유출됐을 수 있습니다.

‍

■ 요약

‍

확인된 대상은 결제 서비스명을 직접 포함합니다. npm 대상 패키지에는 paysafe-checkout·paysafe-vault·paysafe-js·paysafe-api·paysafe-node·skrill·neteller 등이, PyPI에는 paysafe-sdk·paysafe-api·paysafe-kyc·paysafe-payments가 포함됐습니다. 이름만 보면 정식 SDK와 구분하기 어렵습니다.

‍

■ 가짜 결제 SDK 동작 방식

‍

이름만으로 구분하기 어려운 이 패키지의 핵심은 PaysafeClient 클래스입니다. 생성자에서 설정값 config.apiKey 또는 환경변수 PAYSAFE_API_KEY를 읽어, 정상 SDK의 초기화 흐름을 그대로 흉내 냅니다. 결제 메서드가 호출될 때마다 내부 유출 함수(exfiltrate)도 함께 실행됩니다.

아래는 공개된 분석에서 확인된 핵심 로직을 방어용으로 단순화한 예시입니다. 실제 유출 코드는 생략했습니다.

class PaysafeClient {
  constructor(config = {}) {
    // 정상 SDK처럼 API 키를 읽어 신뢰를 유도
    this.apiKey = config.apiKey || process.env.PAYSAFE_API_KEY || null
  }

  // 결제 서버와 통신하지 않고 가짜 성공 응답만 반환
  request(method, path) {
    exfiltrate() // 시크릿 수집·유출 (로직 생략)
    return { success: true, method, path }
  }
}

// ... 환경변수 수집·C2 인코딩·유출 로직 생략 ...

‍

■ 시크릿 탈취와 C2 은닉

‍

가짜 성공 응답과 동시에 실행되는 탈취 로직은 프로세스 환경변수를 순회하며 이름에 KEY·SECRET·TOKEN·PASS·AUTH·API가 포함된 값을 걸러냅니다. PAYSAFE_API_KEY(앞 10자)·AWS_SECRET_ACCESS_KEY·GITHUB_TOKEN·NPM_TOKEN이 주요 표적이며, 값은 100자 이내로 잘라 전송합니다. 여기에 호스트명·사용자명·작업 디렉터리·타임스탬프를 함께 묶어 유출 페이로드를 구성합니다.

분석 환경 회피 기능도 포함돼, CPU 코어가 2개 미만이거나 호스트명·사용자명에 sandbox·analyzer·cuckoo·vmware·vbox 같은 단어가 있으면 조기 종료해 탐지를 피합니다.

이렇게 수집된 페이로드가 향하는 C2(명령·제어 서버) 도메인은 XOR·문자 시프트·문자열 역순의 3단계로 은닉돼 있으며, 복원 결과는 caliber-spinner-finishing.ngrok-free.dev(포트 443)입니다. ngrok(로컬 서버를 외부에 임시로 노출하는 터널링 서비스)을 경유해 정상 트래픽처럼 위장합니다. 패키지마다 서로 다른 인코딩 키를 사용해 시그니처 기반 탐지를 어렵게 만든 점도 특징입니다. 이 때문에 단일 문자열 패턴보다는 배포된 파일 해시와 C2 접속 흔적을 함께 봐야 합니다.

‍

■ 탐지 및 점검

‍

• 최근 설치 이력과 잠금파일(package-lock.json·poetry.lock 등)에서 paysafe-*·skrill*·neteller 패키지의 존재 여부를 점검합니다.

• CI/CD 빌드 로그와 러너(빌드·배포 작업을 실행하는 CI 서버)의 아웃바운드 연결에서 caliber-spinner-finishing.ngrok-free.dev 및 *.ngrok-free.dev 접속을 검색합니다.

• 공개된 SHA256 해시(ce09810adca70ebec87bc455380ef629ceaa2a0d926149d9115604060167682c, PyPI c6af37a6739f0d919ab7049caf3a85831cab44bdbea27e0d9de7adec80334e2b 등)로 index.js·__init__.py 파일을 스캔합니다.

• 결제 SDK 호출 이후 실제 결제 게이트웨이로 향하는 트래픽이 없는데 성공 응답만 반환되는 이상 동작을 확인합니다.

• 게시일이 2026-07-07 전후이고 버전이 1.0.0~1.0.3인 신규 결제 관련 의존성을 우선 검토 대상으로 분류합니다.

‍

■ 대응 방안

‍

• 점검에서 설치 이력이 확인되면 영향 패키지를 즉시 제거하고, 정식 결제 SDK의 공식 배포 채널과 정확한 패키지명을 재확인해 재설치합니다.

• 해당 파이프라인에서 노출됐을 PAYSAFE_API_KEY·AWS 액세스 키·GITHUB_TOKEN·NPM_TOKEN을 모두 즉시 폐기·재발급합니다. 설치된 이상 유출로 간주해야 합니다.

• 사내 레지스트리 미러와 허용 목록을 적용하고, 신규 외부 패키지는 승인 절차를 거쳐 도입합니다.

• CI/CD 러너의 아웃바운드 통신을 필요한 목적지로 제한해 ngrok 등 임의 터널 유출 경로를 차단합니다.

• 결제 연동 개발이 없는 조직도 오픈소스 의존성 전반에 타이포스쿼트 점검을 확대 적용해야 합니다. 유출된 npm·게시 토큰은 2차 공급망 침해로 이어질 수 있습니다.

‍

[참고 자료]

Coordinated npm and PyPI Campaign Typosquats Popular Secure Payment Apps (Socket)

Fake Paysafe, Skrill SDKs on NPM and PyPi steal credentials (BleepingComputer)