Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
CVE-2025-61882-Oracle-E-Business-Suite-Pre-Auth-RCE-Exploit — Eine kritische Remote-Code-Ausführung-Schwachstelle (RCE) vor der Authentifizierung in Oracle E-Business Suite (Versionen 12.2.3 – 12.2.14) ermöglicht es Angreifern, über bösartige HTTP-Anfragen die volle Kontrolle über verwundbare Server zu erlangen – derzeit wird sie aktiv in freier Wildbahn ausgenutzt. | Kitploit
Tools/GitHubGitHub/adityabhatt3010/cve-2025-61882-oracle-e-business-suite-pre-auth-rce-exploit
SchwachstellenanalyseExploitationForensikWebsicherheitBedrohungsanalyseIncident ResponseLog-Analyse
GitHubadityabhatt3010/cve-2025-61882-oracle-e-business-suite-pre-auth-rce-exploit

CVE-2025-61882-Oracle-E-Business-Suite-Pre-Auth-RCE-Exploit

Repository anzeigen
12vor 10 MonatenNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →

Über

Eine kritische Remote-Code-Ausführung-Schwachstelle (RCE) vor der Authentifizierung in Oracle E-Business Suite (Versionen 12.2.3 – 12.2.14) ermöglicht es Angreifern, über bösartige HTTP-Anfragen die volle Kontrolle über verwundbare Server zu erlangen – derzeit wird sie aktiv in freier Wildbahn ausgenutzt.

Teilen

CVE-2025-61882 - Oracle E-Business Suite Pre-Auth RCE Exploit

Eine kritische Pre-Authentication Remote Code Execution (RCE)-Schwachstelle in Oracle E-Business Suite (Versionen 12.2.3–12.2.14) ermöglicht Angreifern die vollständige Kontrolle über verwundbare Server über manipulierte HTTP-Anfragen — derzeit aktiv in freier Wildbahn ausgenutzt.


TL;DR

CVE-2025-61882 ist eine kritische Pre-Auth-RCE in Oracle E-Business Suite (EBS), die aktiv in Erpressungs-/Datendiebstahl-Kampagnen ausgenutzt wird. Betroffene Versionen: 12.2.3 → 12.2.14. Oracle hat einen Notfall-Advisory mit IOCs (IPs, Shell-Stager-Befehl, SHA-256-Hashes) veröffentlicht. Patchen oder exponierte Systeme sofort abschirmen, mit den bereitgestellten Detektionen jagen und das sichere Python-Skript unten zum Scannen von Logs verwenden. Führen Sie keine öffentlichen PoCs auf Produktionssystemen aus — testen Sie nur in einer isolierten Laborumgebung mit Autorisierung. 🛑🗿

Cover



Warum das wichtig ist

Oracle EBS betreibt kritische Geschäftsfunktionen (ERP, Gehaltsabrechnung, Finanzen, HR). Eine Pre-Auth-RCE in einer webfähigen EBS-Instanz ermöglicht einem Angreifer die Ausführung beliebiger Befehle auf dem Anwendungsserver, potenziell den Zugriff auf sensible Daten, das Ablegen von Webshells und die Exfiltration von Dateien. Diese Schwachstelle wurde in freier Wildbahn bewaffnet und mit Erpressungskampagnen in Verbindung gebracht — es handelt sich um einen realen Geschäftsvorfall, nicht um ein theoretisches CVE. 🔥


Technische Zusammenfassung (kurz)

  • Typ: Pre-Authentication Remote Code Execution (RCE)
  • Produkt: Oracle E-Business Suite (EBS)
  • Betroffene Versionen: 12.2.3 → 12.2.14
  • Angriffsfläche: Webfähige Komponenten — UiServlet, /OA_HTML/-Flows und zugehörige Endpunkte
  • CVSS (ca.): 9.8 — als kritisch behandeln
  • Exploit: Manipulierte HTTP-Anfragen, die zur Befehlsausführung auf dem Anwendungsserver führen; mehrere Exploit-Muster in freier Wildbahn beobachtet

Zeitleiste (komprimiert)

  • Schwachstelle 2025 entdeckt und ausgenutzt.
  • Oracle veröffentlichte kurz nach öffentlichen Exploit-Berichten einen Notfall-Advisory und Patches.
  • Mehrere Anbieter veröffentlichten Detektionsanleitungen und IOCs.
  • Öffentliche PoCs kursierten — mit äußerster Vorsicht behandeln. ⚠️

Beobachtetes Angreiferverhalten (TTPs)

  • Scannen nach EBS-Oberflächen und Versionsoffenlegungen.
  • Senden manipulierter POSTs/Anfragen an UiServlet und /OA_HTML/, um RCE auszulösen.
  • Bereitstellen von Stagern/Webshells und Erzeugen von Reverse Shells (z. B. /bin/bash -i >& /dev/tcp/...).
  • Komprimieren und Exfiltrieren sensibler Dateien, gefolgt von Erpressung und Datenleak-Forderungen.
  • Nutzung von Infrastruktur, die mit bekannten Erpressungsgruppen in Verbindung steht.

Von Oracle bereitgestellte IOCs (sofort verwenden)

Oracle weist darauf hin, dass diese IOCs beobachtete Aktivitäten über mehrere Vorfälle hinweg darstellen (nicht auf CVE-2025-61882 beschränkt). Behandeln Sie jeden positiven Treffer als hohe Priorität.

IPs

  • 200.107.207.26 — Potenzielle GET/POST-Aktivität
  • 185.181.60.11 — Potenzielle GET/POST-Aktivität

Shell-Stager-Muster

  • sh -c /bin/bash -i >& /dev/tcp// 0>&1 — beobachteter ausgehender TCP-Reverse-Shell-Befehl

SHA-256-Hashes (Exploit-/PoC-Artefakte)

  • 76b6d36e04e367a2334c445b51e1ecce97e4c614e88dfb4f72b104ca0f31235d (oracle_ebs_nday_exploit_poc_scattered_lapsus_retard_cl0p_hunters.zip)
  • aa0d3859d6633b62bccfb69017d33a8979a3be1f3f0a5a4bf6960d6c73d41121 (.../exp.py)
  • 6fd538e4a8e3493dda6f9fcdc96e814bdd14f3e2ef8aa46f0143bff34b882c1b (.../server.py)

Betroffene Versionen (zur Betonung wiederholt)

  • Oracle E-Business Suite 12.2.3 — 12.2.14. 🔁

Hochprioritäre Detektions- & Korrelationsregeln (praktische Einstiegspunkte)

TL;DR Das GitHub-Repository enthält passive Detektionsartefakte für CVE-2025-61882 (Oracle E-Business Suite Pre-Auth-RCE). Verwenden Sie diese zum Jagen, Triage und Eindämmen — nicht zum Ausnutzen. 🛑🗿

Eine kurze Description.md (Mini-README) wurde bereits im Ordner detections/ hinzugefügt — prüfen Sie diese Datei für die vollständige Dokumentation und das TL;DR. Diese Top-Level-README fasst nur das Detektionspaket und die Nutzung zusammen, damit Sie schnell loslegen können.

Was in diesem Paket enthalten ist

  • detections/splunk/

    • oracle_cve61882_ioc_traffic.spl — Erkennt Verkehr zu/von Oracle-bereitgestellten IOC-IPs.
    • oracle_cve61882_uiservlet_post.spl — Erkennt verdächtige POSTs an UiServlet / /OA_HTML/ von externen IPs.
    • oracle_cve61882_reverse_shell.spl — Erkennt Reverse-Shell-Prozesserstellung in Endpunkt-Logs.
  • detections/elastic/

    • oracle_cve61882_uiservlet_post.kql — KQL für UiServlet/OA_HTML-POSTs.
    • oracle_cve61882_filehash_detection.kql — KQL zum Abgleich von Oracle-bereitgestellten bösartigen SHA-256-Hashes.
  • detections/scripts/

    • ebs_safe_hunt.py — Sicheres, Offline-Python-Log-Parsing (keine Netzwerkaufrufe, keine Exploit-Ausführung). Gegen Kopien Ihrer Zugriffs-Logs ausführen.
  • detections/Description.md

    • Die Mini-Dokumentation/das TL;DR, das Sie hinzugefügt haben — enthält den vollständigen Kontext, IOCs, betroffene Versionen und Anleitungen.

Schnellstart

  1. detections/Description.md für Kontext und IOCs prüfen. ✅

  2. Die Splunk-.spl-Abfragen in Ihre Splunk-Umgebung einfügen (oder in gespeicherte Suchen/Alarme importieren).

  3. Die KQL-Abfragen in Kibana-/Elastic-Detektionsregeln einfügen.

  4. ebs_safe_hunt.py auf einen Host kopieren, der nur Lesezugriff auf archivierte oder redigierte Logs hat, dann ausführen:

    root@kitploit:~
    python3 ebs_safe_hunt.py /path/to/access.log
    

    Die markierten malicious_ips, servlet_posts, shell_stager und malicious_hash-Ausgaben prüfen und bei Bedarf eskalieren. 🕵️‍♂️

Sicherheit & Regeln für den Einsatz

  • Diese Artefakte sind passive Detektionstools. Führen Sie keine öffentlichen PoCs gegen Produktionssysteme oder Systeme aus, die Sie nicht besitzen/autorisieren dürfen. ⚠️
  • Wenn die Detektion eine bestätigte Kompromittierung zeigt (Datei-Hash-Treffer, Reverse-Shell-Beweise oder Webshell), isolieren Sie den Host sofort und sammeln Sie Forensik.

Tieferer Einblick in die Skripte:

Prinzip: Kombinieren Sie Versionsoffenlegung oder UI-Treffer mit hochvertrauenswürdigen Indikatoren (bösartige IPs, POST an UiServlet/OA_HTML, Reverse-Shell-Prozessstrings, Datei-Hash-Übereinstimmungen, große ausgehende Uploads).

Splunk-Beispiele Verkehr zu Oracle-IOCs erkennen:

root@kitploit:~
index=web_logs OR index=proxy_logs
| where clientip IN ("200.107.207.26","185.181.60.11") OR dest_ip IN ("200.107.207.26","185.181.60.11")
| stats count by clientip, dest_ip, uri, method, useragent, _time
| sort - count

UiServlet/OA_HTML-POSTs von externen IPs erkennen:

root@kitploit:~
index=web_logs sourcetype=access_combined
| where (uri LIKE "%UiServlet%" OR uri LIKE "%/OA_HTML/%") AND method="POST"
| where NOT cidrmatch("10.0.0.0/8", clientip)  // adjust for your internal ranges
| stats count by clientip, uri, useragent, _time
| sort - count

Reverse-Shell-Prozesserstellung erkennen (EDR):

root@kitploit:~
index=endpoint_events sourcetype=os_process
| where process_cmdline LIKE "%/bin/bash -i%/dev/tcp/%" OR process_cmdline LIKE "%/dev/tcp//%"
| table _time host user process_name process_cmdline parent_process

Elastic-/KQL-Beispiele UiServlet-verdächtiger POST:

root@kitploit:~
http.request.method : "POST" and (http.request.uri : "*UiServlet*" or http.request.uri : "/OA_HTML/*") and not client.ip : ("10.0.0.0/8")

Datei-Hash-Erkennung:

root@kitploit:~
event.type: "file" and file.hash.sha256 : ("76b6d36e04e3...", "aa0d3859d66...", "6fd538e4a8e3...")

Sigma (tragbare Regelideen)

  • Regel: POST an UiServlet//OA_HTML/ von externen IPs → hohe Priorität
  • Regel: Prozesserstellung mit /bin/bash -i >& /dev/tcp/ → kritisch
  • Regel: Datei-Hash-Übereinstimmung für die drei SHA-256-Hashes → bestätigte Kompromittierung

Sicheres Detektionsskript (Python) — gegen Logs verwenden (keine Exploits, keine Netzwerkaufrufe)

Dieses Skript parst Web-Zugriffs-Logs im Combined-Format und markiert verdächtige UiServlet/OA_HTML-POSTs, Anfragen von Oracle-gelisteten bösartigen IPs, Shell-Stager-Muster und Vorkommen der bereitgestellten SHA-256-Hashes. Es führt keine Netzwerkaktivität durch und führt keinen Exploit-Code aus.

root@kitploit:~
#!/usr/bin/env python3
"""
ebs_safe_hunt.py — Safe log parser for CVE-2025-61882 indicators.

Usage:
    python3 ebs_safe_hunt.py /path/to/access.log

Notes:
 - Parses Apache/Nginx combined log lines.
 - Flags UiServlet/OA_HTML POSTs, malicious IPs from Oracle advisory,
   shell stager patterns, and observed SHA256 hashes.
 - Safe: no network / no exploit execution.
"""

import sys
import re
from collections import Counter, defaultdict

# Regex for common combined log format
LOG_PATTERN = re.compile(
    r'(?P<ip>\S+) \S+ \S+ \[(?P<time>.*?)\] "(?P<method>\S+) (?P<uri>\S+) \S+" (?P<status>\d{3}) (?P<size>\S+) "(?P<ref>[^"]*)" "(?P<ua>[^"]*)"'
)

# Oracle-provided IOCs
MALICIOUS_IPS = {"200.107.207.26", "185.181.60.11"}
MALICIOUS_HASHES = {
    "76b6d36e04e367a2334c445b51e1ecce97e4c614e88dfb4f72b104ca0f31235d",
    "aa0d3859d6633b62bccfb69017d33a8979a3be1f3f0a5a4bf6960d6c73d41121",
    "6fd538e4a8e3493dda6f9fcdc96e814bdd14f3e2ef8aa46f0143bff34b882c1b",
}
SHELL_PATTERN = "/bin/bash -i"  # we search for this substring (reverse shell style)
SUSPICIOUS_PATHS = ["UiServlet", "/OA_HTML/"]

# Optional: list of suspicious user-agents often used by scanners
SUSPICIOUS_UAS = ["curl", "wget", "python-requests", "nikto", "sqlmap", "masscan", "Nmap"]

def analyze_log(path):
    ip_counts = Counter()
    uri_counts = Counter()
    ua_counts = Counter()
    suspicious = defaultdict(list)

    with open(path, "r", errors="replace") as fh:
        for line_no, line in enumerate(fh, 1):
            m = LOG_PATTERN.search(line)
            if not m:
                # Optionally, still check for hashes or shell pattern in unstructured lines
                if any(h in line for h in MALICIOUS_HASHES):
                    suspicious["malicious_hash_lines"].append((line_no, line.strip()))
                if SHELL_PATTERN in line or "/dev/tcp/" in line:
                    suspicious["shell_pattern_lines"].append((line_no, line.strip()))
                continue

            ip = m.group("ip")
            method = m.group("method")
            uri = m.group("uri")
            ua = m.group("ua")
            size = m.group("size")

            ip_counts[ip] += 1
            uri_counts[uri] += 1
            ua_counts[ua] += 1

            # 1) Malicious IPs (Oracle)
            if ip in MALICIOUS_IPS:
                suspicious["malicious_ips"].append((line_no, ip, method, uri, ua))

            # 2) POSTs to suspicious EBS paths
            if method.upper() == "POST" and any(p in uri for p in SUSPICIOUS_PATHS):
                suspicious["servlet_posts"].append((line_no, ip, uri, ua))

            # 3) Suspicious user agents (scanners)
            if any(k.lower() in ua.lower() for k in SUSPICIOUS_UAS):
                suspicious["suspicious_ua"].append((line_no, ip, uri, ua))

            # 4) Very large responses (possible exfil) — tune threshold for your environment
            try:
                if size != "-" and int(size) > 5_000_000:  # >5MB
                    suspicious["large_responses"].append((line_no, ip, uri, size))
            except ValueError:
                pass

            # 5) Shell stager pattern or /dev/tcp patterns in the line
            if SHELL_PATTERN in line or "/dev/tcp/" in line:
                suspicious["shell_stager"].append((line_no, ip, uri, line.strip()))

            # 6) Known malicious file hashes present in logs (if available)
            for h in MALICIOUS_HASHES:
                if h in line:
                    suspicious["malicious_hash"].append((line_no, ip, uri, h))

    return {
        "ip_counts": ip_counts,
        "uri_counts": uri_counts,
        "ua_counts": ua_counts,
        "suspicious": suspicious
    }

def pretty_report(r, top=10):
    print("\n=== EBS HUNT REPORT ===\n")
    print("Top source IPs:")
    for ip, c in r["ip_counts"].most_common(top):
        print(f"  {ip}: {c}")
    print("\nTop URIs:")
    for uri, c in r["uri_counts"].most_common(top):
        print(f"  {uri}: {c}")
    print("\nTop User-Agents:")
    for ua, c in r["ua_counts"].most_common(top):
        print(f"  {ua}: {c}")

    print("\nSuspicious findings:")
    if not r["suspicious"]:
        print("  None found.")
        return

    for k, items in r["suspicious"].items():
        print(f"\n-- {k} ({len(items)} matches) --")
        for item in items[:100]:
            print("  " + " | ".join(map(str, item)))

if __name__ == "__main__":
    if len(sys.argv) != 2:
        print("Usage: python3 ebs_safe_hunt.py /path/to/access.log")
        sys.exit(1)
    path = sys.argv[1]
    result = analyze_log(path)
    pretty_report(result)

So verwenden Sie es: Kopieren Sie ebs_safe_hunt.py auf einen Host mit Lesezugriff auf archivierte oder kopierte Logs. Ausführen:

root@kitploit:~
python3 ebs_safe_hunt.py /path/to/access.log

Die markierten malicious_ips, servlet_posts, shell_stager und malicious_hash-Ergebnisse prüfen und angemessen eskalieren. 🕵️‍♂️


Sofortige Schadensbegrenzung & Eindämmungs-Checkliste (praktisch)

  • Patchen: Wenden Sie Oracles Notfall-Patch gemäß Advisory für alle EBS-12.2.3–12.2.14-Installationen an. Befolgen Sie die erforderliche CPU-Reihenfolge. ✅
  • Wenn Sie nicht sofort patchen können: Blockieren Sie den öffentlichen Zugriff auf die EBS-Oberfläche (Firewall, WAF, auf VPN/vertrauenswürdige IPs beschränken). 🔒
  • IOCs an der Peripherie blockieren: Blockieren Sie 200.107.207.26 und 185.181.60.11 sowie alle anderen vom Anbieter gelieferten IOC-IPs/Domains.
  • Jagen: Führen Sie die obigen Splunk-/Elastic-Hunts und das sichere Python-Skript über Logs aus.
  • EDR/AV: Suchen Sie nach den drei SHA-256-Hashes und Webshell-Artefakten; isolieren Sie Hosts bei Fund.
  • Forensik: Erfassen Sie Speicher- und Festplatten-Images für verdächtige Hosts; bewahren Sie Logs auf.
  • Zugangsdaten: Rotieren Sie Service-/Admin-Zugangsdaten nach der Eindämmung.
  • Rechtliches/Kommunikation: Bereiten Sie eine Vorfallmeldung vor, wenn regulierte Daten exfiltriert wurden.

Führungs-Briefing (Einseiter — kopieren/einfügen)

Betreff: Kritisch: CVE-2025-61882 — Oracle E-Business Suite — Sofortiges Handeln erforderlich

Was: Kritische Pre-Auth-RCE (CVE-2025-61882) in Oracle EBS (12.2.3–12.2.14). In Datendiebstahl-/Erpressungskampagnen ausgenutzt.

Sofortige Anforderungen (nächste 24 Stunden):

  • Bestätigen, ob EBS-12.2.3–12.2.14-Instanzen existieren.
  • Wenn ja: Oracles Notfall-Patch jetzt anwenden oder externen Zugriff auf diese Instanzen blockieren.
  • Oracle-IOCs blockieren und Anbieter-Feeds in die SOC-Detektion aufnehmen.
  • SOC: Priorisierte Hunts ausführen (UiServlet/OA_HTML-POSTs, bösartige IPs, Reverse-Shell-Muster, Datei-Hash-Übereinstimmungen).
  • Bei IOC-Treffern: Host isolieren, Forensik sammeln, Rechtsabteilung benachrichtigen.

Risiko: Hoch — potenzielle vollständige Kompromittierung des Anwendungsservers, Datenexfiltration, regulatorische Exposition. Fazit: Jetzt patchen oder abschirmen. — 🗿


Abschließende Hinweise & Warnungen

  • Öffentliche PoCs existieren und sind bewaffnungsfähig. Führen Sie sie nicht auf Produktions- oder Drittsystemen ohne schriftliche Autorisierung aus. Verwenden Sie nur isolierte Labore. ⚠️
  • Oracles IOCs repräsentieren beobachtete Aktivitäten über mehrere Vorfälle hinweg — einige Indikatoren können sich auf verwandte Angriffe beziehen. Untersuchen Sie Treffer mit Kontext, aber eskalieren Sie alle positiven Übereinstimmungen.
  • Versionsoffenlegung ist verrauscht — korrelieren Sie Versionsbeweise immer mit hochvertrauenswürdigen Exploit-Indikatoren, bevor Sie eine Kompromittierung feststellen. 📌

Abschiedsnotiz

Sie haben alles, was Sie brauchen: die Übersicht, IOCs direkt von Oracle, praktische Hunts und ein sicheres Skript für den Triage-Start. Patchen oder schirmen Sie Ihre EBS-Systeme ab, lassen Sie die IOC-Hunts durch Ihr SOC laufen und isolieren Sie alles, was verdächtig aussieht. Bleiben Sie wachsam, patchen Sie schnell und zeigen Sie Ihre Incident-Response-Muskeln. 🗿🔥


Tool herunterladen