5 ms·
Most PDF "attacks" in the real world are very unsophisticated. One of the most common uses of PDFs in a phishing context is just as a way to deliver a link that
by jcrawfordor 4y ago
Most PDF "attacks" in the real world are very unsophisticated. One of the most common uses of PDFs in a phishing context is just as a way to deliver a link that would likely result in blocking by email security products (many don't inspect inside PDFs, and even for those that do the PDF format is complicated enough that it offers tremendous opportunities for obfuscation). I would wager money that the "PDF attack" involved here was as simple as a link to a malicious executable presented in a PDF to avoid detection by email filtering... in my time as a security analyst this was the #1 source of real compromise incidents, and anecdotally it seems to remain popular today based on the number of such PDFs I receive in my spam email.
The PDF format presents many opportunities for other exploits, either obfuscating a payload or running code, but modern PDF viewers are locking these opportunities down to such a degree that they are not very reliable (most of all because it is difficult to know which PDF viewer your target will use, and many popular PDF viewers today like pdf.js are relatively feature-incomplete which is a significant security advantage in this case). It's possible that something more sophisticated was going on but I would be very surprised if it was anything more complex than using the PDF as an obfuscated transport for a binary packed in it and invoked by the user (e.g. by clicking a link in the PDF with a javascript target). Non-user-interaction PDF vulnerabilities exist but are increasingly hard to come by as there has been more than a decade of work on locking down PDF viewers and the situation has improved dramatically in that time.
Contrary to what people sometimes expect, highly organized groups (such as APTs) tend to stick to very basic, simple methods as much as possible, since they are relatively reliable. The use of recent vulnerabilities in a specific PDF viewer, for example, is high risk due to the likelihood of failure and the opportunities for analysis it presents (you will have to do custom development rather than using off-the-shelf tooling). This is the kind of thing that organized groups try to avoid as much as possible, subject to an ROI analysis. Or in other words, if putting a link to an EXE in a PDF still works, why would you bother with anything else?
- noduerme 4y agoIf it's just a javascript link to download an EXE, doesn't the target of the hack still need to run the EXE? Or are you saying that a link in a PDF can install and execute code on its own? Assuming it can't, then the engineer had to click to run some unknown EXE after downloading it... that should hardly be described as a "PDF attack".
- TechBro8615 4y agoThere is a whole class of attacks related to “deep linking” and custom URL schemes that the operating system can pass to any application that registers itself to match it. At that point the sanitization is up to the application. I recently stumbled upon a nice write-up [0] that described this class of attack and surveyed which software was vulnerable to it. Many crypto clients were included. [0] https://positive.security/blog/url-open-rce https://positive.security/blog/url-open-rce
- zrobotics 4y agoWe had an employee compromised by a similar attack-executable linked in a Pdf. Basic flow was-phisher asked employee to sign a document relating to customs. The phisher had gathered that this employee works with shipping claims and returns, and surmised that they need to deal with customs documents requiring signature. There was a link to an exe hosted on a European cloud service in the PDF titled "install fake signature certificate company to sign this document". This directed to a download of a basic ransomware executable. This did get past our AV to the point of encrypting the employee's machine, but thankfully was blocked from spreading to the rest of the network. The employee's machine was toast, but I was able to restore from the prior day's backup and no major harm occurred. I was able to see the phishing attack since we use gsuite email so the ransom ware didn't erase the employee's inbox, but they did lose a half-day work and I updated our training. The attack itself was clever from a social engineering perspective, but the technical exploit was something any script kiddy could have downloaded from the open web, nothing advanced at all. But Gmail doesn't always scan links in PDFs, so a clever ruse was able to bypass Google's scanning as well as our local scanning.
- stef25 4y agoThe employee clicked on a link asking them to install a security certificate and completed the install?
- chinathrow 4y agoThe way I read it, the employee installed/ran an .exe.