Weaponizing Trust: The Fight Against Signed Malicious Code
Background: During the MITRE ATT&CK Initial Access stage (T1199), attackers often impersonate trusted sources to gain a foothold in the target environment. By originating their activities from what appears to be a legitimate or trusted source, they aim to bypass security mechanisms and evade detection by the operating system's security controls. To achieve this, they may use a signed codebase, which can be obtained through only two methods.
- Steal a legitimate company's code-signing private key.
- Create a fake company and register it as a seemingly legitimate but fictitious entity.
How does code signing works: In code Signing include 4 component
- Certificate Authority (CA)
- Time Stamp Authority (TSA)
- Code Singing System ( Environment where code should be signed )
- End Customer ( The system where it should be verified )
Certificate Authority (CA)
Before obtaining a certificate, the developer/company must reach out to a Trusted Certificate Authority (CA) to generate a public-private key pair. The private key is securely held by the developer and used to sign the hash of the codebase, ensuring its authenticity and integrity before deployment to end users. The Certificate Authority is responsible for verifying the identity of the individual or organization requesting the certificate, ensuring they are legitimate and trustworthy.
Time Stamp Authority (TSA) A timestamp ensures that the code-signing certificate's expiration date or issuance date is recorded. This is important because there may be situations where the company to which the certificate was issued shuts down. The timestamp guarantees that the certificate was valid at the time the code was signed, preventing its misuse even if the certificate expires or the company ceases operations.
Code Obtaining/Signing Flow and Verification: A Certification Authority (CA) is responsible for ensuring the legitimacy of a requesting IT company by verifying its business credentials and performing other checks. Once the CA confirms the legitimacy, it issues a certificate using a root certificate that has been provided by operating system (OS) vendors and other trusted parties.
The CA then delivers the generated certificate and keys to the requesting company. The company signs the hash of its codebase with its private key before deploying the product to end customers.
When customers open the software on their OS, the operating system checks the integrity of the CA's certificate. Since the OS trusts the root certificate provided by the OS vendor, it verifies the CA's certificate. If the verification passes, the OS proceeds to execute or create the process. However, if the verification fails, the OS may display a notification indicating that the software is risky or potentially harmful.
Detection Methods: 1. Use malwareBazaar to export all certificates and, leveraging YARA rules or other signals from the EDR (Endpoint Detection and Response), analyze and check the environment 2. Understand the scope of legitimate activities within your environment, then create a whitelist using Intune and other relevant tools.
Current Trends: Currently, there are three types of certificates: OV (Organization Validation), EV (Extended Validation), and DV (Domain Validation). However, we won't focus on the specific use cases of each. In today's landscape, obtaining such certificates to sign malware requires significant resources, which not all threat actors can afford. If you are planning to harden your environment, a good first step is to restrict the execution of unsigned files.
Happy Hunt and Stay Safe ! J0k3r