When CERT-Wavestone is called, three priorities drive every action and decision making: containing the threat, understanding the attack and eradicating the attacker. To achieve these objectives, establishing visibility across the impacted perimeter is the critical first step.

In such contexts where speed and effectiveness are mandatory, CERT-Wavestone relies on many tools: cybersecurity solutions (EDR, SIEM, etc.), open-source collectors and parsers, and its own internally developed tools.

Among these, StormCell stands out as an open-source tool developed by CERT-Wavestone to automate Windows triage processing and free analysts’ time to focus on what truly matters: the investigation itself.

Contain. Understand. Eradicate. Every hour counts.

Increasingly effective attackers

Several cybersecurity incident response actors agree that certain types of cyberattacks, such as ransomware and data exfiltration attacks, are becoming increasingly fast paced. The charts published by Zero Day Clock (https://zerodayclock.com) illustrate this trend:

• A growing share of zero day vulnerabilities are being actively exploited each year, rising from 16% in 2018 to 71% in 2026,
• A decreasing time to exploit (TTE) for these vulnerabilities is noted, falling from several years in 2018 to less than one day in 2026.

This is also a commonly shared observation among Wavestone’s incident response team in its latest annual report (see: CERT-Wavestone annual report), which is based on a set of around twenty major incidents affecting Wavestone clients during 2025:

As a result, to contain and remediate incidents as early as possible our incident response team must be effective in its analysis and decision‑making. This requires an especially quick understanding of the context and of the incident.

The anatomy of a CERT-Wavestone investigation

Each CERT-Wavestone investigation typically begins with a limited scope before rapidly expanding to cover dozens of systems as the situation evolves:

• Stage 1 — Initial analysis: Once the perimeter is secured and initial containment measures are in place, CERT-Wavestone is engaged and assesses the situation on a handful of suspicious or confirmed compromised machines. If the client has a SOC or CERT, existing telemetry and detection tooling provide an immediate starting point. If not, CERT-Wavestone leverages available resources to perform initial forensic collections and outline an initial overview of the attack.
• Stage 2 — Broader investigation: As the killchain becomes clearer, the investigation expands to dozens of compromised machines. When the client’s infrastructure cannot support large-scale acquisitions, CERT-Wavestone deploys its own forensic collection tool to gather triage data efficiently.
• Stage 3 — IoC hunting across the entire IS: Indicators of compromise are established, and the search extends to the entire information system. If not already in place, EDR or alternative tools can be deployed by CERT-Wavestone. Large-scale IoC sweeps rely on the built-in capabilities of the EDR, SIEM or log collection platforms.

Whether on Stage 1 or Stage 2, each collection requires the same standardized pipeline: retrieval, parsing, ingestion, Indicator of Compromise (IoC) identification, and cross-collection correlation. Consequently, manual forensic processing consumes valuable time and effort, forcing analysts to handle routine data operations instead of focusing on investigations.

Handling each collection individually by each analyst is slow, prone to errors and discrepancies, and poorly scales to the number of machines to investigate, and the number of analysts mobilized on the incident.

This is precisely the problem that StormCell, a tool developed by the CERT-W, was designed to solve.

StormCell : what is it ?

StormCell is a tool developed by CERT-Wavestone to address a long-standing need: a Windows forensic analysis orchestrator that adapts to multiple investigation contexts, automates the end-to-end processing of triage data from artifact extraction to centralized ingestion into a SIEM platform, and frees analysts to focus on the investigation, not the pipeline.

Developed in Python to make it easy to use, the tool was recently published on GitHub so that the entire incident response community can access it as open source: https://github.com/CERT-W/StormCell. CERT‑Wavestone intends for this tool to be used, tested, and improved directly by the community.

Although other similar tools have been developed and released since the beginning of its development, StormCell stands out through its modularity and its underlying technology choices, both geared towards speed and adaptability.

Three key stages : ingest, process and enrich, centralize

StormCell’s workflow is based on three key stages:

To properly perform those steps, StormCell relies on several third-party tools : whether it is for artifacts collection with Kape, enrichment and ingestion of logs into a SIEM with Vector or SIEM built-in functionalities with Splunk or ELK.

Despite these dependencies, the tool only needs to be installed and configured once on a single workstation before it can be used throughout the incident response by all analysts.

Extract and Ingest

StormCell is designed to work with two types of forensics collections: disk images and artifact ZIP extracts produced by Kape.

When StormCell is run against a disk image, it directly uses Kape to extract the relevant artifacts.

Compatible ZIP archives can also be generated with the CERT‑Wavestone tool CollectRaptor, which is based on Velociraptor, or with any other collection performed using the Velociraptor KapeTarget module.

Process and Enrich

Once raw artifacts are extracted, the core of the processing chain comes into play: the artifacts are processed with Kape.

Kape is used because it is a tool dedicated to Windows forensics artifacts parsing. It allows, through modules, to automatically execute several tools such as the Zimmerman Suite, Hayabusa or even Chainsaw. Moreover, logs parsed by Kape are directly organized on the filesystem by artifact category (executions, filesystem, registries, etc.) allowing to perform efficient local and manual analysis whenever necessary.

As a whole, StormCell uses Kape to run more than thirty artifact‑processing tools, each covering a complementary analysis scope and ensuring a high level of exhaustiveness for the elements available to analysts.

All these tools can be easily downloaded through the StormCell installation command described in its Readme. StormCell’s modular configuration also makes it simple to integrate new artifact‑processing tools as needed.

Centralize

Once the artifacts have been parsed by Kape, the generated logs are normalized, enriched, and sent to a SIEM platform through Vector, an open‑source tool particularly well‑suited to handling large volumes of data.

To determine which artifacts to send, as well as the normalizations and enrichments to apply, Vector relies on its TOML configuration files. These files include parsers that structure raw data into meaningful fields, and sinks (output destinations) that route events to the target environment, whether a client’s ELK or Splunk instance, or an internal ELK instance dedicated to CERT‑Wavestone.

To retrieve these configurations, StormCell uses the configuration files from the GitHub repository Vector4IR whose CERT‑Wavestone is a contributor.

A major time-saver for analysts

By chaining these three stages together, each forensic collection only needs to be processed once before it becomes available in the SIEM for all analysts. This makes it possible to carry out global investigations while fully leveraging the built‑in capabilities of SIEM technologies: search languages, dashboards and saved searches, lookups and data tables, correlation features, and so on.

The retrieval of collections and their handling with StormCell can be handled by a single analyst, while the others can already begin investigating in real time as the logs are being sent.

StormCell execution modes

According to the setup and configuration details provided in the Readme of the Github repository, a dedicated setup command can be used to download all the tools required for StormCell to properly operate. In addition, numerous options, described in the default configuration file and the help command, are available to accommodate different execution requirements.

For example, it is possible to specify which Kape modules should run, or to force a fresh processing and re‑ingestion of logs. Because StormCell uses a local database file to maintain state across successive executions, its behavior can be completely reset by removing this database.

Finally, StormCell offers three complementary execution modes, designed to adapt to every investigation context, from small scopes to large‑scale crises, and to let analysts be operational as quickly as possible, regardless of the types of resources available to them.

Once mode: small scopes and need for rapid investigation

Designed specifically for targeted investigations on a limited scope, this mode handles a set of preexisting collections in a single execution.

After an initial configuration by the analysts, the tool executes and enables the analysis of the collections without any additional steps.

Mountpoint mode: local collect and analysis in a single command

Mountpoint is StormCell’s end‑to‑end execution mode: from collecting artifacts on a disk or a locally mounted forensic copy all the way to sending them into the SIEM.

This mode is preferred when analyzing disk copies, and it natively includes artifact extraction through Kape’s built‑in capabilities. Once the extraction is complete, its behavior is similar to the Once mode.

Loop mode : Continuous processing for large‑scale investigations

CERT-Wavestone’s preferred mode, it is designed for large‑scale crises and aims to enable StormCell to run continuously throughout the incident. Once configured, the tool monitors a designated folder and automatically processes all collections placed there by the analysts.

This centralized drop‑off folder becomes the logistical core of the investigation: once it is set up, analysts no longer need to worry about processing collections, whether the incident lasts a few days or several weeks, and can simply deposit the triage images then access the processed data in the SIEM platform being used.

Finally, two levels of artifact processing can be configured to best match analysts’ needs when investigations are carried out on new machines:

• Short: a lightweight treatment prioritizing speed, suited to surface‑level analyses that quickly assess a machine and help prioritize investigations.
• Long: an exhaustive treatment that activates in‑depth analysis modules, intended for detailed investigations requiring a full view of the machine’s activity.

The modules to be executed in both modes can be freely configured by the analyst using StormCell. These two complementary modes make it possible to deposit archives initially into the Short folder to obtain a quick but non-exhaustive list of artifacts, then later in the investigations, deposit them into the Long folder to obtain an exhaustive list of artifacts.

StormCell : What’s next ?

StormCell is currently a key tool frequently used within CERT‑Wavestone to accelerate the processing of Windows artifacts during its investigations.

Its orchestration capabilities are planned to be extended to investigations on Cloud environments, particularly M365, as well as Linux and macOS, while also exploring the integration of new forensic sources and advanced technologies such as the use of AI.

That’s why CERT‑Wavestone invites you to contribute to its evolution: forks, pull requests, and feedback from your operational experience are welcome, so that StormCell can become the most suitable tool possible for incident response needs.

Cet article StormCell: How our blue team scales up incident response 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.

CHATGPT

What opportunities for the underground world of cybercrime ?

Need a refresh about ChatGPT?

Figure 1 – Screenshot from ChatGPT when prompted “Introduce ChatGPT in a funny way and at the first person”

Unless living under a rock, you have heard about the incredibly notorious AI powered chatbot developed by OpenAI: Chat GPT, a tool that relies on the Generative Pre-trained Transformer architecture. But just in case, you must know that ChatGPT has been trained on a vast amount of data from the Internet and is able to understand human speech and interact with users. Chat GPT has not finished to be talked about: on March 14^th 2023, Open AI has announced the arrival of Chat GPT 4.0[i].

The growing popularity and potential future applications of ChatGPT have also caught the attention of cybercriminals. Nord VPN’s examination of Dark Web posts from January 13th to February 13th revealed a significant increase in Darkweb forum threads discussing ChatGPT, jumping from 37 to 91 in just a month. The main topics of these threads included:

• Breaking ChatGPT
• Using ChatGPT to create Dark Web Marketplace scripts
• A new ChatGPT Trojan Binder
• ChatGPT as a phishing tool with answers indistinguishable from humans
• ChatGPT trojan
• ChatGPT jailbreak 2.0
• Progression of ChatGPT malware

Figure 2 – Screenshot from CheckPoint: Cybercriminal is using ChatGPT to improve Infostealer’s code

These threads give a first interesting overview of all the rogue usage that can involves ChatGPT or be carried out via the chatbot. Another key security concern could also be included in this list when thinking about ChatGPT’s limitations in terms of cybersecurity, which is the risk of personal and/or corporate data leak, that could lead to identity theft, fraud, or other malicious uses.

What are the plausible cybercriminal use cases?

 Figure 3 – Screenshot of a ChatGPT answer when prompted “Talk at the first person about possible cybercriminal usage of ChatGPT”

Use Case #1 – Support malware creation and kill chain attack

ChatGPT is designed to decline inappropriate requests but there are ways to bypass its restrictions and generate malicious code. For example, instead of directly requesting a ransomware script, users can describe step-by-step functions needed for such a script, ultimately receiving functional parts of malicious code.

Figure 4 – Screenshot of a ChatGPT answer to the request “Write me a function named “find_files” in Python that searches all files that end up with “txt, pdf, docx, ppt, xlsm” starting from the root directory and that return all paths of files that match with the criteria”.

It has been proven possible to use ChatGPT to insert harmful code into a commonly used computer program and create programs that constantly change their appearance, making them harder for security software to detect and block and to obtain an entire process of an artificial intelligence-driven cyberattack, starting with targeted phishing emails and ending with gaining unauthorized access to someone’s computer.

Figure 5 – Screenshot from CheckPoint: Example of the ability to create a malware code without anti-abuse restrictions in a Telegram bot utilizing the OpenAI API

However, as highlighted by NCSC and Kaspersky, using ChatGPT for creating malware is not that reliable, due to potential errors and logical loopholes in the generated code, and even if it provides a certain level of support, the tool doesn’t currently reach the level of cyber professional.

Use Case #2 – Discover and exploit vulnerabilities

When it comes to code vulnerabilities, ChatGPT raises several challenges in terms of detection and exploitation.

In terms of detection, ChatGPT is currently able to detect vulnerabilities in any piece of code submitted if properly prompted to do so, but it can also debug code. For example, when a computer security researcher asked ChatGPT to solve a capture-the-flag challenge, it successfully detected a buffer overflow vulnerability and wrote code to exploit it, with only a minor error that was later corrected.

In terms of exploitation, the risks posed by ChatGPT, and more generally Large Language Models (LLMs) can be used to produce malicious code or exploits despite restrictions, as they can be bypassed. Additionally, LLMs may generate vulnerable and misaligned code, and while future models will be trained to produce more secure code, it’s not the case yet. Moreover, some security researchers remain skeptical about AI’s ability to create modern exploits that require new techniques.

Use Case #3 – Create persuasive content for phishing and scam operations

Creating persuasive text is a major strength of GPT-3.5/ChatGPT, and GPT-4 performs even better in this area. Consequently, it’s highly probable that automated spear phishing attacks using chatbots already exist. Crafting targeted phishing messages for individual victims is more resource-intensive, which is why this technique is typically reserved for specific attacks.

Figure 6 – Screenshot from chatGPT, pishing mail generation

ChatGPT has the potential to significantly change this dynamic, as it allows cybercriminals to produce personalized and compelling messages for each target. To include all necessary components, however, the chatbot requires detailed instructions.

A notable advantage of ChatGPT is its capability to interact and create content in multiple languages, complete with reliable translation. In the past, this was a key way to identify scams and phishing attempts. While some methods are being developed to detect content created by ChatGPT, they haven’t yet proven entirely effective.

This poses a significant risk to all companies, as it makes their employees more susceptible to such attacks and may expose their resources if passwords are stolen in this manner. As mentioned earlier, it is essential to raise awareness about this issue while also strengthening authentication methods, such as implementing two-factor authentication as a potential solution.

Interestingly, other uses have been made of ChatGPT notoriety to develop scams without using the tool itself, such as phishing mails/Scams in order to push towards the purchase of a (fake) ChatGPT subscription and to provide personal data details

Use Case #4 Exploit companies’ data

ChatGPT has been trained on a massive amount of internet data, including personal sites and media content, meaning that it may have access to personal data that is currently hard to remove or control, as no “right to be forgotten” measures exist to date. Consequently, ChatGPT’s compliance with regulations like GDPR is under debate. GPT-4 can manage basic tasks related to personal and geographic information, such as identifying locations connected to phone numbers or educational institutions. By combining these capabilities, GPT-4 could be used to identify individuals when paired with external data.

Another significant concern is the sensitive information users might provide through prompts. Users could inadvertently share confidential information when seeking assistance or using the chatbot for tasks, like reviewing and enhancing a draft contract. This information may appear in future responses to other users’ prompts. They might not only find their confidential documents or research leaked on such platforms due to employees’ inattention, but also reveal information about their system or employees which will be used by hacker to facilitate an intrusion. The primary course of action should be to increase awareness on this subject by providing formation and explanation or to restrict access to the website in the sensitive domains until there is a better comprehension of how data is utilized.

Not only the real ChatGPT can be used for this objective, but the creation of other chatbots using the same model as ChatGPT but configured to trick victims into disclosing sensitive information or downloading malware has also been observed.

Use Case #5 Disinformation campaigns

ChatGPT can be used to quickly write very convincing articles and speeches based on fake news. The American startup Newsguard has conducted an experience on ChatGPT to demonstrate its disinformation potential: on 100 fake information submitted to ChatGPT, the tool has produced fake detailed articles, essays and TV scripts for 80 of them, including significant topics such as Covid-19 and Ukraine[ii].

As highlighted (again) by the war between Ukraine and Russia, the crucial role of information and disinformation through cyber channels, can have significant consequences.

Use Case #6 Create darknet marketplace

Cybercriminals have also been observed using ChatGPT to support the creation of DarkWeb marketplaces. ChekPoint has illustrated this phenomenon with some examples[iii]:

• A cybercriminal post on a Darkweb forum showing how to code with ChatGPT a DarkWeb Market script that does not rely on Python or Java Script, using third-party API to get up-to-date cryptocurrency (Monero, Bitcoin and Etherium) prices as part of the Dark Web market payment system.
• Dark web discussions threads linked to fraudulent usage of ChatGPT, such as how to generate an e-book or a short chapter using ChatGPT and then sell its content online.

Figure 2 – Screenshot from CheckPoint: Multiple threads in the underground forums on how to use ChatGPT for fraud activity

What are the key take aways?

Even if ChatGPT tends to lack of the necessary level of features, it can still be a useful tool to facilitate cyberattacks. Even if it is an obvious support tool mostly for script kiddies and unexperimented actors, ChatGPT – as any AI tool – can be a facilitator for any type of hackers, either to completely conceive a malware, to accelerate malicious actions such as phishing or to increase the sophistication level of cyberattacks.

With the release of GPT-4, OpenAI has made efforts to counter inappropriate requests, however ChatGPT  still raise serious security issues and challenges for business security. It is important to keep in mind that the malicious use cases detailed in the previous section are only hypothetical scenarios: malicious use of ChatGPT has already been observed and it is essential to convey strong cybersecurity messages on the topic:

• Don’t include sensitive info in queries to #ChatGPT : Avoid personal/sensitive information sharing while using ChatGPT
• Stay informed and vigilant: AI-related topics are evolving quickly, it is central to stay put regarding tools evolution (e.g. release of Chat GPT 4.0), and new security topics that can emerged over time
• Scams and phishing are likely to become more and more realistic in their crafting: continue raising awareness about this risk and train yourself and your ecosystem
• Basic cybersecurity practices are still true: have a regular vulnerability management, set up doble authentication, train your teams and raise awareness…
• ChatGPT opening the door to the possibility of creating realistic fake content, it is central to stay informed about tooling initiatives aiming at detecting machine-written text such as GPT Zero, a tool developed by Princeton student (Note: OpenAI is also working on a tool to detect machine-written text, but is for now far from being perfect since it detect machine-written text only one in four times)

Reading of the Month

CERT-EU : RUSSIA’S WAR ON UKRAINE: ONE YEAR OF CYBER OPERATIONS

https://cert.europa.eu/static/MEMO/2023/TLP-CLEAR-CERT-EU-1YUA-CyberOps.pdf

[i] https://cdn.openai.com/papers/gpt-4.pd

[ii] https://www.newsguardtech.com/misinformation-monitor/jan-2023/

[iii] https://research.checkpoint.com/2023/opwnai-cybercriminals-starting-to-use-chatgpt/

Cet article CDT Watch – March 2023 est apparu en premier sur RiskInsight.

BLINDSIDE

Facing the EDR behavioral supervision, attackers develop techniques for successful attacks by staying under the radars. One of these techniques is called Blindside. This technique works on many EDRs relying on a hook and was revealed by Cymulate. 

According to Cymulate, the author of Blindside, the technique is not immune to detection. Some mitigations can be implemented such as:

• Monitor the use of the SetThreadContext function: the function context can inform on breakpoint setting (write inside debug address registers)
• Monitor the presence of suspicious debug functions
• Edit EDR settings for checking debug registers

It remains difficult to bypass EDR solutions as their detection methods vary between vendors. Nevertheless, it is important to remember that it is possible and that the security should not rely solely on the solution.

CERT-W: FROM THE FRONT LINE

THE FIRST RESPONDER WORD

READING OF THE MONTH

SOPHOS: MATURING CRIMINAL MARKETPLACES PRESENT NEW CHALLENGES TO DEFENDERS

Maturing criminal marketplaces present new challenges to defenders, Sophos 2023 Threat Report

VULNERABILITY OF THE MONTH

PROXYNOTSHELL: WHEN APPLYING MITIGATIONS KEEPS YOU VULNERABLE

CVE-2022-41040 & CVE-2022-41082

Published by NVD: 02/10/2022

Products: Microsoft Exchange server

Versions: on-site/on premise 2013, 2016 and 2019

Score: 8.8 HIGH

Context   PoC

Microsoft Exchange is a mailbox server exclusively running on the Windows operating système.

In September 2022, a vulnerability to compromise the underlying Exchange server was discovered. It was named ProxyNotShell after its similarities with the ProxyShell vulnerability. To exploit ProxyNotShell, attackers need to have an authentified access to the Microsoft Echange server. The exploitation of the vulnerability allows attacker to deploy a webshell on the targeted server, giving them an initial access.

Around November, a number of mitigations (Hotfix) were released awaiting for a patch. As a result, some 60 000 servers worldwide still are vulnerables since the few mitigations rules can be bypassed by attackers.

According to CrowdStrike, Play ransomware group, which has been active since last June, took advantage of this in using a new exploit to bypass the URL rewrite mitigations for the Autodiscover endpoint. Early December the managed cloud hosting services company Rackspace technology complies to having been attacked after a successful exploit of the vulnerability in Microsoft Exchange Server.

The Microsoft Exchange server should have at least the KB5019758 patch. If not, the main action to perform is to immediately install the updates on the vulnerable servers. If some factors make the installation impossible, it is adviced to disable OWA until it can be applied. In addition, it is strongly recommended to disable remote PowerShell for non-admin users and use EDR tools to detect if web services are spawning PowerShell processes.

SEE YOU NEXT MONTH!!

Cet article CDT Watch – January 2023 est apparu en premier sur RiskInsight.

BRING YOUR OWN VULNERABLE KERNEL DRIVER (BYOVKD)

Facing the EDR behavioral supervision, attacker develops techniques for successful attacks by staying under the radars. One of these techniques is called BYOVKD: Bring Your Own Vulnerable Kernel Driver.

Even if it does not raise an alert on the EDR console, the Defense team must be vigilant to any telemetry that would indicate the loading of an unusual driver on assets. Furthermore, prevention mechanisms exist for this type of case, some examples below:

• Block abuse of exploited vulnerable signed drivers
• Driver block rules

CERT-W: FROM THE FRONT LINE

THE FIRST RESPONDER WORD

READING OF THE MONTH

EMOTET

What is Emotet 2022?

Emotet is a Malware-as-a-Service (MaaS) relying on a botnet network which appeared in 2014. It was originally designed as a banking Trojan aiming to steal sensitive information related to bank accounts. In 2021, police forces arrested several people belonging to Emotet organization, which then reappeared with new features in 2022. The group behind Emotet seems to be opportunist and most of its victims are from US, UK, Japan, Germany, Italy, Spain, France, and Brazil.

Why is it dangerous?

Emotet is a polymorphic malware whose code changes over time. Among the numerous new features of the 2022 version, searchers from the DFIR Report have identified an ability to bypass anti-malware detection. To do that, Emotet 2022 uses a 64 bits base code and various signatures to avoid pattern recognition. The malware is also able to keep itself up to date once downloaded by using Command & Control servers, which send it updates the same as an Operating System. The MaaS is also able to release IcedID, which are modular banking Trojans able to drop other malwares. Doing so, Emotet helped to distribute ransomwares for impact, Cobalt Strike for initial access, XMRig for stealing wallet data…

How does Emotet 2022 initial infection work?

Using a phishing email with a malicious Office attachment, Emotet exploits a 2017 Microsoft vulnerability which allows remote code execution on vulnerable devices (CVE 2017-11882) to compromise its first victim.

Once downloaded in memory, the malware executes a sequence of legitimate Windows commands to perform a recognition of its environment, then spreads in the local network and steals information.

Emotet spreads through spam emails. According to Deep Instinct, 45% of them are containing malicious Office attachment such as Spreadsheets or scripts in most of the cases. As those emails traduce the object and attachments names in the target’s local language and come from known senders, the phishing looks particularly realistic.

Comprehensive look of EMOTET fall 2022

Why is this new version of the MaaS particularly tricky?

Emotet 2022 can identify whether it’s downloaded into a sandbox environment, or a device connected to a network. In the first configuration it won’t activate itself, but in the second it will rely on a password dictionary to spread thanks to brute-force.  Moreover, the November 2022 Excel files generally enclosed contains macros which no longer needs a user click to be authorized. The victim is only asked two things: copying the files into the Microsoft Office Template zone, which requires administrator privileges. Opening the file in this location will execute the macros without any warnings.

How to protect from Emotet 2022?

Since Emotet 2022 uses malicious spam and phishing is the most used technique for initial access, we highly advice you to consider these measures:

• Provide your company a solution against phishing.
• Launch an awareness campaign for employees and stakeholders.
• Provide you company an Endpoint Detection and Response which complete the anti-virus by performing behavioural analysis, which helps visualize the virus kill chain to identify the action levers.

Give a local administrator account to an employee only in case of specific need.

VULNERABILITY OF THE MONTH

DEBIAN-SPECIFIC REDIS SERVER LUA SANDBOX ESCAPE VULNERABILITY – CVE-2022-0543

Published by NVD: 18/02/2022

Products: Redis server for Debian and Debian-derived Linux distributions

Versions: less and equal to 5:5.0.14-1+deb10u2, 5:6.0.16-1+deb11u2, 5:7.0.5-1, 5:7.0.7-1

Score: 10 CRITICAL

Context  PoC

Redis is an opensource NoSQL database management system. Redis includes an embedded Lua scripting engine, it allows client to run scripts. By design, the Lua engine must be sandboxed: it means that packages and APIs available are limited in an execution context. Redis clients are not allowed to execute arbitrary code on the Redis server.

In some Debian and Debian-derived Linux packages, the Lua environment is not sufficiently regulated because the Lua Library is provided as a dynamic library. It can allow attackers to access arbitrary Lua functionalities and results in a Lua Sandbox escape.

Early December, reports indicate that attackers are exploiting this vulnerability to deploy a new backdoor malware dubbed Redigo on Redis Server. The malware communicates with a server of command and control using port 6379 which is a legitimate port used by Redis for communication between client and server: the Redis server joins a botnet network.

According to Aqua, the malware has some functions specially written to the Redis server which may imply that the group behind this desired to build an adjusted attack that would target Redis servers.

A successful attack implies that attacker could execute arbitrary commands and access to sensitive information.

A group of attackers is behind the Redigo malware which is an emerging threat. Furthermore, the exploit of the CVE-2022-0543 is public and is used in the wild to deploy the malware. Vulnerable Redis Server must be patched and up to date.

SEE YOU NEXT MONTH!!

Cet article CDT Watch – December 2022 est apparu en premier sur RiskInsight.

What are the supply chain threats?

What’s a picture of the current situation?

Since 2019, there has been a growing focus on third-party attacks. With good reason: CyberArck estimates in a study from 2022 that 71% of organizations suffered a successful

software supply chain-related attack that resulted in data loss or asset compromise. According to Argon Security – recently acquired by Aqua Security – published the latest edition of its annual Software Supply Chain Security Review this week. The Software Supply Chain Security Review from Argon’s report that software supply chain attacks grew by more than 300% in 2021 compared to 2020.

In terms of maturity, in 2022: a survey of 1,000 CIOs found that 82% said their organization is vulnerable to cyber-attacks targeting software supply chains (Venafi). From our own Cyberbenchmark, we can see that 50% of our interviewee don’t control their security requirements with their third party and 15% conduct audits on their most critical suppliers in 2022.

What kind of attacks are we talking about? 

Attacks on the supply chain are related to threats around third parties. ENISA defines this type of attack as follows: “ A supply chain attack is a combination of at least two attacks. The first attack is on a supplier that is then used to attack the target to gain access to its assets. The target can be the final customer or another supplier. Therefore, for an attack to be classified as a supply chain one, both the supplier and the customer have to be targets.”

As a reminder the supply chain involves a wide range of resources (hardware and software), storage (cloud or local), distribution mechanisms (web applications, online stores), and management software

• Indirect or bounce attack: An attack on one or more intermediate information systems. The attacker uses the supplier as an entry vector to retrieve the information needed to access the final target.
• Supply chain attack: the attacker relies on a software production chain to infect a legitimate program and distribute it to third parties.

Why is it serious?

First because these attacks are complicated to detect: originally used for espionage, these are attacks where the attacker aims to remain discreet until the attack is launched. Second because it is a one-to-many kind of attack. A small change in software source code can affect the entire supply chain (plus, the chains are increasingly interconnected). The most known example is Kaseya and its 800 and 1,500 total businesses affected victims. Thirdly, many enterprises don’t have enough visibility on their ecosystem to anticipate or even detect the flaws in their IS. As we have seen, the security maturity in this field is currently quite low.

There are some aggravating factors:

• The cyber criminal’s ecosystem has matured and industrialized, allowing more sophisticated attacks to target matured victims. ​They can therefore afford this kind of sophisticated attack which used to take time, financial investment, and expertise…
• Expansion of the attack surface: The IS ecosystem is increasingly large, and increasingly interconnected, and more and more third parties are involved. They have potentially less control of the IS and less visibility, therefore potentially less control of the security of all these third parties, particularly in IAM management: who has very privileged access rights to its IS…
• The risk is to give access to third parties who can represent entry points for attackers: to one’s IS and to one’s sensitive data since one shares them with third parties
• In 2021, in an analysis conducted with 1200 CISOs (in America, Europe and Singapore), about 38% of respondents said that they had no way of knowing when or whether an issue arises with a third-party supplier’s cybersecurity (in 2020, it was 31%) (BlueVoyant66)
• Github estimates that there is 203 dependencies on an average software project in 2022.  If a popular app includes one compromised dependency, every business that downloads from the vendor is compromised as well, so the number of victims can grow exponentially.

Examples of attacks

• Compromise intermediate elements of the supply chain​ (i.e. source code tools) ​

Midstream attacks target intermediate elements such as software development tools, manipulating the build process of the artifact​

• Ex: SolarWinds
• Compromise upstream software ​(i.e. compromising the source code)​

Infects a system that is ‘upstream’ of users, for example through a malicious update, which then infects all ‘downstream’ users who download it. ​

• One of the biggest was the compromise of CCleaner 2017 update  with 2.3 million users impacted

• Compromise project interdependencies​

Compromise third-party components, such as an open-source package​

Dependencies confusion: the attackers provide a fake “new” upgrade of a software’s project needed component for the targeted software to automatically download it and implement it in the project. ​

• Ex: Apple, Microsoft, Uber, Paypal (BugBounty 2020)

Within these strategies, one of the most impactful methods is to target the CI/CD pipeline. If the infrastructure is not secured enough and there is a poor access management (our audit teams often see this), it can be easily targeted. Once compromised, the attacker has access to a part of the critical ‘linfra, to the source code of the application and the infrastructure and can generally do what he wants

The impacts are high:

• Attackers have access to critical IT infrastructure, development processes, source code, libraries, and applications: ​
• Modify the code or inject malicious code during the build process and alter the application ​
• Deploy malware via the orchestrator directly on production environments

CERT-W: FROM THE FRONT LINE

The First Responder Word

READING OF THE MONTH

ENISA

This is the tenth edition of the ENISA Threat Landscape (ETL) report, an annual report on the status of the cybersecurity threat landscape. It identifies the top threats, major trends observed with respect to threats, threat actors and attack techniques, as well as impact and motivation analysis.

Link to the report

SEE YOU NEXT MONTH!!

Cet article CDT Watch – November 2022 est apparu en premier sur RiskInsight.

MAUI

Sources:

https://www.cisa.gov/uscert/ncas/alerts/aa22-187a

https://stairwell.com/wp-content/uploads/2022/07/Stairwell-Threat-Report-Maui-Ransomware.pdf

https://securelist.com/andariel-deploys-dtrack-and-maui-ransomware/107063/

Ransomware Activity

Presentation of the figures collected by our tool on the data given by the RaaS platforms about their successful attacks. This graph gives an estimation of the number of victims by the most active RaaS groups, by month.

Number of announced victims by the most active Ransomware-as-a-Service (RaaS) for the past 10 months:

Noticeable change:

• Lockbit2.0 disappears to make room for Lockbit3.0
• Conti’s number of victims is dropping after May 2022. It does not mean that the individuals stopped their activities since the organization could have been divided into several groups after the events related to the Russian situation in April 2022 and come back under other names.
• The activity has decreased during the summer of 2022, except for Lockbit 3.0.

   Number of announced victims by the 15 most active RaaS groups for the past 10 months:

It must be taken into account that the data is based on the RaaS declaration of victims, the graphs are therefore an estimation of the reality.

CERT-W: FROM THE FRONT LINE

The First Responder Word

VULNERABILITY OF THE MONTH

Sophos Firewall

SEE YOU NEXT MONTH!!

Cet article CDT Watch – September 2022 est apparu en premier sur RiskInsight.

Bumblebee

SOURCES :

Bumblebee is still transforming, Proofpoint

[1] https://www.malware-traffic-analysis.net/2022/index.html

[2]https://isc.sans.edu/forums/diary/How+the+Contact+Forms+campaign+tricks+people/28142/

CERT-W: FROM THE FRONT LINE

The First Responder Word

Reading Of The Month

We recommend the article of Robert Lemos, a darkreading contributing writer about firms which suffers identity-related breaches.

80% of firms suffered identity-related breaches in last 12 months, Robert Lemos

SEE YOU NEXT MONTH!!

Cet article CDT Watch – June 2022 est apparu en premier sur RiskInsight.

The marketplaces of stolen data

Which type of data are sold?

The different platforms of marketplaces sell different types of data. While some platforms are really focused on selling one specific “product” (eg. hacking forums where Initial Access to companies is sold, as well as auction sites to sell stolen data eg. REvil and its auction site back in 2020), other platforms thrive with a very wide panel of goods, ranging from various weapons to “fullz” (full data about people: Social Security numbers, Bank account numbers, ID,…) without forgetting per-install malware service and financial information about a company. Overall, personal data is one of the most common types one can find on these marketplaces, as well as organization initial access, and non-financial or financial accounts/credentials.

When it comes to prices, whereas the number and variety of data items sold are increasing, the prices are declining as the market grows.

The price of an Initial Access depends on its quality, but it ranges from a couple of hundred USD for a small company to hundreds of thousands of dollars for the bigger ones. The average price is $7,100 in 2021. Patricia Ruffio listed here the prices found per type of data, from credit card data with account balance up to 5K ($120) to social media account ($65 for a gmail account), going through PayPal account logins ($150 for 50 accounts) and European Passport ($3,800). In comparison, DDOSing an unprotected website for a month now costs $850 on average and installing malware on a thousand devices ranges from $45 to $5500 depending on its quality and success rate.

Last but not least, some ransomware groups such as BlackByte go as far as selling stolen data on dedicated auction sites, not only as a means of pressure on victim companies, but also as a very juicy second revenue stream, with starting bids reaching up to $500,000.

What’s the selling process?

Besides a classical strategy of competitivity between the different marketplaces, based on discounts or fidelity points, the platforms are fighting over a security aspect in order to gain the buyer’s trust.

With the growth of marketplaces comes a strong trend for the sellers to strengthen their client’s trust. Taking advantage of legal uncertainty, these websites or events like the Evolution Marketplace exit scam with over $12 million in Bitcoin have greatly tarnished their reputation and taken its toll on customer and vendor trust.

As a result, along with the numerous DDOS protection, layers marketplaces now hide behind to prevent attacks from rivals, the quality of vendors and their items is now more thoroughly assessed and monitored. Direct scams are supposedly prevented by using the marketplace platform as an intermediate deposit for payment so that a client may be refunded in case of deception by the vendor. All transactions are currently mainly in Bitcoin and Monero for anonymity purposes.  Some auction and IAB platforms even sometimes use mandatory referral systems to shield themselves from outsiders & untrustworthy members.

Consequently, dark web marketplaces seem more reliable and stolen data is more prone to be sold quickly.

Once sold, what are the stolen data used for?

The financial reason is undoubtedly the main aspect for many actors in the market: most of these data can be used directly for blackmail of course, or to launch another cyberattack with a bigger impact…and more gains. It can be “standard” attacks such as personal data simply used as a basis for phishing operations and for compromising, for example, bank accounts, or it can be larger attacks. In fact, the average ransom paid by companies rose up to $541k according to the 2022 Unit 42 Ransomware Threat Report, highlighting the high profitability of simple ransom and blackmail with the stolen data. While not as straightforward, leveraging stolen Social Security Numbers, IDs, Credit cards are other ways to generate profit or to gain access to companies using identity theft.

However, stolen data may be used for more varied purposes. Corporate espionage is one of them: should a competitor be informed of a potential data leak, and what prevents it from looking at your deepest hidden secrets? It can also be a political matter: for example when Lockbit2.0 hits the French ministry of Justice, the main concerns shift to who laid their hands on such potentially sensitive pieces of information and what their intentions are. Another example of societal impact would be the data breach of Pfizer/BioNTech vaccines data in 2020, which led to attackers modifying the stolen data on the vaccine and publishing them with the headline “Vaccines are malicious”.

What are the impacts on my organization?

As mentioned, the collected data such as initial access can be the essential vector to compromise an organization’s SI and lead to even more impacting attacks. Besides, the main victim’s perimeter is not the only one compromised: the whole ecosystem of partners, clients, and providers… can be affected. If the ransomware is the first type of attack coming to mind after a data breach, one should not underestimate the impacts of identity impersonation and fraud, targeted DDoS…

As it has often been proven and discussed these last years, the financial impact of such compromission can be colossal and even led organizations to their end. Besides, the cost of the attack itself is not the only one to be taken into account. Other components must be considered: loss of customer’s trust, loss due to potential system’s unavailability, cost of intervention from experts to investigate, but also cost of new customer acquisition to win back those that have been lost. Just as an example, Equifax announced that the data breach it faced in 2017 cost around $1.5 billion dollars if not more.

The financial and reputational impacts are intrinsically linked. Indeed, upon facing a data breach, a company is very likely to get customer or partner disengagement. According to a report from IBM, the lost business contributes to 38% of data breach costs. Companies also handle PII (Personally Identifiable Information) which, if stolen, can lead to additional legal costs, class-action settlements, or fines from public institutions.

The total cost of a data breach could be deadly for some companies and must be acknowledged. Equifax spent several million in fines and settlements after dealing with its massive data breach in 2017.

Last but not least, the social and political aspects must not be neglected. Last year, the Labour Party suffered a data breach through a ransomware attack on a third-party supplier. This kind of attack can lead to disinformation campaigns or even interferences in the election process.

In order to prevent a data breach, beyond cybersecurity basic actions, companies must enhance their maturity level when it comes to data security. Evaluating the value of the data is one of the key: the more attractive the data is, the greater chance an attacker will try to steal it. Storage and network security, Identity and Access Management, Cyber Resilience are some of the topics to be addressed at first. On top of this, companies should also focus on creating a strong watch on cybersecurity events and implement, even small, Cyber Threat Intelligence programs. Looking at the cybercrime ecosystem as well as spotting potential attack vectors and modus operandi is never a bad idea to anticipate a cyberattack.

CERT-W: FROM THE FRONT LINE

The First Responder Word

Reading Of The Month

We recommend the Citalid overview of the

Russio-Ukrainien conflit’s cyber aspect

(click on the picture)

SEE YOU NEXT MONTH!!

Cet article CDT Watch – May 2022 est apparu en premier sur RiskInsight.

Overview

Spring is a lightweight opensource application framework for Java. It allows for easy development and testing of Java applications.
Spring is used to create Java enterprise applications. It provides means to build applications and supports different scenarios.
A new vulnerability was found in Spring Core leading to a Remote Code Execution.

On March 31st, a CVE was released: Spring4Shell (CVE-2022-22965)

Exploitability

Prerequisites

/ JDK9.0 or higher

/ Spring Framework 5.3.0 to 5.3.17 or 5.2.0 to 5.2.19 & older versions

/ Apache Tomcat as the servlet container

/ Spring-webmvc or spring-webflux dependency

/ Packaged as a traditional WAR

Risks 

Once all prerequisites are met, the Spring4Shell exploit allows for unauthenticated Remote Code Execution on the vulnerable host. This initial access may lead to further harmful infection steps by attackers.

A list of applications and vendors that have published a statement indicating if their product was affected is available:

https://www.kb.cert.org/vuls/id/970766

Difficulty

Many researchers are still sceptical as to how achievable this exploit is. It is now clear that due to the heavy prerequisites of the exploit, it should occur in fewer cases than the Log4Shell exploit. However, once the prerequisites are met, exploiting the vulnerability is pretty straightforward and has fewer constraints than Log4Shell (egress traffic is not needed).

Real-world examples

Some real-world examples meet the prerequisites. Some researchers have found that the Handling Form submission sample code provided by Spring in one of their tutorials is vulnerable to the Spring4Shell exploit.

Mitigations

Main recommendation: Update applications to Spring Framework 5.3.18 or 5.2.20 if possible

Manual workaround:

This section is applicable only if it is not possible to update the applications as mentioned above.

A temporary fix may be manually applied to mitigate the possibility of the Spring4Shell exploit: the following class must be created under the project package of the application system. After making sure the class is loaded by Spring, the project must be recompiled. This workaround only works against exploits known at this time, it’s effectiveness may not be guaranteed in the long term.

Good practice:

Point of attention:

The Spring4Shell exploit only provides command execution on the vulnerable host: it allows for initial access on a server exposed to the Internet. Commands will be executed in the context of the running application. A healthy, up-to-date infrastructure, as well as a good application of the least privilege principle, may greatly mitigate Spring4Shell’s impact.

Cet article Identity card of the Spring4Shell vulnerability by CERT-W est apparu en premier sur RiskInsight.

Conti Kill Chain

SOURCES :

CERT-W: FROM THE FRONT LINE

The First Responder Word

READING OF THE MONTH

We recommend the interview of Pompompurin, a cyber activist who’s work ranges from leaking the data of thousands of WeLeakInfo Users to abusing the FBI’s Servers to send thousands of false emails.

The interview by Data Knight

Cet article CDT Watch – March 2022 est apparu en premier sur RiskInsight.

THE RISE OF INITIAL ACCESS BROKERS

As seen in the underground economy edition, the cybercriminal economy relies on the professionalization and specialization of its system. Among the main actors of this ecosystem, such as the Bullet Proof Hoster or the RaaS, the Initial Access Brokers (IAB) have become more and more crucial these last years. 

What is the IAB’s role in the underground economy?  

They are providers of victims’ access. They scan the web for vulnerabilities, send phishing e-mails or try to use brute force to get hold of the passwords of company employees, or even create persistent access in the victim’s network. Those ready-made ‘access’ are sold on the dark market: depending on its level of quality, prices can range from $1K to $100K. The average selling price of initial access to a network is $7,100. Price is based on the organization’s revenue, type of access sold, and number of devices accessible. For example, Access to an Australian company with 500 million USD in revenue that enables an attacker with “admin” level of privileges has been offered for 12 BTC, and access to a Mexican government body for 100,000 USD. 

The market of corporate initial access grew by almost 16% in H2 2020–H1 2021, from $6,189,388 to $7,165,387. The number of offers to sell access to companies almost tripled over the review period: from 362 to 1,099.  The geography of initial access brokers’ operations has also expanded: if the US-based companies are the most popular victims (30% in 2021), the European companies access sold was multiplied by three between 2019 and 2021. French companies were the most popular lot for sellers of access to compromised networks – they accounted for 20% of all victim companies in 2021 in Europe, followed by the UK (18%). 

Finding and selecting access opportunities represent an essential but very time-consuming piece of the current “ransomware business model”. By monetizing this activity, the IABs are offering a huge advantage of time and energy for the buyers, who can select from a menu of options, picking victims based on their revenue, country, and sector, as well as the type of remote access being offered. 

What kind of access are we talking about? 

One of the main trends of the IAB market is the diversification of access Grows. If RDP and VPN are still the most common offer, new attack vectors such as access to VMWare’s ESXi servers have become quite popular. 

According to several types of research, the kind of access mostly sold are   

• Active Directory credentials: domain administrator access is one of the most valuable access since it allows the attacker to distribute malware all over the network immediately.  
• Initial Network Access (RDP, VPN, SSH): : is one the most common access sold since it is a very popular protocol among remote workers to access their corporate resources. One of the methods used by the IAB is to launch massive scans for RDP servers all around the internet and try to brute force it. 
• Web shell access: some IABs set up web shells on compromised web servers and sell access to it. 
• Admin account on CMS (WordPress, PHP): they provide access to web hosting content (including payment solutions and credit card details)  
• Admin account on virtualization machines and root access on Linux servers: the sale of root access to VMware ESXi increased significantly and some attacker’s group contains code that specifically targets those systems. 
• Remote Monitoring and Management access: offer elevated permissions into several machines of the network, making it interesting data for IABs to sell. 

According to the IAB, the services can include more stolen data, such as information on the financial health of the targeted victim, to help the attacker set the highest realistic price for the ransom.  

What does that mean for me? 

The rise of the IABs activity is, among other things, a direct consequence of the mass shift to remote work and an increase of exposed remote services, (RDP, SSH…) and of the adoption of cloud applications increase. As seen; the main kinds of access sold relies on several vulnerabilities that can be corrected with standard cybersecurity measures: utilize strong passwords, enable 2FA when possible, admins and user awareness, frequent account review… 

Besides, the IABs have become a keystone of the current cybercriminal system. Which means they are an interesting indicator to look at to monitor the criminal activity and the risk to become a target. Especially in the case of a mature actor, setting up monitoring programs across surface-, deep-, and dark-web forums and marketplaces, to detect IABs offering can provide relevant information to prioritize defense actions and prepare against potential attacks.

CERT-W: FROM THE FRONT LINE

The First Responder Word

READING OF THE MONTH

We recommend the Cisco Almanac for 2022:  

“2022 Cybersecurity Almanac: 100 Facts, Figures, Predictions and Statistics” 

2022 Cybersecurity Almanac 

 

UPDATE ON THE UK NATIONAL CYBER STRATEGY

The UK’s National Cyber Strategy transmits a more ‘proactive’ stance to cyber power with a commitment to a ‘whole of society’ approach. The new strategy is supported by £2.6 billion investment seeing a 26.9% percent increase in comparison to previous strategy.

It is structured in five pillars: UK Cyber Ecosystem, Cyber Resilience, Technology advantage, Global leadership and finally Countering threats with 53 action plans. The plans aim to improve intel sharing platforms to truly ‘defend as one’ with a new Govt Cyber Coordination Centre (GCCC). Supporting industrial partners and strengthening business regulations through govt levers and enhance the nation’s cyber structure and skills.

Access the summary from the UK office here!

SEE YOU NEXT MONTH!!

Cet article CDT Watch – February 2022 est apparu en premier sur RiskInsight.

SysJoker: Windows Version

To produce this tech focus, we used data from:

New SysJoker Backdoor Targets Windows, Linux, and macOS – Intezer

CERT-W: FROM THE FRONT LINE

The First Responder Word

Reading Of The Month

To learn more about the main trends anticipated by Sophos for cybersecurity in 2022, it is here:

Interrelated threats target an interdependent world, Sophos

Cet article CDT Watch – January 2022 est apparu en premier sur RiskInsight.

File Obfuscation

Discover Cobalt Strike capabilities with the technical zoom of the month:

To learn more about the given malwares:

Cobalt Strike Training videos

CERT-W: FROM THE FRONT LINE

The First Responder Word

We recommend the 2021 Benchmark on cybersecurity incidents which reviews the interventions of the CERT-W carried out between September 2020 and October 2021. This Benchmark provides keys to understanding the security issues and a snapshot of current cybersecurity threats in France.

CERT-W’s 2021 Benchmark on cybersecurity incidents

Reading Of The Month

To learn more about Conti, one of the most dangerous Ransomware, we recommend reading the Conti Ransomware Group In-Depth Analysis of Prodaft. According to Prodaft, this report will show you how the gang works with details obtained by their team who accessed Conti’s infrastructure.

Conti Ransomware Group In-Depth Analysis by Prodaft

Cet article CDT Watch – November 2021 est apparu en premier sur RiskInsight.

This represents 60 major security incidents that led to business interruption or advanced IS compromise in a diverse sector:  industry, public sector, agri-food, information technology, finance, etc. The objective of this benchmark is to shed light on and show the evolution of the state of the cyber threats, whilst also providing the keys for better anticipation and reaction.

A strong preponderance of ransomware in the panorama of cyberattacks

Ransomware accounts for 60% of the cyberattacks encountered by CERT-W for our customers. Furthermore, attackers are becoming increasingly more organized and skilled at carrying out more effective attacks

“Cybercriminal groups have succeeded in their digital transformation and their organization into a platform has made it possible to majorly make their attacks more efficient and faster” Gerôme Billois, Partner Cybersecurity

Beyond the simple blocking of the IS, the combination with data theft is becoming more and more present. Indeed, 30%of the ransomware attacks observed  include combine the blocking of the IS and the theft of data,  the latter being an additional lever to obtain financial gains.

Faster and more targeted ransomware attacks

We see a reduction in the average time between initial access and deployment of ransomware in the system with a minimum of 3 days for the fastest attack and an average of 25 days on managed cases. Attackers are becoming more and more determined to harm their victims.  Indeed, they now go so far as to target and destroy the backup mechanisms  in order to force the payment of the ransom  (21% of  cases).

We also find that in 90% of cases data has been irretrievably lost. It should be noted that  we are seeing a significant decrease in ransom payments this year (from 20% the previous year to 5% of cases). Multiple factors can  explain  this decrease, between the better understanding of the low interest to be paid  (the payment of the ransom does not accelerate the time of resolution of the crisis), the actions of awareness  and pressure on the payment intermediaries by the different authorities.

Other types of attacks are still raging in the background

How not to be an easy target? Some tips from CERT-W

“Even if diplomatic and judicial actions have weakened the cybercriminal ecosystem, it is not a question of stopping efforts, we must prepare now thanks to simple actions to put in place” Nicolas Gauchard, Head of CERT-W

Cet article Cyberattacks in 2021: ransomwares, still threat n°1 est apparu en premier sur RiskInsight.

Cybercrime watch

Google Chrome’s update fight against Cybercrime

Google Chrome version 80 now supports AES-256 to user data stored locally. The change has made an impact on AZORult’s ability to steal user’s information. AZORult is a user profile malware that appeared in 2016 thieving big amounts of information including passwords, web browsing history, cookies, etc.

Bouygues Construction another’s ransomware victim

Bouygues Construction was victim of a ransomware attack. First detected on January 30, the company announced the attack in Twitter only few days before the MAZE‘s group expressed to be behind the attack.

Internet Complain Center reporting (FBI IC3 report)

The Federal Bureau of Investigation (FBI) released the Internet Complaint Center (IC3) reporting an increment up to 1300 complaints every single day. The report shows how the Business email compromise (BEC) cost organizations $1.7 billion in 2019. Since companies have implemented “volume spam” campaigns, attackers are becoming more sophisticated targeting high-value individuals such as CEOs and finance employees.

Vulnerability watch

CVE-2020-0688 – Remote code execution vulnerability in Microsoft Exchange software

A remote code execution vulnerability exists in Microsoft Exchange software when the software fails to properly handle objects in memory, aka ‘Microsoft Exchange Memory Corruption Vulnerability’.

CVE-2019-15126 – All-zero encryption key to encrypt part of the user’s communication

An issue was discovered on Broadcom Wi-Fi client devices. Specifically, timed and handcrafted traffic can cause internal errors (related to state transitions) in a WLAN device that lead to improper layer 2 Wi-Fi encryption with a consequent possibility of information disclosure over the air for a discrete set of traffic.

CVE-2020-0022 – Critical Bluetooth vulnerability in Android

Android Bluetooth stack that lets attackers silently deliver malware to and steal data from nearby phones simply knowing the Bluetooth MAC address of the target. As result, possibility to Deny of Service (DoS), if the device is running Android 8.0, 8.1 or 9.0 then Remote Code Execution (RCE)

Weekly top

Top leak: Decathlon leaks 123 Million records

A database misconfiguration let a vpnMentor team to reveal 123 million records including customer and employee information. Over 9GB database was found from an unsecured Elasticsearch server, exposing information from Decathlon – Spain.

Top exploit: CVE-2020-6418 – Confusion flaw in V8, Google Chrome

Confusion flaw in V8 (JavaScript engine used by Google Chrome) letting to arbitrary code execution within the browser sandbox.

Top attack: Cyber-attack cripples’ wool sales across Australia

A ransomware attack affected more than 75 per cent of the wool industry across Australia. Secretary of National Auction Selling Committee (NASC) confirmed the compromising of Talman. Talman is the major software supplier to the industry.

Cet article Review of the current news by CERT-W – February 2020 est apparu en premier sur RiskInsight.