Also, with this blog post, we are releasing a Rekall plugin called pointerdetector that enumerates all exported functions from all DLLs and searches the memory for any pointer to them (essentially a search for dynamically resolved APIs). This plugin can assist in identifying dynamically resolved APIs and especially memory regions containing DLLs loaded with techniques such as reflective DLL injection. This blog post will contain some examples illustrating the usage of this plugin, as well.
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.
I am amazed by how this years BlackHoodie unraveled. Three days that included a pre-conference of lightening talks and two parallel tracks with a total of 64 enthusiastic members. The very spirit of BlackHoodie is nothing other than the quest to gain deep knowledge. Reverse engineering is one of the hardest fields in security. It touches on all fields of computing, starting from assembly, programming, file formats, operating systems, networks and what not. This makes it hard but an extremely fulfilling experience to spend time learning it. For me, the very idea of staring at a binary till you understand what it does is a magical feeling.
While doing heap research on Linux processes (results are going to be published soon), I came across the bot from the Mirai Botnet. As already mentioned in the blog post by Brian, the Mirai bot uses obfuscated configuration data which contains e.g. the CnC server. When now confronted only with a bot (e.g. in the context of a running task or the ELF binary), but without the according source code, the decryption of this configuration data for e.g. incident analysis purposes might not be easily possible (with the python script from the blog post), if the key has been changed.
But in this case that is not a problem at all, because Continue reading “A short Addendum on the Mirai Botnet Blog Post”
In this blogpost we will briefly explain a well known Syscall hooking technique (a more detailed explanation can be gathered from e.g. http://resources.infosecinstitute.com/hooking-system-service-dispatch-table-ssdt/) used by multiple malware samples (like the laqma trojan) and right after discuss how some memory analysis tools have trouble in the analysis and/or reporting of these. Continue reading “Investigating Memory Analysis Tools – SSDT Hooking via Pointer Replacement”
Quite some organizations complemented their traditional AV solutions with a technology that can best be described as behavior-based malware detection. While we all know we are talking about products like Fireeye Email/Network Security, zScaler Web Security/APT Protection, or Cisco WSA, there are a lot of terms around to describe this type of products (such as next generation malware analysis/detection, Secure Web Gateways, or behavior-based malware detection). Those offerings typically promise the detection of malware by analyzing the behavior of ‘samples’ (which are files captured in transit of different types, such as executables or PDF documents). However, beyond the taxonomy challenges, both assessment and consulting work gets us frequently in contact with those solutions. While the main task during assessments is to bypass those solutions, the main question in the consulting context typically is “to what degree are the solutions suited to protect from common targeted attacks in the enterprise context”. Luckily, the experience from assessment work allows us to tackle this question in a structured way (which is our approach for consulting anyways: Benefit from our assessment experiences in order to provide reasonable consulting advice…).
Just recently, Dell SecureWorks Counter Threat Unit(TM) (CTU) researchers published details (see http://www.secureworks.com/cyber-threat-intelligence/threats/skeleton-key-malware-analysis/ ) on a especially nasty piece of malware that bypasses authentication on Active Directory (AD) systems which implement single-factor (password only) authentication. Once deployed the malware stays quite noiseless in the Domain Controller´s (DC) RAM, and the DC´s replication issues caused by it weren´t interpreted – in this case – during months as a hint for system compromise. Probably the malware´s modification on the LSASS process reduced the DC´s ability to perform DC-to-DC authentication, but this is only speculation and not where we would like to go today.
So, what to do? The relevant mitigations, pointed out by Dell´s CTU, as event log monitoring and scanning processes on suspicious systems with the published YARA signature should be applied.
Still, let’s discuss for a second which long-term, preventative measures could come into play as well. Continue reading “Skeleton Key – a Nasty Piece of Malware. Some Remarks.”