1P by GN⁺ 2시간전 | ★ favorite | 댓글 1개
  • 인기 시스템 유틸리티 HWMonitor와 CPU-Z의 다운로드 링크가 일시적으로 변조되어 악성코드가 배포됨
  • 공격자는 CPUID 웹사이트의 백엔드 일부를 장악해 정상 설치 파일 대신 악성 파일을 무작위로 제공함
  • 악성 버전은 가짜 CRYPTBASE.dll을 포함해 명령·제어 서버와 통신하며, PowerShell을 통해 메모리 내에서 실행되는 .NET 페이로드를 주입함
  • CPUID는 침해 사실을 인정하고 6시간 내 수정 완료, 서명된 원본 파일은 손상되지 않았다고 발표함
  • 이번 사건은 공급망 공격의 연장선으로, 코드 수정 없이도 배포 경로만으로 피해를 유발할 수 있음을 보여줌

CPUID 웹사이트 해킹으로 HWMonitor 다운로드가 악성코드로 교체됨

  • CPUID 웹사이트가 일시적으로 해킹되어 HWMonitor와 CPU-Z의 다운로드 링크가 악성코드 배포 경로로 변조됨
    • 공격자는 백엔드 일부를 장악해 정상 링크를 무작위로 악성 파일로 교체
    • 일부 사용자는 설치 파일이 안티바이러스 경고를 유발하거나 비정상적인 파일명으로 표시된다고 보고함
  • HWMonitor 1.63 업데이트 링크가 “HWiNFO_Monitor_Setup.exe”라는 잘못된 파일로 연결되는 사례가 확인되어, 상류 단계의 변조가 의심됨
    • Reddit 등 커뮤니티에서 다수의 사용자가 문제를 인지하고 경고를 공유함
  • CPUID는 이후 공식적으로 침해 사실을 인정, 소프트웨어 빌드 자체가 아닌 보조 API(백엔드 구성요소) 가 약 6시간 동안 침해되었다고 설명
    • 사건은 4월 9일부터 10일 사이에 발생했으며 현재는 수정 완료
    • 서명된 원본 파일은 손상되지 않았다고 명시함
  • 악성 설치 파일은 64비트 HWMonitor 사용자를 대상으로 하며, Windows 구성요소처럼 보이는 가짜 CRYPTBASE.dll을 포함함
    • 해당 DLL은 명령·제어(C2) 서버에 접속해 추가 페이로드를 다운로드
    • 악성코드는 디스크에 흔적을 남기지 않기 위해 PowerShell을 이용해 메모리 내에서 실행, 피해자 시스템에서 .NET 페이로드를 컴파일 후 다른 프로세스에 주입
    • Chrome IElevation COM 인터페이스를 통해 브라우저 저장 자격 증명에 접근하는 행위도 관찰됨
  • 분석 결과, 이번 공격은 과거 FileZilla 사용자를 노린 캠페인과 동일한 인프라를 활용한 것으로 확인됨
    • vx-underground 분석에 따르면 동일한 공격자 그룹이 여러 소프트웨어 배포망을 악용한 정황이 존재함
  • CPUID는 문제를 해결했다고 밝혔으나, API 접근 경로와 감염된 사용자 수는 아직 공개되지 않음
    • 이번 사건은 공격자가 코드 자체를 수정하지 않고도 배포 경로만으로 피해를 유발할 수 있음을 보여주는 사례로 평가됨
Hacker News 의견들
  • CPU-Z의 유지보수자 Sam이 직접 상황을 설명함. 현재 Franck이 자리를 비운 상태에서 서버를 점검 중이며, VirusTotal 링크 기준으로 서버 파일은 정상임을 확인했음. 다만 링크 일부가 변조되어 악성 설치 파일로 연결되었고, 약 6시간 동안(09/04~10/04 GMT) 노출되었음. 현재 링크를 복구하고 추가 조사를 위해 사이트를 읽기 전용 모드로 전환했음

    • 예전에 CPU 리뷰를 작성했던 사람으로서 Sam과 Franck 모두 신뢰할 수 있는 인물임을 보증함. Franck은 CPUID의 핵심 인물이고 Sam은 Canard PC와 Memtest 프로젝트로도 알려진 친구임
    • 문제를 빠르게 파악하고 링크를 수정한 점이 다행임. 사실 처음엔 cpuid.com의 광고 배너가 문제라고 생각했음. 다운로드 페이지에 “Download Now”, “Install for Windows 10/11” 같은 가짜 버튼이 너무 많음. 그래서 나는 이런 상황에서 winget install CPUID.CPU-Z 명령어를 선호함
    • 최근 몇 주간 Discord나 기타 채팅에서 가용성 알림이 악용되어 타이밍 공격이 일어나는 사례를 세 번째로 봤음
    • 이번 공격이 어떻게 이루어졌는지 궁금함
  • 다운로드 후 Windows Defender가 즉시 바이러스를 탐지했지만, 평소 오탐이 많아 무시했다는 사례임. 이런 오탐(false positive) 이 보안 경각심을 무디게 만드는 부작용이 있음

    • Microsoft의 책임도 일부 있다고 생각함. Defender가 단순히 “Win32/Keygen” 같은 이유로 크랙 파일을 차단하면서, 사용자들이 안티바이러스 비활성화 습관을 들이게 됨. 결국 진짜 악성코드도 통과시키는 결과를 낳음
    • 소스 기반 배포재현 가능한 빌드(reproducible builds) 를 통해 이런 문제를 완화할 수 있음
    • 이런 상황을 막으려면 신뢰할 수 있는 Windows 앱스토어나 패키지 매니저가 필요함
  • 새 버전 소프트웨어를 바로 설치하는 사람들을 “인간 방패”라 부르며 풍자함

    • 하지만 CPU-Z나 HWMonitor는 새 PC 설치 후 하드웨어 확인용으로 바로 쓰는 경우가 많음. npm 패키지처럼 실험적 업데이트를 테스트하는 게 아니라, 단순히 최신 버전을 받는 것뿐임
    • 사용자에게 소프트웨어의 안전도 평판을 알려주는 도구가 있으면 좋겠음. Crowdstrike나 SAST 도구는 설치 후 탐지에 그치기 때문임
    • 그러나 한 달 지난 버전이라고 해서 안전하다는 보장은 없음. 공격자는 수개월 뒤에야 악성 행위를 시작할 수도 있음
  • 이번에 영향을 받은 것은 HWMonitor이며, 공식 페이지HWInfo는 다른 프로그램임. Reddit에서도 같은 주제가 논의 중임

  • 설치 파일 자체는 정상인데, 사이트의 링크가 변조되어 Cloudflare R2에 있는 악성 실행 파일로 연결되었음. 향후 원인 분석이 기대됨

    • 이는 공급망 공격이라기보다는 워터링 홀(watering hole) 공격에 가까움. 개발자라면 winget이나 chocolatey 같은 패키지 매니저를 사용하는 게 더 안전함
  • Windows 사용자는 winget으로 설치하는 게 상대적으로 유리함. 공식 매니페스트에서 서명 검증을 수행하고, winget install --exact --id CPUID.CPU-Z 명령으로 안전하게 설치 가능함

    • 하지만 WinGet이 완전한 보호책은 아님. 검증 절차가 얕고, 원본이 이미 손상된 경우엔 악성 업데이트가 통과할 수도 있음. 사실상 CLI 버전 MajorGeeks 수준임
    • 매니페스트의 SHA 체크만으로는 변조를 막기 어려움. 서명 검증이 어떻게 작동하는지 궁금함
    • 그래도 Winget은 점점 나아지고 있음. 예를 들어 ImageMagick 공식 사이트 링크가 깨졌을 때 Winget으로는 정상 다운로드가 가능했음
    • 패키지 매니저 덕분에 최근의 Notepad++ 하이재킹 사건에서도 피해를 줄일 수 있었음. 개발자가 직접 배포하려면 PKI 관리와 서명키 분산 등 인프라 보안에 신경 써야 함
  • Winget을 통해 설치한 버전(v1.63, v2.19)이 안전한지 걱정됨. GitHub 매니페스트Winstall 링크를 확인 중임

  • 지난달 FileZilla를 공격했던 동일한 그룹이 이번에도 관여한 것으로 보임. 이번엔 가짜 도메인이 아니라 공식 사이트의 API 계층을 해킹해, 정상 사이트에서 악성 파일을 배포하게 만들었음

  • 추가적인 기술 세부사항은 vx-underground의 게시물에 정리되어 있음

  • 이번 공격은 기술 사용자들이 신뢰하는 유틸리티를 노린 정교한 시도로, 바이너리 자체가 아니라 다운로드 링크를 생성하는 API 레이어가 주요 공격 표면이 되었음