Executive summary 

A group of Russian state-supported cyber actors has been targeting and compromising various Western government and commercial organizations using the Zimbra Collaboration Suite (ZCS) software since at least July 2025. The Russian state-supported advanced persistent threat (APT) group’s activity is tracked in the cybersecurity community under several names (see Cybersecurity industry tracking), primarily as “LAUNDRY BEAR,” a name initially coined by the Netherlands General Intelligence and Security Service (AIVD) and Defence Intelligence and Security Service (MIVD) [1].

LAUNDRY BEAR’s targeting is almost certainly to gather sensitive information for the Russian Federation, with these actors primarily focusing on the covert acquisition of email data. Previous campaigns indicated LAUNDRY BEAR relied on unsophisticated initial access techniques—including password spraying, phishing, and pass-the-cookie—allowing the group to successfully run high-volume operations. The latest campaign targeting ZCS uses a novel exploit that was a zero-day vulnerability when first exploited and continues to be successfully exploited. The vulnerability, Common Vulnerabilities and Exposures (CVE) CVE-2025-66376, was patched in November 2025. This demonstrates LAUNDRY BEAR’s intent and ability to deploy increasingly sophisticated technical capabilities.

Unlike traditional phishing campaigns that persuade a user into taking an action, such as clicking a link or opening a file, LAUNDRY BEAR’s latest campaign leverages a view-based exploit that only requires a user to view a malicious email within a vulnerable version of the webmail service. Once viewed, the exploit attempts to exfiltrate the victim’s last 90 days of email communications, the organization email directory (i.e., Global Address List [GAL]), and other sensitive information to servers controlled by LAUNDRY BEAR. The exploit also attempts to establish persistent access to victim accounts through a variety of means as detailed in the Persistence and credential access section.

This Cybersecurity Advisory (CSA) warns of this ongoing malicious threat activity and urges organizations to update their vulnerable software and implement additional mitigations to thwart these Russian state-supported actors’ continued success. The CSA is being released by the following authoring and co-sealing agencies:

• United States National Security Agency (NSA)
• United States Federal Bureau of Investigation (FBI)
• Netherlands Defence Intelligence and Security Service (MIVD)
• Netherlands General Intelligence and Security Service (AIVD)
• United States Cybersecurity and Infrastructure Security Agency (CISA)
• United States Defense Counterintelligence and Security Agency (DCSA)
• United States Department of Defense Cyber Crime Center (DC3)
• United States Department of the Treasury
• United States Naval Criminal Investigative Service (NCIS)
• Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC)
• Communications Security Establishment Canada’s (CSE’s) Canadian Centre for Cyber Security (Cyber Centre)
• New Zealand National Cyber Security Centre (NCSC-NZ)
• United Kingdom National Cyber Security Centre (NCSC-UK)
• Czech Republic National Cyber and Information Security Agency (NÚKIB)¹
• Danish Defence Intelligence Service (DDIS)²
• Estonian Foreign Intelligence Service (EFIS)³
• Finnish Defence Intelligence (FDI)⁴
• Finnish Security and Intelligence Service (SUPO)⁵
• French General Directorate for Internal Security (DGSI)⁶
• French National Cybersecurity Agency (ANSSI)⁷
• Italian External Intelligence and Security Agency (AISE)⁸
• Italian Internal Intelligence and Security Agency (AISI)⁹
• Security and Intelligence Service of the Republic of Moldova (SIS RM)¹⁰
• Polish Foreign Intelligence Agency (AW)¹¹
• The Military Counterintelligence Service of Poland (SKW)¹²
• Spain National Intelligence Centre (CNI)¹³
• Sweden National Cyber Security Centre (NCSC-SE)¹⁴

The authoring agencies urge any organizations using ZCS to implement the recommendations listed within the Mitigations section of this advisory to reduce the risk associated with this activity. This CSA also includes specific remediations for organizations to implement if they discover the presence of the listed Indicators of compromise (IOCs).  

As more organizations update their ZCS software based on this CSA, LAUNDRY BEAR may discontinue the current campaign exploiting this vulnerability; however, based on the success of this and previous campaigns, it is very likely that the group will continue to target ZCS and other email systems used by organizations in Western countries. The actors will almost certainly continue to rely on email to engage potential victims by exploiting novel vulnerabilities and, when necessary, use social engineering techniques to assist with their efforts. The authoring agencies recommend organizations regularly update their mail service software and continuously monitor their email systems and emails for malicious activity.

For a downloadable list of IOCs, see:

• AA26-204A.stix.xml (STIX XML)
• AA26-204A.stix.json (STIX JSON)

Cybersecurity industry tracking

The cybersecurity industry provides overlapping cyber threat intelligence, indicators of compromise (IOCs), and mitigation recommendations related to these Russian state-supported cyber actors. While not exhaustive, the following are threat group names commonly used for these actors within the cybersecurity community:

• LAUNDRY BEAR
• Void Blizzard [2]
• CL-STA-1114 [3]
• TA488 (formerly UNK_PitStop) [4]

Note: Cybersecurity companies have different methods of tracking and attributing cyber actors, and this may not be a 1:1 correlation to the U.S. government’s understanding for all activity related to these groupings.

Background

Public advisories from Netherlands General Intelligence and Security Service (AIVD), Netherlands Defence Intelligence and Security Service (MIVD), and Microsoft highlighted these Russian state-supported advanced persistent threat (APT) actors in May 2025, calling them LAUNDRY BEAR and Void Blizzard respectively [1] [2]. Both advisories assessed that the group was engaged in malicious cyber activity as early as April 2024.  

The May 2025 advisories highlighted a cluster of activity targeting cloud-based email environments, including Microsoft Exchange in particular, and abusing legitimate APIs to perform data exfiltration in bulk [T1114.002]. The group relied on unsophisticated means of initial access, including procuring stolen credentials on criminal marketplaces [T1078], and using social engineering techniques to lure targets into interacting with a malicious site masquerading as a legitimate one. As of April 2025, one of these sites resembled a European Defence & Security Summit registration portal that required registrants to sign in to their Microsoft account to view. Once a user entered their Microsoft credentials into this malicious site, LAUNDRY BEAR’s modified version of the open source adversary emulation toolkit, Evilginx, intercepted the user’s credentials. LAUNDRY BEAR then used this authentication data, including passwords and session tokens, to access the compromised account and conduct mass email exfiltration, as well as harvest other information. This method of compromise is commonly known as an adversary-in-the-middle (AiTM) technique [T1557].  

Beginning around July 2025, LAUNDRY BEAR shifted toward a more technical method of email compromise, highlighting their continued efforts to covertly acquire email communications from a variety of Western organizations of interest and deliver them to the Russian Federation. Using a custom-developed capability [T1587.001] named “Улей” or “Ulej” (Russian for beehive), LAUNDRY BEAR successfully targeted and exfiltrated sensitive user information from organizations who use the Zimbra Collaboration Suite (ZCS) product [T1114]. Data LAUNDRY BEAR attempted to exfiltrate from compromised accounts included:

• Last 90 days of emails,
• Email address,
• Password [T1589.001],
• Global Address List (GAL) [T1087],
• Two-factor authentication (2FA) tokens, and
• Newly-created Application Passcode [T1098].

The covert and persistent nature of this activity, along with the absence of any known financial extortion, almost certainly indicates this group’s involvement in espionage activities with Russian government backing. Additionally, extensive Ukrainian targeting, prior to use against U.S. and other NATO allies, outlines an increasing trend within Russian cyber threat groups to target Ukrainian users first—both as a priority target and as a testbench for malicious cyber techniques before broader global deployment.

Targeting details

LAUNDRY BEAR has targeted and compromised users in various organizations, including those associated with:

• the Defense Industrial Base (DIB),  
• the federal and local government,
• education,
• energy,
• law enforcement,  
• media,  
• non-governmental organizations, and
• technology.

Technical details

Note: This advisory uses the MITRE ATT&CK® Matrix for Enterprise framework, version 19. This advisory also uses MITRE D3FEND^TM version 1.4.0¹⁵. See Appendix A and Appendix B for tables of the activity mapped to MITRE ATT&CK and D3FEND tactics, techniques, and countermeasures.

Ulej is a novel data exfiltration and aggregation capability, that currently (as of the publication of this report) supports a campaign specifically targeting users of ZCS webmail servers. This capability is used to exploit CVE-2025-66376 [Common Weakness Enumeration (CWE) CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')], but likely could be adapted to exploit other vulnerabilities. It exfiltrates emails and other sensitive user data from a victim’s system immediately after exploitation and stores the data in an actor-controlled unattributable virtual private server (VPS) [T1074.002] running LAUNDRY BEAR’s “Flowerbed” collection framework. The collected data is almost certainly further exfiltrated to internal network resources for review and long-term retention.

Reconnaissance

LAUNDRY BEAR uses the Ulej capability to exploit the CVE-2025-66376 vulnerability in organizations using ZCS. This campaign’s targeted victimology and limited exploitation capabilities likely indicate this group manually identifies and targets the victim organizations. LAUNDRY BEAR likely identifies organizations with public-facing Zimbra infrastructure by port scanning [T1595] and fingerprinting datasets easily procured through various commercial vendors [T1596.005].  

After identifying a target organization, the group likely compiles email addresses for individual users to target with the exploit [T1589.002] from datasets offered by commercial vendors [T1597.002], open source intelligence [T1593], or previously exfiltrated data [T1597].  

Resource development

The actors procure VPSs from a variety of providers [T1583.003], including those with Know Your Customer (KYC) requirements, and often use fabricated identities. LAUNDRY BEAR primarily uses Mullvad VPN [T1583] when interacting with these servers, further demonstrating the group’s intent to mask their identity and maintain operations security (OPSEC). After the server is provisioned, an automated process deploys the Docker containers necessary for Ulej’s Flowerbed framework [T1608], which then receives and aggregates the data Ulej exfiltrates. These servers are typically only used for 7-60 days before moving to new infrastructure.

Flowerbed framework

Flowerbed is a Python project that uses Docker for containerization. The project includes four different Docker containers:

• Catcher,
• Certbot,
• Nginx, and
• Gardener.

Catcher acts as both a DNS and HTTP server to receive and aggregate exfiltrated victim information [T1048]. For additional information on Catcher, refer to the Exfiltration section of this advisory. Flowerbed’s next container, Certbot, is based on one of the official Certbot containers, which allows for automated generation of Let’s Encrypt certificates using DNS challenges through Cloudflare. This certificate can then be used by the Nginx container, which serves as an HTTPS reverse proxy for Catcher, enabling Flowerbed to disguise some of its exfiltration activity through an encrypted communications channel [T1048.002]. The Nginx reverse proxy also validates that the Server Name Indicator (SNI) value contains “*.i.*” prior to forwarding the traffic to Catcher. If the SNI does not contain that string, the Nginx server returns a 444 error to the client. This is likely an attempt to reject non-Ulej connections. Finally, the Gardener container functions as a health check for the Catcher service. Gardener is a simple Python script that validates Catcher correctly receives and processes data.

The simplistic Flowerbed codebase has indications that artificial intelligence (AI) played a role in its development. This highlights how AI is increasingly being used to develop malicious capabilities [T1588.007]. The dependence on AI for a simple capability, such as Flowerbed, alongside a previous reliance on open source capabilities, such as Evilginx2 [T1588.002], likely indicates a lack of advanced technical knowledge within LAUNDRY BEAR, especially in relation to true software development capabilities.

Initial access

To gain initial access, LAUNDRY BEAR sends an email containing a malicious JavaScript payload to the target [T1566]. Through exploitation of CVE-2025-66376, this JavaScript payload is immediately executed once the user views the malicious email [T1203], such as the one shown in Figure 1, in the ZCS webmail platform. Since at least November 2025, LAUNDRY BEAR began sending these phishing emails from victim infrastructure through compromised accounts [T1199], as shown in the email metadata in Figure 2. These compromised accounts were likely previous victims of this, or another LAUNDRY BEAR, campaign and their use is intended to further obfuscate and frustrate anti-phishing tools and training.

According to the National Vulnerability Database (NVD), CVE-2025-66376 was initially published on 5 January 2026. This vulnerability allows for execution of a JavaScript payload included in email content due to improper sanitization of Cascading Style Sheet’s (CSS) @import directives within an email [5]. Because the activity attributed to this campaign began in July 2025—months before Synacor released a patch and the CVE was published—the payload initially exploited a zero-day vulnerability at that time [T1587.004].  

Utilization of a zero-day exploit within this campaign demonstrates the ability for even emerging threat groups like LAUNDRY BEAR to operationalize novel exploits into a highly successful capability.

Hidden in LAUNDRY BEAR’s email is a Base64 encoded payload within the “onload” field of a Scalable Vector Graphics (SVG) element [T1027.017], as shown in Figure 3. Leading up to the inclusion of this payload in the SVG element are various instances of @import directives, as required to leverage CVE-2025-66376. This payload includes an XOR encrypted final script encoded in a Base64 inner payload (see Figure 3) [T1027.013]. The outer payload decodes and decrypts the inner payload using an XOR function and a hardcoded key and then executes the script contained within the inner payload containing the collection and exfiltration logic. By changing the key used for the XOR encryption of the inner payload or adding additional @import directives with non-functional code [T1027.010], LAUNDRY BEAR can easily generate new payloads that bypass basic threat detection signatures. This malicious payload attempts to collect and exfiltrate information in 12 asynchronous stages [T1119]. The stages in order of appearance within the payload are as follows:

1. sendStartPing,
2. gather_email,
3. gather_environment,
4. gather_2fa_codes,
5. gather_app_password,
6. gather_device_status,
7. gather_oauth_consumers,
8. gather_autocomplete_password,
9. enable_mail_protocols,
10. gather_gal,
11. sendArchives, and
12. sendFinishPing. 

Use of a zero-day exploit within this campaign demonstrates the ability for even emerging threat groups like LAUNDRY BEAR to operationalize novel exploits into a highly successful capability [T1587].

Persistence and credential access

To establish sustained persistence into the victim’s email account, the script attempts to modify account preferences and collect authentication information. Any collected credentials are later exfiltrated, as further described in the Exfiltration section below. Other campaigns attributed to LAUNDRY BEAR also demonstrated the group’s ability to circumvent multi-factor authentication through session token replay [T1550.004], and the Zimbra campaign follows a similar trend.

The script used in this campaign tries to discover the victim’s email address during the gather_email stage [T1087]. The script searches for this email address in two ways. First, it examines the batchInfoResponse variable, which an HTML script element on the webpage can define, for an email address. Even if the script finds an email address there, it also checks whether it acquired a Cross-Site Request Forgery (CSRF) token as described later in the Collection section of this advisory. If so, the script uses the “GetIdentitiesRequest” Simple Object Access Protocol (SOAP) command under the “ZimbraAccount” namespace to determine the victim’s email address [T1185] and then exfiltrates it. However, if the script does not have a CSRF token or the SOAP request fails, the script exfiltrates the email value recovered from the first method instead. If both attempts fail to capture the victim’s email, the script sends a JavaScript Object Notation (JSON) payload with a key of “email” and value of null over HTTPS and does not attempt DNS exfiltration.

During the gather_autocomplete_password stage, the script attempts to collect the victim’s saved password via the autocomplete feature of the victim’s password manager. The script injects two HTML div elements requesting login credentials onto the page outside of the victim’s view, as shown in Figure 4 and Figure 5. After waiting five seconds, the script then attempts to extract the password provided automatically by the password manager from the input element shown in Figure 4. If there is no value in that input field, it checks the password input field shown in Figure 5. If neither input field contains a value, a JSON payload with a key of “autocomplete_password” and value of null is sent over HTTPS and DNS exfiltration is not attempted.

LAUNDRY BEAR almost certainly relies on a mail client using the Internet Message Access Protocol (IMAP) for persistent access to the victim’s mailbox. During the enable_mail_protocols stage, a SOAP request leveraging the “ModifyPrefsRequest” command under the “ZimbraAccount” namespace is sent. This request attempts to set the “zimbraPrefImapEnabled” preference to TRUE. While the default setting for “zimbraPrefImapEnabled” is not well documented, this action is almost certainly intended to ensure that IMAP access to the victim’s mailbox is enabled.

ZCS does not support 2FA for some mail clients, including IMAP. To support users who rely on IMAP clients, ZCS allows for the generation of Application Passcodes. Application Passcodes are randomly generated passwords that can be used for clients that cannot support the normal 2FA process to authenticate. During the gather_app_password stage, the script makes a SOAP request using the “CreateAppSpecificPasswordRequest” command under the “ZimbraAccount” namespace to create a new Application Passcode [T1556.006]. The SOAP request uses “ZimbraWeb” as the name of the application.

Additionally, the script also attempts to collect 2FA tokens. During the gather_2fa_codes stage, the script makes a SOAP request using the “GetScratchCodesRequest” command under the “ZimbraAccount” namespace. The script then attempts to exfiltrate any non-null 2FA codes collected this way. The number of codes can vary, and each code is exfiltrated to Flowerbed individually.

Collection

As demonstrated in the Persistence and credential access section, this script relies heavily on SOAP requests to collect victim information. To make these requests, the script aims to acquire the victim’s current CSRF token, which it attempts to access within the webpage’s local storage using localStorage.getItem("csrfToken"). If the script is unable to acquire this CSRF token, it will be unable to make any SOAP requests. In addition to the SOAP commands documented in the Persistence and credential access section, other SOAP commands executed to collect victim information are shown in Table 1.

The script attempts to collect the victim’s GAL through brute force by searching for each two-character combination from a character set of “abcdefghijklmnopqrstuvwxyz1234567890.-_”. These queries are conducted using 20 batches of SOAP requests with 77 “SearchGalRequest” SOAP commands in each batch except for the last request containing only 58.

During the gather_environment stage, the script attempts to determine which type of ZCS webmail client the victim is using. The script checks the user’s current URL to determine the client type being used, checking for certain indicators (shown in Table 2) to determine the client type. The corresponding value is then used as the payload when exfiltrating the client type.

As part of collection, the script attempts to harvest any emails not marked as “junk” from the last 90 days from the victim’s account. Emails are collected daily by an HTTP GET request to the URL path, “/home/~/?fmt=tgz&meta=0&query=date:-{DAY_OFFSET}d AND (not in:junk)”. The {DAY_OFFSET} value would be between 0 and 89 representing how many days ago the email was sent or received. To prevent redundant collection and exfiltration of emails, a variable with a name based on the email date being queried, using a format of zd_comp_YYYY-MM-DD, and value of true, is saved to the window.top.localStorage property. This variable is saved regardless of whether the email is successfully exfiltrated.  

According to Mozilla documentation, if the user is not in a private browsing session, any data stored to localStorage does not typically expire. This means that if the user happens to execute the script again from the same computer, the script avoids attempting to re-exfiltrate previously captured emails. However, the script always attempts to pull any emails with a {DAY_OFFSET} of zero. In other words, the script always pulls emails sent or received the same day it is run. After email results are returned from the query for each day of email activity, those results are then passed to Flowerbed as described in the Exfiltration section.

The script also provides LAUNDRY BEAR with telemetry on any errors that occur during the collection process. This is accomplished by executing any collection or exfiltration code through helper functions that contain error handling logic. If an error occurs, a payload containing information on the error itself, the context of the error happening, and the stage in which the error occurred is sent to Flowerbed as described in the Exfiltration section below. For cases where the error occurs within a SOAP request, “:api” is concatenated to the stage value in the payload. If an error occurs during the batch SOAP requests that occur when collecting the GAL of the victim, the stage value will use a format of gather_gal:{VAL}:api. The {VAL} placeholder indicates which batch request, a number from 0 to 19, the error occurred in. Errors that occur during the password autocomplete interception process will use “gather_autocomplete_password:dom” for the stage value. Finally, if an error occurs when attempting to collect or exfiltrate a specific day’s emails, the stage will include which day the error occurred on, using the previously defined placeholder {DAY_OFFSET}, with a format of sendArchive:day-{DAY_OFFSET}.

Exfiltration

At the end of each stage in the collection process, the script attempts to exfiltrate acquired information to Flowerbed. The script primarily relies on two forms of data exfiltration: DNS [T1048.003] and HTTPS. Some information is exfiltrated over both the DNS and HTTPS channels.

Prior to exfiltration, a randomized 10- or 11-character alphanumeric string is generated as an identifier for the victim. This identifier is included in the URL of both the DNS- and HTTPS-based exfiltration.  

DNS exfiltration

DNS exfiltration occurs through DNS A record queries. To ensure data exfiltrated through DNS is not corrupted when traversing through non-actor-controlled DNS infrastructure, Ulej maintains compliance with RFC 1035, Domain Names - Implementation and Specification, specifically accounting for the case insensitivity and subdomain length requirements. Base32 encoding is used to create a case-insensitive payload. Once the payload is encoded, a period (“.”) is added every 60 characters to ensure each subdomain is under 63 characters long. The script then creates a new image object sourced from a URL with the scheme defined in Figure 6. Any traffic involving DNS exfiltration will have “d-“ prefixing the victim identifier, and the subdomain immediately following indicates the type of information being exfiltrated.

When the script generates an image object, the browser tries to retrieve the complete domain of the URL specified as the source of the image. This triggers a DNS request sent to the actor-controlled server and processed by Flowerbed. Table 3 lists both the information exfiltrated via DNS and their corresponding data type identifiers in the DNS queries.  

HTTPS exfiltration

Any information exfiltrated via DNS is also exfiltrated through HTTPS, as well as additional data including email content, contacts, attachments, and error logging information. By using Let’s Encrypt certificates, this group can quickly deploy new infrastructure and leverage encrypted HTTPS communications with valid server certificates when exfiltrating information from the victim’s environment. The HTTPS exfiltration capability only uses two HTTP content types, defined in Table 4. Traffic associated with HTTPS exfiltration will use the URL scheme shown in Figure 7.  

Some of the data transmitted via HTTPS uses the standard JSON content type format. The script includes the information in a POST request to actor-controlled infrastructure.  

Table 5 provides a summary of the JSON-based exfiltration.

The script transmits all HTTPS exfiltration not identified in Table 5 using the Octet-Stream content type as binary data. The POST requests for this method include a filename in the “X-Filename” header. Traditionally, developers use headers prefixed with “X-” to denote custom headers that do not follow a defined standard. The purpose of including this header remains unclear since the Catcher capability ignores the provided filename when saving the data. Table 6 summarizes the data exfiltrated in this format.

The script sends all exfiltrated data identified in Table 6 to the Catcher service exactly as received from the SOAP request in a JSON payload, except for email exfiltration. For email exfiltration, the script sends it as a GZIP compressed archive [T1560]. Although most of the exfiltration consists of valid JSON, the script still attempts to exfiltrate all information identified in Table 6 using the application/octet-stream content typing rather than application/json.

At the beginning and end of the collection and exfiltration activity, during the sendStartPing and sendFinishPing stages respectively, the script submits a POST request with a JSON payload to indicate that the script is starting or finishing execution. Throughout execution, the script also logs error events and send the logs using similar JSON payloads. The script sends the JSON in a POST request to the URL documented in Figure 2, using a URL path of “/v/p” and with a “subtype” key that shows which type of action it logged (start, finish, or error).  

Catcher

Ulej exfiltrates information to Flowerbed to be handled by a service named Catcher. Catcher is a containerized Python application, running in Docker as part of Flowerbed, which is detailed in the Resource development section. It receives exfiltrated data and temporarily stores it, enabling its eventual transfer to infrastructure designed for long-term, secure storage.

Catcher acts as an HTTP server over port 8000 and a DNS server on port 53. As described in the Resource development section, the Flowerbed project uses an additional Docker container running an Nginx reverse proxy to enable HTTPS support. This reverse proxy uses a certificate generated by Let’s Encrypt and forwards all traffic with an SNI containing “*.i.*” to port 8000 within the Catcher container.

The DNS service can accept A, AAAA, MX, TXT, and CAA queries. For any MX, AAAA, or CAA queries, the server will always provide an empty response. The system only supports TXT records as needed to process Automatic Certificate Management Environment (ACME) requests, which enable the assignment of Let’s Encrypt certificates. If the server receives an A query, Catcher will always respond with the public IP address of the Flowerbed server.  

However, if a query includes a domain formatted as shown in Figure 6 and Figure 7, the service saves a log file in JSON format to disk containing the following details of the DNS query:

• Time of query,
• Source IP address for query,
• Queried domain, and
• Type of query.

The HTTP server typically responds with OK, except in cases where the path is “pixel.gif” when the response contains a 1x1 gif image with a SHA-256 hash of ef1955ae757c8b966c83248350331bd3a30f658ced11f387f8ebf05ab3368629. Like the DNS service, the HTTP service will only log entries when the domain found in the host header of the request follows the expected formatting as seen in Figure 6 and Figure 7. As the HTTPS exfiltration uses non-standardized binary and JSON-formatted payloads when exfiltrating to Catcher, Catcher will check the content type of the request. If the content type is set to “application/json”, Catcher encodes the data in Base64 and includes it in the JSON log entry written to disk. If the content type is set to any other value, Catcher leaves the Base64 payload in the JSON log entry blank and saves the payload to a separate file with the same filename as the JSON log entry with a “.bin” file extension. An HTTPS exfiltration event causes Catcher to save a JSON formatted log file to disk containing the following information from the HTTP request:

• Time,
• Source IP address,
• Request method,
• Host,
• Path,
• Query string,
• Headers, and
• Base64 payload.

These JSON event log files and binary output files are then initially saved to the directory /root/hits/tmp and later moved to the /root/hits/ready directory once processed. This prevents incomplete files, which are still being uploaded to Catcher, from premature exfiltration from the server. Approximately every 60 seconds, a likely automated workflow establishes a Secure Shell (SSH) connection with the server hosting Flowerbed for a few seconds, almost certainly exfiltrating the data processed by Catcher to non-public-facing infrastructure. The command in Figure 8 also executes hourly to remove all files last modified at least two days ago from the /root/hits/ready directory.

Response strategies

Mitigations

In many cases, by the time an organization identifies a compromise related to this campaign, numerous sensitive and proprietary emails have already been exfiltrated. The significant risk posed by this cyber threat emphasizes the importance for organizations that use ZCS and other similar webmail solutions to take proactive steps to mitigate this risk.

All organizations that use the ZCS webmail service should immediately prioritize ensuring that their ZCS is not running a vulnerable version. A patch for CVE-2025-66376 was released for both 10.1.13 and 10.0.18 versions of ZCS [D3-AH]. If immediate patching is not feasible, organizations should advise employees to use alternative mail clients to access email and avoid using the Classic ZCS webmail client until ZCS is updated to a non-vulnerable version [d3f:Isolate].

System administrators should closely monitor any Internet-connected ZCS or other email systems and the workstations that access those systems and promptly apply available software updates [D3-AH]. Administrators can maintain awareness of active vulnerability exploitation by referencing open source resources, including CISA’s Known Exploited Vulnerabilities Catalog and NCSC-UK’s Responding to active exploitation of vulnerabilities guidance.

Organizations should consider using a third-party authentication service that supports passkeys for authentication to mediate access to ZCS and other services that do not natively support passkeys. By doing so, organizations can work to eliminate the possibility of automated password collection from autocomplete or password reuse [D3-CH]. However, Application Passcodes may still be necessary and should be monitored closely.  

Organizations should implement network monitoring capabilities with collection and short-term retention of packet capture or NetFlow data and maintain log collection and storage [CPG 3.Q]. This will allow organizations to monitor for and identify suspicious network activity [CPG 4.B], such as:

• Significant amounts of outbound data being sent to IPs associated with VPS providers not used by the organization [D3-NTA];
• Frequent DNS queries for a suspicious domain with seemingly random subdomains [D3-DNSTA];
• A sudden spike of connections to a server associated with a recently established domain [D3-NTCD]; and  
• Connections to internal services, such as webmail, from VPN providers frequently leveraged by this group for nefarious activity, such as Mullvad VPN [D3-NTCD].

Additionally, for organizations that can inspect the content of outbound HTTPS connections via break-and-inspect infrastructure, security teams should identify traffic matching the characteristics described in the Exfiltration section of this advisory.

Indicators of compromise (IOCs)

Flowerbed infrastructure

The following indicators have been attributed to use by LAUNDRY BEAR for their campaign targeting ZCS’s webmail service as of the publication of this advisory. (Disclaimer: Due to the frequency of operational structure changes by this group, these indicators are intended solely for historic attribution purposes. Some indicators, such as IPs, compromised emails, and domains, may be outdated, so organizations should check for current activity before acting on these IOCs.) Table 7 provides details about the server infrastructure used to host Flowerbed, and Table 8 lists the corresponding SHA-1 hash values for the Let’s Encrypt certificates used by that infrastructure [D3-IAA].

LAUNDRY BEAR has used the following email addresses to procure resources used for this campaign:

• ivanka.zurabishvili@proton[.]me,
• zmul1@buildandconsulting[.]com,
• garrysmithme@pinmx[.]net, and
• hostingclient@pinmx[.]net.

Phishing distribution

LAUNDRY BEAR primarily relied on ProtonMail for distribution of malicious email. However, as stated above, LAUNDRY BEAR’s more recent efforts likely have shifted to distributing the payload through previous victims.  

The following email addresses have distributed payloads attributed to this campaign:

• c.laurent.ejfa@proton[.]me,
• j.moreau.epsc@proton[.]me,
• liberty.insights@proton[.]me,
• certain email addresses (presumably compromised) at the isofts.kiev[.]ua domain (i.e., ending with @isofts.kiev[.]ua), and
• certain email addresses (presumably compromised) at the navs.edu[.]ua domain (i.e., ending with @navs.edu[.]ua).

Additionally, the following are SHA-256 hashes of email samples containing the malicious payload attributed to this campaign:

• 98df604ecc57f884a2e6ce3266a0013ad64455cac48442c2312cfa4765007aaf,
• 60db9abae75cd8ccc49dd7ea5feb41677566dcd442f12ebc5745ffd2810fb874,
• b1f5beb1175fc5c7d1806a2f0d900eb124c54f0286c5c52b66eea7a6633adb1d, and
• 1517b3caa495f6c4e832df9c75fc94667e3c233773f7fa4e056d5e30e5ead760.

Post-compromise artifacts

Currently, the script does not remove artifacts. This leaves additional opportunities to identify victims of this activity. While emphasis should always be placed on consistent monitoring of network traffic and endpoint activity, there are a variety of persistent artifacts described below that can be used to identify victims of this campaign.

This Ulej capability relies on creating a significant number of SOAP requests to collect account information for exfiltration. ZCS logs from these requests are stored, by default, in the /opt/zimbra/log/mailbox.log file [D3-PA]. A significant amount of SOAP request activity that aligns with what was described in the Persistence and credential access and Collection sections of this advisory could indicate a potential compromise. Specific examples of high-risk SOAP request activity might include:

• Many SearchGalRequest command requests from a single user over a short period of time;
• Use of the CreateAppSpecificPasswordRequest command, especially in cases where it is creating an Application Passcode named “ZimbraWeb”; and
• Use of the GetScratchCodesRequest command.

While LAUNDRY BEAR uses the localStorage property to track what days had emails previously exfiltrated, defenders can use this property to identify victims of this campaign and determine the scope of exfiltrated information [D3-PA]. Review of the items stored in that property for an organization’s ZCS webmail client page on an endpoint device could indicate compromise if there are items named with a format of zd_comp_YYYY-MM-DD, as explained in the Collection section of this advisory.

While Application Passcodes have non-malicious purposes, in this case instances of these passcodes with the name “ZimbraWeb” are almost certainly malicious. The ZCS webmail application can support 2FA natively and does not require the use of an Application Passcode, so there is no reason that there should be one named “ZimbraWeb.”

In instances where organizations identify victims of this campaign, they should also examine the inbox of the suspected victim for the original phishing email [D3-MA]. If an email that has a payload exploiting CVE-2025-66376 is discovered, steps should be taken immediately to identify and quarantine other instances of emails with similar body content, senders, and subject lines to prevent further exploitation and exfiltration.  

Remediation

In the event an organization identifies activity associated with this campaign, that organization should take steps to minimize further exploitation. The organization should consider requesting that employees minimize use of the ZCS webmail client until the organization updates to a patched version that is not vulnerable to CVE-2025-66376.

Organizations should use identifiers from the IOCs section of this report to identify any individuals compromised by this campaign and record the date(s) of compromise(s) to determine the scale and scope of emails exfiltrated.

All users from the organization should have all Application Passcodes and 2FA scratch keys revoked. Affected organizations should require all employees to change passwords in line with establishing minimum password strength requirements [CPG 3.B] and creating unique credentials [CPG 3.C], specifically noting that compromised employees might have had any password stored in a password manager exfiltrated.

Works cited

[1] Netherlands General Intelligence and Security Service (AIVD) and Netherlands Defence Intelligence and Security Service (MIVD). AIVD and MIVD identify a new Russian cyber threat actor. 2025. https://www.aivd.nl/site/binaries/site-content/collections/documents/2025/05/27/aivd-en-mivd-onderkennen-nieuwe-russische-cyberactor/Advisory+AIVD+en+MIVD+Public+report+on+new+cyber+actor.pdf

[2] Microsoft Corporation. New Russia-affiliated actor Void Blizzard targets critical sectors for espionage. 2025. https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/

[3] Palo Alto Networks Unit 42. Russian Global Webmail Espionage. 2026. https://unit42.paloaltonetworks.com/russian-webmail-espionage/ 

[4] Proofpoint. TA488 Targets Zimbra Mailservers with Half-Click Exploits. 2026. https://www.proofpoint.com/us/blog/threat-insight/ta488-zcs-exploit

[5] Seqrite. Operation GhostMail: Russian APT exploits Zimbra Webmail to Target Ukraine State Agency. 2026. https://www.seqrite.com/blog/operation-ghostmail-zimbra-xss-russian-apt-ukraine/  

Footnotes

¹ Národní úřad pro kybernetickou a informační bezpečnost
² Forsvarets Efterretningstjeneste
³ Välisluureamet
⁴ Sotilastiedustelu
⁵  Suojelupoliisi
⁶ Direction générale de la sécurité intérieure
⁷ Agence nationale de la sécurité des systèmes d’information
⁸ Agenzia Informazioni e Sicurezza Esterna
⁹ Agenzia Informazioni e Sicurezza Interna
¹⁰ Serviciul de Informații și Securitate al Republicii Moldova
¹¹ Agencja Wywiadu
¹² Służba Kontrwywiadu Wojskowego
¹³ Centro Nacional de Inteligencia
¹⁴ Nationellt Cybersäkerhetscenter
¹⁵ MITRE and ATT&CK are registered trademarks of The MITRE Corporation. MITRE D3FEND is a trademark of The MITRE Corporation.

Acknowledgements

The authoring agencies acknowledge the contributions to this advisory from Palo Alto Networks Unit 42 and Proofpoint.

Disclaimer of endorsement

The information and opinions contained in this document are provided "as is" and without any warranties or guarantees. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favoring by the United States Government, and this guidance shall not be used for advertising or product endorsement purposes.

Organizations have no obligation to respond or provide information back to the authoring organizations in response to this joint advisory. If, after reviewing the information provided, an organization decides to provide information to the authoring organizations, reporting must be consistent with all applicable laws and policies.

Purpose

This document was developed in furtherance of the authoring agencies’ cybersecurity missions, including their responsibilities to identify and disseminate threats, and to develop and issue cybersecurity specifications and mitigations. This information may be shared broadly to reach all appropriate stakeholders.

Contact

Appendix A: MITRE ATT&CK tactics and techniques

See Table 9 through Table 19 for all the threat actor tactics and techniques referenced in this advisory.

Appendix B: MITRE D3FEND countermeasures

See Table 20 for a mapping of several of the cybersecurity countermeasures mentioned in this advisory.

Wo du uns folgen kannst: Facebook, Reddit, Google News, X, Threads

Zwei große Änderungen hat es in den vergangenen Jahren bei Phishing-Angriffen gegeben: Die Kriminellen erstellen mithilfe von generativer KI sprachlich fast perfekte Mails, die in Stil, Struktur und Tonalität kaum noch von legitimen Nachrichten zu unterscheiden sind. Wo früher holpriges Deutsch sofort Misstrauen geweckt hat, liest sich heute eine Phishing-Mail wie eine echte Mitteilung von Microsoft, einer Bank oder einem Paketdienst.

Auch das Design wirkt meist höchst professionell. Zum anderen sind auch die technischen Tricks beim Datendiebstahl heute höher entwickelt. Einige Maschen umgehen sogar eine Zwei-Faktor-Authentifizierung. Das Ziel der Angreifer bleiben vor allem Zugangsdaten, Session-Tokens und persönliche Infos.

1. Microsoft-365-Log-in-Falle trickst Zwei-Faktor-Anmeldung aus

Eine neue Angriffsmethode verwendet den originalen Microsoft-Anmeldedialog und kommt entsprechend fast ohne gefälschte Webseiten aus. Die Kriminellen nutzen dafür den Oauth-Device-Code-Flow. Das ist ein Anmeldeverfahren für Geräte oder Programme, die keinen brauchbaren Browser oder keine komfortable Texteingabe bieten, etwa Smart-TVs, IoT-Geräte, Drucker oder CLI-Tools.

Offiziell heißt er „OAuth 2.0 Device Authorization Grant“. Mit der Methode lassen sich auch Konten übernehmen, die mit einer Zwei-Faktor-Authentifizierung geschützt sind.

Die Kriminellen schicken an ihre Opfer eine Phishing-Nachricht und geben vor, das Gerät der Opfer müsste für den Log-in ins Microsoft-365-Konto neu autorisiert werden. Die Nachrichten beginnen meist harmlos, etwa mit „Ihre Sitzung ist abgelaufen“, und bieten einen Link zur Neuanmeldung. Wenn das Opfer dem Link in der Nachricht folgt, landet es zunächst auf einer gefälschten Website, schließlich aber beim offiziellen Microsoft-Authentifizierungsverfahren für Geräte und Anwendungen (Oauth-Device-Code-Flow).

Proofpoint

Es handelt sich um echte Microsoft-Meldungen und Webseiten. Allerdings autorisiert das Opfer nicht den Zugang zu seinem eigenen PC oder Smartphone, sondern eine Anwendung der Kriminellen. Diese bekommen nach der Freigabe durch das getäuschte Opfer einen Access-Token. Damit kann die feindliche Anwendung per API auf das Microsoft-Konto zugreifen, ohne dass noch einmal ein Passwort eingegeben werden muss.

Übrigens: Die meisten dieser Angriffe verstecken den Link zur gefälschten Website in einem QR-Code. Dieser entgeht den Spam-Filtern eher als ein üblicher Link, und es lässt die meisten Opfer vom PC auf das Smartphone wechseln.

Auf diesem ist es wegen des kleineren Bildschirms und oft fehlender Sicherheits-Software noch wahrscheinlicher, dass das Opfer die Täuschung nicht bemerkt. Eine ausführliche Analyse der Angriffe auf Microsoft-365-Konten haben die Sicherheitsexperten von Proofpoint veröffentlicht.

2. Support-Masche: Ihr Computer ist gesperrt & Co.

Die Support-Masche ist zwar nicht neu, funktioniert aber nach wie vor: Noch immer fallen zahlreiche Menschen auf die perfide Betrugsstrategie herein. Zu den prominenten Opfern zählt Bundestagspräsidentin Julia Klöckner.

Mutmaßlich staatlich organisierte Angreifer kontaktierten sie über den Messenger-Dienst Signal und gaben sich als vermeintliche Signal-Support-Mitarbeiter aus. Unter einem Vorwand forderten sie Klöckner und weitere Politiker auf, ihre PIN einzugeben. Dadurch erlangten die Angreifer Zugriff auf die Signal-Konten der Betroffenen – und damit auf private Chats und Kontakte.

Das Bundesamt für Verfassungsschutz und das Bundesamt für Sicherheit in der Informationstechnik (BSI) haben gemeinsam einen Leitfaden veröffentlicht, der potenziellen Opfern hilft zu prüfen, ob ihr Signal-Konto übernommen wurde.

Bundesnetzagentur

Ebenfalls weiterhin verbreitet sind Angriffe durch angebliche Microsoft-Support-Mitarbeiter. Die Betrüger kontaktieren ihre Opfer per Telefon, E-Mail oder über gefälschte Pop-up-Warnungen im Browser.

Dabei behaupten sie, der Windows-PC habe ein Sicherheitsproblem – etwa sei der Computer gesperrt oder mit Schadsoftware infiziert. Anschließend versuchen sie, die Betroffenen zur Installation einer Fernwartungssoftware oder eines vermeintlichen Sicherheitstools zu bewegen. Tatsächlich erhalten die Angreifer dadurch oft vollständigen Zugriff auf den Rechner.

3. Gefälschter Microsoft Defender warnt

Der Microsoft Defender ist ein Windows-Bordmittel und schützt PCs gegen alle bekannten PC-Viren. Entsprechend alarmierend ist für viele Nutzer eine Warnung dieses Antiviren-Tools. Eine gefälschte Form dieser Warnung erscheint mal per E-Mail, mal als Pop-up im Browser. In diesen Nachrichten wird behauptet, der Schutz des Defenders müsse kostenpflichtig erneuert werden. In der Folge werden die Nutzer auf gefälschte Shop-Webseiten geleitet, die eine Zahlung für einen Virenschutz verlangen.

Grundsätzlich gilt: Der Microsoft Defender ist auf Privat-PCs ein Bordmittel und kostenlos in Windows enthalten. Eine Zahlung ist nicht nötig. Sollte die Warnung per Mail bei Ihnen landen, löschen Sie diese einfach. Schlägt sie als Pop-up im Browser auf, schließen Sie einfach das Browser-Fenster, notfalls mit der Tastenkombination „Alt+F4”.

Der Antivirenspezialist Norton hat eine Anleitung veröffentlicht, die erklärt, wie sich solche Pop-up-Warnungen im Browser beseitigen lassen, falls sie sich im System festgesetzt haben.

4. Microsoft-Onedrive: Cloud-Phishing über Freigaben

Cloud-Dienste wie Onedrive von Microsoft nutzen viele Windows-Nutzer mehrmals täglich. Genau deshalb sind sie ein attraktives Ziel für Phishing. Statt klassischer E-Mails mit Dateianhängen erhalten die Nutzer Freigabe-Benachrichtigungen mit einem Betreff wie „Dokument wurde mit Ihnen geteilt“. Der Inhalt wirkt meist harmlos und oft beruflich relevant: Rechnungen, Projektpläne, Gehaltslisten oder interne Dokumente.

Besonders tückisch ist die Kombination aus echten und gefälschten Elementen. Manche Angriffe nutzen tatsächlich legitime Cloud-Plattformen, bieten dort aber manipulierte Dokumente an. Das Ziel dieser Angriffe sind mehrheitlich die Log-in-Daten der Opfer zu Ihren Cloud- und Mail-Konten. Diese werden dann von den Angreifern übernommen und etwa für neue Phishing-Attacken genutzt.

5. Lieferdienste, Lieferdienste und noch mal Lieferdienste

Phishing im Namen von Paketdiensten gehört zu den stabilsten Angriffsmustern überhaupt und wird gleichzeitig immer ausgefeilter. Der Grund ist die hohe Alltagstauglichkeit: Fast jeder erwartet regelmäßig Lieferungen und ist deshalb kaum misstrauisch, wenn eine Mail, SMS oder Whatsapp zum Thema Paketversand eintrudelt. Moderne Varianten enthalten nicht nur einfache Textlinks, sondern vollständige Tracking-Systeme.

Arne Arnold

Diese Seiten sind dynamisch aufgebaut und simulieren echte Logistikprozesse. Beim Sendungsverlauf heißt es dann etwa: „Zustellung fehlgeschlagen – bitte Adresse bestätigen“ oder „Letzte Möglichkeit zur Terminänderung“. Besonders kritisch ist die Kombination aus Zeitdruck und Kontext. Wer Opfer eines solchen Angriffs wird, gibt meist seine Log-in-Daten für Shopping- oder Zahlungsdienste preis. Oder er überweist den Angreifern direkt Geld, da angeblich Steuern, Bearbeitungsgebühren oder ein Expresszuschlag fällig sind.

Arne Arnold

Übrigens: Ab dem 1. Juli 2026 gibt es zusätzliche Abgaben auf Sendungen aus Nicht-EU-Ländern. Für Waren unter 150 Euro sind dann pauschal 3 Euro Zollgebühr und eine Einfuhrumsatzsteuer fällig. Einige Kurierdienste verlangen zusätzlich eine Servicepauschale für diese Zollanmeldung. Über die genauen Kosten informiert eine Seite der Verbraucherzentrale NRW. Es lohnt sich, die tatsächlichen Kosten zu kennen, denn es ist wahrscheinlich, dass zu diesem Termin vermehrt Phishing-Mails zu diesem Thema versendet werden.

6. Phishing zu Online-Banking gibt es immer

Phishing zum Online-Banking gibt es fast schon so lange wie das Online-Banking selbst. Die Bedrohungslage ist aber so angespannt wie nie, denn die Angriffe sind nun wirklich zahlreich. Über die neuesten Phishing-Fallen informieren unter anderem die Verbraucherzentralen.

Beispiele aus dem Mai 2026 lauten etwa so: „Bestätigung Ihrer Mobilfunknummer erforderlich“. Absender ist vorgeblich die Easybank. Eine Fälschung von Commerzbank-Mails warnt vor einem fälligen „Photo-TAN Update“, bei dem ein „einmaliger Abgleich der Zugangsdaten“ nötig ist.

Andere Phishing-Mails geben vor, von der Deutschen Bank zu sein, und fordern eine Reaktivierung des „photoTAN-Sicherheitszertifikats“. Auch Kunden der DKB erhielten im Mai Phishing-Mails.

Verbraucherzentrale

Sollten Sie eine Mail von Ihrer Bank bekommen, klicken Sie auf keinen Fall auf einen der Links in dieser Mail. Wenn Sie sich unsicher sind, ob Sie reagieren sollen, rufen Sie die Website Ihrer Bank über Ihren Browser auf.

Sollte es tatsächlich ein Anliegen der Bank geben, wird es Ihnen nach dem Einloggen in Ihr Online-Konto angezeigt. Oder Sie rufen Ihre Bank einfach per Telefon an und fragen, ob Informationen von Ihnen benötigt werden.

7. Phishing per Post: Kreditbetrug per Postident-Verfahren

Diese Phishing-Angriffe erreichen Sie per Post in Ihrem echten Briefkasten. Die Briefe geben vor, von Ihrer Bank zu stammen, und fordern Sie auf, Ihre Daten erneut per Postident zu bestätigen. Postident ist ein Verfahren der Post, mit dem Sie Ihre Identität gegenüber anderen, etwa einer neuen Bank oder einem Kreditinstitut, bestätigen können. Wer das beigefügte Schreiben nutzt, legitimiert in der Regel einen hohen Kredit bei einer anderen Bank.

Schäden von 15.000 bis 25.000 Euro sind hier keine Seltenheit. Vorangegangen ist meist ein Diebstahl Ihrer genauen Daten (Postadresse, Hausbank, Arbeitgeber, Verdienst), den die Angreifer dann nutzen. An die Daten kommen die Kriminellen etwa über gefälschte Wohnungsinserate bei Immoscout24 oder ähnlichen Portalen. Wer sich auf eine Wohnung oder ein Haus mit Gehaltszetteln und weiteren Angaben bewirbt, hat bereits alle wichtigen Daten für den Postident-Betrug verraten. Seien Sie beim Postident-Verfahren stets besonders vorsichtig. Konkrete Tipps lesen Sie hier.

Sicherheitstipps: Phishing erkennen und blockieren

An diesen Merkmalen erkennen Sie betrügerische Nachrichten:

• Unverlangter Kontakt: Sie erhalten eine E-Mail, Whatsapp oder SMS über eine Gutschrift, eine Lastschrift oder andere finanzielle Ansprüche, obwohl Sie aktuell keine Buchung storniert oder reklamiert haben.
• Zeitdruck: Die Nachricht suggeriert dringenden Handlungsbedarf und fordert zur schnellen Reaktion auf.
• Verdächtige Links: Die Links in der Nachricht sind hinter einem QR-Code maskiert, führen zu unpassenden Domains oder sind ungewöhnlich lang.
• Aufforderung zur Dateneingabe: Seriöse Unternehmen fordern in Nachrichten oder Mails nur äußerst selten zur Eingabe sensibler Daten auf.
• Unpersönliche Anrede: Oft fehlt die namentliche Ansprache oder es werden generische Formulierungen verwendet.

Diese Maßnahmen schützen vor Phishing-Fallen:

• E-Mail, SMS und Whatsapp & Co. sind keine geschlossenen Nachrichtenkanäle: Sie müssen damit rechnen, auch betrügerische Nachrichten zu erhalten.
• Misstrauen Sie Links in Nachrichten: Klicken Sie keine Links an und scannen Sie keine QR-Codes, wenn Log-in-, Zahlungs- oder Sicherheitsaufforderungen in der Mail stehen. Öffnen Sie den jeweiligen Dienst im Browser über die manuelle Eingabe der Adresse.
• Nutzen Sie Browser und Passwortmanager als Frühwarnsystem: Wenn Ihr Passwortmanager Ihre Log-in-Daten auf einer Webseite nicht einfügen möchte, dann ist die Domain vermutlich gefälscht. Achten Sie zudem auf die Warnungen Ihres Browsers.
• MFA aktivieren: Nutzen Sie immer eine Zwei- oder Multifaktor-Authentifizierung, wenn diese angeboten wird. Vor allem Passkeys erhöhen die Sicherheit.
• Remote-Support misstrauen: Installieren Sie keine Fernwartungs-Tools, nachdem Sie unaufgefordert kontaktiert wurden.
• Freigaben hinterfragen: Wenn Sie Freigaben für Dateien in Cloud-Speichern erhalten, kontaktieren Sie zunächst den Absender, idealerweise telefonisch.

Infos zu aktuellen Angriffen: Informieren Sie sich über Phishing-Kampagnen etwa bei der Verbraucherzentrale NRW.

Als letzte Verteidigungslinie lassen sich Antivirenprogramme, Browserschutz und Spezial-Tools einsetzen:

• Antivirus: Große Sicherheits-Suiten wie G Data Internet Security filtern Phishing-Mails heraus, bevor sie diese Nachrichten öffnen.
• Browser-Schutz: Browser von Sicherheitsanbietern blockieren viele aktuelle Phishing-Seiten, etwa der KI-Browser Norton Neo.
• Spezial-Tools: KI-Chatbots wie Scamio von Bitdefender begutachten verdächtige Nachrichten und warnen vor gefährlichen Inhalten.

Arne Arnold

Zimbra Phishing Campaign Uses CVE-2025-66376

LAUNDRY BEAR Targets Email and Sensitive Data

Ulej and Flowerbed Support Email Data Exfiltration

Organizations Urged to Patch Vulnerable Zimbra Systems

Read more →

The post Windows 11 Security Cheat Sheet: BitLocker, Passkeys, and Defender Explained appeared first on IT Security News.

The post Windows 11 Security Cheat Sheet: BitLocker, Passkeys, and Defender Explained appeared first on TechRepublic.

Passwords and traditional MFA remain common targets for phishing and credential theft. FalconID extends phishing-resistant, FIDO2-based passkeys to third-party applications, enabling secure, passwordless authentication across platforms like Entra ID, Okta, GitHub, and Salesforce.

Passkeys are device-bound, centrally managed through the Falcon console, and continuously protected by Falcon security signals—allowing organizations to revoke access instantly when risk changes.

🛡️ Falcon ID
Learn more here: https://cs.link/urLrS

📣 Connect With Us:

► X:
https://twitter.com/CrowdStrike
► Instagram:
https://www.instagram.com/crowdstrike
► LinkedIn:
https://www.linkedin.com/company/crowdstrike

🔔 Subscribe to stay updated!

#CrowdStrike #Cybersecurity

Executive summary 

A group of Russian state-supported cyber actors has been targeting and compromising various Western government and commercial organizations using the Zimbra Collaboration Suite (ZCS) software since at least July 2025. The Russian state-supported advanced persistent threat (APT) group’s activity is tracked in the cybersecurity community under several names (see Cybersecurity industry tracking), primarily as “LAUNDRY BEAR,” a name initially coined by the Netherlands General Intelligence and Security Service (AIVD) and Defence Intelligence and Security Service (MIVD) [1].

LAUNDRY BEAR’s targeting is almost certainly to gather sensitive information for the Russian Federation, with these actors primarily focusing on the covert acquisition of email data. Previous campaigns indicated LAUNDRY BEAR relied on unsophisticated initial access techniques—including password spraying, phishing, and pass-the-cookie—allowing the group to successfully run high-volume operations. The latest campaign targeting ZCS uses a novel exploit that was a zero-day vulnerability when first exploited and continues to be successfully exploited. The vulnerability, Common Vulnerabilities and Exposures (CVE) CVE-2025-66376, was patched in November 2025. This demonstrates LAUNDRY BEAR’s intent and ability to deploy increasingly sophisticated technical capabilities.

Unlike traditional phishing campaigns that persuade a user into taking an action, such as clicking a link or opening a file, LAUNDRY BEAR’s latest campaign leverages a view-based exploit that only requires a user to view a malicious email within a vulnerable version of the webmail service. Once viewed, the exploit attempts to exfiltrate the victim’s last 90 days of email communications, the organization email directory (i.e., Global Address List [GAL]), and other sensitive information to servers controlled by LAUNDRY BEAR. The exploit also attempts to establish persistent access to victim accounts through a variety of means as detailed in the Persistence and credential access section.

This Cybersecurity Advisory (CSA) warns of this ongoing malicious threat activity and urges organizations to update their vulnerable software and implement additional mitigations to thwart these Russian state-supported actors’ continued success. The CSA is being released by the following authoring and co-sealing agencies:

• United States National Security Agency (NSA)
• United States Federal Bureau of Investigation (FBI)
• Netherlands Defence Intelligence and Security Service (MIVD)
• Netherlands General Intelligence and Security Service (AIVD)
• United States Cybersecurity and Infrastructure Security Agency (CISA)
• United States Defense Counterintelligence and Security Agency (DCSA)
• United States Department of Defense Cyber Crime Center (DC3)
• United States Department of the Treasury
• United States Naval Criminal Investigative Service (NCIS)
• Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC)
• Communications Security Establishment Canada’s (CSE’s) Canadian Centre for Cyber Security (Cyber Centre)
• New Zealand National Cyber Security Centre (NCSC-NZ)
• United Kingdom National Cyber Security Centre (NCSC-UK)
• Czech Republic National Cyber and Information Security Agency (NÚKIB)¹
• Danish Defence Intelligence Service (DDIS)²
• Estonian Foreign Intelligence Service (EFIS)³
• Finnish Defence Intelligence (FDI)⁴
• Finnish Security and Intelligence Service (SUPO)⁵
• French General Directorate for Internal Security (DGSI)⁶
• French National Cybersecurity Agency (ANSSI)⁷
• Italian External Intelligence and Security Agency (AISE)⁸
• Italian Internal Intelligence and Security Agency (AISI)⁹
• Security and Intelligence Service of the Republic of Moldova (SIS RM)¹⁰
• Polish Foreign Intelligence Agency (AW)¹¹
• The Military Counterintelligence Service of Poland (SKW)¹²
• Spain National Intelligence Centre (CNI)¹³
• Sweden National Cyber Security Centre (NCSC-SE)¹⁴

The authoring agencies urge any organizations using ZCS to implement the recommendations listed within the Mitigations section of this advisory to reduce the risk associated with this activity. This CSA also includes specific remediations for organizations to implement if they discover the presence of the listed Indicators of compromise (IOCs).  

As more organizations update their ZCS software based on this CSA, LAUNDRY BEAR may discontinue the current campaign exploiting this vulnerability; however, based on the success of this and previous campaigns, it is very likely that the group will continue to target ZCS and other email systems used by organizations in Western countries. The actors will almost certainly continue to rely on email to engage potential victims by exploiting novel vulnerabilities and, when necessary, use social engineering techniques to assist with their efforts. The authoring agencies recommend organizations regularly update their mail service software and continuously monitor their email systems and emails for malicious activity.

For a downloadable list of IOCs, see:

• AA26-204A.stix.xml (STIX XML)
• AA26-204A.stix.json (STIX JSON)

Cybersecurity industry tracking

The cybersecurity industry provides overlapping cyber threat intelligence, indicators of compromise (IOCs), and mitigation recommendations related to these Russian state-supported cyber actors. While not exhaustive, the following are threat group names commonly used for these actors within the cybersecurity community:

• LAUNDRY BEAR
• Void Blizzard [2]
• CL-STA-1114 [3]
• TA488 (formerly UNK_PitStop) [4]

Note: Cybersecurity companies have different methods of tracking and attributing cyber actors, and this may not be a 1:1 correlation to the U.S. government’s understanding for all activity related to these groupings.

Background

Public advisories from Netherlands General Intelligence and Security Service (AIVD), Netherlands Defence Intelligence and Security Service (MIVD), and Microsoft highlighted these Russian state-supported advanced persistent threat (APT) actors in May 2025, calling them LAUNDRY BEAR and Void Blizzard respectively [1] [2]. Both advisories assessed that the group was engaged in malicious cyber activity as early as April 2024.  

The May 2025 advisories highlighted a cluster of activity targeting cloud-based email environments, including Microsoft Exchange in particular, and abusing legitimate APIs to perform data exfiltration in bulk [T1114.002]. The group relied on unsophisticated means of initial access, including procuring stolen credentials on criminal marketplaces [T1078], and using social engineering techniques to lure targets into interacting with a malicious site masquerading as a legitimate one. As of April 2025, one of these sites resembled a European Defence & Security Summit registration portal that required registrants to sign in to their Microsoft account to view. Once a user entered their Microsoft credentials into this malicious site, LAUNDRY BEAR’s modified version of the open source adversary emulation toolkit, Evilginx, intercepted the user’s credentials. LAUNDRY BEAR then used this authentication data, including passwords and session tokens, to access the compromised account and conduct mass email exfiltration, as well as harvest other information. This method of compromise is commonly known as an adversary-in-the-middle (AiTM) technique [T1557].  

Beginning around July 2025, LAUNDRY BEAR shifted toward a more technical method of email compromise, highlighting their continued efforts to covertly acquire email communications from a variety of Western organizations of interest and deliver them to the Russian Federation. Using a custom-developed capability [T1587.001] named “Улей” or “Ulej” (Russian for beehive), LAUNDRY BEAR successfully targeted and exfiltrated sensitive user information from organizations who use the Zimbra Collaboration Suite (ZCS) product [T1114]. Data LAUNDRY BEAR attempted to exfiltrate from compromised accounts included:

• Last 90 days of emails,
• Email address,
• Password [T1589.001],
• Global Address List (GAL) [T1087],
• Two-factor authentication (2FA) tokens, and
• Newly-created Application Passcode [T1098].

The covert and persistent nature of this activity, along with the absence of any known financial extortion, almost certainly indicates this group’s involvement in espionage activities with Russian government backing. Additionally, extensive Ukrainian targeting, prior to use against U.S. and other NATO allies, outlines an increasing trend within Russian cyber threat groups to target Ukrainian users first—both as a priority target and as a testbench for malicious cyber techniques before broader global deployment.

Targeting details

LAUNDRY BEAR has targeted and compromised users in various organizations, including those associated with:

• the Defense Industrial Base (DIB),  
• the federal and local government,
• education,
• energy,
• law enforcement,  
• media,  
• non-governmental organizations, and
• technology.

Technical details

Note: This advisory uses the MITRE ATT&CK® Matrix for Enterprise framework, version 19. This advisory also uses MITRE D3FEND^TM version 1.4.0¹⁵. See Appendix A and Appendix B for tables of the activity mapped to MITRE ATT&CK and D3FEND tactics, techniques, and countermeasures.

Ulej is a novel data exfiltration and aggregation capability, that currently (as of the publication of this report) supports a campaign specifically targeting users of ZCS webmail servers. This capability is used to exploit CVE-2025-66376 [Common Weakness Enumeration (CWE) CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')], but likely could be adapted to exploit other vulnerabilities. It exfiltrates emails and other sensitive user data from a victim’s system immediately after exploitation and stores the data in an actor-controlled unattributable virtual private server (VPS) [T1074.002] running LAUNDRY BEAR’s “Flowerbed” collection framework. The collected data is almost certainly further exfiltrated to internal network resources for review and long-term retention.

Reconnaissance

LAUNDRY BEAR uses the Ulej capability to exploit the CVE-2025-66376 vulnerability in organizations using ZCS. This campaign’s targeted victimology and limited exploitation capabilities likely indicate this group manually identifies and targets the victim organizations. LAUNDRY BEAR likely identifies organizations with public-facing Zimbra infrastructure by port scanning [T1595] and fingerprinting datasets easily procured through various commercial vendors [T1596.005].  

After identifying a target organization, the group likely compiles email addresses for individual users to target with the exploit [T1589.002] from datasets offered by commercial vendors [T1597.002], open source intelligence [T1593], or previously exfiltrated data [T1597].  

Resource development

The actors procure VPSs from a variety of providers [T1583.003], including those with Know Your Customer (KYC) requirements, and often use fabricated identities. LAUNDRY BEAR primarily uses Mullvad VPN [T1583] when interacting with these servers, further demonstrating the group’s intent to mask their identity and maintain operations security (OPSEC). After the server is provisioned, an automated process deploys the Docker containers necessary for Ulej’s Flowerbed framework [T1608], which then receives and aggregates the data Ulej exfiltrates. These servers are typically only used for 7-60 days before moving to new infrastructure.

Flowerbed framework

Flowerbed is a Python project that uses Docker for containerization. The project includes four different Docker containers:

• Catcher,
• Certbot,
• Nginx, and
• Gardener.

Catcher acts as both a DNS and HTTP server to receive and aggregate exfiltrated victim information [T1048]. For additional information on Catcher, refer to the Exfiltration section of this advisory. Flowerbed’s next container, Certbot, is based on one of the official Certbot containers, which allows for automated generation of Let’s Encrypt certificates using DNS challenges through Cloudflare. This certificate can then be used by the Nginx container, which serves as an HTTPS reverse proxy for Catcher, enabling Flowerbed to disguise some of its exfiltration activity through an encrypted communications channel [T1048.002]. The Nginx reverse proxy also validates that the Server Name Indicator (SNI) value contains “*.i.*” prior to forwarding the traffic to Catcher. If the SNI does not contain that string, the Nginx server returns a 444 error to the client. This is likely an attempt to reject non-Ulej connections. Finally, the Gardener container functions as a health check for the Catcher service. Gardener is a simple Python script that validates Catcher correctly receives and processes data.

The simplistic Flowerbed codebase has indications that artificial intelligence (AI) played a role in its development. This highlights how AI is increasingly being used to develop malicious capabilities [T1588.007]. The dependence on AI for a simple capability, such as Flowerbed, alongside a previous reliance on open source capabilities, such as Evilginx2 [T1588.002], likely indicates a lack of advanced technical knowledge within LAUNDRY BEAR, especially in relation to true software development capabilities.

Initial access

To gain initial access, LAUNDRY BEAR sends an email containing a malicious JavaScript payload to the target [T1566]. Through exploitation of CVE-2025-66376, this JavaScript payload is immediately executed once the user views the malicious email [T1203], such as the one shown in Figure 1, in the ZCS webmail platform. Since at least November 2025, LAUNDRY BEAR began sending these phishing emails from victim infrastructure through compromised accounts [T1199], as shown in the email metadata in Figure 2. These compromised accounts were likely previous victims of this, or another LAUNDRY BEAR, campaign and their use is intended to further obfuscate and frustrate anti-phishing tools and training.

According to the National Vulnerability Database (NVD), CVE-2025-66376 was initially published on 5 January 2026. This vulnerability allows for execution of a JavaScript payload included in email content due to improper sanitization of Cascading Style Sheet’s (CSS) @import directives within an email [5]. Because the activity attributed to this campaign began in July 2025—months before Synacor released a patch and the CVE was published—the payload initially exploited a zero-day vulnerability at that time [T1587.004].  

Utilization of a zero-day exploit within this campaign demonstrates the ability for even emerging threat groups like LAUNDRY BEAR to operationalize novel exploits into a highly successful capability.

Hidden in LAUNDRY BEAR’s email is a Base64 encoded payload within the “onload” field of a Scalable Vector Graphics (SVG) element [T1027.017], as shown in Figure 3. Leading up to the inclusion of this payload in the SVG element are various instances of @import directives, as required to leverage CVE-2025-66376. This payload includes an XOR encrypted final script encoded in a Base64 inner payload (see Figure 3) [T1027.013]. The outer payload decodes and decrypts the inner payload using an XOR function and a hardcoded key and then executes the script contained within the inner payload containing the collection and exfiltration logic. By changing the key used for the XOR encryption of the inner payload or adding additional @import directives with non-functional code [T1027.010], LAUNDRY BEAR can easily generate new payloads that bypass basic threat detection signatures. This malicious payload attempts to collect and exfiltrate information in 12 asynchronous stages [T1119]. The stages in order of appearance within the payload are as follows:

1. sendStartPing,
2. gather_email,
3. gather_environment,
4. gather_2fa_codes,
5. gather_app_password,
6. gather_device_status,
7. gather_oauth_consumers,
8. gather_autocomplete_password,
9. enable_mail_protocols,
10. gather_gal,
11. sendArchives, and
12. sendFinishPing. 

Use of a zero-day exploit within this campaign demonstrates the ability for even emerging threat groups like LAUNDRY BEAR to operationalize novel exploits into a highly successful capability [T1587].

Persistence and credential access

To establish sustained persistence into the victim’s email account, the script attempts to modify account preferences and collect authentication information. Any collected credentials are later exfiltrated, as further described in the Exfiltration section below. Other campaigns attributed to LAUNDRY BEAR also demonstrated the group’s ability to circumvent multi-factor authentication through session token replay [T1550.004], and the Zimbra campaign follows a similar trend.

The script used in this campaign tries to discover the victim’s email address during the gather_email stage [T1087]. The script searches for this email address in two ways. First, it examines the batchInfoResponse variable, which an HTML script element on the webpage can define, for an email address. Even if the script finds an email address there, it also checks whether it acquired a Cross-Site Request Forgery (CSRF) token as described later in the Collection section of this advisory. If so, the script uses the “GetIdentitiesRequest” Simple Object Access Protocol (SOAP) command under the “ZimbraAccount” namespace to determine the victim’s email address [T1185] and then exfiltrates it. However, if the script does not have a CSRF token or the SOAP request fails, the script exfiltrates the email value recovered from the first method instead. If both attempts fail to capture the victim’s email, the script sends a JavaScript Object Notation (JSON) payload with a key of “email” and value of null over HTTPS and does not attempt DNS exfiltration.

During the gather_autocomplete_password stage, the script attempts to collect the victim’s saved password via the autocomplete feature of the victim’s password manager. The script injects two HTML div elements requesting login credentials onto the page outside of the victim’s view, as shown in Figure 4 and Figure 5. After waiting five seconds, the script then attempts to extract the password provided automatically by the password manager from the input element shown in Figure 4. If there is no value in that input field, it checks the password input field shown in Figure 5. If neither input field contains a value, a JSON payload with a key of “autocomplete_password” and value of null is sent over HTTPS and DNS exfiltration is not attempted.

LAUNDRY BEAR almost certainly relies on a mail client using the Internet Message Access Protocol (IMAP) for persistent access to the victim’s mailbox. During the enable_mail_protocols stage, a SOAP request leveraging the “ModifyPrefsRequest” command under the “ZimbraAccount” namespace is sent. This request attempts to set the “zimbraPrefImapEnabled” preference to TRUE. While the default setting for “zimbraPrefImapEnabled” is not well documented, this action is almost certainly intended to ensure that IMAP access to the victim’s mailbox is enabled.

ZCS does not support 2FA for some mail clients, including IMAP. To support users who rely on IMAP clients, ZCS allows for the generation of Application Passcodes. Application Passcodes are randomly generated passwords that can be used for clients that cannot support the normal 2FA process to authenticate. During the gather_app_password stage, the script makes a SOAP request using the “CreateAppSpecificPasswordRequest” command under the “ZimbraAccount” namespace to create a new Application Passcode [T1556.006]. The SOAP request uses “ZimbraWeb” as the name of the application.

Additionally, the script also attempts to collect 2FA tokens. During the gather_2fa_codes stage, the script makes a SOAP request using the “GetScratchCodesRequest” command under the “ZimbraAccount” namespace. The script then attempts to exfiltrate any non-null 2FA codes collected this way. The number of codes can vary, and each code is exfiltrated to Flowerbed individually.

Collection

As demonstrated in the Persistence and credential access section, this script relies heavily on SOAP requests to collect victim information. To make these requests, the script aims to acquire the victim’s current CSRF token, which it attempts to access within the webpage’s local storage using localStorage.getItem("csrfToken"). If the script is unable to acquire this CSRF token, it will be unable to make any SOAP requests. In addition to the SOAP commands documented in the Persistence and credential access section, other SOAP commands executed to collect victim information are shown in Table 1.

The script attempts to collect the victim’s GAL through brute force by searching for each two-character combination from a character set of “abcdefghijklmnopqrstuvwxyz1234567890.-_”. These queries are conducted using 20 batches of SOAP requests with 77 “SearchGalRequest” SOAP commands in each batch except for the last request containing only 58.

During the gather_environment stage, the script attempts to determine which type of ZCS webmail client the victim is using. The script checks the user’s current URL to determine the client type being used, checking for certain indicators (shown in Table 2) to determine the client type. The corresponding value is then used as the payload when exfiltrating the client type.

As part of collection, the script attempts to harvest any emails not marked as “junk” from the last 90 days from the victim’s account. Emails are collected daily by an HTTP GET request to the URL path, “/home/~/?fmt=tgz&meta=0&query=date:-{DAY_OFFSET}d AND (not in:junk)”. The {DAY_OFFSET} value would be between 0 and 89 representing how many days ago the email was sent or received. To prevent redundant collection and exfiltration of emails, a variable with a name based on the email date being queried, using a format of zd_comp_YYYY-MM-DD, and value of true, is saved to the window.top.localStorage property. This variable is saved regardless of whether the email is successfully exfiltrated.  

According to Mozilla documentation, if the user is not in a private browsing session, any data stored to localStorage does not typically expire. This means that if the user happens to execute the script again from the same computer, the script avoids attempting to re-exfiltrate previously captured emails. However, the script always attempts to pull any emails with a {DAY_OFFSET} of zero. In other words, the script always pulls emails sent or received the same day it is run. After email results are returned from the query for each day of email activity, those results are then passed to Flowerbed as described in the Exfiltration section.

The script also provides LAUNDRY BEAR with telemetry on any errors that occur during the collection process. This is accomplished by executing any collection or exfiltration code through helper functions that contain error handling logic. If an error occurs, a payload containing information on the error itself, the context of the error happening, and the stage in which the error occurred is sent to Flowerbed as described in the Exfiltration section below. For cases where the error occurs within a SOAP request, “:api” is concatenated to the stage value in the payload. If an error occurs during the batch SOAP requests that occur when collecting the GAL of the victim, the stage value will use a format of gather_gal:{VAL}:api. The {VAL} placeholder indicates which batch request, a number from 0 to 19, the error occurred in. Errors that occur during the password autocomplete interception process will use “gather_autocomplete_password:dom” for the stage value. Finally, if an error occurs when attempting to collect or exfiltrate a specific day’s emails, the stage will include which day the error occurred on, using the previously defined placeholder {DAY_OFFSET}, with a format of sendArchive:day-{DAY_OFFSET}.

Exfiltration

At the end of each stage in the collection process, the script attempts to exfiltrate acquired information to Flowerbed. The script primarily relies on two forms of data exfiltration: DNS [T1048.003] and HTTPS. Some information is exfiltrated over both the DNS and HTTPS channels.

Prior to exfiltration, a randomized 10- or 11-character alphanumeric string is generated as an identifier for the victim. This identifier is included in the URL of both the DNS- and HTTPS-based exfiltration.  

DNS exfiltration

DNS exfiltration occurs through DNS A record queries. To ensure data exfiltrated through DNS is not corrupted when traversing through non-actor-controlled DNS infrastructure, Ulej maintains compliance with RFC 1035, Domain Names - Implementation and Specification, specifically accounting for the case insensitivity and subdomain length requirements. Base32 encoding is used to create a case-insensitive payload. Once the payload is encoded, a period (“.”) is added every 60 characters to ensure each subdomain is under 63 characters long. The script then creates a new image object sourced from a URL with the scheme defined in Figure 6. Any traffic involving DNS exfiltration will have “d-“ prefixing the victim identifier, and the subdomain immediately following indicates the type of information being exfiltrated.

When the script generates an image object, the browser tries to retrieve the complete domain of the URL specified as the source of the image. This triggers a DNS request sent to the actor-controlled server and processed by Flowerbed. Table 3 lists both the information exfiltrated via DNS and their corresponding data type identifiers in the DNS queries.  

HTTPS exfiltration

Any information exfiltrated via DNS is also exfiltrated through HTTPS, as well as additional data including email content, contacts, attachments, and error logging information. By using Let’s Encrypt certificates, this group can quickly deploy new infrastructure and leverage encrypted HTTPS communications with valid server certificates when exfiltrating information from the victim’s environment. The HTTPS exfiltration capability only uses two HTTP content types, defined in Table 4. Traffic associated with HTTPS exfiltration will use the URL scheme shown in Figure 7.  

Some of the data transmitted via HTTPS uses the standard JSON content type format. The script includes the information in a POST request to actor-controlled infrastructure.  

Table 5 provides a summary of the JSON-based exfiltration.

The script transmits all HTTPS exfiltration not identified in Table 5 using the Octet-Stream content type as binary data. The POST requests for this method include a filename in the “X-Filename” header. Traditionally, developers use headers prefixed with “X-” to denote custom headers that do not follow a defined standard. The purpose of including this header remains unclear since the Catcher capability ignores the provided filename when saving the data. Table 6 summarizes the data exfiltrated in this format.

The script sends all exfiltrated data identified in Table 6 to the Catcher service exactly as received from the SOAP request in a JSON payload, except for email exfiltration. For email exfiltration, the script sends it as a GZIP compressed archive [T1560]. Although most of the exfiltration consists of valid JSON, the script still attempts to exfiltrate all information identified in Table 6 using the application/octet-stream content typing rather than application/json.

At the beginning and end of the collection and exfiltration activity, during the sendStartPing and sendFinishPing stages respectively, the script submits a POST request with a JSON payload to indicate that the script is starting or finishing execution. Throughout execution, the script also logs error events and send the logs using similar JSON payloads. The script sends the JSON in a POST request to the URL documented in Figure 2, using a URL path of “/v/p” and with a “subtype” key that shows which type of action it logged (start, finish, or error).  

Catcher

Ulej exfiltrates information to Flowerbed to be handled by a service named Catcher. Catcher is a containerized Python application, running in Docker as part of Flowerbed, which is detailed in the Resource development section. It receives exfiltrated data and temporarily stores it, enabling its eventual transfer to infrastructure designed for long-term, secure storage.

Catcher acts as an HTTP server over port 8000 and a DNS server on port 53. As described in the Resource development section, the Flowerbed project uses an additional Docker container running an Nginx reverse proxy to enable HTTPS support. This reverse proxy uses a certificate generated by Let’s Encrypt and forwards all traffic with an SNI containing “*.i.*” to port 8000 within the Catcher container.

The DNS service can accept A, AAAA, MX, TXT, and CAA queries. For any MX, AAAA, or CAA queries, the server will always provide an empty response. The system only supports TXT records as needed to process Automatic Certificate Management Environment (ACME) requests, which enable the assignment of Let’s Encrypt certificates. If the server receives an A query, Catcher will always respond with the public IP address of the Flowerbed server.  

However, if a query includes a domain formatted as shown in Figure 6 and Figure 7, the service saves a log file in JSON format to disk containing the following details of the DNS query:

• Time of query,
• Source IP address for query,
• Queried domain, and
• Type of query.

The HTTP server typically responds with OK, except in cases where the path is “pixel.gif” when the response contains a 1x1 gif image with a SHA-256 hash of ef1955ae757c8b966c83248350331bd3a30f658ced11f387f8ebf05ab3368629. Like the DNS service, the HTTP service will only log entries when the domain found in the host header of the request follows the expected formatting as seen in Figure 6 and Figure 7. As the HTTPS exfiltration uses non-standardized binary and JSON-formatted payloads when exfiltrating to Catcher, Catcher will check the content type of the request. If the content type is set to “application/json”, Catcher encodes the data in Base64 and includes it in the JSON log entry written to disk. If the content type is set to any other value, Catcher leaves the Base64 payload in the JSON log entry blank and saves the payload to a separate file with the same filename as the JSON log entry with a “.bin” file extension. An HTTPS exfiltration event causes Catcher to save a JSON formatted log file to disk containing the following information from the HTTP request:

• Time,
• Source IP address,
• Request method,
• Host,
• Path,
• Query string,
• Headers, and
• Base64 payload.

These JSON event log files and binary output files are then initially saved to the directory /root/hits/tmp and later moved to the /root/hits/ready directory once processed. This prevents incomplete files, which are still being uploaded to Catcher, from premature exfiltration from the server. Approximately every 60 seconds, a likely automated workflow establishes a Secure Shell (SSH) connection with the server hosting Flowerbed for a few seconds, almost certainly exfiltrating the data processed by Catcher to non-public-facing infrastructure. The command in Figure 8 also executes hourly to remove all files last modified at least two days ago from the /root/hits/ready directory.

Response strategies

Mitigations

In many cases, by the time an organization identifies a compromise related to this campaign, numerous sensitive and proprietary emails have already been exfiltrated. The significant risk posed by this cyber threat emphasizes the importance for organizations that use ZCS and other similar webmail solutions to take proactive steps to mitigate this risk.

All organizations that use the ZCS webmail service should immediately prioritize ensuring that their ZCS is not running a vulnerable version. A patch for CVE-2025-66376 was released for both 10.1.13 and 10.0.18 versions of ZCS [D3-AH]. If immediate patching is not feasible, organizations should advise employees to use alternative mail clients to access email and avoid using the Classic ZCS webmail client until ZCS is updated to a non-vulnerable version [d3f:Isolate].

System administrators should closely monitor any Internet-connected ZCS or other email systems and the workstations that access those systems and promptly apply available software updates [D3-AH]. Administrators can maintain awareness of active vulnerability exploitation by referencing open source resources, including CISA’s Known Exploited Vulnerabilities Catalog and NCSC-UK’s Responding to active exploitation of vulnerabilities guidance.

Organizations should consider using a third-party authentication service that supports passkeys for authentication to mediate access to ZCS and other services that do not natively support passkeys. By doing so, organizations can work to eliminate the possibility of automated password collection from autocomplete or password reuse [D3-CH]. However, Application Passcodes may still be necessary and should be monitored closely.  

Organizations should implement network monitoring capabilities with collection and short-term retention of packet capture or NetFlow data and maintain log collection and storage [CPG 3.Q]. This will allow organizations to monitor for and identify suspicious network activity [CPG 4.B], such as:

• Significant amounts of outbound data being sent to IPs associated with VPS providers not used by the organization [D3-NTA];
• Frequent DNS queries for a suspicious domain with seemingly random subdomains [D3-DNSTA];
• A sudden spike of connections to a server associated with a recently established domain [D3-NTCD]; and  
• Connections to internal services, such as webmail, from VPN providers frequently leveraged by this group for nefarious activity, such as Mullvad VPN [D3-NTCD].

Additionally, for organizations that can inspect the content of outbound HTTPS connections via break-and-inspect infrastructure, security teams should identify traffic matching the characteristics described in the Exfiltration section of this advisory.

Indicators of compromise (IOCs)

Flowerbed infrastructure

The following indicators have been attributed to use by LAUNDRY BEAR for their campaign targeting ZCS’s webmail service as of the publication of this advisory. (Disclaimer: Due to the frequency of operational structure changes by this group, these indicators are intended solely for historic attribution purposes. Some indicators, such as IPs, compromised emails, and domains, may be outdated, so organizations should check for current activity before acting on these IOCs.) Table 7 provides details about the server infrastructure used to host Flowerbed, and Table 8 lists the corresponding SHA-1 hash values for the Let’s Encrypt certificates used by that infrastructure [D3-IAA].

LAUNDRY BEAR has used the following email addresses to procure resources used for this campaign:

• ivanka.zurabishvili@proton[.]me,
• zmul1@buildandconsulting[.]com,
• garrysmithme@pinmx[.]net, and
• hostingclient@pinmx[.]net.

Phishing distribution

LAUNDRY BEAR primarily relied on ProtonMail for distribution of malicious email. However, as stated above, LAUNDRY BEAR’s more recent efforts likely have shifted to distributing the payload through previous victims.  

The following email addresses have distributed payloads attributed to this campaign:

• c.laurent.ejfa@proton[.]me,
• j.moreau.epsc@proton[.]me,
• liberty.insights@proton[.]me,
• certain email addresses (presumably compromised) at the isofts.kiev[.]ua domain (i.e., ending with @isofts.kiev[.]ua), and
• certain email addresses (presumably compromised) at the navs.edu[.]ua domain (i.e., ending with @navs.edu[.]ua).

Additionally, the following are SHA-256 hashes of email samples containing the malicious payload attributed to this campaign:

• 98df604ecc57f884a2e6ce3266a0013ad64455cac48442c2312cfa4765007aaf,
• 60db9abae75cd8ccc49dd7ea5feb41677566dcd442f12ebc5745ffd2810fb874,
• b1f5beb1175fc5c7d1806a2f0d900eb124c54f0286c5c52b66eea7a6633adb1d, and
• 1517b3caa495f6c4e832df9c75fc94667e3c233773f7fa4e056d5e30e5ead760.

Post-compromise artifacts

Currently, the script does not remove artifacts. This leaves additional opportunities to identify victims of this activity. While emphasis should always be placed on consistent monitoring of network traffic and endpoint activity, there are a variety of persistent artifacts described below that can be used to identify victims of this campaign.

This Ulej capability relies on creating a significant number of SOAP requests to collect account information for exfiltration. ZCS logs from these requests are stored, by default, in the /opt/zimbra/log/mailbox.log file [D3-PA]. A significant amount of SOAP request activity that aligns with what was described in the Persistence and credential access and Collection sections of this advisory could indicate a potential compromise. Specific examples of high-risk SOAP request activity might include:

• Many SearchGalRequest command requests from a single user over a short period of time;
• Use of the CreateAppSpecificPasswordRequest command, especially in cases where it is creating an Application Passcode named “ZimbraWeb”; and
• Use of the GetScratchCodesRequest command.

While LAUNDRY BEAR uses the localStorage property to track what days had emails previously exfiltrated, defenders can use this property to identify victims of this campaign and determine the scope of exfiltrated information [D3-PA]. Review of the items stored in that property for an organization’s ZCS webmail client page on an endpoint device could indicate compromise if there are items named with a format of zd_comp_YYYY-MM-DD, as explained in the Collection section of this advisory.

While Application Passcodes have non-malicious purposes, in this case instances of these passcodes with the name “ZimbraWeb” are almost certainly malicious. The ZCS webmail application can support 2FA natively and does not require the use of an Application Passcode, so there is no reason that there should be one named “ZimbraWeb.”

In instances where organizations identify victims of this campaign, they should also examine the inbox of the suspected victim for the original phishing email [D3-MA]. If an email that has a payload exploiting CVE-2025-66376 is discovered, steps should be taken immediately to identify and quarantine other instances of emails with similar body content, senders, and subject lines to prevent further exploitation and exfiltration.  

Remediation

In the event an organization identifies activity associated with this campaign, that organization should take steps to minimize further exploitation. The organization should consider requesting that employees minimize use of the ZCS webmail client until the organization updates to a patched version that is not vulnerable to CVE-2025-66376.

Organizations should use identifiers from the IOCs section of this report to identify any individuals compromised by this campaign and record the date(s) of compromise(s) to determine the scale and scope of emails exfiltrated.

All users from the organization should have all Application Passcodes and 2FA scratch keys revoked. Affected organizations should require all employees to change passwords in line with establishing minimum password strength requirements [CPG 3.B] and creating unique credentials [CPG 3.C], specifically noting that compromised employees might have had any password stored in a password manager exfiltrated.

Works cited

[1] Netherlands General Intelligence and Security Service (AIVD) and Netherlands Defence Intelligence and Security Service (MIVD). AIVD and MIVD identify a new Russian cyber threat actor. 2025. https://www.aivd.nl/site/binaries/site-content/collections/documents/2025/05/27/aivd-en-mivd-onderkennen-nieuwe-russische-cyberactor/Advisory+AIVD+en+MIVD+Public+report+on+new+cyber+actor.pdf

[2] Microsoft Corporation. New Russia-affiliated actor Void Blizzard targets critical sectors for espionage. 2025. https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/

[3] Palo Alto Networks Unit 42. Russian Global Webmail Espionage. 2026. https://unit42.paloaltonetworks.com/russian-webmail-espionage/ 

[4] Proofpoint. TA488 Targets Zimbra Mailservers with Half-Click Exploits. 2026. https://www.proofpoint.com/us/blog/threat-insight/ta488-zcs-exploit

[5] Seqrite. Operation GhostMail: Russian APT exploits Zimbra Webmail to Target Ukraine State Agency. 2026. https://www.seqrite.com/blog/operation-ghostmail-zimbra-xss-russian-apt-ukraine/  

Footnotes

¹ Národní úřad pro kybernetickou a informační bezpečnost
² Forsvarets Efterretningstjeneste
³ Välisluureamet
⁴ Sotilastiedustelu
⁵  Suojelupoliisi
⁶ Direction générale de la sécurité intérieure
⁷ Agence nationale de la sécurité des systèmes d’information
⁸ Agenzia Informazioni e Sicurezza Esterna
⁹ Agenzia Informazioni e Sicurezza Interna
¹⁰ Serviciul de Informații și Securitate al Republicii Moldova
¹¹ Agencja Wywiadu
¹² Służba Kontrwywiadu Wojskowego
¹³ Centro Nacional de Inteligencia
¹⁴ Nationellt Cybersäkerhetscenter
¹⁵ MITRE and ATT&CK are registered trademarks of The MITRE Corporation. MITRE D3FEND is a trademark of The MITRE Corporation.

Acknowledgements

The authoring agencies acknowledge the contributions to this advisory from Palo Alto Networks Unit 42 and Proofpoint.

Disclaimer of endorsement

The information and opinions contained in this document are provided "as is" and without any warranties or guarantees. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favoring by the United States Government, and this guidance shall not be used for advertising or product endorsement purposes.

Organizations have no obligation to respond or provide information back to the authoring organizations in response to this joint advisory. If, after reviewing the information provided, an organization decides to provide information to the authoring organizations, reporting must be consistent with all applicable laws and policies.

Purpose

This document was developed in furtherance of the authoring agencies’ cybersecurity missions, including their responsibilities to identify and disseminate threats, and to develop and issue cybersecurity specifications and mitigations. This information may be shared broadly to reach all appropriate stakeholders.

Contact

Appendix A: MITRE ATT&CK tactics and techniques

See Table 9 through Table 19 for all the threat actor tactics and techniques referenced in this advisory.

Appendix B: MITRE D3FEND countermeasures

See Table 20 for a mapping of several of the cybersecurity countermeasures mentioned in this advisory.

The post Microsoft admits SMS and voice MFA can’t stop AI attacks, mandates passkeys in Entra by February 2027 appeared first on Windows Latest

The post Yubico Released YubiKey 5.8 With Secure Enterprise Workflows and AI-driven Approvals appeared first on Cyber Security News.

Passwörter sind nervig und in vielen Fällen unsicher. Aber zum Teufel mit dem Aktualisieren und Verbessern der Passwörter. Entscheiden Sie sich lieber für das Ersetzen. Genauer gesagt: Ersetzen Sie Ihre Passwörter durch Passkeys.

Passkeys müssen nicht auswendig gelernt werden, können direkt auf Ihrem Smartphone gespeichert werden und sind sicherer als Passwörter. Ein besonderer Vorteil: Sie sind Phishing-resistent. Außerdem sollten Ihre Anmeldedaten, falls eine Website gehackt wird (was heutzutage nur allzu häufig vorkommt), weder knackbar noch für andere nutzbar sein.

Wenn Sie einen Passkey erstellen, werden sowohl ein öffentlicher als auch ein privater Schlüssel generiert. (Dies wird als Public-Key- oder asymmetrische Verschlüsselung bezeichnet.) Der private Schlüssel wird von Ihrem Gerät oder Passwort-Manager verwahrt. Zu den unterstützten Geräten gehören Smartphones, Tablets, Hardware-Dongles wie YubiKeys und kompatible PCs. Sie können wählen, ob Sie Passkeys lokal auf Ihrem Gerät oder in der Cloud speichern möchten.

Diese geheimen Schlüssel werden durch die biometrische Authentifizierung Ihres Geräts (z. B. Fingerabdruck oder Gesicht) oder durch die Methode gesichert, die Ihren Passwort-Manager schützt.

Alaina Yee / Foundry

Der öffentliche Schlüssel wird hingegen an die Website weitergegeben, für die er generiert wurde. Sie benötigen sowohl den öffentlichen als auch den privaten Schlüssel, um sich bei dem Konto anzumelden, mit dem sie verknüpft sind. Bei jeder Anmeldung fordert die Website über die folgenden Schritte einen Nachweis an, dass Sie der Kontoinhaber sind:

1. Eine Anfrage wird an Ihr Gerät (oder Ihren Passwort-Manager) gesendet, um den Verifizierungsprozess zu starten.
2. Ihr Fingerabdruck, ein Gesichtsscan oder eine andere Authentifizierungsmethode ist erforderlich, um die Anfrage zu autorisieren.
3. Wenn Sie zustimmen, wird Ihr privater Schlüssel (auch bekannt als geheimer Schlüssel) verwendet, um eine digitale Signatur zu erstellen, die dann an die Website gesendet wird.
4. Die Website verwendet die digitale Signatur dann, um zu versuchen, den von Ihnen angegebenen öffentlichen Schlüssel zu entschlüsseln. Ist dies erfolgreich, haben Sie Zugriff.

Wenn Passkeys korrekt implementiert sind, kann niemand Ihren privaten Schlüssel anhand des öffentlichen Schlüssels ableiten – was bedeutet, dass Datenlecks und Sicherheitsverletzungen nicht so gefährlich sind. (Zumindest was die Sicherheit von Passwörtern angeht.) Passkeys funktionieren zudem nur für die spezifische Website, für die sie generiert wurden, sodass sie nicht von gefälschten, bösartigen Websites erfasst oder verwendet werden können – genau so stehlen Phishing-Betrüger normalerweise Passwörter.

Der einzige wirkliche Haken bei Passkeys besteht darin, dass Sie sie lokal auf einem Gerät speichern – wenn Sie das Gerät verlieren, könnten Sie aus Ihrem Konto ausgesperrt werden. Dies geschieht jedoch nur, wenn Sie sich bewusst dafür entscheiden, einen Passkey lokal zu speichern, beispielsweise auf einem Windows-PC mit einem rein lokalen Konto (was heutzutage selten ist) oder auf einem YubiKey. Sie können solche Probleme leicht vermeiden, indem Sie ein zweites Gerät oder einen Hardware-Sicherheitsschlüssel nutzen und/oder Ihrem Konto als Backup ein extrem sicheres Passwort sowie eine Zwei-Faktor-Authentifizierung hinzufügen.

Diese letzte Option macht Passwörter zwar nicht vollständig überflüssig, bringt Sie aber zumindest für den Alltag schon ein gutes Stück weiter. Ich persönlich finde das Einloggen mit einem Passkey schneller als mit Passwörtern, selbst wenn ich einen Passwort-Manager mit automatischer Ausfüllfunktion verwende.

Wenn Ihnen der Umstieg wie eine große Aufgabe erscheint, beginnen Sie zunächst mit den großen Diensten wie Google, Apple und Microsoft sowie mit großen Online-Shops wie Amazon. Die Umstellung Ihrer am häufigsten genutzten Apps und Websites sowie aller Dienste, die mit sensiblen Informationen (einschließlich Rechnungsdaten) umgehen, macht Ihr Online-Leben bereits sicherer und bequemer.

Passwörter sind nervig und in vielen Fällen unsicher. Aber zum Teufel mit dem Aktualisieren und Verbessern der Passwörter. Entscheiden Sie sich lieber für das Ersetzen. Genauer gesagt: Ersetzen Sie Ihre Passwörter durch Passkeys.

Passkeys müssen nicht auswendig gelernt werden, können direkt auf Ihrem Smartphone gespeichert werden und sind sicherer als Passwörter. Ein besonderer Vorteil: Sie sind Phishing-resistent. Außerdem sollten Ihre Anmeldedaten, falls eine Website gehackt wird (was heutzutage nur allzu häufig vorkommt), weder knackbar noch für andere nutzbar sein.

Wenn Sie einen Passkey erstellen, werden sowohl ein öffentlicher als auch ein privater Schlüssel generiert. (Dies wird als Public-Key- oder asymmetrische Verschlüsselung bezeichnet.) Der private Schlüssel wird von Ihrem Gerät oder Passwort-Manager verwahrt. Zu den unterstützten Geräten gehören Smartphones, Tablets, Hardware-Dongles wie YubiKeys und kompatible PCs. Sie können wählen, ob Sie Passkeys lokal auf Ihrem Gerät oder in der Cloud speichern möchten.

Diese geheimen Schlüssel werden durch die biometrische Authentifizierung Ihres Geräts (z. B. Fingerabdruck oder Gesicht) oder durch die Methode gesichert, die Ihren Passwort-Manager schützt.

Alaina Yee / Foundry

Der öffentliche Schlüssel wird hingegen an die Website weitergegeben, für die er generiert wurde. Sie benötigen sowohl den öffentlichen als auch den privaten Schlüssel, um sich bei dem Konto anzumelden, mit dem sie verknüpft sind. Bei jeder Anmeldung fordert die Website über die folgenden Schritte einen Nachweis an, dass Sie der Kontoinhaber sind:

1. Eine Anfrage wird an Ihr Gerät (oder Ihren Passwort-Manager) gesendet, um den Verifizierungsprozess zu starten.
2. Ihr Fingerabdruck, ein Gesichtsscan oder eine andere Authentifizierungsmethode ist erforderlich, um die Anfrage zu autorisieren.
3. Wenn Sie zustimmen, wird Ihr privater Schlüssel (auch bekannt als geheimer Schlüssel) verwendet, um eine digitale Signatur zu erstellen, die dann an die Website gesendet wird.
4. Die Website verwendet die digitale Signatur dann, um zu versuchen, den von Ihnen angegebenen öffentlichen Schlüssel zu entschlüsseln. Ist dies erfolgreich, haben Sie Zugriff.

Wenn Passkeys korrekt implementiert sind, kann niemand Ihren privaten Schlüssel anhand des öffentlichen Schlüssels ableiten – was bedeutet, dass Datenlecks und Sicherheitsverletzungen nicht so gefährlich sind. (Zumindest was die Sicherheit von Passwörtern angeht.) Passkeys funktionieren zudem nur für die spezifische Website, für die sie generiert wurden, sodass sie nicht von gefälschten, bösartigen Websites erfasst oder verwendet werden können – genau so stehlen Phishing-Betrüger normalerweise Passwörter.

Der einzige wirkliche Haken bei Passkeys besteht darin, dass Sie sie lokal auf einem Gerät speichern – wenn Sie das Gerät verlieren, könnten Sie aus Ihrem Konto ausgesperrt werden. Dies geschieht jedoch nur, wenn Sie sich bewusst dafür entscheiden, einen Passkey lokal zu speichern, beispielsweise auf einem Windows-PC mit einem rein lokalen Konto (was heutzutage selten ist) oder auf einem YubiKey. Sie können solche Probleme leicht vermeiden, indem Sie ein zweites Gerät oder einen Hardware-Sicherheitsschlüssel nutzen und/oder Ihrem Konto als Backup ein extrem sicheres Passwort sowie eine Zwei-Faktor-Authentifizierung hinzufügen.

Diese letzte Option macht Passwörter zwar nicht vollständig überflüssig, bringt Sie aber zumindest für den Alltag schon ein gutes Stück weiter. Ich persönlich finde das Einloggen mit einem Passkey schneller als mit Passwörtern, selbst wenn ich einen Passwort-Manager mit automatischer Ausfüllfunktion verwende.

Wenn Ihnen der Umstieg wie eine große Aufgabe erscheint, beginnen Sie zunächst mit den großen Diensten wie Google, Apple und Microsoft sowie mit großen Online-Shops wie Amazon. Die Umstellung Ihrer am häufigsten genutzten Apps und Websites sowie aller Dienste, die mit sensiblen Informationen (einschließlich Rechnungsdaten) umgehen, macht Ihr Online-Leben bereits sicherer und bequemer.

Reisen macht in der Regel Spaß, besonders im Sommer, wenn alle im Urlaub sind. Daher kann es leicht passieren, dass man auch die Sorgen um die Cybersicherheit zu Hause zurücklässt. Leider machen Kriminelle keine Pause. Tatsächlich setzen sie gerade auf Ihre nachlässigen Gewohnheiten.

Doch mit ein paar kleinen Anpassungen können Sie Ihre freie Zeit wieder ganz unbeschwert genießen. Insbesondere diese vier Maßnahmen befassen sich mit Problemen, die immer wieder in den Nachrichten auftauchen – und sie sind recht einfach umzusetzen.

Behalten Sie Ihre Bordkarte für sich

Ihre Bordkarte kann viel über Sie preisgeben. Zunächst einmal kodieren Fluggesellschaften mehr Informationen in den Barcode, als auf der Karte angezeigt werden – Details wie Ihr Geburtsdatum, Ihre Reisepassnummer und Ihre Vielfliegernummer.

Ein besonders drastisches Beispiel liefert die US-Billigfluglinie Frontier Airlines. Es stellt sich heraus, dass jeder, der eine Kopie des QR-Codes eines Passagiers besitzt, sensible Daten aus dessen Konto abrufen kann – wie beispielsweise hinterlegte Kreditkartennummer, Anschrift, TSA-PreCheck-Nummer und Reisepassnummer –, indem er eine Anfrage an eine API stellt, die die Website des Unternehmens betreibt.

Selbst abgesehen von der Gefahr des Identitätsdiebstahls kann Ihnen jemand, der Ihre Bordkarte im Blick hat, erheblichen Ärger bereiten. Mit Ihrem vollständigen Namen und dem Bestätigungscode kann diese Person Ihre Flugdaten ändern oder Ihre Buchung sogar komplett stornieren.

Das Fazit: Schirmen Sie Ihren Bildschirm oder Ihr ausgedrucktes Ticket vor allen außer dem Mitarbeiter am Gate ab. Und veröffentlichen Sie auf keinen Fall ein Bild Ihrer Bordkarte in den sozialen Medien.

Vermeiden Sie öffentliche Computer

Die Nutzung eines gemeinsam genutzten PCs in einem Hotel (oder an einem anderen öffentlichen Ort) birgt Risiken. Diese Computer können mit Malware infiziert sein, die alle eingegebenen Daten, einschließlich Passwörter, erfasst. Oder sie ermöglichen es einem Hacker, sich unbefugten Zugriff auf alle Konten zu verschaffen, bei denen Sie sich angemeldet haben.

Auch durch ausgedruckte Dokumente können Sie digitale Spuren hinterlassen. Manche Drucker speichern eine Kopie der Druckaufträge – und aller darin enthaltenen persönlichen Daten.

Das Fazit: Verzichten Sie so weit wie möglich auf öffentliche Computer und Drucker. Wenn Sie unbedingt einen öffentlichen Computer nutzen müssen, verwenden Sie ein Inkognito-Browserfenster und melden Sie sich mit einem Passkey statt mit einem Passwort an.

Verwenden Sie ein VPN in öffentlichen WLAN-Netzen

Sam Singleton

Öffentliches WLAN kann aus zwei Gründen gefährlich sein. Erstens könnten andere Personen, die sich mit Ihnen im selben legitimen Netzwerk befinden, versuchen, Ihre Aktivitäten auszuspionieren. Zweitens könnten Sie sich versehentlich mit einem gefälschten kostenlosen WLAN-Netzwerk verbinden.

Im ersten Fall ist das Risiko, dass Sie sensible Daten an einen Hacker verlieren, heutzutage geringer. Die meisten Verbindungen zu Websites sind mittlerweile standardmäßig verschlüsselt. Einige wenige nutzen jedoch für bestimmte Aktivitäten nach wie vor unverschlüsselte Verbindungen, sodass das Risiko nicht gleich Null ist.

Was gefälschte WLAN-Netzwerke betrifft, so kann es passieren, dass Sie über gefälschte Anmeldeseiten Ihre Zugangsdaten preisgeben oder sogar Malware auf Ihr Gerät geschleust wird.

Das Fazit: Nutzen Sie Ihre Mobilfunkdaten für sensible Angelegenheiten wie Bankgeschäfte oder medizinische Belange. Ist dies nicht möglich, verwenden Sie ein VPN (die besten VPNs stellen wir hier vor), wenn Sie sich mit einem öffentlichen WLAN verbinden. Ein gutes VPN fungiert als geschützter Tunnel, der all Ihre Aktivitäten verschlüsselt und die von Ihnen besuchten Websites vor Netzwerkbeobachtern verbirgt.

Verwenden Sie Ihr eigenes USB-Ladegerät

Haben Sie schon einmal von„Juice Jacking“ gehört? Es handelt sich um eine beängstigend klingende, aber eher seltene Taktik, mit der auf gespeicherte Daten auf einem Smartphone zugegriffen wird – oder um Malware darauf zu installieren.

„Juice Jacking“ funktioniert folgendermaßen: Ein Hacker manipuliert einen USB-Ladeanschluss, wie er an Flughäfen, in Hotels und an anderen öffentlichen Orten zu finden ist. Wenn Sie Ihr Smartphone anschließen, sind Sie potenziell anfällig für Angriffe. Und was die Sache noch komplizierter macht: Sicherheitsexperten vertreten nach wie vor widersprüchliche Meinungen darüber, wie groß die Bedrohung durch „Juice Jacking“ tatsächlich ist.

Das Fazit: Verwenden Sie einfach Ihr eigenes USB-Ladegerät. Das hat einen doppelten Vorteil: Sie müssen sich weder Gedanken über „Juice Jacking“ noch über elektrische Schäden durch ein minderwertiges Ladegerät machen. (Ich habe einmal durch ein minderwertiges Ladegerät einen Anschluss an meinem Smartphone kurzgeschlossen. Das war wirklich ärgerlich.)

Ist das keine Option? Schalten Sie Ihr Smartphone vorsichtshalber aus, bevor Sie ein öffentliches Ladegerät verwenden.

Tags: #Cyber Crime | #Passkeys | #Phishing

Read more →

The post Google adds FIDO2 keys and phone passkeys to Windows login via GCPW appeared first on IT Security News.

The post Google adds FIDO2 keys and phone passkeys to Windows login via GCPW appeared first on Help Net Security.

Tags: #Cyber Security | #Microsoft

Read more →

The post Microsoft Entra ID authentication overhaul to start in September 2026 appeared first on IT Security News.

The post Microsoft Entra ID authentication overhaul to start in September 2026 appeared first on Help Net Security.

The post Microsoft Changes Entra ID default Authentication Method to Passkeys, Replacing Passwords appeared first on Cyber Security News.

Tags: #OpenAI | #Passkeys

The post Microsoft Entra ID security updates: Passkeys are the default authentication method in Entra ID appeared first on Microsoft Security Blog.

Getting started

• Admins: Visit the Help Center to learn more about enforcing 2SV.
• End users: There is no end user setting for this feature.

Rollout pace

• Rapid Release and Scheduled Release domains: Gradual rollout (up to 15 days for feature visibility)  starting on July 13, 2026

Availability

• Available to all Google Workspace customers

Resources

• Google Workspace Admin Help: Prepare to install GCPW

Read more →

The post Microsoft Entra ID security updates: Passkeys are the default authentication method in Entra ID appeared first on IT Security News.

Security and privacy are core principles of Mozilla’s Manifesto and remain at the heart of Firefox’s development. In this edition, we highlight some of the key security and privacy initiatives from Q2 2026, grouped into the following areas:

• Firefox Product Security & Privacy, new security and privacy features, protections, and integrations in Firefox
• Core Security, platform security improvements, hardening efforts, and foundational enhancements
• Community Engagement, highlights from our security research community and bug bounty program
• Web Security & Standards, progress on web technologies and standards that help websites better protect users from online threats

Preface

Note: Some of the bugs linked below might not be accessible to the general public and restricted to specific work groups. We de-restrict fixed security bugs after a grace-period, until the majority of our user population have received Firefox updates. If a link does not work for you, please accept this as a precaution for the safety of all Firefox users.

Firefox Product Security & Privacy

Private Access Control Tokens (PACT): PACT is a cross-industry initiative designed to tackle one of the web’s most urgent challenges: enabling websites to reliably distinguish legitimate users and authorized automated agents from abusive traffic without compromising user privacy. To introduce the initiative, we published a technical deep dive on Mozilla Hacks alongside a companion Mozilla blog post that explains the vision, motivation, and privacy-preserving design behind PACT.

Qualified Website Authentication Certificates (QWACs): Firefox is prepared to meet upcoming eIDAS requirements under the EU Digital Identity Framework. Qualified Website Authentication Certificates (QWACs), as required by the framework, are supported in Firefox 153 (Bug 2043399) onwards.

Hardening Firefox with Claude Mythos: In a blogpost we shared how our AI-assisted security testing pipeline, powered by Claude Mythos, uncovered and helped remediate hundreds of previously hidden vulnerabilities in Firefox, significantly strengthening the browser’s security while demonstrating the transformative potential of AI to enhance defensive cybersecurity.

Visual Indications for Geolocation Access: In light of some web pages using geolocation for activities that are not related to their maps functionality, Firefox now displays a real-time visual indicator whenever a web page is accessing the user’s geolocation. Starting with Firefox 153, the address bar now provides a real-time visual indicator the moment a website begins accessing a user’s location, providing users with immediate awareness and greater transparency into when and how their geolocation data is being used.

Improving Website Compatibility in Private Browsing: Starting with Firefox 152, Private Browsing Mode now offers users the option to temporarily lower tracking protections for the current tab when stricter tracker blocking could be causing a website to malfunction. Previously, this may have resulted in users turning off privacy protections completely to continue using visited web page. With our new feature, users can quickly restore site functionality of the current tab, preserving users’ overall privacy settings.

Instant fresh start through new Fire Button: Firefox 151 introduced the new Fire Button for Private Browsing, giving users an instant fresh start with a single click. Instead of closing and reopening a Private Window, users can immediately clear all browsing data and continue browsing in a clean session, making Private Browsing faster, more convenient, and just as private.

Advanced Anti-Fingerprinting Protections: Firefox 151 expands our default anti-fingerprinting defenses by ensuring the Available Screen Resolution, Touch Points, and Canvas APIs will provide uniform results for all of our users while also maintaining performance and compatibility. On macOS, for example, these enhancements are expected to reduce the share of users identified as unique by more than 20%, making it significantly harder for websites to uniquely identify and track users using obscure fingerprinting.

Local Network Access Protections: Firefox now requires user permission before websites can access apps and services on a user’s local network or device, helping prevent unauthorized access and sneaky tracking attempts. The LNA feature is rolling out gradually, starting with Firefox Desktop 151 through 153. Android support will follow in upcoming releases.

Core Security

Firefox CA Root Program: We published Root Store Policy v3.1, introducing stricter transparency, documentation, and audit requirements for public CAs to strengthen trust in the Web PKI.

WebAuthn Related Origin Requests: This feature allows seamless passkey sign-ins across related domains e.g., the same provider using multiple top-level domains. In contrast to other browsers, Firefox UI provides transparency and choice so users are aware and can control when websites request for passkeys from other, related sites.

Community Engagement

Hosting Events: We organized and hosted multiple web tech meet-ups in the Mozilla Berlin office, bringing together the developer community to explore the latest advances in web technology, privacy, and security. If you’re in the area, we’d love to have you join us at a future event.

Community Shares: Firefox tracking protection was presented at the SnooSec conference held in the Reddit NYC office. We also had a presentation about existing and upcoming protections against web tracking at the Chemnitz Linux Days conference, and a talk about the latest browser-based XSS protections at OWASP AppSec ‘26 in Vienna.

Web Security & Standards

Web Application Integrity, Consistency and Transparency (WAICT): We are working on WAICT, a new proposal to bring stronger integrity and transparency guarantees to web applications, helping make the web a more trustworthy platform for security-sensitive applications such as end-to-end encrypted messaging. We shared our technical vision in a Mozilla Hacks blog post, including a prototype implementation in Firefox Nightly that works with our WAICT Demo and a draft specification.

Sanitizer API: We are advancing the Sanitizer API to make robust protection against cross-site scripting (XSS) vulnerabilities more accessible. By exploring an implicit sanitizer policy that integrates with Trusted Types, we aim to prevent an entire class of XSS attacks with no application code changes, making secure-by-default web applications easier to build and deploy.

Looking Ahead

Firefox users will receive these security and privacy improvements automatically. If you’re not already a user, we recommend you give it a try. Firefox helps you shape a more personal internet that puts you back in control - all while supporting the non-profit Mozilla in its mission to keep the web open, safe, and accessible for everyone.

Thank you to everyone who contributes to making Firefox and the web more secure and privacy-focused. You can have an impact too, just by reporting bugs, conducting research, contributing code, or providing feedback.

We look forward to sharing more updates in the Q3 2026 edition.

— The Firefox Security & Privacy Teams

Am 12. Oktober 2027 beendet Microsoft für Privatanwender den erweiterten Support (den man als Extended Security Updates, ESU, bezeichnet) für Windows 10 (Version 22H2 Home, Professional, Pro Education oder Workstations Edition). Nur Unternehmenskunden bekommen gegen Bezahlung noch länger Sicherheits-Updates, und zwar bis 2028.

Das bedeutet: Nach dem 13. Oktober 2027 (nach der ursprünglichen Planung sollte bereits am 12.10.2026 Schluss sein, doch Microsoft verlängerte den Supportzeitraum für Windows 10 noch einmal) erhalten Sie als Privatanwender für Ihren Windows-10-Rechner keine Sicherheits-Updates mehr. Neu entdeckte Sicherheitslücken in Windows 10 schließt Microsoft dann grundsätzlich nicht mehr, stattdessen bleiben diese offen und können von Angreifern ausgenutzt werden.

PROMOTION

Ihr Laptop bremst Sie aus? Dieses 2-in-1 lässt Sie produktiver arbeiten

Das HP OmniBook X Flip vereint Leistung und Flexibilität: Der AMD Ryzen AI Prozessor mit dedizierter NPU liefert bis zu 50 TOPS KI-Leistung. Das 14 Zoll 2K-Touchdisplay (16:9) überzeugt mit scharfen Bildern, das Scharnier ermöglicht vier Nutzungsmodi. Dank Schnellladefunktion ist der Akku in 30 Minuten zu 50 % geladen – ideal für lange Arbeitstage unterwegs.

Erfahren Sie mehr über das HP OmniBook X Flip

Bei besonders schwerwiegenden Sicherheitslücken sind aber weiterhin Ausnahmen möglich. Denn Microsoft hatte auch schon bei älteren, eingestellten Versionen wie Windows XP und Windows 7 in seltenen Fällen noch Patches nach Supportende veröffentlicht. Doch darauf dürfen Sie sich nicht verlassen.

Sie stehen also spätestens am 13. Oktober nächsten Jahres vor der Entscheidung, ob Sie Ihren Windows-10-Rechner noch weiternutzen wollen. Diese Möglichkeiten haben Sie:

Upgrade auf Windows 11: Sicher, gratis, empfehlenswert

Für diese Zielgruppe: Ihr alter PC/Laptop läuft stabil und ist für Ihre Bedürfnisse ausreichend schnell. Sie wollen möglichst kein Geld ausgeben und trotzdem relativ sicher vor Hackern und Viren sein. Zudem möchten Sie ein aktuelles Betriebssystem nutzen.

Der einfachste Weg besteht darin, dass Sie Ihr Windows 10 auf Windows 11 upgraden. Das ist für Sie kostenlos. Einzige Hürde: Ihre Hardware muss für Windows 11 geeignet sein. Das bedeutet: TPM 2.0, Secure Boot und kompatible Prozessoren ab der 8. Intel-Generation oder vergleichbare AMD-Modelle sind in Ihrem Rechner vorhanden.

Microsoft stellt die kostenlose PC-Integritätsprüfungs-App zur Verfügung, mit der Sie unter Windows 10 testen können, ob die Aktualisierung möglich ist. Klicken Sie dazu nach dem Start des Tools auf „Jetzt überprüfen“.

Tipp: Mit einigen Tricks können Sie Windows 11 auch auf Rechnern installieren, die für Windows 11 wegen veralteter Hardware nicht geeignet sind.

Lösung: Wir erklären beide Upgrade-Wege – also für kompatible und für nichtkompatible Windows-10-Rechner – in dem Ratgeber “Windows-10-Update auf Windows 11 24H2: Wie gehts? Was kostet es?“.

Zur Installation auf Hardware, die eigentlich nicht für Windows 10 geeignet ist, können Sie zudem “Windows 11 auf jeder Hardware installieren – so geht´s” lesen. Einen umfassenden Überblick zur Upgrade-Thematik bietet zudem unser Ratgeber “Windows-10-Nutzer aufgepasst: Das müssen Sie jetzt tun“.

Übrigens: Sollten Sie Windows 11 Home im Einsatz haben, dann entgehen Ihnen die vielen Vorteile der Pro-Version, die wir Ihnen hier vorstellen. Im PC-WELT Software-Shop ist das Windows-11-Upgrade für 59,99 Euro statt 145 Euro erhältlich.

Neuen Windows-11-Rechner kaufen: Sicher, teuer, empfehlenswert

Für diese Zielgruppe: Ihr alter PC/Laptop hat bereits Macken, stürzt ab oder ist zu langsam. Sie benötigen ohnehin neue Hardware.

In diesem Fall ist der Kauf eines neuen Rechners oder Laptops ganz klar die beste Wahl für Sie. Damit machen Sie nichts falsch, allerdings müssen Sie dafür Geld in die Hand nehmen.

• Die besten Mini-PCs im Test – für Büro, Streaming, Gaming und Server
• Die besten Mini-PCs bis 800 Euro im Test: Viel Leistung auf kleinstem Raum
• Die besten Notebooks aller Klassen im Vergleich
• Das sind die besten PCs fürs Büro und Homeoffice

Wechsel zu Linux: Sicher, kostenlos, aufwendig

Für diese Zielgruppe: Ihr alter PC/Laptop läuft stabil und ist für Ihre Bedürfnisse ausreichend schnell. Sie wollen möglichst kein Geld ausgeben und trotzdem relativ sicher vor Hackern und Viren sein. Und Sie benötigen Windows nicht zwingend für bestimmte Anwendungen oder Spiele.

Sie müssen sich in das neue Betriebssystem allerdings einarbeiten und neue Programme kennenlernen. Das kostet Zeit und vermutlich auch etwas Nerven. Der Lohn der Mühe: Sie sind endlich frei von Microsoft. So, wie es unser Kollege in “Nie mehr Windows: Dieses Tool macht Sie jetzt Microsoft-frei” beschreibt.

Lösung: In “Linux wie Windows: Welche Distribution ist am ähnlichsten?” stellen wir Ihnen zudem geeignete Linux-Distributionen vor. Außerdem empfehlen wir Ihnen den Artikel “Linux für Windows-Umsteiger: 10 Fragen & Antworten“.

Wechsel zu einem Mac: Sicher, teuer, aufwendig

Für diese Zielgruppe: Ihr alter PC/Laptop hat bereits Macken, stürzt ab oder ist zu langsam. Sie benötigen ohnehin neue Hardware und sind bereit, viel Geld auszugeben und sich in ein neues Betriebssystem einzuarbeiten.

Lösung: iMacs und Macbooks sind leistungsfähig und sicher, bekommen lange Updates und sind langlebig. Sie sind aber auch teuer, wobei das Macbook Neo jetzt einen vergleichsweise preiswerten Einstieg ermöglicht, siehe “Das Macbook Neo für 700 Euro ist Microsofts schlimmster Albtraum“.

Wechsel zu einem Chromebook oder Googlebook: Sicher, günstig, bedingt empfehlenswert

Für diese Zielgruppe: Ihre alte Hardware läuft nicht mehr rund und Sie benötigen einen Laptop nur für wenig rechenintensive Aufgaben wie Surfen, Social Media, Streaming oder Office-Arbeiten. Sie wollen wenig Geld ausgeben und vergleichsweise sicher unterwegs sein. Sie arbeiten ohnehin immer schon durchgehend online.

Lösung: In diesem Fall müssen Sie Ihren alten Windows-10-Laptop nicht zwingend durch ein teures Windows-11-Notebook oder ein Macbook ersetzen. Sondern können stattdessen auch ein vergleichsweise preiswertes Chromebook kaufen. Oder künftig ein Googlebook.

Chromebooks eignen sich als günstige Notebooks gut für alltägliche Aufgaben und Büroarbeiten. Dabei müssen Sie ganz auf das Ökosystem von Google vertrauen, im Gegenzug bekommen Sie viel Sicherheit vor Schadsoftware. Hier finden Sie passende Geräte: Die besten Chromebooks im Test.

Die Googlebooks sind die neueste Laptop-Familie von Google. Standardmäßig mit Gemini Intelligence und dem Magic Pointer an Bord. In “Mit den Googlebooks will Google den Laptop-Markt aufmischen: Das steckt dahinter” stellen wir Ihnen diese Geräte vor. Als Betriebssystem dient hier genauso wie bei den Chromebooks Chrome OS. Verkaufsstart soll im Herbst 2026 sein. Preise nennt Google noch keine, ebenso fehlen alle Informationen zur Hardware.

Die letzte Chance

Was aber tun, wenn man kein Geld für einen neuen Rechner hat, der alte PC aber das Upgrade auf Windows 11 wegen seiner schwachen Hardware nicht zulässt? Nun, dann bleibt theoretisch die Möglichkeit, Windows 10 weiter zu verwenden.

Windows 10 nach Oktober 2027 weiternutzen: Nicht empfehlenswert

Für diese Zielgruppe: Ihr alter PC/Laptop läuft stabil und ist für Ihre Bedürfnisse ausreichend schnell. Sie wollen oder können kein Geld ausgeben und/oder benötigen weiter Windows 10 für bestimmte Anwendungen oder Spiele. Oder Sie wollen sich nicht mehr an ein neues Betriebssystem gewöhnen.

Lösung: Beachten Sie die folgenden Hinweise

Virenscanner und Anwendungen aktuell halten

Einen Windows-10-Rechner nach dem 12.10.2027 mit dem Internet zu verbinden, ist sehr gefährlich. Falls Sie das doch tun wollen und sich der Gefahr bewusst sind, dann halten Sie unbedingt den Virenscanner und die Firewall auf dem PC immer aktuell. Aktualisieren Sie zudem immer alle Anwendungen auf dem Rechner, also beispielsweise die Browser.

Defender bleibt aktuell

Immerhin: Die vorhandenen Sicherheitsfunktionen des Betriebssystems bleiben aktiv, das gilt auch für den Malwareschutz. Sie veralten aber mit zunehmender Dauer. Der in Windows integrierte Microsoft Defender Antivirus wird aber weiterhin aktualisiert. Microsoft stellt hierfür die sogenannten „Security Intelligence Updates“ (die Datenbanken zur Erkennung neuer Viren und Malware) für alle Windows 10-Nutzer mindestens bis Oktober 2028 bereit. Dies garantiert einen grundlegenden und aktuellen Schutz vor Schadsoftware, auch wenn das Betriebssystem selbst nicht mehr gegen Schwachstellen im Code gepatcht wird.

Meiden Sie unbekannte Webseiten und Downloads

Die Firewall Ihres Routers schützt Ihren Windows-10-Rechner auch weiterhin. Gefährlich wird es aber, wenn Sie Webseiten im Browser aufrufen. Vermeiden Sie deshalb unbedingt den Besuch unbekannter Webseiten. Klicken Sie keine unbekannten Links an und seien Sie besonders vorsichtig bei Downloads – das gilt auch für Links und Dateianhänge in Mails.

Kein Online-Banking

Vermeiden Sie Einkäufe, Bezahlvorgänge und Online-Banking auf diesem Rechner.

2FA besonders wichtig

Schützen Sie alle Ihre Benutzerkonten durch die Zweifaktorauthentifizierung oder durch Passkeys. Melden Sie sich bei all Ihren wichtigen Websites mit einem zusätzlichen Code (oder Schlüssel/Passwort) an, den Sie auf Ihrem Smartphone und nicht auf Ihrem jetzt anfälligen Windows-Computer speichern. Auf diese Weise können Malware oder Hacker Ihre Konten nicht über Ihren Computer übernehmen.

Vom Internet trennen

Falls Sie Ihren Windows-10-Rechner nach Oktober 2027 weiter nutzen wollen, um darauf beispielsweise ein fest installiertes Spiel zu spielen, für das Sie keine Internetverbindung benötigen, dann trennen Sie den Rechner am besten dauerhaft vom Internet. Und stecken Sie nur solche externen Datenträger wie USB-Sticks oder Festplatten an, die Sie mit einem aktuellen Virenscanner überprüft haben.

Weitere Ratschläge für die Weiternutzung von Windows 10 lesen Sie in “Ab heute bekommt Windows 10 keine Sicherheits-Updates mehr – das müssen Sie jetzt tun“. In diesem Zusammenhang sollten Sie auch die Windows-10-ISO-Datei herunterladen.

Nutzen Sie Windows 10 in einer virtuellen Maschine: Sicher und gratis

Falls Sie Windows 10 nur gelegentlich und nur für bestimmte Zwecke benötigen, können Sie das Betriebssystem auch in einer virtuellen Maschine installieren. Auf Ihrem Rechner läuft dann beispielsweise das aktuelle Windows 11 und Windows 10 starten Sie, wenn Sie es benötigen, als Gastsystem in der virtuellen Maschine.

Updates für Windows 10 bis 2023: Sonderweg

Eine Alternative, die Sie bereits jetzt nutzen können, ist die Sicherheitslösung 0Patch. Dabei handelt es sich um ein Unternehmen, das Sicherheitsupdates für Windows 10 bis zum Jahr 2030 bereitstellt. Allerdings aktualisiert die cloudbasierte Software des Unternehmens nicht die Systemdateien von Windows 10, sondern aktiviert die Patches im Arbeitsspeicher des Rechners. Dadurch müssen diese bei jedem Start neu geladen werden.

Der Einstieg in die Software ist sogar kostenlos möglich. Wer umfassender geschützt sein will, kann die kostenpflichtige Version für 25 Euro pro Jahr zuzüglich Steuer buchen.

Windows-10-Variante mit Updates bis 2032: Nicht legal

Im Internet finden sich immer wieder Tipps, auf das Betriebssystem Windows 10 IoT Enterprise LTSC 2021 zu setzen. Dieses entspricht im Grunde genommen Windows 10 Enterprise mit allen Funktionen und erhält Updates bis 2032. Lizenzrechtlich ist der Einsatz als Büro-PC aber nicht erlaubt.

Technisch gesehen können Sie das Betriebssystem nach dem Kauf aber bis 2032 sicher einsetzen. Wie das geht, erklären wir in “Kostenlos von Windows 11 zu Windows 10 wechseln und Updates bis 2032 nutzen – so geht’s mit UpDownTool“.

Wichtig: Wie auch immer Ihre Entscheidung ausfällt, sollten Sie ein Backup Ihrer Daten auf dem alten Rechner machen. Mit O&O DiskImage ist das kein Problem.

Dieser Beitrag Vishing-Kit missbraucht Microsoft Entra Passkeys: Betreiber erbeuten unautorisierte Zugriffe erschien als erstes auf IT BOLTWISE x Artificial Intelligence.

Read more →

The post Hackers Abuse Microsoft Entra Passkey Enrollment to Hijack Enterprise Accounts appeared first on IT Security News.

This article Multiple same passkeys show up when trying to sign into a website first appeared on TheWindowsClub.com.

The post Hackers Abuse Microsoft Entra Passkey Enrollment to Hijack Enterprise Accounts appeared first on Cyber Security News.

Dieser Beitrag ATO 2026: Warum Passkeys den nächsten Angriff auf die Verifikation verschieben erschien als erstes auf IT BOLTWISE x Artificial Intelligence.

The post Singapore’s Shift to Passkeys Reveals a Password Problem appeared first on TechRepublic.

The post ExpressVPN adds passkeys on password manager, passes security audit appeared first on CyberInsider.

No exploit. No zero-day. Just a protocol that was never built to keep a secret.

That’s the uncomfortable little truth this room is built around. So let’s pull it apart.

Most of the internet’s classic protocols were designed in a more trusting era. It was a time when the people sharing a network mostly knew each other, and “someone might be listening” wasn’t the default assumption.

Those protocols still run everywhere. And many of them still send your credentials across the wire in plain text.

Protocols and Servers 2 on TryHackMe is about exactly that gap, and what closes it. It walks through three foundational attacks against network protocols, then the defenses that neutralize each one:

• Sniffing — quietly reading traffic off the wire
• Man-in-the-Middle (MITM) — sitting between two parties and tampering
• Password attacks — guessing or cracking the credentials themselves

This is a writeup of the whole room: the concepts in plain language, the commands that matter, and the task answers explained. If you’re working through it yourself, follow along.

One idea ties the entire room together: cleartext protocols are insecure by design. Everything else is a consequence of that single fact.

Part 1 — Sniffing Attacks

A sniffing attack is the simplest idea in the room: use a packet-capture tool to grab traffic as it crosses the network, then read it.

If a protocol talks in cleartext, anyone positioned to see that traffic can pull out private messages or login credentials. Nothing is encrypted before it leaves your machine.

"Isn't everything encrypted now?"

It’s tempting to think sniffing is a solved, retro problem now that TLS is everywhere. It isn’t. It stays dangerous wherever cleartext still lives:

• Internal corporate networks, where machine-to-machine traffic is often left unencrypted
• Legacy systems like old mail servers, embedded devices, and industrial control systems
• Misconfigured services where TLS is available but not strictly enforced
• IoT devices that habitually use plain protocols
• Wireless networks, where anyone in range can listen
• After a MITM attack that has successfully downgraded or stripped encryption

In real internal pentests and red-team work, sniffing is still one of the most reliable ways to harvest credentials and learn how systems actually talk to each other.

The tools

Capturing packets needs a network card and the right privileges (root on Linux, administrator on Windows). Here are the staples:

• tcpdump — lightweight open-source CLI capture tool, preinstalled on most Linux systems.
• Wireshark — the GUI standard, with powerful filtering, protocol dissection, and visualization.
• tshark — Wireshark’s command-line sibling, great for scripting.

Worth knowing too: tcpflow (reassembles TCP streams), ngrep (pattern-matching in traffic), and NetworkMiner (extracts files from captures).

Specialized credential-grabbers exist, but tcpdump and Wireshark can do the job with a little effort.

Capturing POP3 credentials with tcpdump

The classic demo: a user checks email over POP3 (port 110, cleartext).

With access to the traffic — via a wiretap, a switch’s port mirroring, ARP spoofing, a compromised host, or a successful MITM — you run this command:

sudo tcpdump port 110 -A

Breaking that down:

• sudo — packet capture needs root privileges.
• port 110 — only keep traffic to or from the POP3 server.
• -A — print packet contents as ASCII, so cleartext is human-readable.

In the capture, the login arrives across two packets and reads straight out:

… USER frank … PASS D2xc9CgD

Username frank, password D2xc9CgD, handed over in plain sight.

Wireshark gets you there even faster: type “pop” in the display filter, and only POP3 traffic remains, credentials included.

Handy tcpdump filters

+------------------------------------+-----------------------------------------------------------+
| Command                            | Purpose                                                   |
+------------------------------------+-----------------------------------------------------------+
| sudo tcpdump port 110 -A           | Capture traffic on port 110 (POP3) in readable ASCII      |
| sudo tcpdump host 10.20.30.148 -A  | Capture ASCII traffic to/from a specific host IP          |
| sudo tcpdump port 80 -A            | Capture HTTP traffic (credentials in POST data)           |
| sudo tcpdump port 21 -A            | Capture FTP traffic (cleartext credentials)               |
| sudo tcpdump -w capture.pcap       | Save raw network packets to a file for later analysis     |
| tcpdump -r capture.pcap -A         | Read and display a saved capture file in ASCII text       |
+------------------------------------+-----------------------------------------------------------+

Mitigation

Any cleartext protocol is exposed. The only requirement for the attack is a vantage point between the two parties or on the same network segment.

The core fix is encryption. This means wrapping the protocol in TLS (like HTTP to HTTPS, FTP to FTPS, or POP3 to POP3S) and replacing Telnet with SSH.

Layered on top of that:

• Network segmentation to limit who can see whose traffic
• Encrypted VLANs or tunnels for sensitive internal traffic
• 802.1X port-based authentication so unknown devices can’t connect
• Zero-trust thinking: treat every network as hostile and encrypt everything
• Monitoring for ARP spoofing and other redirection to catch sniffing in progress

Question: How do you capture only Telnet traffic with tcpdump? Answer: Telnet runs on port 23, so you add “port 23”.

Question: What is the simplest Wireshark display filter for IMAP? Answer: “imap”.

Part 2 — Man-in-the-Middle (MITM) Attacks

Sniffing is passive listening. A MITM attack is active.

The attacker slips between two parties (A and B) so that A thinks it’s talking to B, while everything actually flows through the attacker. They can read and completely alter the data.

The room’s example says it best: A asks to transfer $20, the attacker rewrites the amount mid-flight, and B acts on the tampered message.

It works whenever the protocol doesn’t verify the authenticity and integrity of each message.

Getting into the middle

To sit between two parties, an attacker has to redirect traffic through their own machine. Common routes include:

• ARP spoofing — on a local network, the attacker sends forged ARP messages tying their own MAC address to the gateway’s IP, routing traffic directly to them.
• DNS spoofing — feeding false DNS answers to send victims to attacker-controlled servers.
• Rogue access points — fake Wi-Fi setups (like “Airport_WiFi_Free”) that route every connected victim’s traffic through the attacker.
• BGP hijacking — announcing false routes at the internet’s routing layer to reroute traffic for whole organizations or regions.

The tooling

• Bettercap — the modern, actively maintained successor to Ettercap. Handles ARP/DNS spoofing, HTTP/HTTPS proxying, and is modular.
• Ettercap — the classic LAN MITM tool. It still works, but Bettercap is generally preferred today.
• mitmproxy — an interactive HTTPS proxy used for inspecting and modifying web traffic on the fly.
• Responder — Windows-focused. Abuses fallback name-resolution protocols (LLMNR, NBT-NS) that kick in when DNS fails, answering with its own IP to capture authentication hashes. A staple of internal Active Directory pentests.

MITM against encrypted traffic

Encryption raises the bar, but it isn’t a magic shield:

• SSL stripping — quietly downgrade the victim’s connection to plain HTTP while the attacker keeps an HTTPS link to the real server. This is easy to miss if the user never typed “https://” or didn’t check for the padlock icon.
• Fake certificates — present your own certificate and run two separate encrypted legs. This works if the victim blindly clicks through the browser warning or if a Certificate Authority is compromised.
• Compromised or rogue CAs — the most serious case. If an attacker controls a trusted CA, they can mint valid-looking certificates for absolutely any domain.

Modern defenses

A decade of security hardening makes MITM much harder now:

• HTTPS by default (browsers flag plain HTTP as “Not Secure”)
• HSTS (forces HTTPS and blocks stripping attacks)
• Certificate Transparency (public, auditable logs of all issued certificates)
• Certificate pinning (apps accept only specific, hardcoded keys)
• DANE (publishing certificate info in DNSSEC-signed DNS)

MITM still succeeds when users ignore certificate warnings, apps validate keys poorly, the target speaks cleartext, or legacy gear lacks modern features.

The fundamental fix remains the same: cryptography. You need authentication plus encryption/signing, which is exactly what properly implemented TLS provides.

Question 1: How many interfaces does Ettercap offer?

Answer: 3

Question 2: How many ways can you invoke Bettercap?

Answer: 3

Part 3 — TLS: The Fix for Both Attacks

Both sniffing and MITM share one cure: TLS (Transport Layer Security). This part of the room is the solution chapter.

A quick history

SSL appeared in 1994 via Netscape, with SSL 3.0 dropping in 1996 as the web grew into shopping and payments. TLS succeeded it in 1999.

Where things stand now:

• SSL 2.0 and 3.0 are deprecated and highly insecure. Never use them.
• TLS 1.0 and 1.1 were officially deprecated in 2021 and dropped by major browsers.
• TLS 1.2 (from 2008) is still widely used and secure when configured with modern ciphers.
• TLS 1.3 (from 2018) is the current standard. It features fewer algorithms, a faster handshake, and forward secrecy by default.

People still say “SSL certificate” out of habit, but in practice, everything modern uses TLS.

Where TLS sits

Cleartext application-layer protocols send data entirely in the open.

TLS adds encryption just below the application protocol, wrapping its data before it hits the network card. On the OSI model, it lives right between the transport and application layers.

Upgrading protocols with TLS

• HTTP (Port 80) upgrades to HTTPS (Port 443)
• FTP (Port 21) upgrades to FTPS (Port 990)
• SMTP (Port 25) upgrades to SMTPS (Port 465)
• POP3 (Port 110) upgrades to POP3S (Port 995)
• IMAP (Port 143) upgrades to IMAPS (Port 993)

It’s not just web and mail. DNS can be wrapped too via DoT (DNS over TLS) on port 853, or DoH (DNS over HTTPS) on port 443. Both stop eavesdroppers from seeing which sites you look up.

Implicit TLS vs STARTTLS

• Implicit TLS uses a dedicated port that is fully encrypted from the very first byte (like 443 or 993).
• STARTTLS connects in cleartext on the normal port, then issues a “STARTTLS” command to upgrade the connection in place. This is common for email setup.

Both offer encryption, but implicit TLS is highly preferred.

A MITM attacker can easily strip the STARTTLS command during negotiation and force the session to stay in cleartext if the client isn’t configured to require it.

How HTTPS works

Plain HTTP takes two steps: open a TCP connection, then send requests. HTTPS inserts a step in between:

1. Establish a standard TCP connection.
2. Establish a TLS connection (the handshake).
3. Send the HTTP requests, which are now fully encrypted.

A simplified TLS 1.2 handshake goes like this:

ClientHello (client offers its TLS versions and cipher suites) → ServerHello (server picks the parameters and sends its certificate) → Key Exchange (both derive a shared secret) → Finished (both confirm and switch to encrypted communication):

ClientHello → ServerHello → Key Exchange → Finished

Certificates and trust

HTTPS leans on certificates signed by trusted Certificate Authorities (CAs). Your browser expects a valid certificate from a trusted CA, which proves you’re talking to the real server and blocks easy MITM attempts.

A certificate shows who it was issued to, who issued it, and its validity period. An expired certificate should never be trusted.

The modern ecosystem made this nearly universal thanks to automated platforms like Let’s Encrypt, which pushed global HTTPS traffic past 95%.

Question: What is the three-letter acronym for the DNS protocol that uses TLS?

Answer: DoT (DNS over TLS)

Part 4 — SSH: Secure Remote Administration

SSH (Secure Shell) is the secure replacement for Telnet. It is the universal way to administer servers, network gear, and cloud infrastructure.

The “S” means you can confirm the server’s identity, your messages are encrypted for the intended recipient only, and any data tampering is instantly detectable.

It handles confidentiality and integrity seamlessly over port 22.

Authentication methods

• Password — The simplest method. The password rides the encrypted channel, but weak choices can still fall to brute-force attacks.
• Public key (recommended) — A private key stays on your machine, while the public key goes on the server. The server challenges you to prove you hold the private key without ever transmitting it.
• Certificate-based — An SSH CA signs user and host keys. This scales incredibly well because you don’t have to manually distribute public keys to every single server.
• MFA — Combines a traditional key or password with a one-time code for high-security environments.

Connecting

• To connect, you run:

ssh mark@MACHINE_IP

Enter the password or let your key authenticate, and you are on the remote terminal. Every single command you send runs over an encrypted channel.

Question: Connect as mark (password XBtc49AB) and find the kernel release with uname -r.

Commands: ssh mark@MACHINE_IP uname -r

Answer: 5.15.0–119-generic

Host key verification

On your very first connection, SSH shows the server’s key fingerprint and asks if you want to continue.

Ideally, you verify this fingerprint through an admin or config management before typing “yes”. It is then saved in your local known_hosts file.

If that key ever changes unexpectedly in the future, SSH throws a massive warning, a major indicator of a potential MITM attack or a reinstalled server.

Generating keys

• To create a new key pair, run:

ssh-keygen -t ed25519 -C "your_email@example.com"

The private key stays strictly on your machine and should be passphrase-protected. The public key (.pub) is safe to share. You can push it to a remote server easily using:

ssh-copy-id mark@MACHINE_IP

Useful options

+--------------------------------------------+------------------------------------------------------------+
| Command                                    | Purpose                                                    |
+--------------------------------------------+------------------------------------------------------------+
| ssh -p 2222 mark@MACHINE_IP                | Connect to a remote server running on a non-standard port   |
| ssh -i ~/.ssh/custom_key mark@MACHINE_IP   | Specify a specific private key file to use for login       |
| ssh -J bastion.example.com mark@internal   | Jump through a secure bastion host to reach an internal IP |
| ssh -L 8080:localhost:80 mark@MACHINE_IP   | Set up a local port forward to tunnel traffic through SSH  |
| ssh -D 9050 mark@MACHINE_IP                | Create a dynamic SOCKS proxy forward for traffic routing   |
| ssh mark@MACHINE_IP "cat /etc/passwd"      | Run a single, one-off command without opening a full shell |
+--------------------------------------------+------------------------------------------------------------+

Secure file transfer

• SFTP — Interactive, FTP-like file management running completely over SSH. This is the recommended choice today.
• SCP — Simple file copies over SSH. This is now deprecated by OpenSSH in favor of SFTP, though it still works on most systems.
• rsync over SSH — The best option for large or repeated transfers because it only copies the specific parts of files that changed.

To copy files via SCP:

scp mark@MACHINE_IP:/home/mark/archive.tar.gz ~/ (remote to local)

scp backup.tar.bz2 mark@MACHINE_IP:/home/mark/ (local to remote)

Quick clarifier:

SFTP runs over SSH (port 22).

FTPS is FTP-over-TLS (port 990).

They are entirely different protocols despite having similar names.

Question: Download book.txt from the remote system; what download size did scp display in KB?

Command: scp mark@MACHINE_IP:/home/mark/book.txt ~/

Answer: 415

Hardening SSH

To protect a server, you can modify its config file (/etc/ssh/sshd_config):

• Set PasswordAuthentication to “no” once public keys are established.
• Set PermitRootLogin to “no” to force users to log in with regular accounts first.
• Use AllowUsers or AllowGroups to create an explicit access whitelist.
• Change the default port to reduce automated log noise.
• Deploy fail2ban to automatically block IPs with repeated failed login attempts.

Part 5 — Password Attacks

Even with a network fully encrypted, authentication remains a primary target. Authentication is simply the act of proving your identity, like entering a password to access a service.

The three factors:

• Something you know — a password or PIN
• Something you have — a phone, hardware security key, or smart card
• Something you are — a fingerprint or facial scan

This section focuses entirely on attacking “something you know.”

Why weak passwords persist

Massive historic breaches show that old habits die hard.

The most common passwords found in modern breaches still include variations like 123456, password, qwerty, Password1, and seasonal choices like Summer2024.

Because people constantly reuse passwords across multiple sites, a single leak frequently gives attackers access to entirely unrelated corporate or personal accounts.

Types of attacks

• Guessing — using personal info like a target’s pet, birth year, or favorite sports team harvested from social media.
• Dictionary— automatically trying lists of real words and common variations.
• Brute force — systematically trying every possible characters combination. This is exhaustive, which is why password length matters so much.
• Credential stuffing — taking leaked username/password pairs from old breaches and automatically testing them against other web services.
• Password spraying — testing one or two incredibly common passwords against a massive list of user accounts to dodge lockout policies.
• Hybrid — combining dictionary words with systematic patterns, like capitalizing the first letter and adding a year to the end.

Wordlists

• The classic go-to wordlist is RockYou, located on the TryHackMe AttackBox at:

/usr/share/wordlists/rockyou.txt

Beyond that, security professionals use collections like SecLists, CrackStation lists, or custom-generated lists tailored specifically to the target’s language, region, or industry habits.

THC Hydra

Hydra is a fast network login cracker that throws wordlists at live services like FTP, POP3, IMAP, SSH, and HTTP.

The basic syntax looks like this:

hydra -l username -P wordlist.txt server service

• -l specifies a single username (-L for a text file of names)
• -P specifies a password wordlist (-p for a single password)
• server is the target IP or hostname
• service is the protocol you are targeting

Examples:

hydra -l mark -P /usr/share/wordlists/rockyou.txt MACHINE_IP ftp
hydra -l frank -P /usr/share/wordlists/rockyou.txt MACHINE_IP ssh
hydra -l lazie -P /usr/share/wordlists/rockyou.txt MACHINE_IP imap

Handy options include -s to target a non-default port, -vV for detailed verbosity, -t to adjust parallel attack threads, and -f to immediately stop execution when the first valid password is found.

Other tools

Alternative online crackers include Medusa and Ncrack.

For Windows and Active Directory environments, tools like NetExec excel at spraying credentials over SMB and LDAP.

If you manage to dump password hashes from a database, offline tools like Hashcat or John the Ripper are used because they can guess millions of combinations per second without worrying about network lag or lockouts.

Mitigation

Defending against password attacks requires a modern approach to identity management:

• Enforce length-first password policies based on NIST guidelines. Favor overall length over complex character rotation, and check new passwords against lists of known compromised credentials.
• Implement strict account lockout or throttling mechanisms to kill automated automated guessing, while remaining aware of password spraying patterns.
• Use CAPTCHAs to prevent basic bot execution on login forms.
• Deploy Multi-Factor Authentication (MFA) across all external endpoints.
• Transition toward passwordless ecosystems, utilizing passkeys (FIDO2/WebAuthn), hardware keys, or verified magic links.