CSharpScripts is a curated collection of offensive-security proof-of-concept C# scripts demonstrating reflective PE loading, shellcode execution and .NET assembly analysis, documented here for authorized red teamers and defenders.
| Tool | Arno0x/CSharpScripts — collection of C# offensive proof-of-concept scripts for reflective PE/shellcode injection and .NET assembly inspection |
| Category | Offensive security PoC scripts (.NET / C#) |
| Primary Use | Authorized red team training and defensive research into in-memory execution of PE files and shellcode, plus .NET assembly enumeration with parseAssembly.cs |
| Safe Use | Educational analysis and documentary review for authorized penetration testers and defenders operating in labs or sanctioned engagements against systems they own or are contracted to test |
| Telemetry Note | The scripts run entirely in memory and leave minimal disk artifacts; defenders should watch for csc.exe compilations with the /unsafe flag, suspicious System.IO.Compression references, proxy egress to unexpected hosts, and reflective loading behavior in EDR telemetry |
CSharpScripts is a small but historically instructive repository from the researcher publishing as Arno0x0x0x on Twitter, gathering roughly 344 stars on GitHub and written entirely in C#. The author frames it candidly in the README: some entries are forks or adaptations of other people's work, retuned to fit specific needs or simply to learn and improve. That framing matters, because the real value of the collection is pedagogical rather than operational — each script isolates one technique from the reflective-execution tradecraft of the mid-2010s and demonstrates it in the plainest possible form. For a defender or an apprentice red teamer, this is close to ideal source material: small, readable, single-purpose code.
The first script, bfDecryptShellcode.cs, is described by its own author as a "little dumb and probably not very useful PoC," and that self-deprecation is actually the interesting part. The script brute-forces the decryption of a multi-byte XOR encrypted shellcode blob, then loads the recovered payload into memory and executes it. The correctness signal is an MD5 hash of the decrypted payload, which serves as the marker that the proper key has been found. The README notes the companion project ShellcodeWrapper as the natural producer of both artifacts. Analytically, the script is a lesson in key-search validation: without the hash oracle, a brute-force loop over XOR keyspace would have no way to distinguish a correct decryption from garbage, since XOR decryption always produces output and only one key produces meaningful output.
The second entry, parseAssembly.cs, is the most defensible and arguably most generally useful script in the repo, and the one with the broadest audience beyond offensive teams. It is a console application that dynamically loads a .NET assembly — either an exe or a dll — from a local file path or from a remote URL, optionally accepting content that is base64 encoded. Once loaded, it enumerates the assembly's types, methods and properties using reflection. The README gives two invocation shapes: parseAssembly.exe myAssembly.dll for local files and parseAssembly.exe http://some.site.com/myAssembly base64 for remote, encoded content. For malware analysts and reverse engineers this is a lightweight reconnaissance aid when triaging an unknown managed binary, and it needs no offensive context at all to justify its existence.
The heart of the collection is the set of scripts adapted from the well-known work of Casey Smith, publishing as @subTee, on reflectively injecting a PE or shellcode into the calling process. peloader.cs loads a base64-encoded x64 PE file into the process's own memory and reflectively executes it, with the payload passed as a hardcoded base64 string variable at the top of the file. The README is explicit that the hardcoding is deliberate — this is a compile-time-payload design, not a loader with arguments, which makes each compiled binary a bespoke artifact. That design choice has detection implications defenders should internalize: no command-line payload arguments means no suspicious process arguments, shifting the detection burden to compile-time telemetry and memory scanning.
shellcodelauncher.cs follows the same pattern for raw shellcode instead of a full PE: the payload is embedded as a byte array in a variable, and the script maps it into the calling process's memory and transfers execution. The README mentions that the array can be generated with msfvenom using its -f csharp output format, which is the standard way offensive tooling emits C#-ready byte arrays. For the defensive reader, the takeaway is that csharp-format shellcode emission is a well-established format contract between generators and launchers, and spotting it in tooling or in analyzed samples is a reliable indicator of intent. We deliberately omit any payload-generation workflow here; the documentary point is the mechanism, not a recipe.
The most forensic-relevant entry is runfromzipinmemory.cs, which the author describes as derived from Smith's Netkatz work. The README contains a genuinely interesting defensive observation: the author discovered that the local antivirus (McAfee in their corporate environment) was configured not to analyze the contents of ZIP archives, on the assumption that malicious content would be caught on extraction to disk. The script defeats that assumption by loading everything into memory and using reflection to execute a PE directly from process memory — never touching disk. The author notes the double effect: the AV stays silent, and from a forensic perspective the visibly running process looks innocuous. This is the canonical fileless-execution argument, and it is worth reading precisely because it explains why disk-centric AV architectures lost ground to memory-centric EDR.
netPEloader.cs extends the same idea with an adaptation story that is itself educational. The author took Smith's Netkatz proof of concept — which downloads and runs a credential-auditing PE straight in memory — and hit three real-world obstacles in a corporate environment: an authenticating proxy requiring NTLM credentials, URL categorization blocking the original hosting site, and proxy-level AV inspection catching the downloaded artifact. Their modifications were correspondingly pragmatic: system proxy and default Windows credential support for egress, relocation of the hosted payload to an innocuous-looking file-sharing domain, and prepending roughly 64 KB of random bytes to the PE header region to break signature-based detection at the proxy. Note carefully what this narrative documents: a 2016-era evasion defeating signature scanning, not a technique that survives modern behavioral EDR, and an obvious IOC in the form of an abnormally oversized binary with a garbage prefix.
Every script in the repo compiles with the stock C# compiler that ships with the .NET framework on Windows 7 and later, invoked as csc.exe with the /unsafe flag from the Framework64 path. That compile story is itself a detection lesson: csc.exe spawning with /unsafe and /reference:System.IO.Compression.dll on an endpoint that has no developer tooling is a high-signal event, and blue teams hunting through process telemetry will find it a durable pivot point long after the resulting binary is forgotten. The repo publishes source rather than binaries, which means nothing here executes without a deliberate local build step by the operator.
Pulling the code for study is a one-liner: git clone https://github.com/Arno0x/CSharpScripts. The benign analysis entry point, once built, is simply parseAssembly.exe someAssembly.dll against any managed binary you already own. Nothing in this article should be read as guidance for deploying the injection scripts against systems you do not own or are not contracted to test — the reflective loaders in particular are the kind of tooling that, used without authorization, crosses straight into criminal territory in most jurisdictions.
Where does this collection fit today? It is dated by modern standards — the techniques predate AMSI-aware tradecraft, ETW-based coverage and mainstream memory-scanning EDR — and that is exactly why it remains worth reading. It captures the foundational vocabulary of in-memory execution on Windows in a few hundred lines of readable C#, and the README's honest engineering commentary (why the AV missed the ZIP, why the proxy caught the download, why the hash oracle was needed) teaches more per line than most contemporary frameworks. For defenders building detection content and for red teamers learning what their tooling actually does under the hood, CSharpScripts is a compact primary source, and the @subTee lineage it documents is a thread worth following through the history of the discipline.
Arno0x/CSharpScripts.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.