핵심 요약
- 보안 기업 소크레이더가 크롬과 엣지 확장 프로그램 형태를 위장한 공격 도구를 ‘PEEP’으로 명명하고 분석 결과를 공개했다.
- PEEP은 사용자 계정 정보와 세션 쿠키를 탈취하는 데 그치지 않고, 감염 PC에서 명령을 실행하는 기능까지 갖추고 있다.
- 해당 도구는 초기 침투용이 아니라, 이미 관리자 권한 또는 명령 실행 권한을 확보한 공격자가 시스템에 발판을 마련한 뒤 자리를 굳히기 위한 후속(Post-exploitation) 도구로 분류된다.
analysis
목차
PEEP 백도어가 크롬과 엣지 확장 프로그램으로 둔갑해 사용자 모르게 브라우저를 장악하는 방식이 공개됐다. 보안 기업 소크레이더가 이 도구를 분석해 명명한 PEEP 백도어는 단순한 정보 탈취용 악성코드가 아니다. 이미 시스템 권한을 확보한 공격자가 브라우저를 발판으로 삼는 후속 도구라는 점에서 위협 수준이 다르다.
필자가 이 사건에서 가장 의미 있다고 본 부분은 ‘설치 단계’다. 일반 사용자는 자기가 확장 프로그램을 설치했다는 사실조차 인지하지 못할 가능성이 높기 때문이다.
1. PEEP 백도어의 정체 — 소크레이더가 명명한 도구, 무엇을 하는가
소크레이더는 PEEP 백도어를 ‘이미 권한을 가진 공격자가 시스템에 더 깊이 뿌리내리기 위한 도구’로 분류했다. 초기 침투용 악성코드와 달리, PEEP 백도어는 한 번 관리자 권한이 확보된 PC에서 동작하며 브라우저를 감시·명령 실행 플랫폼으로 전환한다.
크롬 웹스토어와 마이크로소프트 애드인 마켓을 완전히 우회한다는 점이 핵심이다. 공격자는 사용자의 PC에 직접 확장 파일을 내려받아 등록하며, 브라우저가 평소 표시하는 ‘이 확장을 추가하시겠습니까?’ 팝업도 뜨지 않는다.
2. 무결성 값 위조 — 정상 설치처럼 보이게 만드는 기술
크로미엄 기반 브라우저는 확장 설정 파일(preferences)의 변조 여부를 확인하기 위해 해시 기반 무결성 값을 저장한다. PEEP 백도어는 이 값을 정상 값으로 위조해 검사 단계 자체를 무력화한다. 결과적으로 브라우저는 ‘정상적인 방식으로 설치된 확장’으로 판단하고 아무 경고도 띄우지 않는다.
이 패턴은 소크레이더 분석을 소개한 보안뉴스 원문에서 설명한 그대로다. 정상적인 템플릿 메커니즘을 역이용해 백도어를 심는 시도는 과거에도 반복됐다. 매그ento 환경의 StyleSmuggler 제로데이가 그 예다 — StyleSmuggler 제로데이 분석 기사처럼 정상 우회 경로를 악용해 백도어를 심는 공격은 웹·브라우저 영역에서 계속 진화하고 있다.
3. PEEP 백도어가 빼가는 것 — 계정에서 PC 제어까지
수집 가능한 정보의 범위가 넓다. 기본적으로 사용자가 로그인한 웹사이트의 세션 쿠키와 계정 정보가 대상이다. 여기서 더 나아가 감염 PC에서 임의 명령을 실행하는 기능까지 갖추고 있어, 사실상 브라우저가 원격 제어 콘솔로 변한다고 봐도 과언이 아니다.
실무자 입장에서 눈에 띄는 건 ‘거주(persistence)’ 기능이다. 한 번 심어진 PEEP 백도어는 브라우저가 다시 시작돼도 살아남으며, 공격자에게 안정적인 진입 통로를 제공한다.
4. 왜 초기 침투 도구가 아닌가 — 공격 단계상 위치의 의미
PEEP 백도어는 처음 PC에 침투할 때 쓰는 1차 도구가 아니다. 피싱이나 취약점 공격으로 이미 관리자 권한을 잡은 공격자가 ‘다음 단계’로 활용하는 도구다. 즉, PEEP 백도어만 단독으로 발견됐다면 그 PC에는 이미 더 큰 문제가 있었다고 봐야 한다.
다만 이 단계의 도구들이 정교해질수록, 기업 입장에서 평소 확장 프로그램 목록을 점검하는 일상의 중요성이 커진다. 초기 침투를 막지 못했더라도, PEEP 백도어와 같은 2차 도구를 빨리 발견하면 피해 확산을 줄일 수 있다.
5. 쟁점 — 웹스토어 정책과 무결성 검증의 한계
이 사건이 시사하는 구조적 문제는 두 가지다. 첫째, 공식 스토어를 우회한 확장은 사실상 검은 시장과 다크웹에서만 거래되며 일반 사용자가 사전에 알 방법이 없다. 둘째, 무결성 검증 체계 자체가 ‘정상 파일을 정상으로 보이게 만드는’ 공격을 구분하지 못한다.
단순히 사용자 경각심만으로 해결되는 문제가 아니라는 점에서, 브라우저 벤더의 정책 재설계가 필요해 보인다. 확장 설치 시 단순 팝업을 넘어 파일 해시와 출처를 강제 검증하는 방식이 도입되지 않으면 PEEP 백도어와 유사한 공격은 계속 등장할 가능성이 높다.
쟁점 정리
- 공식 스토어 우회 설치는 사용자 인지 영역 밖에서 일어난다
- 무결성 값 위조는 브라우저 보안 모델의 구조적 한계를 드러낸다
- PEEP 백도어는 단독 도구가 아닌 ‘거주’ 단계 도구이므로 발견 시 더 큰 침투가 있었음을 전제해야 한다
- 확장 프로그램 점검은 EDR 도입 기업에서도 형식적으로 끝나는 경우가 많다
지금 바로 해볼 것
- 크롬(chrome://extensions)과 엣지(edge://extensions)에 등록된 확장 목록을 지금 열어 출처가 불분명한 항목을 제거한다
- 그룹 정책(GPO) 또는 관리 콘솔로 비공식 확장 설치를 차단하는 정책을 적용한다
- EDR 솔루션에서 브라우저 프로세스(Chrome.exe, msedge.exe)의 자식 프로세스 실행을 모니터링하도록 룰을 점검한다
- 관리자 권한 계정의 평소 사용을 줄이고 일상 업무는 표준 사용자 권한으로 전환한다
- 주기적으로 브라우저 업데이트를 적용해 무결성 검증 체계 자체의 개선분을 받는다
자주 묻는 질문
PEEP 백도어는 일반 사용자도 감염될 수 있나요?
단독으로는 어렵습니다. PEEP 백도어는 이미 관리자 권한을 가진 공격자가 심는 도구이므로, 별도의 1차 침투(피싱, 취약점 공격 등)가 먼저 일어났을 가능성이 높습니다.
크롬 웹스토어에서 받은 확장도 안전한가요?
웹스토어를 거친 확장은 비교적 검증을 받지만 100% 안전하지는 않습니다. 가능하면 출처가 명확한 제작사의 확장만 설치하고, 설치 후에도 권한을 주기적으로 확인하는 것이 좋습니다.
어떤 증상이 나타나면 PEEP 백도어를 의심해야 하나요?
특정 확장 프로그램이 종료해도 다시 나타나는 경우, 브라우저가 비정상적으로 느려지거나 알 수 없는 프로세스가 자식 프로세스를 생성하는 로그가 보인다면 PEEP 백도어 포함 2차 침투 단계를 의심해야 합니다.
기업에서는 어떤 정책이 가장 효과적인가요?
비공식 확장 설치를 차단하는 그룹 정책과 브라우저 프로세스의 이상 행위를 탐지하는 EDR 룰 조합이 가장 실효성이 높습니다. 단일 통제만으로는 우회 시도가 빠르기 때문입니다.
참고 원문
이 기사는 다음 원문을 확인해 작성했습니다: 보안뉴스 — 브라우저가 감시 도구로… 크롬·엣지 확장 프로그램 위장 백도어 'PEEP' 발견
전문가 코멘트(AI)
정보보안침해대응전문가
PEEP류 확장 백도어의 본질은 신규 공격 기법이 아니라 ‘관리자 권한 확보 이후’를 방어하는 통제 공백의 노출이다
이 공격의 기술적 핵심은 크로미엄 계열 브라우저의 Secure Preferences 무결성 검증이 로컬 관리자 권한 앞에서는 재계산·위조가 가능하다는 신뢰 경계 약점을, 스토어 우회 설치라는 실전 경로로 자동화했다는 점이다. 세션 쿠키 탈취는 다중 인증을 우회하는 가장 실질적인 계정 장악 경로이고, 여기에 임의 명령 실행과 거주 기능이 결합되면 브라우저가 사실상 C2 채널이자 프록시로 전환된다. 다만 관리자 권한 선점이 전제 조건이므로 최소 권한 운영, GPO·ExtensionSettings 기반 비공식 확장 차단, 브라우저 프로세스 자식 실행 모니터링 등 이미 성숙한 통제로 상당 부분 방어 가능한 위협이다. 침해대응 관점의 유효 IOC는 스토어 출처가 아닌 로컬 경로에서 로드된 확장, preferences 파일의 비정상 쓰기, 브라우저 재시작 후 소리 없이 복구되는 확장 항목 등으로 구체화할 수 있다. 아쉬운 점은 이 유형의 무결성 위조가 전례 없는 신기법이 아니며, 상당수 EDR 환경이 브라우저 설정 변조를 기본 탐지 항목으로 삼지 않아 실전 탐지율이 배포 환경에 크게 좌우된다는 사실이다.
브라우저플랫폼보안엔지니어
확장 무결성 검증은 ‘사용자 수준 변조 차단’용 설계로, 관리자 권한 공격자를 상정하는 순간 구조적 한계에 도달한다
크로미엄의 확장 무결성 체계는 원래 사용자 수준 또는 원격 변조자의 설정 훼손 탐지를 위협 모델로 설계되었고, 검증 시드가 로컬 머신에 존재하는 이상 로컬 관리자를 막는 장치로는 처음부터 기대할 수 없다. 설치 동의 팝업은 OS가 강제하는 경계가 아니라 UI 정책일 뿐이므로, 문제의 본질은 우회 설치 자체보다 ‘스토어 밖 설치의 출처가 서명 기록으로 남지 않는다’는 점이다. 기술적으로는 설치 출처 서명·원격 증명, 비스토어 설치 기본 차단 기본값, 로드 시점 출처 재검증 같은 개선안이 존재하지만 호환성과 프라이버시 트레이드오프 때문에 도입이 더딘 것이 현실이다. 엔터프라이즈용 확장 제어 정책은 이미 강력하므로, 진짜 공백은 기술 부재가 아니라 그것이 기본값이 아니라는 배포 구조의 문제다. 매니페스트 V3 전환과 스토어 심사 강화로 스토어 경유 공격이 줄어드는 만큼 로컬 우회 설치의 상대적 비중은 커질 것이며, 이 사례는 그 방향성을 예고하는 전형으로 본다.
비판적 분석가
이 공개는 기술 분석이자 동시에 ‘1차 침투는 몰라도 2차 탐지가 곧 제품 가치’라는 보안 산업의 수요 창출 서사로 읽힌다
누가 이득을 보는가부터 물어야 한다 — 위협에 기억하기 쉬운 이름을 붙이고 ‘다크웹 거래’라는 프레임을 얹는 일은, 기술적 사실 그 자체보다 기업 보안 예산 심사 자리에서 인용되기 쉬운 서사를 만든다는 점에서 명확한 수혜 구조를 가진다. ‘공식 스토어를 우회한 확장은 다크웹에서만 거래된다’는 주장은 정황상 과장으로 읽힐 여지가 크다 — 이미 관리자 권한을 확보한 공격자에게 익명 시장은 불필요하며 직접 배포가 기본값이기 때문이다. ‘초기 침투 도구가 아니다’라는 분류는 기술적으로는 정확하지만, 동시에 1차 침투는 별개 문제로 치워두고 2차 단계 탐지를 제품 가치로 삼는 EDR 벤더 서사와 지나치게 깔끔하게 맞물린다. 브라우저 벤더는 스토어 밖 설치 통제 강화의 명분을 얻고, 보안 벤더는 브라우저 모니터링 수요를 얻고, 대중은 새로운 경각심 메시지를 얻는다 — 세 주체가 모두 이득을 보는 위협 서사는 결코 흔하지 않다. 우리가 진짜 주목해야 할 점은 피해 규모, 표적, 배포 채널에 관한 검증 가능한 데이터가 얼마나 공개되었는가이며, 그것이 비어 있다면 이 사건은 순수한 기술 분석이라기보다 마케팅에 최적화된 위협 스토리였을 가능성을 배제할 수 없다.
물밑 시나리오
- 위협 명명과 보고서 공개 시점이 해당 보안 기업의 위협 동향 발표·제품 홍보 주기와 겹쳤을 가능성이 있다 — 위협에 고유명사를 부여해 검색 가능한 브랜드를 만드는 것은 업계에서 오래 쓰여 온 리드 제너레이션 기법이기 때문이다.
- ‘다크웹 거래’ 프레임은 실제 배포 경로 증거보다 공포 기반 수요 창출 장치로 기능했을 수 있다 — 관리자 권한 선점이 전제된 공격에서는 익명 유통 시장 자체가 무의미하다는 정황과 충돌하기 때문이다.
답글 남기기