We are excited to announce the release of version 0.3 of our Memory Analysis package, currently in beta. This update introduces two major features: support for prototype Page Table Entries (PTEs) and the ability to enumerate and display Windows services from memory captures.
Windows 10 (version 1507) introduced memory compression, a feature that allows certain memory pages to be compressed and managed by the “MemCompression” process. As a result, in a memory snapshot, some pages may be unavailable because they reside in compressed memory. Memory compression in Windows is optional and can be disabled if desired, but it is enabled by default.
We are excited to announce the release of version 0.2 of our Memory Analysis package, currently in beta, which adds support for memory decompression and reading paged-out memory from pagefiles.
In the example image below, we can see a case where certain registry keys are missing when examining a memory snapshot—these keys are located in memory pages that have been compressed. In the lower part of the image, after enabling memory decompression, the previously missing keys become visible.
We’re excited to announce the release of the new Memory Analysis package, capable of analyzing memory dumps from all Windows versions, from XP to 11, both x86 and x64.
The package will be available to all licenses of Cerbero Suite. Today we’re rolling out the beta for all commercial licenses, and it will be accessible to all licenses once the beta period ends. This new package replaces the previous Windows Memory Analysis package.
We have released the RegHive Format package for all licenses of Cerbero Suite.
This package offers enhanced functionality for exploring Windows Registry hives. It enables detailed inspection of keys and values, and importantly, provides additional insights by displaying the last modification date and time for each key. Moreover, it includes the ability to view security access details for each key, offering a comprehensive overview of the Registry’s structure and access controls.
With the upcoming releases customers with commercial licenses for Cerbero Suite Advanced and Cerbero Engine can verify Microsoft Authenticode signatures on Linux and macOS. Our Authenticode support includes full-chain certificate and time-stamp verification.
In conjunction with our recently extended support for certificate file formats, this provides complete support for inspecting signed Portable Executable binaries.
The only required step to verify Authenticode signatures on non-Windows systems is to install our “Microsoft Authenticode” package from Cerbero Store.
Cerbero Suite has been using its own implementation of Microsoft Authenticode for performance reasons since the very beginning, back in 2012. However, thanks to the recently introduced Cerbero Store we can now offer this feature on systems other than Windows.
We have also exposed Authenticode validation to our Python SDK.
from Pro.PE import * print(PE_VerifyAuthenticode(obj))
Alternatively, scan hooking extensions can check the generated report for the validation scan entries.
Based on RSA’s PKCS7 standard, Authenticode is the technology developed by Microsoft to digitally certify programs and drivers on Windows. Trusted signatures guarantee that the certificate owner is indeed the author of the signed executable, and also that the data itself has not been tampered with by anyone else.
In a default configuration scenario, the operating system considers these signatures during all but three events:
Point two is a weak security measure for the following reasons:
Also the verification is not self evident if done manually using Windows Explorer, as the properties dialog doesn’t show the validity of the certificate until the user clicks the “Details” button. This is highly misleading, because the user might get a false sense of security by just checking whether the executable contains a digital signature.
The upcoming version 0.8.6 of the Profiler introduces support for this technology, allowing users to very quickly access and verify code signing information.
The following screenshot shows a perfectly valid digital signature; all the certificates taken from the Authenticode data have been successfully used to build a trust chain that validates the PKCS7 using the system store, which means that those at the root of the tree have been directly validated by the Windows Certificate Store.
As you can see, the risk factor is set to zero, since the validity of the publisher has been determined. This behavior can be changed from the Risk panel of the options: it is not on by default!
For comparison, the following screenshot shows how an invalid digital certificate is displayed:
In this case the hash is no longer what expected, issuing both a digest and an invalid certificate errors.
Countersignatures are of course supported and I think you’ll be pleased with how fast our implementation is.
Additional resources: