Inline-Execute-PE

면책 조항:

이 프로젝트는 복잡하며, 작동 방식을 이해하고 적절히 테스트하지 않으면 Beacon이 충돌하여 접근 권한을 상실할 수 있습니다!

"설계 고려 사항 및 해설" 섹션까지의 모든 문서를 읽을 것을 강력히 권장합니다!

소개

Inline-Execute-PE는 CobaltStrike용 Beacon Object File(BOF) 모음과 Aggressor 스크립트로 구성된 제품군입니다. 이를 통해 운영자는 관리되지 않는 Windows 실행 파일을 Beacon 메모리에 로드하고 실행하여 출력을 검색하고 Beacon 콘솔에 표시할 수 있습니다.

이를 통해 운영자는 Mimikatz, Dsquery, Sysinternals 도구 등 많은 타사 도구를 디스크에 저장하거나, Donut과 같은 도구를 사용하여 위치 독립 코드로 변환하거나, 새 프로세스를 생성하여 실행할 필요 없이 사용할 수 있습니다.

이러한 실행 파일은 Beacon 메모리에 매핑되어 네트워크를 통해 전송하거나 새 메모리를 할당하거나 매번 새 conhost.exe 프로세스를 생성할 필요 없이 반복 실행할 수 있습니다.

Beacon에 로드된 실행 파일은 CobaltStrike 팀 서버에 연결된 모든 CobaltStrike 클라이언트에서 접근 및 실행할 수 있습니다.

Inline-Execute-PE는 x64 Beacon과 Mingw 또는 Visual Studio로 컴파일된 x64 Windows C 또는 C++ 실행 파일을 대상으로 설계되었습니다. 이 프로젝트는 x86 실행 파일이나 다른 언어로 작성되거나 다른 컴파일러로 컴파일된 x64 실행 파일을 지원하지 않습니다.

설정

저장소를 복제하고 선택적으로 make를 실행하여 BOF를 다시 컴파일합니다.

CobaltStrike 클라이언트에 Inline-Execute-PE.cna를 로드합니다. CobaltStrike가 실행 중인 디렉터리가 사용자가 쓰기 가능한지 확인하십시오. Inline-Execute-PE는 해당 디렉터리에 petable.txt 파일을 생성하여 Inline-Execute-PE가 작동하는 데 필요한 데이터의 가용성을 보장합니다.

명령어

Inline-Execute-PE는 BOF를 실행하는 3개의 대상 노출 명령과 프로젝트 데이터 구조를 조작하는 3개의 내부 명령으로 구성됩니다.

대상 노출:

1. peload
2. perun
3. peunload

내부 데이터 구조:

1. petable
2. peconfig
3. pebroadcast

peload

peload는 Inline-Execute-PE의 시작점입니다. 이 명령은 PE를 Beacon 메모리에 로드하는 데 사용됩니다. 다음 주요 작업을 수행합니다.

1. 지정된 PE를 네트워크를 통해 Beacon으로 전송하거나 대상 머신의 디스크에서 읽을 PE 이름을 전송합니다.
2. Inline-Execute-PE의 수명 주기 동안 필요한 다양한 포인터와 핸들을 보관하는 구조체를 Beacon 메모리에 생성합니다.
3. Beacon에 메모리를 할당하고 RW 보호로 PE를 기록합니다.
4. 사용자 지정 키를 사용하여 PE를 메모리에서 XOR 암호화합니다.
5. 다른 메모리 청크를 할당하고 XOR 암호화된 PE를 복사합니다. 이는 후속 실행을 위해 PE를 "되돌릴" 수 있도록 하는 데 필요합니다.
6. Beacon 아래에 conhost.exe 자식 프로세스를 생성하여 stdin/stdout/stderr를 초기화합니다.
7. stdout과 stderr를 익명 파이프로 리디렉션하여 PE 출력을 캡처할 수 있도록 합니다.

perun

perun은 Inline-Execute-PE의 두 번째 단계입니다. 다음 주요 작업을 수행합니다.

1. 명령줄 인수를 네트워크를 통해 Beacon으로 전송합니다.
2. PE를 메모리에서 XOR 복호화합니다.
3. PE의 Import Address Table을 수정하여 명령줄 인수 및 프로세스 종료와 관련된 특정 API를 후킹합니다.
4. PE 메모리 보호를 RWX로 변경합니다.
5. 자체 스레드에서 PE를 실행합니다.
6. PE의 출력을 캡처하여 CobaltStrike로 반환합니다.
7. PE 메모리 보호를 RW로 되돌립니다.
8. peload 중에 생성된 XOR 복사본으로 PE를 메모리에서 덮어씁니다.

peunload

peunload는 운영자가 PE 사용을 완료했거나 다른 PE를 로드하려는 경우 Beacon 메모리에서 PE를 제거하기 위해 호출됩니다. 다음 주요 작업을 수행합니다.

1. peload 중에 생성된 핸들 및 파일 포인터를 닫습니다.
2. peload 중에 생성된 conhost.exe 프로세스를 종료합니다.
3. PE의 두 복사본을 메모리에서 0으로 채운 후 해제합니다.
4. PE가 Beacon 프로세스에 로드한 DLL을 언로드하려고 시도합니다(선택 사항).

petable

petable은 현재 Beacon에 로드된 모든 PE에 대한 정보를 표시하는 데 사용됩니다.

각 CobaltStrike 클라이언트는 자체 petable을 가지고 있습니다. Inline-Execute-PE는 모든 연결된 CobaltStrike 클라이언트 간의 데이터 동기화를 보장하기 위해 많은 노력을 기울입니다. 자세한 내용은 "설계 고려 사항 및 해설"을 참조하십시오.

peconfig

peconfig는 Inline-Execute-PE 작동 방식과 관련된 옵션을 구성하는 데 사용됩니다. 현재 변경할 수 있는 두 가지 옵션은 다음과 같습니다.

1. Timeout. perun이 PE 실행 완료를 기다리는 시간을 지정합니다. PE에 잘못된 인수가 제공되어 PE가 절대 반환/실행 완료되지 않는 경우를 대비한 안전 장치로 존재합니다. 기본값은 60초이며, 더 오래 실행되는 PE를 수용하기 위해 수정할 수 있습니다.
2. UnloadLibraries. 이 옵션은 peunload가 PE에 의해 로드된 DLL을 Beacon 프로세스에서 해제하려고 시도할지 여부를 제어합니다. 기본값은 TRUE입니다. 일부 PE에서는 DLL이 Beacon 프로세스에서 언로드될 때 문제가 발생하여 Beacon이 충돌할 수 있습니다. 이 경우 PE에 의해 로드된 모든 DLL을 Beacon 프로세스에 그대로 두는 것이 좋습니다. 이는 powershell.exe를 사용할 때 관찰되었습니다(아마도 .Net CLR을 Beacon 프로세스에 로드하기 때문일 수 있음).

pebroadcast

pebroadcast는 클라이언트의 petable 내용을 다른 모든 연결된 CobaltStrike 클라이언트에 수동으로 브로드캐스트하는 데 사용할 수 있습니다.

다른 모든 CobaltStrike 클라이언트는 브로드캐스트된 데이터로 petable을 업데이트합니다. 이 기능은 실제로 필요하지 않을 수 있지만, 혹시 모를 경우를 위해 존재합니다.

사용법

peload를 사용하여 PE를 Beacon 메모리에 로드합니다.

또는 대상 머신에 있는 PE를 새 프로세스를 생성하지 않고 사용하려면 경로와 --local 스위치를 제공합니다.

perun을 호출하고 로드된 PE에 인수를 전달합니다.

인수에서 큰따옴표는 백슬래시를 사용하여 이스케이프해야 합니다.

언로드 중에 DLL 해제 시 문제를 일으키는 PE를 확인한 경우 peconfig를 사용하여 unloadlibraries를 false로 설정합니다.

PE 사용이 완료되면 peunload를 호출하여 Beacon에서 정리합니다.

이제 다른 PE를 Beacon에 로드할 수 있습니다.

perun 시간 초과

PE에 전달하는 명령줄 인수에 주의해야 합니다. 일부 PE는 잘못된 인수가 제공되면 바로 충돌하는 반면, 다른 PE는 무한히 실행되어 프로세스가 계속 실행 중임에도 Beacon이 콜백하지 못하게 할 수 있습니다.

이는 Mimikatz.exe에서 인수 목록 끝에 'exit'을 지정하지 않을 때 확인할 수 있습니다.

...

Inline-Execute-PE는 지정된 시간 초과 값에 도달하면 실행 중인 PE의 스레드를 종료합니다. 이를 통해 Beacon이 정상 통신을 재개할 수 있습니다(perun BOF가 실행을 완료할 때까지 Beacon은 콜백하지 않습니다). 이 Beacon에서 일반 CobaltStrike 명령과 다른 BOF는 여전히 사용할 수 있지만, Inline-Execute-PE는 비활성화됩니다. 이러한 방식으로 실행 중인 PE가 종료되면 Beacon 프로세스에서 stdout 및 stderr가 손상되는 것으로 보이며, 이후 로드된 PE가 제대로 작동하지 않습니다.

PE는 여전히 (그리고 반드시) Beacon 메모리에서 언로드되어야 하지만, petable을 보면 이 Beacon에 더 이상 추가 PE를 로드할 수 없음을 나타낼 수 있습니다.

Inline-Execute-PE로 실행하려는 PE를 테스트하고 perun에 명령줄 인수를 제공할 때 주의를 기울이는 것이 중요합니다. 일부 PE는 다른 PE보다 더 관대합니다.

팁, 요령 및 관찰 사항

다음은 테스트 및 개발 중에 사용자가 Beacon에 로드하려는 특정 PE에 대해 관찰된 사항을 특별한 순서 없이 나열한 것입니다.

1. Powershell.exe에 peunload를 사용하면 UnloadLibraries가 TRUE인 경우 일반적으로 Beacon이 충돌합니다. 이는 Powershell.exe가 CLR을 로드하기 때문인 것으로 생각됩니다.
2. Cmd.exe는 첫 번째 인수로 '/c'를 사용하지 않으면 Beacon이 충돌합니다. 예: 'perun /c cd'는 정상 작동하지만, 'perun cd'는 그렇지 않습니다.
3. Mimikatz.exe는 로드, 사용, 언로드된 후 UnloadLibraries가 첫 번째 peunload 중에 TRUE였던 경우 다시 로드되면 Beacon이 충돌합니다.
4. 일부 PE는 종료 시 도움말 메뉴를 출력하도록 프로그래밍되어 있습니다. 이러한 메시지는 ExitProcess 및 exit() 등의 호출이 후킹되어 ExitThread로 리디렉션되기 때문에 표시되지 않습니다. 이는 PE가 Beacon 프로세스를 종료하지 않도록 하기 위함입니다.
5. 일부 PE는 메모리 해제를 잘 처리하지 못하며 프로세스 종료 시 해제되는 메모리에 의존합니다. PE가 Beacon 프로세스 내에서 실행되므로(따라서 PE가 완료되어도 프로세스가 종료되지 않음), 더 많은 PE가 로드되고 실행됨에 따라 Beacon이 비대해질 수 있습니다. Process Explorer와 같은 도구를 사용하여 테스트 중에 이를 관찰하고 작업 중에 염두에 두십시오.
6. Sysinternals의 PsExec는 작동하지 않는 것으로 보입니다. 실행은 되지만 원격 머신에 대한 핸들이 유효하지 않다고 불평합니다. 실제로 psexec와 같은 것을 사용하려면 CobaltStrike의 socks 프록시와 공격 박스 버전의 psexec를 사용하는 것이 더 나을 것입니다.
7. Inline-Execute-PE를 사용하기 위해 새 비콘을 생성하는 것은 나쁜 생각이 아닙니다. 특히 다양한 PE가 프레임워크 내에서 상호 작용하고 작동하는 방식에 익숙해지는 과정에서 더욱 그렇습니다. 하나는 없음과 같고 둘은 하나와 같습니다.
8. 새 프로세스를 생성할 때의 텔레메트리를 피하면서 LOLBIN을 사용하려면 peload와 함께 --local 스위치를 사용하여 대상 시스템의 디스크에서 읽어오십시오. 이는 버전 문제를 피하는 데도 유용할 수 있습니다.

IOC 및 AV/EDR

Inline-Execute-PE와 관련된 IOC는 다음에 국한되지 않습니다.

1. VirtualAlloc을 사용한 메모리 할당
2. 할당된 메모리의 보호를 RW와 RWX 사이에서 변경
3. 자식 conhost.exe 프로세스 생성
4. 매핑된 PE에 필요한 DLL 로드
5. 실제 PE가 수행하는 모든 작업(예: Mimikatz가 LSASS에 접근하는 등)

AV/EDR

개발 중에 EDR에 대한 완전한 테스트를 수행하지 않았습니다. 부분적으로는 게으름과 부분적으로는 테스트 환경의 부재 때문입니다. 그러나 최신 패치가 적용된 Windows Defender(제 경험상 상당히 좋은 AV 제품)에 대해서는 테스트되었습니다.

Mimikatz.exe는 아마도 Inline-Execute-PE와 함께 사용하기에 가장 의심스럽고 잘 알려진 PE일 것입니다. Windows Defender가 Inline-Execute-PE를 사용하여 실행 중인 Mimikatz를 탐지하는 능력은 Beacon이 실행 중인 프로세스에 따라 달라진다는 것을 발견했습니다.