optiv/dentMicrosoft의 WDAPT 센서의 취약점을 활용하여 COM 기반 우회를 생성하기 위한 프레임워크입니다.
Dent의 최신 버전을 보거나 이슈를 제출하려면 https://github.com/Tylous/Dent를 참조하십시오.
Dent
이 프레임워크에서 사용된 기술에 대해 더 알고 싶다면 이 기사를 참조하십시오.
이 프레임워크는 Microsoft Defender Advanced Threat Protection의 Attack Surface Reduction(ASR) 규칙의 취약점을 악용하여 쉘코드를 탐지되거나 차단되지 않고 실행하는 코드를 생성합니다. ASR은 일련의 규칙을 위반하는 작업을 기반으로 이벤트를 감지하는 최전선 방어 수단으로 설계되었습니다. 이러한 규칙은 공격자의 전술, 기술 또는 절차(TTP)와 자주 연관되는 엔드포인트의 특정 행동 지표에 초점을 맞춥니다. 이 규칙들은 원격 발판을 구축하는 일반적인 공격 벡터인 Microsoft Office 제품군에 중점을 둡니다. 많은 규칙 기반 제어는 정상적인 비즈니스 운영과 다른 네트워크 기반 또는 프로세스 기반 행동 지표에 초점을 맞춥니다. 이러한 규칙은 시스템의 초기 침해 또는 조직에 심각한 영향을 미칠 수 있는 기술(예: 자격 증명 유출 또는 랜섬웨어)에 초점을 맞춥니다. 이들은 일반적인 공격 표면의 많은 부분을 다루며 자산을 손상시키는 데 사용되는 알려진 기술을 방해하는 데 초점을 맞춥니다.
Dent는 여러 취약점을 활용하여 이러한 제한적인 제어를 우회하고 Microsoft Defender Advanced Threat Protection 센서에 의해 차단되거나 효과적으로 탐지되지 않고 엔드포인트에서 페이로드를 실행합니다. 위의 기사는 공개 후에도 Microsoft Defender Advanced Threat Protection에 여전히 존재하는 이러한 취약점에 대해 설명합니다.
첫 번째 단계는 항상 그렇듯이 리포지토리를 클론한 다음 빌드하는 것입니다.
go build Dent.go
./Dent -h
________ __
\______ \ ____ _____/ |_
| | \_/ __ \ / \ __\
| | \ ___/| | \ |
/_______ /\___ >___| /__|
\/ \/ \/
(@Tyl0us)
"Call someone a hero long enough, and they'll believe it. They'll become it.
They have no choice. Let them call you a monster, and you become a monster."
Usage of ./Dent:
-C string
Name of the COM object.
-N string
Name of the XLL playload when it's writen to disk.
-O string
Name of the output file. (default "output.txt")
-P string
Path of the DLL for your COM object. (Either use \\ or '' around the path)
-U string
URL where the base64 encoded XLL payload is hosted.
-show
Display the script in the terminal.
이 프레임워크는 Microsoft Defender Advanced Threat Protection의 취약점과 결함을 악용하기 위한 것이므로 실제로 페이로드/임플란트를 생성하지는 않습니다. 그러나 모든 연구, 개발 및 테스트는 ScareCrow를 사용하여 수행되었습니다. Microsoft Defender Advanced Threat Protection은 원격 측정에 사용자랜드 후킹에 의존하지 않고 커널 콜백과 같은 다양한 다른 메커니즘을 활용합니다. 테스트 결과, 이 프레임워크는 Microsoft Defender Advanced Threat Protection을 우회하여 쉘코드를 실행하는 데 매우 효과적입니다.
릴리스 시점 현재 두 가지 기술이 있습니다. 이러한 취약점을 다양한 방식으로 활용하는 다른 기술을 주기적으로 계속 추가할 예정이니 계속 지켜봐 주시기 바랍니다.
COM 개체는 애플리케이션이 시스템에 설치될 때 자주 생성됩니다. 생성되면 모든 애플리케이션이나 스크립트가 이를 호출할 수 있지만, 이것이 유일한 생성 방법은 아닙니다. Windows 레지스트리의 HKEY_CLASSES_ROOT 섹션에 레지스트리 키를 수정/생성하여 시스템의 쉘코드를 가리키는 COM 개체를 만들 수 있습니다. 즉, COM을 활용할 수 있는 모든 애플리케이션이나 스크립트가 이를 호출하여 쉘코드를 실행할 수 있습니다.
이는 CoCreateInstance API 함수의 작동 방식 때문입니다. CoCreateInstance는 CLSID(특정 COM 클래스 개체를 식별하는 데 사용되는 전역 고유 식별자)를 기반으로 COM 개체를 생성하고 초기화하는 데 사용됩니다. 이 함수는 레지스트리 키에 저장된 값을 사용하여 호출을 실행하기 위한 정보를 가져옵니다. 이러한 CLSID 값은 레지스트리의 HKEY_CLASSES_ROOT\CLSID\ 경로에서 찾을 수 있습니다. 그러나 프로세스가 CLSID를 호출하려면 먼저 해당 CLSID의 값을 알고 있어야 합니다. 이는 먼저 HKEY_CLASSES_ROOT\<COM 개체 이름>에서 COM 개체를 찾기 위해 레지스트리 쿼리를 수행하고, 존재하는 경우 하위 폴더에 저장된 CLSID 값을 얻기 위해 두 번째 레지스트리 쿼리를 수행함으로써 이루어집니다.
레지스트리 하위 폴더를 더 자세히 살펴보면 CLSID 값에 대한 권한이 일관되지 않음을 알 수 있습니다. 여기에 저장된 대다수의 COM 개체는 Trusted Installer에게만 '모든 권한'을 허용합니다. Trusted Installer는 관리자로부터도 리소스를 보호하는 서비스 계정입니다. 이는 공격자가 관리자 권한을 획득하더라도 리소스를 악의적으로 조작할 수 없도록 하기 위한 것입니다. 불행히도 많은 COM 개체가 Administrators 그룹의 모든 사용자에게 '모든 권한'을 허용합니다. 또한 루트 키 CLSID는 NT AUTHORITY\System 또는 Trusted Installer 대신 Administrators 그룹에 '모든 권한'을 부여합니다. 이로 인해 상승된 컨텍스트에서 특정 COM 개체 값을 생성하거나 수정할 수 있습니다.
중요
이러한 레지스트리 키의 생성은 상승된 컨텍스트에서 실행할 경우에만 작동합니다. GUI를 통해 더블 클릭하면 관리자라도 .VBS 파일이 상승된 컨텍스트에서 실행되지 않습니다. 관리 셸 또는 명령 프롬프트에서 실행하는 것이 좋습니다. 그러나 키가 생성되면 모든 애플리케이션이 모든 컨텍스트에서 이 COM 개체를 호출할 수 있습니다.
이 유형의 우회와 함께 ScareCrow 페이로드를 활용하려면 다음 명령을 실행할 수 있습니다:
./ScareCrow -I <path to your raw stageless shellcode> -domain <domain name> -Loader dll
페이로드가 준비되면 -N 플래그는 디스크에 기록될 때 페이로드의 이름을, -C 플래그는 COM 개체의 이름을, -I 플래그는 기록할 위치를, 마지막으로 -O 플래그는 콘텐츠를 저장할 출력 파일을 지정하는 데 사용합니다.
이 옵션은 여러 ASR 규칙을 우회하여 쉘코드를 다운로드하고, 디스크에 쓰고, 로드하고 실행하여 ASR 예방 제어를 우회하는 코드 블록을 생성합니다. 이는 전체 Excel 애플리케이션을 나타내지만 자동화된 형태로, 프로그래밍 방식으로 상호 작용할 수 있는 Excel.Application COM 개체를 사용하여 수행됩니다. 이것은 여전히 Excel이므로 ASR 규칙을 트리거하지 않습니다. 이는 Excel.Application을 호출하면 WinWord.exe 프로세스가 아닌 Service Host 프로세스(Svchost.exe) 아래에서 생성되기 때문입니다. Svchost.exe는 여러 Windows 기반 서비스를 호스팅하는 데 사용되는 시스템 수준 프로세스이지만, 생성된 자식 프로세스(Excel.exe)는 시스템 수준 권한을 얻지 못했습니다.
전체 애플리케이션인 COM 개체를 만들었기 때문에 Excel 프로세스가 Svchost.exe 아래에 생성되어 WinWord.exe 프로세스에 불안정을 초래하지 않도록 적절히 처리될 수 있었습니다. 이 프로세스가 Svchost.exe 아래에 있지만 쉘코드를 실행하는 또 다른 문제가 있습니다. 매크로 내에서 바이너리 실행이나 WinAPI 사용은 다른 ASR 규칙을 트리거하므로 ASR 규칙을 트리거하거나 WDAPT의 EDR 구성 요소에 탐지되지 않고 수행할 수 있는 작업이 제한됩니다. 여기서 DLL이 빛을 발합니다. DLL 기반 페이로드가 올바른 내보내기 함수로 컴파일되면 Office 플러그인으로 사용되어 로드될 때 자동으로 쉘코드를 실행할 수 있습니다. 이를 위해 Excel의 RegisterXLL 함수를 활용할 수 있습니다. RegisterXLL 함수는 XLL 플러그인을 메모리에 로드하고 자동으로 등록 및 실행합니다. XLL 파일은 본질적으로 Excel 기반 DLL입니다.
시스템에 콘텐츠를 가져오기 위해 다른 COM 개체(Microsoft.XMLHTTP)를 사용하여 HTTP 요청(이 경우 URL에 대한 HTTP GET 요청)을 실행할 수 있습니다. 두 번째 COM 개체(ADODB.stream)는 데이터 스트림의 바이트를 읽고 쓰는 기능을 제공합니다. 두 COM 개체를 결합하면 공격자가 HTTP GET 요청을 통해 원격 리소스를 요청하고 응답(이 경우 파일 자체)을 디스크에 쓸 수 있습니다. 이는 다시 COM 개체(ADODB.stream)를 사용하여 데이터 스트림의 바이트 읽기/쓰기를 처리합니다. 두 번째 COM 개체(Microsoft.XMLDOM)는 파일에 저장된 데이터를 읽을 수 있게 합니다. XMLDOM 개체는 데이터 형식(이 경우 base64)을 설정할 수 있으며, 적절한 데이터 형식으로 열리고 문자열에 저장되면 ADODB.stream 개체는 다른 데이터 형식(이 경우 BinaryStreamType)을 사용하여 코드 문자열을 디스크에 쓰고 base64 문자열을 다시 이진 형태로 변환할 수 있습니다.
이 유형의 우회와 함께 ScareCrow 페이로드를 활용하려면 다음 명령을 실행할 수 있습니다:
./ScareCrow -I <path to your raw stageless shellcode> -domain <domain name> -Loader excel -O <Output filename>
생성된 후 출력 파일에서 13행과 14행을 복사하여 함께 병합하고 다음을 제거해야 합니다:
var <variable name> 제거; 제거
인코딩된 페이로드가 준비되면 -N 플래그는 디스크에 기록될 페이로드 이름, -U 플래그는 인코딩된 페이로드가 호스팅될 URL(예: https:///), -F 플래그는 사이트에서 호스팅되는 파일의 이름을 지정합니다. 출력된 코드는 매크로 문서에서 작동하도록 설계되었습니다.
추가 조사를 통해 이는 WDATP 센서의 결함이 아니라 WDATP가 이 활동을 볼 수 있지만 무시된다는 것이 관찰되었습니다. WDATP 엔드포인트의 이벤트 타임라인에서 AppWiz.xll에 대한 참조를 찾은 결과 Word가 AppWiz.xll 파일을 생성할 때 WDATP가 '생성된 파일' 이벤트를 기록한 것을 확인했습니다. .XLL 파일은 실행 가능하다는 점에 유의해야 합니다.
2020년 11월 20일 - 연구 개발 및 기사 작성.
2021년 3월 14일 - 식별된 문제를 설명하는 예비 공개 문서를 Microsoft에 제공.
2021년 3월 31일 - Microsoft는 Office 자식 프로세스 생성 및 디스크에 파일 쓰기와 관련된 취약점이 실제 취약점임을 인지하고 인정했으며 수정 작업을 시작했습니다. 그러나 레지스트리의 권한 불일치는 상승된 권한 요구 사항으로 인해 취약점으로 간주되지 않았습니다.
2021년 4월 21일 - Microsoft는 저자에게 2021년 3월 22일에 출시된 서명 빌드 1.333.1055.0과 2021년 4월 21일에 출시된 1.335.1321.0에 Office 애플리케이션 기반 취약점에 대한 탐지가 포함되어 있으며 사건을 종결했다고 알렸습니다.
2021년 4월 22일 - 저자는 동일한 기술을 재테스트하여 취약점이 여전히 존재함을 확인했습니다.