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.
Hardening a Linux client system to an acceptable degree is a time-consuming
process, one that demands familiarity with a broad set of configuration
parameters, framework recommendations, and the reasoning behind each control.
This post introduces our new Linux client hardening guide
(MD,
PDF), a comprehensive, publicly
available hardening reference for Linux systems.
Motivation and Scope
The guide covers the full breadth of controls needed to significantly raise the
security posture of a modern Linux installation while preserving operational
usability (this will be very subjective, the guide reflects my opinion of
“usable”). It has been developed and validated against Ubuntu 24.04 LTS as the
primary reference platform, and cross-tested on Fedora, Debian 12, and Arch
Linux as well as on traditionally server-oriented distributions like openSUSE
Leap 15.6, Debian 12, Rocky Linux 9, and Red Hat Enterprise Linux 9 while not
focussing on those as the guide is created for Linux clients.
After seven years, we’re publishing a new macOS hardening guide. Fully updated,
modernized, and now publicly available on
GitHub
as
Markdown
and on our website as
PDF.
The previous guide, written for macOS Mojave (10.14), reflected a very different
macOS security model. At the time, hardening often meant working around the
operating system, manually enforcing controls, and compensating for missing
platform guarantees. That guide served its purpose, but the platform has
fundamentally changed since then.
Today we are releasing a new white paper that delivers a technical analysis of
security weaknesses discovered in WinpMem, an open-source Windows memory
acquisition driver widely used in digital forensics.
After a concise primer on relevant Windows internals (virtual vs. physical
memory, page tables and PTEs, CR3 context switching, and kernel and user memory
separation), the report examines how both the fundamental design of WinpMem and
specific implementation choices create severe risk.
I am glad to announce the release of the ERNW whitepaper 71 containing
information about quarantine file formats of different AV software vendors. It
is available
here.
Anti-Virus Software
I took quarantine files from real-life incidents and created some in a lab
environment. Afterwards I tried to identify metadata, like timestamps, path
names, malware names, and the actual malicious file in the quarantine files. One
goal was to use this information to support our incident analyses: Using the
results, we can now easily create timelines showing information about
quarantined files, extract the detected malware, and sometimes even find
information about processes that created the malicious files.
With this blog post I am pleased to announce the publication of a new ERNW White Paper about the HL7 FHIR communication standard.
Introduction
Digital networking is already widespread in many areas of life. More and more medical devices are also being networked in the healthcare industry. This growth makes the development and use of new medical communication standards necessary since existing solutions can only meet the changing requirements with great effort. The HL7 FHIR standard is an example of such a medical communication standard. FHIR is said to have increased the interoperability between different medical contexts,e.g., administration, billing, and clinical care, to enable data exchange of various systems. The FHIR standard addresses the security risks associated with strongly networked communication from a large number of systems across the trust and organizational boundaries only indirectly because FHIR does not define mandatory security controls or requirements.
With this blog post I am pleased to announce the publication of a new ERNW White Paper [1]. The paper is about severe vulnerabilities in an insulin pump we assessed during project ManiMed and we are proud to publish this subset of the results today.
Manipulating Medical Devices
The German Federal Office for Information Security (BSI), in its role as the Federal Cyber Security Authority in Germany, aims to sensitize manufacturers and the public regarding security risks of networked medical devices. In response to the often fatal security reports and press releases of networked medical devices, the BSI initiated the project Manipulation of Medical Devices (ManiMed) in 2019. In this project, a security analysis of selected products is carried out through security assessments. In the context of this project, severe vulnerabilities were identified during the assessment of the DANA Diabecare RS system.
Last week Will “harmj0y” Schroeder published an excellent technical article titled “Not A Security Boundary: Breaking Forest Trusts” in which he lays out how a highly critical security compromise can be achieved across a forest boundary, resulting from a combination of default AD (security) settings and a novel attack method. His post is a follow-up to the DerbyCon talk “The Unintended Risks of Trusting Active Directory” which he had given together with Lee Christensen and Matt Nelson at DerbyCon (video here). They will also discuss this at the upcoming Troopers Active Directory Security Track (details on some more talks, including Sean Metcalf’s one, can be found in this post or this one).
In this article, we describe the impact of the increased use of Docker in corporate environments on forensic investigations and incident analysis. Even though Docker is being used more and more (Portworx, Inc., 2017), the implications of the changed runtime environment for forensic processes and tools have barely been considered. We describe the technological basics of Docker and, based on them, outline the differences that occur with respect to digital evidence and previously used methods for evidence acquisition. Specifically, we look at digital evidence within a Docker container which are lost or need to be acquired in different ways compared to a classical virtual machine, and what new traces and opportunities arise from Docker itself.