Scenario
In this training scenario, we will execute a ransomware payload, running as admin, and with a custom signature. This scenario is not too different from the ‘vanilla’ sample, but utilizes a signed executable.
Often times signed executables are treated is if they are verified to be benign. While it’s true that certified software should all be signed, this is not a bidirectional relationship, and we shouldn’t trust things just because they’re signed. Unfortunately, sometimes that mistake is made.
Identifying it
Aside from the fact that this cert name is a bit odd for training purposes, how does Cyber Crucible know it’s not trustworthy? Cyber Crucible plays it safe and maintains a (group specific) list of trusted certificates. This means that we can easily catch test signing certs, as well as official certs from large CAs like digicerts.
We can see above that even though the file “321d0…” is signed, it’s still not trusted. Since there are no other complex obfuscation techniques used to deploy the attack, we know exactly where it came from!
To confirm the execution method, we can look into the process creations around the time of the incident. What we see confirms that there was no complex exploit method, or even a script! As with other samples, the child process creations are interesting, though. Even though the execution method of the malware itself was obvious, many background processes are started that disable protections and other system settings.
At this point the attack has been contained by Cyber Crucible, but analysis of the related processes is important to find scope of the malicious behaviors. The execution of the unsigned exe alone looks obvious when its laid out by Cyber Crucible, but many times background processes started by something as privileged and protected as Defender would simply be ignored.