The Windows Insight repository now hosts the Windows Telemetry ETW Monitor framework. The framework monitors and reports on Windows Telemetry ETW (Event Tracing for Windows) activities – ETW activities for providing data to Windows Telemetry. It consists of two components:
the Windbg Framework: a set of scripts for monitoring Windows Telemetry ETW activities. The scripts are fed to a running windbg instance, connected to the Windows instance whose Windows Telemetry ETW activities are monitored.
the Telemetry Information Visualization (TIV) framework for visualization of information and statistics. The TIV framework is a set of Python scripts that visualize information and statistics based on the data produced by the Windbg Framework. The output of the TIV framework is a report in the form of a web page.
The Windows Telemetry ETW Monitor has been tested on Windows 10, version 1909.
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.
The Windows Insight repository now hosts three articles on Windows code integrity and WDAC (Windows Defender Application Control):
Device Guard Image Integrity: Architecture Overview (Aleksandar Milenkoski, Dominik Phillips): In this work, we present the high-level architecture of the code integrity mechanism implemented as part of Windows 10.
Windows Defender Application Control: Initialization (Dominik Phillips, Aleksandar Milenkoski): This work describes the process for initializing WDAC performed by the Windows loader and the kernel when Windows 10 is booted.
Windows Defender Application Control: Image verification (Aleksandar Milenkoski): This work discusses the workflow of WDAC for verifying images.
On September 14th the final deadline of complying with the new Payment Service Directive PSD2 will be reached. Among other things, this directive will bring quite a few technical challenges for credit institutions. These include new requirements on two-factor authentication and API access for third parties. In this blog post we will give a short overview of what this means for banks from a security perspective and outline a few of the security-related issues based on what we have been observing during recent assessments of such APIs.
Some weeks ago, Heinrich and I had the pleasure to participate in the heisec-Webinar “Emotet bei Heise – Lernen aus unseren Fehlern”. We really enjoyed the webinar and the (alas, due to the format: too short) discussions and we hope we could contribute to understand how to make Active Directory implementations out there a bit safer in the future.
While waiting for a download to complete, I stumbled across an interesting blogpost. The author describes a flaw in LibreOffice that allowed an attacker to execute code. Since this was quite recent, I was interested if my version is vulnerable to this attack and how they fixed it. Thus, I looked at the sources and luckily it was fixed. What I didn’t know before however was, that macros shipped with LibreOffice are executed without prompting the user, even on the highest macro security setting. So, if there would be a system macro from LibreOffice with a bug that allows to execute code, the user would not even get a prompt and the code would be executed right away. Therefor, I started to have a closer look at the source code and found out that exactly this is the case!
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.
In some organizations we work with a certain state of IPv6 deployment has been reached in the interim which includes, among others, the following aspects:
the network infrastructure is IPv6-enabled (incl. interface addressing, routing [protocols] and the like).
parts of supporting services (security functions, monitoring, system management) include IPv6 in a proper way.
3rd party providers have been contractually obliged to deliver their services in an “IPv6-enabled” mode (as opposed to only being “IPv6-capable” which was the standard requirement in many RFIs during earlier years).
It might then happen that networking people (who often are the initial motivators for deploying IPv6) in such organizations are stating, when asked about IPv6: “it’s [mostly] done”.
Point is that, alas, this does not necessarily mean that a single service or application is *actually using* IPv6, so while the above certainly constitutes an achievement it might not even be halfway through.
The Windows Insight repository currently hosts four articles on VSM (Virtual Secure Mode):
Virtual Secure Mode: Architecture Overview (Aleksandar Milenkoski): In this work, we discuss the architecture of a virtualized Windows environment.
Virtual Secure Mode: Communication Interfaces (Aleksandar Milenkoski): In this work, we discuss the communication interfaces that VSM implements: Isolated User Mode (IUM) system calls, normal-mode services, secure services, and hypercalls.
Virtual Secure Mode: Protections of Communication Interfaces (Aleksandar Milenkoski): This work discusses implemented mechanisms for securing the above VSM communication interfaces. This includes restrictions on issuing hypercalls, data marshalling and sanitization, and secure data sharing.
Virtual Secure Mode: Initialization (Dominik Phillips, Aleksandar Milenkoski): This work describes the process for VSM initialization activities performed by the Windows loader and the Windows kernel when Windows 10 is booted.