octoberfest7/dropspawn_bofDLL 애플리케이션 디렉터리 하이재킹을 사용하여 Beacons을 생성하는 CobaltStrike BOF
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 검색 순서로 넘어갑니다. 이는 일반적으로 문제가 되지 않습니다. WerFault의 애플리케이션 디렉터리가 System32이기 때문입니다.
대상 시스템에서 하이재킹 가능한 DLL 중 하나를 다운로드하세요.
이는 내보내기를 추출하여 페이로드 DLL에 포함시키기 위해 필요합니다. Windows 버전에 따라 DLL이 변경되므로 DropSpawn을 사용하려는 동일한 머신에서 하이재킹 가능한 DLL을 가져오는 것이 중요합니다. 또한 x86 비콘을 실행 중이고 DropSpawn을 사용하여 x64 비콘을 생성하려는 경우 '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은 비콘의 현재 디렉터리를 사용하려고 시도합니다. 경로에 공백이 있으면 따옴표를 사용하세요.
parent - 선택 사항. 새로 생성된 프로세스로 PPID 스푸핑에 사용할 프로세스의 이름. 여러 실행 인스턴스가 다른 권한 수준으로 실행되는 프로세스(예: svchost.exe)가 지정된 경우 DropSpawn은 PPID 스푸핑에 사용할 수 있는 인스턴스를 식별하려고 시도합니다.
예시: dropspawn /root/gitlab/DropSpawn_BOF/dist/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에 자기 삭제 함수를 포함하면 새 프로세스가 생성되어 DLL을 로드하는 즉시 삭제됩니다. 이는 게임 체인저입니다. 일반적으로 DLL을 로드한 프로세스가 계속 실행되는 동안 DLL이 디스크에 잠겨 있기 때문입니다. 자기 삭제 기술이 어떤 이유로 실패하거나(또는 프로세스 생성 실패) DropSpawn은 디스크에서 페이로드 DLL을 삭제하려고 시도하고 결과에 대해 사용자에게 알립니다.
프로세스 인젝션은 일반적으로 원격 프로세스 열기 -> 원격 메모리 할당 -> 원격 메모리 쓰기 -> 원격 메모리 실행 체인을 따르며, 처음에 새 프로세스를 생성하는 대신 기존 프로세스를 사용하는 옵션이 있습니다. DropSpawn은 새 프로세스만 생성합니다. 새로 생성된 프로세스가 셸코드 할당, 쓰기, 실행을 담당하므로 일반적으로 원격 프로세스 인젝션과 관련된 많은 IOC를 피할 수 있습니다.
물론 이 기술은 DLL 페이로드의 품질에 달려 있습니다. 하지만 Windows가 무엇을 보는지 살펴볼 수 있습니다(다음 섹션은 개인용 DropSpawn 버전을 사용하고 비콘을 생성합니다).
이벤트 뷰어 기준으로는 모든 것이 정상으로 보입니다:
MDE에서는 거의 볼 수 없습니다.
DropSpawn 실행:
MDE 로그:
PPID 스푸핑 사용:
PPID 스푸핑 미사용:
두 경우 모두 원래 비콘 프로세스(또한 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 페이로드를 생성하는 데 필수적입니다.
제가 이 기술을 트위터에 처음 게시했을 때, 여러 사람이 대화에 참여하여 POC를 제작했습니다. SecurityAndStuff가 여기에 제작했고, Snovvcrash는 여기에 있습니다.
