@inversecos

Forensic analysts are often taught two methods for detecting file timestomping that can lead to blind spots in an investigation. The two most well-taught methods for analysts to detect timestomping are: Compare the $STANDARD_INFORMATION timestamps vs the $FILE_NAME timestamps in the Master File Table (MFT) Look for nanoseconds in a timestamp matching “0000000” as this often shows the use of an automated tool (i.e. Metasploit)  These two detection methods are based on two fallacies that I will explore in this blog post: Myth 1: $FILE_NAME timestamps cannot be timestomped  Myth 2:  Attacker tools cannot alter nanoseconds in a timestamp INTRODUCTION TO TIMESTOMPING Timestomping is a technique where the timestamps of a file are modified for defence evasion. Threat actors often perform this technique to blend malicious files with legitimate files so that when an analyst is performing IR, critical evidence escapes detection.  Timestomping using tools like Cobalt Strike (of...

Registry artifact timestamps are extremely important to an incident response investigation. Threat actors may hide persistence mechanisms within the registry or modify registry values to disable Antivirus and other security tools. Knowing the time registry values are set/modified is very important to the overall investigation, especially when faced with answering questions pertaining to… Why did <security_tool> not detect the threat?  What files did the threat actors recently view? What folders did the threat actors open? When was the persistence mechanism installed in the registry?  And many other questions that are important to an investigation…  The idea of timestomping / time manipulation of a registry key’s ‘Last Write’ is a topic that has not been comprehensively covered in DFIR write-ups with most timestomping write-ups focused on timestomping of files via manipulation of the $STANDARD_INFORMATION time.  There exists a native Windows API “NtSetInformatio...

Threat actors can leverage native Windows API calls to install malicious services without generating correlating entries in the event log. Using native APIs to install services instead of the standard API calls allow threat actors to bypass security controls and event logging. This technique was utilised in the infamous Stuxnet malware sample created by the alleged US and Israeli government to target the Iranian nuclear program. It also happens to be one of my favourite malware samples <3. I will not be covering what native API calls are – for more information please take a read of one of my previous tweets .. This technique is not new (as it was used by Stuxnet), however, a lot of analysts in the industry see the event logs as a single source of truth without realising that sometimes it’s not always the case. As such, it’s always prudent for a responder/hunter/detection engineer to correlate various streams of evidence per artefact versus relying on a single source of evidence....

  An organisation’s cloud storage is a prime target for attackers looking to identify sensitive information for exfiltration. Depending on the settings set on Azure Storage accounts, companies could be unknowingly exposing their containers / blobs to the internet for direct access. Azure Storage is Microsoft’s solution for data management and storage in the cloud. Depending on the permissions set on an organisation’s storage account and if the access keys / shared access signature (SAS) URIs are uncovered by an attacker – attackers can connect to an organisation’s storage account and pull the data stored. This blog post explores the methods an attacker can use to interact with Azure Storage accounts to pull/access sensitive data and what to analyse to detect these attacks. The tools I used to perform this include: Azure CLI   MicroBurst created by Karl Fosaaen@Kfosaaen Azure Portal 😊 Background on Azure Storage One of the hardest parts of learning any new topic in cybersecur...