Detection and Attribution of Anti-Forensic Techniques in Cloud Environments

Cloud computing has become a part of IT infrastructure, providing organizations with scalable access to computing resources [1], [3]. However, this reliance also exposes data to security risks, and traditional forensic methods do not translate well to cloud-stored data [1], [2], [4]. Because physical access is limited and multi-tenancy is common, collecting evidence is difficult, which allows attackers to exploit vulnerabilities without detection [2], [4], [6]. Anti-forensics, which are tactics used to hide activity, destroy or alter evidence, and block analysis, are especially effective in cloud systems [7], [8], [10]. Attackers use data obfuscation, log manipulation, secure deletion, and cloud-specific features such as instance deployment and snapshot manipulation to hide evidence.

Despite progress, a key gap remains in finding the source of anti-forensic activity. Many existing methods can detect evidence tampering but fail to attribute it because they rely primarily on static log analysis rather than correlating evidence from multiple sources [6], [11], [24]. This paper presents a framework that detects and attributes anti-forensic techniques in environments using correlation across many evidence sources to improve accuracy and reliability [11], [24], [25]. The main contributions of this study are threefold: (1) an investigation of common anti-forensic techniques in cloud computing; (2) an integrated framework for detecting and attributing anti-forensic activities through the correlation of multiple evidence sources; and (3) an empirical evaluation of the proposed approach through controlled experiments in Microsoft Azure.

Anti-forensic techniques are methods used by adversaries to obscure, manipulate, or destroy digital evidence. These techniques pose particular challenges in cloud environments because of virtualization, resource flexibility, multi-tenancy, and the limited physical access available to investigators. Adversaries may exploit cloud-specific features to hinder evidence collection, integrity verification, and forensic analysis. This section examines three categories of anti-forensic activity relevant to cloud computing: cloud-log tampering, metadata spoofing, and encryption- and encoding-based obfuscation [7]–[10].

• Threat scenario: In a cloud environment log wiping usually does not mean editing a log file. Often an attacker who has enough power attacks the log setup itself for example by deleting the diagnostic setting that sends service logs to the analysis workspace. This means that later activity is never recorded. This corresponds to the MITRE ATT&CK technique Disable or Modify Cloud Log (T1562.008) [13], [14], [28], [29]. We performed this attack on Microsoft Azure to see if it can be spotted and identified.

• Testbed: Experiments were conducted on 13 October 2026 on the Azure for Students subscription (Poland Central region). The environment comprised one General Purpose v2 storage account (Locally Redundant) with one blob container and one Log Analytics workspace Figure 1. There were two diagnostic settings enabled: diag-activity is responsible for exporting the subscription Activity Log to the workspace and the archive account, and diag-blob forwards blob service logs (read, write, delete) to the workspace. There were two service principals (user1, user2) both having Storage Blob Data Contributor role, authenticated using OAuth and generating normal workload through a python script with 1 to 6 seconds of pauses between requests. User1 was upload-intensive (action weight 70/20/10: upload/download/list), user2 download-intensive (15/70/15). To check repeatability, this attack was repeated under a modified workload; see Results below. [26], [28], [29].

• Baseline: The first run was not used because both scripts ended up using the identity by mistake. The clean baseline starts at 07:01:48 UTC. Ends at 08:46:17 UTC. It includes 4,218 events as shown in Table 1. The average time between events is 1.49 seconds. The 99.9th percentile is 7 seconds and the longest interval, between events is also 7 seconds.

• Attack procedure: An administrator account deleted the diag- setting using the Azure CLI. After waiting for 3 minutes both scripts ran 100 actions each while logging was turned off. The setting was then added again. Attack boundaries were taken from the timestamps in the Activity Log. A manually kept attack log was used as a check to make sure everything was correct Figure 2 [13], [14].

• Detection methods:

– D1, event rule: Look in the Activity Log for DIAGNOSTICSETTINGS/DELETE operations.

– D2, gap detection: Mark any time period longer than 30 seconds between storage-log events. The limit is four times the longest normal interval (7 seconds). [Optional: try 15 seconds and 60 seconds. Note the results.]

– D3, correlation: Mark a gap only if it includes a diagnostic-setting deletion in the Activity Log.

– D4, state comparison: Count blobs that had their Last-Modified time during the blackout and compare that number to the number of logged events.

– Blackout duration: Connect each deletion to the diagnostic-setting write in the Activity Log.

• Results: The Activity Log records show the deletion of diag-blob at 10:03:59.894 UTC and the re-creation of diag-blob at 10:18:23.083 UTC, which created a blackout of 14.4 minutes (Table 2). During this blackout window the storage log contained no OAuth-authenticated events Figure 2. Blob versioning showed that at least 84 blob versions were written. This count is a bound because reads and listings leave no trace in the storage account. The Activity Log also recorded the account that performed the deletion and the source address of that account, which differed from the address used by the scripted workloads. An address identifies a session, not a person. On the baseline the gap detector raised no alerts across 4,217 intervals Figure 3. After the attack and a cool-down run the gap detector raised three alerts (Figure 4,Table 3). The first alert, from 08:46:17 to 10:29:32 UTC (103.3 minutes) contained the blackout. Was about seven times longer than the tampering because no activity occurred during the idle time before it. The other two alerts (11.3 minutes and 3.8 minutes) are not silences. No user activity was logged between 08:46 and 10:44 UTC and the only events in that period were two AppendBlock writes at 10:29:32 and 10:40:48 UTC by an identity that was neither user1 nor user2; these writes split one period into three gaps. Requiring a gap to contain a diagnostic-setting deletion (D3) therefore leaves a single alert. So the storage log alone cannot show how much of that silence was tampering. Only the Activity Log, through the event rule (D1) and, by pairing the deletion with the re-creation gave the blackout window and the responsible account (Figure 5).To test repeatability the attack was done again in a full test with user1 and user2’s upload/download load swapped compared to the first test. The Activity Log recorded the diagnostic-setting deletion at 05:21:28.735 UTC and its recreation at 05:30:50.737 UTC giving a blackout duration of 9.37 minutes (Figure 6) compared to 14.4 minutes in the test. This shows that blackout duration changes with the timing of the attacker’s actions rather than staying the same. Gap detection raised two alerts during this test (Figure 7) one of which matched the tampering event and the other did not giving a precision of 1 out of 2. If the gap was required to contain a diagnostic-setting deletion the false alert was removed, leaving one alert that matched the real tampering event (precision 1 out of 1) (Figure 8) the same result seen in the first test. These results show that linking gap detection with the Activity Log gives precision in at least two separate tests, with different workloads while gap detection alone still can produce false alerts from normal background activity not related to the attack.

Metadata spoofing involves manipulating file or system metadata, such as creation timestamps, modification timestamps, or ownership information. Because investigators often rely on metadata to reconstruct events and establish timelines, manipulated values can undermine the reliability of digital evidence. Detecting inconsistencies between metadata fields and independently recorded timestamps can help identify potential tampering [15], [17], [18].

1. Dataset and attack: We made 500 text files on the ext4 file system of a Kali Linux system, which keeps track of file birth times. We noted each files birth time as the real information before changing anything. Out of the 500 files 250 were picked randomly (using Python's random.sample with seed 42). Each of those selected files had access and modification times set with touch -t with the year chosen randomly from 2015 to 2021 and the month day, hour and minute also chosen randomly. The other 250 files stayed the same.

2. Local detector: A rule-based detector checks a file. Triggers an alert if any one of three signals is detected. These signals are tied to the file’s metadata. When using touch it changes the modification time. The inode change time and birth time stay true to the actual events. Also touch -it only sets the modification time to seconds not fractions of a second [20], [21].

• Signal 1: The modification time is earlier than the birth time.

• Signal 2: The change time is one day, after the modification time.

• Signal 3: The modification time shows zero nanoseconds.

3. Local results: The detector correctly classified all 500 files: 250 positives, 0 false positives, 250 true negatives, and 0 false negatives. This gives precision, recall and F1 all at 1.000 (Table 4, Figure 9). The forged dates are between 4.8 and 11.7 years before the creation time. These results demonstrate that the detector performs well when forged timestamps differ substantially from the actual file creation times. However, they do not establish its effectiveness against near-time forgeries, in which the manipulated timestamps are close to the actual creation times. An attacker who makes a time near the truth might still get through. To test this directly, a second dataset was generated with dates only 1–6 hours before the real creation time (seed=99) rather than the 4.8–11.7 years used above. Against this difficult case the detector reached a precision of 1.000, a recall of 0.544 and an F1 score of 0.705 (Table 4a). Precision stayed perfect with zero false positives among the 250 clean files, but recall dropped sharply because 114 of the 250 near-time forgeries went undetected. This shows that an attacker who spoofs a time near the truth can slip past local metadata detection [16–19, 21].

4. Cross-source check: To test a reference the same 500 files, with their local timestamps as left by the attack were uploaded to an Azure Blob Storage container (Standard LRS, Poland Central); all 500 blobs were confirmed Figure 10, Figure 11. A blob's Last-Modified property is assigned by the storage service when the blob is written so the client cannot set it. I checked Microsoft’s Blob service documentation to confirm this. For each file we compared the modification time with the blobs Last Modified and flagged gaps greater than one day. Clean files showed a gap of 0.05 days (about 1.2 hours the delay between creation and upload), for all 250 files whereas tampered files showed a gap of 2,945.85 days (minimum 1,753.08, maximum 4,264.75) Table 6. The flag matched the ground truth on every file (TP = 250 FP = 0, TN = 250 FN = 0) [15], [19], [27].

5. Scope of the cross-source result: Modified marks the upload time so it only shows the possible time the content existed, not the real modification time. In this test each clean file was uploaded about one hour after it was created. Any big gap between the uploaded time and the creation time means the date was forged. A real file that was made before its upload by more than the allowed limit, like a backup or data that was moved would trigger the warning so a deployment would need a baseline, for each source. I did not compare the clocks of the computer and Azure, and I ran the test only once with one random draw because the detectors are deterministic [20], [27].

Encryption-based obfuscation means using encryption techniques or encoding to hide the content of data that is stored in the cloud. Encryption is often used in security applications, but adversaries can also use encryption to hide malicious or sensitive data. Adversaries may also use encoding techniques, such as Base64 or hexadecimal encoding, to delay detection because these techniques do not require the computational effort of true encryption. These approaches make evidence harder to interpret because masked or encoded data cannot be evaluated until the obfuscation technique is identified and reversed [7], [9], [22].

1. Dataset and Threat Model: To test how well we can spot this trick in cloud storage, we built a labeled dataset of 450 files. The dataset contains 200 files: 50 plain text documents, 50 JSON log entries, 50 real gzip compressed files, and 50 real zip compressed files. The dataset also holds 250 files that are hidden in five different ways: 50 files in Base64, 50 files in hexadecimal, 50 files encrypted with AES-256, 50 files that are first gzip compressed and then Base64 encoded, and 50 files that use a single-byte XOR trick. Every bad file in the dataset is stored with an extension and is marked as text/plain when it is uploaded. This matches how an attacker would hide a file so that a quick look does not reveal anything wrong. The Threat Model says the attacker has access to a storage account that is a compromised or evil identity with Storage Blob Data Contributor rights. The attacker will upload files that look like harmless content because they have a normal declared content type. The defender has the read permissions, but because this is a real cloud environment, the defender cannot afford to download and check every blob in detail [9], [12], [23].

2. Cloud-Native Prefix Scanning: Unlike a forensic scan that downloads and looks at entire files, cloud object storage APIs let you read just a part of a file. Getting only a certain number of bytes from an object without moving the whole thing [30]. Each read was checked using four signs: (i) (i) Shannon entropy higher than 7.5 bits per byte but not counting headers from known compressed files like gzip or zip; (ii) matching the Base64 character set and having an entropy minimum of 4.0 bits per character to rule out normal text that only has letters; (iii) matching the hexadecimal character set and having an entropy minimum of 3.0 bits per character; and (iv) having a content type that starts with text/ and also having a low number of printable characters in the bytes that were read. A blob was marked as suspicious if any of these signs were triggered [22], [23].

3. Detection Results: Table 7 summarizes detection performance across prefix lengths. Reading 128 bytes, which is 6.3% of the total data volume, across the dataset achieved a recall of 0.920 and produced zero false positives. Recall grew a little as the prefix length increased and leveled off at 0.956 starting from 512 bytes, which is 24.9% of the data volume, and stayed the same even when the full download was read. For the obfuscation classes evaluated, the results indicate that scanning a prefix of 512 bytes achieved the same overall recall as scanning the complete blobs. This suggests that reading additional data provided no further detection benefit under the tested conditions.

Table 7 shows these results broken down by encoding class. AES-256 encoded content was detected with recall. Base64 encoded content was detected with recall. Gzip-Base64 encoded content was detected with perfect recall. All three methods were detected with recall at every prefix length. This includes the prefix length, which was 128 bytes. This shows these obfuscation methods are detectable away whenever a read happens. Hexadecimal encoding needed a prefix to get full detection. At 128 bytes It was detected 41 out of 50 times. At 512 bytes it was detected 50 out of 50 times. Single-byte XOR encoding was detected in 39 out of 50 cases. This was 78 percent recall. This was true at every prefix length. This includes downloading. This shows this is a problem with the detection approach. It is not because of no data. Single-byte XOR produces ciphertext with entropy. It has no structural signature. This is different from Base64 or hexadecimal. These methods limit the output to a small character set. This makes it much harder for entropy and pattern-based heuristics to tell the difference between this and natural data variation.

Cloud forensics involves specific challenges that differentiate it from other kinds of digital forensics exercises. The very nature of the cloud environment poses major problems in terms of gathering, preserving, and analyzing evidence. This part discusses some of these challenges involved in conducting cloud forensics investigations [1], [2], [5].

1. In conventional forensic investigation procedures, analysts can have easy physical access to storage media and systems. Nevertheless, with the emergence of the cloud environment, information is stored in remote servers controlled by the cloud service provider. Consequently, investigators depend a lot on the cloud service provider for accessing information; therefore, their ability to collect and authenticate evidence becomes extremely difficult [1], [2].

2. Cloud systems use the concept of multi-tenancy, where various users use the same physical resources. As such, it is difficult to isolate the data of one user from the rest. Moreover, privacy laws do not allow investigators to access the data of any other tenant residing on the same physical system [2], [4], [6].

3. The information in cloud computing is usually spread over several geographical locations and data centers. Such dispersion improves the efficiency of the system, but it makes forensics difficult because it becomes hard to pinpoint where the information is located and how events transpire within the system [2], [4].

4. Clouds are characterized by high dynamics in terms of resource creation, modification, and deletion. This leads to a phenomenon known as data volatility, where vital pieces of digital evidence get deleted even before the forensic investigator gets a chance to obtain it. The types of data vulnerable to this phenomenon include temporary storage, memory data, and sessions [4], [26].

5. Data in cloud computing may be stored in various locations that may have their own unique legal requirements. This makes it difficult for the investigators in the forensic process to investigate, as they will need to comply with the international laws [1], [4].

This study evaluated three approaches to detecting anti-forensic activities in Microsoft Azure: cloud-log tampering detection, metadata-spoofing detection, and the detection of encryption- and encoding-based obfuscation. Correlating Activity Log events with storage-log gaps improved detection precision across two attack trials. Local metadata analysis performed well against large timestamp manipulations but was less effective against near-time forgeries. Cross-source timestamp verification provided additional evidence of metadata manipulation, while prefix scanning detected several forms of obfuscated content without requiring full-blob downloads. These findings demonstrate the potential of correlating cloud evidence sources and inspecting partial object content. However, the evaluation was limited to controlled experiments, synthetic data, a single cloud provider, and account-level attribution. The results should therefore be interpreted within these limitations.

Future work will focus on four directions: (1) evaluating log-tampering detection under continuous background activity and extending attribution to dedicated attacker identities; (2) investigating metadata-spoofing detection across a wider range of timestamp offsets and legitimate file operations; (3) evaluating obfuscation detection using larger datasets, additional encoding techniques, and other cloud providers; and (4) extending the framework to support real-time alerting while addressing legal and privacy requirements in multi-tenant environments.