Abstract
Cryptographic ransomware attacks are constantly evolving by obfuscating their distinctive features (e.g., I/O patterns) to bypass detection mechanisms and to run unnoticed at infected servers. Thus, efficiently exploring the I/O behavior of ransomware families is crucial so that security analysts and engineers can better understand these and, with such knowledge, enhance existing detection methods. In this paper, we propose CRIBA, an open-source framework that simplifies the exploration, analysis, and comparison of I/O patterns for Linux cryptographic ransomware. Our solution combines the collection of comprehensive information about system calls issued by ransomware samples, with a customizable and automated analysis and visualization pipeline, including tailored correlation algorithms and visualizations. Our study, including 5 Linux ransomware families, shows that CRIBA provides comprehensive insights about the I/O patterns of these attacks while aiding in exploring common and differentiating traits across families.

Abstract
Modern storage systems requirements demand flexible, scalable solutions that address diverse concerns such as data reduction, replication, security, and multi-cloud distribution. Existing solutions often provide these guarantees through monolithic implementations, limiting their adaptability to specific application needs. This paper introduces PolyLayer, a multi-interface, composable and multi-backend storage architecture. It builds on the concept of stackable storage architectures and redesigns these to support commonly used user APIs (e.g., POSIX, Key-value, Object store), while providing support for data persistence across multiple storage backends (i.e., on-premises, cloud services, blockchain). We present the first steps towards the design of such architecture, while implementing a proof-of-concept and evaluating it. Our preliminary results show that the design can effectively be used in real-world scenarios where new functionality is added to a storage system with low overhead over the base system. For instance, we show how anti-tampering mechanisms can be added to a traditional relational database without any change to the database itself or the application using it.