Can't find CAPEv2 version of zer0m0n on GitHub

[scccccccccc]

For some reason I want to analyse samples in kernel mod, so I noticed zer0m0n project, which I can't find a CAPEv2 version on github.

To be honest, I want to capture the implicit loading of dlls with IAT of my malware sample. In my opinion , it requires capemon.dll to be loaded earlier than any other dll, just like what "Early Bird APC" or "EDR Preloading" techs mentioned, so that the hook for NtCreationSection will complete before actions of implicit loading. To achieve this, I noticed that "InjectDllViaIAT" function in capemon project had already put the IID structure of capemon.dll at the beeginning of NewImportDirectory, which may lead to earlier hooking :


but it's also the fact that the calls of NtCreationSection for implicit loading haven't been logged in my experiments.
I also tried mandatory using of InjectDllViaQueuedAPC, which mentioned in "Early Bird APC" tech, but failed too.
In fact, there are still other ways may achieve my goal, like injecting capemon.dll through driver, or directly writing sys file to notify any image loading with PsSetLoadImageNotifyRoutine function, which I haven't tried. Anyway, That's all for later.

Anyway, whether zer0m0n would satisfy me, I'm just curious for the existence of the CAPE ver of it now. The latest version of zer0m0n I found is zer0m0n v1.0, project here: https://github.com/angelkillah/zer0m0n
It just supports cuckoo 2.0.

I also noticed that in "CAPEv2\analyzer\windows\lib\api\process.py", CAPEv2 wants sys files named "zer0m0n_x64.sys" and "zer0m0n.sys", while zer0m0n v1.0 actually offering "zer0m0n-x64.sys" and "zer0m0n-x86.sys", does that mean the version of zer0m0n that offer CAPEv2 compatibility actually exist? Is secondary development of ver 1.0 to "ver CAPEv2" meaningful?

sorry for my bad english

[kevoreilly]

Hi scccccccccc, interesting questions... Firstly to be honest I have never used zer0m0n in cape - it's there more as a legacy of cuckoo-modified. So I can't tell you if it could be made to work or not, sorry about that.

However the subject of usermode analysis is close to my heart, as is the loading of the monitor and process initialisation. The very reason I put the work in to write a new loader centered around InjectDllViaIAT() was to improve the woeful situation in Cuckoo where the ultimate misnomer of a technique 'EarlyBird' was used to inject the monitor. This is demonstrably much later than IAT patching and I have found the IAT patching is able to capture extremely early malicious code which some modern malware uses in dll sideloading of dlls where the malicious code is in the dll's initialisation or 'dllmain'.

I am therefore curious if you have some malware that evades capture and can run NtCreateSection before it's hooked, I would really love to see it! Would you be able to share the hash or sample?

[scccccccccc]

sure~ actually several samples I tested failed to be logged :(

• Huawei JD.zip

  32 bits, implicit loading

  white exe: Huawei JD (Job Description).exe

  black dll: libcef.dll

  sha256: 228b9ad7570860afe0dbf5c337341771fdf6c5b38fea7ff9459bd6eb9a94e098

• Release.zip

  64 bits, implicit loading

  white exe: StarRail.exe

  black dll: StarRailBase.dll

  sha256: 7b34e0b357acf5212bdbfc2a7afa07f5fe8818da642b28ca2ec293999b94c669

• BRC4

  64 bits, implicit loading

  white exe: OneDriveUpdater.exe

  black dll: version.dll

  sha 256: 1fc7b0e1054d54ce8f1de0cc95976081c7a85c7926c03172a3ddaa672690042c

oh, and what's more, I have modified the hook for NtCreateSection as follows:

HOOKDEF(NTSTATUS, WINAPI, NtCreateSection,
	__out	 PHANDLE SectionHandle,
	__in	  ACCESS_MASK DesiredAccess,
	__in_opt  POBJECT_ATTRIBUTES ObjectAttributes,
	__in_opt  PLARGE_INTEGER MaximumSize,
	__in	  ULONG SectionPageProtection,
	__in	  ULONG AllocationAttributes,
	__in_opt  HANDLE FileHandle
) {
	WCHAR FilePath[MAX_PATH];
	//wchar_t *FilePath = (wchar_t *)malloc(32768 * sizeof(wchar_t));
	DWORD PathLength = GetFinalPathNameByHandleW(FileHandle, FilePath, MAX_PATH, FILE_NAME_NORMALIZED);

	NTSTATUS ret = Old_NtCreateSection(SectionHandle, DesiredAccess,
		ObjectAttributes, MaximumSize, SectionPageProtection,
		AllocationAttributes, FileHandle);
	LOQ_ntstatus("process", "Phopiu", "SectionHandle", SectionHandle,
		"DesiredAccess", DesiredAccess, "ObjectAttributes", ObjectAttributes ? ObjectAttributes->ObjectName : NULL,
		"FileHandle", FileHandle, "FilePathLength", PathLength, "FilePath", FilePath);

	if (NT_SUCCESS(ret) && FileHandle && (DesiredAccess & SECTION_MAP_WRITE)) {
		file_write(FileHandle);
	}

	return ret;
}

I used GetFinalPathNameByHandleW so I could know which file had been loaded into memory with its handle, and loq as "u", it works fine like:

the image above showed that I'm actually able to capture dll loading through NtCreateSection. By the way, this sample uses LoadLibrary to explicitly load malicious dll, which happened so late that caused it to be captured, I think. And the infos of it as below:

• APTQ27

  32 bits, dynamic loading with LoadLibrary

  white exe: \reloc\0\autorun.exe

  black dll: \reloc\0\language.dll

  sha 256: d4cfb90a36244ac86c4a9c8f52308c95f010fb9ea02739b56832cfc1b1126ecb