Why look into UEFI exploitation?
At DEFCON 27, researchers Michael Leibowitz and Topher Timzen presented their research into hiding malicious activity from threat hunters. As a threat hunter this immediately sparked my interest – and my concern. Part of their methodology for hiding malicious payloads was to utilise a fairly recent addition to Windows systems that allowed for manipulation of the Unified Extensible Firmware Interface (UEFI) memory space. Using this mechanism, they were able to directly write their malicious codes into UEFI variables through a compiled C code loader only later for the payload to be extracted with a secondary loader with no detection of the payload on the system. The reason for concern is simple: the technique they describe exploited the fact that the Operating System (OS) security systems and Anti-Virus (AV) installed had no visibility of the UEFI memory space.
Although automated systems may not have access to this memory space, my assumption was that a tailored approach would be able to yield the variables in this area for analysis and therefore detection. Attempts to use Endpoint Detection & Response (EDR) solutions for UEFI all failed as did attempts to access the memory space in ways other than those disclosed by the researchers. Although their extraction methods worked, they unfortunately required that the payload name and Global Unique Identifier (GUID) (specified during write) are known – something which obviously an attacker would know, but a defender would not. This represented a hole in detection capabilities that could allow malicious payloads to sit on systems indefinitely without detection. With the proper extraction and implementation, it could also be extremely difficult to detect their use in an active attack.