Exploit Packs

Overview: The Industrialization of Cybercrime

Between 2007 and 2009, the cybercrime ecosystem underwent a fundamental transformation. Individual, hand-crafted attacks gave way to a specialized, service-based model - the commercial exploit kit. These were packaged PHP applications sold on underground forums that enabled even low-skilled criminals to deploy sophisticated browser-based drive-by download attacks.

The collection contains four exploit pack specimens that document this pivotal era:

Specimen	Language	Key Innovation	Era	Source
Fragus	PHP/MySQL	Affiliate PPI tracking	2008-2009	fragus
ICEPack IE7 mod	PHP	GeoIP + browser fingerprinting	2007-2008	ICEPack
Fiesta3	PHP	Dynamic PDF/SWF exploit generation	2008-2009	Fiesta3
my_poly_sploit	PHP	Polymorphic shellcode, multi-browser	2008	my_poly_sploit

The Business Model

Exploit kits introduced a separation of concerns that mirrored legitimate software industry practices:

┌─────────────────────────────────────────────────────┐
│               Exploit Kit Ecosystem                  │
├─────────────────┬───────────────┬───────────────────┤
│  Kit Developer  │ Kit Operator  │ Traffic Supplier   │
│  (writes code)  │ (rents/buys)  │ (affiliate/seller) │
│                 │               │                     │
│  • Exploit R&D  │ • Hosts kit   │ • Compromises sites │
│  • Updates      │ • Manages C2  │ • Buys traffic      │
│  • Sells access │ • Tracks PPI  │ • Earns per install │
└─────────────────┴───────────────┴───────────────────┘

This specialization dramatically increased the scale and efficiency of cybercrime - each actor could focus on their core competency rather than building entire attack chains from scratch.

Fragus: The SaaS of Malware Distribution

Source: fragus

Fragus exemplifies the affiliate-based Pay-Per-Install (PPI) business model that became the standard for exploit kits. Analysis of its PHP source code and sql.sql database schema reveals architecture remarkably similar to a legitimate SaaS platform.

Database Architecture

The SQL schema exposes the commercial infrastructure:

Table	Purpose	Key Fields
`sellers`	Affiliate management	Unique ID, assigned exploits, custom executables
`donkeys`	Victim tracking (PPI)	IP, OS, browser, country, seller_id
`files`	Payload management	Per-seller executable assignments
`exploits`	Active exploit configuration	Toggle-able per seller

Infection Flow (Pseudocode)

// Fragus landing page - simplified logic
function handle_victim(request):
    ip       = request.remote_addr
    ua       = request.user_agent
    seller   = request.query["id"]      // affiliate tracking parameter

    // Check if already infected (de-duplication)
    if db.query("SELECT * FROM donkeys WHERE ip = ?", ip):
        return redirect_to_benign_page()

    // Fingerprint victim
    os       = parse_os(ua)
    browser  = parse_browser(ua)
    country  = geoip_lookup(ip)

    // Select exploit chain based on fingerprint
    exploits = get_active_exploits(seller, browser, os)

    // Log the victim for PPI accounting
    db.insert("donkeys", {ip, os, browser, country, seller})

    // Serve targeted exploit chain
    return render_exploit_page(exploits, seller.payload_url)

MITRE ATT&CK Mapping - Fragus

Technique	ID	Implementation
Drive-by Compromise	T1189	Visitor to compromised site redirected to kit landing page
Exploitation for Client Execution	T1203	Browser/plugin vulnerabilities exploited for code execution
Ingress Tool Transfer	T1105	Payload downloaded and executed post-exploitation
Deobfuscate/Decode Files	T1140	Multi-stage payload decoding at runtime
System Information Discovery	T1082	OS/browser fingerprinting via User-Agent

ICEPack: Precision Targeting with GeoIP and Fingerprinting

Source: ICEPack

ICEPack demonstrates the technical sophistication of these kits, particularly in victim fingerprinting and targeted exploit delivery. The index.php entry script acts as an intelligent gatekeeper.

GeoIP Targeting System

Using a local GeoIP database (geoip.inc, GeoIP.dat), ICEPack determines the victim's country of origin and checks it against configurable allow/block lists.

Why GeoIP filtering matters:

Revenue optimization - Focus on high-value regions (US, UK, DE) where PPI rates were highest
Evasion - Block IP ranges associated with security researchers or law enforcement
Legal strategy - Some operators avoided infecting machines in their own country to reduce legal risk

Browser Fingerprinting Matrix

ICEPack meticulously parsed User-Agent strings to build a targeting matrix:

Browser	Windows Versions Supported	Exploit Selection
Internet Explorer 6	98, ME, 2000, XP	MDAC, VML, CreateObject
Internet Explorer 7	XP SP2, Vista	IE7-specific exploits
Firefox 1.x-2.x	All Windows	QuickTime, WinZip ActiveX
Opera 9.x	All Windows	Limited exploit set

Modular Exploit Delivery

Based on fingerprinting results, the kit dynamically includes the appropriate exploit module from its exploits/ directory:

// ICEPack exploit selection - simplified logic
function select_exploit(browser, version, os):
    if browser == "MSIE" and version <= 6:
        include("exploits/ie6_mdac.php")
        include("exploits/ie6_vml.php")
    elif browser == "MSIE" and version == 7:
        include("exploits/ie7_createobj.php")
    elif browser == "Firefox":
        include("exploits/ff_quicktime.php")

    // Each exploit module independently attempts exploitation
    // First successful exploit wins - delivers payload

The examined version contained over a dozen modular PHP files, each corresponding to a specific exploit. This modularity allowed easy updates as new vulnerabilities were discovered - the kit operator simply dropped a new PHP file into the exploits/ directory.

MITRE ATT&CK Mapping - ICEPack

Technique	ID	Implementation
Gather Victim Host Information	T1592	Browser, OS, GeoIP fingerprinting
Exploitation for Client Execution	T1203	Targeted exploit selection per browser
Phishing	T1566	Traffic driven via compromised sites or spam links
Obfuscated Files or Information	T1027	JavaScript obfuscation in exploit delivery

Fiesta3: Weaponizing Document Formats (PDF/SWF)

Source: Fiesta3

Fiesta was notable for its exploitation of legitimate document formats - particularly PDF and Flash (SWF). The pdf.php script demonstrates a classic implementation of document-based exploitation.

Dynamic PDF Generation

Rather than serving a static malicious file, Fiesta dynamically constructs PDF documents in memory:

// Fiesta PDF exploit - simplified logic
function build_exploit_pdf(payload_url):
    pdf = new PDFDocument()

    // Build PDF structure with embedded JavaScript
    pdf.add_object(catalog)
    pdf.add_object(pages)

    // The key: an OpenAction that triggers on PDF open
    js_action = create_openaction_js(payload_url)
    pdf.set_open_action(js_action)

    // JavaScript performs version check + memory spray
    // Target: Adobe Reader [Collab API] (CVE-2007-5659)
    javascript = """
        var version = app.viewerVersion;
        if (version < 8.0) {
            // Memory spray: fill heap with padding + payload sled
            var padding = unescape("%u" + "9090" + "%u" + "9090");
            var payload = unescape("{encoded_payload}");
            var block = padding + payload;

            // Spray into predictable memory locations
            var spray = new Array();
            for (var i = 0; i < 1000; i++) {
                spray[i] = block;
            }

            // Trigger vulnerability - execution jumps to sprayed payload
            this.store = Collab["collect" + "EmailInfo"]({subj: ""});
        }
    """

    pdf.embed_javascript(javascript)
    return pdf.render()

Exploitation Chain

┌──────────────┐    ┌──────────────┐    ┌───────────────┐    ┌──────────────┐
│ Victim visits │───▶│ Kit profiles  │───▶│ pdf.php builds│───▶│ PDF opens in │
│ landing page  │    │ Adobe Reader  │    │ exploit PDF   │    │ browser plug │
└──────────────┘    └──────────────┘    └───────────────┘    └──────┬───────┘
                                                                     │
                    ┌──────────────┐    ┌───────────────┐           ▼
                    │ Payload runs │◀───│ Shellcode does │◀───┌──────────────┐
                    │ on victim    │    │ wget/download  │    │ Heap spray + │
                    └──────────────┘    └───────────────┘    │ CVE trigger  │
                                                              └──────────────┘

Key Exploited Vulnerabilities

CVE	Target	Format	Description
CVE-2007-5659	Adobe Reader < 8.0	PDF	Collab API `collectEmailInfo` buffer overflow
CVE-2008-2992	Adobe Reader 8.x	PDF	`util.printf` JavaScript overflow
CVE-2007-0071	Flash Player	SWF	DefineSceneAndFrameLabelData integer overflow

MITRE ATT&CK Mapping - Fiesta

Technique	ID	Implementation
User Execution: Malicious File	T1204.002	PDF served as document requiring Adobe Reader
Command and Scripting: JavaScript	T1059.007	Embedded JS performs version check and heap spray
Exploitation for Client Execution	T1203	CVE-2007-5659 buffer overflow
Ingress Tool Transfer	T1105	Shellcode downloads final payload

my_poly_sploit: Polymorphic Shellcode

Source: my_poly_sploit

The fourth specimen demonstrates polymorphic shellcode generation, where the exploit payload changes its binary signature on every delivery - making signature-based detection nearly impossible.

How Polymorphic Shellcode Works

// Polymorphic payload generation - conceptual
function generate_payload(payload_url):
    // Core payload (static - the actual malicious logic)
    core = fetch_and_run_routine(payload_url)

    // Generate random encryption key for this instance
    key = random_bytes(4)

    // Encrypt the core payload
    encrypted_core = xor_cipher(core, key)

    // Generate a unique decoder stub
    // The decoder varies in register choice, NOP patterns, etc.
    decoder = generate_decoder_stub(key,
        register = random_choice(["eax", "ebx", "ecx", "edx"]),
        nop_style = random_choice(["90", "43 4B", "40 48"]))

    // Every generated instance has a unique binary signature
    return decoder + encrypted_core

Comparative Analysis: Exploit Kit Evolution

Feature	ICEPack (2007)	Fragus (2008)	Fiesta (2008-09)
Business model	Single operator	Multi-affiliate PPI	Multi-affiliate PPI
GeoIP filtering	✅ Allow/block lists	✅ Country tracking	✅ Country targeting
Browser fingerprinting	✅ Detailed UA parsing	✅ OS + browser	✅ Plugin version check
Exploit types	Browser ActiveX/DOM	Browser + plugin	PDF, SWF, browser
Admin panel	Basic statistics	Full affiliate dashboard	Detailed statistics
De-duplication	IP-based	IP + cookie	IP-based
Obfuscation	Moderate JS obfuscation	Standard encoding	Polymorphic shellcode

How Exploit Kits Changed the Threat Landscape

Before Exploit Kits (pre-2006)

Attackers needed to find vulnerabilities, write exploits, build infrastructure, and distribute malware - all as one actor
High technical barrier to entry limited the number of active threats

After Exploit Kits (2007+)

Modular supply chain: exploit developers, kit operators, traffic suppliers, and payload authors all operated independently
Lowered barrier: operators with zero exploit-writing ability could deploy sophisticated attack infrastructure
Scale: a single kit installation could serve thousands of unique exploit combinations per day
Economics: PPI rates of $0.10-$1.50 per install (depending on geography) created a predictable revenue model

Defensive Legacy

The rise of exploit kits forced the security industry into several critical innovations:

Reputation systems - Domain and IP reputation scoring became essential
Web Application Firewalls - Signatures for exploit delivery patterns, not just payloads
Browser sandboxing - Chrome's multi-process architecture (2008) was partly a response to drive-by downloads
Automatic updates - Browsers began auto-updating to close the vulnerability window
Plugin restrictions - Flash, Java, and PDF plugins were progressively restricted and ultimately deprecated