CVE-2024-29824 : Exploring The Remote Code Execution Vulnerability In Ivanti EPM

In recent developments, a significant security vulnerability has emerged within Ivanti Endpoint Manager (EPM), identified as CVE-2024-29824.

This critical flaw allows for remote code execution (RCE), posing a severe risk to systems running the affected software.

The exploit enables attackers to execute arbitrary code on target systems, potentially leading to full system compromise.

This article delves into the technical details of the vulnerability, its implications for cybersecurity, and the measures that can be taken to mitigate its effects.

As organizations increasingly rely on digital solutions for their operations, understanding and addressing such vulnerabilities is crucial.

We will explore how CVE-2024-29824 was discovered, its potential impact, and the steps developers and administrators need to take to secure their systems against this potent threat.

Awesome Web Hacking – A Comprehensive Guide To Tools, Techniques, And Resources

This list is for anyone wishing to learn about web application security but do not have a starting point.

You can help by sending Pull Requests to add more information.

If you’re not inclined to make PRs you can tweet me at @infoslack

Table Of Contents

  • Books
  • Documentation
  • Tools
  • Cheat Sheets
  • Docker
  • Vulnerabilities
  • Courses
  • Online Hacking Demonstration Sites
  • Labs
  • SSL
  • Security Ruby on Rails

Books

  • The Web Application Hacker’s Handbook: Finding and Exploiting Security Flaws
  • Hacking Web Apps: Detecting and Preventing Web Application Security Problems
  • Hacking Exposed Web Applications
  • SQL Injection Attacks and Defense
  • The Tangled WEB: A Guide to Securing Modern Web Applications
  • Web Application Obfuscation: ‘-/WAFs..Evasion..Filters//alert(/Obfuscation/)-‘
  • XSS Attacks: Cross Site Scripting Exploits and Defense
  • The Browser Hacker’s Handbook
  • The Basics of Web Hacking: Tools and Techniques to Attack the Web
  • Web Penetration Testing with Kali Linux
  • Web Application Security, A Beginner’s Guide
  • Hacking: The Art of Exploitation
  • Crypto 101 is an introductory course on cryptography
  • Metasploit Unleashed
  • Security Engineering
  • OpenSSL Cookbook
  • Learn and apply cryptographic techniques.
  • A guide to the key concepts, terminology, and technologies of cybersecurity perfect for anyone planning or implementing a security strategy.
  • Kickstart a career in cyber security by learning how to adapt your existing technical and non-technical skills.
  • A book about cryptographic techniques and Secret Key methods.
  • This practical book is a one-stop guide to implementing a robust application security program.
  • Practical guide to cyber threat hunting.
  • Bug Bounty Bootcamp
  • Hacking APIs
  • A book about building web apps that are ready for and resilient to any attack.

For more information click here.

Security Ninjas AppSec Training – Your Complete Guide To Mastering Application Security

This hands-on training lab consists of 10 fun real world like hacking exercises, corresponding to each of the OWASP Top 10 vulnerabilities.

Hints and solutions are provided along the way. Although the backend for this is written in PHP, vulnerabilities would remain the same across all web based languages, so the training would still be relevant even if you don’t actively code in PHP.

Making the Hands-on Lab Work:

Docker instructions

I would highly recommend that you run the training in a docker container because of the following:

  1. Setting up and destroying the environment would be super easy and quick.
  2. The docker container would be sandboxed which means that the vulnerable application wouldn’t be able to harm the host OS.

Setup:

  1. Setup docker. There are many ways to do this depending on the OS you use.
  2. Make sure docker has been installed correctly by running ‘docker version’.
  3. Start the Application Security Training container by running the following command (I chose port 8899 to avoid port allocation conflicts): ‘docker run -d -p 8899:80 opendns/security-ninjas’
  4. Get the IP address of your container: In my case the command was ‘boot2docker ip’ as I was running docker using boot2docker
  5. Go to your web browser and enter {IP address from step 4}:8899
  6. The training should be running now.
  7. Kill the container after you are done. Go back to the terminal and type ‘docker ps’. Get the container id of the training
  8. Then run ‘docker kill {container id}’

Running it using a web server:

If for some reason you are not able to run the training in a docker container, you may also run it using a web server.

  1. Download a web server (like Apache) and PHP.
  2. Download the source code from here and put it in the directory where the web server looks for files to serve.
  3. In the Security Ninjas sub-directory, change text file permissions – ‘chmod 777 *.txt’
  4. Make sure WHOIS is installed on the web server.
  5. Start the web server and reach the application from your web browser.

The following steps are optional but recommended:

  1. Install Firefox.
  2. Install the FoxyProxy plugin for Firefox. Then:
    • In select mode: Use proxy “Default” for all URLs.
    • Configure the Default proxy to use 127.0.0.1:8080.
  3. You can delete or disable this plugin after the exercise.
  4. Install Burp Suite free from. You could use some other proxy tool as well.
  5. You can get some basic Burp Suite tutorials from
  6. You can turn the proxy off for most of the exercises but for some, having the intercept on would make it much easier to inspect and alter the HTTP requests.
  7. Run the training in Firefox.

jwt_tool : Unlocking JWT Security With The JSON Web Token Toolkit

Discover the power of jwt_tool, a comprehensive toolkit designed for the robust testing of JSON Web Tokens (JWTs).

Perfect for pentesters and developers, this toolkit offers a variety of functions, from validating token authenticity to exploiting known vulnerabilities.

Dive into the capabilities of jwt_tool and enhance your security skills and knowledge.

Its functionality includes:

  • Checking the validity of a token
  • Testing for known exploits:
    • (CVE-2015-2951) The alg=none signature-bypass vulnerability
    • (CVE-2016-10555) The RS/HS256 public key mismatch vulnerability
    • (CVE-2018-0114) Key injection vulnerability
    • (CVE-2019-20933/CVE-2020-28637) Blank password vulnerability
    • (CVE-2020-28042) Null signature vulnerability
  • Scanning for misconfigurations or known weaknesses
  • Fuzzing claim values to provoke unexpected behaviours
  • Testing the validity of a secret/key file/Public Key/JWKS key
  • Identifying weak keys via a High-speed Dictionary Attack
  • Forging new token header and payload contents and creating a new signature with the key or via another attack method
  • Timestamp tampering
  • RSA and ECDSA key generation, and reconstruction (from JWKS files)
  • …and lots more!

Audience

This tool is written for pentesters, who need to check the strength of the tokens in use, and their susceptibility to known attacks.

A range of tampering, signing and verifying options are available to help delve deeper into the potential weaknesses present in some JWT libraries.

It has also been successful for CTF challengers – as CTFs seem keen on JWTs at present.

It may also be useful for developers who are using JWTs in projects, but would like to test for stability and for known vulnerabilities when using forged tokens.

Requirements

This tool is written natively in Python 3 (version 3.6+) using the common libraries, however various cryptographic funtions (and general prettiness/readability) do require the installation of a few common Python libraries.
(An older Python 2.x version of this tool is available on the legacy branch for those who need it, although this is no longer be supported or updated)

Installation

Docker

The preferred usage for jwt_tool is with the official Dockerhub-hosted jwt_tool docker image
The base command for running this is as follows:
Base command for running jwt_tool:
docker run -it --network "host" --rm -v "${PWD}:/tmp" -v "${HOME}/.jwt_tool:/root/.jwt_tool" ticarpi/jwt_tool

By using the above command you can tag on any other arguments as normal.
Note that local files in your current working directory will be mapped into the docker container’s /tmp directory, so you can use them using that absolute path in your arguments.
i.e.
/tmp/localfile.txt

Manual Install

Installation is just a case of downloading the jwt_tool.py file (or git clone the repo).
(chmod the file too if you want to add it to your $PATH and call it from anywhere.)

$ git clone https://github.com/ticarpi/jwt_tool
$ python3 -m pip install -r requirements.txt

On first run the tool will generate a config file, some utility files, logfile, and a set of Public and Private keys in various formats.

Custom Configs

  • To make best use of the scanning options it is strongly advised to copy the custom-generated JWKS file somewhere that can be accessed remotely via a URL.
    • This address should then be stored in jwtconf.ini as the “jwkloc” value.
  • In order to capture external service interactions – such as DNS lookups and HTTP requests – put your unique address for Burp Collaborator (or other alternative tools such as RequestBin) into the config file as the “httplistener” value.
    • Review the other options in the config file to customise your experience.

Colour Bug In Windows

To fix broken colours in Windows cmd/Powershell: uncomment the below two lines in jwt_tool.py (remove the “# ” from the beginning of each line)
You will also need to install colorama: python3 -m pip install colorama

# import colorama
# colorama.init()

For more information click here.

Certiception – Reinventing Network Security With Deceptive Active Directory Certificate Services

Certiception is a honeypot for Active Directory Certificate Services (ADCS), designed to trap attackers with a realistic and attractive bait that triggers highly relevant alerts.

Developed by the SRLabs Red Team, Certiception creates a vulnerable-looking certificate template in your ADCS environment, sets up restrictions to prevent exploitation, and supports in setting up effective alerting.

Originally released at Troopers24, Certiception comes with a strategic guide to effective deception: The Red Teamers’ guide to deception

Background

In our Red Team and Incident Management engagements we regularly observe that lateral movement and privilege escalation go undetected.

If detections trigger at all, they are not reacted to in a timely manner, because false positives are commonplace.

We believe internal honeypots (aka. canaries, aka. deception tech) are an effective way for defenders to catch threats that make it through initial defenses.

Internal honeypots are intentional traps for attackers placed in your network.

They look vulnerable but trigger an alert on exploitation. Here’s why we think deception has great potential:

  • Low effort and cost: Setup can rely on existing tools such as a SIEM.
  • High relevance alerts: A triggered honeypot hints at a significant threat, so the alerts are worth investigating.
  • Low noise: Designed to trigger only on malicious activity, internal honeypots have a low false positive rate.

Despite their potential, we regularly encounter fundamentally ineffective deception setups. To help defenders create more effective honeypots, Certiception comes with an extensive deception strategy guide.

Active Directory Certificate Services (ADCS) is an ideal location for a honeypot:

  1. Easy Access: Accessible by all domain users, ADCS is easy for attackers to discover.
  2. High Stakes: Vulnerabilities can lead to full domain compromise, making exploitation highly attractive.
  3. Common Knowledge: Vulnerabilities and exploitation tools are widely known.
  4. Authenticity: Vulnerable ADCS templates are commonplace, raising little contempt.
  5. Under-Monitored: Many networks barely monitor ADCS, encouraging even cautious attackers to dare exploitation.

This is why we built Certiception.

Concept

Certiception sets up a new CA in your environment and configures an ESC1 honeypot.

It is implemented as an Ansible playbook calling multiple roles. Overall, the following steps are executed:

  • Set up a new CA, add a “vulnerable” ESC1 template and enable it only on the new CA
  • Install and configure the TameMyCerts policy module to prevent issuance if certificate signing requests contain a SAN
  • Enable extended audit log to include template names in event logs
  • Print a SIGMA rule to set up alerting in your SIEM
  • Set up continuous checks with Certify to catch any other CA enabling the vulnerable template (not pushed yet, will be added to the repo in the next days)

Parameters like the CA or template name can be customized to disguise the honeypot.

Lemma – Harnessing AWS Lambda For Scalable Command-Line Tool Execution

The author of this project is not responsible for any damage or data loss incurred as a result of using this software.

Use this software at your own risk. While efforts have been made to ensure the accuracy and reliability of the software, it is provided “as is” without warranty of any kind.

By using this software, you agree to assume all risks associated with its use. Opinions are that of the author and not that of AWS. Review the AWS pentesting policy prior to executing any security tools on AWS Lambda.

Lemma

Lemma is a Python-based AWS Lambda package and client designed to execute packaged command-line tools in a scalable, remote environment on AWS Lambda.

Lemma takes advantage of the new Response Streaming feature on AWS Lambda to stream real-time stdout back to the user as the tool is running. The Lemma project comprises three main components:

  1. Lemma Lambda Function Package: This package bundles a collection of command-line Linux tools provided by the user, making them accessible via AWS Lambda. It allows users to execute these tools remotely and scale their executions across multiple lambda instances.
  2. Web-CLI: This component provides a web-based terminal interface built with xterm.js, AWS Lambda Web Adapter and FastAPI, accessible via the Lambda URL.
    • This web UI allows users to execute their command-line tools packaged in the Lambda entirely within their web browser.
  3. Terminal-CLI: A python-based command-line interface tool in charge invoking the Lemma Lambda function.
    • This tool facilitates the remote execution of the Lambda-hosted tools from a local environment.
      • It pipes stdin and stdout between local and remote tools, providing the ability to execute and scale cli-based workflows onto lambda and back using pipes.

While the intented use case for Lemma is to run verbose security security tooling on AWS lambda, Lemma can be used for any type of command-line tool you wish to run remotely.

Features

  • Supports both a Web-CLI and a Terminal-CLI
  • Quick and easy build script
  • Support for adding your own custom tools
  • Support for x86_64 and ARM64 lambda types
  • Support for choosing memory, region and timeout
  • Flexible terminal piping support

Installation

Requirements For Lemma Lambda

  1. An AWS account
  2. AWS access credentials with permissions to execute cloudformation templates
  3. Docker, python3 with pip

Lambda Build And Deploy Steps

Steps to build and deploy on a fresh Ubuntu 22 instance

  1. sudo apt update
  2. sudo apt install docker.io python3 python3-pip
  3. git clone https://github.com/defparam/lemma
  4. cd lemma
  5. export AWS_ACCESS_KEY_ID=<your access key id>
  6. export AWS_SECRET_ACCESS_KEY=<your secret access key>
  7. ./build.sh
  8. Fill out all the questions
  9. Copy the lambda URL with the key

Web-CLI:

  1. Open chrome and simply browse to your lambda URL w/key

Terminal-CLI:

  1. While in the lemma directory: pip3 install . (The Terminal-CLI is also available on pypi: pip install lemmacli)
  2. Invoke: lemma
  3. When asked about the lambda URL, paste it into the prompt. This URL will be saved at ~/.lemma/lemma.ini

AMSI Bypass via VEH – Technique Using Vectored Exception Handling

A PowerShell AMSI Bypass technique via Vectored Exception Handler (VEH). This technique does not perform assembly instruction patching, function hooking or Import Address Table (IAT) modification.

How It Works:

For this technique to work, you must first inject the VEH DLL into the PowerShell process. This can be done either by injecting the DLL or via DLL hijacking .

This technique works by setting up a hardware breakpoint on the function AmsiScanBuffer on all PowerShell process threads, then installing a VEH to handle the trigger of this breakpoint.

When a thread calls AmsiScanBuffer, the VEH will make the thread to exit the function without executing anything and setting the result of the function to AMSI_RESULT_CLEAN.

This is all done inside the VEH, without modifying the code of the process or without any PE modifications.

Usage:

For demonstration purposes, this repository contains a very basic DLL injector. Use it this way:

  • 1.) Compile the DLL Injector and VEH DLL.
  • 2.) Open an instance of PowerShell.
  • 3.) Run the DLL injector by providing the FULL PATH to the DLL. Example:
./DLL_Injector.exe C:\Windows\Temp\AMSI_VEH.DLL

RedELK – Essential Naming Requirements For Deployment

In the complex landscape of RedELK deployment, adhering to precise naming requirements is crucial for operational success.

This article delves into the essential naming conventions necessary for a smoothly functioning RedELK setup.

From FilebeatID to Redirector configurations, understand the specifics that ensure your cybersecurity infrastructure is effective and efficient.

For a properly working RedELK setup it is required to pay attention to the following requirements.

NameDescriptionSpecifics to pay attention to
FilebeatIDName given to the host by Filebeat.
The name is given during running the install-redir.sh or install-c2server.sh scripts.

For the c2 servers: have the identifier match the name in the mounts/redelk-config/etc/cron.d/redelk and the name passed to install-c2server.sh script

If entered incorrectly during installation, background scripts will fail and implant log files, screenshots and keystrokes will not be accessible via RedELK interface. You can change it in the /etc/filebeat/filebeat.yml config file on the specific host or in mounts/redelk-config/etc/cron.d/redelk on the RedELK server
attackscenarioName of the attack scenario this infra component belongs to.An infra component can only belong to a single attackscenario.

In case of TIBER or the likes this will likely be something like scenario1, scenario2 and scenarioX. Could also be more descriptive, e.g. ransomware, fingain, or your internally used code name.

Name needs to be the same for all other components in the same scenario; it is an important way for filtering within the Kibana interface.

The name is given during running the install-redir.sh or install-c2server.sh scripts. If entered incorrectly during installation, you can change it in the /etc/filebeat/filebeat.yml config file on the specific host.
Redirector backendName given in the config of the redirector application (Apache, HAProxxy, etc) for the backend.Must start with c2 or decoy

Use a descriptive name, e.g. decoy-phishrun1 or c2-https.

Stock Kibana views and dashboards expect the naming standard. Some alarms are hardcoded triggered for these c2* names
Redirector frontendName given in the config of the redirector application (Apache, HAProxxy, etc) for the frontend.Let it be descriptive for you as you will use this in the RedELK interface to understand where traffic was coming in. Better not use spaces in the name.

Kdrill – Unveiling Rootkit Intrusions In Windows 64-Bit Systems

Kdrill is a tool to analyze the kernel land of Windows 64b systems (tested from Windows 7 to Windows 11). Its main objective is to assess if the kernel is compromised by a rootkit.

The code is compatible with python2/3 without dependencies and can perfom checks without Microsoft symbols or Internet connectivity.

For live memory/kernel analysis, the Winpmem driver is used and Kdrill interfaces itself with the driver, another possibility is to connect to a remote GDB server. KDrill can also analyze Full crash dumps and Kernel crash dumps (mainly stored in C:\Windows\MEMORY.DMP) and a fucked version of AFF4 dumps (zip, but not zipped).

Kdrill accesses the physical memory and decodes/re-builds the OS internals structures to explore them, and to verify their intergrity.

The following checks are performed:

  • Loaded modules list
  • Drivers in memory code (compared to on-disk version)
  • Callbacks of kernel objects and internal ntoskrnl lists
  • PlugAndPlay tree and filters
  • FltMgr callbacks
  • KTimers DPC functions
  • IRP driver’s tables
  • Driver signing global variables avec callbacks
  • NDIS filters and callbacks
  • NetIO/FwpkCLNT filtering dispatch
  • Devices and their attached device objects
  • IDT entries
  • PatchGuard initialization and state

Internals

Kdrill retrieves all kernel structures offsets automatically and builds a specific mapping at each execution.

So it doesn’t need symbols or Internet connectivity to resolve them (:wink: disconnected networks).

Most checks verify if the callback or pointed function is in a driver and if the driver is inside a “trust list” I made totally random.

I strongly recommend you to check if those drivers are signed (by a trusted signer)

However, for integrity drivers checks, you will need to have an Internet access to download Microsoft binaries from MS servers in order to diff them. If you already have them in c:\symbols it’s fine too

Rootkits Examples

Some examples of rootkits detections (not all triggers, juste intersting finds).

Winnti

Winnti replaces functions pointers in the NDIS callback of TCPIP. With the cndis command we can identify it:

#>> cndis
 [*] Checking NDIS Firewall layers
  [*] List from fffffa80033d3d70
    Driver      : pacer.sys
    GUID        : {B5F4D659-7DAA-4565-8E41-BE220ED60542}
    Description : QoS Packet Scheduler
    Driver      : wfplwf.sys
    GUID        : {B70D6460-3635-4D42-B866-B8AB1A24454C}
    Description : WFP LightWeight Filter
 [*] Checking NDIS Protocol layers
  [*] List from fffffa8002a71a60
    Name : NDIS6FW
  Callback fffff88003329e50 -> c:\users\toto\appdata\local\temp\tmp1ec3.tmp (not in white list) SUSPICIOUS
  Callback fffff88003329e50 -> c:\users\toto\appdata\local\temp\tmp1ec3.tmp (not in white list) SUSPICIOUS
[...]
    Name : NDISWAN
    Name : WANARPV6
    Name : WANARP
    Name : TCPIP6TUNNEL
    Name : TCPIPTUNNEL
    Name : TCPIP6
    Name : TCPIP
  Callback fffff8800332a660 -> c:\users\toto\appdata\local\temp\tmp1ec3.tmp (not in white list) SUSPICIOUS
  Callback fffff8800332a810 -> c:\users\toto\appdata\local\temp\tmp1ec3.tmp (not in white list) SUSPICIOUS

For more information click here.

LogHunter – A Revolutionary Tool For Session Detection via Event Logs

Opsec tool for finding user sessions by analyzing event log files through RPC (MS-EVEN).

I was once doing a very complex project where there were over 1000 hosts in the infrastructure.

I needed to detect the user session. Running Invoke-UserHunter would have been a huge mistake.

That’s when I came up with the idea that we could extract all the information we needed from Event Logs.

That’s how the LogHunter tool came into being. The tool is able to extract the following events via MS-EVEN protocol: 4624: “An account was successfully logged on.”, 4768: “A Kerberos authentication ticket (TGT) was requested.”, 4672: “Special privileges assigned to new logon.”, 4769: “A Kerberos service ticket (TGS) was requested.”.

These events will give us information about which computer the target user is on. Then hijack that computer and take control of the user.

Requirements

You only have to install impacket. Other modules (e.g. logging, argparse, sys, struct, Queue, Thread, datetime) are standard Python libraries and are installed with Python.

pip install impacket

Usage

See demo video at the end of the README.md 🙂

To use the tool, all you need to do is pass credentials as you would to a regular impacket tool:

python LogHunter.py OFFICE/Administrator:lolkekcheb123!@dc01.office.pwn

After that, the tool will start receiving events from the target computer (in this case, from dc01.office.pwn), writing them to the events.log file (can be overridden with the -outfile parameter).

You can then search for the file using find.sh. You can search by user name, by EventID, or by computer name – whatever you prefer.

./find.sh -file events.log -searchkeyword Administrator