2025년 제43회 사이버헬퍼 보안 리포트 AI-Based Supply Chain Credential Compromise (SCCC)

 

 

서론
기업 보안에서 가장 취약한 연결고리는 언제나 “제3자(서드파티)”다.
하지만 2025년 이후의 공격은 단순한 파트너 사 계정 탈취 수준이 아니다.
AI가 공급망 전체의 인증 구조를 분석하고
권한·흐름·토폴로지를 학습해
가장 취약한 계정을 선택적으로 침투하는
AI 기반 공급망 자격증명 침해(SCCC)가 등장했다.

이 공격은 SSO, OAuth, API Key, JWT, SSH Key 등
모든 인증 체계를 표적화할 수 있으며
공격자가 아닌 협력사 명의로 침해가 발생하는 것처럼 보이기 때문에
탐지와 귀책 판정 모두가 사실상 불가능에 가깝다.

1. 왜 SCCC가 공급망 공격의 정점인가

1. 서드파티는 “너무 많은 권한”을 가진다
   예시:

• 유지보수 업체가 DB read 권한 보유

• SI 업체가 개발 환경 Git 접근

• 콜센터가 CRM 고객 정보 접근

• 클라우드 MSP가 IAM 관리자 권한 보유

기업은 내부 직원보다
서드파티에게 더 넓은 권한을 주는 경우가 흔하다.

1. 인증 체계가 복잡해짐
   2025년 기준 대부분 기업은
   아래 인증 구조가 혼재된 상태로 운영된다.

• SSO + OAuth + API Key

• JWT 기반 마이크로서비스 인증

• SaaS 연동용 Service Account

• 협력사 VPN 사용자 계정

이 복잡성은 공격자에게 “공격 설계의 자유도”를 준다.

1. AI가 공급망 그래프 전체를 인식
   AI는 다음 데이터를 바탕으로
   공급망 전부를 하나의 네트워크처럼 분석한다.

• API 호출 경로

• Service Account 권한

• SaaS 연동 흐름

• 이메일 도메인 관계

• 워크스페이스 공유 권한 구조

• 서버 간 Credential Handoff Sequence

이제 공격자는 단일 벡터가 아니라
“최적의 침투 경로”를 계산해 들어온다.

1. 공격 시나리오 (7단계)

Step 1. Credential Surface Harvesting
공급망 전체에 존재하는 인증 기반을 수집한다.

예:

• 협력사 VPN 계정

• 클라우드 IAM 서브 계정

• Slack / Jira / Notion 게스트 계정

• CI/CD Token

• Third-Party SaaS API Key

이 과정은 소음 없이 진행된다.

Step 2. Trust Relationship Graphing
AI가 “어떤 계정이 어떤 시스템에 언제 접근하는가”를
그래프 구조로 모델링한다.

예:
회계사무소 API 계정 → 월말 ERP 접근
MSP IAM 계정 → 클라우드 리소스 생성
물류 파트너 사 계정 → 출고 시스템 읽기

Step 3. Low-Noise Credential Acquisition
공격자는 최약체 계정만 노린다.

• 재사용 비밀번호

• 만료되지 않은 API Key

• 삭제되지 않은 협력사 계정

• 오래된 SSH 키

• 비활성화된 서비스 계정

이 계정들은 대부분 “감시 대상이 아님”.

Step 4. Role-Imitating Access
AI는 계정 본래의 행동 패턴을 그대로 재현한다.

예:
물류업체 계정이면
출고 데이터 조회 후 동일한 순서로 페이지 이동.
보안 솔루션은 이를 “정상 트래픽"으로 본다.

Step 5. Shadow Privilege Escalation
표면적으로는 기존 권한만 사용하는 것처럼 보이지만
내부적으론 시스템 간 Credential 교환 구조를 활용하여
권한이 서서히 상승한다.

예:
VPN → SaaS → 내부 API → DB

이동 과정이 자연스러워 탐지되지 않는다.

Step 6. Supply Chain Data Injection
공격자는 전체 기업이 아닌
“협력사 데이터”를 변조해 침해를 유발한다.

예:

• 물류사 출고 데이터 0.5% 변조

• 회계사무소 전달 데이터에 금액 필드 조작

• MSP 구성 파일 일부 변경

직접 공격이 아니라
협력사를 통한 공격이므로 귀책이 복잡해진다.

Step 7. Attribution Misleading
마지막으로 AI는 공격의 모든 흔적을
“협력사 내부 문제”처럼 위장한다.

결과적으로:
기업은 피해를 입고
협력사는 누명을 쓰며
공격자는 노출되지 않는다.

1. 실제 위협이 되는 SCCC 시나리오

사례 A — MSP를 통한 클라우드 IAM 침해
MSP가 가진 IAM Sub-admin 계정이 탈취되어
리소스 생성 → 권한 부여 → 로그 삭제까지 수행.
클라우드 벤더는 “정상 API 호출”로 판단.

사례 B — 회계사무소 API 계정 악용
월말 결산용 ERP API 계정을 이용해
매출 데이터 일부 변조.
3개월간 아무도 눈치 못 챔.

사례 C — 협력사 Git 계정 탈취
3rd-party 개발 계정을 사용해
레포지토리 일부 코드에 백도어 삽입.
CI/CD 로그는 전부 정상.

사례 D — SaaS 게스트 계정 활용
Notion / Confluence 게스트 계정이
Workspace Metadata를 수집하여
전체 조직 구조와 권한을 파악하는 데 사용됨.

1. 기존 보안 체계가 실패하는 이유

1. 공급망 계정은 “감시 사각지대“
   보안팀은 내부 계정만 주로 모니터링한다.

2. AI가 협력사 사용 패턴까지 복제
   이상행위 탐지가 무력화된다.

3. Credential Reuse & Overprivilege
   협력사는 최소 권한 원칙을 잘 지키지 않는다.

4. SaaS 기반 인증 구조는
   서버에서 이벤트를 제대로 통제할 수 없다.

1. 대응 전략 (전문가용)

1. Supply Chain Identity Mesh 구축
   기업-협력사 간 인증 경로를 단일 Mesh로 통합.

2. Cross-Tenant Behavior Baseline
   협력사 계정의 행동 패턴을
   기업 기준이 아닌 “상대 조직 기준”으로 비교.

3. Credential Time-Bucket Rotation
   협력사 계정의 모든 Credential을
   일정 주기별로 자동 폐기·재발급.

4. Trust Path Visualization
   협력사가 어떤 시스템에 어떻게 접근하는지
   Real-time Trust Graph 제공.

5. Supply Chain Drift Detection
   협력사 권한 사용량 변화 추적.
   0.1%라도 이상하면 경고.

결론
SCCC는 단순한 공급망 공격이 아니다.
협력사라는 “정상 채널”을 이용해
전체 기업을 간접 지배하는 공격이다.

2025년 이후 기업 보안의 핵심은
내부 직원이 아닌 “외부 계정”을
어떻게 통제하느냐에 달려 있다.

사이버헬퍼는
공급망 계정 위협에 특화된
다차원 인증 분석 엔진을 기반으로
SCCC 대응 체계를 구축하고 있다.