Malicious PDF File Used As Delivery Mechanism
Billions of PDF files are exchanged daily and many people trust them because they think the file is "read-only" and contains just "a bunch of data". In the past, badly crafted PDF files could trigger nasty vulnerabilities in PDF viewers. All of them were affected at least once, especially Acrobat or FoxIt readers. A PDF file can also be pretty "dynamic" and embed JavaScript scripts, auto-open action to trigger the execution of a script (for example PowerShell on Windows, etc), or any other type of embedded data.
Today it's slightly different: Most PDF files can be rendered and displayed directly by the operating system or in the web browser. Most dynamic features in PDF files do not work out of the box. Attackers had to find another way to use these trusted documents. The PDF file format is complex and supports many features. One of them is the "Annot" keyword which helps to link an object to a URL by defining a "clickable" zone. Here is an example:
obj 19 0 Type: /Annot Referencing: << /F 4 /Subtype /Link /A << /S /URI /Type /Action /URI (hxxps://firstviewautoservice[.]com//men/Prefer Quotation.zip) >> /Type /Annot /StructParent 100000 /Border [0 0 0] /Rect [228.0958 225.9112 366.9041 265.6779] >>
PDF files are based on "objects" used and objects are linked together to render the document. How to interpret this piece of code? A clickable zone ("/Rect") is defined and an annotation is created ("/Annot") to link the rectangle to a URI ("/SubType Link"). If the victim clicks on the rectangle, the application rendering the PDF file will open the default browser and visit the provided URL. That's what the user sees:
The defined rectangle (the clickable zone) is created on top of the "PREVIEW FILE" button. Guess what will happen?
The link will download a ZIP archive that contains a sample of AgentTesla communication through a C2 on Telegram:
{ "c2": [ "hxxps://api[.]telegram[.]org/bot6455833672:AAEFwznYRFbwog3UBqp13FPbH7YVb236SRI/" ], "rule": "AgentTeslaV5", "family": "agenttesla" }
I wrote a quick and dirty YARA rule to detect such types of PDF documents:
rule PDF_with_annot { meta: description = "Detects the presence of a URL linked to a clickable object in a PDF" author = "Xavier Mertens" strings: $page = "/Type /Page\n" $annot= "/Type /Annot" $link = "/Subtype /Link" $action = "/Type /Action" $uri = "/URI (" $rect = "/Rect [" $pdf = "%PDF-" condition: $pdf at 0 and #page == 1 and #annot < 3 and #link < 3 and $action and $uri and $rect }
Malicious documents with an annotation remain simple and contain usually just one page with a limited amount of annotations (<3). The sample that I spotted has a low VT score (6/60 (SHA256:87455c255848e08c1e95370d6744c196a9d6ba793353312d929e43a4e2c006ea).
Conclusion: a PDF file with a bit of social engineering remains a nice way to deliver malicious content to a user.
[1] https://www.virustotal.com/gui/file/87455c255848e08c1e95370d6744c196a9d6ba793353312d929e43a4e2c006ea
Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key
Reverse-Engineering Malware: Advanced Code Analysis | Singapore | Nov 18th - Nov 22nd 2024 |
Comments