CenterPoint Energy가 SEC 공시로 확인한 고객정보 유출 사고를 정리했다. 회사는 내부 탐지가 아니라 해킹 포럼 게시글을 통해 침해 사실을 알았다.
2026년 9월 1일, 정체불명의 인물이 해킹 포럼에 파일을 올렸다. 텍사스 대형 전력·가스 공급사 CenterPoint Energy의 고객 데이터라는 주장이었다.
회사는 자체 로그가 아니라 이 게시글을 외부에서 파악하고서야 침해 사실을 알았다. 2주 뒤인 9월 14일, CenterPoint는 SEC 공시로 유출을 공식 확인했다.
CenterPoint Energy는 휴스턴을 중심으로 텍사스에서만 약 280만 명, 인디애나·미네소타·미시시피·루이지애나·오하이오를 합쳐 총 약 400만 고객에게 전기·가스를 공급하는 Fortune 500 유틸리티다. 이런 규모의 인프라 기업은 개인정보뿐 아니라 청구·서비스 이력까지 대량으로 쌓아두고 있어, 공격자에게는 매력적인 표적이다.
이번 사건의 공격자로 지목된 건 "4d722e4d656f77"라는 별칭을 쓰는 인물 또는 그룹이다. 랜섬웨어 조직처럼 시스템을 암호화하지 않았다. 대신 데이터를 확보해 포럼에 직접 올리는, 데이터 판매·공개형 액세스 브로커에 가까운 수법을 택했다.
9월 1일, 공격자는 해킹 포럼에 원본 749만 건, 정제 후 673만 건이라는 수치를 내세워 데이터를 게시했다. CenterPoint는 이 게시물을 외부에서 파악한 뒤 사이버보안 사고대응 절차를 가동하고 외부 전문가를 투입했다.
9월 14일, 회사는 SEC에 Form 8-K를 제출해 "외부 대면 시스템을 통한 무단 접근"이 있었다고 공식 확인했다. 다만 어떤 시스템이 어떤 방식으로 뚫렸는지는 공시에 명시하지 않았다.
공격자는 별도로 인증과 rate limiting이 미흡한 회사 관리 API를 악용했다고 주장했다. 이는 공격자 발언일 뿐, 회사가 공식 확인한 침투 경로가 아니다.
공격자가 게시한 데이터셋에는 고객명, 전화번호, 서비스·청구 주소, 계정번호, premise ID, 청구 금액, 납부 상태, 자동납부 여부, 사회보장번호 일부가 포함된 것으로 보도됐다. CenterPoint의 공식 공시는 "고객 일부의 개인정보"라고만 서술해, 정확한 항목과 규모를 특정하지 않았다.
전기·가스 공급 서비스 자체는 영향을 받지 않았다. 청구·고객 시스템 침해였을 뿐, 운영기술(OT) 영역까지 번지지는 않은 것으로 보인다.
피해 고객을 대리해 이미 여러 로펌이 집단소송 조사에 들어갔다. 유출 규모가 공식 확정되기도 전에 법적 절차가 먼저 움직이기 시작한 셈이다.
이번 사건에서 눈에 띄는 대목은 CenterPoint가 내부 로그가 아니라 외부 게시글을 통해 침해를 알았다는 점이다. 대량 API 스크래핑형 유출은 인증 실패나 이상 트래픽으로 내부에서 먼저 잡히기보다, 다크웹·해킹 포럼 모니터링 서비스가 데이터 판매 게시글을 포착하면서 뒤늦게 드러나는 경우가 흔하다.
공격자 주장대로 인증되지 않은 API가 통로였다면, 짧은 시간에 다수 계정 레코드를 순차 조회하는 요청 패턴이 로그에 남았을 가능성이 크다. 단일 세션에서 비정상적으로 큰 응답 크기가 반복되는 것도 대량 스크래핑의 전형적 흔적이다.
WAF나 API rate limiting이 갖춰져 있었다면 이런 패턴은 초기에 차단됐을 것이다. 공격자가 스스로 "미흡한 rate limiting"을 자백했다는 사실은, 이후 소송에서 회사 측 보안 통제 수준이 핵심 쟁점이 될 가능성을 시사한다.
CenterPoint 사례는 대형 인프라 기업도 침해를 외부 제보로 알게 될 수 있다는 걸 보여준다. 내부 탐지 체계보다 위협 인텔리전스·다크웹 모니터링이 먼저 신호를 잡는 구조는 이 회사만의 문제가 아니다.
2024년 10월 미국 유틸리티 American Water가 겪은 랜섬웨어형 침해와 비교하면 차이가 드러난다. 그때는 청구 시스템이 일주일간 마비됐지만, 이번엔 서비스 중단이 없었다. 데이터를 확보한 뒤 암호화 없이 곧장 공개하는 수법이 최근 액세스 브로커 사이에서 늘고 있다는 정황과도 맞아떨어진다.
국내 전력·가스 공급 업체나 대형 공공 인프라 기업도, 고객 조회용 API를 외부에 노출하고 있다면 인증·rate limiting 설정을 다시 점검해볼 만하다.
AI 활용 안내 이 글은 AI(Claude)의 도움을 받아 작성되었습니다. 인용된 통계와 사례는 참고 자료에 명시된 출처에 근거하며, 설명을 위한 일부 표현은 각색되었습니다.
면책 조항 본 글은 보안 인식 제고를 위한 교육 목적으로 작성되었습니다. 언급된 공격 기법을 실제로 시도하는 행위는 「정보통신망법」, 「형법」 등에 따라 처벌받을 수 있으며, 본 블로그는 이에 대한 법적 책임을 지지 않습니다.