With this blog post I am pleased to announce the publication of a new ERNW White Paper about our incident analysis and digital forensics framework. It is available on our website.
Due to the increasing number and impact of computer security incidents, it has become essential to develop and implement efficient measures for their investigation. However, comprehensive forensic analyses are time-consuming, and this time is often not available to security analysts during computer security incidents. As a result, automated tools are increasingly being used. These tools, however, often cover only a limited scope of the necessary analyses and typically require deep technical expertise to be used effectively.
When looking at security measures in Microsoft Entra ID environments, a common
recommendation is to implement Conditional Access policies.
Whether Conditional Access is implemented can be quickly checked, and you can
put a check mark next to it in your best-practice compliance form. However,
simply implementing conditional access will not provide much security. A
phishing attack that we recently analyzed highlights this very well.
In a recent incident response project, we had the chance to virtually look over
the attackers’ shoulder and observe their activities. The attackers used the
Remote Desktop Protocol (RDP) for lateral movement within the compromized
environment and beyond (MITRE techniques
T1570,
T1021). As a matter of fact,
RDP creates cache files that contain tiles of the transferred screen recording
data. While this fact is well-known and there are existing tools, we found it
worth reporting because of two different aspects:
I’m happy to announce the publication of the paper
Windows memory forensics: Identification of (malicious) modifications in memory-mapped image files
at this years DFRWS USA, and the release of the corresponding
volatility plugin.
With this research came also an update to the Ptenum family (affecting
especially the ptemalfind plugin), which makes the plugins reliable in
identifying modified pages despite memory combining, so make sure to grab the
newest version from the Github repository.
Process Hollowing is a technique used by various malware families (such as
FormBook, TrickBot and Agent Tesla) to hide their malicious code within a benign
appearing process. The typical workflow for setting up such a
hollowed process is as
follows:
Create a new process (victim) using a benign executable, in suspended state.
Unmap the executable from that process.
Allocate memory for the malicious executable at the address of the
previously mapped victim executable.
Write the malicious executable to the new memory area and potentially apply
relocations.
Adjust the entry point.
Resume process.
We will refer to this as the “normal” Process Hollowing workflow. There are also
variants of this technique, one being to not unmap the original executable and
to allocate the new memory somewhere else. We will call this one no-unmap. But
wait, why does malware not simply overwrite the existing executable but creates
a new memory area which stands out due to its characteristics? In this blog post
we will have a closer look at this overwrite approach but also on the no-unmap
method, their effects on analysis/detection tools and on some tricks to make the
detection harder. We are also releasing Proof of Concept implementations of all
mentioned tools/plugins (the links are at the end of this post).
Last year, the CISO of a customer sent me a laptop for analysis. The reason was
that he feared the company could have been victim of industrial espionage.
Starting in spring 2020, the IT help desk got several employee laptops with full
hard drives, caused by a huge amount of audio recordings. The audio files
contained recordings even of highly sensitive telephone conferences. An
automated scan on all employee computers for such audio recordings showed that
about 300 devices were affected.
After our last blogpost regarding Emotet and several other Emotet and Ransomware samples that we encountered, we recently stumbled across a variant belonging to the Gozi, ISFB, Dreambot respectively Ursnif family. In this blogpost, we want to share our insights from the analysis of this malware, whose malware family is mainly known for being a banking trojan that typically tries to infect browser sessions and sniff/redirect data. In particular, we are going to provide details about the first stage Word Document, the embedded JavaScript/XSL document, an in-depth runtime analysis of the downloaded executable, and some details regarding detection.
After the Emotet Incident at Heise, where ERNW has been consulted for Incident Response, we decided to start a blogpost series, in which we want to regularly report on current attacks that we observe. In particular we want to provide details about the utilized pieces of malware, different stages, and techniques used for the initial infection and lateral movement. We hope that this information might help you to detect ongoing incidents, apply countermeasures, and in the best case to figure out proactive countermeasures and security controls beforehand.
At this years ARES conference, Jonas Plum (Siemens) and me (Andreas Dewald, ERNW Research GmbH) published a paper about the forensic analysis of APFS, file system internals and presented different methodologies for file recovery. We also publicly released a tool implementing our presented approaches, called afro (APFS file recovery).
APFS is the file system for Apple devices that is used by default on all current iOS mobile devices, as well as macOS since High Sierra, and is thus currently rolled out on a large number of devices. By using afro, we evaluated and compared the different approaches amongst each other and identified the method that so far delivers the best results and compared it to photorec. This showed that AFRO outperforms photorec on the evaluated APFS dataset. In the presentations of this research we were often asked if other tools like Blackbags Blacklight do not already support this recovery process. So, we decided to compare the file recovery capabilities of BlackLight and afro. We wanted to compare afro to the sleuth kit as well, as at the DFRWS conference it was discussed about adding APFS Support to The Sleuthkit Framework, but no implementations are public yet.