Agregátor RSS

As intelligent systems move into production environments and begin taking actions, organizations quickly discover that accountability becomes much harder. Unlike traditional enterprise software, these tools can produce unpredictable outcomes as they interact dynamically with data, APIs, and business workflows.

“When something goes wrong with AI, it is generally assigned to whoever was closest to the pain point,” says David DuChene, manager of data and AI pre-sales at SHI International, which works with enterprises on AI deployments and governance.

As these systems shift from advisor to actor within workflows, accountability becomes harder to enforce through policies alone. IT leaders must build it directly into the fabric of their operations through clear ownership, continuous observability, defined escalation paths, and infrastructure designed to make responsibility visible when things go wrong.

Here are six ways to make AI accountability enforceable in production.

1. Assign direct ownership from the beginning

Many enterprises still view AI accountability as a shared responsibility, but some experts argue that this is the first assumption to fail when systems enter production.

“Shared accountability is not accountability,” says Joe Wilson, SVP and CIO of CSG, a customer experience, billing, and payments software provider. “You need a direct owner.”

He says that at CSG, AI initiatives go through governance reviews involving executive leadership, and direct ownership is assigned at the start of projects. Wilson, who oversees the AI governance and deployment strategy for CSG, says the company also created “CIO reps” embedded inside business units and product groups to ensure accountability spans the entire lifecycle of AI initiatives.

According to SHI’s DuChene, many enterprises still lack formalized accountability structures for those environments. “They may have responsible parties on paper, but once a system actually breaks down, everything gets relitigated,” he says. “It goes back to who’s closest to the pain point.”

One diagnostic question, he argues, reveals whether organizations are truly prepared: “If your AI deployment generates a wrong answer and costs the business money tomorrow, who’s going to write the postmortem?”

If leaders cannot answer that question quickly, accountability structures likely don’t yet exist in practice.

2. Build governance before scaling deployments

In the past few years, many enterprises deployed AI systems before establishing the governance and operational foundations necessary to support them safely. “The biggest gap we see is a sequencing problem,” says DuChene. “We’ve gone around and built a bunch of houses where we’re standing up the walls before we’re pouring the foundations.”

That sequencing problem creates expensive retrofitting efforts later. DuChene says teams frequently discover they lack data classification systems, AI-aware identity and access controls, lineage and provenance tracking, audit capabilities, and escalation channels for failures.

According to Seth Dobrin, CEO of deterministic AI model maker Arya Labs and former global AI leader at IBM, governance often fails because organizations treat it as a policy layer rather than something embedded directly into operational workflows. “How do you integrate it into the workflow?” he asks. “If you don’t get that right, it’s going to fall apart.”

Dobrin recalls working with an insurance company that spent 18 months building an intelligent system before legal teams blocked deployment entirely. The problem was not the technology itself, but the absence of governance early in the process. “They had to throw it away,” Dobrin says. “Had they started earlier, they would have steered it to a place where they could have gotten to yes.”

Dobrin says governance should not slow projects down. Instead it should be integrated deeply enough into workflows that teams can move quickly without downstream compliance or operational failures. “The objective should never be to say no,” he says. “It should always be to figure out how to say yes.”

Wilson at CSG makes a similar point, arguing that governance should help teams absorb complexity rather than simply restrict what they can do. He compares it to a vehicle suspension system rather than a braking mechanism. “Our intention is not to slow things down,” he says. “Our intention is to speed stuff up, but also when you get into rough terrain, to be able to navigate that terrain.”

3. Treat data governance as the foundation of accountability

According to Wilson, CSG focused on governing its data before scaling AI initiatives across the business. Those efforts started with data synchronization and privacy impact assessments.

“The foundation is data,” Wilson says. “If we don’t have clean, synchronized, and governed data across the board, we’re not going to win this battle.”

Many organizations underestimate how difficult it becomes to maintain accountability once AI systems begin interacting with fragmented enterprise data environments, says Quais Taraki, CTO of EnterpriseDB, a company that works with enterprises on data infrastructure and governance.

An AI assistant summarizing customer interactions, for example, may pull regulated or confidential data from systems that were never intended to feed generative AI tools.

Strong data governance practices — including lineage, provenance tracking, classification systems, and access controls — not only help head off such problems but also create the foundation for accountability when something does go wrong. Otherwise, teams struggle to determine what data an AI system accessed, how outputs were generated, and whether sensitive information influenced a decision.

“Without lineage and provenance, you can’t do root-cause analysis,” Taraki says. “You won’t know what to change, or how things mutated in ways you didn’t expect.”

Taraki argues that accountability should follow governed data products rather than organizational silos. When ownership is split across infrastructure teams, data scientists, and application developers, responsibility can become difficult to establish after failures occur. Assigning clear ownership to the data products that feed AI systems helps create accountability throughout the AI lifecycle.

4. Build observability into (and beyond) AI systems

Traditional enterprise monitoring systems were designed primarily to track uptime, infrastructure health, and application performance. AI introduces a different challenge: tracing reasoning paths, decision chains, and behavioral drift.

Nik Kale, a member of the Coalition for Secure AI (CoSAI) and participant in AI security and agent identity standards efforts, describes this through what he calls an “Investigation Graph.” This is a reasoning trail showing what an AI system observed, what tools it accessed, what conclusions it reached, and what actions it ultimately took.

“When something breaks, the first instinct is always to ask, ‘Why did the AI make that decision?’” Kale says. “Honestly, I think that’s the wrong question. The right question is, ‘What did the system actually do?’”

That distinction is increasingly important because AI failures rarely originate from a model alone. Instead, they emerge from interactions between models, credentials, APIs, workflows, policies, and downstream systems.

“The model didn’t act,” Kale says. “The system around the model acted.”

That broader view of accountability is also changing how IT leaders think about observability. Rather than monitoring AI models in isolation, enterprises increasingly need visibility across the systems those models interact with, including data sources, APIs, applications, security controls, and downstream workflows.

In practice, that starts with comprehensive logging of prompts, model outputs, tool calls, data access events, and agent actions. Combined with traditional application and infrastructure telemetry, those logs create an auditable record of how AI systems behaved and why decisions were made.

That visibility becomes especially important when IT leaders try to identify unauthorized AI usage. While governance policies define which tools employees should use, observability helps reveal which tools they are actually using. Unusual data access patterns, unexpected API calls, traffic to external AI services, and unexplained movement of sensitive data can all be indicators of shadow AI.

Even well-governed organizations can struggle when employees adopt unauthorized AI tools outside approved workflows. “If it’s shadow IT, we don’t even know it exists,” says DuChene. “We don’t know what data of ours is going into it, how it’s being used, or how it’s being distributed.”

By extending observability beyond AI models to the broader enterprise environment, IT can detect those activities earlier, investigate them more quickly, and reduce the accountability gaps that shadow AI creates.

5. Create ‘escalate’ and ‘stop’ mechanisms

The most important accountability question may not be what an AI system can see or do, but when it should stop and ask for help.

According to Kale, that’s often the most underdeveloped part of enterprise AI deployments. “Most enterprises have figured out how to monitor their AI systems,” he says. “But nobody has really built the third piece, which is, when does the system actually stop and ask for help?”

Kale argues that enterprises need explicit escalation paths, human decision points, and clearly defined stop mechanisms for systems operating in production.

“You don’t want a rubber stamp — you want a human in the loop,” he says, adding that the human should be named and have the authority to say no.

According to Wilson, incident response processes also need to evolve, because AI failures behave differently from traditional IT outages. “A traditional IT incident typically looks like it’s an up or down scenario,” he says. “AI failures are a little more subtle than that.”

Models may drift gradually, outputs may degrade over time, or workflows may begin producing unexpected results without systems technically failing. The result, says Wilson, is a growing need for multidisciplinary response processes involving legal, communications, security, audit, business teams, and IT operations simultaneously.

6. Treat AI systems more like workers than software

Some enterprises still govern AI like traditional applications. But according to Kale, AI systems behave more like workers and less like deterministic software.

“You cannot just deploy once and be done,” he says. “Like workers, they need ongoing oversight.”

That ongoing oversight is becoming a core accountability function. Employees are not hired, trained, and then left unsupervised indefinitely. Managers monitor performance, provide feedback, evaluate changing responsibilities, and intervene when behavior drifts from expectations. Kale argues that AI systems increasingly require similar treatment.

Traditional software can often be reviewed and approved at release time because its behavior remains relatively stable between versions. AI systems are different. Models evolve, prompts change, retrieval systems are updated, and the information available to agents changes continuously.

That challenge extends beyond internally developed systems. Enterprises must also monitor the third-party AI services they rely on. Not only do vendor models evolve on their own, but vendors also update software and capabilities behind the scenes.

“The vendor we approved last quarter is functionally a different vendor this quarter,” Kale says.

As a result, accountability cannot end when a system is deployed. Someone must remain responsible for monitoring performance, reviewing changes, assessing risk, and determining whether systems continue to operate within acceptable boundaries. Kale points to CoSAI’s AI Shared Responsibility Framework as one emerging effort to clarify those responsibilities across enterprises, software vendors, model providers, and infrastructure operators.

The organizations making the most progress are discovering that accountability cannot be assigned on paper and forgotten. As AI systems become more autonomous, accountability is becoming an operational capability built into data governance, observability, escalation processes, and ongoing oversight. For IT leaders, the challenge is no longer defining responsibility. It is making responsibility enforceable.

Related reading:

• CIOs plagued by growing AI accountability gap
• AI is spreading decision-making, but not accountability
• Who authorized the AI agent? Breaking the blame loop in agentic AI
• Why AI adoption keeps outrunning governance — and what to do about it
• 5 ways to curb AI sprawl without stifling innovation

A suspected China-nexus threat activity cluster has been observed targeting Indian taxpayers, tax professionals, and corporate finance teams to deliver a remote access trojan designed to steal sensitive data from compromised hosts. The multi-stage campaign, codenamed Operation DragonReturn by Seqrite Labs, involves sending spear-phishing emails impersonating the Income Tax Department of India.

A suspected China-nexus threat activity cluster has been observed targeting Indian taxpayers, tax professionals, and corporate finance teams to deliver a remote access trojan designed to steal sensitive data from compromised hosts. The multi-stage campaign, codenamed Operation DragonReturn by Seqrite Labs, involves sending spear-phishing emails impersonating the Income Tax Department of India. Ravie Lakshmananhttp://www.blogger.com/profile/[email protected]

Data on more than 2.3 million people associated with Moody Bible Institute (MBI) has been exposed online after the Christian college was targeted by ShinyHunters. The attack was first disclosed by MBI in June, and the extortion crew later leaked the stolen data. Have I Been Pwned has since added the cache to its breach notification database, putting a figure on the number of exposed accounts. MBI is one of many victims of ShinyHunters' pay-or-leak attacks in 2026, and while the organization has not explicitly commented on whether it negotiated with the criminals, the leak suggests that the group's extortion demands were not met. Broadly consistent with ShinyHunters' claims, the MBI data made available for download on June 23 includes names, genders, dates of birth, physical and email addresses, phone numbers, and marital statuses. The cache also included documents concerning donor relations, MBI's supporters, students, and alumni. MBI has not spoken publicly since June 22, the day before ShinyHunters leaked its files. The organization stated that its tech team had addressed a vulnerability and brought in external cybersecurity experts to help with its incident response. It urged those affiliated with MBI to monitor their accounts and make use of free credit freezes and fraud alerts until it had completed its investigation. "Throughout this process, we are grateful for the Lord's faithfulness and for the dedicated teams and outside experts working tirelessly to protect our ministry and those we serve," said MBI. "We are confident that God remains sovereign over every circumstance, and we trust Him to grant wisdom and discernment as we navigate this situation together." MBI has various operations, or "ministries." Chief among them is its university, which offers undergraduate, graduate, and online courses for those pursuing ministry work. It also offers aviation courses with a theology component. More than 250,000 students have studied at MBI since it was first established in 1886. It also runs Moody Radio, a Christian radio network/station, and a publishing arm devoted to Christian literature. ShinyHunters' leak site lists 86 victims since January, although the number for the year is likely higher, since those who paid extortion fees would be removed from the list of breached organizations. The group has been linked to high-profile attacks involving Salesforce, Carnival, and Pitney Bowes. The gang has also claimed that a Oracle PeopleSoft campaign affected more than 100 organizations, and cited a PeopleSoft breach in the details about its attack on MBI. National security alerts were issued about ShinyHunters earlier in the year following its attack on learning platform Canvas, which compromised the data of an estimated 275 million students. ®

Finská písková baterie ukládá přebytečnou zelenou elektřinu ve formě tepla • Levné akumulační médium nepodléhá degradaci a nehrozí žádná exploze • Velkokapacitní tepelná úložiště pomohou průmyslu nahradit drahá fosilní paliva

For the first time, the source code of KSOS, backed by the US Department of Defense in the late 1970s and 1980s, is available to the public in the archives of The Unix Heritage Society (TUHS). TUHS volunteers preserve the historical source code and documentation of the original UNIX – or as much of it as is left. A few days ago, in an email to its mailing list, TUHS founder Warren Toomey announced the addition of KSOS to the collection. "KSOS was the US Department of Defense (DoD) Kernelized Secure Operating System (KSOS, formerly called Secure UNIX). KSOS is intended to provide a provably secure operating system for larger minicomputers," he wrote. Despite its age, KSOS sounds surprisingly modern. It was a Unix-compatible OS, implemented in a type-safe programming language, Modula, rather than C. Modula was the late great Niklaus Wirth's successor to Pascal and, in turn, the forerunner to Modula-2 – which we described when it was added to the GNU Compiler Collection in 2022. KSOS was designed to be formally verifiable, so that it could be trusted for use in highly secure systems. It ran on commodity hardware, and its development was sponsored by the US DOD. Very few OS kernels have been formally verified, and one of the best-known modern examples is the seL4 microkernel, as used in the Ironclad OS we covered last year, and also in the new QSOE RISC-V RTOS. KSOS isn't some cutting-edge experimental new Rust effort, like the Asterinas project we described last year or the even newer Maestro project. What became KSOS started in 1978 at Ford Aerospace (yes, that Ford). On the team were Peter Neumann, who later ran the RISKS Digest – The Register was quoting him in 2004 – and Tom Perrine, who described it and its modern relevance in a 2002 article for the USENIX journal ;login:. It's titled "The Kernelized Secure Operating system (KSOS)" [PDF], and at only three and a bit pages long, it's well worth a read. Even then, 24 years ago, projects were struggling to reinvent things KSOS did successfully a couple of decades earlier. That's even more true today. To learn more about how KSOS worked, there's a 1978 Executive Summary [PDF] – which, despite its title, runs to 15 pages. Clearly, executives back then had longer attention spans. Perrine gave a talk about KSOS at DEF CON 20 in 2012, which you can watch on YouTube. KSOS isn't forgotten. For instance, it came up in a talk at last year's FOSDEM: Confidential Computing's Recent Past, Emerging Present, and Long-Lasting Future. Page 8 of the slide deck [PDF] says KSOS was "among the first security-focused kernels, emphasizing formal verification" and "source code was publicly available, rejecting 'security through obscurity.'" KSOS was not confined to academic research. It was used in production. Last October, Perrine explained more in another TUHS email: "KSOS – for PDP-11, originally developed by Ford Aerospace, and then extended at Logicon. It did have a supervisor-mode UNIX-system-call-compatible system. Later, there was also a userland library that implemented something that mostly matched the UNIX system calls. It had no kernel code in common with UNIX. It was written in Modula. "KSOS was used in the Trusted Downgrade System of the multi-level-secure 'all-source' intel fusion system that Logicon built for a few agencies. ACCAT-GUARD and USAFE-GUARD, for example. "KSOS-32 – a VAX 'port' of KSOS (which was then retconned as 'KSOS-11'). The Modula code from -11 was run though Emacs macros to produce Modula-2, and then parts were rewritten as needed. "I worked on both systems at Logicon." It's Perrine we have to thank for KSOS reappearing in public view after 38 years – he released an old tarball of the source code that was preserved by fellow KSOS-32 developer Jeff Makey, and with the help of John O Goyo and Thalia Archibald, it made its way to the TUHS code archive. Now there’s a new quest: find the original compiler used to build it. One thing that may help slightly is that KSOS was not self-hosting: it was compiled under UNIX. We have mentioned TUHS's important work before: for instance, when a tape of UNIX V4 was found in University of Utah boffin Robert Ricci's department — and successfully recovered. Bootnote Mr Goyo also found time to email The Reg FOSS desk about the recovery, for which we thank him. ®

One of the most common pieces of anti-phishing advice is to double-check the website’s domain name before providing your credentials. Typically, a fraudulent domain stands out to the trained eye, differing from the official URL by at least a few characters. Recently, however, we encountered a campaign where attackers instruct victims to input data directly into a legitimate, trusted corporate site: the Microsoft Identity Platform, which supports an OAuth 2.0 specification known as the Device Authorization Grant.

This specific protocol extension was designed to simplify the login experience for smart TVs, IoT hardware, printers, and other input-constrained devices that lack a full browser or keyboard. It allows users to use a nearby smartphone or PC for authorizing these devices to access their accounts. To complete the process, the user enters a one-time code on a designated authentication page. The Microsoft Identity Platform returns this code along with a link to enter it in response to a request to https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode; hence, an attack scenario exploiting this mechanism is called Device Code Phishing.
In this post, we break down how the Device Authorization Grant specification (also known as the Device Authorization Grant Flow or Device Code Flow) works, analyze real-world attacks leveraging this technology, and outline effective strategies to defend against Device Code Phishing.

Core steps of Device Authorization Grant

1. Requesting the authorization code

When a user launches an app on a client device, such as a streaming app on a Smart TV, the app detects that it is unauthenticated and sends a POST request to https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode. This request includes the client_id (the unique identifier of the app registered in Microsoft Entra ID / Azure AD) and the scope (the requested access permissions). In response, the application receives several parameters: device_code (a secret code for internal use), user_code (a short code displayed to the end-user), verification_uri (the login URL the user needs to visit), expires_in (the code’s lifespan), and interval (how frequently the app should poll the server).

2. Displaying the code to the user

The device displays both the user_code and the verification_uri to the user, instructing them to complete authentication on another device. For instance, a smart TV will display the code and URL — often rendering the verification_uri as a QR code — so the user can access it via their smartphone.

3. Entering the code and confirming access

By scanning the QR code with a smartphone camera or manually typing out the address, the user navigates to the verification_uri (such as https://microsoft.com/devicelogin) and enters the user_code.

4. Polling the server

The device (smart TV) begins polling the server to check the authorization status — essentially verifying whether the user has approved the access request. It does this by sending a POST request to the token endpoint: https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token. The request passes the grant_type parameter with the value urn:ietf:params:oauth:grant-type:device_code, indicating the use of the Device Authorization Grant method. This signals to the authorization server exactly which authentication method is being used to request access tokens. The server waits for the user to enter the user_code on their secondary device and approve access to their resources or data. Until that approval happens, the server responds with an error code like authorization_pending (keep waiting) or slow_down (reduce the polling frequency).

5. Issuing access tokens

Once the user successfully approves the application’s request, the server responds to the application by issuing an access_token (to access the data), a refresh_token (to renew access later), an id_token (containing user profile details like name and email), along with several other service parameters.

6. Automatic access renewal

The device (our smart TV) uses the refresh_token to silently renew the access_token without requiring any further user interaction. When the current access_token expires (typically after 1 hour), the device automatically sends a token refresh request containing the refresh_token to the token endpoint. It then receives a fresh pair of access and refresh tokens, ensuring the user remains authenticated seamlessly.

While this workflow is truly convenient for input-constrained devices, attackers can abuse it to hijack user accounts and maintain persistent access for extended periods using the issued refresh_token. Let’s use a real-world example to break down this attack vector.

Analysis of a Device Code Phishing attack

The phishing email

In a phishing campaign we observed spanning from early April to mid-May 2026, the initial email was styled as a notice from a law firm. Attached to the email was a password-protected PDF file.

Once the victim opened the PDF and entered the password, they were presented with a landing page listing several documents. However, viewing these documents required clicking a provided link.

PDF file with a malicious link

A close look at the target URL reveals that instead of pointing to a typical, easily recognizable phishing domain, it actually points to a legitimate Microsoft address. However, the URL parameters are configured to redirect the user to a phishing resource.

The link within the document does not keep the user on the Microsoft platform; instead, it immediately redirects them to a phishing page designed to mimic a corporate legal portal.

The phishing page

Interestingly, the landing page featured multiple CAPTCHAs, presumably deployed to filter out security crawlers. Once past these hurdles, the user was routed to a final page that instructed them to copy a one-time code. This code was the user_code that the attacker’s server-side application had already fetched by querying https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode, as detailed in the workflow above.

The one-time code

The one-time codeClicking the displayed one-time code automatically copied it to the clipboard while simultaneously redirecting the user to Microsoft’s actual, legitimate authentication page (verification_uri), where they were prompted to paste and enter the code.

Official Microsoft authentication page

Once the user entered the code, it kicked off the Device Authorization Grant flow described earlier. The unsuspecting victim then completed the full MFA process directly on Microsoft’s official page. As soon as authentication succeeded, the attacker harvested the session’s access_token, refresh_token, and id_token. This enabled them to read and send emails from the victim’s mailbox, exfiltrate files from OneDrive, and access Teams conversations.

Adaptation of the attack method

This phishing campaign was limited in scope and spanned slightly more than a month. However, the threat actor continues to actively leverage this method, adapting it to target specific geographic regions. We’ve recently detected slightly modified Device Code Phishing campaigns shifting their focus toward users in Brazil, among others.

The Brazilian phishing variant

Translated from Portuguese:

“Hello!
Your order has just been processed, and the confirmation has been sent to you in PDF format. Please see the details below.
OPEN / DOWNLOAD PDF
A new quote is attached to this email.
Please let me know if you need any further assistance.”

  Unlike the previous campaign, this email did not include a malicious PDF attachment. Instead, it embedded a link pointing to cacoo.com, a legitimate online diagramming platform owned by Nulab. Just as before, this trusted domain served as an open redirect to steer the user toward the phishing infrastructure.

The proxy link routes through the legitimate Cacoo.com domain before redirecting to the phishing site

Translated from Portuguese:

Request confirmation
Status Code = Success
DOWNLOAD OR VIEW THE DOCUMENT
Important note: Log in to the account that received this message to securely authenticate the document.

Clicking the link routed the user back to the familiar landing page displaying the one-time code.

Landing page displaying the code

From there, the potential victim was once again redirected to the official Microsoft portal to complete the Device Authorization Grant authentication process.

Official Microsoft page prompting for the user code

How to defend against Device Code Phishing attacks

As our research demonstrates, threat actors don’t always rely on harvesting credentials or deploying malware to access sensitive data — they can just as easily weaponize legitimate tools. Therefore, users must exercise vigilance not only when visiting suspicious sites, but also when navigating official platforms like Microsoft or Cacoo.com.

Recommendations for users

• If you did not personally initiate a login request on an external device using the Microsoft Device Authorization Grant, do not approve the authorization request.
• Never enter an authorization code received via unexpected emails or messages, even if the provided link points directly to an official Microsoft domain.
• Threat actors frequently leverage open redirects on legitimate domains, appending parameters like redirect_uri, return_url, or next after the question mark (?) to point to a malicious destination. Before clicking any link, hover your cursor over it to inspect both the primary domain and any suspicious redirect parameters. Once the page loads, verify that the final URL actually matches the expected asset — this is the absolute minimum requirement before entering corporate credentials.

We strongly advise enterprise teams to evaluate the business necessity of the Device Code Flow within their corporate infrastructure. If this authentication mechanism is not required for daily operations, it should be disabled globally via Conditional Access policies within Microsoft Entra ID. Additionally, security teams should set up dedicated monitoring for DeviceCodeSignIn events, strictly e nforce device compliance states, and configure alerts for anomalous sign-in behavior originating from unusual locations.

To establish a comprehensive defense against Device Code Phishing attacks, organizations should deploy robust email security solutions capable of securing both corporate and personal messages.

Researchers at Shandong University have shown a fast new way to pull data off computers that are cut off from every network. The technique, called TrojPix, tweaks on-screen pixels in ways the eye cannot see, so that the video cable carrying them radiates a faint radio signal a nearby receiver can decode. But TrojPix works only once malware is already on the target machine, so it

Researchers at Shandong University have shown a fast new way to pull data off computers that are cut off from every network. The technique, called TrojPix, tweaks on-screen pixels in ways the eye cannot see, so that the video cable carrying them radiates a faint radio signal a nearby receiver can decode. But TrojPix works only once malware is already on the target machine, so it Swati Khandelwalhttp://www.blogger.com/profile/[email protected]

iPhone v oblasti mobilní bezpečnosti i po letech dominuje • Google jej dohání, ale v některých oblastech stále ztrácí • iOS je ze startu maximálně zabezpečený, Android čeká na zásahy uživatele

** iPhone v oblasti mobilní bezpečnosti i po letech dominuje ** Google jej dohání, ale v některých oblastech stále ztrácí ** iOS je ze startu maximálně zabezpečený, Android čeká na zásahy uživatele

Cybersecurity researchers have flagged a novel Java-based remote access trojan (RAT) called QuimaRAT that's capable of targeting Windows, Linux, and macOS environments. According to LevelBlue, the cross-platform malware is advertised under a malware-as-a-service (MaaS) model, costing anywhere between $150 for one month to $1,200 for lifetime access. Other subscription tiers include $300 for

Cybersecurity researchers have flagged a novel Java-based remote access trojan (RAT) called QuimaRAT that's capable of targeting Windows, Linux, and macOS environments. According to LevelBlue, the cross-platform malware is advertised under a malware-as-a-service (MaaS) model, costing anywhere between $150 for one month to $1,200 for lifetime access. Other subscription tiers include $300 for Ravie Lakshmananhttp://www.blogger.com/profile/[email protected]

Researchers found a flaw in Opera GX, the gaming-focused version of the Opera browser, that let a malicious website silently install a browser add-on and use it to lift specific data from the pages a victim visits. In a proof of concept, they reconstructed a signed-in user's full Gmail address from a single visit, with no click. Opera has patched the flaw and says it found no evidence that

Researchers found a flaw in Opera GX, the gaming-focused version of the Opera browser, that let a malicious website silently install a browser add-on and use it to lift specific data from the pages a victim visits. In a proof of concept, they reconstructed a signed-in user's full Gmail address from a single visit, with no click. Opera has patched the flaw and says it found no evidence thatSwati Khandelwalhttp://www.blogger.com/profile/[email protected]

Česká firma SpaceKnow skončila na čínském sankčním seznamu, důvodem je zřejmě to, co umí odhalit • . • SpaceKnow v roce 2024 odhalila čínskou loď, která sabotovala podmořské internetové kabely v Baltském moři. • SpaceKnow se spojila s americkou firmou Satellogic, která vypouští malé satelity ...

Scanners meant to catch malicious add-on "skills" for AI coding agents can be fooled by a few simple changes that leave the malware working, according to a new study from researchers at the Hong Kong University of Science and Technology. Their strongest trick slipped past every scanner tested more than 90% of the time, and the same team built a runtime checker that catches most of the

Scanners meant to catch malicious add-on "skills" for AI coding agents can be fooled by a few simple changes that leave the malware working, according to a new study from researchers at the Hong Kong University of Science and Technology. Their strongest trick slipped past every scanner tested more than 90% of the time, and the same team built a runtime checker that catches most of theSwati Khandelwalhttp://www.blogger.com/profile/[email protected]

Spoluautor internetových protokolů Vinton Cerf odchází v 83 letech do důchodu • Legendární vizionář varuje před používáním lidské řeči u autonomních AI agentů • Stroje podle jeho slov nutně potřebují přísné a přesné komunikační standardy