COMMENTS (0)
댓글은 익명으로 작성되며, 삭제 비밀번호를 설정하면 본인만 삭제할 수 있습니다. 비밀번호를 설정하지 않은 댓글은 누구나 삭제할 수 있습니다.
보안 기업 Trellix가 2026년 4월 RansomHouse에 소스코드 저장소를 침해당했다. 2억 개 엔드포인트를 보호하는 기업이 표적이 된 경위와 보안 업계 파급을 분석한다.
댓글은 익명으로 작성되며, 삭제 비밀번호를 설정하면 본인만 삭제할 수 있습니다. 비밀번호를 설정하지 않은 댓글은 누구나 삭제할 수 있습니다.
2026년 4월 17일, 데이터 탈취 그룹 RansomHouse는 사이버보안 기업 Trellix의 소스코드 저장소에 침투했다고 주장했다. Trellix가 침해를 공식 확인한 것은 그로부터 17일 뒤인 5월 4일이었다. 전 세계 5만 개 이상의 기업·정부 고객과 2억 개 이상의 엔드포인트를 방어하는 기업이 정작 자신의 코드베이스를 잃었다는 사실은, 보안 솔루션 공급자 스스로가 침해 피해자가 된다는 역설을 드러냈다. 탈취된 소스코드는 보안 제품의 내부 로직과 취약점 처리 구조를 담고 있어, 이를 확보한 제3의 공격자에게 Trellix 고객사 전체가 추가 위협의 잠재적 표적이 될 수 있다.
| 항목 | 내용 |
|---|---|
| 침해 주장 일자 | 2026년 4월 17일 (RansomHouse) |
| 공식 공개 일자 | 2026년 5월 4일 (Trellix) |
| 피해 대상 | 소스코드 저장소 일부 |
| 공격 그룹 | RansomHouse |
| Trellix 입장 | "배포 프로세스 및 소스코드 악용 증거 없음" |
Trellix는 2021년 10월 McAfee Enterprise와 FireEye의 합병으로 탄생했다. 전 세계 5만 개 이상의 기업과 정부 기관을 고객으로 두며, 보호 대상 엔드포인트 수는 2억 개를 넘는다. 금융·의료·국방 등 핵심 인프라 부문에 엔드포인트 보안, 네트워크 방어, 위협 인텔리전스 솔루션을 공급한다. Trellix의 전신인 FireEye는 2020년 러시아 연계 공격자에게 침해돼 레드팀 도구가 유출된 전례가 있었다. 그로부터 5년 만에, 합병 이후 재출범한 기업이 다시 침해 사고의 당사자가 됐다.
RansomHouse는 2021년 12월 캐나다의 Saskatchewan Liquor and Gaming Authority를 첫 피해자로 삼으며 등장했다. 이 그룹의 가장 큰 특징은 파일 암호화 없이 데이터 탈취만으로 협박한다는 점이다. 일반적인 랜섬웨어 그룹은 파일을 암호화한 뒤 복구 키 대가로 몸값을 요구하지만, RansomHouse는 처음부터 탈취 데이터를 공개하거나 다른 공격 그룹에게 판매하는 방식을 채택했다. 이들의 논리는 단순하다. "랜섬 협상은 시간과 관료적 절차가 필요하지만, 데이터 판매는 즉각 수익이 된다." 현재까지 170개 이상의 조직이 피해를 입었으며, 미국이 전체 공격의 47%를 차지한다.
2022년 6월, RansomHouse는 반도체 기업 AMD의 내부 네트워크에서 약 450GB의 데이터를 탈취했다고 공개했다. 유출된 파일에는 네트워크 구성 정보, 시스템 데이터, 7만 개에 달하는 내부 장비 정보, 직원 자격증명이 포함됐다. 자격증명 목록에는 "password", "123456", "Welcome1" 같은 취약한 패스워드가 다수 포함돼 있었다. AMD 사건에서 이 그룹은 몸값 협상을 기다리는 대신 데이터를 즉각 유출 사이트에 공개했다. 협박보다 데이터 판매가 더 수익성이 높다는 그들의 논리가 실행에 옮겨진 첫 대형 사례였다.
RansomHouse는 피싱·스피어피싱 이메일이나 공개된 취약점을 초기 침투 수단으로 활용하는 것으로 알려져 있다. 내부 진입 후에는 Cobalt Strike, Metasploit 등 공개 침투 테스트 프레임워크를 사용하며, VMware ESXi 서버를 자동 처리하는 자체 도구 MrAgent도 운용한다. 이 그룹은 "전문 중재자 커뮤니티"를 자처하며 정중한 커뮤니케이션 방식을 유지하는데, 이는 협상 전술이 아니라 데이터 판매 협상 창구를 열어 두기 위한 브랜딩에 가깝다.
RansomHouse는 4월 17일 Trellix 내부에 접근해 소스코드 저장소와 어플라이언스 관리 시스템에 침투했다고 주장한다. 어플라이언스 관리 시스템은 Trellix가 고객사에 공급하는 네트워크 보안 장비를 원격에서 관리하는 인터페이스다. 이들은 자체 darkweb 유출 사이트에 Trellix를 피해 조직으로 등록하고, 내부 시스템 화면 캡처를 증거로 게시했다. BleepingComputer는 해당 이미지의 진위를 독립 검증하지는 못했다.
Trellix가 사건을 공식 인정한 것은 5월 4일이다. 회사는 성명에서 "소스코드 저장소의 일부에 대한 무단 접근을 확인했으며, 외부 포렌식 전문가와 함께 즉각 대응에 나섰다"고 밝혔다. 법 집행 기관에도 통보했다. 이어 5월 8일 RansomHouse가 darkweb 유출 사이트에서 이 사실을 공개 주장하면서 외부에 알려졌다.
침투 주장 일(4월 17일)과 Trellix의 공개 일(5월 4일) 사이 17일의 공백은 두 가지로 해석된다. 하나는 Trellix가 침해를 조기에 감지하고 대응한 뒤 공개했다는 것, 다른 하나는 그 기간 동안 침해 사실을 인지하지 못했다는 것이다. 회사가 침해 감지 시점을 공개하지 않은 이상, 17일이 통제된 대응의 시간이었는지 미인지의 시간이었는지는 확인되지 않는다.
일반 기업의 데이터 유출과 달리, 보안 벤더의 소스코드 침해는 더 넓은 파급 효과를 낼 수 있다. 소스코드에는 제품의 내부 로직, 보안 검사 방식, 패치 이전 취약점의 처리 구조가 담겨 있다. 탈취된 코드가 다른 공격 그룹에 전달되면, 그들은 해당 보안 제품의 미공개 취약점을 먼저 파악하거나 정상 소프트웨어로 위장한 변조 버전을 배포하는 공급망 공격의 출발점으로 삼을 수 있다.
Trellix는 현재 "소스코드 배포 프로세스는 영향을 받지 않았으며, 소스코드가 악용된 증거는 없다"는 입장을 유지한다. 그러나 어떤 제품의 코드가 얼마나 노출됐는지는 밝히지 않았다. RansomHouse 역시 탈취 데이터의 용량이나 내용을 공개하지 않았다. Trellix 고객 5만 개 이상은 이 불확실성 속에서, 자신의 보안 아키텍처 신뢰 기반이 얼마나 노출됐는지를 스스로 가늠해야 하는 상황에 놓였다. 보안 솔루션 제공업체의 소스코드가 유출됐다는 사실만으로도, 그 제품을 기반으로 한 보안 아키텍처의 신뢰성에 의문이 생기기 때문이다.
이 파급 구조는 Trellix만의 문제가 아니다. 보안 기업이 공격 표적이 되는 이유는 그들이 고객사 인프라와 가장 깊이 연결된 위치에 있기 때문이다.
보안 기업이 공격의 표적이 되는 구조적 이유가 있다. 이들은 고객사의 인프라와 긴밀하게 연결돼 있어, 보안 벤더 한 곳을 침해하면 다수의 고객사로 접근 경로가 열릴 수 있다. 2020년 FireEye 침해는 그 파급 효과를 보여준 전례다. 당시 공격자는 FireEye의 레드팀 도구를 탈취했고, 이어진 SolarWinds 공급망 공격으로 미국 정부 기관을 포함한 수천 개 조직이 피해를 입었다.
이번 Trellix 사건에서는 그만한 파급이 확인되지 않았다. 조사가 진행 중이며, Trellix는 소스코드 악용 증거가 없다는 입장이다. RansomHouse가 공개한 스크린샷의 진위도 독립 검증되지 않았다. 단, RansomHouse의 수익 모델이 데이터 판매인 만큼, 탈취한 소스코드가 다른 위협 행위자에게 넘어갈 가능성은 배제할 수 없다. AMD 사건에서 이 그룹은 협상 없이 데이터를 즉각 제3자에게 공개했다. 소스코드를 구매할 동기가 있는 다른 공격자들에게 Trellix의 내부 코드는 AMD의 자격증명보다 훨씬 높은 가치를 가진다. 이것이 이번 사건이 2억 개 엔드포인트를 지키는 기업의 침해로 그치지 않을 수 있는 이유다.
Trellix는 조사 완료 후 추가 정보를 공개하겠다는 입장이다.
AI 활용 안내 이 글은 AI(Claude)의 도움을 받아 작성되었습니다. 인용된 통계와 사례는 참고 자료에 명시된 출처에 근거하며, 설명을 위한 일부 표현은 각색되었습니다.
면책 조항 본 글은 보안 인식 제고를 위한 교육 목적으로 작성되었습니다. 언급된 공격 기법을 실제로 시도하는 행위는 「정보통신망법」, 「형법」 등에 따라 처벌받을 수 있으며, 본 블로그는 이에 대한 법적 책임을 지지 않습니다.
KW_PROTECT_0