CERT Intrinsec Incidents Report 2025

CERT Intrinsec is a French Incident Response team providing incident response and crisis management services to organizations across multiple sectors. Certified PRIS (Prestataire de Réponse aux Incidents de Sécurité) by ANSSI since 2022, the team has been operating since 2013 and has handled hundreds of engagements, gaining firsthand insight into the evolution of threat actor tradecraft.

In 2025, CERT Intrinsec was engaged in approximately sixty significant incidents involving ransomware operators, Initial Access Brokers (IABs), insider threats, and suspected state-sponsored actors conducting intelligence operations. These incidents spanned a wide range of environments, from legacy on-premise infrastructure to cloud-native Microsoft 365 tenants.

This report synthesizes our observations from these engagements with a focus on actionable findings. Rather than presenting descriptive statistics alone, we examine intrusion mechanisms, attacker dwell time, targeted assets, and defensive gaps — with the explicit goal of informing detection strategies and hardening priorities for security practitioners.

Methodology

Scope and inclusion criteria

This report covers incident response engagements conducted by CERT Intrinsec between January and December 2025. An incident was included in our dataset if it met the following criteria: (1) a confirmed compromise, as opposed to attempted intrusion or false positive, and (2) a demonstrated impact on confidentiality, integrity, or availability of data or systems.

Applying these criteria, sixty incidents were retained for analysis. Incidents classified as false positives, near-misses, or limited to reconnaissance activity without successful intrusion were excluded.

Dataset characteristics

The sixty incidents involved French organizations, including both domestic operations and international subsidiaries. The dataset reflects a diverse cross-section of industries: banking and insurance, construction, agrifood, public sector, transportation, and media & telecommunications.

Regarding organizational size, approximately two-thirds of affected entities employed over 1,000 staff, while the remaining third were smaller organizations. Two-thirds of engagements involved clients under preexisting retainer agreements; the remaining third were ad-hoc engagements with organizations contacting CERT Intrinsec for the first time.

Data collection

For each incident, the following data points were systematically recorded:

• Initial access vector
• Intrusion date and detection date (enabling dwell time calculation)
• Tactics, Techniques, and Procedures (TTPs), mapped to the MITRE ATT&CK framework
• Compromised accounts (count and privilege level)
• Compromised assets (count and type)
• Attacker tooling observed
• Data exfiltration, where applicable (volume and method)

Threat categorization

Incidents were categorized by threat actor type and assessed intent:

• Ransomware operators — incidents involving encryption, extortion, or both
• Initial Access Brokers (IABs) — intrusions focused on establishing persistent access for resale, without direct monetization by the initial threat actor
• Insider threats — malicious or negligent actions by employees or contractors
• Espionage (suspected) — intrusions exhibiting TTPs consistent with intelligence gathering, typically attributed to state-sponsored or state-aligned actors
• Undetermined intent — confirmed compromises where the intrusion was contained before the adversary’s objective could be established

Limitations and potential biases

Several limitations should be considered when interpreting our findings.

Selection bias. Our dataset exclusively comprises incidents that were either detected by the victim organization or reported by a third party. Undetected compromises fall outside our visibility.

Client portfolio bias. The sectoral and organizational size distribution reflects CERT Intrinsec’s client base rather than the broader French economic landscape. Large organizations and sectors with regulatory compliance requirements (e.g., banking) may be over-represented.

Incident distribution by threat type

The sixty incidents were distributed as follows: Initial Access Broker activity accounted for approximately one-third of cases, as did incidents where threat actor intent remained undetermined due to early containment. Ransomware incidents represented roughly one-sixth of engagements. A small number of incidents involved suspected state-sponsored espionage or insider threats; given the limited sample size, these categories are discussed qualitatively rather than statistically in subsequent sections.

The relatively high proportion of IAB and undetermined-intent incidents reflects the detection maturity of organizations under retainer agreements, where intrusions were frequently identified before progressing to final-stage objectives such as ransomware deployment or large-scale data exfiltration.

2025 Threat Landscape

As CERT Intrinsec responds to incidents affecting a diverse range of clients—from large enterprises with mature cybersecurity practices but complex information systems, to smaller organizations with simpler infrastructures yet limited resources to implement effective security controls—our investigations offer a broad perspective on the evolving threat landscape.

Business Email Compromise – Office365 attacks

The majority of Business Email Compromises (BEC) encountered by CERT Intrinsec in 2025 involved attacks related to the Microsoft Cloud ecosystem (Office365).
In these incidents, we saw two trends emerge:

• Adversary-in-the-Middle (AitM) attacks defeating multi-factor authentications protections;
• Direct Send abuse to perform targeted phishing attacks

Adversary-in-the-Middle attacks

Adversary-in-the-Middle (AitM) attacks aim at tricking a user into authenticating on a fake phishing website with the look & feel of Microsoft authentication webpage. Instead of simply stealing the credentials of the targeted user, it performs extra steps by triggering the multi-factor authentication process, on behalf of the victim. The attacker can therefore retrieve the victim’s credentials and an authenticated session on the EntraID tenant, bypassing the MFA protection. Tools such as EvilGinx2 weaponizes this attack.

To prevent your users from falling against these attacks, CERT Intrinsec recommends:

• Hardening conditional access policies to prevent authentications from unknown sources (geo based or reputation based)
• Using FIDO2 tokens
• Raising awareness regarding these kind of attacks for users
• Monitoring risky SignIns and risky users dashboards, etc.

DirectSend attacks

DirectSend is a Microsoft Exchange Online feature allowing emails to be sent without authentication within the same tenant. Misconfiguration of mail infrastructure may allow attackers to abuse this feature to send targeted phishing email from any user within a tenant to any other user. This abuse was leveraged in several campaigns to send phishing trying to steal credentials or perform AitM attacks.

In May 2025, Microsoft provided a way to disable this feature. CERT Intrinsec recommends:

• Reviewing mail infrastructure and enforcing strong DMARC policies.
• Disabling the Direct Send feature is a great way to prevent this abuse but might break legitimate business process
• Implement a mail filtering rule to prevent emails from being sent, through DirectSend, from an internal user (sender) to outside the organization.

Exploitation of public-facing applications

The exploitation of high-severity vulnerabilities against public-facing applications (websites, VPN, SharePoint, etc.) was one of the main causes of security incidents handled by CERT Intrinsec in 2025. Often, these incidents will be linked to large-scale exploitation of a vulnerability around its publication.

In order to prevent or limit this kind of incident, the following actions should be considered:

• Maintaining a complete, up-to-date listing of all public-facing applications on a given information system.
• Having a strong update policy regarding public-facing applications (less than 48 hours for security patches).
• Monitoring CVE (Common Vulnerabilities and Exposures) publications related to technologies used in public-facing applications.
• Heavily supervising public-facing applications and their system for any unusual behavior.

Ransomware Attacks

Amongst the approximately ten ransomware incidents investigated in 2025, all followed a double extortion model: data exfiltration preceded encryption, with the threat of public data exposure used as additional leverage against victims.
The ransomware families observed included Akira, LockBit, Fog, Incransom, and Lynx.

Encryption techniques

Two primary deployment methods were observed:

Remote encryption via network shares. The most common approach involved executing the ransomware binary from a single compromised system — typically a domain controller or infrastructure server — and encrypting data on remote systems through administrative shares (ADMIN$, C$). This method avoids deploying the ransomware payload on each individual endpoint, reducing the attacker’s footprint and limiting detection opportunities at the endpoint level.

Deployment via Group Policy Object (GPO). In one engagement, attackers leveraged Active Directory Group Policy to distribute the ransomware payload as a scheduled task across domain-joined systems, ensuring simultaneous execution at scale. Both methods rely on domain-level privileges, reinforcing the critical importance of protecting Active Directory (see Section 4).

Pre-encryption destruction sequence

Prior to encryption, attackers systematically targeted backup infrastructure and virtualization platforms to maximize impact and eliminate recovery options:

Hypervisors (VMware ESXi, Hyper-V) – Destruction or encryption of virtual machines at the hypervisor level;
Backup infrastructure (Veeam) – Access via compromised privileged accounts or exploitation of known Veeam vulnerabilities to delete or encrypt backup repositories.

This destruction phase was observed in every ransomware incident. Attackers consistently prioritized eliminating recovery capabilities before triggering encryption — a deliberate sequence designed to maximize pressure on the victim organization.

Operational timing

The interval between data exfiltration completion and ransomware deployment was consistently short — typically one to two days. Encryption was almost invariably initiated during nighttime hours, when security monitoring is reduced and response times are longer.

Recommendations

• Isolate backup infrastructure from Active Directory. Veeam servers and backup repositories should be deployed outside the Active Directory domain, using dedicated local accounts and separate authentication. A compromised Domain Admin account should not provide access to backup infrastructure.
• Implement immutable backups. Configure backup repositories to enforce immutability (write-once, read-many) to prevent deletion or encryption even if the backup server is compromised.
• Harden hypervisors independently. ESXi and Hyper-V hosts should not rely on Active Directory authentication. Enforce dedicated local credentials, restrict management interfaces to isolated networks, and apply security patches promptly.
• Maintain offline backup copies. At least one backup copy should be physically or logically air-gaped from the production network and domain infrastructure.
• Implement out-of-hours monitoring. Given the consistent pattern of nighttime deployment, ensure that security operations provide 24/7 coverage — or at minimum, automated alerting capable of triggering emergency response during off-hours.
• Test recovery capabilities. Regularly validate that backups can be restored in a realistic disaster recovery scenario. Backup infrastructure that has been silently compromised or corrupted provides no protection.

Malicious VPN access – Stolen Accounts

This refers to situations where the first action of a malicious actor identified during the incident was a successful authentication using a valid VPN account (without enabled MFA), granting the attacker access to a company’s internal network.

In this situation, it can be difficult to identify the source of the exploited account’s first compromise. In some cases, we could trace back to the account’s sale by an Initial Access Broker (IAB) on specialized forums thanks to the support of our CTI squad.

The lack of obvious malicious action at this point of the attack can make it harder to detect the malicious actor quickly, but several actions can be taken in order to prevent or detect this kind of action:

• Making Multi-Factor Authentication (MFA) mandatory for any VPN authentication. From our experience, this would have prevented a large number of incidents based on a stolen VPN account.
• Identifying the IP’s country of origin and reputation. This can be used to either block or raise an alert when an authentication happens from an unusual country or from an IP linked to a VPN or a malicious actor.
• Intensifying the use of Cyber Threat Intelligence (CTI) to identify accounts being sold by malicious actors before they can be exploited.

Workstation Compromise

Another prevalent initial access method involved the compromise of end-user workstations through social engineering. Attackers leveraged tactics such as fake CAPTCHA challenges (e.g., ClickFix), malicious online advertisements and compromised or spoofed websites.

These techniques were used to deliver payloads, particularly infostealers, capable of harvesting credentials, session cookies, and other sensitive data.

The infostealer ecosystem operates at industrial scale: users can also be infected through malicious downloads, trojanised software cracks, or compromised legitimate applications. Harvested credentials are aggregated and sold on dedicated marketplaces and Telegram channels, often within hours of collection. The time elapsed between credential theft and exploitation by a threat actor varied considerably, ranging from less than 24 hours to several months. This variability complicates detection: organizations cannot assume that credentials stolen months ago are “stale” or unexploitable.

• Enforce MFA on all remote access — VPN, Microsoft 365, and any internet-facing authentication portal. This single control addresses the root cause of 80% of observed incidents.
• Monitor credential exposure & Subscribe to CTI — Integrate leaked credentials detection into security operations.
• Reduce credential validity — Implement shorter session lifetimes and conditional access policies to limit the window of exploitation for stolen credentials.

Malicious Insider

In addition to external threats, CERT Intrinsec investigated a few incidents involving malicious insiders in 2025.

These individuals abused their legitimate access to carry out unauthorized actions, such as stealing corporate workstations or deleting critical data from CRM systems.

Such cases underscore the importance of access monitoring, privilege segregation, and user activity logging.

Incident Scale and Detection Timelines

During the incidents investigated, up to 30 devices were compromised per incident, with up to 32 user accounts affected depending on detection and containment speed.

The time between initial compromise and CERT activation ranged from 15 hours to 90 days. The median time was 7 days, often including phases of detection, impact assessment, containment, internal investigation, and formal reporting.

Notably, some threats remained undetected for extended periods due to evasion techniques or gaps in monitoring across parts of the information system. For example, compromised websites—later used to steal banking credentials or distribute malware—were often discovered several months after the initial breach.

Other notable tendencies

Privilege Escalation and Credential Access

Once initial access was established, threat actors systematically sought to escalate privileges and harvest additional credentials. In corporate network environments, Active Directory remained the primary target, with attackers exploiting a combination of misconfiguration, weak credential hygiene, and insufficient segmentation.
The techniques described below were not observed in a fixed sequence; rather, attackers opportunistically employed whichever methods yielded results in each specific environment.

Credential harvesting techniques

Extraction of credentials from LSASS process memory was observed in nearly all incidents involving corporate network compromise. Threat actors employed various techniques to evade detection, including abuse of native Windows tools: comsvcs.dll invoked via rundll32, Task Manager’s dump functionality, or signed binaries such as ProcDump. Extracted memory dumps were typically exfiltrated to attacker-controlled infrastructure for offline analysis, avoiding the need to run credential extraction tools (e.g., Mimikatz) directly on victim systems.

In several incidents, attackers harvested credentials stored by applications, including web browsers, file transfer clients (WinSCP, FileZilla), and remote management tools (mRemoteNG). These credentials often provided access to additional systems or third-party services. In isolated cases, sophisticated actors deployed hooks on authentication pages of internal applications (e.g., GLPI) to intercept administrator credentials in real time.

Commonly exploited Active Directory weaknesses

Several Active Directory misconfiguration recurred across engagements:

Excessive privileges, Delegation issues, Hard-coded service credentials, Local administrator password reuse, Weak or reused passwords, etc.
These weaknesses are well-documented and frequently highlighted in penetration test reports. Their persistence in production environments reflects a gap between security assessment findings and remediation implementation.

High-value targets

Attackers prioritized specific system categories for credential harvesting:

• Administrator workstations — frequently containing cached credentials, browser sessions, and access to privileged tools ;
• Infrastructure servers — domain controllers, hypervisors, backup servers, and management consoles ;
• Jump hosts and bastion servers — by design, these systems aggregate privileged sessions and credentials.
• Compromise of any single high-value target often provided sufficient credentials for lateral movement to the remainder of the environment.

Defensive implications

The prevalence of credential harvesting and Active Directory exploitation supports the following defensive priorities:

• Implement Privileged Access Workstations (PAW). Isolate administrative activities on hardened, dedicated systems to prevent credential exposure on standard endpoints.
• Deploy LAPS (Local Administrator Password Solution). Eliminate local administrator password reuse by enforcing unique, automatically rotated passwords per system.
• Enforce Active Directory tiering. Prevent credential exposure across trust boundaries by segregating Tier 0 (domain controllers), Tier 1 (servers), and Tier 2 (workstations) administration.
• Audit and reduce privileged accounts. Regularly review accounts with Domain Admin, Enterprise Admin, or equivalent privileges; remove unnecessary memberships.
• Eliminate hard-coded credentials. Audit scripts, scheduled tasks, and service configurations for embedded passwords; migrate to managed service accounts (gMSA) or secrets management solutions.
• Protect LSASS. Enable Credential Guard where supported; configure LSA protection (RunAsPPL); monitor for suspicious access to the LSASS process.
• Detect reconnaissance tooling. Implement detection rules for SharpHound/BloodHound LDAP query patterns, anomalous SPN requests (Kerberoasting indicators), and large-scale Active Directory enumeration.
• Strengthen service account passwords. Enforce long, complex passwords (25+ characters) for accounts with SPNs to render Kerberoasting impractical.

Execution and Tooling

Attackers required command execution capabilities throughout the intrusion lifecycle — from internal reconnaissance to privilege escalation, lateral movement, and impact. In all observed incidents, threat actors relied on native Windows interpreters (PowerShell, cmd.exe) for basic operations, supplemented by specialized tooling for more complex tasks.

Post-exploitation frameworks and tooling

Several post-exploitation tools were commonly observed across engagements: NetExec (formerly CrackMapExec) was frequently used for credential validation, lateral movement, and remote command execution. This framework offers multiple execution modules, each leaving distinct forensic artifacts:

• smbexec, Remote service creation, Service Creation events (7045)
• atexec, Remote scheduled task, Scheduled Task events (4698)

Impacket scripts (wmiexec.py, smbexec.py, psexec.py) were also observed. A distinctive forensic indicator of Impacket-based execution is the creation of services with names containing Unix epoch timestamps — a pattern rarely seen in legitimate Windows administration and highly indicative of compromise.

PsExec and direct access to administrative shares (ADMIN$, C$, etc.) remained present in some engagements, though less prevalent than in previous years. Attackers increasingly favor tooling that avoids dropping executable files on disk.

The detection gap

In the majority of incidents, victim organizations failed to detect the attacker’s tooling during the intrusion. These tools were identified only during post-incident forensic analysis. This detection failure was not due to the stealthiness of attacker techniques — the tools described above leave abundant, well-documented forensic artifacts. Rather, detection failed because the necessary logs were either not collected or not monitored:

• Windows Event Logs were configured with default settings, missing critical event categories
• No centralized log collection (SIEM) was in place, or retention was insufficient
• Security teams lacked detection rules for known offensive tooling
• Administrative activity was not baselined, making anomalies invisible

This observation is consistent across our engagements: the gap is not just technical capability, but operational maturity in logging and monitoring.

Defensive implications

The following recommendations focus on closing the logging and detection gap:

Logging policy — foundational requirements:

• New service creation (7045). Detects smbexec, PsExec, Impacket
• Scheduled task creation (4698). Detects atexec
• Process creation with command line (4688). Visibility into executed commands
• PowerShell script block logging (4104). Captures PowerShell payloads
• Logon events (4624, 4625) – Authentication
• Administrative share access (5140, 5145) Detects ADMIN$ and C$ access

Without these events, detection of post-exploitation activity is effectively blind.

Centralized collection and retention:

• Forward logs to a SIEM or centralized logging platform
• Ensure retention of at least 90 days — many intrusions are discovered weeks after initial access
• Include domain controllers, servers, and workstations in collection scope

Detection content

Deploy detection rules for known offensive tool signatures:

• Service names containing Unix timestamps (Impacket indicator)
• Randomly named services with cmd.exe or PowerShell execution (smbexec indicator)
• Scheduled tasks created via remote RPC
• Alert on administrative share access from non-administrative systems
• Baseline legitimate administrative tooling; alert on deviations

Operational readiness

Ensure security teams can investigate alerts within hours, not days. Conduct periodic purple team exercises to validate detection coverage. Test whether current logging would detect a NetExec/Impacket-based attack.

The tools used by attackers are well-known and leave predictable traces. The question is not whether detection is possible, but whether organizations have invested in the logging and monitoring infrastructure to make it happen.

Command and Control through VPN exploitation

VPN as primary C2 channel

A notable finding across our engagements: when attackers obtained legitimate VPN credentials, they rarely deployed dedicated Command and Control infrastructure. The compromised VPN session itself served as the primary remote access channel — providing encrypted, authenticated connectivity that blended seamlessly with legitimate traffic.
This observation has significant implications for detection: traditional C2 hunting focused on beaconing patterns, unusual outbound connections, or known malicious infrastructure is ineffective when the attacker operates through the organization’s own VPN gateway.

Remote Monitoring and Management tools as fallback

When attackers required additional remote access mechanisms, they overwhelmingly favored legitimate Remote Monitoring and Management (RMM) tools over traditional offensive C2 frameworks. The following tools were observed across engagements:

• AnyDesk
• Splashtop
• ScreenConnect / ConnectWise
• MeshAgent
• Teramind

Data Exfiltration Methodology

Data exfiltration was observed in incidents involving ransomware double extortion, Initial Access Brokers preparing access packages for resale, and suspected espionage operations.
RCLONE, a command-line cloud synchronization tool, was the dominant exfiltration utility.
Mega.nz was the most frequently observed destination, with SFTP to attacker-controlled infrastructure observed in a smaller number of cases.
In the vast majority of incidents, exfiltration was not detected during the intrusion — it was identified only during post-incident forensic analysis. This consistent detection failure highlights fundamental gaps in outbound traffic monitoring.

Exfiltration staging pattern

A consistent operational pattern was observed: rather than executing RCLONE directly on systems hosting the targeted data, attackers staged the tool on domain controllers or administrator workstations — systems with broad network visibility and existing access to network shares.

This approach offers several advantages to the attacker: it minimizes the number of systems on which exfiltration tooling is deployed and leverages existing network share access from privileged systems. Additionally, we assess that attackers deliberately select domain controllers and administrator workstations because these systems frequently benefit from less restrictive network policies — proxy exclusions, direct internet access, or relaxed firewall rules — originally configured to accommodate administrative operations. This misconfiguration provides attackers with an unfiltered egress path that would not be available from standard user endpoints.

Defensive implications

• Restrict outbound internet access from Tier 0 systems. Domain controllers should not have direct internet access under any circumstances. Enforcing this through firewall policy would neutralize the most common exfiltration pattern observed. This single control addresses the root cause.
• Block or monitor known exfiltration destinations. If not business-justified, block access to Mega.nz and similar cloud storage providers at the proxy or firewall level. Where blocking is not feasible, alert on any connection from server infrastructure to these services.
• Detect RCLONE execution. Alert on RCLONE binary presence or execution — particularly on domain controllers and administrative workstations, where this tool has no legitimate purpose. Monitor for known RCLONE command-line patterns (sync, copy, –transfers, –config).
• Monitor anomalous outbound volume. Implement netflow analysis or proxy-based monitoring for unusual outbound data volume, especially from privileged systems. Exfiltration of significant datasets produces detectable traffic anomalies — provided someone is looking.
• Monitor network share access patterns. Domain controllers or administrative workstations performing bulk read operations across multiple file shares is consistent with exfiltration staging and should trigger investigation.
• Treat exfiltration detection as a priority investment. The consistent failure to detect exfiltration in progress represents a missed opportunity to contain incidents before the most damaging phase — data exposure. Organizations that invest in outbound monitoring gain a critical last line of defense.

Conclusion

Observations made by CERT Intrinsec in 2025 show that threat actors are constantly evolving in order to bypass defenses put in place by organizations, who have a growing understanding of threat actors and their operating methods.

This can be seen in the increase of cloud-targeted attacks, often using methods able to bypass traditional defenses such as Multi-Factor Authentication.

The start of 2026 shows a continuity in this logic, with a resurgence of attacks involving AWS (Amazon Web Services) environments, such as compromises of EC2 instances or complete AWS tenants.