MDSec 레드팀이 ServiceNow 테넌트에서 24개 역할으로 관리자 권한까지 상승한 방법과, 예약 작업 기능을 재활용한 파일리스 C2 구조를 분석한다.
레드팀 MDSec이 2026년 8월 공개한 보고서 하나가 SaaS 보안의 불편한 진실을 드러냈다. ServiceNow 테넌트 하나를 침해한 뒤, 연구진은 최소 24개의 서로 다른 역할(role)에서 관리자 권한까지 올라갈 수 있는 경로를 찾아냈다. 흥미로운 건 방법이다. 이 권한상승 단계에는 새로운 취약점이 하나도 없었다 — ServiceNow가 원래 제공하는 기능(User Criteria, 예약 작업, 워크플로우 스튜디오)을 설계된 대로 사용했을 뿐이다.
기업들은 온프레미스 시스템의 권한 관리에는 익숙하다. Active Directory 그룹 정책, 서버 접근 통제, 방화벽 규칙까지 보안팀이 직접 감사하고 SIEM에 로그를 흘려보낸다. 문제는 ServiceNow 같은 SaaS 플랫폼으로 넘어오는 순간 이 감각이 통하지 않는다는 데 있다.
ServiceNow는 IT 서비스 관리(ITSM), HR 케이스 관리, CMDB(구성관리데이터베이스)까지 한 플랫폼에서 처리하는 종합 SaaS다. 국내에서도 대기업·공공기관 상당수가 IT 헬프데스크와 자산관리 도구로 이 플랫폼을 쓴다. 그런데 이 안의 역할·스크립트·워크플로우 체계는 자체 완결된 세계라서, 외부 보안 도구로는 내부에서 무슨 일이 벌어지는지 보기 어렵다. MDSec의 실험은 바로 이 "안 보이는 내부"를 공격자가 어떻게 이용할 수 있는지 보여준다.
ServiceNow의 접근 통제는 크게 세 층으로 이뤄진다.
역할(Role): 사용자에게 부여되는 권한 묶음. catalog_admin(카탈로그 관리자), import_admin(데이터 가져오기 관리자), sn_cmdb_editor(CMDB 편집자)처럼 업무 단위로 세분화돼 있다.
ACL(Access Control List): 어떤 역할이 어떤 테이블·필드에 접근할 수 있는지 정의하는 규칙.
비즈니스 로직(Business Rule, Scheduled Job, Glide Script): 특정 이벤트(레코드 생성, 시간 경과 등)가 발생하면 자동 실행되는 서버사이드 스크립트. ServiceNow의 스크립팅 언어는 자바스크립트 기반 "Glide" API를 쓴다.
문제는 이 세 층이 서로 독립적이지 않다는 점이다. 특정 역할이 특정 기능(예: User Criteria 생성)에 접근할 수 있고, 그 기능 안에서 임의의 Glide 스크립트를 실행할 수 있다면, 원래 그 역할에는 없던 권한까지 스크립트를 통해 우회로 얻을 수 있다. MDSec은 이 우회로가 하나가 아니라 최소 24개 존재한다고 밝혔다.
MDSec은 초기 침투 자체는 "쉬운 단계"였다고 말한다. 실제 인게이지먼트에서는 2주짜리 피싱 캠페인으로 특정 임직원 단말에 임플란트를 심고, 사용자가 ServiceNow에 로그인하는 순간 세션 쿠키를 탈취해 그 세션에 올라탔다. 여기에 더해 파일 공유 서버를 뒤지다 노출된 config.xml 파일 하나가 결정적이었는데, 이 안에 import_admin 권한을 가진 계정의 MID 서버(ServiceNow와 내부망을 연결하는 중계 서버) 자격증명이 그대로 들어 있었다. 보고서는 이와 별개로 인증 없이 Glide 스크립트를 실행할 수 있게 해주는 "매우 심각한 제로데이 2건"도 초기 침투 경로로 언급한다 — 다만 진짜 어려운 구간은 초기 침투가 아니라 그다음 권한상승이었다고 MDSec은 강조한다.
"MDSec identified at least 24 roles that could be abused to achieve privilege escalation within a ServiceNow instance." — MDSec, "When It Snows, It Pours: Anatomy of a ServiceNow Red Team"
가장 명확하게 문서화된 경로는 catalog_admin 역할에서 시작한다.
catalog_admin은 user_criteria_admin 권한을 상속받는다.action_designer 역할을 부여한다.action_designer는 워크플로우 스튜디오에서 스크립트를 실행할 수 있는 권한이다. 이 스튜디오 안에서 다시 스크립트를 돌려, 최종적으로 admin 역할까지 자가 부여한다.세 문단으로 요약했지만 핵심은 하나다. 각 단계는 개별적으로는 "정상 기능 사용"이라 ACL 위반으로 잡히지 않는다.
다른 경로도 구조가 비슷하다. import_admin(MID 서비스 계정) 경로는 REST API로 악성 스크립트가 담긴 변환(transform) 규칙을 만들어 web_service_access_only 제한을 끄고 대화형 로그인으로 전환한 뒤 같은 방식으로 admin까지 올라간다. sn_cmdb_editor 경로는 CMDB360 워크스페이스의 서비스 매핑 쿼리 기능을 거쳐 business_rule_admin을 획득한다.
권한을 얻은 다음 MDSec 연구진은 "SnowFall"이라는 자체 제작 C2 프레임워크로 지속성을 구현했다. 핵심은 ServiceNow의 예약 작업(Scheduled Job, 내부적으로 sysauto_script 테이블에 저장된다) 기능이다. "AppStoreMonitor"처럼 눈에 띄지 않는 이름으로 예약 작업을 등록하면, 이 작업이 10분 주기로 자동 실행되면서 sn_ws.RESTMessageV2 API를 통해 외부 서버에 HTTP 요청을 보내고 명령을 받아온다. 별도의 악성 실행 파일이 시스템에 남지 않는 파일리스(fileless) 구조다.
여기에 더해 MID 서버(ServiceNow와 내부망 사이를 중계하는 에이전트)까지 침해하면, snc-automation-api.jar의 CredentialsProviderFactory 클래스를 이용해 ServiceNow가 암호화 보관 중인 각종 자격증명을 복호화할 수 있다. ECC 큐(ecc_queue 테이블)를 통해 명령을 주고받는 이 경로는 사실상 내부망 진입 통로 역할을 한다.
MDSec은 흔적을 남기지 않기 위해 계정·역할 변경 시점에 gr.setValue('sys_created_by', 'system')처럼 생성자 필드를 system으로 위조하고, GlideDateTime으로 타임스탬프를 과거로 조작해 마치 원래 시스템이 만든 레코드처럼 보이게 했다. 여기에 sys_user_login_history, sys_user_role_history, sys_flow_log, sys_script_execution_history, syslog_transaction 같은 로그 테이블의 관련 레코드를 삭제하는 정리 루틴까지 더했다.
이 실험이 무서운 지점은 24개 권한상승 경로에 "새로운 취약점"이 하나도 없었다는 사실이다. 전부 ServiceNow가 문서화한 정식 기능이다. 즉 패치로 막을 수 있는 문제가 아니라, 역할 간 상속 관계와 스크립트 실행 권한을 설계 단계에서 다시 들여다봐야 하는 구조적 문제다. (초기 침투에 쓰인 제로데이 2건은 벤더 패치로 해결 가능한 별개 문제다.)
탐지 관점에서 봐야 할 지점은 명확하다. 첫째, 특정 역할이 원래 갖지 않던 권한을 부여받는 이벤트(sys_user_role_history 테이블 변경)는 그 자체로 이상 신호다. 특히 낮은 권한 역할이 짧은 시간 안에 연쇄적으로 다른 역할을 획득하는 패턴은 정상 업무 흐름에서는 드물다. 둘째, sysauto_script에 새로 등록된 예약 작업 중 외부 도메인으로 HTTP 요청을 보내는 것이 있는지는 정기적으로 감사할 대상이다. 셋째, 계정 생성·역할 변경 레코드의 sys_created_by가 system인데 실제로는 관리 콘솔에서 수동 생성된 정황이 있다면 시간 위조를 의심할 근거가 된다.
MDSec은 이 보고서에서 "ServiceNow 내 탐지·대응 역량은 극도로 미성숙한 상태"라고 평가했고, 실제 인시던트 대응 현장에서 이런 지속성 메커니즘을 발견하지 못한 사례가 있었다고 언급했다. SIEM에 온프레미스 로그는 잘 모으면서 SaaS 플랫폼 내부 감사 로그는 놓치고 있는 조직이 많다는 뜻이다.
ServiceNow를 도입한 조직이라면, 방화벽·EDR 로그만큼이나 역할 변경·예약 작업 생성 이벤트도 SIEM으로 끌어오는 게 우선순위가 돼야 한다.
AI 활용 안내 이 글은 AI(Claude)의 도움을 받아 작성되었습니다. 인용된 통계와 사례는 참고 자료에 명시된 출처에 근거하며, 설명을 위한 일부 표현은 각색되었습니다.
면책 조항 본 글은 보안 인식 제고를 위한 교육 목적으로 작성되었습니다. 언급된 공격 기법을 실제로 시도하는 행위는 「정보통신망법」, 「형법」 등에 따라 처벌받을 수 있으며, 본 블로그는 이에 대한 법적 책임을 지지 않습니다.