◎ 개요

  • Persistence는 단순히 “재부팅 후 살아남는 기법”만을 뜻하지 않습니다.
  • 공격자가 시스템, 계정, 클라우드 권한, SaaS 연결 고리를 통해 장기적으로 재접속 가능 상태를 유지하는 모든 행위가 포함됩니다.
  • 그래서 윈도우 레지스트리나 예약 작업만 보는 것이 아니라, 클라우드 IAM과 OAuth 기반 지속성까지 함께 봐야 최신 환경을 제대로 설명할 수 있습니다.

 

◎ Registry Run Keys

  • Registry Run Keys는 Windows 부팅이나 사용자 로그인 시 자동 실행을 유도하는 대표적인 Persistence 방식입니다.
    공격자는 Run, RunOnce, Services 관련 레지스트리 위치에 악성 실행 경로를 넣어 시스템 시작과 함께 코드가 실행되도록 만들 수 있습니다.
  • 이 방식은 사용자가 로그온할 때 자연스럽게 실행되기 때문에 눈에 잘 띄지 않는 편입니다.
  • 실무에서는 레지스트리 키 자체보다 “누가 언제 어떤 경로를 등록했는지”가 중요합니다.
  • 정상 프로그램의 설치 과정인지, PowerShell이나 스크립트를 통한 조작인지, 비정상 사용자 프로필 경로인지 확인하셔야 합니다.
  • 특히 실행 파일 경로가 Temp, AppData, Public 같은 위치를 가리키면 더 주의 깊게 보셔야 합니다.

 

◎ Scheduled Tasks

  • Scheduled Tasks는 가장 흔하게 악용되는 Persistence 중 하나입니다.
  • 공격자는 Windows 작업 스케줄러를 사용해 특정 시간마다 악성 스크립트나 바이너리를 실행하거나, 로그인 시 자동 실행되도록 구성할 수 있습니다.
  • 관리 작업처럼 보이기 때문에 탐지 초기에 정상 행위로 오인되기 쉽습니다.
  • 탐지 관점에서는 schtasks.exe, PowerShell, WMI, 작업 생성 이벤트가 중요합니다.
  • 작업 이름이 정상 관리 작업처럼 보이더라도 실행 경로, 인자, 작성 주체, 생성 시점을 함께 봐야 합니다.
  • 또한 특정 작업이 시스템 서비스 계정이나 숨은 스크립트 실행과 연결되면 Persistence 가능성을 높게 봐야 합니다.

 

◎ Cloud IAM Persistence

 - 최근의 Persistence는 클라우드에서도 매우 중요합니다.

  • 공격자는 단말보다 계정과 권한을 오래 유지하는 쪽에 집중하며, IAM 사용자, 역할, 정책, 액세스 키, 연동 앱을 통해 지속성을 확보하려고 합니다.
  • 즉, 클라우드에서는 파일보다 권한 구조가 Persistence의 핵심 대상이 됩니다.

 - 예를 들면

  • 공격자가 새 액세스 키를 만들거나, 권한이 과도한 정책을 붙이거나, 역할 신뢰 관계를 조작하거나, 오래 남는 서비스 계정을 확보하는 방식이 가능합니다.
  • 이러한 행위는 전통적인 호스트 기반 Persistence보다 더 오래 숨을 수 있고, 계정 하나만으로 여러 서비스에 영향을 줄 수 있다는 점에서 위험합니다.
  • 따라서 클라우드 Persistence는 IAM 변경 이력과 인증 로그를 함께 봐야 합니다.

 

 

◎ SaaS와 OAuth 기반 사례

  • SaaS 환경에서는 OAuth 기반 지속성이 매우 현실적인 위협입니다.
  • 공격자는 사용자를 속여 악성 앱에 동의하게 만들거나, 이미 획득한 토큰과 세션을 재사용해 장기적인 접근을 유지할 수 있습니다.
  • 이 방식은 비밀번호를 다시 훔치지 않아도 되기 때문에 방어자가 놓치기 쉽습니다.
  • 특히 클라우드·IDaaS 환경에서는 사용자가 앱 권한을 승인하는 순간, 공격자가 메일, 파일, 일정, 저장소에 지속 접근할 수 있습니다.
  • 즉, OAuth Persistence는 “계정 탈취”보다 “권한 위임의 남용”에 가깝다고 보시면 이해가 쉽습니다.
  • 이 때문에 SaaS 보안에서는 토큰 수명, 앱 동의 내역, 비정상 권한 변경을 주기적으로 검토해야 합니다.

 

◎ 실무 탐지 포인트

  • Persistence 탐지에서는 하나의 이벤트보다 설정 변경의 흐름을 보셔야 합니다.
  • 레지스트리 키 추가, 예약 작업 생성, 서비스 등록, IAM 정책 변경, OAuth 앱 동의가 각각 단독으로는 정상일 수 있지만, 공격자의 연쇄 행동으로 이어지면 의미가 달라집니다.
  • 따라서 “누가 변경했는가”, “어디에 지속성을 심었는가”, “그 변경 뒤 어떤 후속 행위가 발생했는가”를 같이 보셔야 합니다.
  • 윈도우 환경에서는 Autoruns, 작업 스케줄러 이벤트, 레지스트리 감사가 중요하고, 클라우드에서는 감사 로그와 IdP 로그가 중요합니다.
  • 또한 Persistence는 감염 직후보다 며칠 뒤, 혹은 재부팅 이후에 드러나는 경우가 많으므로 시간축 분석이 중요합니다.
  • 그래서 탐지 룰도 “즉시 악성”만 찾지 말고 “장기적 재접속 가능성”을 만드는 변경을 잡는 방향이 좋습니다.

 

◎ 방어 관점

  • 방어에서는 Persistence를 막는 것보다, Persistence를 만들기 어렵게 하고 남기기 어렵게 만드는 것이 핵심입니다.
  • 권한 최소화, 계정 수명 관리, 앱 동의 제한, 예약 작업과 시작 항목 통제, IAM 변경 승인 절차가 기본이 됩니다.
  • 클라우드와 SaaS에서는 특히 오래 남는 토큰, 과도한 권한, 외부 앱 동의가 지속성의 출발점이 될 수 있으므로 정책 관리가 중요합니다.
  • 실전적으로는 “정상 유지관리”와 “공격자의 지속성”을 구분할 수 있는 기준선을 만드는 것이 좋습니다.
  • 평소 허용되는 레지스트리 경로, 예약 작업 작성 주체, IAM 관리자 권한 변경 패턴, OAuth 앱 승인 패턴을 정의해 두시면 탐지 정확도가 올라갑니다.
  • 결국 Persistence는 기술이 아니라 운영 습관의 차이에서 발견되는 경우가 많습니다.

 

◎ 정리

  • Persistence는 공격자가 재부팅이나 세션 만료 이후에도 다시 돌아올 수 있도록 발판을 유지하는 전술입니다.
  • Windows에서는 Registry Run Keys와 Scheduled Tasks가 대표적이고, 최신 환경에서는 Cloud IAM과 SaaS/OAuth 기반 지속성이 점점 더 중요해지고 있습니다.
  • 따라서 Persistence 방어는 호스트, 계정, 클라우드 권한을 함께 보는 관점에서 설계하셔야 합니다.

 

 

 

반응형

+ Recent posts