XLL 피싱 기술
Microsoft의 최근 발표에 따르면 인터넷(이메일 및 웹 다운로드)에서 가져온 문서의 매크로를 차단하기 시작함에 따라, 공격자들은 사용자 주도 접근(UDA)을 달성하기 위한 다른 방법을 적극적으로 탐색하기 시작했습니다. 실행 가능한 피싱 접근 방법을 찾을 때 고려해야 할 몇 가지 사항이 있습니다:
이것들이 주요 질문이지만, 물론 더 많은 질문이 있을 수 있습니다. 이러한 요소들이 서로 복합적으로 작용한다는 점을 깨닫게 되면 상황은 더 복잡해집니다. 예를 들어, 클라이언트가 실행 파일이나 DLL의 다운로드를 금지하는 웹 프록시를 가지고 있다면, 페이로드를 컨테이너(ZIP, ISO 등) 안에 넣어야 할 수도 있습니다. 이렇게 하면 탐지 측면에서 나중에 더 많은 문제가 발생할 수 있습니다. 더 강력한 방어는 이를 우회하기 위해 더 복잡한 기술 조합을 필요로 합니다.
이 글은 가상의 대상 조직을 염두에 두고 작성됩니다. 이 조직은 이메일 필터링 규칙, 특정 파일 형식의 다운로드 차단, 엔드포인트에서의 애플리케이션 허용 목록, EDR 솔루션으로서의 Microsoft Defender for Endpoint 등 여러 방어 조치를 사용하고 있습니다.
실제 조직은 이러한 방어 조치 중 전혀 사용하지 않거나, 일부만 사용하거나, 더 많은 방어 조치를 사용할 수 있으며, 이는 이 연구에서 설명된 기술을 단순화하거나 복잡하게 만들 수 있습니다. 항상 그렇듯이, 대상을 잘 알아야 합니다.
XLL은 Microsoft Excel을 위해 특별히 제작된 DLL입니다. 일반인의 눈에는 일반 Excel 문서와 매우 유사해 보입니다.
XLL은 Microsoft Excel(클라이언트 네트워크에서 매우 흔히 볼 수 있는 소프트웨어)에 의해 실행된다는 점에서 UDA에 매우 매력적인 옵션을 제공합니다. 추가적인 이점으로, Excel에 의해 실행되기 때문에 페이로드는 신뢰할 수 있는 응용 프로그램(Excel)이 실행하므로 거의 확실히 애플리케이션 허용 목록 규칙을 우회할 수 있습니다. XLL은 C, C++ 또는 C#으로 작성할 수 있으며, 이는 VBA 매크로보다 훨씬 더 많은 유연성과 성능(그리고 안정성)을 제공하므로 더욱 바람직한 선택이 됩니다.
물론 단점도 있습니다. XLL의 합법적인 사용 사례는 거의 없으므로, 조직이 이메일과 웹 다운로드 모두에서 해당 파일 확장자의 다운로드를 차단하는 것은 매우 쉬운 검사 항목이어야 합니다. 안타깝게도 많은 조직이 이러한 변화를 따라잡지 못하고 있어 XLL은 당분간 실행 가능한 피싱 방법으로 남을 것입니다.
XLL 내에서 코드를 실행하는 데 사용할 수 있는 여러 가지 이벤트가 있으며, 가장 주목할 만한 것은 xlAutoOpen입니다. 전체 목록은 여기에서 확인할 수 있습니다:
XLL을 더블 클릭하면 사용자에게 다음과 같은 화면이 표시됩니다:
이 단일 대화 상자만이 사용자와 코드 실행 사이에 있습니다; 상당히 얇은 사회 공학만으로도 코드 실행은 거의 확실합니다.
명심해야 할 점은 XLL은 실행 파일이므로 아키텍처에 따라 다르다는 것입니다. 즉, 대상을 알아야 합니다. 대상 조직이 사용하는 Microsoft Office/Excel의 버전은 (보통) 페이로드를 빌드할 아키텍처를 결정합니다.
Office 버전에는 비교적 명확한 경계선이 있으며, 이는 경험 법칙으로 사용할 수 있습니다:
Office 2016 이하: x86
Office 2019 이상: x64
각 제품에 대해 다른 아키텍처를 설치하는 것이 가능하지만, 이것이 기본적으로 설치되는 아키텍처이며 대부분의 경우 XLL을 어떤 아키텍처로 빌드할지 결정하는 신뢰할 수 있는 방법이어야 합니다. 물론 전달 방법과 피싱 캠페인에 사용되는 구실에 따라 두 버전을 모두 제공하고 피해자가 자신의 시스템에 맞는 버전을 선택하도록 하는 것도 가능합니다.
이 연구 중에 빌드된 XLL 페이로드는 edparcell의 이 프로젝트를 기반으로 했습니다. 그의 저장소는 Visual Studio에서 XLL을 시작하는 방법에 대한 좋은 지침을 제공하며, 그의 코드를 출발점으로 사용하여 악성 XLL 파일을 개발했습니다.
그의 저장소에서 주목할 만한 차이점은, 자신만의 XLL 프로젝트를 만들고자 한다면 최신 Excel SDK를 다운로드한 다음, README에서 언급된 2010 버전의 SDK 대신 이 버전을 사용하여 이전에 링크된 저장소의 지침을 따라야 한다는 것입니다.
페이로드의 전달은 UDA의 맥락에서 중요한 고려 사항입니다. 두 가지 주요 방법에 초점을 맞출 것입니다:
파일을 첨부하거나 파일을 다운로드할 수 있는 웹사이트 링크를 포함하는 방식으로, 이메일은 UDA 프로세스의 중요한 부분입니다. 수년에 걸쳐 많은 조직(및 이메일 제공업체)은 악성 첨부 파일로부터 사용자와 조직을 보호하기 위해 규칙을 성숙시키고 강화했습니다. 상황에 따라 다르지만, 조직은 이제 다음과 같은 기능을 갖추고 있습니다:
조직의 이메일 규칙을 퍼징하는 것은 작전의 중요한 부분이 될 수 있지만, 레드 팀 작전이 진행 중이며 정보가 적극적으로 수집되고 있다는 신호를 보내지 않도록 항상 주의해야 합니다.
이 글의 목적상, 대상 조직이 XLL 페이로드의 전달을 방지하는 강력한 이메일 첨부 파일 규칙을 가지고 있다고 가정합니다. 웹 전달로 전환해 보겠습니다.
이 공격 벡터에서도 이메일은 여전히 사용되지만, 첨부 파일을 보내는 대신 웹사이트 링크를 보내는 데 사용됩니다. 허용되는 파일 다운로드 유형을 제어하는 웹 프록시 규칙 및 네트워크 완화 조치는 이메일 첨부 파일에 적용되는 규칙과 다를 수 있습니다. 이 글의 목적상, 조직이 웹에서 실행 파일(MZ 헤더)의 다운로드를 차단한다고 가정합니다. 이러한 경우 패커/컨테이너를 탐색할 가치가 있습니다.
기본 아이디어는 실행 파일을 다른 파일 형식 안에 넣어 조직의 정책을 우회하는 것입니다. 여기서 주요 고려 사항은 파일 형식에 대한 네이티브 지원입니다. 예를 들어 7Z 파일은 타사 소프트웨어를 설치하지 않고는 Windows에서 열 수 없으므로 좋은 선택이 아닙니다. ZIP, ISO, IMG와 같은 형식은 Windows에서 네이티브로 지원되며, 추가적인 이점으로 피해자에게 추가 단계가 거의 필요하지 않기 때문에 매력적인 선택입니다.
조직은 불행히도 ISO와 IMG의 웹 다운로드를 차단합니다. 또한 데이터 손실 방지(DLP)를 사용하기 때문에 사용자는 외부 저장 장치를 마운트할 수 없으며, ISO와 IMG도 이에 해당합니다.
운 좋게도, 조직이 MZ 헤더 파일의 다운로드를 차단하더라도 실행 파일이 포함된 ZIP 파일의 다운로드는 허용합니다. 이러한 ZIP 파일은 악성 코드가 적극적으로 스캔되며, 비밀번호로 보호된 ZIP 파일의 경우 사용자에게 비밀번호를 묻는 메시지가 표시됩니다. 하지만 실행 파일이 압축되어 있기 때문에 일반적인 MZ 파일 거부 규칙에 의해 차단되지 않습니다.
ZIP 파일은 XLL 페이로드의 컨테이너로 선택되었습니다. 이유는 다음과 같습니다:
편리하게도, Windows에서 ZIP 파일을 더블 클릭하면 파일 탐색기에서 해당 ZIP 파일이 열립니다:
덜 편리하게는, 압축된 위치에서 XLL 파일을 더블 클릭하면 Windows Defender가 트리거됩니다. 악성 코드가 전혀 포함되지 않은 edparcell의 기본 프로젝트조차도 그렇습니다.
Windows Defender 경고를 보면 단지 일반적인 "Wacatac" 경고입니다:
하지만 이상한 점이 있습니다. 악성으로 식별된 파일은 c:\users\user\Appdata\Local\Temp\Temp1_ZippedXLL.zip\에 있었으며, 우리가 더블 클릭한 C:\users\user\Downloads\ZippedXLL\에 있지 않았습니다. ProcessExplorer에서 Excel 인스턴스를 살펴보면 Excel이 실제로 XLL을 압축 파일에서가 아니라 appdata\local\temp에서 실행하고 있음을 보여줍니다:
이는 ZIP 파일과 관련된 결함으로 보이며, XLL 자체의 문제는 아닙니다. ZIP 내에서 TXT 파일을 열어 메모장으로 열어도 TXT 파일이 appdata\local\temp로 복사되어 거기서 열립니다. 이 위치에서 텍스트 파일을 여는 것은 괜찮지만, Defender는 이 위치에서 어떤 종류의 실제 코드 실행이라도 악성으로 식별하는 것으로 보입니다.
사용자가 ZIP 파일에서 XLL을 추출한 다음 실행하면 아무 문제 없이 실행됩니다. 하지만 사용자가 이렇게 할 것이라고 보장할 수 없으며, 만약 그렇게 하지 않을 경우 AV/EDR을 우회할 수 있을지 확신할 수 없습니다. 게다가 ZIP을 더블 클릭한 다음 XLL을 더블 클릭하는 것이 훨씬 간단하며, 피해자는 ZIP을 추출하는 번거로운 작업보다 이러한 간단한 동작을 완료할 가능성이 훨씬 높습니다.
이 문제로 인해 XLL 대신 다른 페이로드 유형을 고려하기 시작했습니다. VSTO를 탐색하기 시작했습니다. VSTO는 Office용 Visual Studio 템플릿입니다. 해당 글을 꼭 확인해 보시길 권장합니다.
VSTO는 궁극적으로 DLL을 호출합니다. 이 DLL은 모든 것을 시작하는 .XLSX와 함께 로컬에 위치하거나, .XLSX가 http/https를 통해 원격으로 호스트되고 다운로드할 수 있습니다. 로컬 옵션은 실제 이점이 없으며(실제로 VSTO 공격과 관련된 파일이 여러 개 더 있기 때문에 몇 가지 단점이 있음), 원격 옵션은 안타깝게도 코드 서명 인증서가 필요하거나 원격 위치가 신뢰할 수 있는 네트워크여야 합니다. 유효한 코드 서명 인증서가 없기 때문에 VSTO는 XLL 페이로드가 직면한 이 시나리오의 문제를 완화하지 못합니다.
우리는 정말로 구석에 몰린 것 같습니다. XLL 자체를 실행하는 것은 괜찮지만, 조직 정책으로 인해 XLL을 이메일 첨부 파일이나 웹 다운로드를 통해 피해자에게 직접 전달할 수 없습니다. XLL은 컨테이너 안에 패키징되어야 하지만, DLP로 인해 ISO, IMG, VHD와 같은 형식은 사용할 수 없습니다. 피해자는 타사 소프트웨어 없이 컨테이너를 네이티브로 열 수 있어야 하며, 이는 ZIP을 옵션으로 남깁니다. 하지만 앞서 논의한 대로, 압축 폴더에서 XLL을 실행하면 appdata\local\temp로 복사되어 실행되며 AV가 플래그를 지정합니다.
수많은 시간 동안 브레인스토밍과 테스트를 하며 VSTO 토끼굴에 빠져들고 가능한 모든 옵션을 탐색한 끝에, 마침내 너무 어리석어서 작동할 수도 있는 방법을 시도해 보기로 결정했습니다.
이번에는 폴더를 만들고, 그 안에 XLL을 넣은 다음, 폴더를 압축했습니다:
폴더를 클릭하면 XLL 파일이 나타납니다:
XLL을 더블 클릭하면 Excel에서 추가 기능 프롬프트가 표시됩니다. XLL은 여전히 appdata\local\temp로 복사되지만, 우리가 만든 추가 폴더로 인해 한 계층이 더 있습니다:
"사용"을 클릭하면 코드가 실행되며 Defender가 플래그를 지정하지 않습니다:
좋습니다! 코드 실행에 성공했습니다. 이제 무엇을 할까요?
피해자가 XLL을 다운로드하고 실행하도록 유도하는 구실은 조직과 전달 방법에 따라 매우 다양합니다. 주제에는 직원 급여 데이터, 기술에 따른 보상 계산기, 프로젝트 정보, 이벤트 참석자 명단 등이 포함될 수 있습니다. 미끼가 무엇이든, 공격은 피해자에게 약속된 것을 실제로 제공한다면 훨씬 더 효과적일 것입니다. 후속 조치가 없으면 피해자는 의심을 품고 문서를 보안 팀에 제보할 수 있으며, 이는 공격자를 빠르게 노출시키고 대상 시스템에 대한 접근을 제한할 수 있습니다.
XLL 자체는 코드 실행이 완료된 후 빈 Excel 창만 남깁니다. 피해자가 찾고 있는 Excel 스프레드시트를 제공하는 것이 훨씬 좋습니다.
XLSX를 바이트 배열로 XLL 내부에 포함시킬 수 있습니다. XLL이 실행되면 XLSX를 XLL 옆 디스크에 드롭한 후 엽니다. XLSX의 이름은 XLL과 동일하게 지정하되 확장자만 다릅니다.
XLL이 C로 작성되었기 때문에, 이전에 C의 페이로드 기능에 대한 글에서 다룬 기능, 즉 자체 삭제를 가져올 수 있습니다. 이 두 가지 기술을 결합하면 XLL이 디스크에서 삭제되고 동일한 이름의 XLSX가 그 자리에 드롭됩니다. 구분하지 못하는 눈에는 XLSX가 처음부터 그 자리에 있었던 것처럼 보일 것입니다.
불행히도 XLL이 삭제되고 XLSX가 드롭되는 위치는 appdata\temp\local 폴더이며, 원래 ZIP이 있는 위치가 아닙니다. 이를 해결하기 위해 XLSX만 포함된 두 번째 ZIP을 만들고 이를 XLL 내에서 바이트 배열로 읽어올 수 있습니다. 실행 시 앞서 언급한 작업 외에도 XLL은 c:\users\victim\Downloads\에서 원래 ZIP 파일을 찾아 삭제한 후, XLSX만 포함된 두 번째 ZIP을 그 자리에 드롭할 수 있습니다. 물론 사용자가 원래 ZIP을 다른 위치에 저장하거나 다른 이름으로 저장한 경우 실패할 수 있지만, 대부분의 경우 자동으로 사용자의 다운로드 폴더에 드롭될 것입니다.
이 스크린샷은 아래쪽 창에 appdata\local\temp에 생성된 임시 폴더에 XLL과 드롭된 XLSX가 있는 반면, 위쪽 창에는 XLL이 열린 원래 파일 탐색기 창을 보여줍니다. 아래쪽 창에서 XLL의 크기가 0임에 주목하세요. 이는 실행 중에 자체 삭제되었기 때문이지만, 위쪽 창이 닫힐 때까지 XLL 파일은 appdata\local\temp 위치에서 완전히 사라지지 않습니다. 피해자가 XLL을 다시 클릭하더라도 이제는 비활성화되어 실제로 존재하지 않습니다.
마찬가지로, 피해자가 파일 탐색기에서 열린 ZIP을 빠져나오자마자(창을 닫거나 다른 폴더로 이동), spreadsheet.zip을 다시 클릭하면 이제 test 폴더에 importantdoc.xlsx가 있는 것을 발견할 수 있습니다. 따라서 XLL이 제거되고 무해한 XLSX로 대체되어 디스크에 존재하는 두 위치 모두에서 변경됩니다.
이 GIF는 MDE 평가판 VM에서 XLL의 다운로드 및 실행을 보여줍니다. 어떤 이유로 Excel이 여기서 두 개의 인스턴스를 여는 반면, 제 집 컴퓨터에서는 하나만 열렸습니다. 그 이유는 정확히 알 수 없습니다.
항상 그렇듯이, "MDE는 무엇을 볼까?"라고 물어볼 것입니다.
TestMachine11에서 비콘을 다시 잡은 것을 증명하는 빠른 스크린샷 덤프:
먼저, 경고가 전혀 없습니다:
타임라인/이벤트 로그는 무엇을 캡처하나요?
아이고. 솔직히 말하면, 키로깅, 암호화, 자격 증명 해독 경고가 어디서 오는지 전혀 모르겠습니다. 제 코드는 그런 작업을 전혀 수행하지 않기 때문입니다. 우리의 행동은 이렇게 나열되면 확실히 의심스러워 보이지만, MDE가 단일 엔드포인트에서 얼마나 많은 데이터를 수집하는지 다시 언급하겠습니다. 수백, 수천, 수십만 개의 엔드포인트가 EDR에 연결되어 있는 조직은 말할 것도 없습니다. 실제 경고가 발생하지 않는 한, 아마 괜찮을 것입니다.
대부분의 사람들이 아마 기다리고 있던 순간입니다. 제가 개발한 XLL 러너의 코드 샘플을 제공하며, 트레이드크래프트 섹션에서 논의된 부분만 제한합니다. 독자가 실제로 코드를 XLL에 넣고 나머지 러너와 함께 구현하는 것은 독자의 몫입니다. 항상 그렇듯이, 해를 끼치지 말고, 조직을 피싱할 권한을 가지고 있는지 확인하십시오.
파일을 읽어서 바이트 배열에 복사할 수 있는 16진수를 생성하는 프로그램의 소스 코드를 포함했습니다. 사용자에게 제시할 XLSX와 동일한 XLSX가 포함된 폴더가 들어 있는 ZIP 파일에 대해 이 프로그램을 사용하고, 각각의 바이트 배열에 저장하십시오. 이 코드를 다음을 사용하여 컴파일하십시오:``` gcc -o ingestfile ingestfile.c
저는 Kali 머신에서 MingW를 사용하여 XLL을 컴파일하는 데 몇 가지 문제가 있었습니다. 그래서 여기에 명령어들을 게시하기로 했습니다: **x64**```
x86_64-w64-mingw32-gcc snippet.c 2013_Office_System_Developer_Resources/Excel2013XLLSDK/LIB/x64/XLCALL32.LIB -o importantdoc.xll -s -Os -DUNICODE -shared -I 2013_Office_System_Developer_Resources/Excel2013XLLSDK/INCLUDE/
x86``` i686-w64-mingw32-gcc snippet.c 2013_Office_System_Developer_Resources/Excel2013XLLSDK/LIB/XLCALL32.LIB -o HelloWorldXll.xll -s -DUNICODE -Os -shared -I 2013_Office_System_Developer_Resources/Excel2013XLLSDK/INCLUDE/
컴파일한 후에는 새 폴더를 만들고 XLL을 그 폴더에 복사하십시오. 그런 다음 zip을 사용하여 압축하십시오:```
zip -r <myzipname>.zip <foldername>/
이 게시물에서 설명한 전술이 효과를 보려면 코드 조각에 있는 일부 변수를 XLL과 zip 파일의 이름과 일치시켜야 합니다.
Office 매크로의 지배력이 막을 내리면서, XLL은 피싱 캠페인에 매력적인 옵션을 제공합니다. 약간의 창의성을 발휘하면 다른 기술과 결합하여 조직 및 보안 팀이 구현한 여러 방어 계층을 우회하는 데 사용될 수 있습니다. 읽어주셔서 감사합니다. 도움이 되셨기를 바랍니다!