'Anything is possible, but nothing is easy." - Bustlin Billy

Jon Lu discloses his steps to trigger a Sensitive Information Exposure issue by starting to analyze a couple of analytic tracking ids and then investigate further a low impact security misconfiguration.

[Word ahead]

During this article, we have tried to keep the overall technical details to a comfortable level for anyone looking to understand how a software security misconfiguration can be spotted, probed, and exploited during a security assessment engagement. As a result, this approach led to a much higher finding outlined with the OWASP Top 10 Web Application Security Risks, A3 Sensitive Data Exposure.

From an attacker's perspective, PII Sensitive Information Exposure has several uses. Threat actors seek personally identifiable information to steal money, compromise identities, or sell them over the dark web for profit.

[Story line]

This finding started with a Blackbox engagement we had. As a part of the initial discovery phase, we began to cover the usual recon steps:

• Conducting Search Engine Discovery Reconnaissance for Information Leakage
• Fingerprinting Web Server
• Reviewing Webserver Metafiles for Information Leakage
• Enumerating Applications on Webserver
• Reviewing Webpage Content for Information Leakage
• Identifying Application Entry Points
• Mapping Execution Paths Through Application
• Fingerprinting Web Application Framework
• Fingerprinting Web Application
• Mapping Application Architecture

Overall, this job's uniqueness came from not using the Burp Proxy, Zap Proxy, or other similar software. We had to do a web assessment from a slightly different perspective, mostly involving writing custom tooling and using other out of band approaches. It was a different engagement than a business as usual web application penetration testing engagement in a nutshell.

Study time : We found this resource a good intro in the matter.


Some of us are coming from a DEV background, and, because of that, we remembered from back in the days that we can use Google Chrome Developer Tools in conjunction with a Google Cloud Shell for building up tooling, probing, and tracking various bits pieces. Also, during the years, the browser's Developer tools feature was improved a lot and became more than a simple console serving development and debugging purposes.

[Hint #1]
If you don't know too much about this subject, you can watch these recordings to have a quick deep dive in.

We used the network feature and inspected the traffic for a while. We noticed an endpoint entry like this:


The target also had a subscription wall where the client was expected to provide some details, and then the user would be allowed to download a pdf document. A pretty common scenario overall.

[Hint #2]
It Is worth mentioning that every time you might encounter a "provide info to download" wall, then that company, in most cases, uses a CRM system to record the action for future marketing purposes.

We started to look into the request/response sequences and we noticed a request like this:


So, basically, they are using a system that attempts to track you through three different ids:

•   elqTrackId=144133acc2c64af5b619876ed63ade25 
•   elqaid=3103 
•   elqat=2 

Besides, the download link format was somehow unusual for us. We decoded it quickly to get a clear picture of what we have here.

Decoded URL

Decoded URL had this format:


The GUIDv4+ token wrapped this way was slightly different from that we seen before, and we decided to label it as a potential way to fingerprint future underlying applications.

The next step was to test for directory indexing. We are usually doing this for two reasons:

  1. Low hanging fruit. It can generate unexpected results.
  2. To test for debugging error messages or stack traces that would expose info regarding the software in use.

This time we've elevated the details provided by a default error message, server-side. Implementing custom error messages is still a reliable configuration to reduce an application attack heat signature for those who wonder.

Oracle Eloqua Default Error Message

Q. Now, what is Oracle Eloqua? A. It is Oracle's CRM, built to orchestrate brilliant campaigns for B2B.

Overall, the Oracle Eloqua CRM has a rich API reference, well documented. We did a quick introspection into how the API reference looks. We got this format.

Oracle Eloqua API

We had to extract all these API endpoints and test them. Thus, to expedite the process, we wrote two straightforward Python scripts to deal with the API endpoints scrapping and probing actions.

[Script #1]


[Script #2]


In the end, we managed to achieve:

a. We got hit an endpoint that returned us a remarkable volume of personal information details, PII. Unauthenticated. High impact.

b. We highlighted the current Oracle Eloqua deployment was configured to support basic authentication instead of a more secure Oauth2.

We threat modeled two attack scenarios, and, as a result of further work around those, we managed to log in—high impact.

  1. A "Spray and Pray" approach involving a decent-sized combination list of usernames and passwords.
  2. A targeted OSINT / Doxing actions aiming to generate a valid set of credentials for this authentication wall.


Complex CRM systems are complicated beasts. Configuring and secure them might require constant effort and a proper set of skills. Companies dealing with PII data type open to paying for enterprise CRM alike solutions should also consider taking an appropriate secure from the design phase approach by:

  1. Performing an initial Thread Modeling against the initial business requirements aiming to identify various anomalies.
  2. Executing an offensive security assessment aiming to outline any real security gaps.
  3. Reviewing the findings, identify the root cause, and deploy broad fixes.
  4. Retesting and confirm fixes.
  5. Considering repeating the security assessment as part of an ongoing security program. The attack vectors evolve, and malicious actors always find novel techniques looking to abuse systems.