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".
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.
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.
What I don't understand: Why do you let your users run downloaded executables, at all?
And due to a legacy system, we can't rely on windows UAC to prevent these attacks either, this user needed to have a local admin account. Yes, this is a security issue in itself, but needs must.
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?