Full Report
Sometimes on an engagement, you’d like to construct a believable certificate chain, that you have the matching private keys for. An example might be that a mobile app is doing cert pinning, based on attributes of the signing certificate, such as the Canonical Name (CN), serial number, or Issuer, or that you are intercepting an embedded app that only supports a particular algorithm. Whatever the reason, it’s a fairly complicated process if you are not familiar with X509 certificates. And trying to kludge it together with OpenSSL and some shell scripts under time constraints will only make you tear your hair out! While Metasploit can do some of this, it only clones a single certificate and self-signs it, rather than cloning the entire chain. If you need more than that, keep reading!
Analysis Summary
# Tool/Technique: Apostille
## Overview
Apostille is a tool designed to reconstruct believable X.509 certificate chains, including the corresponding private keys, which is often necessary for advanced Man-in-the-Middle (MITM) scenarios, especially when dealing with applications employing certificate pinning based on specific certificate attributes (like CN, serial number, or Issuer). It addresses the limitation of tools like Metasploit, which only clone and self-sign a single certificate.
## Technical Details
- Type: Tool
- Platform: Implied to operate where Java and BouncyCastle libraries are available, often used in conjunction with tools like Burp Suite or Mallet for traffic interception.
- Capabilities: Clones entire certificate chains, generates matching private keys, supports copying certificate attributes (serial number, validity period, extensions), and allows output to PEM format or a Java KeyStore (JKS).
- First Seen: Published October 06, 2017
## MITRE ATT&CK Mapping
- T1557 - Man-in-the-Middle
- T1557.001 - Man-in-the-Middle: SSL/TLS Certificates
- T1027 - Obfuscated Files or Information
- T1027.004 - Obfuscated Files or Information: Stored Credentials (In a specific context—creating seemingly legitimate keys/certificates for injection)
## Functionality
### Core Capabilities
- **Certificate Chain Cloning:** Reconstructs entire certificate chains by cloning attributes from targeted certificates (obtained via URL or JKS).
- **Private Key Generation:** Generates new private keys matching the parameters (algorithm, key size/curve) of the target certificate's public key.
- **Certificate Reconstruction:** Constructs new certificates by copying all attributes and extensions from the target and signs them using the newly generated private key.
- **Chain Signing:** Works through the chain, signing intermediate and end-entity certificates using the private key derived from the corresponding parent certificate.
- **Output Flexibility:** Outputs sequences of PEM-encoded private keys and public keys to stdout, or bundles them into a Java KeyStore (JKS) if an output file name and passwords are provided.
### Advanced Features
- **Attribute Preservation:** Ensures the resulting certificate is "indistinguishable from the original, apart from the actual key values," maintaining critical pinning attributes.
- **Algorithm Support:** Currently supports RSA, DSA, and EC key algorithms for key generation.
- **Trust Store Interaction:** Attempts to locate the necessary CA certificate by first looking for self-signed certificates in the chain root, or by checking the Java Trust Store if necessary (though notes imply potential manual steps might be needed to handle existing CA entries on targets).
## Indicators of Compromise
- File Hashes: N/A (Tool dependent)
- File Names: N/A (Output files are user-defined, often JKS or PEM files)
- Registry Keys: N/A
- Network Indicators: N/A (Functionality is local manipulation of certificate data; network interaction depends on where the target certificate is sourced from or where the resulting certificate chain is deployed.)
- Behavioral Indicators: Execution of Java code utilizing BouncyCastle libraries to manipulate X.509 structures and generate new cryptographic key pairs.
## Associated Threat Actors
- Not explicitly tied to a named threat actor in the context provided; the tool appears designed for penetration testing and red team engagements (as suggested by the context describing engagements and interaction with tools like Burp).
## Detection Methods
- Signature-based detection: Signature generation would be primarily focused on the distribution binaries or scripts implementing the Apostille logic (if those binaries are unique).
- Behavioral detection: Monitoring for applications utilizing the Java BouncyCastle library to programmatically generate new private keys and sign new X.509 certificates based on existing ones.
- YARA rules: Not provided.
## Mitigation Strategies
- **Trust Management:** Ensure only explicitly trusted Root and Intermediate CAs are present in device Trust Stores. Removing legitimate CA certificates from a victim's Trust Store to make room for self-signed/cloned CAs is noted as a theoretical step an attacker might attempt.
- **Certificate Pinning Robustness:** Implement certificate pinning that verifies not just attributes like CN or Issuer, but also stronger identifiers or anchors the trust chain to a highly secure, non-modifiable public root.
- **Runtime Analysis:** Implement application hardening to detect the dynamic loading and use of cryptographic libraries for unauthorized certificate creation/manipulation during runtime.
## Related Tools/Techniques
- **Metasploit (auxiliary/gather/impersonate_ssl):** Mentioned as a less capable alternative that only clones and self-signs a single certificate.
- **OpenSSL/Shell Scripts:** The manual, complex process that Apostille seeks to replace.
- **Burp Suite / Mallet:** Tools that utilize the output generated by Apostille for TLS interception.