설치된 브라우저 확장이 지갑 드레이너인지 판단하려면, 겉으로 보이는 정상 기능 뒤에 악성 서버(C2) 연결과 데이터 전송 기능이 숨겨진 이중 구조인지부터 확인해야 합니다. Chrome은 자동 업데이트 특성상 사용자가 인지하지 못한 시점에 악성 코드가 삽입될 수 있어서, 설치 목록 전체를 상시 점검하는 수밖에 없습니다. Chrome Enterprise의 강제 설치 정책(ExtensionInstallForcelist)이 적용된 확장은 사용자가 임의로 제거할 수 없어 보안 공백이 생기기 쉽습니다.
지갑 드레이너 확장을 판단하는 3가지 구조 신호
최근 발견된 브라우저 확장 기반의 지갑 탈취 공격은 단순한 악성 소프트웨어 설치를 넘어 정교한 위장 전술을 씁니다. 보안 연구자 Karlo Zanki는 일부 확장이 지갑 비밀 정보 탈취와 암호화폐 유출 기능을 갖췄다고 보고했습니다. 사용자가 설치된 확장의 위험성을 판단할 때 주목할 핵심 신호는 세 가지입니다.
1. 의도된 기능과 악성 기능의 이중 구조
가장 위험한 형태는 겉으로는 정상 기능을 하면서 내부적으로는 악성 동작을 수행하는 이중 기능형 구조입니다. 이런 확장은 초기 버전에는 악성 코드 없이 배포되어 사용자의 신뢰를 얻은 뒤, 이후 업데이트로 악성 기능을 추가하는 패턴을 보입니다.
2. 외부 명령제어(C2) 서버와의 연결
정상적인 확장은 서비스 제공자의 공식 API와 통신하지만, 드레이너 확장은 명령제어(C2) 서버에 연결해 악성 모듈을 내려받습니다. 악성 서버에 사용자 데이터를 전송하고 외부 명령을 받는 방식으로 움직이며, 이 과정에서 지갑 연결이나 승인 흐름을 가로챕니다.
3. 비정상적인 정보 입력 유도
지갑 드레이너는 기술적인 탈취에 사회공학적 기법까지 결합합니다. 사용자가 지갑의 복구 문구(Recovery Phrase)를 입력하도록 유도하는 인터페이스를 만들어 직접적으로 비밀 정보를 노립니다.
정상 기능 위장과 자동 업데이트: 안전의 역설
많은 사용자가 "현재 확장 프로그램이 문제없이 잘 작동한다"는 점을 근거로 안전하다고 판단하지만, 이것이야말로 드레이너 확장의 전형적인 위장 전략입니다.
신뢰 지표의 악용
공격자들은 사용자가 확장을 신뢰하게 만들려고 아래 지표를 전략적으로 활용합니다.
- Chrome Web Store의 검증 배지와 추천 배치
- 누적 설치 수와 긍정적인 사용자 리뷰
- 장기간의 정상 운영 이력
실제로 DomainTools 연구에 따르면 사용자를 Chrome Web Store의 악성 확장 설치로 유도하는 사례가 보고됐습니다.
자동 업데이트로 인한 무자각 감염
Chrome은 설치된 확장을 최신 버전으로 자동 업데이트하도록 설계돼 있습니다. 기본적으로 브라우저 시작 시점과 수 시간 간격으로 업데이트를 확인하기 때문에, 사용자는 별도 클릭이나 피싱 경로를 거치지 않고도 조용히 악성 업데이트를 받게 됩니다. 설치 당시에는 안전했던 확장이라도 시간이 흐른 뒤 자동으로 '드레이너'로 변모한 버전을 쓰게 될 수 있다는 뜻입니다.
분석된 사례 및 영향 범위
최근 Socket 보고에 따르면 공개된 지 6개월 이내의 확장 프로그램 중 상당수에서 지갑 탈취 기능이 발견됐습니다. 코드와 작업 방식이 유사한 사례들이 확인됐는데, 단일 캠페인으로 추정됩니다.
| 구분 | 상세 내용 |
|---|---|
| 발견된 악성 확장 수 | 총 19개 (Chrome 18개, Edge 1개) |
| 주요 위험 확장 | Enable Right Click & Copy — Smart Unlock + OCR |
| 잠재적 영향 사용자 | 약 80,000명 (Chrome 및 Edge 합산) |
| 추적 캠페인 명칭 | 슈피리어(Superior) / 2024년 2월부터 연관 |
다만 위 수치는 Socket의 분석 결과이며, 실제 탈취·유출된 암호화폐의 전체 규모, 특정 APT 그룹의 정체, 공개된 PoC(개념 증명) 코드는 현재 근거 장부에서 확인되지 않았습니다.
관리자와 사용자를 위한 점검 및 대응 가이드
브라우저 확장 프로그램은 권한이 강력해서 한 번 침해되면 지갑 비밀키와 세션 정보가 모두 유출됩니다. 단계적으로 나눠 대응하는 것이 권고됩니다.
1. Chrome Enterprise 관리자 주의사항
기업 환경에서는 ExtensionInstallForcelist 정책으로 특정 확장을 강제 설치할 수 있습니다. 이렇게 설치된 확장은 일반 사용자가 비활성화하거나 제거하지 못해서, 관리자가 신뢰한 확장이 사후에 악성으로 변모하면 모든 엔드포인트에 똑같은 보안 허점이 생깁니다. 강제 설치 목록의 확장에는 정기적인 코드 리뷰와 업데이트 모니터링이 필수입니다.
2. 개인 사용자 대응 순서
악성 확장 노출이 의심되거나 발견되면 단순 제거만으로는 부족합니다. 코이 시큐리티는 5단계 대응 프로세스를 권고합니다.
- 확장 즉시 제거: 의심되는 확장 프로그램을 브라우저에서 삭제합니다.
- 브라우저 데이터 초기화: 캐시, 쿠키, 저장된 세션 정보를 삭제해 하이재킹 위험을 제거합니다.
- 전체 악성코드 검사: 시스템 전반에 걸친 추가 페이로드 설치 여부를 확인합니다.
- 온라인 계정 모니터링: 탈취된 세션이나 자격증명으로 인한 무단 접근이 있는지 살핍니다.
- 전체 목록 재점검: 현재 설치된 모든 확장 프로그램 목록을 다시 검토해 유사한 패턴의 확장이 있는지 점검합니다.
이런 점검은 일회성이 아닙니다. 자동 업데이트 주기에 따라 상태가 언제든 바뀔 수 있다는 전제하에 주기적으로 반복하는 작업입니다.
함께보면 좋은 글!
CVE-2021-23758 적용 여부 판단: Ajax.NET Professional 버전 경계와 엔드포인트 노출 확인 기준
내 환경에서 CVE-2021-23758이 실제로 적용되는지 판단하려면 세 가지를 순서대로 확인하면 된다. 먼저 사용하는 패키지명(ajaxpro.2 / AjaxNetProfessional / Joint.AjaxPro)을 식별한 뒤 패키지별 취약 버전 경계를 대조한다. 다음은 web.config의 ajaxpro/*.ashx 핸들러 등록 여부, 마지막은 AjaxMethod 시그니처에서 임의 object 인자를 받는 메서드 존재 여부다.이 취약점은 2026년 8월 26일 CISA KEV 카탈로그에 등재되었고, CISA remediation deadline은 2026-09-09로 설정되어 있다..NET 기반 웹 서비스를 운영하거나 DevSecOps 파이프라인에 NuGet 의존성 점검이 포함된 환경이라면, 이 기한..
ITDesk
OSINT 파이프라인 허용 범위 vs 법적 경계: amass passive·Scrapy settings 구조와 대상 측 rate limiting·CAPTCHA 대응
OSINT 수집 파이프라인을 운영할 때 도구별 허용 범위는 passive 모드의 공개 소스 조회에 국한된다. active 기법은 사전 승인 없이 실행하지 않는 게 원칙이고, 대상 측의 rate limiting·CAPTCHA·robots.txt 조치는 기술적 표준이더라도 수집 측이 이를 무시하면 정보통신망법상 법적 리스크가 따른다. 수집 범위를 설정할 때는 도구 기능 경계와 대상 측 보호 조치를 동시에 고려하는 것이 판단 기준이다.amass passive 모드의 실제 수집 범위OWASP Amass는 오픈소스 attack surface intelligence 프레임워크로, 조직의 물리적·디지털 footprint를 종합적으로 매핑하고 자동화된 데이터 수집·네트워크 매핑·OSINT 기능을 결합한다. Recon-..
ITDesk
Red Hat NOTABUG 처리와 CVE-2022-0995 패치 결정 시 고려할 판단 포인트
CVE-2022-0995는 Linux 커널 watch_queue 이벤트 알림 하위시스템의 경계 외(OOB) 메모리 쓰기 결함으로, 로컬 사용자의 권한 상승이나 시스템 서비스 거부를 유발할 수 있다. Red Hat은 자사 RHEL 6~9 전 제품군에서 영향을 받은 배포 커널 버전이 없다고 판정해 Bugzilla 항목을 NOTABUG로 마감했으나, 같은 Red Hat 계열의 Fedora는 영향을 받아 별도 errata로 수정 처리되었다. NOTABUG 마감을 "이 취약점이 무의미하다"는 전 세계적 판단으로 읽어서는 안 된다. 운영자는 자신이 운영하는 배포판과 커널 빌드별로 적용 여부를 개별 확인한 뒤 패치 우선순위를 정하는 수순이다.CVE-2022-0995 개요: watch_queue OOB 쓰기와 로컬 권..
ITDesk