312-50 Question 346
Single answer▪ Web API, Webhooks, and Web ShellDuring an authorized assessment, you discover a web application that lets administrators configure an outbound webhook for build notifications. The application sends a JSON POST to any URL entered in the webhook settings and includes a custom header containing a static bearer token. You also find that the target server hosting the application exposes an upload feature for image files, but uploaded files are stored outside the web root and are not directly executable. Your goal is to demonstrate a realistic attack path that could lead to command execution while minimizing noise and preserving evidence. Which action is the MOST appropriate next step?
- A
Configure the webhook to call an attacker-controlled HTTPS endpoint, capture the bearer token and request structure, then assess whether the same token is accepted by privileged internal Web API endpoints that could trigger server-side actions such as plugin installation or job execution
- B
Upload a PHP web shell disguised as an image and browse directly to the upload path, because web servers typically execute uploaded files if the extension is changed after upload
- C
Use the webhook feature to send repeated large POST requests to an internal host until the server crashes, because denial of service is the safest way to prove remote code execution risk
- D
Modify the webhook URL to use a file:// URI so the application writes a shell script locally on the server, then execute it through the browser
Show answer and explanation
Correct answer: A
Explanation
The key to this scenario is understanding the relationship between webhooks, Web APIs, and post-authentication abuse paths that can ultimately result in command execution. A webhook is an outbound request mechanism, not a shell by itself. In a real engagement, one of the first steps is to capture and analyze the webhook request safely by directing it to infrastructure you control. That lets you inspect authentication material, request headers, payload schema, and origin behavior. If the static bearer token is accepted by other internal or administrative API endpoints, you may be able to pivot into API-driven actions such as job execution, connector creation, or extension management, any of which can become an RCE path depending on the product.
By contrast, a web shell requires successful code placement in an executable context. Since the upload feature stores files outside the web root and they are not directly executable, uploading a shell is not currently a viable path without another vulnerability. This distinction is important in CEH-style questions: not every upload leads to a web shell.
Best-practice references include OWASP guidance on API security and webhook handling. Relevant concepts include validating token scope and authorization (OWASP API Security Top 10, especially broken object level authorization and broken function level authorization), treating webhook secrets or bearer tokens as sensitive credentials, and restricting webhook destinations to prevent abuse such as SSRF. For testing methodology, capturing webhook traffic to validate authentication behavior before attempting privileged API actions is both practical and minimally disruptive.
- A. Correct.
Correct. This is the most realistic and defensible next step. A webhook is an outbound HTTP callback, so pointing it to an attacker-controlled listener is a standard way to inspect the exact request, including headers, token format, and payload. If the bearer token is reusable against other Web API endpoints, that may enable authenticated API abuse, including triggering administrative functions that can lead to code execution depending on the application design. This approach is low-noise, evidence-driven, and aligns with common API testing methodology: validate token scope, test authorization boundaries, and determine whether server-side actions can be initiated through documented or exposed endpoints.
- B. Incorrect.
Incorrect. This reflects a common misconception about file upload exploitation. The scenario explicitly states that uploads are stored outside the web root and are not directly executable. Simply uploading a PHP web shell, even if disguised, does not provide execution unless there is a separate vulnerability such as local file inclusion, unsafe file move, image processing command injection, or server misconfiguration. Browsing directly to the upload path would not work if the files are not web-accessible.
- C. Incorrect.
Incorrect. Intentionally causing a denial of service is generally not an appropriate next step in a standard CEH-style assessment unless explicitly in scope and approved. More importantly, crashing an internal host does not demonstrate remote code execution. It is noisy, operationally risky, and does not help validate the actual exploit path involving the webhook or API.
- D. Incorrect.
Incorrect. This is not a realistic assumption for modern webhook implementations. Webhooks are normally delivered over HTTP or HTTPS, and applications generally do not treat a user-supplied webhook URL as a generic file-write primitive. A file:// URI would typically be rejected, unsupported, or handled by the HTTP client library in a way that does not create a local writable artifact. Even if accepted, it would not imply browser-based execution.