고객지원 채팅에 올라온 파일 하나가 소프트웨어 신뢰 체계의 민감한 층을 건드렸다. Mozilla에 기록된 사고 설명에 따르면, 공격자는 2026년 4월 2일 DigiCert 지원팀에 고객 채팅 채널로 접근해 고객 스크린샷처럼 위장한 ZIP 파일을 보냈고, 그 안에는 악성 페이로드가 포함된 .scr 실행 파일이 들어 있었다 ^[12]. 이후 침해된 지원 시스템을 통해 제한된 수의 코드 서명 인증서 초기화 코드가 확보됐고, 그중 일부는 악성코드 서명에 사용된 것으로 보고됐다 ^[1].

사건은 어떻게 시작됐나

공격의 출발점은 DigiCert 지원 채널을 겨냥한 사회공학이었다. Help Net Security도 이 사건의 핵심을 비슷하게 설명한다. 고객 스크린샷으로 보이도록 꾸민 ZIP 파일 안에 윈도우 화면 보호기 형식인 .scr 파일이 들어 있었고, 이 파일이 악성 기능을 수행했다는 것이다 ^[2].

SecurityWeek에 따르면 악성코드는 두 개의 엔드포인트를 감염시켰다. 하나는 4월 3일 탐지됐고, 다른 하나는 4월 14일에 확인됐다 ^[10]. 공격자는 감염된 시스템에서 내부 지원 포털로 이동한 것으로 전해졌다 ^[10]. 이 포털에는 인증된 DigiCert 지원 분석가가 제한된 기능을 통해 고객 계정으로 전환해 볼 수 있는 기능이 있었고, 이 기능을 통해 보류 중인 인증서의 초기화 코드 등 특정 기능에 접근할 수 있었다고 SecurityWeek는 설명했다 ^[10]. BleepingComputer 역시 범위는 제한적이었다고 전하면서, 이미 승인됐지만 아직 전달되지 않은 EV 코드 서명 인증서의 초기화 코드가 노출됐다고 보도했다 ^[5].

왜 EV 코드 서명 인증서가 표적이 됐나

코드 서명 인증서는 소프트웨어의 출처와 무결성을 판단하는 데 쓰이는 신뢰 체계의 일부다. DigiCert는 브라우저와 운영체제에서 신뢰되는 주요 인증기관으로, 인터넷 통신과 소프트웨어 배포에서 중요한 역할을 하며 코드 서명 인증서는 소프트웨어 개발자들이 널리 사용한다 ^[11].

따라서 이번 사건의 본질은 단순한 지원 시스템 침해만이 아니다. 공격자는 코드 서명이 주는 ‘겉보기 신뢰’를 악용했다. ThreatNoir는 확보된 코드 서명 인증서 중 일부가 악성코드 서명에 사용됐다고 전했다 ^[1]. CyberInsider도 공격자가 내부 지원 시스템과 인증서 발급 관련 데이터를 악용해 유효한 EV 코드 서명 인증서를 얻었고, 일부 인증서가 나중에 악성코드 서명에 사용됐다고 설명했다 ^[11].

이 점이 위험하다. 서명된 악성 파일은 처음 봤을 때 정상 소프트웨어처럼 보일 수 있다. Vectra는 공격자가 EV 인증서를 이용해 악성 파일에 서명하고, EV 서명 애플리케이션에 부여되는 높은 신뢰를 악용할 수 있다고 설명한다. 서명 기반 신뢰에만 의존하는 조직은 이런 방식에 취약해질 수 있다 ^[15].

루트 키 탈취로 볼 수는 없다

다만 범위는 구분해서 봐야 한다. 현재 공개된 자료들이 설명하는 것은 지원 엔드포인트 침해, 내부 지원 기능 악용, 초기화 코드 접근이다 ^{[1][5][10][12]}. 이 자료들은 DigiCert의 루트 키나 인증기관, 즉 CA 키가 침해됐다고 설명하지 않는다.

그렇다고 사건이 가볍다는 뜻은 아니다. 다만 알려진 내용만 놓고 보면, 이번 사고는 인증기관 전체가 장악된 사건이라기보다 코드 서명 인증서의 지원·발급 절차가 악용된 사건에 가깝다 ^[1][5][10].

피해 규모: 숫자가 다르게 보이는 이유

공개된 수치는 완전히 한 가지로 정리되지 않는다. 각 보도가 서로 다른 기준을 말하고 있기 때문이다.

• ThreatNoir는 제한된 수의 코드 서명 인증서가 관련됐고, 그중 일부가 악성코드 서명에 쓰였다고 설명했다 ^[1].
• Risky Business는 도난당한 코드 서명 인증서 27개가 이후 악성코드 서명에 사용됐다고 보도했다 ^[8].
• ThreatLocker는 총 60개의 코드 서명 인증서가 폐기됐다고 전했다 ^[3].

따라서 숫자를 볼 때는 ‘확보된 인증서’, ‘악용된 인증서’, ‘폐기된 인증서’가 같은 범주인지 확인해야 한다. 보도상 사건의 범위는 제한적이었지만, 유효해 보이는 코드 서명 인증서 몇 개만으로도 공격자는 신뢰를 악용한 악성코드 유포를 시도할 수 있다 ^[1][15].

DigiCert의 조치: 폐기와 주문 취소

BleepingComputer에 따르면 DigiCert는 식별된 인증서를 발견 후 24시간 안에 폐기했고, 폐기 일자를 인증서 발급일로 되돌려 설정했다 ^[5]. 또한 영향을 받은 기간의 보류 주문은 예방 차원에서 취소됐다 ^[5]. ThreatNoir도 영향을 받은 인증서가 발견 후 24시간 안에 폐기됐고, 해당 기간의 미처리 주문이 취소됐다고 전했다 ^[1].

인증서 폐기는 추가 악용을 줄이는 데 필요하지만, 방어자 입장에서 일이 끝났다는 뜻은 아니다. EV 서명은 공격자가 의도적으로 활용하는 신뢰 신호가 될 수 있으므로, 보안팀은 서명된 파일도 인증서 정보, 파일 해시, 실행 행위, 위협 인텔리전스 맥락을 함께 놓고 판단해야 한다 ^[15].

Microsoft Defender 오탐이 만든 혼선

사건 주변에서는 Microsoft Defender 오탐도 혼란을 키웠다. BleepingComputer는 Microsoft Defender가 DigiCert 인증서를 Trojan:Win32/Cerdigent.A!dha로 잘못 탐지했다고 보도했다 ^[5]. Daily.dev는 4월 30일 서명 업데이트 이후 Defender가 정상적인 DigiCert 루트 인증서를 잘못 표시했으며, Microsoft가 이후 Security Intelligence 업데이트 1.449.430.0으로 수정하고 제거된 인증서를 복원했다고 정리했다 ^[7].

기업 보안팀에는 까다로운 상황이었다. 실제 인증서 악용, 서명된 악성코드에 대한 경보, 그리고 정상 인증서에 대한 오탐을 동시에 구분해야 했기 때문이다 ^[5][7].

보안팀이 바로 점검할 포인트

이번 사건의 교훈은 코드 서명이 무의미하다는 것이 아니다. 코드 서명은 여전히 중요한 단서다. 다만 그것이 최종 판정이 되어서는 안 된다.

• 서명을 보되, 맹신하지 않는다. 유효한 서명이나 EV 기반 서명이 있다고 해서 파일이 자동으로 안전하다고 볼 수는 없다. 공격자는 EV 인증서를 악성 파일 서명에 활용할 수 있다 ^[15].
• 인증서 세부 정보를 함께 본다. 발급자, 일련번호, 인증서 체인, 타임스탬프, 폐기 상태는 의심스러운 실행 파일을 판단할 때 중요하다. DigiCert 사건에서도 인증서 폐기와 폐기일 조정이 핵심 대응이었다 ^[5].
• 파일 행위를 더 무겁게 본다. 해시, 프로세스 생성, 네트워크 연결, 지속성 확보 방식, 샌드박스 결과를 서명 정보와 함께 봐야 한다. 서명된 악성코드는 바로 이 신뢰를 노린다 ^[15].
• 지원·관리 포털을 고위험 구역으로 다룬다. 제한된 지원 기능이라도 고객 계정 접근이나 인증서 초기화 코드 조회와 연결되면 보안상 중요한 공격 경로가 될 수 있다 ^[10].
• 오탐 대응 절차도 필요하다. Defender 사례처럼 인증서 관련 경보가 항상 실제 감염을 뜻하지는 않는다. 정상 DigiCert 루트 인증서가 잘못 탐지됐고, 이후 Microsoft 업데이트로 복원됐다는 보고가 있었다 ^[7].

결론

DigiCert 사건은 EV 코드 서명 인증서의 신뢰 효과가 방어자에게도 역이용될 수 있음을 보여줬다. 공개된 보고를 기준으로 하면 루트 키나 CA 키가 침해된 사건이라기보다, 지원 시스템과 초기화 코드, 그리고 일부 악용된 코드 서명 인증서를 둘러싼 제한적이지만 중요한 보안 사고였다 ^{[1][5][10][12]}. 결론은 분명하다. 현대적인 악성코드 방어에서 디지털 서명은 중요한 단서일 수 있지만, 결코 마지막 답이 되어서는 안 된다.