22 August, 2025

Bypassing Browser PDF Security: Using Embedded JavaScript Forms for Social Engineering

Bypassing Browser PDF Security: Using Embedded JavaScript Forms for Social Engineering
Jordan Bonagura
Author: Jordan Bonagura
Share:

I can say that, since I started my journey at Secure Ideas, I’ve felt extremely fortunate.  Not only because of the excellent work environment, populated by brilliant minds committed to delivering the best penetration testing experiences for our clients, but also because of the opportunity to conduct a wide variety of tests across different industries and sectors.

What do I mean by that? The answer is one week, I might be testing a satellite application; the next, I could be performing tasks related to social engineering.

The other day, while working on a web application penetration testing project, I came across an application with a solid security layer, protecting against various common attacks.  Anyone experienced in web application testing knows that file upload functionality is one of the most heavily scrutinized features.

After a long battle trying to bypass various file extensions and figuring out where the files were being stored through the chat functionality, my curiosity led me to test JavaScript execution embedded within a PDF.  I already knew that, even if the application allowed it, modern browsers would likely block the execution on the client side due to native security features.

Still… Due to my nature and the profession I chose, I decided to test it.  The application accepted the PDF with embedded JS, but, as expected,  the browser blocked it.  My classic cookie pop-up did not appear… So, no cookies for me? I wasn’t satisfied. I thought: “If I can’t get cookies, maybe I can get something else. One thing I’m sure of, I won’t be hungry…

And that's when the idea struck: if the alert( ) function works, why not sprinkle some extra sugar on this dessert and exploit the human factor?

I thought, instead of sending a generic phishing email and hoping the user clicks on it believing they’ve won the lottery, why not integrate it directly into an environment where the user already feels secure.  And that is their own application interface, their domain.

In other words, a social engineering attack that inherits the appearance of legitimacy by originating within the user’s trusted environment.  It seemed not only possible but intriguingly effective.  Also, it seems at least fun, so I decided to go further.

When continuing exploring the idea.  What if I created a prompt telling the user they need to update their password? Something like this on the PDF code:

Or something even more sophisticated: when clicking “OK,” after the pop-up, an interactive form could appear within the PDF on the browser environment with some fields like “old password,” “new password,” and “confirm new password.”  Again, since it is inside the user’s own environment and with a realistic layout, what reason would they have to question its legitimacy?

 

Imagine the above screenshot with a polished appearance matching the company’s branding and color scheme, the user might willingly enter their credentials.  Then, upon clicking a “submit” button those credentials could be sent directly to the attacker.

Most fascinating and crucially, this isn’t limited to PDF editors or viewers, but to modern browsers, which users typically consider “secure,” since most Java Script executions are automatically blocked.  So, in the following examples, I am having the “trustable” browser serving as the vector for this type of attack when JavaScript or form submission is embedded in a seemingly legitimate interface.

An example of this is shown below.  Rather than using app.launchURL( ) function which works only in PDF software or even /URI( ), which allows only static sites, I’m using /S /SubmitForm.  This approach works directly in the browser, is allowed by the default PDF restrictions, and appears fully trustworthy to the user.

As can be seen in the Burp request, the password is being sent over the network through a standard browser, reaching a destination that may simply be waiting to capture the entered credentials.

By exploiting the trust users place in familiar, secure environments within the inclusion of trustable modern browsers, social engineering attacks can bypass security assumptions and manipulate human trust in ways that traditional defenses simply don't account for.

Related Resources