↓Skip to main content

meh: Bypass Order, Shellcode Execution and Target OS

·3 mins

Intro #

In the previous post, I briefly introduced my new side project, ‘meh’. This loosely detailed the idea, the current state of the tool and the next steps I was planning.

Since then, I have implemented a collection of new features, slowly ticking away at the previous ’next steps’ list, as well as refactoring some previously existing code.

Priority order for bypasses #

I have added a priority order for bypasses in the event that specific functionality should run before the other. I personally don’t think this will have a major effect, but in my head, logic was telling me “We might as well check if we are in the debugger or a VM first and decide if we want to carry on trying to anything… right?”

With that question in my head, the order was as simple as adding a value in the bypass templates - and once the function calls were being populated in the script, I just order these based on that files value before populating the final agent source code. Done!

Executing Shellcode #

Up to now, the agent didn’t do anything other than starts, falls asleep, and exits. There is no functionality outside of the selected bypasses, which ultimately don’t really do anything right now. To address this, I have implemented a single method of injecting and executing shellcode within the agent. This came with a collection of additional features:

  • CLI arg and interactive prompt, requesting the required shellcode
  • Cleaning and standardising the shellcode, supplied by the user, before placing it in the agent source code for usage. For example, I want to normalise the shellcode down to “aabbccddee” before using, instead of “\xaa\xbb\xcc\dd” etc. Handling this tool side will hopefully reduce possible human error.

I now had a pretty big “issue” which I hadn’t thought of until now… Operating System and Architecture differences. In true “silly me” fashion, I forgot about one of the biggest requirements :D

Handling OS and Architecture Differences #

For now, I have implemented a choice of target Operating System when using the interactive prompts. Right now, these are Windows, Linux and Darwin. This tool will most likely be used to create malicious exe’s, that will help pentesting and red teaming against this more common environment, however as a challenge to myself I want to open up the possibilities and give as many choices as possible.

When selecting one of the OS choices, this value is used throughout the rest of the tool. It helps narrow down the scope of bypasses available (for example, some use CGo and include windows.h files, requiring the Go build compiler to include these and allow usage).

With the OS choice available, this now meant it gave me additional scope for shellcode execution methods, target API’s to choose, methods of identifying debuggers (ptrace in Linux for example, whilst check debug registers in Windows).

It also makes sure the final compiled piece of malware is compiled correctly with regards to GOOS, and the naming convention of the file.

At the moment I haven’t accounted for different architecture, but once implemented - it will allow the user to choose and will (hopefully) allow me to offer a library of shellcode options, with choices limited by the architecture choice (x86, x86_64, ARM, etc).

Coming Up Next #

In the first post, my screenshots showed a ‘w.i.p’ option for obfuscating the code… at the time, it did nothing. But the next will show my ‘obfuscation’ techniques I have started to implement and the differences it is making to the end code result!