가짜 Teams 지원 요청 한 번이 도메인 관리자까지 노린다

Microsoft는 2026년 9월 2일 외부 Microsoft Teams 테넌트의 공격자가 사내 IT 지원 담당자를 사칭해 직원에게 원격 제어를 허용하게 만든 침입 캠페인을 공개했다. Microsoft 위협 인텔리전스 분석 에는 원격 세션에서 악성 MSI를 설치하고 휴대용 Node.js로 JavaScript 임플란트를 실행한 뒤, Active Directory를 조사하고 WinRM으로 도메인 컨트롤러와 인증 기관에 접근한 과정이 담겼다.

9월 4일 공개된 Clubic의 후속 보도 도 Teams 지원 사칭에서 원격 제어, Node.js 임플란트와 내부 인증 서버 접근으로 이어진 같은 분석을 전했다. 확인된 범위는 도메인 핵심 시스템을 향한 정찰과 원격 연결까지이며, 도메인 관리자 계정 탈취나 랜섬웨어 배포, 데이터 유출이 완료됐다는 공개 증거는 없다.

외부 Teams 연락이 내부 이동으로 이어진 과정

공격의 출발점은 첨부파일이나 Teams 취약점이 아니라 외부 사용자의 채팅 또는 통화였다. 공격자는 보안 업데이트, 스팸 필터 업데이트, 계정 확인 등을 구실로 화면 공유의 제어 요청을 승인하거나 Quick Assist 연결 코드를 알려 달라고 요구했다. 음성 통화를 함께 사용하면 악성 지시와 주소가 Teams 채팅 기록에 남지 않을 수 있다.

1. 외부 테넌트 계정이 IT 또는 헬프데스크 담당자를 사칭해 Teams로 접근한다.
2. 직원이 외부 연락 경고를 넘고 화면 제어 또는 원격 지원 연결을 승인한다.
3. 공격자가 원격 세션에서 PowerShell로 MSI를 내려받아 사용자에게 설치 화면을 표시하지 않고 실행한다.
4. MSI가 LocalAppData에 로더와 암호화된 임플란트를 놓고, 휴대용 Node.js 런타임으로 JavaScript 코드를 실행한다.
5. 임플란트가 화면을 캡처하고 호스트, 보안 제품, 도메인 계정과 서버를 조사하며 추가 DLL을 실행한다.
6. Node.js 백도어에서 시작된 작업이 WinRM을 이용해 도메인 컨트롤러와 인증 기관을 포함한 도메인 가입 시스템으로 이동한다.

MSI에는 ‘devfix’나 ‘Hotfix’처럼 정상 업데이트를 연상시키는 이름이 사용됐다. 지속성은 현재 사용자 Run 레지스트리 값이나 시작프로그램 바로가기에 ‘EdgeUpdate’를 등록하는 방식으로 만들어졌다. 이 때문에 파일명이나 서명된 실행 파일 하나만 검사하는 것보다 외부 Teams 연락, 원격 지원, PowerShell, msiexec, LocalAppData의 Node.js, WinRM으로 이어지는 시간순 행위를 연결하는 것이 중요하다.

Teams 결함이 아니라 사용자 신뢰를 통과했다

Microsoft가 공개한 침입은 Teams 자체의 보안 결함을 악용한 사례가 아니다. Teams는 첫 외부 연락에 테넌트 표시, 수락·차단 선택과 피싱 경고를 제공했지만, 공격자는 직원이 경고를 직접 넘고 정상 원격 지원 기능을 열도록 설득했다. 최초 요청을 승인한 한 번의 세션이 이후 단계의 발판이 된 셈이다.

원격 제어 뒤에도 정상 도구가 계속 섞였다. Windows Installer는 MSI를 조용히 설치했고, 공식 배포본의 서명된 Node.js 런타임은 사용자 쓰기 가능 경로의 난독화된 코드를 실행했다. PowerShell, cmd.exe, WScript와 rundll32 같은 Windows 구성 요소도 다운로드, 부트스트랩과 후속 페이로드 실행에 동원됐다.

제목의 ‘도메인 관리자까지 노린다’는 말은 관리자 계정 탈취가 확인됐다는 뜻이 아니다. 관측된 공격자가 도메인 계정과 서버를 열거하고 도메인 컨트롤러·인증 기관으로 WinRM 연결을 시작했으며, Microsoft가 감염 기기에서 접근 가능했던 도메인 관리자 자격 증명까지 교체 대상으로 검토하라고 권고했다는 의미다. 확인된 표적과 완료된 피해를 구분해야 과장 없이 대응 범위를 정할 수 있다.

직원이 끊을 지점은 원격 제어 승인 전이다

가장 이른 차단 지점은 예고하지 않은 외부 지원 연락을 받은 순간이다. 표시 이름에 회사명, IT 또는 보안이라는 단어가 들어 있어도 내부 직원이라는 증거가 되지 않는다. 계정 중단을 피하려면 즉시 처리해야 한다는 재촉과 원격 제어 요구가 함께 나오면 해당 대화 안에서 신원을 확인하려 해서는 안 된다.

• 외부 사용자나 외부 테넌트 표시가 붙은 지원 요청은 바로 수락하지 않는다.
• 사내 포털, 등록된 전화번호 또는 별도의 내부 채널로 실제 티켓과 담당자를 확인한다.
• 조직이 정한 인증 문구나 티켓 번호가 있다면 수신한 대화가 아닌 독립된 채널에서 대조한다.
• 예고 없는 화면 제어, Quick Assist 코드 전달과 권한 상승 요청을 거절한다.
• 상대가 전달한 PowerShell 명령이나 설치 파일을 직접 실행하지 않는다.

이미 제어를 허용했다면 원격 연결을 종료하고 보안팀의 절차에 따라 기기를 격리해야 한다. Teams 대화와 통화 시각, 표시된 외부 계정, 사용한 원격 지원 도구와 승인한 동작은 삭제하지 말고 보존하는 편이 조사에 유리하다. 설치 창을 보지 못했더라도 안전하다고 판단할 수 없다. 관측된 MSI는 사용자 인터페이스를 숨기는 방식으로 설치됐기 때문이다.

관리자는 외부 협업·RMM·실행·WinRM을 나눠 통제해야 한다

관리자 대책은 외부 Teams 협업을 일괄 차단하는 한 가지 규칙으로 끝나지 않는다. 업무상 필요한 외부 도메인을 명시적으로 관리하고, 외부 발신자 표시가 사용자에게 분명하게 보이는지 확인해야 한다. 내부 헬프데스크가 연락하는 채널, 담당자 인증 방법, 티켓 발급과 원격 지원 절차도 고정해야 사칭자가 정상 업무 사이에 끼어들기 어렵다.

• Teams 외부 접근을 신뢰하는 도메인으로 제한하고 예외를 정기적으로 재검토한다.
• 승인된 RMM과 원격 지원 도구, 사용 담당자와 허용 조건을 목록으로 관리한다.
• 원격 지원 프로세스 직후 PowerShell, cmd.exe, WScript 또는 msiexec가 실행되는 흐름을 경보로 묶는다.
• 사용자 프로필의 임의 폴더에서 실행되는 휴대용·이름 변경 Node.js와 비표준 확장자 로더를 함께 감시한다.
• WinRM을 승인된 관리 워크스테이션으로 제한하고 사용자 문맥이나 비관리 프로세스에서 시작된 연결을 조사한다.
• 감염 기기에서 접근할 수 있었던 계정과 원격 로그온 기록을 확인하고 필요한 자격 증명을 교체한다.

Node.js 자체를 차단하면 정상 개발·업무 환경에서 오탐이 커질 수 있다. 더 구체적인 단서는 LocalAppData에서 실행되는 런타임, WScript가 시작한 Node.js, 표준 입력이나 임시 파일로 전달되는 JavaScript, 그리고 같은 사용자에게 만들어진 ‘EdgeUpdate’ 지속성이다. 이 행위를 앞선 원격 지원 세션 및 뒤따른 WinRM 연결과 묶으면 정상 관리 작업과 구분할 근거가 강해진다.

일반 사용자 PC에서 시작된 WinRM 연결이 여러 서버와 신원 인프라로 향했다면 초기 감염 기기만 격리해서는 범위를 판단할 수 없다. 해당 호스트에서 사용하거나 접근할 수 있었던 계정, 대상 서버의 원격 로그온, 도메인 컨트롤러와 인증 기관의 활동까지 조사해야 한다. 다만 연결 시도만으로 모든 대상에서 명령이 실행됐다고 간주해서도 안 된다.

도메인 장악과 랜섬웨어 완료는 확인되지 않았다

9월 5일의 nulltap 기술 검토 는 원격 제어, MSI, Node.js 지속성과 WinRM 이동을 다시 정리하면서 Microsoft가 대상 조직 수를 공개하지 않았고, 도메인 장악·데이터 절도·갈취·랜섬웨어 완료도 보고하지 않았다고 범위를 구분했다. 공격 주체의 이름과 피해 기업 역시 공개되지 않았다.

현재 확정된 것은 외부 Teams 지원 사칭이 사용자 승인 원격 세션으로 바뀌고, 정상 관리 도구 사이에 악성 MSI와 JavaScript 임플란트가 숨은 뒤 신원 인프라를 향한 이동으로 확대됐다는 점이다. 향후 피해 조직이나 추가 분석이 공개되기 전까지는 최종 피해를 추정해 붙이기보다 Teams 대화·통화 식별자, 원격 세션 기록, 프로세스 원격측정, MSI와 사용자 프로필의 지속성 항목, WinRM 네트워크 이벤트를 연결해 확인된 공격 사슬을 조사하는 것이 정확하다.