피싱 메일 없이 도달하는 로컬 실행

[관점]

사내에 AI 도구를 들일 때 심사 항목은 대체로 데이터 학습 여부와 정보 유출 가능성에 맞춰진다. 필요한 질문이지만, 그 질문만으로는 이 사안이 걸러지지 않는다.

이 리서치가 드러내는 것은 데이터가 나가는 문제가 아니라 명령이 들어오는 문제다. 설정이 기기 간에 동기화되고 그 설정이 로컬 도구를 부릴 수 있으면, 계정 하나만 확보한 공격자가 피해자 단말에서 코드를 실행할 수 있다. 메일을 보낼 필요도 없다.

그래서 AI 데스크톱 앱은 생산성 도구가 아니라 특권 소프트웨어로 분류해야 한다. 원격 관리 도구를 심사할 때 쓰던 기준을 그대로 가져오는 편이 맞다.

Pentera 의 공격보안 서비스팀은 AI 데스크톱 애플리케이션의 설정 동기화 기능을 매개로 피해자 단말에서 코드를 실행하는 경로를 실증하였다. 전제는 하나다 — 피해자의 이메일 플랫폼 접근권 확보다.

구조의 문제

리서치가 주목한 것은 개인 설정(Personal Preferences) 필드가 모든 세션과 기기에 동기화된다는 점이다. 이 필드는 사용자가 어시스턴트에게 자신의 선호를 알려 두는 자리이므로, 내용이 곧 지시로 해석된다. 그리고 데스크톱 앱은 확장·MCP·터미널을 통해 로컬과 상호작용한다.

두 성질이 결합하면 결과가 달라진다. 웹에서 계정에 접근한 공격자가 설정을 바꾸면, 그 지시가 피해자의 데스크톱 앱으로 따라 내려가 로컬 도구를 호출한다.

두 가지 경로

리서치는 네 단계(계정 접근 → payload 주입 → 도구 열거 → 명령 실행 또는 피싱)를 제시하고, 피해자 환경에 따라 두 갈래로 구분한다.

명령 실행 확장이 이미 설치된 경우. 동기화된 설정에 인코딩된 지시를 심어 두면, 어시스턴트가 사용 가능한 도구를 스스로 탐지한다. 사용자가 평소처럼 대화를 시작할 때 배경에서 공격자의 명령이 실행되고, 사용자에게는 정상 응답으로 보인다.

확장이 설치되지 않은 경우. 동기화된 설정이 오류 메시지를 만들어 내고, 어시스턴트 자신이 피싱 계층 역할을 한다. 사용자에게 확장 설치를 유도하되 그것이 오류 해결처럼 보이게 한다. 설치가 끝나면 앞의 경로로 합류한다.

두 번째가 특히 다루기 어렵다. 사용자가 의심할 대상이 낯선 메일이나 링크가 아니라 평소 쓰던 도구의 안내 메시지이기 때문이다.

설정 동기화를 매개로 한 공격 경로 4단계와 두 갈래 분기 Deloitte One Cyber & Resilience

파급 범위

리서치는 연구·개발 워크스테이션이 표적이 될 경우를 짚는다. 그 단말에는 SSH 키와 클라우드 자격증명이 있고, 로컬 실행이 성립하면 조직 내부 접근으로 이어진다. 개인 계정 하나의 문제가 조직 사고가 되는 지점이다.

리서치의 권고는 세 층으로 나뉜다. 사용자에게는 AI 앱의 로컬 권한을 파악하고 팝업·오류 메시지를 독립적으로 검증하며 설치 지시에 즉시 응하지 말 것을, 보안팀에는 AI 데스크톱 앱을 특권 소프트웨어로 분류하고 설정 변경·동기화를 모니터링하며 확장 설치를 제한하고 비정상 자식 프로세스를 탐지할 것을, 레드팀에는 AI 앱의 동기화 설정과 도구 생태계를 평가 범위에 포함할 것을 제시한다.

국내 적용 관점

분류를 먼저 바꿔야 통제가 붙는다. 국내 조직의 소프트웨어 심사 대장에서 AI 어시스턴트는 대개 생산성 도구로 등록되어 있다. 이 분류에서는 설치 권한, 확장 관리, 자식 프로세스 감시 같은 항목이 애초에 적용되지 않는다. 순서는 분류 변경이 먼저다. 원격 관리 도구나 스크립트 실행 도구에 적용하던 심사 항목을 그대로 가져오면 되고, 새 기준을 만들 필요가 없다. 분류만 바꿔도 기존 통제가 자동으로 따라붙는다는 점이 이 조치의 장점이다.

소프트웨어 분류 변경에 따른 통제 적용 범위 차이 Deloitte One Cyber & Resilience

계정 침해가 곧 단말 침해가 되는 경로를 끊어야 한다. 전제 조건이 이메일 플랫폼 접근권이라는 점을 다시 볼 필요가 있다. 국내 조직 다수가 업무 메일과 AI 도구를 같은 SSO 에 물려 두었고, 그러면 계정 하나가 뚫렸을 때 도달 범위가 메일함에서 끝나지 않는다. 확인 순서는 이렇다. AI 도구가 어떤 인증 체계에 연결되어 있는지, 관리자 콘솔에서 설정 동기화를 끌 수 있는지, 확장·MCP 설치를 조직 정책으로 제한할 수 있는지. 세 가지 모두 제품 기능에 달린 문제라 도입 심사 단계에서 물어야 한다.

개발 조직이 먼저 쓰고 정책이 뒤따르는 순서가 위험을 키운다. 국내 기업의 AI 도구 도입은 부서 단위로 시작되고 전사 정책이 나중에 붙는 경우가 많다. 그 사이에 개발 조직이 로컬에서 코딩 에이전트를 쓰기 시작하면, 사내 저장소 자격증명과 클라우드 키가 에이전트의 접근 범위 안으로 들어간다. 이 상태는 금지 정책으로 되돌리기 어렵다. 허용 구성을 먼저 정해 주는 편이 실효가 크다. 최소한 세 가지다. 에이전트가 쓰는 자격증명은 개인 키가 아니라 용도별 단기 토큰으로 발급할 것, 자동 실행 가능한 명령의 범위를 저장소별로 명시할 것, 도구 호출 로그를 개발 환경 밖으로 내보내 보관할 것.

탐지 측면에서는 기존 룰을 재사용할 수 있다. 리서치가 권고하는 「비정상 자식 프로세스 탐지」는 새로 만들 항목이 아니다. LOLBin 대응에서 쓰는 부모-자식 프로세스 관계 기반 룰이 그대로 적용된다. AI 데스크톱 앱이 셸이나 스크립트 해석기를 자식으로 띄우는 패턴을 관측 대상에 추가하면 된다. 다만 개발자 단말에서는 이 패턴이 정상일 수 있으므로, 자산군을 나누어 기준선을 따로 잡아야 한다.

점검 항목

질문 1  AI 데스크톱 앱이 소프트웨어 대장에 어떤 분류로 등록되어 있는가?
        원격 관리 도구와 같은 심사 항목이 적용되는가?
질문 2  관리자 콘솔에서 설정 동기화와 확장 설치를 조직 정책으로 제어할 수 있는가?
질문 3  AI 도구가 업무 메일과 같은 인증 체계에 연결되어 있는가?
질문 4  AI 앱이 셸·스크립트 해석기를 자식 프로세스로 실행하는 이벤트가 수집되는가?
질문 5  개발 환경의 에이전트가 개인 키가 아닌 단기 토큰을 사용하는가?

출처 · Pentera, AI Double Agent: Claude Just Got a New Voice (2026-07-01, Dvir Avraham · Reef Spektor)