RMM 도구 악용 멀티스테이지 악성코드 캠페인: 원격관리 도구 통제 포인트

서론

원격 모니터링·관리(RMM) 도구는 기업 IT 운영에 꼭 필요한 소프트웨어다. 헬프데스크는 장애를 원격으로 확인하고, 인프라 운영팀은 서버와 단말 상태를 점검하며, MSP는 고객사의 시스템을 관리한다. 문제는 공격자도 같은 장점을 노린다는 점이다. 정상 도구이기 때문에 보안 장비의 의심을 덜 받고, 원격 세션을 만들면 별도 악성코드 없이도 키보드·화면·파일·명령 실행 권한을 확보할 수 있다.

최근 공개된 “RMM Tool Abuse: Analysis of a Multi-Stage Malware Campaign” 사례는 이 위험을 잘 보여준다. 공격자는 가짜 Adobe 업데이트 페이지로 사용자를 유인하고, ZIP 파일 안의 VBScript 드로퍼를 실행하게 한 뒤, MSI 패키지를 내려받아 ConnectWise ScreenConnect 설치로 이어지는 흐름을 구성했다. 랜딩 페이지는 방문자 정보를 Telegram 봇으로 전송했고, 데스크톱 사용자를 대상으로 자동 다운로드와 수동 다운로드 버튼을 함께 제공했다. 전형적인 “악성코드처럼 보이지 않는 악성 운영”이다.

AI로 피싱 문구, 랜딩 페이지, 스크립트 변형을 더 쉽게 만들 수 있는 환경에서는 이런 캠페인의 진입장벽이 더 낮아진다. 따라서 RMM 통제는 단순히 특정 제품을 차단하는 문제가 아니라, 조직이 허용한 원격관리 체계와 공격자가 몰래 들여오는 원격관리 체계를 구분하는 운영 보안 문제로 봐야 한다.

공격 흐름: 가짜 업데이트에서 원격 세션까지

이번 캠페인의 핵심 흐름은 네 단계로 정리할 수 있다.

1. 초기 유인
2. 공격자는 Adobe 업데이트처럼 보이는 웹페이지를 준비했다.
3. 페이지는 데스크톱·태블릿 사용자에게 ZIP 파일 다운로드를 유도하고, 모바일 사용자는 별도 초대 URL로 리다이렉션했다.

4. 페이지 내 JavaScript는 접속 유형, 시간, User-Agent, 다운로드 이벤트를 Telegram Bot API로 전송했다.

5. 스크립트 드로퍼 실행

6. ZIP 내부에는 Adobe.vbs 형태의 VBScript가 포함됐다.
7. 스크립트는 Shell.Application, Scripting.FileSystemObject, wscript.exe, runas 같은 문자열을 런타임에 조립해 정적 탐지를 어렵게 했다.

8. WinHttp.WinHttpRequest.5.1을 이용해 원격 MSI를 내려받고, SSL 인증서 오류를 무시하도록 옵션을 설정했다.

9. MSI 기반 2단계 페이로드

10. 다운로드된 MSI는 임시 폴더에 저장되는 구조였다.
11. 분석 결과 MSI 내부에는 ConnectWise ScreenConnect 설치 구성요소가 포함돼 있었다.

12. 설치 또는 실행이 성공하면 공격자는 합법 원격관리 도구를 통해 피해 단말에 접근할 수 있다.

13. 지속성·원격제어 확보

14. RMM 도구는 화면 캡처, 명령 실행, 파일 전송, 원격 제어 기능을 제공한다.
15. MITRE ATT&CK는 원격 접근 도구 악용을 T1219 Remote Access Tools로 분류하며, ConnectWise/ScreenConnect는 실제 위협그룹과 랜섬웨어 침해에서 반복적으로 관찰된 도구로 정리한다.
16. CISA도 AnyDesk, ScreenConnect 같은 정상 RMM 소프트웨어가 피싱 이후 백도어, 지속성, C2 채널로 악용될 수 있다고 경고한 바 있다.

이 흐름에서 눈여겨볼 점은 “새로운 악성코드”보다 “정상 도구를 배포하는 경로”가 더 중요하다는 것이다. 조직이 RMM 설치 파일, 휴대용 실행 파일, 원격 세션 연결을 제대로 구분하지 못하면 EDR이 프로세스를 봐도 운영 행위와 침해 행위를 분리하기 어렵다.

탐지 포인트: 파일명보다 행위와 맥락을 봐야 한다

RMM 악용 탐지는 특정 파일 해시만으로 끝나지 않는다. 캠페인별 해시는 금방 바뀌고, 공격자는 정식 설치 파일이나 휴대용 실행 파일을 그대로 쓸 수 있다. 탐지 기준은 “누가, 어디서, 어떤 경로로, 어떤 원격관리 세션을 열었는가”에 맞춰야 한다.

1. 스크립트 실행 징후

우선 wscript.exe, cscript.exe, mshta.exe, powershell.exe가 사용자 다운로드 폴더나 임시 폴더의 ZIP 해제 경로에서 실행되는지 봐야 한다. 특히 다음 조합은 우선순위를 높여 조사한다.

• 브라우저 다운로드 직후 wscript.exe 또는 cscript.exe 실행
• VBS/JS 스크립트가 WinHttp.WinHttpRequest, ADODB.Stream, ShellExecute, runas를 호출
• 스크립트 실행 후 %TEMP% 경로에 MSI/EXE 저장
• msiexec.exe /i ... /qn 같은 조용한 설치 옵션 사용
• 사용자가 직접 설치할 이유가 없는 시간대 또는 부서에서 원격관리 도구 설치 발생

Windows 이벤트 관점에서는 프로세스 생성 로그, PowerShell 로그, 스크립트 블록 로그, Sysmon Event ID 1·7·11·22, EDR 프로세스 트리 데이터를 함께 봐야 한다. “브라우저 → ZIP 해제 → VBS → WinHTTP 다운로드 → msiexec → RMM 프로세스”로 이어지는 부모-자식 관계가 보이면 단일 이벤트보다 훨씬 강한 신호다.

2. MSI 설치와 서비스 생성

RMM 도구는 설치 과정에서 서비스, 예약 작업, 자동 시작 항목을 만들 수 있다. 정상 운영 도구도 같은 행위를 하므로, 설치 주체와 배포 경로를 기준으로 판단해야 한다.

• 설치 주체가 소프트웨어 배포 시스템이 아닌 일반 사용자 계정인지
• MSI 원본 경로가 내부 패키지 저장소가 아닌 %TEMP%, Downloads, 브라우저 캐시인지
• 설치 직후 외부 RMM 서버로 지속 연결이 시작되는지
• 새 서비스 이름, 설치 경로, 서명자, 제품명이 승인 목록과 일치하는지
• 설치된 RMM 인스턴스가 조직의 테넌트·서버·사이트 ID에 묶여 있는지

운영팀은 “ConnectWise가 있으면 정상”처럼 제품명만으로 판단하면 안 된다. 같은 제품이라도 조직 소유 테넌트에 등록된 인스턴스인지, 공격자가 운영하는 서버에 연결되는 인스턴스인지가 본질적인 차이다.

3. 네트워크와 DNS 연결

RMM 악용은 외부 제어 서버와의 연결이 필요하다. 따라서 네트워크 관측에서는 다음을 확인한다.

• 승인되지 않은 RMM 도메인, 신규 등록 도메인, 동적 DNS, VPS 대역과의 연결
• screenconnect, anydesk, atera, splashtop, teamviewer, rustdesk, simplehelp, meshcentral 등 제품군 관련 도메인·프로세스의 비인가 사용
• 평소 RMM 사용이 없는 사용자 단말에서 장시간 외부 세션 유지
• 업무시간 외 원격제어 세션과 대량 파일 전송
• SSL 인증서 오류 무시, 비정상 User-Agent, Telegram Bot API 통신 같은 부가 신호

네트워크 차단은 무조건적인 제품 차단보다 “허용된 RMM 서버만 통신”하는 방식이 현실적이다. 헬프데스크와 MSP 운영에 필요한 예외를 명확히 정의하고, 그 외의 RMM 연결은 탐지 또는 차단 대상으로 둬야 한다.

통제 포인트: 승인된 원격관리만 남긴다

RMM 통제의 목표는 업무를 막는 것이 아니라, 업무에 필요한 원격관리 경로만 남기는 것이다. 이를 위해 네 가지 축으로 관리해야 한다.

1. 자산·도구 인벤토리

먼저 조직에서 허용한 RMM 도구 목록을 만든다. 제품명만 적는 수준으로는 부족하다. 최소한 다음 정보를 포함해야 한다.

• 제품명과 실행 파일명
• 설치 경로와 서비스명
• 서명자와 인증서 정보
• 관리 서버·클라우드 테넌트·사이트 ID
• 사용 부서와 담당자
• 사용 가능한 계정 그룹
• 접속 가능 네트워크와 시간대
• 로그 보존 위치와 보존 기간

이 인벤토리가 없으면 보안팀은 비인가 RMM을 봐도 정상 운영 예외인지 침해인지 판단할 수 없다. 특히 MSP가 고객사에 설치한 도구는 고객사 보안팀이 식별할 수 있도록 별도 목록으로 관리해야 한다.

2. 허용목록과 실행 제어

RMM은 설치 파일만 막아서는 부족하다. CISA가 지적한 것처럼 휴대용 실행 파일은 관리자 권한이나 정식 설치 없이도 실행될 수 있다. 따라서 설치 제어와 실행 제어를 분리해 적용해야 한다.

• Windows Defender Application Control, AppLocker, EDR 애플리케이션 제어로 승인된 RMM 실행 파일만 허용
• %TEMP%, Downloads, 사용자 프로필 하위 경로에서 RMM·MSI·스크립트 실행 제한
• 서명된 파일이라도 승인된 해시·경로·서명자·테넌트 조건을 모두 만족할 때만 허용
• msiexec.exe의 조용한 설치 옵션과 사용자 쓰기 가능 경로 실행을 모니터링
• 브라우저가 내려받은 ZIP 내부 스크립트 실행 차단 또는 격리

운영 현실상 모든 단말에 즉시 강제 차단을 적용하기 어렵다면, 우선 “탐지 모드”로 시작해 2~4주간 정상 사용 패턴을 수집한 뒤 차단 정책으로 전환하는 방식이 안전하다.

3. 권한과 세션 통제

RMM 도구는 접속 순간부터 강력한 권한을 제공한다. 따라서 계정 통제는 설치 통제만큼 중요하다.

• RMM 관리자 계정에 MFA 의무화
• 공유 계정 금지, 개인별 계정과 역할 기반 권한 적용
• 세션 승인, 세션 녹화, 파일 전송 제한, 클립보드 제한 설정
• 외부 협력사 계정은 기간 제한과 승인 워크플로우 적용
• 사용하지 않는 에이전트와 사이트 제거
• 관리자 콘솔 접속 IP 제한 또는 VPN/VDI 경유 강제

특히 MSP나 외주 운영사가 RMM 콘솔을 사용하는 경우, 고객사 단말 접근 권한이 과도하게 열려 있지 않은지 정기적으로 확인해야 한다. 공급망 신뢰관계는 공격자에게도 매력적인 통로다.

4. 로그와 복원력 점검

RMM 악용은 침해 이후 복구와도 연결된다. 공격자가 RMM으로 백업 서버나 파일 서버에 접근하면 랜섬웨어 배포, 백업 삭제, 데이터 유출로 이어질 수 있다. 따라서 로그와 복구 체계를 함께 점검해야 한다.

• RMM 콘솔 로그인, 세션 시작·종료, 파일 전송, 명령 실행 로그 보존
• EDR에서 RMM 프로세스의 자식 프로세스 생성 이벤트 수집
• SIEM에서 비인가 RMM 설치·실행·외부 통신 상관분석 룰 구성
• 백업 서버와 관리 서버에 대한 RMM 접근 제한
• 침해 시 RMM 에이전트 일괄 비활성화 절차 마련
• 백업 복구 테스트와 관리자 계정 재발급 절차 점검

AI 기반 공격 자동화가 확산되면 랜딩 페이지와 드로퍼 변형은 더 빠르게 바뀔 수 있다. 결국 조직의 생존력은 “처음부터 완벽히 막았는가”만이 아니라 “비인가 원격관리 채널을 얼마나 빨리 찾아 끊고, 피해 시스템을 얼마나 빨리 복구하는가”에 달려 있다.

EDR·SIEM 체크리스트

다음 항목은 보안팀이 즉시 점검할 수 있는 실무 체크리스트다.

EDR 정책

• 승인된 RMM 제품과 승인되지 않은 RMM 제품을 별도 탐지 그룹으로 분리했는가
• wscript.exe, cscript.exe, mshta.exe가 인터넷에서 내려받은 파일을 실행할 때 경보가 발생하는가
• msiexec.exe가 사용자 쓰기 가능 경로의 MSI를 조용히 설치할 때 탐지하는가
• RMM 프로세스가 cmd.exe, powershell.exe, rundll32.exe, reg.exe, net.exe를 자식 프로세스로 실행할 때 경보가 발생하는가
• RMM 도구의 휴대용 실행 파일 사용을 탐지하는가
• Telegram Bot API, 동적 DNS, 신규 등록 도메인 통신을 RMM 설치 흐름과 상관분석하는가

SIEM/로그

• RMM 설치, 서비스 생성, 자동 시작 등록 이벤트가 중앙 로그로 수집되는가
• RMM 콘솔 로그와 엔드포인트 로그를 사용자·호스트 기준으로 연결할 수 있는가
• 헬프데스크 업무시간 외 원격 세션을 별도로 모니터링하는가
• 비인가 부서 또는 일반 사용자 단말에서 RMM 사용이 발생하면 알림이 가는가
• MSP 계정의 대량 접속, 다수 고객사 동시 접속, 실패 로그인 증가를 탐지하는가

네트워크

• 허용된 RMM 서버·테넌트 이외의 외부 연결을 차단 또는 경보 처리하는가
• RMM 제품별 기본 도메인과 포트를 허용목록으로 관리하는가
• 단말에서 직접 외부 RMM 서버로 나가는 우회 경로가 없는가
• 프록시·DNS 로그에서 신규 RMM 관련 도메인을 추적하는가

운영 절차

• 신규 RMM 도입 시 보안 검토와 로그 연동이 필수 절차인가
• 예외 승인에는 만료일과 담당자가 있는가
• 침해 대응 플레이북에 RMM 세션 종료, 에이전트 제거, 토큰·계정 폐기 절차가 포함돼 있는가
• 백업·복구 시스템은 RMM 일반 관리자 권한으로 접근할 수 없도록 분리돼 있는가

대응 우선순위

RMM 악용 대응은 등급표보다 실행 순서가 중요하다. 운영 중단을 최소화하려면 “이미 열려 있는 원격관리 채널을 끊는 일”과 “정상 운영 예외를 확인하는 일”을 분리해 진행해야 한다.

결론

RMM 도구 악용은 “정상 소프트웨어를 악성 목적으로 쓰는” 대표적인 생활형 공격 기법이다. 공격자는 가짜 업데이트, 스크립트 드로퍼, MSI 설치, Telegram 알림, ScreenConnect 배포를 조합해 피해 단말에 원격관리 채널을 만들었다. 이 과정에서 완전히 새로운 취약점이나 고급 악성코드가 필요했던 것은 아니다.

따라서 방어의 핵심은 제품명이 아니라 통제 상태다. 조직이 승인한 RMM은 인벤토리, 계정, 네트워크, 로그, 세션 정책으로 관리해야 한다. 승인되지 않은 RMM은 설치 여부와 관계없이 실행·통신·세션 생성 단계에서 탐지해야 한다. 그리고 침해가 발생했을 때는 원격관리 채널을 끊고, 계정을 폐기하고, 백업에서 복구할 수 있는 절차까지 준비해야 한다.

AI가 공격 준비 시간을 줄이는 시대에는 이런 기본 통제가 더 중요해진다. 복원력은 백업만의 문제가 아니다. 공격자가 만들어 둔 원격 접근 통로를 빠르게 발견하고 제거할 수 있는 운영 능력까지 포함한다.

현장 확인용 IOC와 검증 범위

원문 분석에서 확인된 지표는 단기 차단과 헌팅의 출발점으로 활용하되, 장기 탐지는 행위 기반 규칙과 결합해야 한다. 특히 이번 건은 원문 본문과 원문 IOC 섹션의 도메인 표기가 서로 다르므로, 공개 본문에서는 출처에 나온 표기를 구분해 적고 현장 검색 시 단수·복수형을 모두 확인하는 방식으로 정리한다.

검증 시에는 세 가지를 함께 본다. 첫째, 사용자가 다운로드한 ZIP 또는 스크립트가 %TEMP%에 MSI를 쓰고 msiexec.exe로 이어졌는지 확인한다. 둘째, 설치된 ScreenConnect 인스턴스가 조직 소유 테넌트와 사이트 ID에 속하는지 확인한다. 셋째, 설치 직후 외부 원격관리 서버, Telegram Bot API, 동적 DNS 또는 신규 등록 도메인으로 통신이 이어졌는지 프록시·DNS·EDR 타임라인을 대조한다. 단수형 account.paperless.myserver2.org와 복수형 accounts.paperless.myserver2.org는 원문에서 서로 다른 위치에 등장하므로 둘 중 하나만 IOC로 단정하지 말고 모두 검색 범위에 넣어야 한다.

참고자료

• Shaquib Izhar, “RMM Tool Abuse: Analysis of a Multi-Stage Malware Campaign”, Medium, 2026-07-02, https://shaquibizhar.medium.com/rmm-tool-abuse-analysis-of-a-multi-stage-malware-campaign-60822dfb3b7d
• CISA, NSA, MS-ISAC, “Protecting Against Malicious Use of Remote Monitoring and Management Software”, AA23-025A, https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-025a
• MITRE ATT&CK, “T1219 Remote Access Tools”, https://attack.mitre.org/techniques/T1219/
• MITRE ATT&CK, “S0591 ConnectWise”
• 디지털데일리, “아마추어도 AI로 해킹하는 시대…생존 해법은 복원력”, 2026-07-02

본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.