Technical Analysis of a Multi-Stage Adobe Acrobat PDF JavaScript Sample

Overview

This repository publishes a code-centric reverse-engineering write-up on a malicious PDF sample that embeds staged Adobe Acrobat JavaScript. The analyzed sample uses a hidden form field as its initial loader, reconstructs a second-stage JavaScript body through Acrobat stream decoding, performs environment triage and Acrobat-specific interface abuse, establishes network-backed staging, and finally decrypts, decompresses, and executes a deferred third-stage payload. The goal of this repository is defensive analysis and documentation. The focus is on observable behavior, recovered code structure, and attack-chain reconstruction.

Key Findings

• The PDF contains an embedded Stage-1 launcher stored in a hidden form field (Btn1).
• The recovered Stage-2 JavaScript disables optional content groups to reduce visual indicators.
• The sample builds its own privileged execution wrappers around Acrobat APIs such as app.beginPriv() and app.endPriv().
• It performs target triage, including:
  • viewerVersion
  • viewerType
  • platform
  • filesystem-based OS inference
  • PE-header parsing to detect x64 Reader
• It sets up exploit-oriented primitives involving crafted getters and Acrobat-native interfaces such as ANShareFile(...) and ANFancyAlertImpl(...).
• It constructs telemetry-rich beacon URLs for a hardcoded remote endpoint and uses RSS JavaScript feeds as part of its staging flow.
• The final visible loader path is explicit:
  • hex-decode bird1
  • AES-CTR decrypt
  • DEFLATE inflate
  • store as global.final_js
  • execute via deferred eval(...)

Attack Chain Summary

1. PDF JavaScript reads hidden field Btn1
2. Stage-1 decodes and schedules Stage-2
3. Stage-2 initializes obfuscated logic and hides OCG layers
4. Target environment is fingerprinted
5. Acrobat-native exploit-oriented setup is attempted
6. Telemetry and staging channels are prepared
7. The script polls for runtime-populated payload material
8. Encrypted content is decrypted and decompressed in memory
9. A third-stage JavaScript payload is executed through setTimeOut

Why This Sample Matters

The sample is significant because it is not a simple static PDF with embedded script fragments. It behaves like a structured multi-stage loader that:

• qualifies the target environment
• abuses Acrobat-specific privileged functionality
• prepares later payload delivery
• reconstructs follow-up code entirely in memory

That combination makes it relevant both for PDF malware analysis and for studying Acrobat JavaScript trust and staging behavior.

Write-Up

The Write-Up can be found here.