Next-Gen Cloud Security: IRDS4C’s Deception Strategy for Early Intrusion and Ransomware Detection

DDS Safe, a cloud service provider backup and storage system for dentists, got infected with the ransomware called ReVil in 2019. In the study [13], about 400 clinics couldn’t access their data and were out of service. Another big attack was NotPetya. NotPetya takes advantage of system weaknesses to break into networks and operating systems. Unlike many other ransomware types, it doesn’t need to trick a user into clicking anything [14]. The objective is to encrypt the files and data before getting noticed. This type of attack is known as "Ransomware-as-a-Service" (RaaS). Examples include REvil, WannaCry, BadRabbit, and NotPetya. Understanding how ransomware infects cloud storage is very important. One of the biggest risks is how cloud storage syncs with local storage. Services like Google Drive let users work on the local folders, and any changes automatically update in the cloud [15]. Ransomware takes advantage of this to spread.To protect cloud servers with sensitive data, researchers focus on detecting intruders. Since 1991, decoy systems have been used to confuse hackers [16]. In the study [17], author showed how honey files and tokens can trick attackers. Similarly, Whitham [18] explained how honeypots can detect unauthorized access by feeding intruders fake data. Decoy files and tokens help track unauthorized activity in cloud servers, and decoy resources can also be used to detect ransomware or malware trying to steal or encrypt sensitive files [19, 20]. The IRDS4C model is built on decoy techniques [21]. These techniques are very important for keeping the system stable and secure. It is based on four main ideas to fool hackers and make them interact with the decoy resources. The first one is making sure the fake resources look real enough to convince the attacker. The second one is reachability, which means placing decoys in common folders where ransomware usually looks for files. The third one is diversity—using different types of decoys at the same endpoint so intrusions and ransomware can be caught quickly. The fourth is making sure that real users don’t mistakenly interact with decoy files. To catch intrusions within the cloud system, decoy endpoints, honey folders, and honey tokens are used.

Honey files come in two types [21]: "high" and "low" interaction files. High-interaction files confuse hackers and keep them engaged with fake data. Low-interaction decoy files, on the other hand, quickly detect scripts or ransomware trying to steal or encrypt files. Different kinds of decoy servers [22] and fake tokens (such as decoy emails, fake directories, or fake pictures). The more honey servers are used [23, 24], the better the detection rate. Many techniques exist to detect ransomware, both in cloud and on-premises setups.

This paper focuses on detecting ransomware in Windows systems and protecting files from being encrypted or corrupted. Microsoft Windows is the commone used OS worldwide, with over 70% shares. Linux and Unix will be explored in future work. One common technique is Comparing Files Hashing, which calculates the hash value of files and checks for changes over time [25]. Another method is Comparing File Entropy Value, which measures randomness in file data to detect suspicious activity [26]. A third method uses hooking API functions, which allows the system to monitor file system activity for unusual changes [27]. Finally, decoy assets use a positioning technique to trick ransomware into interacting with them first as listed in Table 1.

Our paper uses file event-handler watching with fake methods and reallocating ways. If ransomware or any code/script tries to access IRDS4C’s low-interaction files filled with random data, it gets detected instantly. The high-interaction decoy files mislead hackers and push them deeper into fake traps. The decoy resources include fake folders, partitions, and storage, helping detect intrusions, unauthorized access, and ransomware attacks. Using both high and low-interaction files ensures that both simple and advanced attacks can be caught effectively.

Table 1. Differences among detection methods for ransomware [28]

We tested a series of experiments to check if our IRDS4C system really works. The results of these tests are explained in this section. We set up IRDS4C on Google Cloud Platform [37], as seen in Figure 2, and applied and tested it on (I-P-S-aaS) models. To properly test IRDS4C, we built different test environments and ran three experiments focusing on ransomware and intrusions. Experiment 1: We tested IRDS4C against various ransomware samples. The goal was to measure how fast it detects threats and how accurate it is in identifying different types of ransomware attempt 2: We took the same ransomware samples from attempt 1 and tested them using two other well known methods: File Hashing and File Entropy techniques. Then, we compared their results with IRDS4C’s performance to see which method was better. Experiment 3: We checked how well IRDS4C can catch intruders. To do this, we made SaaS and PaaS portals publicly available on the internet and observed if IRDS4C could detect unauthorized access attempts in a smart way. These experiments helped us understand IRDS4C’s strengths and how well it performs in real world scenarios.

The IRDS4C framework was subjected to rigorous testing to evaluate its effectiveness in detecting and mitigating ransomware and intrusion activities within cloud environments. The evaluation was conducted using a diverse set of ransomware samples, including prominent variants such as WannaCry, Ryuk, and Sodinokibi, across different cloud models.

For the experimental setup, the IRDS4C framework was deployed on the Google Cloud Platform and tested with cloud layers. Multiple experiments were conducted using a diverse set of ransomware samples and intrusion scenarios [36].

VMware Setup:

• Software Version: VMware Workstation Pro 17.0

• Virtual Machines: Each machine had:

• 4 CPUs
• 8 GB RAM
• 100 GB SSD storage
• Network: Bridged mode with individual virtual network adapters
• Snapshots: We created snapshots right after installing and setting up everything. This way, every test started from the exact same point.

Operating Systems Used:

• WinServer_2019

• Ubuntu Server 20.04.3 LTS

OS Configuration:

• Both systems were fully updated as of January 2025.

• Windows Defender antivirus was turned off to focus on how IRDS4C itself detects threats.

• Ubuntu's built-in firewall (UFW) was enabled with basic settings, and SELinux was set to permissive mode for controlled testing.

• We ran tests on both default setups and hardened security setups to see how different security settings affect IRDS4C’s detection.

Test Environment Setup:

• Network: All virtual machines were linked together using a dedicated virtual switch inside VMware. Each had a unique static IP address, and firewall rules were set clearly to allow ransomware and simulated attack activities.

• Simulating Attacks: We used specific scripts to run ransomware samples (7 samples), and for intrusions like SQL injections or privilege escalation, we used standard security testing tools like Metasploit and OWASP ZAP.

This approach let us accurately see how well IRDS4C spots and reacts to threats.

Figure 2. Google cloud platform dashboard

Table 4. IRDS4C and ransomware detection

Table 5. Results

5.1 Attempt 1: Challenges ransomware detection

The total of 53 samples from seven notorious ransomware families BadRabbit, NotPetya, Phobos (RedLine), WannaCry, Sodinokibi (REvil), Ryuk, and Netwalker were used to evaluate the IRDS4C framework [38]. These samples were sourced from reputable malware analysis services and executed in a controlled cloud environment [39] as illustrated in Table 4 and Figure 3.

Table 4 and Figure 3 summarize the detailed evaluation results of IRDS4C's detection capability against several prevalent ransomware families. Table 3 specifically includes more information of ransomware samples tested per family, including BadRabbit (20 samples), Phobos (RedLine) (11 samples), Sodinokibi (REvil) (6 samples), Ryuk (6 samples), WannaCry (4 samples), NotPetya (3 samples), and Netwalker (3 samples). It also documents IRDS4C's response times, measured in seconds, and clearly indicates the malicious behaviors executed by each ransomware type, such as file encryption, information theft, and file deletion. Figure 4 visually illustrates the detection speeds of IRDS4C for each ransomware type, facilitating a direct comparison.

IRDS4C's detection performance was consistently strong, identifying ransomware activity rapidly, typically between 9 and 17 seconds after initial execution. Phobos ransomware showed the fastest detection at 9 seconds, while NotPetya, known for its complexity, had the longest detection time at 17 seconds. These differences in detection times can be attributed to each ransomware's distinctive behavior patterns, encryption methods, and file-access mechanisms. The consistent accuracy (100% detection) and rapid response demonstrated by IRDS4C underline its effectiveness and reliability, suggesting that employing deception-based techniques significantly enhances ransomware detection capabilities in cloud-based systems.

3.png

Figure 3. The detection, in seconds, per ransomware families which IRDS4C detected

5.2 Experiment 2: Comparing detection techniques

IRDS4C was compared with existing detection mechanisms like file_hashing and file_entropy techniques as illustrated in Figure 4 and Table 5. The same samples were used to assess detection times and accuracy [36].

4.png

Figure 4. IRDS4C against the other methods for detection per sec [36]

5.2.1 Performance metrics

• Detection Rate: Percentage of successful detections.

• Mean_Time_to_Detect (MTTD): The average time from attack initiation to detection.

• False Positive Rate: Percentage of benign activities incorrectly flagged.

• Resource Utilization: CPU, memory, and network overhead.

Measuring the Mean Time to Detect (MTTD) [40] for the IRDS4C framework, file hashing, and file entropy involves calculating the average time taken to detect ransomware threats across each method. This can help demonstrate the effectiveness and efficiency of the IRDS4C system in comparison to traditional methods. Here’s how to approach it:

Steps to Measure MTTD

Data Collection:

• Gather the detection times for each ransomware family for IRDS4C, file hashing, and file entropy from your experimental results.

• Create a dataset that lists the detection times for each method.

Calculate MTTD for Each Method:

• The Mean Time to Detect is calculating using the equation:

$MTTD =\frac{\sum \textit { Detection } \cdot \textit { Times }}{N}$                     (1)

where, _N is the total_number of detected rasnomware for that method, all the results for the MTTD mentioned in Table 6.

Table 6. Mean Time to Detect (MTTD) for 3 detection methods

Results:

• Detection Rate: IRDS4C achieved 100% detection.

• MTTD: IRDS4C averaged 12.43 seconds, outperforming traditional methods.

• False Positive Rate [41]: IRDS4C recorded 0% false positives in static environment such as servers and SCADA systems. The zero false positive rate is ensured because only ransomware or attackers will access these canary files, which act as tripwires. Created in unused directories and hidden from regular users, they remain untouched by legitimate processes. Any access attempt signals malicious activity, such as file enumeration, unauthorized access, or ransomware encryption, making detection highly reliable.

• Resource Efficiency: Minimal overhead introduced.

5.3 Attempt 3: Evaluating intruders’ detection

The objective of this attempt was to evaluate how well IRDS4C detects intruders trying to break into cloud systems. We set up honey files, honey tokens, and honey endpoints, then let three attackers try to access sensitive information on our test machines. We focused on monitoring the behavior of these three experienced intruders using a five-layer detection system.

• Layer 1 - Decoy Files: We developed fake folders/files with tempting names, like Webconfig password.docx and Username and password.xls, to trick intruders into interacting with them.

• Layer 2 - Decoy Tokens: We placed fake items like misleading directories, such as /wbconfign and /admin, to lure attackers looking for restricted access points.

• Layer 3 - Decoy Servers: We set up honey servers, such as Honey Web and Honey DB, to see if intruders would interact with them.

• Layer 4 - Decoy Partitions: We created fake storage partitions to detect access attempts.

• Layer 5 - Decoy Shared Folders: We added decoy folders to track if attackers attempted to open shared files.

5.3.1 Intruder testing results

• Intruder 1: Entered the cloud test environment at 11:00 AM. IRDS4C detected the breach after 15 minutes (11:15 AM) via Decoy Files. The attacker tried opening Webconfig password.docx and also accessed Honey Web & Honey DB servers, the decoy partition, and the decoy folder. However, they ignored Decoy Tokens and never accessed real system resources.

• Intruder 2: Started at 2:40 PM, detected 7 minutes later at 2:47 PM. This attacker interacted with Decoy Files (Username and password.xlsx), and also accessed Decoy Tokens, particularly the fake URL /webconfig. They also interacted with decoy servers, partitions, and folders but never reached real files.

• Intruder 3: More careful and strategic than the others, this attacker started at 3:00 PM and was detected 13 minutes later at 3:13 PM. Instead of touching Decoy Files, they interacted with Decoy Tokens first, such as the /admin fake directory. They also accessed Honey Web & Honey DB servers, the decoy partition, and decoy folders but did not reach real files as listed in Table 7.

Table 7. IRDS4C intrusion detection results