[8월 22일 보안브리핑] BounceBit·Apollo·Triple-A

오늘의 주요 보안 이슈

오늘 브리핑은 서로 다른 보안 경계가 무너진 세 사례를 다룹니다. BounceBit에서는 지갑의 개인키가 아니라 체인 프로토콜의 권한 검증이 공격 표면이 됐고, Apollo Global에서는 사회공학을 계기로 일부 클라우드 플랫폼에 무단 접근이 이뤄졌습니다. Triple-A가 공개한 사후 분석에서는 다중 채널 사칭으로 엔지니어 자격증명을 확보한 뒤 권한 상승, 악성코드, 정상 API 자격증명 악용을 거쳐 운영 지갑에서 회사 재무자산을 이동한 흐름이 드러났습니다. 환경은 다르지만, 세 사안 모두 요청을 만든 주체와 실행 권한을 끝까지 연결해 검증해야 한다는 공통점을 보여줍니다.

운영 관점에서 우선순위도 분명합니다. BounceBit 이용자는 공격 이전 스냅샷과 BNB Chain 재발행 절차를 기준으로 잔액을 확인해야 하며, 비공식 교환·복구 링크를 따라가면 안 됩니다. Apollo와 유사한 환경을 운영하는 조직은 사회공학을 단순 피싱 메일 문제로 좁히지 말고 헬프데스크 인증·세션·클라우드 권한을 한 흐름으로 점검해야 합니다. Triple-A 사례는 최초 계정 침해를 완전히 막지 못하더라도 운영 지갑, 고객 자금, 지역별 법인을 분리하면 피해 범위를 줄일 수 있다는 점을 구체적으로 보여줍니다.

주요 이슈 한눈에 보기

• BounceBit Chain: Evmos 기반 네이티브 모듈의 권한 검증 문제로 9개 메인넷 계정에서 약 2억8,650만 BB가 14건의 거래로 이동했습니다. 체인은 중단됐고 BB는 공격 이전 스냅샷을 기준으로 BNB Chain에서 BEP-20 토큰으로 재발행됩니다.
• Apollo Global: 7월 6일부터 10일까지 일부 클라우드 플랫폼에 무단 접근이 발생했습니다. 영향 정보에는 이름, 생년월일, 연락처, 자택 주소, 사회보장번호가 포함됐으며 회사는 수사기관과 외부 보안·포렌식 전문가를 투입했습니다.
• Triple-A: 7월 25일 다중 채널 사회공학으로 엔지니어 자격증명이 침해됐고, 권한 상승·악성코드·정상 API 자격증명 악용을 거쳐 운영 지갑에서 회사 재무자산이 이동했습니다. 약 3시간 안에 차단됐으며 고객 자금은 분리 신탁계좌에 보관됐습니다.

주요 침해사고

BounceBit Chain 권한 검증 악용

BounceBit가 8월 21일 공개한 보안 업데이트에 따르면 공격은 8월 19일 21시 2분부터 20일 1시 54분까지 UTC 기준으로 진행됐습니다. 공격자는 9개 메인넷 계정에서 약 2억8,650만 BB를 14건의 거래로 옮겼습니다. 문제의 핵심은 개인키 탈취나 서명 위조가 아니었습니다. BounceBit Chain이 기반으로 사용한 Evmos 스택의 네이티브 모듈에서 스마트계약 호출자가 자금 출처 계정을 지정할 때 해당 계정의 승인을 제대로 검증하지 못했고, 그 결과 다른 계정의 BB를 권한 없이 이동시키는 경로가 열렸습니다.

BounceBit는 블록 생산을 20,702,857번 블록 부근에서 멈추고 체인 상태를 고정했습니다. 이후 기존 Layer 1을 패치해 다시 가동하는 대신 독립 체인을 영구 종료하고, BB를 BNB Chain의 BEP-20 토큰으로 재발행하는 방향을 선택했습니다. 재발행 기준은 첫 무단 이동 이전인 20,697,260번 블록 스냅샷입니다. 공격자가 옮긴 물량은 새 토큰 잔액에서 제외되며, 보유자는 스냅샷을 기준으로 자동 분배를 받도록 설계됐습니다. 이 조치는 장부를 단순히 되돌리는 수준이 아니라, 더 이상 유지되지 않은 Evmos 기반 독립 체인의 운영 구조까지 바꾸는 결정입니다.

이용자가 확인할 대상은 지갑 전체가 아니라 BB의 보유 위치와 거래 시점입니다. 개인 지갑에서 공격 이전부터 BB를 보유했다면 공식 스냅샷 기준과 자동 분배 안내를 대조하면 됩니다. 중앙화 거래소에 보관했다면 거래소의 입출금 중단·재개 공지를 우선 확인해야 합니다. 체인 전환기에는 “수동 마이그레이션”, “잔액 동기화”, “긴급 복구”를 내세운 서명 요청이 등장하기 쉬우므로, BounceBit가 공개한 공식 채널과 거래소 공지 밖의 링크에서 지갑을 연결하거나 권한을 승인하지 않은 것이 중요합니다.

• 보유 위치 확인: 개인 지갑과 거래소 잔액을 구분하고 공격 이전 스냅샷 기준으로 대조합니다.
• 공식 공지 확인: BB 재발행과 입출금 재개 일정은 BounceBit와 이용 거래소의 공식 채널에서 확인합니다.
• 서명 요청 차단: 별도 에어드롭 신청이나 수동 전환을 요구하는 링크에서 지갑 연결과 토큰 승인을 진행하지 않습니다.
• 운영 자산 분리: Evmos 계열 모듈을 사용하는 체인은 출처 계정 지정과 승인 검증 로직을 별도로 검토합니다.

Apollo Global 클라우드 데이터 침해

Apollo Global Management가 캘리포니아 당국에 제출한 통지와 8월 21일 보도에 따르면, 회사는 7월 6일부터 10일까지 일부 클라우드 플랫폼에서 무단 접근을 조사했습니다. 회사는 이 사건을 사회공학과 연결해 설명했으며, 이번 달 초 조사 과정에서 이름, 생년월일, 연락처, 자택 주소, 사회보장번호가 영향을 받은 정보에 포함된다는 사실을 파악했습니다. Apollo는 수사기관에 사건을 알리고 외부 사이버보안·포렌식 전문가를 투입했으며, 영향을 받은 사람에게 신원 보호와 신용 모니터링 서비스를 제공하고 있습니다.

이번 사례는 클라우드의 기술적 설정만으로 침해 위험을 판단하면 놓치기 쉬운 지점을 보여줍니다. 사회공학으로 직원 인증 정보나 세션을 확보한 공격자는 정상 계정과 정상 브라우저 흐름을 사용할 수 있습니다. 그러면 경계 장비가 악성 파일을 탐지하는 방식보다, 평소와 다른 로그인 위치·시간·기기, 갑작스러운 권한 상승, 대량 조회나 다운로드, 새 토큰 발급을 연결해 보는 분석이 더 중요해집니다. 특히 금융·법률·투자 업종처럼 공개된 임직원 정보가 풍부한 조직은 공격자가 실제 회사명과 직무를 조합해 설득력 있은 통화를 만들 수 있다는 점을 전제로 절차를 설계해야 합니다.

개인정보 통지를 받은 이용자는 제공되는 보호 서비스에 등록하기 전에 통지서에 적힌 공식 웹주소를 직접 입력해야 합니다. 이름과 사회보장번호가 함께 노출된 범위라면 신용 보고서와 신규 계좌 알림을 확인하고, 본인이 신청하지 않은 대출·카드·주소 변경이 보이면 해당 금융기관의 공식 고객센터로 바로 연락하는 순서가 안전합니다. 조직은 피해자 지원과 별개로 헬프데스크의 본인 확인 절차, 고위험 계정의 피싱 내성 인증, 클라우드 세션 강제 종료, 장기 토큰 회수, 감사 로그 보존을 하나의 사고 대응 묶음으로 실행해야 합니다.

• 개인 대응: 공식 통지 경로에서 신원 보호 서비스를 확인하고 신용 보고서·신규 계좌 알림을 점검합니다.
• 연락 경로 검증: 통지 메일의 링크보다 회사와 금융기관의 공식 사이트·대표번호를 직접 이용합니다.
• 계정 대응: 의심 세션 종료, 비밀번호 재설정, 피싱 내성 다중인증 적용을 같은 순서로 처리합니다.
• 클라우드 추적: 로그인·권한 상승·토큰 발급·대량 조회 로그를 시간순으로 묶어 조사합니다.

Triple-A 운영 지갑 침해 사후 분석

Triple-A가 8월 21일 공개한 사후 분석에 따르면 사건은 7월 25일 싱가포르 법인의 운영 지갑에서 시작됐습니다. 공격자는 한 엔지니어를 상대로 여러 채널에서 신뢰를 쌓고 신분을 사칭했으며 실시간 통화까지 결합해 자격증명을 확보했습니다. 이후 운영 환경에 들어가 더 높은 시스템 권한을 얻고 악성코드를 배치했습니다. 공격 흐름은 생산 데이터베이스 접근, 정상 API 자격증명 악용, TRON·Ethereum·Polygon·Arbitrum에 있은 운영 지갑의 무단 출금으로 이어졌습니다.

Triple-A는 GMT 기준 2시 39분 무단 접근을 식별한 뒤 사고대응 절차와 전담 위원회를 가동했습니다. 일부 서비스를 유지보수 모드로 전환하고 외부 보안 조사기관 Sygnia와 블록체인 추적업체 zeroShadow를 투입했으며, 싱가포르 통화청과 경찰에도 사건을 알렸습니다. 5시 15분 무렵 초기 검증과 차단을 마치고 서비스를 복구해 탐지부터 약 3시간 안에 거래와 정산을 정상화했습니다. 조사 과정에서 공격자의 활성 접근을 제거하고 식별된 지속성 메커니즘도 다룹니다.

피해 범위를 제한한 핵심은 자산 구조였습니다. 공격받은 지갑에는 회사가 환전 과정에 사용하는 재무자산만 들어 있었고, 고객 자금은 DBS와 Standard Chartered 등 보호기관의 분리 신탁계좌에 보관됐습니다. 해당 운영 환경에서 고객 자금으로 이어지는 경로를 분리한 덕분에 회사는 손실을 준비금으로 흡수하면서 고객 거래와 정산을 계속할 수 있었습니다. 계정 하나가 침해됐을 때 무엇까지 도달할 수 있는지를 사전에 제한하는 구조가 사고 규모를 결정한 사례입니다.

• 통화 검증: 엔지니어와 운영 담당자에게 들어오는 권한·지원 요청은 통화와 메시지의 발신 채널을 분리해 재확인합니다.
• 운영 권한 축소: 생산 시스템 접근 인원을 줄이고 지갑 활동에 추가 승인과 강한 인증을 적용합니다.
• 환경 분리: 기업 업무망, 생산 환경, 운영 지갑을 나누고 한 영역의 자격증명으로 다른 영역에 들어가지 못하게 합니다.
• 실시간 탐지: 자격증명 오용, 권한 상승, API 키 사용, 비정상 출금을 하나의 시간선으로 경보화합니다.
• 지갑 한도 관리: 운영 지갑의 노출 한도와 자산 이동 승인 조건을 정기적으로 재검토합니다.

운영 참고

세 사안의 대응을 하나의 공통 점검표로 바꾸면 먼저 권한의 출처를 확인해야 합니다. 블록체인에서는 거래에 지정된 자금 출처와 실제 승인 주체가 일치하는지, 기업 클라우드에서는 로그인한 계정과 요청을 시작한 사람의 신원이 같은지, 운영 지갑에서는 엔지니어 계정이 생산 데이터베이스와 API 자격증명까지 연속해서 접근할 수 있는지를 살펴봐야 합니다. 다음으로는 스냅샷, 세션 회수, 환경 분리, 지갑 한도처럼 공격자가 도달할 수 있은 범위를 잘라내는 조치가 우선입니다.

마지막 단계는 이용자와 운영자가 같은 출처를 보도록 만드는 일입니다. 토큰 재발행, 개인정보 보호 서비스, 자산 추적처럼 후속 절차가 필요한 사안일수록 비공식 안내가 끼어들 여지가 커집니다. 공식 공지 주소를 내부 티켓과 고객 안내에 함께 남기고 변경 시각·담당자·검증 결과를 기록하면 다음 교대조가 같은 기준으로 판단할 수 있습니다. 긴급성만 강조하기보다 누가 무엇을 확인했고 어떤 권한을 회수했는지까지 남기는 것이 재침입과 2차 사기를 줄이는 데 도움이 됩니다.