Error when compiling with my own exactable: "The magic number in GZip header is not correct. Make sure you are passing in a GZip stream."

[Ogyeet10]

Hello @Ogyeet10 here,

Background

I'm attempting to use LOL to install and persist an application (Payload.exe), which is consistently blocked by Windows Defender despite various attempted workarounds (disabling AV, adding exceptions, etc.). The executable is separate from r77 and LOL and should be persistent on the system.

Issue

After replacing the example executable and code in your LivingOffTheLand project with my Payload.exe and recompiling, the installation on a test VM doesn't seem to run the executable as expected. Manual invocation of the assembly loading script ([Reflection.Assembly]::Load([Microsoft.Win32.Registry]::CurrentUser.OpenSubKey("Software\Microsoft\Internet Explorer").GetValue($Null)).EntryPoint.Invoke(0,$Null)) showed why:

Exception calling "Invoke" with "2" argument(s): "The magic number in GZip header is not correct. Make sure you are passing in a GZip stream."

Suspected Issue

This error suggests a problem with how the executable is compressed (or not compressed). Upon reviewing the post-build process code, I noticed that EncryptFile.exe is used with the -e flag but not again with the -c flag for compression, which seems inconsistent with the process intended to handle GZip streams.

Questions

1. Could the absence of the -c compression flag in the build process be an oversight, or is it intentional?
2. If it's intentional, could you explain the expected configuration to avoid the GZip header error?
3. Whats generating that error? I don't see any GZip related code in that one-liner.

PS. Sorry about all the issues.

Thanks, Aidan

[bytecode77]

Payload.exe has these post build events:

mkdir "$(SolutionDir)Injector\Resources"
xcopy /Y "$(TargetPath)" "$(SolutionDir)Injector\Resources"
"$(SolutionDir)EncryptFile\bin\$(ConfigurationName)\EncryptFile.exe" "$(SolutionDir)Injector\Resources\$(TargetFileName)" -c -e

note the -c -e at the end. This way, Payload.exe is compressed and encrypted, and then stored in resources of the extracting executable. So, if you want to replace Payload.exe, you need to use EncryptFile.exe yourfile.exe -c -e,

One more thing... This is a small PoC that demonstrates LOTL in general and not a readymade tool to "pack" an executable and evade AV. Therefore, it might very well not evade detection, for instance if an EDR scans the process, etc. But I didn't want to put in all this complexity, because this project just shows how to use system binaries to jump from the registry into a hollowed process.

[Ogyeet10]

Thanks for the clarification,

Just to keep you updated, my current goal is to avoid detection primarily from Windows Defender. I understand that LOTL is not designed as a ready-to-use packing tool, which is why I am integrating it with PEunion (with a modified stub) along with some modifications to the LOTL source code to make it FUD (from Windows Defender). I'm just checking if the existing unmodified project would meet my requirements without extensive modifications.

Thank you again for your help. Your advice has been incredibly helpful.

Best regards,

Aidan