공격보다 빠른 방어: 2026년 파괴적 공격 시나리오를 무력화하는 전략

해당 블로그의 원문은 2026년 3월 7일 Google Cloud 블로그(영문)에 게재되었습니다. 

작성자: Matthew McWhirt, Bhavesh Dhake, Emilio Oropeza, Gautam Krishnan, Stuart Carrera, Greg Blaum, Michael Rudden

업데이트 (3월 13일): 엔드포인트 / MDM 플랫폼의 남용 또는 오용에 대한 지침 추가

배경

위협 행위자는 데이터를 파괴하거나, 악의적인 활동의 증거를 제거하거나, 시스템을 조작하여 작동 불능 상태로 만들기 위해 파괴적인 악성코드를 활용합니다. 파괴적인 사이버 공격은 전략적 또는 전술적 목표를 달성하기 위한 강력한 수단이 될 수 있지만, 보복의 위험으로 인해 사용 빈도는 극히 일부의 사건으로 제한될 가능성이 높습니다. 파괴적인 사이버 공격에는 파괴적인 악성코드, 와이퍼(wipers) 또는 변종 랜섬웨어(modified ransomware)가 포함될 수 있습니다.

분쟁이 발생했을 때, 사이버 공격은 저렴하고 쉽게 배포할 수 있는 무기입니다. 정세 불안이 공격 증가로 이어진다는 것은 놀라운 일이 아닙니다. 이 블로그 게시물은 조직이 환경 내에서 발생하는 파괴적인 공격으로부터 스스로를 보호하기 위해 우선적으로 고려해야 할 선제적 권고 사항을 제공합니다. 이 권고안에는 파괴적인 공격뿐만 아니라, 위협 행위자가 정찰을 수행하고, 권한을 상승시키며, 내부망을 이동(lateral movement)하고, 액세스를 유지하며, 목표를 달성하려고 시도하는 잠재적인 사고로부터 조직을 보호하는 데 도움이 되는 실용적이고 확장 가능한 방법들이 포함되어 있습니다.

이 블로그 게시물에 설명된 탐지 기회는 기존 보안 도구에 대한 보조적인 모니터링 역할을 하기 위한 것입니다. 조직은 추가적인 예방 및 탐지 조치로 엔드포인트 및 네트워크 보안 도구를 활용해야 합니다. 이러한 도구는 시그니처 및 휴리스틱을 포함한 광범위한 탐지 기능을 사용하여 합리적인 신뢰도로 악의적인 활동을 탐지합니다. 이 블로그 게시물에서 참조하는 맞춤형 탐지 기회는 특정 위협 행위자의 행동과 상호 연관되어 있으며, 정상적인 패턴과의 차이점을 통해 식별되는 비정상적인 활동을 트리거하기 위한 것입니다. 효과적인 모니터링은 조직의 고유한 환경에 대한 철저한 이해와 사전에 수립된 기준선(baseline)의 활용에 달려 있습니다.

조직의 복원력

이 블로그 게시물의 핵심 초점은 기술적 및 전술적 중심의 보안 통제에 맞춰져 있지만, 기술적인 준비와 복구가 유일한 전략은 아닙니다. 위기 대비 및 조율을 보안 거버넌스의 핵심 구성 요소로 포함하는 조직은 자연스럽게 "살아있는" 복원력 태세를 갖출 수 있습니다. 여기에는 다음이 포함됩니다.

• 대역 외(Out-of-Band) 사고 지휘 및 커뮤니케이션: 기업의 신원 관리 체계(corporate identity plane)와 완전히 분리된, 사전 검증된 "대역 외" 커뮤니케이션 플랫폼을 구축하십시오. 이는 주요 통신 플랫폼을 사용할 수 없는 경우에도 핵심 이해관계자와 제3자 지원팀이 안전하게 협력하고 소통할 수 있도록 보장합니다.

• 명확한 운영 비상 계획 및 복구 계획: 복원 또는 재구축 노력 중에도 연속성을 보장하기 위해 필수 비즈니스 기능에 대한 수동 절차를 포함한 기준 운영 요구사항을 수립하십시오. 조직은 또한 우선순위가 지정된 애플리케이션 복구 순서를 개발하고, 복구 목표를 위한 안전한 기반을 구축하는 데 필요한 필수 종속성을 파악해야 합니다.

• 신뢰할 수 있는 제3자 공급업체 관계 사전 구축: 비즈니스 운영에 필수적인 다양한 기술 및 플랫폼을 기반으로, 외부 파트너와 사전 정의된 계약을 체결하여 법률/계약 요구사항, 사고 대응, 치료, 복구 및 랜섬웨어 협상을 위한 전문가의 지원을 보장하십시오.

• 복구 절차 연습 및 개선: 격리된 불변의 백업과 대역 외 통신 채널을 사용하여 미션 크리티컬 서비스의 종단 간(end-to-end) 복원을 검증하는 훈련을 수행하여, 복구 시간 목표(RTO)와 데이터 무결성(RPO)이 테스트되고, 연습되며, 최신 상태로 유지되도록 하십시오.

Google Security Operations

Google Security Operations(SecOps) 고객은 Mandiant Intel Emerging Threats, Mandiant Frontline Threats, Mandiant Hunting Rules, CDIR SCC Enhanced Data Destruction Alerts 규칙 팩(rule packs)에서 이러한 광범위한 카테고리의 규칙 등을 이용할 수 있습니다. 이 블로그 게시물에서 논의된 활동은 Google SecOps에서 다음 규칙 이름으로 탐지됩니다.

• BABYWIPER 파일 삭제 (BABYWIPER File Erasure)

• 보안 증거 인멸 및 정리 명령 (Secure Evidence Destruction And Cleanup Commands)

• CMD를 이용한 애플리케이션 자가 삭제 (CMD Launching Application Self Delete)

• 다운로드 폴더 내 바이너리 복사 (Copy Binary From Downloads)

• 특수 문자가 포함된 DLL 함수 실행(Rundll32) (Rundll32 Execution Of Dll Function Name Containing Special Character)

• 서비스를 통한 CMD 실행 (Services Launching Cmd)

• 예약된 작업을 통한 시스템 프로세스 실행 (System Process Execution Via Scheduled Task)

• Dllhost 위장 공격 (Dllhost Masquerading)

• 인젝션을 위한 백도어 DLL 파일 생성 (Backdoor Writing Dll To Disk For Injection)

• 단일 명령어를 통한 Windows Defender 다중 제외 설정 (Multiple Exclusions Added To Windows Defender In Single Command)

• Windows Defender 경로 제외 설정 추가 (Path Exclusion Added to Windows Defender)

• CurrentControlSet 서비스 레지스트리 변경 (Registry Change to CurrentControlSet Services)

• PowerShell을 이용한 콘텐츠 값 '0' 설정 (Powershell Set Content Value Of 0)

• DD 유틸리티를 이용한 디스크 덮어쓰기 (Overwrite Disk Using DD Utility)

• 명령어를 통한 Bcdedit 수정 (Bcdedit Modifications Via Command)

• 드라이브 와이핑을 위한 크래시 덤프 비활성화 (Disabling Crash Dump For Drive Wiping)

• 의심스러운 Wbadmin 명령 실행 (Suspicious Wbadmin Commands)

• Fsutil을 이용한 파일 영구 삭제(Zero Out) (Fsutil File Zero Out)

권장 사항 요약

1. 외부 노출 자산 (External-Facing Assets)

식별, 목록화 및 시스템 강화

위협 행위자가 외부 노출 벡터(external-facing vector)를 통해 취약점이나 잘못된 구성을 악용하는 것을 방어하기 위해, 조직은 외부에서 접근 가능한 애플리케이션 및 조직 관리 서비스의 범위를 파악해야 합니다. 외부에서 접근 가능한 애플리케이션과 서비스(온프레미스 및 클라우드 모두 포함)는 위협 행위자들이 알려진 취약점을 악용하거나, 일반적이거나 기본값인 자격 증명에 대한 무차별 대입 공격(brute-forcing)을 수행하거나, 유효한 자격 증명으로 인증하여 초기 침투(initial access) 권한을 확보하기 위한 주요 표적이 됩니다.

외부 노출 애플리케이션 및 서비스를 선제적으로 식별하고 검증하려면 다음 사항을 고려하십시오.

• 취약점 스캐닝 기술을 활용하여 자산 및 관련 취약점을 식별합니다.

• 인증 및 액세스에 악용될 수 있는 외부 노출 벡터를 식별하는 것을 목표로 집중적인 취약점 평가(vulnerability assessment) 또는 모의 침투 테스트(penetration test)를 수행합니다.

• 외부 노출 서비스를 위해 조직이 활용하는 제품에 알려진 취약점을 완화하기 위한 패치나 업데이트가 필요한지 기술 공급업체에 확인합니다.

식별된 취약점은 패치 및 강화 조치를 취해야 할 뿐만 아니라, 식별된 기술 플랫폼을 검토하여 의심스러운 활동의 증거나 기술/장비 변조가 이미 발생하지 않았는지 확인해야 합니다.

다음 표는 일반적인 클라우드 기반 인프라 내에서 외부 노출 자산과 리소스를 선제적으로 검토하고 식별할 수 있는 기능에 대한 개요를 제공합니다.

다중 인증(MFA) 의무화

단일 인증(SFA)을 활용하는 외부 노출 자산은 무차별 대입 공격(brute-forcing), 패스워드 스프레이 공격(password spraying), 또는 탈취한 유효한 자격 증명을 이용한 무단 원격 액세스에 매우 취약합니다. 현재 SFA를 허용하는 외부 노출 애플리케이션 및 서비스는 다중 인증(MFA)을 지원하도록 구성되어야 합니다. 또한, 온프레미스의 외부 노출 관리형 인프라에 접근할 때뿐만 아니라 클라우드 기반 리소스(예: Microsoft 365[M365]와 같은 Software-as-a-Service[SaaS])를 이용할 때도 MFA가 의무적으로 적용되어야 합니다.

MFA를 구성할 때 일반적으로 고려되는 방법은 다음과 같으며, 보안 수준이 가장 높은 것부터 가장 낮은 순으로 정렬되었습니다.

• FIDO2(Fast IDentity Online 2) / WebAuthn 보안 키 또는 패스키

• 소프트웨어/하드웨어 OAUTH(Open Authentication) 토큰

• 인증 애플리케이션 (예: Duo / MS Authenticator / Okta Verify 등)

• 시간 기반 일회용 비밀번호 (TOTP)

• (가장 권장하지 않는 옵션) 가능한 경우 번호 일치(number matching) 방식을 사용하는 푸시 알림

• 전화 통화

• SMS(문자 메시지) 인증

• 이메일 기반 인증

특정 MFA 방식의 위험성 

푸시 알림

조직이 MFA 수단으로 푸시 알림(예: 애플리케이션을 통한 수락 또는 모바일 기기로의 자동 전화 통화를 요구하는 알림)을 활용하는 경우, 위협 행위자는 이러한 MFA 구성의 약점을 파고들어 접속을 시도할 수 있습니다. 사용자가 인증이 시작된 맥락(위치, 기기 등)을 파악하지 못한 채 자신의 기기에서 무심코 푸시 알림을 수락할 수 있기 때문입니다.

전화/SMS 인증

조직이 MFA 수단으로 전화 통화나 SMS 기반 인증을 활용하는 경우, 이러한 방법은 암호화되지 않으므로 위협 행위자에게 가로채일 수 있는 위험이 존재합니다. 또한, 위협 행위자가 직원의 전화번호를 자신이 통제하는 USIM(가입자 식별 모듈) 카드로 이전(SIM 스와핑)할 수 있다면 이 방식은 더욱 취약해집니다. 이 경우 MFA 알림이 원래의 직원 대신 위협 행위자에게 전송됩니다.

이메일 기반 인증

조직이 액세스 유효성 검사 또는 MFA 코드 수신을 위해 이메일 기반 인증을 활용하고, 위협 행위자가 이미 표적의 이메일에 접근할 수 있는 권한을 확보한 상태라면, 행위자는 수신된 이메일을 가로채어 검증하고 MFA 프로세스를 완료할 가능성이 높습니다.

이러한 MFA 방법 중 하나를 활용하는 경우 다음 사항을 고려해야 합니다.

• 원격 사용자에게 본인이 직접 로그인 시도를 하지 않은 상태에서 로그인 알림을 수락하거나 응답하지 않도록 교육하십시오.

• 사용자가 의심스러운 MFA 알림을 신고할 수 있는 방법을 마련하십시오. 이는 계정이 침해되었음을 나타내는 징후일 수 있습니다.

• 조직 외부로 이메일 메시지가 자동 전달(auto-forwarding)되는 것을 방지하는 메시징 정책이 마련되어 있는지 확인하십시오.

시간 기반 일회용 비밀번호

시간 기반 일회용 비밀번호(TOTP)는 인증 시스템과 최종 사용자가 소유한 인증기(authenticator)가 모두 알고 있는 '시드(seed)'라는 공유 비밀 키에 의존합니다. 시드가 유출되면 TOTP 인증기를 복제하여 위협 행위자가 사용할 수 있습니다.

외부 노출 자산 및 MFA 시도 탐지 기회

2. 주요 자산 보호 (Critical Asset Protections)

도메인 컨트롤러 및 주요 자산 백업 (Domain Controller and Critical Asset Backups)

조직은 도메인 컨트롤러 및 주요 자산에 대한 백업이 항상 사용 가능한 상태인지, 그리고 무단 액세스나 변조로부터 보호되고 있는지 확인해야 합니다. 백업 프로세스 및 절차는 지속적으로 점검하고 훈련해야 합니다. 백업 데이터는 네트워크 및 신원(Identity) 기반의 세분화(segmentation)가 모두 적용된 안전한 격리 영역(secure enclaves) 내에 저장되고 보호되어야 합니다.

랜섬웨어나 파괴적인 공격으로 인해 조직의 Active Directory(AD)가 손상되거나 사용할 수 없게 될 경우, 도메인 컨트롤러 백업에서 Active Directory를 복원하는 것이 도메인 서비스를 재구성하기 위한 유일한 실행 가능한 옵션일 수 있습니다. 조직은 다음의 도메인 컨트롤러 복구 및 재구성 모범 사례를 선제적으로 검토해야 합니다.

• 도메인 컨트롤러 및 SYSVOL 공유(예: 도메인 컨트롤러에서 C:\Windows\SYSVOL 백업)에 대해 정상 작동이 확인된 백업본이 있는지 점검합니다.

  • 도메인 컨트롤러의 경우, 시스템 상태(System State) 백업을 권장합니다.

    참고: 시스템 상태 백업을 수행하려면 도메인 컨트롤러에 Windows Server 백업(Windows Server Backup) 기능이 설치되어 있어야 합니다.

  • 도메인 컨트롤러의 시스템 상태 백업을 시작하려면 관리자 권한으로 실행된 명령 프롬프트(Command Prompt)에서 다음 명령어를 실행할 수 있습니다.

wbadmin start systemstatebackup -backuptarget:<targetDrive>:

그림 1: 시스템 상태(System State) 백업 수행 명령어

• • SYSVOL 백업을 수행하려면 관리자 권한으로 실행된 명령 프롬프트(Command Prompt)에서 다음 명령어를 실행할 수 있습니다. (백업을 수행하는 계정에는 감사 및 보안 로그 관리(Manage auditing and security log) 권한도 설정되어 있어야 합니다.)

robocopy c:\windows\sysvol c:\sysvol-backup /copyall /mir /b /r:0 /xd

그림 2: SYSVOL 백업 수행 명령어

• 전체 도메인 복구가 필요한 상황에 대비하여, FSMO(Flexible Single Master Operation) 역할을 보유한 도메인 컨트롤러를 사전에 식별해 두십시오. 이 도메인 컨트롤러들은 복구 시 가장 우선순위가 높게 처리되어야 합니다.

netdom query fsmo

그림 3: FSMO 역할을 보유한 도메인 컨트롤러 식별 명령어

• 오프라인 백업: 오프라인 상태의 도메인 컨트롤러 백업이 온라인 백업과 물리적/논리적으로 분리되어 안전하게 보관되고 있는지 확인하십시오.

• 암호화: 백업 데이터는 전송 중(네트워크 통신 중)일 때와 저장 상태(at rest), 혹은 외부 스토리지(offsite storage)에 미러링될 때 모두 암호화되어야 합니다.

• DSRM 비밀번호 검증: 각 도메인 컨트롤러에 대해 디렉터리 서비스 복원 모드(Directory Services Restore Mode, DSRM) 비밀번호가 관리자가 인지하고 있는 값으로 설정되어 있는지 확인하십시오. 이 비밀번호는 권한 있는(authoritative) 또는 권한 없는(nonauthoritative) 도메인 컨트롤러 복원을 수행할 때 반드시 필요합니다.

• 백업 작업에 대한 경고 구성: 백업 데이터의 가용성 및 무결성에 치명적인 작업(예: 백업 데이터 삭제, 백업 메타데이터 완전 삭제, 복원 이벤트, 미디어 오류 등)을 탐지하고 알림을 제공하도록 백업 제품 및 기술을 구성해야 합니다.

• 역할 기반 액세스 제어(RBAC) 적용: 백업 미디어 및 데이터 백업을 제어하고 관리하는 애플리케이션에 대한 접근은 RBAC를 사용하여 저장된 데이터 및 구성 매개변수에 접근할 수 있는 계정의 범위를 엄격하게 제한해야 합니다.

• 테스트 및 검증: 권한 있는 도메인 컨트롤러 복원 프로세스와 권한 없는 도메인 컨트롤러 복원 프로세스 모두 문서화되어야 하며, 정기적으로 테스트를 거쳐야 합니다. 이와 동일한 테스트 및 검증 절차를 주요 자산과 데이터에도 적용해야 합니다.

비즈니스 연속성 계획

핵심 자산 복구는 심층적인 계획 및 준비에 크게 의존하며, 이는 종종 조직의 비즈니스 연속성 계획(BCP)에 포함됩니다. 계획 수립 및 복구 준비에는 다음과 같은 핵심 역량이 포함되어야 합니다.

• 가장 중요한 자산(crown jewels data) 및 이를 지원하는 애플리케이션에 대한 명확한 이해를 바탕으로, 미션 크리티컬 비즈니스 운영을 최우선으로 하는 백업, 장애 조치(failover), 복원 작업을 연계

• 명확하게 정의된 자산 우선순위 및 복구 순서

• 주요 시스템 및 데이터에 대해 철저하게 문서화된 복구 프로세스

• 복구 작업을 지원할 수 있도록 훈련된 인력

• 복구 프로세스가 성공적으로 실행될 수 있도록 검증

• 데이터 및 애플리케이션 백업 관리 및 검증에 대한 책임 소재 명확화

• 초기화, 주기, 검증 및 테스트(온프레미스 및 클라우드 기반 데이터 모두 해당)를 포함하는 온라인 및 오프라인 데이터 백업 보존 정책

• 애플리케이션 및 인프라 중심의 지원을 우선시하기 위해 공급업체와 체결한 서비스 수준 계약(SLA)

연속성 및 복구 계획은 시간이 지남에 따라 노후화될 수 있으며, 환경이나 인력 변화를 반영하여 프로세스가 업데이트되지 않는 경우가 많습니다. 지속적인 평가, 지속적인 교육, 그리고 복구 검증 훈련에 우선순위를 두면 조직은 재난 상황 발생 시 훨씬 더 철저하게 대비할 수 있습니다.

백업 관련 탐지 기회 

IT 및 OT 망 분리

조직은 기업 정보 기술(IT) 도메인, 신원, 네트워크, 자산과 운영 기술(OT) 프로세스 및 제어를 직접 지원하는 환경 간에 물리적, 논리적 망 분리(segmentation)가 명확히 이루어지도록 해야 합니다. IT와 OT 망 분리를 적용함으로써, 조직은 위협 행위자가 손상된 계정과 기존 네트워크 접근 경로를 이용해 기업 환경에서 미션 크리티컬한 OT 자산으로 횡적 이동(pivot)하는 것을 차단할 수 있습니다.

OT 환경은 기업 신원 및 인증과 신뢰 관계를 맺거나 교차 사용되지 않는 분리된 신원 저장소(예: 전용 Active Directory 도메인)를 활용해야 합니다. 기업 신원이나 자산의 침해가 위협 행위자에게 OT 프로세스에 영향을 미칠 수 있는 자산에 직접 접근할 수 있는 능력을 부여하는 결과를 초래해서는 안 됩니다.

IT와 OT에서 각각 분리된 AD 포리스트(forests)를 활용하는 것 외에도, IT 및 OT 환경에서 이중 용도로 사용될 수 있는 기술들(백업 서버, 백신[AV], 엔드포인트 탐지 및 대응[EDR], 점프 서버, 스토리지, 가상 네트워크 인프라 등)도 분리 대상에 포함되어야 합니다. OT 망 분리는 기업(IT) 환경에 장애가 발생하더라도 기업 인프라와의 직접적인 의존성(계정, 자산, 네트워크 경로) 없이 OT 프로세스가 독립적으로 안전하게 기능할 수 있도록 설계되어야 합니다. 즉시 분리할 수 없는 의존성의 경우, 조직은 IT(기업) 중심의 사고 징후가 탐지되었을 때 OT 환경을 효과적으로 격리할 수 있도록 잠재적인 단기 프로세스나 수동 제어(manual controls) 방안을 식별해야 합니다.

IT와 OT 환경의 분리는 미국 국립표준기술연구소(NIST)의 SP 800-82r3: Guide to Operational Technology (OT) Security 및 IEC 62443(구 ISA99)과 같은 산업 표준에서 권장하는 모범 사례입니다.

이러한 모범 사례 표준에 따르면, IT 및 OT 네트워크 망 분리에는 다음 사항이 포함되어야 합니다.

• 기업(IT) 네트워크에서 OT 네트워크 내로 직접 접근 가능한 포트, 서비스, 프로토콜의 범위를 제한하여 OT 공격 표면 축소.

• 기업(IT)에서 OT로 들어오는 액세스는 분리된 OT DMZ(Demilitarized Zone) 내에서 종료되어야 합니다. OT DMZ는 기업 IT 도메인에 있는 계정이나 엔드포인트를 활용하는 것 외에, 별도의 수준의 인증 및 액세스 권한 부여를 요구해야 합니다.

• 기업 환경에서 들어오는(incoming) 트래픽과 OT 환경에서 나가는(outgoing) 트래픽 모두를 제한하는 명시적인 방화벽 규칙을 적용해야 합니다.

• 방화벽은 승인되고 인가된 트래픽 흐름만 허용하는 '기본 거부(deny by default)' 원칙을 사용하여 구성해야 합니다. OT를 지원하는 모든 자산에 대한 아웃바운드(인터넷 방향) 트래픽 흐름 역시 기본 거부 모델을 따라야 합니다.

• 기업 IT와 OT 간에 신원(계정) 분리가 강제되어야 합니다. 두 환경 중 어느 한 곳의 계정이나 엔드포인트도 해당 환경을 벗어난 권한이나 액세스 권리를 가져서는 안 됩니다.

• OT 환경에 대한 원격 액세스는 기업 IT 환경 내에 원격 액세스 권한이 할당된 계정과 유사한 계정을 활용해서는 안 됩니다. OT 자산 및 리소스에 원격으로 액세스할 때는 별도의 자격 증명을 사용하는 다중 인증(MFA)을 강제해야 합니다.

• 안전 시스템에 대한 격리 및 신뢰성 검증을 포함한 수동 제어 프로세스에 대한 교육 및 검증.

• OT 인프라를 구성하는 시스템 및 기기의 백업, 프로그래밍 로직, 논리적 구성도(logistical diagrams)를 저장하기 위한 안전한 격리 영역(secured enclaves) 마련.

• OT 기기와 관련된 기본 사용자 이름과 비밀번호는 항상 공급업체의 기본 설정(default configuration)에서 변경해야 합니다.

IT 및 OT 망 분리 환경에서의 탐지 기회 

아웃바운드 트래픽 제한 (Egress Restrictions)

재부팅 빈도가 낮은 서버나 자산은 위협 행위자가 C2(명령 및 제어) 인프라에 지속적으로 비컨(beacon)을 보내는 백도어를 설정하기 위한 주요 표적이 됩니다. 이러한 유형의 자산에 대한 인터넷 접근을 차단하거나 엄격하게 제한함으로써 조직은 위협 행위자가 서버를 손상시키고, 데이터를 탈취하거나 아웃바운드(egress) 통신을 활용하여 액세스를 유지하기 위한 백도어를 설치할 위험을 효과적으로 줄일 수 있습니다.

아웃바운드 제한은 서버, 내부 네트워크 장비, 주요 IT 자산, OT 자산 및 현장 기기(field devices)가 외부 사이트와 주소(인터넷 리소스)와 통신을 시도할 수 없도록 강제되어야 합니다. '기본 거부(deny by default)' 개념은 모든 서버, 네트워크 장비 및 주요 자산(IT 및 OT 모두 포함)에 적용되어야 하며, 오직 명시적으로 정의된 화이트리스트(allow-listed) 기반의 승인된 아웃바운드 트래픽 흐름만 허용해야 합니다. 가능한 경우, 여기에는 DNS 터널링(DNS tunneling)을 통한 통신을 방지하기 위해 화이트리스트에 포함되지 않은 재귀적 DNS 확인(recursive DNS resolutions)을 차단하는 것도 포함되어야 합니다.

가능하다면 아웃바운드 트래픽은 프록시(proxy)와 같은 검사 계층을 거치도록 라우팅하여 외부 연결을 모니터링하고 악의적인 도메인이나 IP 주소로의 연결을 차단해야 합니다. 미분류 네트워크 위치(예: 최근 등록된 도메인)로의 연결은 허용되어서는 안 됩니다. 이상적으로는 악성 도메인에 대한 조회를 모니터링하기 위해 DNS 요청이 외부 서비스(예: Cisco Umbrella, Infoblox DDI 등)를 통해 라우팅되어야 합니다.

위협 행위자는 종종 아웃바운드 SMB(Server Message Block) 또는 WebDAV(Web-based Distributed Authoring and Versioning) 통신을 기반으로 자격 증명(NTLM [New Technology Local Area Network Manager] 해시 포함)을 탈취하려고 시도합니다. 조직은 환경 내의 모든 엔드포인트에서 허용되는 아웃바운드 프로토콜의 범위를 검토하고 제한해야 합니다. 많은 사용자 기반 엔드포인트에서 HTTP(TCP/80) 및 HTTPS(TCP/443) 아웃바운드 통신이 필요할 가능성이 높지만, 외부 사이트 및 주소의 범위는 웹 트래픽 필터링 기술을 기반으로 제한될 수 있습니다. 이상적으로 조직은 사전 정의된 화이트리스트를 기반으로만 아웃바운드 프로토콜 및 통신을 허용해야 합니다. 아웃바운드 제한을 위해 일반적으로 꼽히는 고위험 포트는 다음과 같습니다.

• 파일 전송 프로토콜 (FTP)

• 원격 데스크톱 프로토콜 (RDP)

• 보안 셸 (SSH)

• 서버 메시지 블록 (SMB)

• 간이 파일 전송 프로토콜 (TFTP)

• WebDAV

의심스러운 아웃바운드 트래픽 흐름 탐지 기회 

가상화 인프라 보호 

위협 행위자는 정찰, 내부망 이동(lateral movement), 데이터 탈취 및 잠재적인 랜섬웨어 배포 목적의 일환으로 가상화 인프라(예: VMware vSphere, Microsoft Hyper-V)를 자주 표적으로 삼습니다. 가상화 인프라를 보호하려면 1차 방어선으로 제로 트러스트(Zero Trust) 네트워크 아키텍처가 필요합니다. 관리 어플라이언스에는 로컬 권한 계정에 대한 기본 다중 인증(MFA)이 부족한 경우가 많으므로, 신원(Identity) 기반 보안에만 의존하는 것은 고위험의 단일 실패 지점(single point of failure)이 될 수 있습니다. 자격 증명이 손상되면 논리적 네트워크 아키텍처가 가상화 관리 제어 영역(management plane)을 보호하는 최후의 방어선이 됩니다.

가상화된 인프라의 공격 표면을 줄이기 위해 VMware vSphere vCenter ESXi 및 Hyper-V 어플라이언스와 서버에 권장되는 모범 사례는 관리 인터페이스에 대한 액세스를 격리하고 제한하는 것입니다. 기본적으로 관리 작업이 시작될 수 있는 전용 서브넷에서만 연결이 허용되는 격리된 가상 랜(VLAN, 네트워크 세그먼트) 내에 이러한 인터페이스를 엔클레이브(enclaves, 안전한 격리 영역)로 구성해야 합니다.

가상화 제어 영역(control plane)을 보호하기 위해 조직은 "심층 방어(defense-in-depth)" 네트워크 모델을 고려해야 합니다. 이 아키텍처는 물리적 격리와 동서(east-west) 마이크로 세그멘테이션을 통합하여 신뢰할 수 없는 네트워크로부터의 모든 액세스 경로를 제거합니다. 그 결과, 활발한 침입 시도 중에도 격리되고 복원력을 유지하는 관리 영역(management zone)이 구축됩니다.

VMware vSphere 제로 트러스트 네트워크 아키텍처 

주요 목표는 권한 있는 자격 증명이 유출되더라도 논리적 네트워크가 가상화 관리 인터페이스에 대한 접근을 차단하는 확실한 방어 계층으로 유지되도록 하는 것입니다.

• 불변의 VLAN 망 분리(Immutable VLAN Segmentation): 호스트 관리, 인프라/VCSA, vMotion(라우팅 불가), 스토리지(라우팅 불가), 프로덕션 게스트 VM에 대해 각각 다른 802.1Q VLAN ID를 사용하여 엄격한 격리를 강제합니다.

• 가상 라우팅 및 포워딩(VRF): 모든 인프라 VLAN을 전용 VRF 인스턴스로 전환합니다. 이를 통해 "사용자(User)" 또는 "게스트(Guest)" 영역이 완전히 침해되더라도 관리 영역으로 가는 라우팅 경로가 전혀 존재하지 않도록 보장합니다.

계층 3 및 4(Layer 3 and 4) 액세스 정책

관리 네트워크는 신뢰할 수 있고 강화된 출처(sources)에서만 접근할 수 있어야 합니다.

• PAW 전용 액세스: 일반 기업 LAN에서 관리 서브넷으로 향하는 모든 직접 라우팅 경로를 해체합니다. 액세스는 지정된 권한 있는 액세스 워크스테이션(PAW, Privileged Access Workstation) 서브넷에서만 시작되어야 합니다.

• 인바운드(Ingress) 필터링 (관리 영역):

  • 허용(ALLOW): PAW 서브넷에서만 TCP/443(UI/API) 및 TCP/902(MKS) 허용.

  • 차단(DENY): PAW 서브넷을 제외한 모든 소스에서 SSH(TCP/22) 및 VAMI(TCP/5480)를 명시적으로 차단.

• 제한적인 아웃바운드(Egress) 정책: 하드웨어 게이트웨이에서 아웃바운드 필터링을 강제합니다(VCSA GUI로는 아웃바운드를 관리할 수 없음). C2 트래픽과 데이터 유출을 이용한 지속성(persistence) 유지를 방지하기 위해, 특정되고 검증된 업데이트 서버(예: VMware Update Manager) 및 승인된 ID 제공자(IdP)를 제외한 모든 인터넷 액세스를 차단합니다.

호스트 기반 방화벽 적용

동일한 VLAN 내의 가시성 사각지대를 제거하기 위해 네트워크 방화벽을 호스트 수준의 필터링으로 보완하십시오.

• VCSA (Photon OS): VAMI를 통해, 혹은 더 바람직하게는 세분화된 출발지/목적지 매핑을 위해 iptables/nftables를 사용하여 OS 수준에서 기본 정책을 "기본 거부(Default Deny)"로 전환합니다.

• ESXi 하이퍼바이저: "모든 IP 주소에서 연결 허용(Allow connections from any IP address)"을 선택 해제하여 모든 서비스(SSH, 웹 액세스, NFC/스토리지)를 특정 관리 IP로만 제한합니다.

VMware vSphere VCSA 호스트 기반 방화벽과 관련된 추가 정보.격리 대상이 되어야 할 VMWare vCenter와 관련된 관리 포트 목록.

Hyper-V 제로 트러스트 네트워크 아키텍처

vSphere와 마찬가지로 Hyper-V도 게스트 워크로드에서 관리 영역으로의 내부망 이동을 방지하기 위해 다양한 트래픽 유형의 엄격한 격리가 필요합니다.

• VLAN 망 분리: 호스트 관리, 실시간 마이그레이션(Live Migration), 클러스터 하트비트(CSV), 프로덕션 게스트 VM에 대해 각기 다른 VLAN을 사용하여 격리를 강제해야 합니다.

• 라우팅 불가(Non-Routable) 네트워크: 고대역폭의 민감한 스트림이 다른 세그먼트에서 가로채이지 않도록 실시간 마이그레이션 및 클러스터 공유 볼륨(CSV)용 트래픽은 라우팅할 수 없는 VLAN에 배치해야 합니다.

계층 3 및 4(Layer 3 and 4) 액세스 정책

관리 네트워크는 신뢰할 수 있고 강화된 출처에서만 접근할 수 있어야 합니다.

• PAW 전용 액세스: 일반 기업 LAN에서 관리 서브넷으로 향하는 모든 직접 라우팅 경로를 해체합니다. 액세스는 엄격하게 지정된 PAW 서브넷에서만 시작되어야 합니다.

• 인바운드(Ingress) 필터링 (관리 영역):

  • 허용(ALLOW): PAW 서브넷에서만 WinRM / PowerShell 원격 접속(TCP/5985 및 TCP/5986), RDP(TCP/3389), WMI/RPC(TCP/135 및 동적 RPC 포트)를 허용. Windows Admin Center를 사용하는 경우 게이트웨이에 대한 HTTPS(TCP/443)를 허용.

  • 차단(DENY): 자격 증명 탈취 및 내부망 이동을 방지하기 위해 신뢰할 수 없는 소스로부터의 SMB(TCP/445), RPC/WMI(TCP/135) 및 기타 모든 관리 트래픽을 명시적으로 차단합니다.

• 제한적인 아웃바운드(Egress) 정책: 네트워크 게이트웨이에서 아웃바운드 필터링을 강제합니다. C2 트래픽과 데이터 유출을 방지하기 위해, 특정되고 검증된 업데이트 서버(예: 내부 WSUS), 승인된 AD 도메인 컨트롤러, KMS(Key Management Servers)를 제외하고 Hyper-V 호스트에서 외부로 나가는 모든 인터넷 액세스를 차단합니다.

호스트 기반 방화벽 적용

고급 보안이 포함된 Windows Defender 방화벽(WFAS)을 사용하여 호스트 수준에서 심층 방어 태세를 갖추십시오.

• 범위 제한(Scope Restriction): 활성화된 모든 관리 규칙(예: 파일 및 프린터 공유, WMI, PowerShell 원격 접속)에 대해 원격 IP 주소 범위를 "다음 IP 주소(These IP addresses)"로 수정하고 PAW 및 관리 서버 서브넷만 입력합니다.

• 관리 로깅(Management Logging): Windows 방화벽 프로필에서 '삭제된 패킷(Dropped Packets)'에 대한 로깅을 활성화합니다. 이를 통해 SIEM은 "거부된" 연결 시도를 수집할 수 있으며, 이는 내부 정찰이나 무단 액세스 시도의 신뢰도 높은 지표로 활용됩니다.

Hyper-V 호스트 기반 방화벽과 관련된 추가 정보.Hyper-V 보안 강화와 관련된 추가 정보.

일반적인 가상화 인프라 강화

VMware vSphere의 관리 인터페이스를 보호하려면 VMKernel 네트워크 인터페이스 카드(NIC)가 호스트에서 실행되는 가상 머신에 할당된 가상 네트워크와 동일한 네트워크에 바인딩되지 않아야 합니다. 또한 ESXi 서버를 잠금 모드(lockdown mode)로 구성하여 vCenter 서버에서만 콘솔에 접근하도록 허용할 수 있습니다. 잠금 모드(lockdown mode)와 관련된 추가 정보.

SSH 프로토콜(TCP/22)은 관리 및 문제 해결을 위해 물리적 가상화 서버나 어플라이언스(vCenter)에 접근하는 일반적인 채널을 제공합니다. 위협 행위자는 파괴적인 공격을 수행하기 위해 가상화 인프라에 직접 접근할 때 SSH를 자주 악용합니다. 관리 인터페이스에 대한 접근을 안전한 격리 영역(enclave)으로 제한하는 것 외에도, 가상화 인프라에 대한 SSH 접근은 비활성화되어야 하며 특정 사용 사례에 대해서만 예외적으로 활성화해야 합니다. SSH가 필요한 경우 네트워크 ACL을 사용하여 연결이 시작될 수 있는 위치를 엄격히 제한해야 합니다.

가상화 인프라와 관련된 관리 인터페이스에 접근할 때도 신원 기반 망 분리(Identity segmentation)가 구성되어야 합니다. Active Directory 인증이 물리적 가상화 스택에 대한 직접적인 통합 액세스를 제공하는 경우, (가상화 인프라를 관리할 권한이 있는) 유효한 Active Directory 계정을 탈취한 위협 행위자는 해당 계정을 사용하여 가상화된 시스템에 직접 접근해 데이터를 훔치거나 파괴적인 행위를 수행할 수 있습니다.

가상화된 인프라에 대한 인증은 강력한 비밀번호로 구성되고 환경 내의 다른 액세스 용도로 공동 사용되지 않는 전용 고유 계정에 의존해야 합니다. 또한 가상화 인프라와 관련된 관리 인터페이스 접근은 주요 인프라 구성 요소에 접근하는 데 사용되는 비밀번호의 저장 및 캐싱을 방지하는 격리된 PAW(권한 있는 액세스 워크스테이션)에서만 시작되어야 합니다.

오프라인 자격 증명 탈취 및 유출로부터 하이퍼바이저 보호

조직은 하이퍼바이저 계층에서 발생하는 오프라인 자격 증명 탈취 위험을 완화하고 보안 격차를 체계적으로 해결하기 위해 선제적이고 심층적인 방어 형태의 기술적 강화 전략을 구현해야 합니다. 이 공격의 핵심은 "디스크 스왑(Disk Swap)"으로 알려진 오프라인 자격 증명 탈취 기법입니다. 공격자가 하이퍼바이저(vSphere 또는 Hyper-V)에 대한 관리 제어권을 확보하면 다음 단계를 수행합니다.

• 표적 식별: 도메인 컨트롤러(DC)와 같은 중요한 가상화 자산을 식별합니다.

• 오프라인 조작: 대상 VM의 전원을 끄고 가상 디스크 파일(예: VMware의 .vmdk 또는 Hyper-V의 .vhd/.vhdx)을 분리(detach)합니다.

• NTDS.dit 추출: 분리한 디스크를 공격자의 통제하에 있는 임시 또는 방치된("고아", orphaned) VM에 연결합니다. 이 모니터링되지 않는 가상 머신에서 Active Directory 데이터베이스인 NTDS.dit 파일을 복사합니다.

• 은밀한 복구: 디스크를 원래 DC에 다시 연결하고 VM의 전원을 다시 켜서 게스트 운영 체제 내에 디지털 포렌식 증거를 최소한으로만 남깁니다.

강화 및 완화 지침

이러한 로직을 방어하기 위해 조직은 암호화 격리 및 엄격한 수명 주기 관리에 중점을 둔 심층 방어 전략을 구현해야 합니다.

• 가상 머신 암호화: 모든 Tier 0 가상화 자산(예: 도메인 컨트롤러, PKI, 백업 서버)을 암호화해야 합니다. 암호화는 가상 디스크 파일을 도난당하거나 분리하더라도 특정 키에 대한 액세스 없이는 읽을 수 없도록 보장합니다.

• 엄격한 폐기 프로세스: 전원이 꺼져 있거나 방치된("고아") 가상 머신을 데이터스토어에 남겨두지 마십시오. 이러한 "유령(ghost)" VM은 공격자에게 이상적인 임시 작업(staging) 환경입니다. 자산을 인벤토리에서 단순히 제거하는 대신 가상 디스크를 완전히 삭제하여 공식적으로 폐기하십시오.

• 하이퍼바이저 계정 강화: 기본 관리자 계정(예: ESXi의 root 또는 Hyper-V 호스트의 로컬 Administrator)을 비활성화하거나 엄격히 제한하십시오. 중앙 관리 영역 외부에서 직접적인 호스트 수준 변경을 방지하기 위해 가능한 경우 잠금 모드(Lockdown Mode)(VMware ESXi 기능)를 강제 적용하십시오.

• 원격 감사 로깅: 모든 하이퍼바이저 수준의 감사 로그(예: hostd.log, vpxa.log 또는 Hyper-V의 Windows 이벤트 로그)를 활성화하고 중앙 집중식 SIEM으로 전달하십시오.

백업 보호

보안 조치는 프로덕션 환경과 백업 환경을 모두 포괄해야 합니다. 프로덕션 영역에 대한 공격은 종종 백업 무결성 훼손 시도와 동시에 이루어져 운영 연속성의 완전한 상실을 초래합니다. 가상 디스크 파일(VMware의 VMDK 및 Hyper-V의 VHD/VHDX)은 오프라인 데이터 탈취 및 직접적인 조작을 노리는 고가치 표적입니다.

강화 및 완화 지침 

오프라인 탈취 및 백업 조작의 위험을 완화하기 위해 조직은 가상 디스크의 전체 수명 주기에 걸쳐 "기본 암호화(Default Encrypted)" 정책을 구현해야 합니다.

• 모든 Tier-0 자산에 대한 저장 시(At-Rest) 암호화: 모든 핵심 인프라(예: 도메인 컨트롤러, 인증 기관[CA])에 대해 vSphere VM 암호화 또는 Hyper-V 보호된 VM(Shielded VMs)을 구현하십시오. 이를 통해 원본 VMDK 또는 VHDX 파일이 암호화되어 보호되며, 권한이 없는 자가 디스크를 분리하거나 마운트하더라도 읽을 수 없게 됩니다.

• 암호화된 백업 저장소: 별도의 강화된 키 관리 시스템(KMS)에 저장된 고유 키를 사용하여 저장된 백업 데이터(data at rest)를 암호화하도록 백업 애플리케이션이 구성되어 있는지 확인하십시오. 이는 백업 스토리지 자체가 손상되더라도 백업 파일의 "직접적인 조작"을 방지합니다.

• 스토리지 및 백업의 네트워크 망 분리: 스토리지 관리 네트워크와 백업 인프라를 전용 비라우팅(non-routable) VLAN으로 격리하십시오. 백업 콘솔 및 저장소에 대한 액세스는 피싱에 강한 다중 인증(MFA)을 요구해야 하며, 지정된 PAW(권한 있는 액세스 워크스테이션)에서만 시작되어야 합니다.

• 불변성 및 에어갭(Immutability and Air-Gapping): 불변 백업 저장소(Immutable Backup Repositories)를 사용하여 백업이 한 번 기록되면, 손상된 관리자 계정을 포함한 어떠한 사용자도 정해진 기간 동안 해당 데이터를 수정하거나 삭제할 수 없도록 하십시오. 이는 랜섬웨어 공격이나 의도적인 데이터 파괴 행위 발생 시 확실한 복구 시점(recovery point)을 제공합니다.

가상화 인프라 모니터링을 위한 탐지 기회

DDoS 공격 방어

분산 서비스 거부(DDoS) 공격은 클라우드 기반 리소스 및 서비스의 가용성에 영향을 미칠 수 있는 파괴적인 공격의 대표적인 사례입니다. 현대화된 DDoS 보호 체계는 필터링 및 속도 제한(rate-limiting)과 같은 과거의 개념을 넘어, 공격자의 역량에 맞서 확장 가능한 클라우드 네이티브 기능을 포함해야 합니다.

클라우드 경계 강화

현대 인프라의 하이브리드 운영 모델에서 클라우드 콘솔과 SaaS 플랫폼은 자격 증명 수집(credential harvesting) 및 데이터 유출을 노리는 공격자들의 핵심 고가치 표적(high-value targets)입니다. 이러한 위험을 최소화하려면 무단 액세스를 방지하는 강력한 신원 제어(identity controls)와, 리소스 및 데이터 접근을 보호하고 공격 표면을 최소화하는 플랫폼별 가이드라인을 결합한 이중 방어 전략이 필요합니다.

강력한 인증 강제

강력한 인증은 클라우드 복원력을 확보하고 클라우드 인프라를 안전하게 보호하기 위한 가장 기본적인 요구 사항입니다. 온프레미스 환경과 마찬가지로 권한 있는 자격 증명, 토큰 또는 세션이 손상되면 조직에 치명적인 영향을 미치는 의도치 않은 결과를 초래할 수 있습니다. 이러한 만연한 위험을 완화하기 위해 조직은 모든 외부 노출 클라우드 서비스, 관리 포털 및 SaaS 플랫폼에 대해 무조건적으로 강력한 인증을 강제해야 합니다.

조직은 권한이 부여된 역할 및 기능을 수행하는 계정에 대해 FIDO2(WebAuthn) 하드웨어 토큰이나 패스키와 같은 피싱에 강한(phishing-resistant) 인증기, 또는 인증서 기반 인증의 사용을 강제해야 합니다. 일반 사용자의 경우, 인증 소프트웨어(Microsoft Authenticator 또는 Okta Verify)가 Windows Hello for Business 또는 TouchID와 같은 기기 결합형(device-bound) 요소를 활용하도록 구성되어야 합니다.

또한 조직은 인증 트랜잭션의 일부로 '인증기(신원 + 기기 증명)' 개념을 활용해야 합니다. 여기에는 관리되고 규정을 준수하며 정상적인 상태(healthy)인 기기에서만 권한 있는 액세스가 시작되도록 제한하는 '검증된 기기(validated-device)' 액세스 정책을 적용하는 것이 포함됩니다. 개방된 인터넷에서 클라우드 리소스로의 액세스를 제한하려면 신뢰할 수 있는 네트워크 영역(Trusted network zones)을 정의해야 합니다. VPN이나 TOR와 같은 익명화 서비스에서의 인증을 제한하려면 신뢰할 수 없는 네트워크 영역(Untrusted network zones)을 정의해야 합니다. 가능한 경우 기기 결합형 세션 자격 증명을 사용하면 세션 토큰 탈취 위험을 완화할 수 있습니다.

권한 있는 작업을 위한 신원 및 기기 분리 

권한 있는 액세스 워크스테이션(PAW, Privileged Access Workstations)을 도입하는 것은 관리자 세션을 손상시키려는 위협 행위자에 맞서는 중요한 방어 수단입니다. PAW는 민감한 관리 작업에만 독점적으로 사용되는, 고도로 강화된 전용 하드웨어 엔드포인트입니다.

관리자는 일상적인 업무에는 권한이 없는(non-privileged) 일반 계정을 활용하고, 권한이 필요한 작업은 강화된 PAW 또는 명시적으로 정의된 IP 대역에서만 허용되도록 제한해야 합니다. 통신 환경과 관리 환경 사이의 이러한 "에어갭(air-gap, 논리적 분리)"은 공격자가 하이브리드 환경 내에서 손상된 일반 신원을 이용해 권한이 있는 컨텍스트로 내부망 이동(lateral movement)을 하는 것을 차단합니다.

적시(JIT) 액세스 및 최소 권한의 원칙 

하이브리드 환경에서 정적이고 상시 유지되는(standing) 권한은 심각한 보안 위험을 초래합니다. 제로 트러스트(Zero Trust) 클라우드 아키텍처에 따라, 관리자 권한은 완전히 일시적(ephemeral)이어야 합니다. 적시(Just-In-Time, JIT) 및 최소 권한(Just-Enough-Access, JEA) 메커니즘을 구현하면, 관리자가 특정 단일 작업을 수행하는 데 필요한 세분화된 권한만 부여받고 극히 제한된 기간 동안만 사용할 수 있으며, 이후에는 권한이 자동으로 취소됩니다. 이 아키텍처 모델은 조직이 권한이 필요한 작업에 대한 승인 절차를 강제하고, 모니터링을 강화하며, 특정 세션 내에서 수행된 모든 권한 작업에 대해 상세한 가시성을 확보할 수 있는 능력을 제공합니다.

비인간 신원 보안

조직은 사전 정의된 주기에 따라 API 키, 인증서, 서비스 계정 시크릿(secrets), 토큰 및 세션을 교체(rotate)하는 프로세스를 포함한 신원 거버넌스(identity governance) 관행을 구현해야 합니다. 자율적인 결과물과 연관된 AI 에이전트 또는 신원은 엄격하게 제한된 권한과 관련 모니터링 체계로 구성되어야 합니다. 권한이 없는 사용자는 조직의 승인 없이 타사 애플리케이션 통합을 승인하거나 API 키를 생성하지 못하도록 제한되어야 합니다.

모든 클라우드 및 SaaS 환경 전반에 걸쳐 하드코딩된 시크릿 및 민감한 자격 증명을 식별하고 조치하기 위해 지속적인 스캐닝을 수행해야 합니다.

스토리지 인프라 보안 및 불변 백업 

갈취(extortion) 목적이든 사보타주(sabotage) 목적이든, 파괴적인 사이버 공격의 전략적 목표는 데이터 복구를 불가능하게 만들어 복원 및 재구축 작업을 지연시키는 것입니다. 현대의 공격자들은 파괴적인 이벤트의 일환으로 백업 영역을 체계적으로 표적으로 삼습니다. 백업 데이터가 변조 가능(mutable)하거나 주 환경(primary environment)과 동일한 신원 관리 체계를 공유하는 경우, 공격자는 백업을 삭제하거나 암호화하여 단순한 사고를 길고 혼란스러운 복구 훈련으로 변질시킬 수 있습니다.

현대의 백업 이중화는 다양한 미디어에 걸쳐 데이터 복사본을 여러 개 보관하는 것을 포함해야 하지만, 논리적 액세스 권한이 하나로 통합되어 있다면 지리적 분리(geographic separation)라는 방어 전략은 쉽게 무력화될 수 있습니다. 파괴적인 공격에 대한 복원력을 보장하려면, 보조 복구 환경은 주권 클라우드 테넌트(sovereign cloud tenant) 또는 격리된 구독(isolated subscription) 내에 존재해야 합니다. 이 환경은 프로덕션 환경과 어떠한 공통점도 공유하지 않는 별도의 자격 증명과 관리자 페르소나를 사용하는 독립적인 ID 및 액세스 관리(IAM) 체계에 의해 통제되어야 합니다.

격리된 환경 내의 백업은 불변 스토리지 아키텍처(immutable storage architectures)를 기반으로 구축되어야 합니다. 하드웨어 검증 방식의 WORM(Write-Once, Read-Many) 기술을 활용함으로써, 복구 영역은 데이터 무결성을 수학적으로 보장합니다. 한 번 기록된(committed) 데이터는 보존 기간(retention period)이 만료될 때까지 루트(root) 또는 전역 관리자 권한(global administrative privileges)을 가진 계정이라도 수정, 암호화 또는 삭제할 수 없습니다. 이는 주 환경(primary environment)의 잠재적인 보안 위험과 관계없이 정상 작동이 확인된 복구 시점(known-good recovery point)에 항상 접근할 수 있도록 보장하는 궁극적인 "안전 장치(fail-safe)"를 생성합니다.

일반적인 클라우드 기반 인프라와 관련된 추가적인 심층 방어(defense-in-depth) 보안 아키텍처 통제 항목은 표 9에 포함되어 있습니다.

클라우드 인프라 및 리소스 보호를 위한 탐지 기회

엔드포인트 및 모바일 기기 관리(MDM) 플랫폼 보호

엔드포인트 및 모바일 기기 관리(MDM) 플랫폼을 보호하는 것은 비즈니스 운영을 지원하는 기기들의 보안과 가용성을 보장하는 데 매우 중요합니다. 와이퍼(wiper) 및 파괴적 성격의 공격 맥락에서 이러한 플랫폼은 위협 행위자가 조직의 자체 인프라를 조직 스스로를 공격하는 데 사용하기 위해 노릴 수 있는 "왕국의 열쇠(keys to the kingdom)"를 의미합니다.

전력 승수(Force Multiplier): MDM 및 엔드포인트 관리 도구는 등록되고 관리되는 기기에 구성 및 스크립트를 배포할 수 있는 고유한 기능을 가지고 있습니다. 이 도구가 손상되면, 위협 행위자는 이러한 합법적인 관리 플랫폼을 사용하여 와이퍼 악성코드를 배포하거나 전체 엔터프라이즈 환경에 동시에 원격 데이터 삭제 명령을 실행하여 단 몇 분 만에 시스템을 파괴할 수 있습니다.

복호화를 통해 데이터를 복구할 수 있는 랜섬웨어와 달리, 와이퍼 공격은 마스터 부트 레코드(MBR), GUID 파티션 테이블(GPT), 마스터 파일 테이블(MFT)을 영구적으로 파괴하거나 파일 시스템을 덮어써서 엔드포인트 기기에 접근할 수 없게 만드는 것을 목표로 합니다.

선제적 시스템 강화

관리 제어 영역(management plane)을 보호하기 위해 강력한 신원 및 네트워크 제어를 강제하면, 공격자가 엔드포인트 및 MDM 플랫폼에 접근하여 의도된 기능(예: 와이퍼 스크립트 배포, "원격 지우기(Remote Wipe)" 또는 "공장 초기화(Factory Reset)" 명령 실행)을 남용하는 것을 방지할 수 있습니다.

• 권한 있는 역할과 기능이 할당된 신원에 대해 강력한 인증(예: FIDO2를 포함하여 피싱에 강한 다중 인증[MFA])을 강제합니다.

• 토큰 재전송 공격(token replay attacks)을 방지하기 위해 세션 수명, 유휴 세션 시간 초과를 강제하고 기기 결합형(device-bound) 세션 보호 기능을 활용합니다.

• 특정 작업을 승인하기 위해 액세스 정책 및 다중 관리자 승인(multi-admin approval)을 요구합니다.

• 오래 지속되는 관리자 권한을 줄이고, 권한 있는 역할 및 작업에 대해 JIT(Just-in-Time) 또는 JEA(Just-Enough-Access) 액세스 모델로 마이그레이션합니다.

• Microsoft Intune의 경우, 역할 기반 액세스 제어(RBAC)와 범위 태그(scope tags)를 조합하여 폭발 반경(blast radius)을 줄이고, 손상된 권한 있는 신원이 광범위한 관리 대상 기기/엔드포인트에 영향을 미치는 데 악용될 위험을 최소화합니다.

• "원격 작업/지우기/삭제(Remote tasks/wipe/erase)" 권한이 포함된 관리자 역할을 감사하고, 이러한 이벤트가 중앙 집중식 SIEM으로 전달되도록 합니다. 또한 비즈니스 운영에 필요한 최소한의 관리자만 이러한 작업을 수행할 수 있도록 범위를 줄입니다.

• 최소 권한의 원칙에 따라 API 토큰 권한 범위를 줄입니다. 일정 기간 활동이 없으면 토큰을 제거하거나 만료시킵니다. 정기적으로 토큰을 교체(rotate)합니다.

• 클라우드 호스팅 MDM 플랫폼의 경우, 액세스 정책을 활용하여 네트워크 및 위치 기반 화이트리스트(allow listing)를 강제합니다. 로컬/온프레미스 MDM 서버의 경우, 방화벽을 활용하여 MDM 인프라(관리 제어 영역)에 대한 액세스를 제한합니다.

• 지원되는 경우, 특정 임계값 내에서 대규모 기기 삭제를 방지하도록 데이터 삭제 보호(wipe protection) 기능을 구성합니다. Omnissa Workspace ONE 플랫폼 내에서 이러한 구성의 예시는 여기에서 확인할 수 있습니다.

• MDM 플랫폼을 통해 배포된 기존 스크립트 및 구성 프로필을 검토하여 하드코딩된 일반 텍스트 비밀번호, API 키 또는 기타 민감한 시크릿(secrets)을 식별하고 조치합니다.

엔드포인트 및 모바일 기기 관리 플랫폼 보호를 위한 탐지 기회

3. 온프레미스 내부망 이동 방어

엔드포인트 강화

Windows 방화벽 구성

온프레미스 인프라에 대한 초기 침투(initial access) 권한을 확보하면, 위협 행위자들은 접근 범위와 지속성(persistence)을 더욱 확장하기 위해 내부망 이동(lateral movement)을 수행합니다. 일반적인 내부망 이동 기법을 이용한 Windows 엔드포인트 접근을 방어하기 위해, 환경 내 엔드포인트 간에 허용되는 통신 범위를 제한하도록 Windows 방화벽 정책을 구성할 수 있습니다. Windows 방화벽 정책은 로컬에서 강제하거나 그룹 정책 개체(GPO) 구성의 일부로 중앙에서 강제할 수 있습니다. 최소한 워크스테이션 간, 그리고 워크스테이션과 비도메인 컨트롤러(non-domain controllers) 및 비파일 서버(non-file servers) 간에 차단해야 하는 내부망 이동에 자주 악용되는 공통 포트 및 프로토콜은 다음과 같습니다.

• SMB (TCP/445, TCP/135, TCP/139)

• 원격 데스크톱 프로토콜 (RDP, TCP/3389)

• Windows 원격 관리 (WinRM) / 원격 PowerShell (TCP/80, TCP/5985, TCP/5986)

• WMI (Windows Management Instrumentation) (DCOM을 통해 할당된 동적 포트 범위)

그림 5: Windows 방화벽 규칙 생성을 위한 GPO 경로

시스템을 신속하게 격리하고 차단하기 위해, Windows 방화벽의 중앙 집중식 설정인 '모든 연결 차단(Block all connections)'(그림 8)을 사용하면 해당 시스템으로 들어오는 모든 인바운드 연결이 수립되는 것을 방지할 수 있습니다. 이 설정은 워크스테이션과 노트북에는 즉시 적용할 수 있지만, 서버에 적용할 경우 운영에 지장을 줄 가능성이 큽니다. 다만, 환경 내에서 위협 행위자가 활발하게 내부망 이동(lateral pivoting)을 시도하고 있다는 증거가 있다면, 신속한 격리를 위해 필요한 조치가 될 수 있습니다.

NTLM 인증 구성

위협 행위자는 아웃바운드 SMB 또는 WebDAV 통신을 이용해 자격 증명(Windows NTLMv1 해시 포함)을 탈취하려는 시도를 자주 수행합니다. 조직은 Windows 기반 엔드포인트의 NTLM 설정을 검토하고 NTLMv1 인증 요청을 강화, 비활성화 또는 제한하기 위해 노력해야 합니다.

원격 서버에 대한 NTLM 인증을 완전히 제한하기 위해 다음 GPO 설정을 활용할 수 있습니다.

• 컴퓨터 구성(Computer Configuration) > Windows 설정(Windows Settings) > 보안 설정(Security Settings) > 로컬 정책(Local Policies) > 보안 옵션(Security Options) > 네트워크 보안: NTLM 제한: 원격 서버로 보내는 NTLM 트래픽(Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers)

  • 모두 허용 (Allow all)

  • 모두 감사 (Audit all)

  • 모두 거부 (Deny all)

참고: "모두 거부"를 선택하면 클라이언트 컴퓨터는 원격 서버에서 NTLM 인증을 사용하여 (자격 증명을 보내어) 인증할 수 없습니다. "모두 거부"로 설정하기 전에 조직은 GPO 설정을 "모두 감사"로 구성해야 합니다. 이 구성을 사용하면 엔드포인트의 운영 이벤트 로그(Applications and Services Log\Microsoft\Windows\NTLM)에 감사 및 차단 이벤트가 기록됩니다.

기록된 NTLM 인증 이벤트 중 반드시 필요한 항목이 있다면, 조직은 "네트워크 보안: NTLM 제한: NTLM 인증을 위해 원격 서버 예외 추가(Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication)" 설정을 구성하여 NTLM 인증을 사용해야 하는 원격 서버 목록을 정의할 수 있습니다.

SMB, WMI 및 NTLM 통신 모니터링을 위한 탐지 기회

원격 데스크톱 프로토콜(RDP) 보안 강화

원격 데스크톱 프로토콜(RDP)은 위협 행위자가 시스템에 원격으로 접속하고, 경계망에서 더 넓은 범위의 내부 시스템으로 내부망 이동(lateral move)을 수행하며, 악의적인 활동(데이터 탈취 또는 랜섬웨어 배포 등)을 벌이는 데 흔히 사용하는 방법입니다. 인터넷에 RDP가 열려 있는 외부 노출 시스템은 매우 높은 위험을 초래합니다. 위협 행위자는 이 벡터를 악용하여 조직에 초기 침투(initial access)한 권한을 확보한 후, 조직 내부로 수평 이동하며 공격 목표를 달성할 수 있습니다.

선제적으로, 조직은 공인 IP 주소 범위를 스캔하여 인터넷에 RDP(TCP/3389) 및 기타 프로토콜(SMB – TCP/445)이 열려 있는 시스템을 식별해야 합니다. 최소한 RDP와 SMB는 인터넷과의 인바운드 및 아웃바운드 통신에 직접 노출되지 않아야 합니다. 운영상의 목적으로 필요한 경우, 이러한 프로토콜을 사용하는 시스템과 인터페이스할 수 있는 소스 IP 주소를 제한하는 명시적인 통제 항목을 구현해야 합니다. 또한 다음과 같은 보안 강화 권고 사항도 적용해야 합니다.

다중 인증 강제

운영상의 이유로 외부 노출 RDP를 반드시 사용해야 하는 경우, 이 방식을 통해 연결할 때 다중 인증을 강제해야 합니다. 이는 제3자 다중 인증 기술을 통합하거나, 원격 인증 다이얼인 사용자 서비스(RADIUS)를 사용하는 원격 데스크톱 게이트웨이 및 Azure 다중 인증 서버를 활용하여 달성할 수 있습니다.

네트워크 수준 인증(NLA) 활용

외부 노출 RDP 서버의 경우, 네트워크 수준 인증(NLA)은 연결이 수립되기 전에 추가적인 사전 인증 계층을 제공합니다. NLA는 인터넷에 노출된 RDP 서버를 표적으로 자주 발생하는 무차별 대입 공격(brute-force attacks)을 방어하는 데에도 유용합니다.

NLA는 사용자 인터페이스(UI)(그림 10) 또는 그룹 정책(GPO)(그림 11)을 통해 구성할 수 있습니다.

RDP에 NLA를 활용할 때 유의해야 할 몇 가지 사항은 다음과 같습니다.

• 원격 데스크톱 클라이언트 v7.0 이상을 사용해야 합니다.

• NLA는 인증 요청을 보내는 시스템에서 CredSSP를 사용하여 인증을 전달합니다. CredSSP는 인증을 시도하는 시스템의 LSA(Local Security Authority) 메모리에 자격 증명을 저장하며, 사용자가 시스템에서 로그오프한 후에도 이 자격 증명이 메모리에 남아 있을 수 있습니다. 이는 소스 시스템의 메모리에 있는 자격 증명이 노출될 위험이 있음을 의미합니다.

• RDP 서버에서 NLA가 강제될 때, RDP를 사용하여 원격 액세스가 허용된 사용자에게는 '네트워크에서 이 컴퓨터 액세스(Access this computer from the network)' 권한이 할당되어야 합니다. 이 권한은 내부망 이동(lateral movement) 기법을 방어하기 위해 사용자 계정에 대해 명시적으로 거부되는 경우가 많습니다.

인터넷 노출 시스템에서 관리자 계정의 RDP 사용 제한 

외부 노출 RDP 서버의 경우, 높은 권한을 가진 도메인 및 로컬 관리자 계정이 RDP를 사용하여 외부 노출 시스템에 인증하는 것을 허용해서는 안 됩니다(그림 12).

이는 그룹 정책을 통해 다음 경로에서 구성할 수 있습니다.

• 컴퓨터 구성(Computer Configuration) > 정책(Policies) > Windows 설정(Windows Settings) > 보안 설정(Security Settings) > 로컬 정책(Local Policies) > 사용자 권한 할당(User Rights Assignment) > 터미널 서비스를 통한 로그온 거부(Deny log on through Terminal Services)

관리/숨김 공유 비활성화

내부망 이동(lateral movement)을 수행하기 위해 위협 행위자는 명시적으로 드라이브 문자에 매핑되지 않은 관리 공유(administrative shares) 또는 숨김 네트워크 공유(hidden network shares)를 찾아내어, 이를 환경 전체의 엔드포인트에 원격으로 연결하는 데 악용할 수 있습니다. 조직은 예방적 조치나 신속한 격리 조치의 일환으로 엔드포인트에서 이러한 기본 관리 또는 숨김 공유에 접근하지 못하도록 빠르게 비활성화해야 할 수 있습니다. 이는 레지스트리 수정, 서비스 중지, 또는 MSS (레거시) 그룹 정책 템플릿을 사용하여 수행할 수 있습니다.

엔드포인트에서 일반적으로 사용되는 관리 및 숨김 공유는 다음과 같습니다.

• ADMIN$
• C$
• D$
• IPC$

레지스트리 방식

레지스트리를 사용하여 엔드포인트의 관리 및 숨김 공유를 비활성화할 수 있습니다(그림 13 및 그림 14).

워크스테이션

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
DWORD Name = "AutoShareWks"
Value = "0"

그림 13: 워크스테이션에서 관리 공유를 비활성화하기 위한 레지스트리 설정

서버

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
DWORD Name = "AutoShareServer"
Value = "0"

그림 14: 서버에서 관리 공유를 비활성화하는 레지스트리 값

서비스 방식 (Service Method)

엔드포인트에서 Server 서비스를 중지하면 해당 엔드포인트에 호스팅된 모든 공유에 대한 액세스 기능이 비활성화됩니다(그림 15).

그룹 정책 방식

MSS (레거시) 그룹 정책 템플릿을 사용하여 GPO 설정을 통해 서버 또는 워크스테이션의 관리 및 숨김 공유를 비활성화할 수 있습니다(그림 16).

• 컴퓨터 구성(Computer Configuration) > 정책(Policies) > 관리 템플릿(Administrative Templates) > MSS (Legacy) > MSS (AutoShareServer)

  • 비활성(Disabled)

• 컴퓨터 구성(Computer Configuration) > 정책(Policies) > 관리 템플릿(Administrative Templates) > MSS (Legacy) > MSS (AutoShareWks)

  • 비활성(Disabled)

관리 또는 숨김 공유 액세스 모니터링을 위한 탐지 기회

Windows 원격 관리(WinRM) 보안 강화

위협 행위자는 Windows 원격 관리(WinRM)를 악용하여 환경 내에서 내부망 이동(lateral movement)을 수행할 수 있습니다. WinRM은 모든 Windows Server 운영 체제(Windows Server 2012 이상)에서 기본적으로 활성화되어 있으며, 모든 클라이언트 운영 체제(Windows 7 및 Windows 10)와 구형 서버 플랫폼(Windows Server 2008 R2)에서는 비활성화되어 있습니다.

PowerShell 원격 접속(PS remoting)은 WinRM 프로토콜을 기반으로 구축된 Windows 고유의 원격 명령 실행 기능입니다.

WinRM이 비활성화된 Windows 클라이언트(비서버용) 운영 체제 플랫폼의 상태는 다음과 같습니다:

• WinRM 리스너(listener)가 구성되지 않음

• Windows 방화벽 예외(exception)가 구성되지 않음

기본적으로 WinRM은 TCP/5985 및 TCP/5986 포트를 사용합니다. 이 포트들은 Windows 방화벽을 사용해 비활성화하거나, 특정 IP 주소 하위 집합만 WinRM을 통해 엔드포인트에 연결할 수 있도록 권한을 부여하도록 구성할 수 있습니다.

WinRM 및 PowerShell 원격 접속은 PowerShell 명령어(그림 17) 또는 특정 GPO 설정을 사용하여 엔드포인트에서 명시적으로 비활성화할 수 있습니다.

PowerShell

Disable-PSRemoting -Force

그림 17: 엔드포인트에서 WinRM/PowerShell 원격 접속을 비활성화하는 PowerShell 명령어

참고: Disable-PSRemoting -Force 명령어를 실행하더라도 로컬 사용자가 로컬 컴퓨터에서 PowerShell 세션을 생성하거나, 원격 컴퓨터를 대상으로 하는 세션을 생성하는 것을 차단하지는 않습니다.

해당 명령어를 실행하면 그림 18에 기록된 메시지가 표시됩니다. 이러한 단계는 추가적인 보안 강화를 제공하며, Disable-PSRemoting -Force 명령을 실행한 후에는 대상 엔드포인트를 목적으로 하는 PowerShell 세션 연결이 성공하지 않게 됩니다.

PowerShell을 통해 WinRM을 비활성화하는 추가 단계(그림 19 - 그림 22)를 강제 적용하는 방법은 다음과 같습니다.

1. WinRM 서비스를 중지하고 비활성화합니다.
   
   

   Stop-Service WinRM -PassThruSet-Service WinRM -StartupType Disabled

   림 19: WinRM 서비스를 중지하고 비활성화하는 PowerShell 명령어

   
   
2. 모든 IP 주소에서 요청을 수락하는 리스너(Listener)를 비활성화합니다.
   
   

   dir wsman:\localhost\listener
   
   Remove-Item -Path WSMan:\Localhost\listener\<Listener name>

   그림 20: WSMan 리스너를 삭제하는 PowerShell 명령어

   
   
3. WS-Management 통신을 위한 방화벽 예외 규칙을 비활성화합니다.
   
   

   Set-NetFirewallRule -DisplayName 'Windows Remote Management (HTTP-In)' -Enabled False 

   그림 21: WinRM용 방화벽 예외를 비활성화하는 PowerShell 명령어

   
   
4. LocalAccountTokenFilterPolicy 값을 0으로 복구합니다. 이 설정은 컴퓨터의 Administrators 그룹 구성원에 대한 원격 액세스를 제한합니다.
   
   

   Set-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system -Name LocalAccountTokenFilterPolicy -Value 0

   그림 22: LocalAccountTokenFilterPolicy 레지스트리 키를 구성하는 PowerShell 명령어

그룹 정책 (Group Policy)

• 컴퓨터 구성(Computer Configuration) > 정책(Policies) > 관리 템플릿(Administrative Templates) > Windows 구성 요소(Windows Components) > Windows 원격 관리(Windows Remote Management, WinRM) > WinRM 서비스(WinRM Service) > WinRM을 통한 원격 서버 관리 허용(Allow remote server management through WinRM)

  • 비활성(Disabled)

이 설정을 비활성으로 구성하면, WinRM 리스너가 구성되어 있는지 여부와 상관없이 WinRM 서비스가 원격 컴퓨터의 요청에 응답하지 않습니다.

• 컴퓨터 구성(Computer Configuration) > 정책(Policies) > 관리 템플릿(Administrative Templates) > Windows 구성 요소(Windows Components) > Windows 원격 셸(Windows Remote Shell) > 원격 셸 액세스 허용(Allow Remote Shell Access)

  • 비활성(Disabled)

이 정책 설정은 스크립트 및 명령 실행을 위해 지원되는 모든 셸에 대한 원격 액세스 구성을 관리합니다.

WinRM 사용 모니터링을 위한 탐지 기회

일반적인 내부망 이동 도구 및 기법 제한

표 17은 환경 내에서 내부망 이동(lateral movement)에 사용되는 일반적인 원격 접속 도구 및 기법에 대응하기 위해 활용할 수 있는 보안 구성들을 통합 요약하여 제공합니다.

일반적인 내부망 이동 도구 및 기법 모니터링을 위한 탐지 기회

추가적인 엔드포인트 강화 

엔드포인트에서 악성 바이너리, 멀웨어 및 랜섬웨어(encryptors)가 실행되는 것을 방지하기 위해 추가적인 보안 강화 기술과 통제 항목을 고려해야 합니다. Windows 기반 엔드포인트에 대해 고려할 수 있는 추가적인 보안 통제 예시는 다음과 같습니다.

Windows Defender 애플리케이션 제어

Windows Defender 애플리케이션 제어는 사용자가 엔드포인트에서 실행할 수 있는 애플리케이션과 파일을 통제하기 위한 잠금(lockdown) 및 제어 메커니즘을 제공하는 Active Directory 내의 기본 구성 설정 세트입니다. 이 기능을 사용하면 GPO 내에 다음과 같은 유형의 규칙을 구성할 수 있습니다.

• 게시자 규칙 (Publisher rules): 디지털 서명 및 기타 속성을 기반으로 파일 실행을 허용하거나 제한하는 데 활용할 수 있습니다.

• 경로 규칙 (Path rules): 특정 경로에 위치한 파일을 기반으로 파일 실행 또는 액세스를 허용하거나 제한하는 데 활용할 수 있습니다.

• 파일 해시 규칙 (File hash rules): 파일의 해시값을 기반으로 파일 실행을 허용하거나 제한하는 데 활용할 수 있습니다.

Windows Defender 애플리케이션 제어에 관련된 추가 정보를 확인할 수 있습니다.

Microsoft Defender 공격 표면 감소

Microsoft Defender 공격 표면 감소(ASR) 규칙은 다음과 같은 다양한 위협을 방어하는 데 도움이 될 수 있습니다.

• 파일을 다운로드하거나 실행하려는 실행 파일 및 스크립트를 시작하는 위협 행위자

• 난독화되거나 의심스러운 스크립트를 실행하는 위협 행위자

• LSASS(Local Security Authority Subsystem Service)와 상호 작용하는 자격 증명 탈취 도구를 실행하는 위협 행위자

• PsExec 또는 WMI 명령을 실행하는 위협 행위자

• 표준 활동의 일환으로 애플리케이션이 일반적으로 시작하지 않는 행동을 정규화하고 차단

• 이메일 클라이언트 및 웹 메일에서 실행 가능한 콘텐츠 차단 (피싱 방어)

ASR을 사용하려면 Windows E3 이상의 라이선스가 필요합니다. Windows E5 라이선스는 ASR에 대한 고급 관리 기능을 제공합니다.

Microsoft Defender 공격 표면 감소 기능과 관련된 추가 정보를 확인할 수 있습니다.

제어된 폴더 액세스

제어된 폴더 액세스(Controlled Folder Access)는 랜섬웨어에 의해 데이터가 암호화되는 것을 방지하는 데 도움을 줄 수 있습니다. Windows 10 버전 1709 이상 및 Windows Server 2019 이상부터 제어된 폴더 액세스가 Windows Defender 바이러스 백신 내에 (Windows Defender Exploit Guard의 일부로) 도입되었습니다.

제어된 폴더 액세스가 활성화되면, Windows Defender 바이러스 백신이 애플리케이션과 실행 파일을 평가하여 해당 애플리케이션이 악성인지 안전한지 판단합니다. 애플리케이션이 악성이거나 의심스러운 것으로 판단되면 보호된 폴더 내의 파일에 대한 변경 작업을 수행하지 못하도록 차단됩니다.

활성화된 제어된 폴더 액세스는 다음을 포함한 여러 시스템 폴더 및 기본 위치에 적용됩니다.

• 문서
  
  • C:\users\<username>\Documents
  • C:\users\Public\Documents
• 사진
  • C:\users\<username>\Pictures
  • C:\users\Public\Pictures
• 동영상
  • C:\users\<username>\Videos
  • C:\users\Public\Videos
• 음악
  
  • C:\users\<username>\Music
  • C:\users\Public\Music
• 바탕 화면
  • C:\users\<username>\Desktop
  • C:\users\Public\Desktop
• 즐겨찾기
  • C:\users\<username>\Favorites

Windows 보안 앱, 그룹 정책(GPO), PowerShell 또는 모바일 장치 관리(MDM) 구성 서비스 공급자(CSP)를 사용하여 추가 폴더를 구성할 수 있습니다. 또한, 보호된 폴더에 액세스할 수 있도록 애플리케이션을 허용 목록(allow-list)에 추가할 수도 있습니다.

참고: 제어된 폴더 액세스가 완벽하게 작동하려면 Windows Defender의 실시간 보호(Real Time Protection) 설정이 활성화되어 있어야 합니다.

제어된 폴더 액세스와 관련된 추가 정보를 확인할 수 있습니다.

변조 방지

위협 행위자는 종종 엔드포인트에서 보안 기능을 비활성화하려고 시도합니다. Windows(Microsoft Defender for Endpoint를 통해)나 제3자 AV/EDR 플랫폼에 내장된 변조 방지 기능은 위협 행위자가 보안 도구를 수정하거나 중지하는 것을 방지하는 데 도움을 줍니다. 조직은 엔드포인트에 배포된 보안 기술의 구성을 검토하고, 무단 수정을 방지하기 위해 변조 방지 기능이 활성화되어 있는지(또는 활성화할 수 있는지) 확인해야 합니다. 제품마다 제공하는 보호 수준이 다르기 때문에, 변조 방지 통제가 구현된 후에는 정상적으로 작동하는지 테스트하고 검증해야 합니다.

Microsoft Defender for Endpoint의 변조 방지와 관련된 추가 정보를 확인할 수 있습니다.

변조 방지 이벤트를 위한 탐지 기회

4. 자격 증명 노출 및 계정 보호

권한 있는 계정 및 그룹 식별

위협 행위자는 정찰(reconnaissance) 활동의 일환으로 권한 있는 계정(privileged accounts)을 식별하는 것을 우선시합니다. 이러한 계정이 식별되면, 위협 행위자는 내부망 이동(lateral movement), 지속성(persistence) 확보 및 공격 목표 달성을 위해 해당 계정의 자격 증명(credentials)을 탈취하려고 시도합니다.

조직은 Active Directory 내에서 높은 권한(elevated level of privilege)을 가진 계정 및 그룹의 범위를 선제적으로 파악하고 검토하는 데 집중해야 합니다. 높은 수준의 권한은 다음 기준에 따라 결정될 수 있습니다.

• 기본 도메인 및 Exchange 기반의 권한 있는 그룹에 구성원으로 할당된 계정 또는 중첩 그룹(nested groups) (그림 29)

• AdminSDHolder에 의해 보호되는 보안 그룹에 구성원으로 할당된 계정 또는 중첩 그룹

• 권한 있는 계정, 그룹 또는 엔드포인트가 포함된 조직 구성 단위(OU, Organizational Units)에 대한 권한이 할당된 계정 또는 그룹

• 도메인의 루트(root) 수준에서 직접, 또는 하위 개체로 권한이 상속되는 OU에 대해 특정 확장 권한(extended right permissions)이 할당된 계정 또는 그룹. (예시는 다음과 같습니다.)

  • DS-Replication-Get-Changes-All

  • Administer Exchange Information Store

  • View Exchange Information Store Status

  • Create-Inbound-Forest-Trust

  • Migrate-SID-History

  • Reanimate-Tombstones

  • View Exchange Information Store Status

  • User-Force-Change-Password

• GPO를 수정하거나 연결(linking)할 수 있는 권한이 할당된 계정 또는 그룹

• 도메인 컨트롤러(DC) 또는 티어 0(Tier 0) 엔드포인트에 명시적인 권한이 할당된 계정 또는 그룹

• 디렉터리 서비스 복제(directory service replication) 권한이 할당된 계정 또는 그룹

• 도메인 내의 모든 엔드포인트(또는 광범위한 중요 자산)에 대한 로컬 관리자 접근 권한(local administrative access)을 가진 계정 또는 그룹

기본 도메인 기반의 권한 있는 그룹에 속해 있거나 AdminSDHolder에 의해 보호되는 계정을 식별하기 위해 도메인 컨트롤러에서 다음 PowerShell cmdlet을 실행할 수 있습니다.

get-ADGroupMember -Identity "Domain Admins" -Recursive | export-csv -path <output directory>\DomainAdmins.csv -NoTypeInformation 

get-ADGroupMember -Identity "Enterprise Admins" -Recursive | export-csv -path <output directory>\EnterpriseAdmins.csv -NoTypeInformation 

get-ADGroupMember -Identity "Schema Admins" -Recursive | export-csv -path <output directory>\SchemaAdmins.csv -NoTypeInformation

get-ADGroupMember -Identity "Administrators" -Recursive | export-csv -path <output directory>\Administrators.csv -NoTypeInformation 

get-ADGroupMember -Identity "Account Operators" -Recursive | export-csv -path <output directory>\AccountOperators.csv -NoTypeInformation 

get-ADGroupMember -Identity "Backup Operators" -Recursive | export-csv -path <output directory>\BackupOperators.csv -NoTypeInformation 

get-ADGroupMember -Identity "Cert Publishers" -Recursive | export-csv -path <output directory>\CertPublishers.csv -NoTypeInformation 

get-ADGroupMember -Identity "Print Operators" -Recursive | export-csv -path <output directory>\PrintOperators.csv -NoTypeInformation 

get-ADGroupMember -Identity "Server Operators" -Recursive | export-csv -path <output directory>\ServerOperators.csv -NoTypeInformation 

get-ADGroupMember -Identity "DNSAdmins" -Recursive | export-csv -path <output directory>\DNSAdmins.csv -NoTypeInformation 

get-ADGroupMember -Identity "Group Policy Creator Owners" -Recursive | export-csv -path <output directory>\Group-Policy-Creator-Owners.csv -NoTypeInformation 

get-ADGroupMember -Identity "Exchange Trusted Subsystem" -Recursive | export-csv -path <output directory>\Exchange-Trusted-Subsystem.csv -NoTypeInformation

get-ADGroupMember -Identity "Exchange Windows Permissions" -Recursive | export-csv -path <output directory>\Exchange-Windows-Permissions.csv -NoTypeInformation 

get-ADGroupMember -Identity "Exchange Recipient Administrators" -Recursive | export-csv -path <output directory>\Exchange-Recipient-Admins.csv -NoTypeInformation 

get-ADUser -Filter {(AdminCount -eq 1) -And (Enabled -eq $True)} | Select-Object Name, DistinguishedName | export-csv -path <output directory>\AdminSDHolder_Enabled.csv

그림 29: 도메인 및 Exchange 기반의 권한 있는 계정을 식별하기 위한 명령어

추가 보안 그룹에 권한을 부여받은 권한 있는 계정(privileged accounts)은, 해당 계정이 로그온하거나 시스템에 원격으로 접속할 권한을 가진 엔드포인트를 기반으로 위협 행위자에게 도메인 관리 수준의 권한으로 이어지는 잠재적 경로를 제공할 수 있습니다.

이상적으로는 도메인 내에서 매우 소수의 계정에만 높은 권한의 액세스가 부여되어야 합니다. 높은 권한을 가진 계정은 다음과 같은 용도로 사용되어서는 안 됩니다. 일상적인 업무용으로 사용, 워크스테이션, 노트북 또는 일반 서버에 대화형 또는 원격 로그온을 위해 사용, 혹은 도메인 컨트롤러(티어 0) 자산이 아닌 환경에서 기능을 수행하기 위해 사용. 권한 있는 계정의 액세스 제한에 대한 추가 권고 사항은 본 블로그 게시물의 권한 있는 계정 로그온 제한(Privileged Account Logon Restrictions) 섹션을 참조하십시오.

권한 있는 계정, 그룹 및 GPO 수정 모니터링을 위한 탐지 기회

권한 있는 계정 및 서비스 계정 보호

SPN이 구성된 비컴퓨터 계정 식별 및 검토

서비스 사용자 이름(SPN)이 설정된 계정은 위협 행위자들이 권한 상승을 위해 흔히 노리는 표적입니다. Kerberos 프로토콜을 사용하면 모든 도메인 사용자는 도메인 컨트롤러에 SPN이 구성된 모든 계정에 대한 Kerberos 서비스 티켓(TGS)을 요청할 수 있습니다. 비컴퓨터 계정(일반 사용자/서비스 계정)은 추측 가능한(비임의적인) 비밀번호가 설정되어 있을 가능성이 높습니다. 도메인 기능 수준(Domain Function Level)이나 호스트의 Windows 버전과 관계없이, 비컴퓨터 계정 아래에 등록된 SPN은 고급 암호화 표준(AES) 대신 레거시 RC4-HMAC 암호화 제품군을 사용합니다. RC4-HMAC 암호화 유형의 암호화 및 복호화에 사용되는 키는 해당 계정 비밀번호의 솔트(salt) 없는 NTLM 해시 버전을 나타내며, 이는 티켓 크래킹(cracking)을 통해 도출될 수 있습니다.

Get-ADUser -Filter {(ServicePrincipalName -like "*")} | Select-Object name,samaccountname,sid,enabled,DistinguishedName

그림 31: SPN이 구성된 비컴퓨터 계정을 식별하기 위한 PowerShell cmdlet

가능한 경우, 조직은 SPN이 구성된 비컴퓨터 계정의 등록을 취소(deregister)해야 합니다. SPN이 반드시 필요한 경우에는 Kerberoasting 공격과 관련된 위험을 완화해야 합니다. SPN이 설정된 계정은 강력하고 고유한 비밀번호(예: 최소 25자 이상)로 구성해야 하며, 주기적으로 비밀번호를 변경(rotate)해야 합니다. 또한, 각 계정이 의도된 기능을 수행하는 데 필요한 최소한의 권한만을 가질 수 있도록 이러한 계정들의 권한을 검토하고 축소해야 합니다.

SPN이 설정된 계정은 이 블로그 게시물 전체에서 상세히 다루는 선제적인 보안 강화 조치의 적용 대상(in-scope)으로 간주되어야 합니다.

참고: SPN은 일반적인 대화형(interactive) 사용자 계정과 절대로 연결되어서는 안 됩니다.

SPN이 구성된 비컴퓨터 계정 모니터링을 위한 탐지 기회

권한 있는 계정 로그온 제한

권한 있는 계정 및 서비스 계정의 자격 증명은 내부망 이동(lateral movement) 및 지속성(persistence) 확보를 위해 흔히 사용됩니다.

환경 전반에 걸쳐 권한 있는 액세스 권한을 가진 계정은 일반적인 워크스테이션이나 노트북에서 사용되어서는 안 되며, 제한되고 보호되는 VLAN 및 티어(tier) 내에 위치한 지정된 시스템(예: 권한 있는 액세스 워크스테이션[PAW])에서 사용되어야 합니다. 각 티어마다 전용 권한 계정을 정의해야 하며, 해당 계정이 지정된 티어 내에서만 사용될 수 있도록 강제하는 통제 항목을 마련해야 합니다. 권한 있는 계정에 대한 가드레일(guardrail) 적용은 GPO 내에서 정의하거나 인증 정책 사일로(Authentication policy silos, Windows Server 2012 R2 도메인 기능 수준 이상)를 사용하여 수행할 수 있습니다.

권한 있는 계정의 액세스 범위를 제한하기 위한 권고 사항은 권한 있는 액세스 보안에 대한 Microsoft의 가이드를 기반으로 합니다. 추가 정보는 다음을 참조하십시오:

• https://docs.microsoft.com/en-us/security/compass/privileged-access-access-model

• https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/authentication-policies-and-authentication-policy-silos

사용자 권한 할당

선제적인 보안 강화 또는 신속한 격리 조치의 일환으로, 권한 있는 AD 액세스 권한을 가진 모든 계정이 일반 워크스테이션, 노트북 및 공용 액세스 서버(예: 가상 데스크톱 인프라(VDI))에 (원격 또는 로컬로) 로그인할 수 없도록 차단하는 것을 고려하십시오.

다음에 참조된 설정들은 GPO 내에 정의된 사용자 권한 할당을 사용하여 다음 경로를 통해 구성할 수 있습니다: 

• 컴퓨터 구성(Computer Configuration) > 정책(Policies) > Windows 설정(Windows Settings) > 보안 설정(Security Settings) > 로컬 정책(Local Policies) > 사용자 권한 할당(User Rights Assignment)

도메인 기반의 권한 있는 액세스가 위임된 계정은 다음 설정(그림 32에 묘사된 것과 유사한 GPO 설정을 사용하여 구성 가능)의 컨텍스트 내에서 일반 워크스테이션 및 노트북 시스템에 대한 액세스가 명시적으로 거부되어야 합니다:

• 네트워크에서 이 컴퓨터 액세스 거부 (S-1-5-114: NT AUTHORITY\Local account and member of Administrators group 포함) (SeDenyNetworkLogonRight)

• 일괄 작업으로 로그온 거부 (SeDenyBatchLogonRight)

• 서비스로 로그온 거부 (SeDenyServiceLogonRight)

• 로컬 로그온 거부 (SeDenyInteractiveLogonRight)

• 터미널 서비스를 통한 로그온 거부 (SeDenyRemoteInteractiveLogonRight)

또한, GPO를 사용하여 엔드포인트의 권한을 제한함으로써 다음과 같은 사용자 권한 할당을 가진 계정의 범위를 줄여 권한 상승 및 잠재적인 데이터 탈취를 방지할 수 있습니다.

• 프로그램 디버그 (SeDebugPrivilege)

• 파일 및 디렉터리 백업 (SeBackupPrivilege)

• 파일 및 디렉터리 복원 (SeRestorePrivilege)

• 파일 또는 기타 개체 소유권 가져오기 (SeTakeOwnershipPrivilege)

권한 있는 계정 로그온 모니터링을 위한 탐지 기회

서비스 계정 로그온 제한

조직은 도메인 기반 서비스 계정의 보안을 강화하여, 해당 계정이 대화형(interactive), 원격 데스크톱 및 가능한 경우 네트워크 기반 로그온에 사용되는 것을 제한해야 합니다.

서비스 계정에 권장되는 최소 로그온 보안 강화 (대화형 또는 원격 로그온 용도로 서비스 계정이 필요하지 않은 엔드포인트 대상):

• 컴퓨터 구성(Computer Configuration) > 정책(Policies) > Windows 설정(Windows Settings) > 보안 설정(Security Settings) > 로컬 정책(Local Policies) > 사용자 권한 할당(User Rights Assignment)

  • 로컬 로그온 거부 (SeDenyInteractiveLogonRight)

  • 터미널 서비스를 통한 로그온 거부 (SeDenyRemoteInteractiveLogonRight)

서비스 계정에 권장되는 추가 로그온 보안 강화 (네트워크 기반 로그온 용도로 서비스 계정이 필요하지 않은 엔드포인트 대상):

• 컴퓨터 구성(Computer Configuration) > 정책(Policies) > Windows 설정(Windows Settings) > 보안 설정(Security Settings) > 로컬 정책(Local Policies) > 사용자 권한 할당(User Rights Assignment)

  • 네트워크에서 이 컴퓨터 액세스 거부 (SeDenyNetworkLogonRight)

서비스 계정이 특정 서비스를 실행하기 위해 단일 엔드포인트에서만 사용되어야 하는 경우, 미리 정의된 엔드포인트 목록에서만 해당 계정을 사용할 수 있도록 추가로 제한할 수 있습니다(그림 33).

• Active Directory 사용자 및 컴퓨터(Active Directory Users and Computers) > 계정 선택

  • 계정(Account) 탭

    • 로그온 대상(Log On To) 버튼 > 액세스 가능한 적절한 컴퓨터 범위 선택

서비스 계정 로그온 모니터링을 위한 탐지 기회

관리 서비스 계정 / 그룹 관리 서비스 계정

고정된(static) 서비스 계정을 사용하는 조직은 해당 서비스 계정을 관리 서비스 계정(MSA, Managed Service Accounts) 또는 그룹 관리 서비스 계정(gMSA, Group Managed Service Accounts)으로 마이그레이션(migration)하는 방안의 타당성을 검토해야 합니다.

MSA는 Windows Server 2008 R2 Active Directory 스키마(도메인 기능 수준)와 함께 처음 도입되었으며, 특정 엔드포인트에서 실행되는 서비스와 연결된 전용 서비스 계정에 대해 자동 비밀번호 관리(30일 주기 변경) 기능을 제공합니다.

• 표준 MSA (Standard MSA): 계정이 단일 엔드포인트에 연결되며, 해당 계정의 복잡한 비밀번호가 자동으로 관리되고 사전 정의된 주기(기본값 30일)에 따라 변경됩니다. MSA는 단일 컴퓨터 계정에만 연결될 수 있지만, 동일한 엔드포인트에 있는 여러 서비스에서 이 MSA를 활용할 수 있습니다.

• 그룹 관리 서비스 계정 (gMSA): Windows Server 2012와 함께 처음 도입되었으며 MSA와 매우 유사하지만, 단일 gMSA를 여러(multiple) 엔드포인트에 걸쳐 활용할 수 있도록 허용합니다.

MSA 및 gMSA의 일반적인 사용 사례는 다음과 같습니다.

• 예약된 작업 (Scheduled Tasks)

• 인터넷 정보 서비스(IIS) 애플리케이션 풀

• 구조화된 질의어(SQL) 서비스 (SQL 2012 이상) – Express 버전은 MSA를 지원하지 않습니다.

• Microsoft Exchange 서비스

• 네트워크 부하 분산(NLB, 클러스터링) – gMSA 전용

• MSA를 지원하는 제3자 애플리케이션

참고: 위협 행위자는 권한 상승(privilege escalation) 및 내부망 이동(lateral movement)을 위해 gMSA의 비밀번호를 읽거나 활용할 수 있는 권한을 가진 계정과 그룹을 잠재적으로 발견할 수 있습니다. 이는 get-adserviceaccount PowerShell cmdlet을 활용하고, gMSA 비밀번호에 액세스할 수 있는 보안 주체(security principals)를 저장하는 gMSA의 msDS-GroupMSAMembership (PrincipalsAllowedToRetrieveManagedPassword) 구성을 열거(enumerating)함으로써 수행될 수 있습니다. 관리 서비스 계정을 구성할 때, 조직은 해당 계정의 비밀번호를 획득하고 활용할 수 있는 권한을 가진 계정 및 그룹의 범위를 제한하는 데 집중하고, 이러한 계정과 그룹에 대한 체계적인 모니터링을 강제하는 것이 중요합니다.

MSA 및 gMSA와 관련된 추가 정보는 다음을 참조하십시오:

• https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/managed-service-accounts-understanding-implementing-best/ba-p/397009

• https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview

관리 / 그룹 관리 서비스 계정 모니터링을 위한 탐지 기회 

보호된 사용자(Protected Users) 보안 그룹

권한 있는 계정에 '보호된 사용자(Protected Users)' 보안 그룹을 활용함으로써, 조직은 위협 행위자나 멀웨어가 엔드포인트의 디스크 또는 메모리에서 권한 있는 계정의 자격 증명을 획득하여 발생하는 다양한 노출 요인과 일반적인 공격 기법을 최소화할 수 있습니다.

Microsoft Windows 8.1 및 Microsoft Windows Server 2012 R2 이상부터 환경 내 자격 증명 노출을 관리하기 위해 '보호된 사용자' 보안 그룹이 도입되었습니다. 이 그룹의 구성원인 계정에는 다음과 같은 특정 보호 조치가 자동으로 적용됩니다.

• Kerberos TGT(티켓 부여 티켓)가 일반적인 기본 설정인 10시간 대신 4시간 후에 만료됩니다.

• Kerberos 인증만 사용되므로 LSASS에 계정의 NTLM 해시가 저장되지 않습니다(계정에 대한 NTLM 인증이 비활성화됨).

• 자격 증명 캐싱(Cached credentials)이 차단됩니다. 계정 인증을 위해서는 반드시 도메인 컨트롤러(DC)를 사용할 수 있어야 합니다.

• 엔드포인트에 적용된 정책 설정과 관계없이 계정에 대한 WDigest 인증이 비활성화됩니다.

• DES 및 RC4를 Kerberos 사전 인증에 사용할 수 없으며(Server 2012 R2 이상), 대신 AES 암호화를 사용하는 Kerberos가 강제 적용됩니다.

• 계정을 제한된 위임(constrained delegation)이나 제한되지 않은 위임(unconstrained delegation)에 사용할 수 없습니다. (이는 Active Directory 사용자 및 컴퓨터의 '계정이 중요하므로 위임할 수 없음' 설정을 적용하는 것과 동일합니다.)

'보호된 사용자' 보안 그룹 구성원에 대해 도메인 컨트롤러 측면의 제한 사항을 제공하려면 도메인 기능 수준이 Windows Server 2012 R2 이상이어야 합니다. Microsoft 보안 권고 KB2871997은 Windows 7, Windows Server 2008 R2 및 Windows Server 2012 시스템에 대해 '보호된 사용자' 그룹 구성원에게 적용되는 보호 조치에 대한 호환성 지원을 추가합니다.

'보호된 사용자' 그룹 구성원의 성공(이벤트 ID 303, 304) 또는 실패(이벤트 ID 100, 104) 로그온 이벤트는 도메인 컨트롤러의 다음 이벤트 로그 내에 기록될 수 있습니다.

• %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-Authentication%4ProtectedUserSuccesses-DomainController.evtx

• %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-Authentication%4ProtectedUserFailures-DomainController.evtx

$log1 = New-Object System.Diagnostics.Eventing.Reader.EventLogConfiguration Microsoft-Windows-Authentication/ProtectedUserSuccesses-DomainController
$log1.IsEnabled=$true
$log1.SaveChanges()

$log2 = New-Object System.Diagnostics.Eventing.Reader.EventLogConfiguration Microsoft-Windows-Authentication/ProtectedUserFailures-DomainController
$log2.IsEnabled=$true
$log2.SaveChanges()

그림 35: 도메인 컨트롤러에서 Protected Users 보안 그룹에 대한 이벤트 로깅을 활성화하기 위한 PowerShell cmdlet

참고: 서비스 계정(MSA 포함)은 인증이 실패하므로 Protected Users 보안 그룹에 추가해서는 안 됩니다.

보호된 사용자(Protected Users) 보안 그룹 모니터링을 위한 탐지 기회

일반 텍스트 비밀번호 보호 

권한 있는 계정의 액세스를 제한하는 것 외에도, 엔드포인트의 메모리에 있는 자격 증명(credentials) 및 토큰의 노출을 최소화하는 통제 항목을 강제해야 합니다.

구형 Windows 버전에서는 주로 WDigest 인증을 지원하기 위해 일반 텍스트 비밀번호가 메모리(LSASS)에 저장됩니다. 기본적으로 비활성화되어 있지 않은 모든 Windows 엔드포인트에서는 WDigest를 명시적으로 비활성화해야 합니다.

기본적으로 WDigest 인증은 Windows 8.1 이상 및 Windows Server 2012 R2 이상에서 비활성화되어 있습니다.

Windows 7 및 Windows Server 2008 R2부터는 KB2871997 업데이트를 설치한 후, 레지스트리를 수정하거나 Microsoft 보안 규정 준수 도구 키트(Microsoft Security Compliance Toolkit)의 Microsoft Security Guide GPO 템플릿을 사용하여 WDigest 인증을 구성할 수 있습니다.

레지스트리 방식 

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential
REG_DWORD = "0"

그림 36: WDigest 인증을 비활성화하기 위한 레지스트리 키 및 값

명시적으로 구성해야 할 또 다른 레지스트리 설정은 TokenLeakDetectDelaySecs 설정입니다(그림 37). 이 설정은 로그오프한 사용자의 메모리에 있는 자격 증명을 30초 후에 지워주며, 이는 Windows 8.1 이상의 기본 동작 방식과 동일합니다.

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\TokenLeakDetectDelaySecs
REG_DWORD = "30"

그림 37: TokenLeakDetectDelaySecs 설정을 강제하기 위한 레지스트리 키 및 값

그룹 정책 방식 

Microsoft Security Guide 그룹 정책 템플릿을 사용하여 GPO 설정을 통해 WDigest 인증을 비활성화할 수 있습니다(그림 38).

• 컴퓨터 구성(Computer Configuration) > 정책(Policies) > 관리 템플릿(Administrative Templates) > MS Security Guide > WDigest 인증(WDigest Authentication)

  • 비활성(Disabled)

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\PolicyDefaults
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation

그림 39: 일반 텍스트 비밀번호 저장에 대비한 보안 강화를 위한 추가 레지스트리 키

그룹 정책 재처리

위협 행위자는 레지스트리를 직접 수정(UseLogonCredential 값을 1로 구성)하여 엔드포인트에서 WDigest 인증을 수동으로 활성화할 수 있습니다. WDigest 인증이 기본적으로 자동 비활성화되어 있는 엔드포인트라도, 다음과 같은 GPO 설정을 강제 적용하여 구성된(예상되는) 설정에 대한 자동 그룹 정책 재처리를 자동화된 방식으로 시행할 것을 권장합니다.

• 컴퓨터 구성(Computer Configuration) > 정책(Policies) > 관리 템플릿(Administrative Templates) > 시스템(System) > 그룹 정책(Group Policy) > 보안 정책 처리 구성(Configure security policy processing)

  • 사용(Enabled) - 그룹 정책 개체가 변경되지 않은 경우에도 처리

• 컴퓨터 구성(Computer Configuration) > 정책(Policies) > 관리 템플릿(Administrative Templates) > 시스템(System) > 그룹 정책(Group Policy) > 레지스트리 정책 처리 구성(Configure registry policy processing)

  • 사용(Enabled) - 그룹 정책 개체가 변경되지 않은 경우에도 처리

참고: 기본적으로 그룹 정책 설정은 기본 새로 고침 간격 이전에 실제 그룹 정책이 수정된 경우에만 재처리되고 다시 적용됩니다.

KB2871997 업데이트는 Windows XP, Windows Server 2003 및 Windows Server 2008에는 적용되지 않으므로, 이 플랫폼에서 WDigest 인증을 비활성화하려면 시스템 재부팅 전에 레지스트리 내의 LSA 보안 패키지 목록에서 WDigest를 제거해야 합니다(그림 40 및 그림 41).

HKLM\System\CurrentControlSet\Control\Lsa\Security Packages

그림 40: LSA 보안 패키지를 수정하기 위한 레지스트리 키

WDigest 인증 조건 모니터링을 위한 탐지 기회

RDP 사용 시 자격 증명 보호

RDP 제한된 관리자 모드

RDP 제한된 관리자 모드(Restricted Admin mode)는 관리자 자격 증명으로 서버나 워크스테이션에 원격 데스크톱(Remote Desktop) 연결을 수행하는 담당자에게 할당된 모든 최종 사용자 시스템에서 활성화할 수 있습니다. 이 기능은 RDP를 사용하여 액세스할 때 대상 엔드포인트의 메모리에 관리자 자격 증명이 노출되는 것을 제한할 수 있습니다.

제한된 관리자 RDP를 활용하려면 그림 43에 참조된 명령어를 실행하면 됩니다.

mstsc.exe /RestrictedAdmin

그림 43: 제한된 관리자 RDP를 실행하기 위한 명령어

RDP 연결 시 제한된 관리자(Restricted Admin) 모드를 사용하면, 인증 계정이 대상 엔드포인트의 관리자인 경우 해당 사용자 계정의 자격 증명이 메모리에 저장되지 않습니다. 대신, 사용자 계정의 컨텍스트(context)는 대상 머신 계정(domain\destination-computer$)으로 나타나게 됩니다.

RDP 제한된 관리자 모드를 활용하려면 대상(destination) 엔드포인트뿐만 아니라 출발지(originating) 엔드포인트에서도 관련 설정을 적용해야 합니다.

출발지 엔드포인트 (클라이언트 모드 - Windows 7 및 Windows Server 2008 R2 이상)

제한된 관리자 기능을 사용하여 원격 데스크톱 세션을 시작하는 출발지 엔드포인트에 다음 GPO 설정을 적용해야 합니다.

• 컴퓨터 구성(Computer Configuration) > 정책(Policies) > 관리 템플릿(Administrative Templates) > 시스템(System) > 자격 증명 위임(Credential Delegation) > 원격 서버로의 자격 증명 위임 제한(Restrict delegation of credentials to remote servers)

  • 제한된 관리자 요구(Require Restricted Admin) > 사용(Enabled)으로 설정

    • 다음 제한 모드 사용(Use the Following Restricted Mode) > 제한된 관리자 요구(Required Restricted Admin)

이 GPO 설정을 구성하면 엔드포인트에 그림 44에 표시된 레지스트리 키가 구성됩니다.

HKLM\Software\Policies\Microsoft\Windows\CredentialsDelegation\RestrictedRemoteAdministration
0 = Disabled
1 = Enabled

HKLM\Software\Policies\Microsoft\Windows\CredentialsDelegation\RestrictedRemoteAdministrationType
1 = Require Restricted Admin
2 = Require Remote Credential Guard
3 = Restrict Credential Delegation

그림 44: 제한된 관리자(Restricted Admin) 모드 요구를 위한 레지스트리 설정

대상 엔드포인트 (서버 모드 - Windows 8.1 및 Windows Server 2012 R2 이상)

레지스트리 설정을 구성해야 합니다 (그림 45).

HKLM\System\CurrentControlSet\Control\Lsa\DisableRestrictedAdmin
0 = Enabled
1 = Disabled

그림 45: 제한된 관리자 RDP 활성화 또는 비활성화를 위한 레지스트리 설정

권장: 제한된 관리자 모드를 활성화하려면 레지스트리 값을 0으로 설정하십시오.

제한된 관리자 RDP에서 구성해야 할 또 다른 설정은 DisableRestrictedAdminOutboundCreds 레지스트리 키입니다(그림 46).

HKLM\System\CurrentControlSet\Control\Lsa\DisableRestrictedAdminOutboundCreds
0 = default value (doesn't exist) - Admin Outbound Creds are Enabled
1 = Admin Outbound Creds are Disabled

그림 46: 관리자 아웃바운드 자격 증명을 비활성화하기 위한 레지스트리 설정

권장: 관리자 아웃바운드 자격 증명을 비활성화하려면 레지스트리 값을 1로 설정하십시오.

참고: 이 설정을 0으로 두면, 모든 아웃바운드 인증 요청은 사용자가 제한된 관리자 모드를 사용하여 연결한 해당 시스템(domain\destination-computer$)의 계정으로 나타납니다. 이 값을 1로 설정하면, RDP 제한된 관리자 모드로 연결한 시스템에서 외부로 아웃바운드 인증을 시도할 때 하위 네트워크 자원에 대해 인증할 수 있는 기능이 비활성화됩니다.

RDP 제한된 관리자 모드에 관한 추가 정보는 다음을 참조하십시오:

• https://support.microsoft.com/kb/2973351

• https://blogs.technet.microsoft.com/kfalde/2013/08/14/restricted-admin-mode-for-rdp-in-windows-8-1-2012-r2/

RDP 제한된 관리자 모드 모니터링을 위한 탐지 기회

Windows Defender 원격 자격 증명 가드

Windows 10 및 Windows Server 2016 엔드포인트의 경우, 원격 데스크톱(Remote Desktop)을 사용하여 연결할 때 대상 엔드포인트의 메모리에 권한 있는 계정이 노출되는 것을 줄이기 위해 'Windows Defender 원격 자격 증명 가드'를 활용할 수 있습니다. 원격 자격 증명 가드를 사용하면 모든 자격 증명이 클라이언트(출발지 시스템)에 남아 있으며 대상 엔드포인트에 직접 노출되지 않습니다. 대신, 대상 엔드포인트는 필요에 따라 소스(출발지) 측에 서비스 티켓을 요청합니다.

원격 자격 증명 가드가 활성화된 엔드포인트에 RDP로 로그인하면, 메모리 내의 어떤 SSP(보안 지원 공급자)도 해당 계정의 일반 텍스트 비밀번호나 비밀번호 해시를 저장하지 않습니다. 단, 대상 서버에서 대화형(및 싱글 사인온[SSO]) 환경을 허용하기 위해 Kerberos 티켓은 메모리에 남아 있다는 점에 유의하십시오.

원격 데스크톱 클라이언트(출발지) 호스트 요구사항:

• 자격 증명을 제공할 수 있으려면 최소 Windows 10(v1703) 이상을 실행 중이어야 합니다.

• 사용자의 로그인된 자격 증명을 사용하려면(자격 증명 입력창 없음) 최소 Windows 10(v1607) 또는 Windows Server 2016 이상을 실행 중이어야 합니다.

• 사용자 계정은 클라이언트(출발지)와 원격(대상) 엔드포인트 모두에 로그인할 수 있어야 합니다.

• 원격 데스크톱 클래식(Classic) Windows 애플리케이션을 실행해야 합니다.

• 원격 호스트에 연결하는 데 Kerberos 인증을 사용해야 합니다.

• 원격 데스크톱 유니버설 Windows 플랫폼(UWP) 애플리케이션은 Windows Defender 원격 자격 증명 가드를 지원하지 않습니다.

참고: 클라이언트가 도메인 컨트롤러(DC)에 연결할 수 없는 경우, RDP는 NTLM으로의 폴백(fallback)을 시도합니다. Windows Defender 원격 자격 증명 가드는 자격 증명을 위험에 노출시킬 수 있기 때문에 NTLM 폴백을 허용하지 않습니다.

원격 데스크톱 원격(대상) 호스트 요구사항:

• 최소 Windows 10(v1607) 또는 Windows Server 2016 이상을 실행 중이어야 합니다.

• 제한된 관리자(Restricted Admin) 연결을 허용해야 합니다.

• 클라이언트의 도메인 사용자가 원격 데스크톱 연결에 액세스하는 것을 허용해야 합니다.

• 내보낼 수 없는 자격 증명(nonexportable credentials)의 위임을 허용해야 합니다.

GPO 구성을 사용하여 클라이언트(출발지) 호스트에서 원격 자격 증명 가드를 활성화하는 방법:

• 컴퓨터 구성(Computer Configuration) > 관리 템플릿(Administrative Templates) > 시스템(System) > 자격 증명 위임(Credentials Delegation) > 원격 서버로의 자격 증명 위임 제한(Restrict delegation of credentials to remote servers)

  • 제한된 관리자 모드 또는 Windows Defender 원격 자격 증명 가드 중 하나를 요구하려면, Windows Defender 원격 자격 증명 가드 선호(Prefer Windows Defender Remote Credential Guard)를 선택합니다.

    • 이 구성에서는 원격 자격 증명 가드가 선호되지만, 원격 자격 증명 가드를 사용할 수 없는 경우 (지원된다면) 제한된 관리자 모드를 사용합니다.

    • 원격 자격 증명 가드와 RDP 제한된 관리자 모드 모두 원격 데스크톱 서버에 일반 텍스트로 자격 증명을 보내지 않습니다.

  • 원격 자격 증명 가드를 반드시 요구하려면, Windows Defender 원격 자격 증명 가드 요구(Require Windows Defender Remote Credential Guard)를 선택합니다.

    • 이 구성에서는 원격 컴퓨터가 원격 자격 증명 가드 요구 사항을 충족하는 경우에만 원격 데스크톱 연결이 성공합니다.

원격(대상) 호스트에서 원격 자격 증명 가드를 활성화하는 방법은 그림 49를 참조하십시오.

HKLM\System\CurrentControlSet\Control\Lsa
Registry Entry: DisableRestrictedAdmin
Value: 0
reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /d 0 /t REG_DWORD

그림 49: 원격(대상) 호스트에서 원격 자격 증명 가드(Remote Credential Guard)를 활성화하기 위한 레지스트리 키 및 명령 옵션

mstsc.exe /remoteguard

그림 50: 원격 자격 증명 가드를 활용하기 위한 명령어

Windows Defender 원격 자격 증명 가드 모니터링을 위한 탐지 기회

로컬 계정의 원격 사용 제한

엔드포인트에 존재하는 로컬 계정은 위협 행위자가 환경 내에서 측면 이동(lateral movement)을 하기 위해 자주 활용하는 일반적인 경로입니다. 이 전술은 여러 엔드포인트에서 기본 제공(built-in) 로컬 관리자 계정의 비밀번호가 동일한 값으로 구성되어 있을 때 특히 큰 영향을 미칩니다.

로컬 계정이 측면 이동에 악용되는 영향을 완화하기 위해, 조직은 로컬 관리자 계정이 원격 연결을 설정하는 기능을 제한하는 것과 환경 전반의 로컬 관리자 계정에 대해 고유하고 무작위화된 비밀번호를 생성하는 것을 모두 고려해야 합니다.

KB2871997 업데이트는 측면 이동을 위한 로컬 계정 사용을 제한하기 위해 GPO 설정 내에서 활용할 수 있는 두 개의 잘 알려진 SID를 도입했습니다.

• S-1-5-113: NT AUTHORITY\Local account

• S-1-5-114: NT AUTHORITY\Local account and member of Administrators group

구체적으로, 로컬 계정이 BUILTIN\Administrators 그룹의 구성원인 경우 SID S-1-5-114: NT AUTHORITY\Local account and member of Administrators group이 계정의 액세스 토큰에 추가됩니다. 이것은 모든 로컬 관리자 계정의 자격 증명을 사용하여 전파되는 위협 행위자(또는 랜섬웨어 변종)를 차단하는 데 활용할 수 있는 가장 유용한 SID입니다.

참고: SID S-1-5-114: NT AUTHORITY\Local account and member of Administrators group의 경우, 장애 조치 클러스터링(Failover Clustering)을 사용할 때 이 기능은 클러스터 노드 관리를 위해 관리자가 아닌 로컬 계정(CLIUSR)을 활용해야 합니다. 이 계정이 클러스터의 일부인 엔드포인트에서 로컬 관리자 그룹의 구성원인 경우, 네트워크 로그온 권한을 차단하면 클러스터 서비스가 실패할 수 있습니다. 장애 조치 클러스터링이 사용되는 서버에서는 이 구성을 주의해서 철저히 테스트하십시오.

1단계 – 옵션 1: S-1-5-114 SID

로컬 관리자 계정이 측면 이동에 사용되는 것을 완화하려면, 다음 설정 내에서 SID S-1-5-114: NT AUTHORITY\Local account and member of Administrators group을 사용하십시오.

• 컴퓨터 구성(Computer Configuration) > 정책(Policies) > Windows 설정(Windows Settings) > 보안 설정(Security Settings) > 로컬 정책(Local Policies) > 사용자 권한 할당(User Rights Assignment)

  • 네트워크에서 이 컴퓨터에 대한 액세스 거부 (SeDenyNetworkLogonRight)

  • 일괄 작업으로 로그온 거부 (SeDenyBatchLogonRight)

  • 서비스로 로그온 거부 (SeDenyServiceLogonRight)

  • 터미널 서비스를 통한 로그온 거부 (SeDenyRemoteInteractiveLogonRight)

  • 프로그램 디버그 (SeDebugPrivilege: 권한 상승 시도 및 프로세스 인젝션에 사용되는 권한)

1단계 – 옵션 2: UAC 토큰 필터링 (UAC Token-Filtering)

GPO 설정을 통해 강제할 수 있는 추가적인 통제는 네트워크 로그온 중 원격 관리 및 연결을 위한 로컬 계정 사용과 관련이 있습니다. 전체 권한 범위(앞서 참조된 내용)를 단기간 내에 구현할 수 없는 경우, 네트워크 기반 로그온 시 로컬 계정에 사용자 계정 컨트롤(UAC) 토큰 필터링 방식 적용을 고려하십시오. 

GPO 설정을 통해 이 구성을 활용하려면:

1. MS Security Guide ADMX 파일을 사용하려면 보안 규정 준수 도구 키트(Security Compliance Toolkit, https://www.microsoft.com/en-us/download/details.aspx?id=55319)를 다운로드합니다.

2. 다운로드가 완료되면 SecGuide.admx 및 SecGuide.adml 파일을 각각 \Windows\PolicyDefinitions 및 \Windows\PolicyDefinitions\en-US 디렉터리에 복사해야 합니다.

3. 도메인에 중앙 집중식 GPO 저장소가 구성된 경우 PolicyDefinitions 폴더를 C:\Windows\SYSVOL\sysvol\<domain>\Policies 폴더로 복사합니다.

GPO 설정 

• 컴퓨터 구성(Computer Configuration) > 정책(Policies) > 관리 템플릿(Administrative Templates) > MS Security Guide > 네트워크 로그온 시 로컬 계정에 UAC 제한 적용(Apply UAC restrictions to local accounts on network logons)

  • 사용(Enabled)

활성화되면 각 엔드포인트에 레지스트리 값(그림 53)이 구성됩니다.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy

REG_DWORD = "0" (Enabled)

그림 53: 로컬 계정에 대한 UAC 제한 활성화를 위한 레지스트리 키 및 값

값이 0으로 설정된 경우, 높은 무결성(high-integrity) 액세스 토큰을 사용한 원격 연결은 RID 500 로컬 관리자의 일반 텍스트 자격 증명 또는 비밀번호 해시를 사용하는 경우에만 가능합니다. (이 또한 사용자 계정 컨트롤: 기본 제공 관리자 계정에 대한 관리자 승인 모드 GPO 설정을 통해 구성할 수 있는 FilterAdministratorToken 설정값에 따라 달라집니다.)

FilterAdministratorToken 옵션은 RID 500 로컬 관리자에 대한 관리자 승인(Admin Approval) 모드를 활성화(1)하거나 비활성화(0, 기본값)할 수 있습니다. 활성화되면 RID 500 로컬 관리자 계정의 액세스 토큰이 필터링되므로 이 계정에 대해 UAC가 강제 적용됩니다. (이는 궁극적으로 엔드포인트 간의 측면 이동을 위해 이 계정을 활용하려는 시도를 차단할 수 있습니다.)

GPO 설정

• 컴퓨터 구성(Computer Configuration) > 정책(Policies) > Windows 설정(Windows Settings) > 보안 설정(Security Settings) > 로컬 정책(Local Policies) > 보안 옵션(Security Options) > 사용자 계정 컨트롤: 기본 제공 관리자 계정에 대한 관리자 승인 모드(User Account Control: Admin Approval Mode for the built-in Administrator account)

활성화되면 각 엔드포인트에 레지스트리 값(그림 54)이 구성됩니다.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\FilterAdministratorToken

REG_DWORD = "1" (Enabled)

그림 54: 로컬 관리자 계정에 대한 관리자 승인 모드 요구를 위한 레지스트리 키 및 값

참고: 사용자 계정 컨트롤: 관리자 승인 모드에서 모든 관리자 실행(User Account Control: Run all administrators in Admin Approval Mode)(EnableLUA 옵션)의 기본 설정이 사용(Enabled) (그림 55에 표시된 기본값)에서 비활성(Disabled)으로 변경되지 않도록 확인하는 것이 중요합니다. 이 설정이 비활성화되면 모든 UAC 정책도 함께 비활성화됩니다. 이 설정이 비활성화된 경우, 로컬 관리자 그룹의 구성원인 모든 로컬 계정의 일반 텍스트 자격 증명이나 비밀번호 해시를 사용하여 권한 있는 원격 인증을 수행할 수 있게 됩니다.

GPO 설정 

• 컴퓨터 구성(Computer Configuration) > 정책(Policies) > 관리 템플릿(Administrative Templates) > MS Security Guide > 사용자 계정 컨트롤: 관리자 승인 모드에서 모든 관리자 실행(User Account Control: Run all administrators in Admin Approval Mode)

  • 사용(Enabled)

활성화되면 각 엔드포인트에 레지스트리 값(그림 55)이 구성됩니다. 이것은 기본 설정입니다.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA

REG_DWORD = "1" (Enabled)

그림 55: 모든 로컬 관리자 계정에 대한 관리자 승인 모드 요구를 위한 레지스트리 키 및 값

액티브 디렉토리 인증서 서비스(AD CS) 보호 

액티브 디렉토리 인증서 서비스(AD CS)는 Microsoft가 구현한 공개 키 기반 구조(PKI)로, Active Directory 포레스트 및 도메인과 직접 통합됩니다. 이는 디지털 서명 및 사용자 인증을 포함한 다양한 용도로 활용될 수 있습니다. AD CS에서는 특정 작업에 대해 미리 구성된 인증서를 발급하기 위해 '인증서 템플릿(Certificate Templates)'을 사용합니다. 인증서 템플릿에는 수신되는 인증서 요청에 적용되는 설정과 규칙이 포함되어 있으며, 유효한 인증서 요청을 제공하는 방법에 대한 지침을 제공합니다.

2021년 6월, SpecterOps는 AD CS를 대상으로 한 가능한 공격 연구를 상세히 다룬 Certified Pre-Owned라는 제목의 블로그 게시물을 발표했습니다. 해당 발표 이후, Mandiant는 위협 행위자와 레드팀원들이 침해 후 목표 달성을 위해 AD CS를 표적으로 삼는 활동을 강화하는 것을 지속적으로 관찰해 왔습니다. Mandiant의 블로그 게시물과 보안 강화 가이드(Hardening Guide)는 최근 보안 침해 사고에 대한 당사의 일선 관찰을 통해 식별된 지속적인 오용 시나리오와 AD CS 공격 벡터를 다루고 있습니다.

취약한 인증서 템플릿 식별

AD CS에 의해 구성 및 게시된 인증서 템플릿은 pKICertificateTemplate 객체 클래스를 가진 객체로 Active Directory에 저장되며, 블루팀뿐만 아니라 위협 행위자에 의해서도 발견될 수 있습니다. Active Directory에 인증된 모든 계정은 LDAP을 직접 쿼리하거나, Windows 내장 명령인 certutil.exe를 사용하거나, PSPKIAudit, Certipy, Certify와 같은 전문 도구를 사용하여 이를 식별할 수 있습니다. Mandiant는 이러한 방법 중 하나를 사용하여 취약한 인증서 템플릿을 식별할 것을 권장합니다.

취약한 인증서 템플릿 보안 강화 

취약한 인증서 템플릿이 식별되면 오용을 방지하기 위해 보안을 강화해야 합니다.

1. 모든 도메인 컨트롤러(DC) 및 인증 기관(CA) 서버가 최신 업데이트 및 핫픽스로 패치되었는지 확인합니다.

2. Windows 업데이트(KB5014754)를 설치하고 이벤트 ID 39 및 41을 모니터링 및 조치한 후, 취약한 인증서 매핑에 기반한 인증을 거부하도록 Active Directory의 전체 강제 모드(full enforcement mode)를 구성합니다.

3. 앞서 언급한 방법 중 하나를 사용하여 게시된 인증서 템플릿을 정기적으로 검토하며, 특히 기존 템플릿에 구성된 SAN(주체 대체 이름) 사양과 관련된 설정을 확인합니다.

4. 게시된 모든 인증서 템플릿에 할당된 보안 권한을 검토하고, 등록(Enrollment) 및 쓰기(Write) 권한이 올바른 보안 주체에 위임되었는지 검증합니다.

5. 도메인 인증을 지원하는 다음 확장 키 용도(EKU)가 구성된 템플릿을 검토하고, 이러한 구성의 운영상 필요성을 확인합니다.

   • 모든 용도 (Any Purpose, 2.5.29.37.0)

   • 하위 CA (Subordinate CA, None)

   • 클라이언트 인증 (Client Authentication, 1.3.6.1.5.5.7.3.2)

   • PKINIT 클라이언트 인증 (PKINIT Client Authentication, 1.3.6.1.5.2.3.4)

   • 스마트 카드 로그온 (Smart Card Logon, 1.3.6.1.4.1.311.20.2.2)

6. 민감한 EKU가 포함된 템플릿의 경우, 해당 인증서는 여러 용도로 사용될 수 있으므로 등록 권한을 미리 정의된 사용자 또는 그룹으로 제한합니다. 템플릿의 액세스 제어 목록(ACL)을 감사하여 최소 권한 원칙을 준수하는지 확인해야 합니다. 도메인 인증을 허용하는 템플릿은 방대한 수의 계정을 포함하는 내장 그룹에 등록 권한이 할당되지 않았는지 면밀히 검토하십시오. 오용 위험을 높일 수 있는 내장 그룹의 예는 다음과 같습니다.

   • Everyone

   • NT AUTHORITY\Authenticated Users

   • Domain Users

   • Domain Computers

7. 가능한 경우, SAN을 발급 요구 사항으로 포함하는 모든 템플릿에 대해 "CA 인증서 관리자 승인(CA Certificate Manager approval)"을 강제 적용합니다. 이를 통해 모든 인증서 발급 요청은 CA 서버에서 "인증서 발급 및 관리" 권한을 가진 담당자가 수동으로 검토하고 승인해야 합니다.

8. 인증 기관이 (템플릿 구성과 관계없이) 임의의 SAN을 수락하도록 구성되지 않았는지 확인합니다. 이는 기본 설정이 아니며 가능한 한 피해야 합니다. 이 공격 벡터는 KB5014754로 완화되지만, 강력한 매핑이 강제되기 전까지는 요청자의 SID가 포함된 새로운 OID가 누락된 과거 인증서를 기반으로 오용이 발생할 수 있습니다. 자세한 정보는 다음 Microsoft 문서를 참조하십시오.

9. 루트(Root) 및 하위(Subordinate) 인증 기관을 모두 티어 0(Tier 0) 자산으로 취급하고, 로그온 제한이나 인증 정책 사일로(Authentication Policy Silos)를 적용하여 인증서 서비스가 설치된 서버에 높은 수준의 액세스 권한을 가진 계정 범위를 제한합니다.

10. Active Directory 내에서 인증을 가능하게 하는 CA 인증서를 참조하는 AD의 NTAuthCertificates 컨테이너를 감사하고 검토합니다. AD는 주체를 인증하기 전에 인증 인증서의 Issuer(발행자) 필드에 지정된 CA가 NTAuthCertificates 컨테이너에 있는지 확인하여 CA의 신뢰성을 검증합니다. 권한이 없거나 승인되지 않은 CA 인증서가 존재한다면 추가 조사가 필요한 보안 이벤트의 징후일 수 있습니다.

11. CA의 개인 키 도난(예: DPAPI 백업 프로토콜을 통한 도난)을 방지하기 위해, 인증 기관 서비스가 설치된 서버에서 하드웨어 보안 모듈(HSM)을 사용하여 개인 키를 보호합니다.

12. CA 및 AD 관리와 운영에 다중 인증(MFA)을 강제 적용합니다.

13. 루트 CA는 오프라인 상태로 유지하고, 실제 인증서 발급에는 하위 CA를 사용합니다.

14. Windows 내장 명령인 certutil.exe나 PSPKIAudit, Certipy, Certify와 같은 전문 도구를 사용하여 정기적으로 기존 인증서 템플릿의 잠재적인 설정 오류를 검증하고 식별합니다. 이러한 공개 도구는 레드팀이나 위협 행위자가 자주 사용하므로 EDR 제품에 의해 탐지될 수 있습니다.

15. AD CS에서 NTLM 릴레이 공격을 완화하기 위해 '인증 기관 웹 등록' 및 '인증서 등록 웹 서비스'에 대해 '인증을 위한 확장 보호(EPA)'를 활성화합니다. 또한 AD CS가 HTTPS 연결만 수락하도록 설정합니다. 자세한 내용은 다음 Microsoft 문서를 참조하십시오.

16. 그룹 정책을 사용하여 CA 서버의 인증서 서비스 및 도메인 컨트롤러의 Kerberos 인증 서비스에 대한 감사 로깅을 활성화합니다. CA 서버의 이벤트 ID 4886 및 4887, 도메인 컨트롤러의 이벤트 ID 4768이 조직의 SIEM 솔루션에 수집되도록 합니다.

17. 각 CA 서버에서 감사 필터(Audit Filter)를 활성화합니다. 이는 활성화 가능한 7가지 감사 범주를 나타내는 비트마스크(bitmask) 값으로, 모든 범주를 활성화할 경우 감사 필터 값은 127이 됩니다.

18. AD CS 활동과 관련된 탐지를 강화하기 위해 CA 서버 및 도메인 컨트롤러의 이벤트를 로깅하고 모니터링합니다(16단계와 17단계가 적절한 로그 생성을 위한 선행 조건입니다).

AD CS 오용 모니터링을 위한 탐지 기회

5. Kubernetes 및 CI/CD 파이프라인에서 파괴적 행위 방지