AI 공격이 6시간 안에 자격 증명 수천 개를 털었다…대응 창이 짧아졌다

Google Threat Intelligence Group(GTIG)은 2026년 9월 8일, 2026년 2분기 실제 침해 대응에서 관측한 다중 AI 에이전트 기반 자격 증명 공격을 공개했다. GTIG의 공식 위협 보고서 에 따르면 의심되는 금전 목적 공격자는 이미 침해한 조직의 클라우드 인프라에 프레임워크를 배치하고, 6시간 안에 대규모 수집 캠페인을 계획·구축·실행해 제3자 자격 증명 수천 개를 침해했다.

같은 날 확인된 사건의 핵심은 AI가 표적 선정부터 최초 침입까지 전 과정을 혼자 수행했다는 것이 아니다. BleepingComputer의 사건 분석 도 공격자가 먼저 클라우드 환경을 침해한 뒤 AI 코딩 챗봇, 프롬프트, Markdown 지침을 결합했으며, 실제 표적에 대한 완전 자율 공격 파이프라인은 아직 관측되지 않았다고 구분한다. 확인된 변화는 스캔, 오류 해결, IP 교체와 수집을 이어 붙여 사람의 개입 대기 시간을 줄였다는 점이다.

6시간은 최초 침입 시간이 아니라 자동화 구축·실행 시간이다

제목의 ‘6시간’은 공격자가 외부에서 조직을 처음 발견해 클라우드 침해 전체를 끝낸 보편적 소요 시간이 아니다. 최초 접근은 이미 이뤄진 상태였고, 그 뒤 대규모 자격 증명 수집 캠페인을 계획하고 도구를 구성해 실행하는 데 걸린 관측 시간이다. 따라서 모든 조직이 정확히 6시간 안에 같은 피해를 입는다는 뜻도 아니다.

공격자는 AI 코딩 챗봇에 단일 질문을 던진 것이 아니라 프롬프트, 에이전트 지침, 사전 작성된 Markdown 운영 플레이북을 결합했다. 이 구성은 취약점 스캔 파이프라인을 관리하고, 실행 중 발생한 오류를 실시간으로 처리하며, 발신 IP를 교체하는 논리를 수동 조작 없이 이어갔다. 사람은 침해 환경과 목표, 지침을 제공했지만 반복 작업 사이의 정지 시간이 짧아졌다.

결과적으로 기존에는 운영자가 로그를 확인하고 명령이나 도구를 고친 뒤 재실행했을 단계가 하나의 연속 작업으로 묶였다. 수천 개라는 피해 규모와 6시간이라는 속도는 이 특정 사건에서 함께 관측됐으며, 정확한 자격 증명 개수와 종류, 피해 서비스 목록은 공개되지 않았다.

‘자율 프레임워크’와 ‘완전 자율 해킹’은 같은 말이 아니다

이 사건의 프레임워크는 정해진 공격 흐름 안에서 여러 작업을 스스로 조율했다는 의미에서 자율적으로 작동했다. 그러나 사람이 초기 접근과 목표 설정에서 빠졌다는 증거는 없다. 보고서 역시 실제 표적을 상대로 제로데이 발견부터 네트워크 침투까지 수행하는 완전 자율 파이프라인을 관측했다고 결론 내리지 않았다.

이 구분은 위험을 낮춰 보는 근거가 아니라 방어 대상을 정확히 정하는 기준이다. 보안팀이 먼 미래의 독립형 공격 AI만 상정하면, 현재 이용 가능한 코딩 도구와 지침 파일로 스캔·재시도·수집을 가속하는 공격을 놓치기 쉽다. 당장의 변화는 새로운 침투 능력이 무에서 생긴 것이 아니라 기존 절차에서 사람의 확인 간격이 제거된 데 있다.

별도로 관측된 중국 연계 행위자의 자동 침투 테스트 프레임워크는 표적 상태 관찰, 포트 스캔, 서비스 분석을 수행하도록 설계됐지만 구축 시도 단계에 머물렀고 관련 자산이 차단됐다. 이 사례와 실제로 수천 개의 자격 증명이 침해된 6시간 사건을 합쳐 ‘완전 자율 공격이 실전에 배치됐다’고 표현하면 확인된 범위를 넘어선다.

정상 조직 IP도 스캔 행동을 보이면 조사해야 한다

6시간 사건에서 공격 트래픽은 피해 조직의 클라우드 인프라를 거쳐 정상적인 조직 IP에서 나갔다. 외부 공격 서버의 평판, 국가, 차단 목록에 지나치게 의존하면 이미 신뢰된 자산이 공격 발판으로 바뀐 순간을 놓칠 수 있다. 탐지 단위는 IP 하나가 아니라 워크로드·신원·목적지·행동의 조합이어야 한다.

실무적으로는 평소 제한된 서비스만 호출하던 워크로드가 짧은 시간에 다수의 외부 호스트와 포트에 접속하고, 실패 후 재시도를 반복하는 변화를 우선 조사할 수 있다. 새 프로세스 실행, DNS 질의 대상 증가, 외부 연결 확장, 여러 인증 엔드포인트 호출이 같은 시간대에 이어진다면 각각을 낮은 위험 이벤트로 분리하지 않는 편이 합리적이다.

자동 IP 교체는 주소별 요청량을 분산하므로 단일 IP의 임계치만으로는 활동이 작아 보일 수 있다. 클라우드 흐름 로그와 DNS·프록시 기록, 프로세스 실행 내역, 서비스 계정 인증 로그를 공통 시간축에 놓고 동일한 도구·계정·목적지 패턴을 묶어야 한다. 정상 IP라는 속성은 허용 근거가 아니라 다른 행동 신호와 함께 평가할 입력값이다.

고정된 범용 임계치를 제시하기는 어렵다. 조직마다 정상적인 외부 자산 수와 배포 주기가 다르기 때문이다. 다만 외부 목적지의 급증, 평소 없던 스캔 도구나 셸 실행, IP가 바뀌어도 계속되는 동일 인증 시도라는 세 변화가 겹치면 높은 우선순위로 올릴 근거가 된다.

개발자 비밀과 프로덕션 권한의 연결을 줄여야 한다

수집 속도가 빨라지면 장기 유효한 비밀을 발견한 뒤 검증하고 재사용할 수 있는 시간도 짧아진다. 개발자 개인 토큰, CI/CD 자격 증명, 프로덕션 클라우드 권한을 같은 저장소나 실행 환경에 두면 한 지점의 침해가 여러 서비스로 번질 수 있다. 대응의 중심은 유출 파일만 삭제하는 것이 아니라 자격 증명이 열어 둔 권한 경로를 끊는 데 있어야 한다.

사람의 개발 계정, 자동 빌드 계정, 프로덕션 워크로드 신원을 분리하고 각 신원에는 필요한 권한만 부여하는 방식이 피해 범위를 제한한다. 가능한 환경에서는 장기 API 키보다 수명이 짧은 토큰과 워크로드 신원 연동을 우선할 수 있다. 저장소뿐 아니라 빌드 로그, 환경 변수, 캐시와 AI 코딩 도구가 읽는 프로젝트 디렉터리도 비밀 검사 범위에 포함해야 한다.

폐기 범위도 최초 발견된 키 하나로 끝내서는 안 된다. 해당 키로 발급한 세션, 새로 만든 서비스 계정과 하위 키, 접근 가능한 외부 서비스 토큰을 함께 확인해야 한다. 공격자가 이미 검증을 끝낸 비밀은 원래 파일을 지우거나 발신 IP를 차단해도 계속 사용할 수 있기 때문이다.

대량 검증 활동은 별도의 경보 후보다. 한 워크로드가 여러 프로젝트나 비밀 저장소를 연속 조회한 뒤 서로 다른 클라우드·AI 서비스의 인증 API에 요청하고, 많은 실패 뒤 일부 성공이 이어지는 패턴은 수집한 키를 자동으로 시험하는 흐름일 수 있다. 정상적인 비밀 순환 작업에는 승인된 실행 주체와 대상 목록을 연결해 이런 무차별 검증과 구분할 필요가 있다.

GPU 생성과 비밀 검증은 별개 경보가 아니라 신원 흐름이다

보고서에 나온 ‘Recon’은 6시간 사건과 별개의 관측 사례다. Help Net Security의 보도 에 따르면 노출된 지휘통제 서버의 운영 화면은 클라우드·AI 서비스 API 키를 포함해 2만3,800개가 넘는 수집 비밀을 실시간으로 정리·검증·관리하도록 구성됐다. 이 숫자를 6시간 사건에서 침해된 자격 증명의 정확한 개수로 사용해서는 안 된다.

두 사례를 함께 보면 수집 이후의 검증과 자원 악용까지 하나의 신원 활동으로 추적해야 할 이유가 드러난다. GPU 인스턴스 생성 자체는 정상 업무일 수 있지만, 과거에 컴퓨팅 자원을 만들지 않던 개발자 토큰이나 서비스 계정이 새로운 리전에서 고성능 인스턴스를 생성하고 외부 이미지를 내려받거나 할당량 변경을 시도한다면 맥락이 달라진다.

경보는 인스턴스 유형 하나보다 생성 주체, 리전, 권한 변경, 시작 스크립트, 외부 통신과 비용 변화를 묶는 편이 낫다. 여기에 같은 신원의 비밀 저장소 대량 조회나 여러 인증 서비스에 대한 검증 요청이 선행됐다면 우선순위를 높일 수 있다. 대응할 때도 의심 워크로드를 격리하는 동시에 관련 세션과 토큰을 폐기하고, 그 신원이 생성한 키·역할·컴퓨팅 자원을 함께 조사해야 한다.

현재 공개되지 않은 정보는 피해 조직과 공격자의 구체적 신원, 사용된 AI 코딩 챗봇의 제품명, 최초 클라우드 접근 방식, 자격 증명별 피해 범위다. 확인된 것은 침해 후 다중 에이전트 자동화가 수집 캠페인의 구축과 실행을 6시간 이내로 압축했고 수천 개의 제3자 자격 증명이 침해됐다는 사실이다. 반면 실제 표적에 대한 완전 자율 공격 파이프라인이 운용됐다는 증거는 아직 없다.