RecipeCONSTRUCTEDUntested
A gzip-compressed, base64-encoded PowerShell stage
Two operations for the layer that sits inside most PowerShell loaders: base64 that decodes to binary starting with 1F 8B. Recognise it on sight, then read the script inside.
2 operationschecked 2026-09-26
You are looking at this when
A script that calls FromBase64String and passes the result to IO.Compression.GzipStream, or a long base64 string that begins H4sI. That prefix is the gzip header, 1F 8B 08, as base64.
How it was checked
The sample was built and checked in Python: gzip with a fixed timestamp, then base64, and the reverse gives back the output shown. The recipe JSON has not been loaded into CyberChef by whoever wrote this page, so load it once with the sample before relying on it.
- 1From Base64
- 2Gunzip
[
{
"op": "From Base64",
"args": [
"A-Za-z0-9+/=",
true,
false
]
},
{
"op": "Gunzip",
"args": []
}
]Sample input (constructed)
H4sIAAAAAAAC/w3KsQ2AMAwEwFVe6VmAJSiprWBCJIIj+yME08PVt3qlTstgH0TKdgV9ZOqGoBQFb5vBowayNIX9y3YIyls7TnnU0wdgBImcQwAAAA==
Expected output
Write-Output "constructed stage two: this came out of a gzip layer"
Recognising it before you decode it
Every gzip stream begins with the same two bytes, 1F 8B, followed by 08 for the
deflate method. Base64 turns those three bytes into the four characters
H4sI. Once you have seen it, you will spot it in scripts, in command lines,
and in the middle of event 4104 records, and you will know the next layer is
compressed before you decode anything.
When it is Deflate rather than gzip
Loaders that use IO.Compression.DeflateStream instead of GzipStream produce
raw deflate with no header, so there is no H4sI and Gunzip fails. Swap the
second operation for Raw Inflate and try again.
When the output is more of the same
It usually is. A decoded stage frequently contains another base64 string and another call to the same decompression. Add the two operations again, and repeat until the output stops being encoded. Do not run anything you decode; reading it here is the point.