핵심 POINT
Microsoft는 9월 17일 최신 보안 가이드에서 협업도구를 통한 IT 지원 사칭과 정상 원격지원 도구 악용을 기업이 다시 점검해야 할 공격 경로로 제시했습니다.
이 공격은 Teams 자체 취약점을 이용하기보다 외부 연락을 내부 헬프데스크처럼 믿게 만들어 사용자가 직접 원격제어를 허용하도록 유도하는 사회공학 공격입니다.
예방의 핵심은 갑작스러운 지원 요청을 공식 내부 채널로 재확인하고, 외부 협업·원격지원·관리 프로토콜의 허용 범위를 함께 제한하는 것입니다.
업무용 협업도구에서 “IT 지원팀입니다”, “보안 업데이트가 필요합니다”라는 연락을 받으면 일반적인 사내 안내처럼 느껴질 수 있습니다. 공격자는 바로 이 익숙함을 이용해 사용자가 스스로 원격지원 기능을 실행하고 제어 권한을 넘기도록 유도하고 있습니다.
Microsoft는 2026년 9월 17일 공개한 보안 가이드에서 최근 관찰한 공격 경로 중 하나로 IT 지원 사칭 → 정상 원격지원 도구 실행 → 악성 코드 설치 → 내부 확산 흐름을 다시 강조했습니다. Microsoft Threat Intelligence가 9월 2일 공개한 상세 분석에서는 외부 Teams 연락으로 헬프데스크를 사칭한 뒤, 사용자가 원격 세션을 허용하면 PowerShell과 MSI 설치를 거쳐 내부 시스템 탐색과 WinRM 기반의 수평 이동까지 이어진 사례가 확인됐습니다.
이번 글에서는 Microsoft가 해외 환경에서 관찰한 사례를 바탕으로, 국내 기업에서도 유사한 사회공학 공격에 대비하기 위해 임직원과 IT·보안 담당자가 어떤 부분을 확인해야 하는지 살펴보겠습니다.
■ Teams 메시지 하나가 원격 침입 경로가 되는 방식

출처: AI(ChatGPT) 생성 이미지
이 공격의 시작점은 악성 첨부파일이 아니라 정상적인 협업 기능입니다. 공격자는 외부 테넌트에서 Teams 채팅이나 통화를 시작한 뒤 내부 IT 또는 헬프데스크 담당자처럼 행동합니다. 계정 확인, 보안 업데이트, 스팸 필터 조정 같은 이유를 제시하며 원격지원 세션을 열도록 유도합니다.
Microsoft 분석에 따르면 사용자가 원격제어를 허용한 이후에는 PowerShell로 악성 MSI 설치 파일을 내려받고, 정상 Node.js 런타임과 스크립트를 조합해 명령 실행 환경을 구성한 사례가 확인됐습니다. 이후 공격자는 단말과 Active Directory 환경을 탐색하고, 화면 캡처와 추가 페이로드 실행을 거쳐 WinRM으로 다른 시스템에 접근을 시도했습니다.
중요한 점은 이 과정이 Teams의 취약점 악용으로 시작된 것이 아니라는 점입니다. 외부 연락 표시와 보안 경고가 있어도 사용자가 이를 무시하도록 설득하고 정상 원격지원 절차를 악용하는 방식이 핵심입니다.
공격 흐름을 간단히 보면
• 외부 Teams 채팅·통화로 IT 또는 헬프데스크를 사칭합니다.
• 사용자가 화면 공유나 원격지원 요청을 승인하도록 유도합니다.
• 원격 세션에서 PowerShell 등을 이용해 악성 MSI 설치를 진행합니다.
• 단말과 도메인 정보를 탐색하고 추가 명령을 실행합니다.
• WinRM 등 정상 관리 기능을 이용해 다른 내부 시스템으로 이동을 시도합니다.
■ 정상 도구가 섞여 있어 더 구분하기 어렵습니다
이 공격이 까다로운 이유는 공격 과정에 익숙한 업무 도구가 계속 등장하기 때문입니다. 협업도구, 원격지원 프로그램, PowerShell, Windows Installer, Node.js, WinRM은 모두 정상적인 기업 환경에서도 사용할 수 있습니다.
따라서 특정 프로그램의 실행 여부만으로 공격을 판단하기보다, 누가 원격 세션을 요청했는지, 평소와 다른 실행 흐름이 이어졌는지, 일반 사용자 단말에서 관리용 프로토콜이 갑자기 사용됐는지를 함께 봐야 합니다.
예를 들어 사용자가 외부 연락을 받은 직후 원격지원 프로그램을 실행했고, 그 세션에서 PowerShell이나 명령 프롬프트가 시작되며 MSI 파일이 다운로드됐다면 정상 지원 업무인지 즉시 재확인이 필요합니다.
■ 임직원이 원격제어 요청을 받았을 때 확인할 5가지
사회공학 공격은 기술적인 차단만으로는 충분하지 않습니다. 사용자에게 원격지원을 허용하기 전 확인할 절차를 짧고 명확하게 안내하는 것이 중요합니다.
1. 갑작스러운 IT 지원 연락은 별도 채널로 재확인합니다.
메시지에 답장하는 방식이 아니라 사내 포털, 대표 헬프데스크 번호, 기존 티켓 시스템처럼 이미 알고 있는 내부 채널을 사용해야 합니다.
2. 외부 사용자 표시를 먼저 확인합니다.
협업도구에서 외부 조직 또는 외부 사용자를 나타내는 표시가 있다면 내부 IT 담당자라고 주장하더라도 바로 원격제어를 허용하지 않는 것이 좋습니다.
3. 원격지원 코드나 제어권을 먼저 넘기지 않습니다.
공식 지원 절차가 확인되기 전에는 화면 제어 요청, 원격지원 코드, 관리자 권한 상승 요청을 승인하지 않아야 합니다.
4. 명령어 실행을 요구하면 즉시 중단합니다.
PowerShell, 명령 프롬프트, 실행창에서 특정 명령을 입력하거나 보안 설정을 끄도록 요구하는 연락은 특히 주의해야 합니다.
5. 이상한 지원 요청은 보안팀에 바로 공유합니다.
같은 공격자가 여러 직원을 동시에 접촉할 수 있기 때문에 한 명이 의심 연락을 신고하면 다른 임직원의 추가 피해를 막는 데 도움이 됩니다.
■ IT·보안팀은 외부 협업과 원격지원 정책을 함께 점검

출처: AI(ChatGPT) 생성 이미지
Microsoft는 사용자 교육과 함께 외부 협업 정책, 원격지원 도구, 인증, 엔드포인트 제어를 계층적으로 강화할 것을 권고하고 있습니다. 기업 환경에서는 다음 항목을 우선 확인해볼 수 있습니다.
• Teams 등 협업도구의 외부 접근 허용 범위를 검토하고, 업무상 필요한 신뢰 도메인 중심으로 제한합니다.
• 사내 헬프데스크가 사용하는 원격지원 도구와 인증 절차를 표준화하고, 허용되지 않은 원격지원 프로그램의 사용 여부를 모니터링합니다.
• 관리자와 주요 사용자에는 피싱 저항성이 높은 MFA를 적용하고, 관리 단말 또는 규정 준수 단말에서만 민감한 작업을 수행하도록 제한합니다.
• 일반 사용자 단말에서 PowerShell, 스크립트 인터프리터, 다운로드된 실행 파일이 비정상적인 흐름으로 이어지는지 엔드포인트 정책과 탐지 규칙을 점검합니다.
• WinRM은 승인된 관리 워크스테이션과 관리 목적에 한정해 허용하고, 일반 사용자 프로세스에서 비정상적으로 연결되는 경우 경보를 검토합니다.
■ 이미 원격제어를 허용했다면 먼저 확인할 것

출처: AI(ChatGPT) 생성 이미지
의심스러운 연락에 응답해 원격제어를 허용했거나 명령이 실행된 정황이 있다면 단순히 세션을 종료하는 것만으로 충분하지 않을 수 있습니다. 공격자가 이미 추가 프로그램을 설치하거나 자격증명과 내부 시스템 정보를 확인했을 가능성을 고려해야 합니다.
먼저 해당 단말을 네트워크에서 격리하고, 원격지원 세션 이후 실행된 PowerShell·MSI·스크립트·Node.js 관련 활동과 신규 지속성 설정을 확인하는 것이 좋습니다. 도메인 계정이나 관리자 자격증명이 노출됐을 가능성이 있다면 관련 자격증명의 교체와 인증 로그 확인도 필요합니다.
특히 일반 사용자 단말에서 다수의 내부 서버로 WinRM 연결이 발생했거나 도메인 컨트롤러·인증 관련 시스템으로 비정상 접근이 이어졌다면 초기 단말만 보지 말고 내부 확산 여부까지 범위를 넓혀 조사해야 합니다.
■ 자주 묻는 질문
Q. Teams 자체가 해킹된 공격인가요?
A. Microsoft가 분석한 사례는 Teams의 취약점을 악용한 공격이 아니라 외부 협업 기능과 사회공학을 이용해 사용자가 정상 원격지원 절차를 직접 실행하도록 유도한 공격입니다.
Q. 사내 IT팀이 실제로 원격지원을 하는데 어떻게 구분해야 하나요?
A. 원격지원 여부보다 요청자의 확인 절차가 중요합니다. 갑작스러운 채팅이나 전화만 믿지 말고 사내 포털, 기존 지원 티켓, 공식 헬프데스크 번호 등 독립된 내부 채널을 통해 요청이 실제인지 확인하는 것이 좋습니다.
Q. 원격지원 프로그램을 모두 차단해야 하나요?
A. 업무상 필요한 원격지원까지 모두 차단할 필요는 없습니다. 승인된 도구와 사용 주체를 명확히 하고, 외부 지원 세션의 인증과 기록, 관리자 권한 사용 범위를 통제하는 방식이 현실적입니다.
Q. 어떤 로그를 우선 확인해야 하나요?
A. 의심 연락 시점 전후의 외부 협업 이벤트, 원격지원 프로그램 실행, PowerShell·명령 프롬프트 실행, MSI 다운로드·설치, 사용자 프로필 경로의 신규 실행 파일, WinRM 연결 기록을 우선 확인할 수 있습니다.
Q. 국내 기업에서도 같은 피해가 확인됐나요?
A. 이번 글은 Microsoft가 해외 환경에서 관찰한 공격 사례와 대응 가이드를 바탕으로 정리했습니다. 이 자료만으로 국내에서 동일한 피해가 발생했다고 단정할 수는 없으며, 국내 기업은 유사한 사회공학 공격 경로에 대비하는 관점에서 참고하는 것이 적절합니다.



