gmh5225/cs-dropspawn_bofCobaltStrike BOF로 DLL 애플리케이션 디렉터리 하이재킹을 사용해 Beacon을 실행
DropSpawn은 DLL 하이재킹의 비교적 알려지지 않은 방법을 통해 추가 Beacon을 생성하는 데 사용되는 CobaltStrike BOF입니다. x86-x86, x64-x64, x86-x64 및 그 반대 방향으로 작동합니다. 프로세스 인젝션의 대안으로 사용하세요.
Windows 실행 파일은 DLL 검색 순서를 따르며, 절대 경로가 지정되지 않은 DLL을 로드하려고 시도합니다:
DLL 하이재킹은 일반적으로 다음 중 하나를 요구합니다:
A. 사용자가 실제 DLL이 있는 폴더보다 검색 순서 우선순위가 높은 폴더에 쓰기 권한이 있는 경우
또는
B. 해당 DLL이 시스템 어디에도 존재하지 않는 경우, 사용자의 %PATH% 변수에 있는 사용자 쓰기 가능 폴더(예: %USERPROFILE%\appdata\local\microsoft\windowsapps)에 배치할 수 있는 경우.
이러한 요구 사항은 C:\Windows\System32에 있는 실행 파일에 대한 DLL 하이재킹을 배제합니다. 왜냐하면 이러한 실행 파일이 로드하는 거의 모든 DLL도 System32에 있기 때문입니다. System32 실행 파일을 사용자 쓰기 가능 위치에 복사하여 실행하는 것도 옵션이지만, 대체 위치에서 실행되는 System32 바이너리는 식별하기 쉽기 때문에 OPSEC 측면에서 안전하지 않습니다.
DropSpawn은 "애플리케이션이 로드된 디렉토리"를 사용자가 지정한 임의의 디렉토리로 스푸핑하여 System32 실행 파일(및 기타 사용자 쓰기 불가 폴더에서 발견되는 실행 파일)을 사용한 DLL 하이재킹을 가능하게 합니다.
DropSpawn의 공개 릴리스는 비공개 릴리스와 약간 다릅니다. 비공개 릴리스는 독점 페이로드 생성기를 활용하여 운영자에게 훨씬 더 원활한 경험을 제공합니다. 공개 릴리스는 사용자가 각자의 방식으로 DLL 하이재킹 호환 페이로드를 생성한다는 점을 고려하여 약간 수정되었습니다. 사용자가 DropSpawn을 통합하고 무기화하는 데 도움이 되도록 Python3 스크립트와 데모 DLL용 소스 코드가 포함되어 있습니다.
절대 경로를 지정하지 않고 DLL을 로드하려고 시도하는 대상 실행 파일을 식별합니다. exe를 사용자 쓰기 가능 디렉토리에 복사하고 Procmon으로 모니터링하면서 실행하면 됩니다. 이 예에서는 일반적으로 C:\Windows\System32\WerFault.exe에 있는 WerFault.exe를 사용합니다.
위 예에서 cryptsp.dll, wer.dll, dbghelp.dll 및 bcrypt.dll은 모두 절대 경로가 WerFault 내에 지정되지 않았기 때문에 적합한 후보입니다. 결과적으로 WerFault는 나머지 DLL 검색 순서를 사용하기 전에 먼저 애플리케이션 디렉토리에서 해당 DLL을 로드하려고 시도합니다. WerFault의 애플리케이션 디렉토리가 System32이기 때문에 일반적으로 이는 문제가 되지 않습니다.
대상 시스템에서 하이재킹 가능한 DLL 중 하나를 다운로드합니다.
이는 해당 DLL의 내보내기를 추출하여 페이로드 DLL에 포함시키기 위해 필요합니다. Windows 버전 간에 DLL이 변경되므로 DropSpawn을 사용하려는 동일한 머신에서 하이재킹 가능한 DLL을 가져오는 것이 중요합니다. 또한 x86 beacon을 실행 중이고 DropSpawn을 사용하여 x64 beacon을 생성하려는 경우, 'C:\windows\system32...' 대신 'C:\windows\sysnative...'를 지정하여 실제 DLL의 x64 버전을 다운로드해야 합니다.
다운로드한 DLL과 원하는 페이로드 아키텍처를 전달하여 generate_dll.py를 실행합니다. Generate_dll.py는 이 스크립트의 수정 버전입니다. 제공된 DLL을 파싱하고, DLL의 내보내기가 포함된 .def 파일을 생성한 다음, MingW를 호출하여 데모 페이로드 DLL을 컴파일합니다. 생성된 프로세스가 스푸핑된 DLL 내의 실제 함수를 호출하려고 하면, 페이로드 DLL은 System32에 있는 실제 DLL로 호출을 전달하여 호스트 프로세스가 충돌하지 않도록 합니다.
생성된 페이로드 DLL을 사용하여 dropspawn을 호출합니다.
dropspawn <payload DLL> <x86|x64> <spawn할 프로그램> [쓰기 가능한 대상 폴더] [부모 프로세스]
payload DLL - 생성된 DLL 페이로드의 전체 경로.
architecture - 생성하려는 프로세스의 아키텍처
program to spawn - 생성하려는 프로세스의 이름/경로. 이 프로세스가 System32(또는 syswow64)에 있는 경우 이름만 지정하면 됩니다. 그렇지 않으면 전체 경로를 지정하세요. 프로세스에 명령줄 인수를 제공할 수도 있습니다. 경로에 공백이 있거나 인수를 사용하는 경우 전체를 따옴표로 묶으세요.
writable target folder - 선택 사항. 비워 두면 dropspawn은 Beacon의 현재 디렉토리를 사용하려고 시도합니다. 경로에 공백이 있으면 따옴표를 사용하세요.
parent - 선택 사항. 새로 생성된 프로세스와 함께 PPID 스푸핑에 사용할 프로세스 이름. 권한 수준이 다른 여러 인스턴스가 실행 중인 프로세스(예: svchost.exe)가 지정된 경우, dropspawn은 PPID 스푸핑에 사용할 수 있는 프로세스를 식별하려고 시도합니다.
예: dropspawn /root/dbgcore.dll x64 "WerFault.exe -u -p 4352 -s 160" C:\users\user\appdata\local\temp explorer.exe
이렇게 하면 페이로드 DLL 'dbgcore.dll'이 'c:\users\user\appdata\local\temp\dbgcore.dll'에 디스크로 드롭되고, 명령줄 인수 '-u -p 4352 -s 160' 및 부모 프로세스로 explorer.exe를 사용하여 x64 WerFault.exe 프로세스가 생성됩니다.
정리는 쉽습니다. 디스크에 드롭되는 페이로드 DLL에 Self-Deletion 함수를 포함하면, 새 프로세스가 생성되어 DLL을 로드하는 즉시 삭제됩니다. 일반적으로 DLL을 로드한 프로세스가 계속 실행되는 한 DLL이 디스크에서 잠겨 있기 때문에 이는 획기적인 변화입니다. Self-Deletion 기술이 어떤 이유로 실패하거나(또는 프로세스 생성이 실패하는 경우) DropSpawn은 디스크에서 페이로드 DLL을 삭제하려고 시도하고 어느 쪽이든 작업 결과를 사용자에게 알립니다.
프로세스 인젝션은 일반적으로 원격 프로세스 열기 -> 원격 메모리 할당 -> 원격 메모리 쓰기 -> 원격 메모리 실행 체인을 따르며, 기존 프로세스를 사용하는 대신 시작 부분에 새 프로세스를 생성하는 옵션이 있습니다. DropSpawn은 새 프로세스만 생성합니다. 새로 생성된 프로세스가 셸코드 할당, 쓰기 및 실행을 담당하므로 일반적으로 원격 프로세스 인젝션과 관련된 많은 IOC를 피할 수 있습니다.
이 기술은 물론 DLL 페이로드의 품질에 달려 있습니다. 하지만 Windows가 무엇을 보는지 살펴볼 수 있습니다(다음 섹션은 비공개 버전의 DropSpawn을 사용하고 Beacon을 생성하는 경우입니다).
이벤트 뷰어와 관련해서는 모든 것이 정상으로 보입니다:
MDE에는 볼 수 있는 것이 거의 없습니다.
dropspawn 실행:
MDE 로그:
PPID 스푸핑 사용 시:
PPID 스푸핑 없이:
두 경우 모두 원래 beacon 프로세스(또한 werfault)가 dbgcore.dll을 디스크에 드롭하고, 새 WerFault.exe 프로세스를 생성하며, 새로 생성된 프로세스가 dbgcore.dll을 로드한 다음 이름을 변경(삭제)하는 것을 볼 수 있습니다. 중요한 점은 DLL 하이재킹과 함께 자주 발생하는 dbgcore.dll에 대한 추가 조사가 없다는 것입니다. 왜냐하면 자주 하이재킹되는 위치에 쓰지 않고, WerFault.exe(또는 선택한 프로세스)가 WmiPrvSE.exe와 같은 방식으로 DLL 하이재킹과 연관되지 않기 때문입니다.
흥미롭게도 PPID 스푸핑을 사용하면 사용하지 않을 때보다 거의 더 가시적입니다. 다만 이는 보안 제품에 따라 다를 수 있습니다.
언급했듯이, 사용자는 DropSpawn을 사용하려는 대상 머신에서 실제 DLL을 다운로드하는 것이 필수적입니다. 잘못된 버전의 DLL을 사용하면 생성된 프로세스가 존재하지 않는 함수를 호출하려고 할 때 충돌할 수 있습니다.
DropSpawn은 System32 외부의 실행 파일과도 사용할 수 있습니다. 그러나 프로세스가 실제 애플리케이션 디렉토리에서 추가 DLL을 로드하려고 하면 문제가 발생할 수 있습니다. 애플리케이션 디렉토리를 다른 곳으로 스푸핑했기 때문에, 실제 애플리케이션 디렉토리가 DLL 검색 순서를 통해 도달할 수 없는 경우 프로세스는 필수 DLL을 찾을 수 없어 충돌하거나 시작에 실패합니다. 프로덕션에서 사용하기 전에 항상 개발 머신에서 잠재적 하이재킹을 테스트하세요!
이 연구는 프로세스가 최종 DLL 검색 순서를 어떻게 구성하는지 탐구하면서 시작되었습니다(실행 파일이 다른 디렉토리에 있고 현재 디렉토리가 검색 경로의 일부이기 때문에 런타임에 결정되어야 함). 제 연구는 이 포럼 게시물로 이어졌고, 이 기법의 핵심인 두 가지 중요한 문서화되지 않은 API의 기원이 되었습니다.
이미 앞서 링크되었지만, 로더 잠금 회피에 관한 게시물, DLL 프록시용 .def 파일 생성 스크립트, 실행 중인 실행 파일의 자체 삭제 활성화 연구는 DropSpawn에 적합한 효과적이고 무기화된 DLL 페이로드를 생성하는 데 필수적입니다.
이 기법을 Twitter에 처음 게시했을 때, 여러 사람이 대화에 참여하여 POC를 제작했습니다. SecurityAndStuff가 이 POC를 제작했고, Snovvcrash는 여기에 자신의 POC를 두었습니다
