Evil twins — malicious Wi-Fi hotspots that intercept user data — are back in vogue. While the threat itself is nothing new (we’ve covered it before), fake Wi-Fi incidents have recently reached new heights — literally. In a particularly interesting case from Australia, a passenger was arrested for setting up evil twins both at the airport and on board the plane during the flight.

There’s a good reason these days why passengers are more likely to use in-flight Wi-Fi: airlines are increasingly offering entertainment streamed directly to your devices rather than on the seatback screens.

Here’s how it works: after takeoff, you enable Wi-Fi on your phone, laptop or tablet, connect to the access point, open your browser, and voilà — you’re on the airline’s media portal. From there you can choose from a selection of movies, music, games, and more. And sometimes this same portal offers internet access —usually for an additional fee.

While streaming entertainment saves airlines money on installing and maintaining seatback screens, it requires more vigilance from passengers — who probably don’t expect to be targeted mid-flight. In the case mentioned above, the perpetrator carried on board a laptop and a mobile Wi-Fi hotspot with the same network name as the legitimate airline Wi-Fi.

Unsuspecting passengers, connecting to what they thought was the official network simply because its signal was stronger (the weaker, genuine one with the same name generally isn’t shown) — were then directed to a fake authentication page. This page requested an email address — and password! — or social network credentials, supposedly to sign in to the airline’s online services. According to police, the criminal intended to use this data to hijack accounts and access personal information.

The insidiousness of this kind of attack lies in the victims’ limited options: stuck on board a plane, connected to what they believe is legitimate Wi-Fi, they have just two options: (i) provide the requested information, or (ii) forgo any and all in-flight entertainment — because neither cellular networks nor other Wi-Fi access points are available during the flight. Therefore, the chances of a successful attack are… sky-high.

How to use in-flight Wi-Fi safely

Our traditional advice about using free Wi-Fi boils down to two simple tips: use 4G/5G cellular access instead of public Wi-Fi hotspots wherever possible, and when that’s not an option — protect your connection with a reliable VPN. But these don’t… quite fly at cruising altitude: cellular data is out of reach; you have to disable your VPN to connect to the in-flight portal; and even if you pay for in-flight internet access, the VPN is likely to be patchy or not work at all.

So, here’s some tailored advice for staying safe when using in-flight Wi-Fi:

Don’t connect to in-flight Wi-Fi just out of curiosity to see what’s on offer.
Come prepared. Download movies and music to your devices beforehand so as not to rely on the airline’s entertainment options. That done, you probably won’t need in-flight Wi-Fi at all.
If you still do need Wi-Fi, review the instructions in your seat pocket carefully. It should list the official Wi-Fi name and connection process.
Be wary of discrepancies. If something about the Wi-Fi connection seems off compared to the instructions, or if you’re asked to enter detailed personal information like email, passwords, passport details, or payment information, disconnect immediately and alert a flight attendant. Confirm with them whether this information is actually required to use the Wi-Fi. Show them the device screen so that they can verify the legitimacy of the connection interface.
Avoid downloading anything during the flight. Connecting to the plane’s network should never require installing apps, plugins, or certificates. If asked to install anything of the sort — disconnect immediately by enabling airplane mode.
If you connect to Wi-Fi to use the in-flight internet, try enabling your VPN as soon as the connection is established. If the VPN can’t be turned on, minimize your online activity, and never log in to sensitive services such as online banking, government websites, or email.
Keep the number of devices you connect to the in-flight Wi-Fi to a minimum — preferably no more than one.
If you do connect, before landing, make sure to go to the Wi-Fi settings and “forget” the airline network. You can then put your device in airplane mode, as required by the aviation regulations.

Kaspersky official blog – ​Read More

We spent several months researching a new and very smart crypto scam, where the victims were slowly, craftily encouraged to install a malicious crypto management app. However, the ones who got scammed were only nominally victims, because the operators, like some digital Robin Hoods, targeted… other pilferers. Take an in-depth look at this scam with us and learn how to protect your cryptocurrency.

The initial bait

It all started with my receiving a fairly trivial forwarded Telegram message about cryptocurrency. Others might have ignored it, but being the web content analysts’ team lead at Kaspersky, I smelled a rat and decided to look into it. To evade detection, the message was presented as a five-second-long video clip, which contained a screenshot showing a hasty, heavily discounted sale of two lucrative crypto projects with respective links thereto. Likely designed to give the recipient a false sense of security, the first link led to a real second-tier crypto exchange — albeit a small one. The real bait was hiding behind the other link.

A convenient server malfunction

Contrary to what could be expected, following the other link didn’t bring up any malicious content. Things were far more interesting: if you entered the address expecting to see a home page, the browser displayed a root directory listing with some enticing file names in it. It appeared as if the server had been misconfigured, or the home page accidentally had been deleted, revealing all of the unsuspecting domain owner’s data. You could click any file in the list and view its contents right in the browser, because, conveniently, all of them had common, easy-to-handle formats, such as TXT, PDF, PNG or JPG.

This made a visitor feel like they’d landed inside the personal data folder of a rich but dimwitted owner of some crypto project. The text files contained wallet details complete with seed phrases, and the images were screenshots showing proof of a large amount in cryptocurrency being successfully sent, substantial wallet balances, and the owner’s lavish lifestyle.

One of the screenshots had a YouTube video in the background, explaining how to buy yachts and Ferraris with Bitcoin. A PDF catalog of these yachts could easily be found in the same directory. In a nutshell, this was seriously juicy bait.

Real wallets and cash

What’s smart about this scam is that the wallet details are real, and one indeed can access the wallets and view, say, the Exodus transaction history or the assets in the other wallets, worth nearly 150,000 US dollars, according to DeBank.

You wouldn’t be able to withdraw anything, though, as the funds are staked — that is, basically tied up in the account. Nonetheless, this makes the visitor far less skeptical: the whole thing seems to be someone’s carelessly leaked real data, not spam or phishing. Besides, there are no external links or malicious files to be seen anywhere — nothing to be suspicious about!

We monitored the site for two months, seeing no changes whatsoever. The scammers seemed to be waiting for a critical mass of interested users to build up while tracking their behavior with web server analytics. It was only after this lengthy warm-up period that they proceeded to the next stage of the attack.

A new hope

The dramatic two-month pause was at last ended with an update: a fresh Telegram screenshot purportedly showing a successful Monero payout. If one took a closer look at the screenshot, one would notice an “Electrum-XMR” wallet app with a transaction log and a sizable balance of almost 6000 Monero tokens (XMR), worth about a million dollars at the time of publishing this.

By a lucky coincidence, a new text file with the seed phrase for the wallet popped up right next to the screenshot.

At this point, anyone dishonest enough rushed to download an Electrum wallet to log in to the careless dupe’s account and grab the remaining money. Tough luck: Electrum only supports Bitcoin, not Monero, and it takes a private key (and not a seed phrase) to regain access to an account. When attempting to restore the key from the seed phrase, every legitimate converter said the seed phrase format was invalid.

Yet greed was clouding the users’ judgment: after all, there was a million dollars at stake, and they needed to hurry before someone else stole it. The fast-buck artists went googling “Electrum XMR” or simply “Electrum Monero”. Whichever it was, the top result was a website ostensibly about an Electrum fork that supported Monero.

Its design resembled that of the original Electrum website, and, in typical open-source fashion, it featured all kinds of descriptions, links to GitHub (the original Electrum repository, though — not Electrum-XMR), a note that explicitly said this was a fork to support Monero, and handy direct links to macOS, Windows and Linux installers.

Which is when the hunter unwittingly becomes the prey. Downloading and installing Electrum-XMR infects the computer with malware identified by Kaspersky as Backdoor.OLE2.RA-Based.a, which provides attackers with covert remote access. What they do next is probably scanning the contents of the machine and stealing crypto wallet data and any other valuable information.

Our security solution would have blocked the malicious website, let alone an attempt to the install the Trojan, but crypto hunters eager to lay their hands on other people’s money are hardly among our users.

All of a sudden, a second iteration

Some time later, when we were done investigating this feat of social engineering, we received another bit of bait, which was hardly a surprise. This time around, the scammers switched from slow steaming to searing. The screenshot showed a fake wallet with a large balance next to an open text file containing a wealth of personal information and a thoughtfully added link to a malicious site. It looks like this scam has apparently proved to work well, and we’re in for lots of similar attacks.

Recognizing the attack

Victims of the scam we discussed above evoke no sympathy at all, seeing how they took the bait by trying to steal other people’s money. However, the scammers keep coming up with new tricks, and next time, you might be offered an ostensibly ethical way of making money. For example, you might accidentally get a screenshot advertising a lucrative airdrop, with the link right in the address bar…

So, stay alert, and take any information with a large pinch of salt. Each stage in the attack was suspicious in its own way. The website sale ad was presented in the form of a video clip with a screenshot, obviously to get around anti-spam algorithms. A website that contains nothing but unencrypted text files with crypto wallet data in these looks too good to be true. The domain purportedly hosting the crypto wallet fork had been registered just two months before the attack. Most importantly, however, the scam-filled crypto landscape makes using little-known wallet apps an unacceptable risk. Thus, follow these steps:

Use only major, tried-and-true crypto wallet apps and exchange websites.
Carefully check that you’re signing in only through official sites and downloading apps from the right sources.
Read our tips for spotting online scammers.
Use comprehensive computer and smartphone protection that’ll keep you from going to phishing sites or running malware.
Subscribe to our blog and/or Telegram channel to be the first to learn about new threats.

Kaspersky official blog – ​Read More

According to Microsoft, the blue screen incident caused by a CrowdStrike Falcon security solution update affected more than 8.5 million computers worldwide. This incident has cost many companies dearly, and has also brought up a lot of debate about how to prevent similar situations from happening again.

First of all, no one is immune to errors; it’s simply impossible to guarantee the complete absence of bugs in complex software systems. However, a properly structured process for developing, testing, and delivering products and their updates to users’ devices can significantly minimize the risk of a serious failure. And we’ve had such a process firmly in place for years.

We, too, had incidents directly related to updates for our products. But the last time we had a notable problem of the kind was back way in 2013. After that unpleasant episode, we conducted a thorough analysis of the root causes — leading to a complete overhaul of our approach to the creation and testing of updates both in products for business and home users. And the system we built has proven itself to be very reliable: in 11 years we’ve not had a single failure of a similar magnitude.

We make no secret of the update release mechanisms we’ve built, and are ready to share them with the industry. After all, without the free exchange of best practices and solutions developed by different companies, progress in the cybersecurity industry will be hindered greatly. Among the main update release safeguarding mechanisms are multi-level testing, gradual rollout of updates, and automatic monitoring of anomalies. Let’s talk about them in detail.

Multi-level testing

There are two types of updates for our products — some are used for adding new detection logic, and some are for changing the functionality of a given product. Adding new functions potentially adds more risks, but sometimes logic updates can cause problems as well. Therefore, we carefully test both types of updates at different stages.

Checking for false positives

When creating and releasing detection rules (both those automatically generated and those written by analysts), we test them on an extensive database of legitimate (or “clean”) objects — files, web pages, behavior patterns, and so on. This way, false positives are identified and filtered out. We’ve an extensive and constantly updated collection of legitimate objects — both software and clean web resources — on which all created rules are tested.

One of the ways this collection is replenished is through our Allowlist Program, which allows software developers (both customers that develop and use their own solutions and independent vendors) to provide us with their software. This reduces the number of potential false positives and the risk of incorrect software classification.

Other methods for obtaining files and metadata include exchanging information with technological partners, using our Threat Intelligence Portal, and so on. In total, our database of legitimate objects contains information on around 7.2 billion objects.

Testing on virtual machines

But update testing isn’t limited to checking them on file collections. If no problems are detected at the first stage, all updated components then undergo multi-stage automatic testing on virtual machines with various configurations of security products, software and operating systems. Various scenarios are run related to our products and the operation of security mechanisms and also the imitation of typical user actions.

Regarding specifically product scenarios, these include a through file system scan, the process of the product update’s installation, rebooting after the update, and so on. This allows us to make sure that the product functions normally after the update, and neither crashes nor affects system stability. Each update goes through this check.

User scenarios simulate typical human behavior on a computer — opening a browser, visiting a web page, downloading a file, launching a program. This check allows us to make sure the product doesn’t have a negative impact on the computer’s performance, speed of work or stability.

Separately, updates are automatically tested for compatibility with industrial software (for example, SCADA systems). Any negative impact on solutions related to this sphere may lead to an inadmissible halt in production processes and potential financial damage.

Quality control

In addition to the above-mentioned checks, we also have a separate quality control team. Not a single product update release is delivered to our clients without confirmation of its readiness by its experts. It also, if necessary, adjusts and constantly improves the verification processes, and monitors the emergence of possible operational risks.

Phased release of updates of protective technologies

Of course, we are realists, and admit that this entire multi-level system of checks may still not be enough. For example, some third-party software will be updated at the same time as ours, and this may cause an unforeseen conflict. And in general, it’s impossible to predict all combinations of configurations of different programs and systems. Therefore, after an update affecting the functionality of security solutions is ready and approved, it doesn’t get sent to all our users’ computers at once. Instead, the updates are released in phases.

An update undergoes preliminary testing on machines in our own network before being published on public update servers. If no problems are detected, the update is first received by a very small number of randomly selected users. If no problems or failures are manifested, then the number of computers that receive the update gradually increases at certain intervals, and so on until the update is available to all users.

Automatic anomaly monitoring

So what happens if an update does cause problems? We monitor the behavior of updated solutions using voluntarily transmitted anonymized data through our KSN, and promptly halt update distribution if something goes wrong.

But most importantly, thanks to the combination of automatic anomaly monitoring and phased release of updates, an error would affect only a very small number of computers — hundreds, not millions or even thousands of them.

Testing updates on the client side

Our company provides the ability to check the received updates once again, only this time on the client side through the Kaspersky Security Center management console.

The client’s system administrators can establish an isolated test group of computers (or virtual machines) with the most common configuration and set of software for the organization’s network, and then create a task to check updates — specifying this test group as the target. In this case all incoming updates are first installed only on test machines, tested in action, and only after the test are they distributed across the entire company network. More information on how to set up such a check can be found on our technical support website.

We thoroughly analyze each and every problem related to software updates that may arise (including those identified in preliminary tests), come to understand the reasons for their occurrence, and then take measures to ensure they don’t happen again. In addition, we’ve implemented a practice of proactively identifying and assessing the risks for possible problems, and address them systematically. As a result of doing this throughout the entire lifetime of our company, we’ve established a multi-level system that allows us to significantly reduce the risk of new problems emerging.

Of course, in just one blog post it’s impossible to tell you everything about all the nuances of our multi-level system for checking product updates. However, if this topic arouses interest in the industry, we’re ready to continue sharing details. Only open cooperation of all players in the information security sphere can create an effective barrier to the actions of cybercriminals.

Kaspersky official blog – ​Read More

It’s been a month already since the US Department of Commerce issued its Final Determination with regard to the sales and use of Kaspersky products by US persons. The agency’s decision, if you happen not to be aware of it, in general terms was to ban Kaspersky products – with a few exceptions for informational and educational products and services – from the market. The outcome is the following: users in the US can no longer access the cybersecurity software they choose based on quality and expertise.

Throughout its 27-year history, our company has always been recognized as supplying the best protection on the market from all kinds of cyberthreats – no matter where they come from. Here are a few examples: earlier this year our products once again received the Product of the Year award from a renowned independent testing lab; from year to year our solutions have been demonstrating 100% protection against the most significant threat – ransomware; and it’s Kaspersky’s threat research team – respected both by the global InfoSec community and our users – that discovers, analyzes, and most importantly reveals to the world the biggest and most sophisticated state-sponsored espionage campaigns.

So, what might be the reason for banning best-in-class cybersecurity solutions trusted by millions? Has the problem been defined clearly and objectively? Have you seen any evidence of those risks that the US government has been referring to for years? We haven’t either.

While having to deal with the outcomes of growing protectionism (and its hard-hitting effects) – like zero-evidence claims of misconduct, and accusations based purely on theoretical risks – we’ve been continuously developing a universal methodology for cybersecurity product assessment, while remaining ever true to our key principle: being maximally transparent and open about how we do our work.

We became the first and remain the only major cybersecurity company to provide third parties with access to our source code, and we also allow our stakeholders and trusted partners to check our threat-detection rules and software updates in an unparalleled goodwill gesture. For several years already we’ve had our Global Transparency Initiative in place – unique in its scope and practical value – which once again reflects our cooperative attitude and determination to address any potential concerns regarding how our solutions work. Nevertheless, we still faced apprehensiveness regarding the reliability of our products – usually stemming from external factors like geopolitical conjecture – and so we went the extra mile by suggesting an even more thorough framework, which would assess the integrity of our security solutions throughout their lifecycle.

What I’ll be describing below is a framework we’ve been proactively sharing with the parties expressing concerns about the credibility of Kaspersky solutions – including those in the United States government. We believe the framework is comprehensive enough to address the most commonly expressed concerns, and is capable of forming a dependable chain of trust.

The key pillars of the cybersecurity assessment methodology we’ve been presenting (which, incidentally, we believe has the potential to form the basis of an industry-wide methodology) include: (i) the localization of data processing, (ii) the review of data received, and (iii) the review of both the information and updates delivered to user machines (as part of software and threat-database updates). Just as within our Global Transparency Initiative, the strategy’s core aim is the engagement of an external reviewer for checking the company’s processes and solutions. What, however, is new about this methodology is both the extent and depth of such reviews. Let’s look into the details…

Data processing localization

The matter of data processing and storage has been one of the most sensitive, not only for Kaspersky, but for the entire cybersecurity industry. We frequently get reasonable questions about what data our products can process, how this data is stored and, most fundamentally, why we need this data. The key purpose of data processing for Kaspersky is providing our users and customers with the very best cybersecurity solutions: by gathering data on malicious and suspicious files that we detect on user machines, we can train our algorithms – teaching them how to detect new threats and contain their spread.

The framework we’ve been presenting also implies greater localization of data processing infrastructure, and implementation of technical and administrative controls restricting access to such processing infrastructure for employees outside a given country or region. We already implement such an approach in delivering our Managed Detection and Response (MDR) service in Saudi Arabia, and the same mechanisms have been suggested in our discussions with the US authorities to alleviate their concerns. These measures would ensure that local data is both stored and processed in a physical environment where ultimate control over the data rests with persons under the local jurisdiction, or that of a closely allied country as deemed appropriate by these persons. Just as with the above-mentioned steps, an independent third-party validator might be invited to review the effectiveness of the measures implemented.

Local data processing requires local threat analysis and the development of local malware detection signatures, and our methodology provides for just that. Data processing localization requires expansion of human resources to support local infrastructure, and we’re prepared to further build up our regional R&D and IT teams in given countries. Such teams would be exclusively responsible for supporting the processing of domestic data, managing local data center software, and analyzing malware to identify new APTs specific to the given region. This measure would also ensure there are more international experts involved in the development of future Kaspersky product lines – making our R&D even more decentralized.

Data retrieval process review

We protect the data we gather against potential risks using rigorous internal policies, practices, and controls; we never attribute data gathered to a specific individual or organization, we anonymize it wherever possible, and we also limit access to such data within the company and process 99% of it automatically.

To further mitigate any potential risks to the data of our customers, we’ve suggested engaging a third-party authorized reviewer to periodically review our data retrieval process. Such a real time reviewer would periodically assess data we receive with data analytics tools and data processing platforms to make sure no personally identifiable information or other protected data is being transferred to Kaspersky, and to confirm that data retrieved is used solely for the detection of and protection against threats, and is appropriately handled.

Review of updates and data delivered to user machines

As a next step on the product side, the mitigation framework would be provided for regular third-party reviews of our threat-database updates and product-related software code development to mitigate supply-chain risks for our customers. Importantly, the third-party would be an independent organization reporting directly to a local regulator. This would be on top of Kaspersky’s existing rigorous and secure software development process, which focuses on mitigating risks – including a scenario where there’s an intruder in the system – to ensure no one can add unauthorized code to our products or AV databases.

But to further enhance security guarantees, the engagement of an external real-time reviewer is intended to assess the security of the code developed by Kaspersky engineers, suggest improvements, identify potential risks, and then determine appropriate solutions.

One of the scenarios of how such a check of threat-database updates can be organized is depicted below:

It’s important to emphasize that the third-party review can be either blocking or non-blocking, conducted either on a regular basis or once a critical mass of updates/components for review is accumulated, as well as applied to all or just a selection of components. The most advanced review option proposed involves real-time blocking – enabling reviewers to fully control the code delivered to user machines. A blocking review would stop any code during the review process from getting into a product or updates – and therefore to Kaspersky’s customers.

This comprehensive review process could be further enhanced by requiring the reviewer’s signature on all updates delivered to user machines after the underlying code has been confirmed and built. This would ensure that the code wasn’t altered after being reviewed in real time.

The proposed review not only enables real-time verification of the security of newly developed code, but also provides access to the entire source code – including its history. This allows the reviewer to fully assess the newly developed code, understand its changes over time, and see how it interacts with other product components.

Such an absolute code review would also be accompanied with access to a copy of the company’s software build environment, which mirrors the one used in Kaspersky – including compilation instructions and scripts, detailed design documentation, and technical descriptions of the processes and infrastructure. Hence, the real-time reviewer could build/compile code independently and compare binaries and/or intermediate build objects to shipped versions. The reviewer would also be able to verify build infrastructure and software for changes.

In addition, a trusted independent third-party could be provided with access to the company’s software development practices. Such independent analysis would aim to provide further guarantees that Kaspersky’s applied measures and processes match leading industry practices. The access would cover all relevant security documentation – including but not limited to: defining security requirements, threat modeling, code review, static and dynamic code verification, penetration testing, etc.

The bottom line is that, in our judgement, the aforesaid strategy can address most ICT supply-chain risks relating to product development and distribution in an effective and verifiable manner. And as I mention above, these are in fact the mitigation measures we’ve submitted in a proposal for discussion to the US Department of Commerce – once again confirming our openness to dialogue and determination to provide the ultimate level of security assurances. However, our proposal was simply ignored. This leads me to believe that the reason is based on the Department’s preconceived ideas. It seems that instead of assessing our proposal for its effectiveness in addressing the risks, it was examined to find an excuse to reject it.

While we have to admit that once again we’re having to deal with an act of digital protectionism, I know for a fact that the world is in acute need of a global cybersecurity risk-management strategy. It’s crucial to be able to address the evolving threat landscape effectively and ensure a unified approach to managing cybersecurity risks across diverse IT security domains. This approach could also help prevent short-sighted decisions depriving millions of users of their freedom of choice regarding credible cybersecurity protection and the creation of artificial restrictions on the exchange of data among cybersecurity professionals. Let’s allow these experts to focus on their important work without the additional burden of geopolitics – whose influence only benefits cybercriminals.

In an interconnected world where cyberthreats transcend borders, a global strategy is vital for bolstering cybersecurity defenses, enhancing trust, and promoting a more secure digital ecosystem. Our framework opens the door to a discussion within the industry about what a universal supply-chain cybersecurity assessment should look like – with the ultimate goal of building a reliable shield of trust and, consequently, a safer world.

And finally, for those seeking answers regarding the drastic new limitations on their freedom of choice, don’t forget that you can – and should – still have your say, by asking your questions directly, here.

Kaspersky official blog – ​Read More

Throughout May and June, the IT world watched the unfolding drama of Copilot+ Recall. First came Microsoft’s announcement of the “memory” feature named Recall that takes screenshots of everything happening on a computer every few seconds and extracting all useful information into a shared database. Then, cybersecurity researchers criticized Recall’s implementation by exposing security flaws and demonstrating the potential for data exfiltration — including of the remote kind. This forced Microsoft to backpedal: first stating the feature wouldn’t be enabled by default and promising improved encryption, and then delaying the mass rollout of Recall entirely — opting to first test it in the Windows Insider Program beta. Despite this setback, Redmond remains committed to the project and plans to launch it on a broad range of computers — including those with AMD and Intel CPUs.

Within the context of devices in the workplace — especially if a company allows BYOD — Recall clearly violates corporate data retention policies and significantly amplifies potential damage if a network is compromised by infostealers or ransomware. What’s more concerning is the clear intention of Microsoft’s competitors to follow this trend. The recently announced Apple Intelligence is still shrouded in marketing language, but the company claims that Siri will have “onscreen awareness” when processing requests, and text-handling tools available across all apps will be capable of both local or ChatGPT-powered processing. While Google’s equivalent features remain under wraps, the company has confirmed that Project Astra — the visual assistant announced at Google I/O —  will eventually find its way onto Chromebooks, utilizing screenshots as the input data stream. How should IT and cybersecurity teams prepare for this deluge of AI-powered features?

Risks of visual assistants

We previously discussed how to mitigate the risks of unchecked ChatGPT and other AI assistants’ usage by employees in this article. However, there we focused on the deliberate adoption of additional apps and services by employees themselves — a new and troublesome breed of shadow IT. OS-level assistants present a more complex challenge:

The assistant can take screenshots, recognize text on them, and store any information displayed on an employee’s screen — either locally or in a public cloud. This occurs regardless of the information’s sensitivity, current authentication status, or work context. For instance, an AI assistant could create a local, or even cloud-based, copy of an encrypted email requiring a password.
Captured data might not adhere to corporate data-retention policies; data requiring encryption might be stored without it; data scheduled for deletion might persist in an unaccounted copy; data meant to remain inside the company’s perimeter might end up in a cloud — potentially under an unknown jurisdiction.
The problem of unauthorized access is exacerbated since AI assistants might bypass additional authentication measures implemented for sensitive services within an organization. (Roughly speaking, if you need to view financial transaction data, even after being authorized in the system you need to enable RDP, raise a certificate, log in to the remote system, and enter the password again — or you could simply view it through an AI assistant such as Recall.)
Control over the AI assistant by the user and even IT administrators is limited. Accidental or deliberate activation of additional OS functions at the manufacturer’s command is a known issue. Essentially, Recall, or a similar feature, could appear on a computer unexpectedly and without warning as part of an update.

Although all the tech giants are claiming to be paying close attention to AI security, the practical implementation of security measures must stand the test of reality. Microsoft’s initial claims about data being processed locally and stored in encrypted form proved inaccurate, as the encryption in question was in fact a simple BitLocker, which effectively only protects data when the computer is turned off. Now we have to wait for cybersecurity professionals to assess Microsoft’s updated encryption and whatever Apple eventually releases. Apple claims that some information is processed locally, some within their own cloud using secure computing principles without storing data post-processing, and some — transmitted to OpenAI in anonymized form. While Google’s approach remains to be seen, the company’s track record speaks for itself.

AI assistant implementation policies

Considering the substantial risks and overall lack of maturity in this domain, a conservative strategy is recommended for deploying visual AI assistants:

Collaboratively determine (involving IT, cybersecurity, and business teams) which employee workflows would benefit significantly from visual AI assistants to justify the introduction of additional risks.
Establish a company policy and inform employees that the use of system-level visual AI assistants is prohibited. Grant exceptions on a case-by-case basis for specific uses.
Take measures to block the spontaneous activation of visual AI. Utilize Microsoft group policies and block the execution of AI applications at the EDR or EMM/UEM level. Keep in mind that older computers might not be able to run AI components due to technical limitations, but manufacturers are working to expand their reach to previous system versions.
Ensure that security policies and tools are applied to all devices used by employees for work — including personal computers.
If the first-stage discussion identifies a group of employees that could significantly benefit from visual AI, launch a pilot program with just a few of these employees. IT and cybersecurity teams should develop recommended visual assistant settings tailored to employee roles and company policies. In addition to configuring the assistant, implement enhanced security measures (such as strict user authentication policies and more stringent SIEM and EDR monitoring settings) to prevent data leaks and protect the pilot computers from unwanted/malicious software. Ensure that the available AI assistant is activated by an administrator using these specific settings.
Regularly and thoroughly analyze the pilot program’s group performance compared to a control group, along with the behavior of company computers with the AI assistant activated. Based on this analysis, decide whether to expand or discontinue the pilot program.
Appoint a dedicated resource to monitor cybersecurity research and threat intelligence regarding attacks targeting visual AI assistants and their stored data. This will allow for timely policy adjustments as this technology evolves.

Kaspersky official blog – ​Read More