Donald Trump is allowing government agencies to contract private cybersecurity companies to carry out operations against cyber-enabled transnational criminal organizations (CE-TCOs). The US President signed a memo on Wednesday confirming a strategy hinted at earlier this year, saying participating companies can support national operations against criminals, including cyber surveillance and technical disruptions of their networks. The latter, described as "Cyber Effects Operations," covers activities that cause "the manipulation, disruption, denial, degradation, or destruction of information systems, networks, physical or virtual infrastructure controlled by information systems, or information resident thereon." Although the memo establishes a distinction between cyber effects operations and cyber surveillance missions, it acknowledged that the latter will also inevitably involve some disruption or manipulation of systems in order to carry out the surveillance. Surveillance operations are designed for intel gathering, either to support further snooping or for later use in cyber effects operations, with the intent of remaining undetected. Trump described CE-TCOs as "any foreign group that conducts cyber-enabled crime against the United States Government, a United States person, or United States interests." Crucially, the definition excludes entities directly associated with, or operating wholly on behalf of, foreign governments. No stepping on TAO's toes, of course. Participating companies will undergo "rigorous vetting" and will be subject to "strict operational procedures," the memo adds. The operational procedures are to be drawn up within 60 days and codified by program executive directors working with the Homeland Security Council. Companies wishing to be called up for service will have to demonstrate that they have the technical capabilities to carry out the required operations, and be willing to prove this each year via annual evaluations. Program managers must ensure that the operational procedures open opportunities for highly resourced, large organizations, as well as "smaller, more agile companies" that may prove useful for "specialized or discrete tasks." The Justice Department will also play a role in authorizing operations, particularly those targeting US residents or raising domestic legal issues. Participating companies will also be prohibited from executing operations that could lead to "critical outcomes," which is shorthand for attacks that result in the loss of life or serious injury, or those that could be seen as an armed attack under international law. These companies will also be required to maintain a bond or escrow of at least $1 million, which shall be forfeited if they violate the terms of their contracts. Unleashing Trump's cyber army The White House published "President Trump's Cyber Strategy for America" document in March, which promised to "unleash the private sector by creating incentives to identify and disrupt adversary networks and scale our national capabilities." The document [PDF] also stated: "We will leverage the immense talents and ingenuity of our private sector research base. "We will establish a new level of relationship between the public and private sectors to defend America in peace and war." The announcement prompted legal eagles and think tanks to ponder the implications of such a move. Many wondered how the promise to mobilize the private sector would be put into practice. They did not then have the details contained in this week's memo, and some assumed participating companies would support operations against nation-states. This particular program, however, excludes entities acting directly on behalf of foreign governments. Writing for the Royal United Services Institute (RUSI) and citing reporting available at the time, cyber and tech research fellow Gareth Mott said that the US Computer Fraud and Abuse Act (CFAA) might need to be amended before American companies could legally offer such services. Experts from law firm Skadden, Arps, Slate, Meagher & Flom agreed, despite the US Cyber Strategy not mentioning any plans for legislative changes. They wrote: "Any attempt to more directly involve the private sector in offensive cyber actions will likely require further legal and regulatory changes before it can be meaningfully implemented. "Even if the administration were to issue new enforcement guidance redirecting prosecutions away from hack-back cases, the availability of civil penalties under the CFAA and its five-year statute of limitations would likely render such executive actions significantly less impactful. "Technology companies should consider closely monitoring developments to track how the administration plans to enact such incentives." However, Jenner & Block lawyers noted in an analysis published by Lawfare that a provision of the CFAA could limit participating companies' exposure. Title 18 of the US Code, § 1030(f), says the CFAA does not prohibit lawfully authorized investigative, protective, or intelligence activity by a US government agency or intelligence agency. Participating companies might therefore be protected when acting under government contracts and direction. However, no court has determined whether that exemption covers private companies carrying out such work. "No court has addressed whether this exception provides any protection for private-sector entities engaged to perform these activities on behalf of the US government and, if so, under what circumstances," the lawyers wrote. "At the very least, it is unlikely that a court would interpret this provision to extend to private companies engaged in independent offensive operations, without government direction or involvement." The last part is key: because the US government will draw up procedures and direct the companies' involvement, the work may fall within the CFAA exemption. Whichever way the US constructs its private sector play, it represents a significant shift in the country's cybersecurity policy, and perhaps that of other nations further down the line. As Mott points out, US allies will certainly be keeping tabs on the private sector program's success, and its take-up from the companies it looks to attract. ®

Confidence in an organization's cyber recovery capabilities deserves scrutiny. If a ransomware attack disables the SaaS data tenanted in the Microsoft cloud ecosystem, the data the business depends on as its lifeblood, the pace at which operations resume rests on assumptions that often prove wrong. Anyone whose answer is "It's all good. Microsoft has my back on this one with its comprehensive native retention and recovery capabilities" is due a reality check. With agile business tools like M365 and Entra ID and solid backend infrastructure in the form of Azure, Microsoft brings a lot to the SaaS party. Both IT departments and MSPs need to be aware, however, that Redmond operates on the same shared responsibility model as other major SaaS providers. In the event of a cyberattack, the recovery burden splits between what the cloud provider handles and what falls to the subscriber alone. MSPs face the additional pressure of meeting stringent SLAs, working with clients’ preferred providers or tooling, and managing their own staffing and profitability accordingly. Microsoft ensures that its services keep running in the aftermath of a strike but does not promise to restore data to a specific known good point before the disaster. That gap always sat with the customer, and planning for it before problems hit beats improvising while picking up the pieces. "There's a common misconception about what Microsoft is responsible for, as distinct from the service they're providing," explains Brent Torre, GM of cyber resilience . Microsoft's native tools, he points out, address problems like short-term accidental deletion and aspects of data governance. They are not a backup solution and will not protect against ransomware or recover data. "Microsoft is clear that whether it's a SaaS application like Microsoft 365, a platform application like SQL Server, or even VMs running in Azure, the customer is always responsible for the information that's in that service, as well as devices, accounts and identities," he adds. "If you get compromised and the attacker starts deleting data, Microsoft has no responsibility for that." A world of pain The gap between availability and true cyber recovery is misunderstood, and it has widened into something of a chasm in recent years. There are three contributing factors to this gap. The first is the evolution of cyberattacks. Typical cyberattacks have pivoted from muscling past a defensive barrier to targeting human weakness, because strolling in through the front entrance with a stolen pass is easier than shimmying through a forced window. Identity has become the primary attack surface. Credential compromise, or identity-based initial access, removes the need to find a vulnerability to exploit and requires only an unwary employee. AI is now a staple weapon in the criminal arsenal, augmenting exploitation techniques such as phishing, social engineering, deceptive emails and spoofed websites, all convincingly used to trick users into typing passwords into a portal controlled by the aggressor. The technique can get more scientific than that. Automated AI-powered bots test millions of leaked username and password pairs across hundreds of different websites, exploiting the common habit of password reuse. Microsoft Entra ID, the vendor's cloud-based identity and access management service and the very tool designed to keep criminals out, is now a prime vector for attack and no match for stolen identity. Once an attacker compromises Entra ID with pilfered credentials, without setting off alarms, they have a free run at gathering data from mailboxes, OneDrive, SharePoint, Teams and other soft targets. The ransomware attack itself can then be launched with ease and at leisure. Another contributory factor is that the vogue for moving workloads to infrastructure and platform as a service (IaaS and PaaS) models shows no sign of abating. Organizations tend to retain some functions on-premises, put some in SaaS applications, and others in cloud environments, but are often guilty of not protecting and managing everything to the same level of quality. Data gets backed up in a variety of locations, yet whether it is all equally recoverable in the event of a breach is another chink in the armor that nobody understands. The 'as a service' model is popular, but it is the weak link when ransomware strikes. The third part of the problem is the emergence of multiple compliance requirements mandating cyber resilience along with correct backup and recovery procedures, for which many organizations are ill-prepared. Together, these pressures give criminals room to do enormous harm to data, business operations and compliance posture in the gap between attack and restoration of SaaS availability. Given that Microsoft's native retention and recovery capabilities are not designed to deliver true cyber resilience, restoring the business to how it was before the attack is something to plan for in advance. Time for independent backup protection "At Kaseya we regularly recommend that you keep a copy of your data, independent of the primary environment it's operating in," advises Torre. "This needs to be something immutable that you can recover from even if the Microsoft or Google or Salesforce ecosystem goes down." This kind of protection is best delivered as a dedicated cloud-to-cloud backup solution stored outside the main SaaS tenant, he argues, an approach increasingly written into cyber insurance and compliance requirements. By pulling copies of regularly targeted data from the Microsoft tenant for storage offsite in a third-party datacenter, organizations can be sure that if SaaS credentials are compromised, critical assets remain safe from attack. Restoration can then push what is needed directly back into the SaaS environment, even where the original tenant has been destroyed. "In fact some people find it faster to stand up a new shell and rebuild it than try to gain access back into a compromised tenant," notes Torre. "Whether you're an internal IT technician, working the night shift, or an MSP needing to live up to your SLAs and maintain profitability, you require a solution that's super straightforward and you need to be able to trust that the recovery will work. Both IT departments and MSPs should be looking out for a solution that's incredibly easy to use. Disaster recovery isn't the only job that they have." A good platform, he says, focuses not just on guaranteeing recovery but on keeping the hygiene of the cyber resilience estate at a high standard without endless human intervention. It should also make certain that Microsoft 365 and Entra ID are restored together in a single workflow, so identity and the data it grants access to come back online in the right order rather than in separate stages. Choosing the right platform Datto is a cybersecurity and data protection business owned by Kaseya. Datto SaaS Protection for Microsoft 365, Datto Backup for Microsoft Azure, and Datto Backup for Microsoft Entra ID are designed between them to close the gap between availability and recovery by storing protected copies of tenant data in the Datto Cloud, outside the Microsoft environment. In this way a compromised production tenant does not take the recovery point down with it. "With our M365 backup, we're protecting one million users worldwide," claims Torre. "A lot of organizations have built trust around our ability to protect and recover their data. We offer a trusted platform for recovery that focuses on ease of recovery, ease of deployment, not just for M365 but for Azure and Entra ID too." Both IT bosses and MSP players need to recognize that a ransomware attack, or other cyber crisis, is a matter of when rather than if. Recovery matters more than protection, because protection is certain to fail at some point, and traditional approaches to backing up data are no longer sufficient on their own. Anticipating disaster is not enough; the organization also needs to be set up to withstand it. That means being as certain as possible that the Microsoft environment can be recovered rapidly, down to the last scrap of data. This capability underpins modern business workflows and operations. Microsoft tracks more than 4,000 identity attacks every second and analyzes 38 million identity risk detections daily — no organization is off the target list. When an attack lands, the restoration clock is already ticking, and any delay in fully restoring IT operations and key environments to their pre-attack state can mean the difference between survival and collapse, with profit, regulatory standing and reputation all riding on the outcome. Securing data with purpose-built cyber resilience platforms that enable rapid, clean recovery is how organizations meet that test. MSPs looking to close the gap can start with the Datto MSP Buyer's Guide to Microsoft Entra ID Backup Sponsored by Datto.

Beacon, a CRM provider for charities and nonprofits, says an AWS access key "potentially exposed in public JavaScript build artifacts" is the leading suspect in its July breach. The revelation came in the company's first update on the attack in more than a week. If the access key was exposed in public build artifacts, it raises questions about why Beacon's development pipeline and code review controls failed to catch it. Beacon used stronger wording about the potential data loss, confirming that a copy of the database was made and assessing that it was probably downloaded in readable form. "This update confirms… that a copy of the database which holds all Beacon customer data, including attachment files, was made and likely downloaded in a readable format by the threat actor," wrote CTO David Simpson. "Analysis of the AWS Cost & Usage reports across May-July 2026 has been conducted. This data showed a significant increase in data transfer on 27-28 July 2026. This timing correlates with the malicious activity, which supports an assessment that substantial downloads occurred." Beacon's logs cannot reveal which specific records left its systems, although the company has confirmed that a copy of the database containing all customer data and attachments was made. In an FAQ accompanying the update, Beacon advises customers to assess the likely exposure by reviewing what they stored in their CRM instance. Many of the charities that have confirmed they are affected have said the data mainly pertains to personal information and details about donations. Simpson said Beacon's AWS data was encrypted at rest, but the compromised access key may have allowed the attacker to retrieve it in readable form. The malicious activity began in the early hours of July 27, according to Beacon's root cause analysis, matching its initial estimate of the incident timeline. The company has more than 1,500 customers, although it has not established how many had data taken. The malicious activity lasted one hour and 27 minutes, Beacon said, and the attacker established no persistence mechanisms in AWS. Simpson warned customers that "there are things we may never be able to find out about this incident," and that other details won't be shared to protect Beacon's security position. He promised to provide customers with a summary when the investigation concludes in a few weeks, but warned that "the level of detail contained in this next and final update may not be any more than" Beacon published on Wednesday. "I recognise this is frustrating, but unfortunately it is the reality of complex incidents like this. With this in mind, we would recommend making your own risk assessments now regarding onward notification to impacted data subjects using your knowledge of the data you process and store with Beacon." Since Beacon disclosed the attack on August 4, the number of high-profile charities confirming they are affected has grown every day. Early confirmations came from the likes of Molly Rose Foundation, Macmillan Cancer Support Jersey, and English National Ballet. Sheffield Hospitals Charity, Shrewsbury and Telford Hospital Charity, the British Deaf Association, and Lincoln Cathedral are among those that have since joined the list. The Charity Commission said that "a number of charities have submitted serious incident reports," and that the volume of these reports is causing delays to responses. "We appreciate your patience and understanding as we prioritise instances of the greatest risk," it said. ®

Una vulnerabilità RCE upload immagini in WordPress può trasformare un'operazione comune, come caricare una foto, in una porta d'accesso per i malintenzionati. Se gestisci un sito WordPress, questo è un argomento che devi assolutamente conoscere.

Di recente è emersa una falla critica che permette a un utente con privilegi di "Autore" di eseguire codice da remoto. Questo attacco, noto come Remote Code Execution, avviene tramite il caricamento di un file immagine malevolo.

Non c'è motivo di allarmarsi. Infatti capire il problema è il primo passo per risolverlo. In questa guida ti spieghiamo cos'è successo, come funziona l'attacco e, soprattutto, come puoi mettere in sicurezza il tuo sito web in pochi semplici passaggi.

Cos'è una vulnerabilità RCE in WordPress e perché dovresti preoccuparti?

Prima di entrare nei dettagli tecnici, chiariamo un concetto fondamentale: RCE, o Remote Code Execution, significa "Esecuzione di Codice da Remoto". È come dare a uno sconosciuto le chiavi del tuo server. Un attacco RCE riuscito consente a un hacker di eseguire comandi sul tuo hosting come se fossi tu.

Le conseguenze possono essere devastanti:

• Furto di dati sensibili, come informazioni degli utenti o dettagli di pagamento.
• Installazione di malware o ransomware sul tuo server.
• Cancellazione o modifica dei contenuti del sito.
• Utilizzo del tuo server per lanciare attacchi verso altri sistemi.

In breve, significa perdere il controllo completo del tuo spazio web. Per questo motivo una falla di sicurezza di questo tipo va presa molto sul serio.

La falla specifica: come un'immagine diventa un'arma

Come può un semplice file PNG scatenare una vulnerabilità RCE in WordPress? Il problema non risiede nel core di WordPress, ma nell'interazione tra la piattaforma e due strumenti che gestiscono le immagini: ImageMagick (noto anche come Imagick) e Ghostscript.

Ecco la catena di eventi che un aggressore potrebbe sfruttare:

1. Il file mascherato: l'attaccante crea un file che appare come un'immagine (ad esempio, vacanza.png), ma al suo interno nasconde codice malevolo, scritto in un linguaggio come PostScript.
2. Il caricamento: un utente con il ruolo di "Autore" carica questo file nella Libreria Media di WordPress.
3. L'errore di validazione: le versioni vulnerabili di WordPress si fidavano dell'estensione del file (.png) senza analizzare a fondo il suo contenuto reale.
4. La delega pericolosa: WordPress passa il file a ImageMagick per elaborarlo, ad esempio per creare le miniature. ImageMagick riconosce che non è una vera immagine ma codice PostScript e delega il compito a Ghostscript, lo strumento designato per interpretare questo tipo di file.
5. L'esecuzione del codice: Ghostscript, eseguendo il suo compito, interpreta il codice contenuto nel file. Questo permette all'hacker di eseguire comandi sul server.

Il punto debole era proprio quel passaggio in cui un plugin di WordPress si fidava ciecamente dell'estensione, permettendo al "cavallo di Troia" di superare le prime difese. Per questo è fondamentale proteggere il tuo sito, mettendo in sicurezza i plugin.

Chi è il bersaglio della vulnerabilità RCE di WordPress?

Questa vulnerabilità non colpisce tutti i siti allo stesso modo. Il principale fattore di rischio dipende da chi ha i permessi per caricare file multimediali. L'attacco, infatti, richiede almeno un account con ruolo di Autore.

Il tuo sito è ad alto rischio se:

• Gestisci un blog con molti autori o collaboratori esterni.
• Hai una piattaforma di membership o un e-commerce dove gli utenti possono caricare immagini.
• Concedi l'accesso al backend a clienti o a un team allargato con ruoli superiori a "Sottoscrittore".

Al contrario, se il tuo sito è gestito solo da te e da pochi amministratori di fiducia, il rischio è basso. Tuttavia, la sicurezza non è mai troppa.

La soluzione: come mettere in sicurezza il tuo sito WordPress

La buona notizia è che la soluzione è semplice, rapida e già disponibile. Il team di sicurezza di WordPress ha rilasciato una patch che corregge completamente questa falla. L'unica azione necessaria è aggiornare la tua installazione di WordPress alla versione più recente.

La correzione è stata implementata a partire dalla versione 7.0.4 del plugin Gutenberg e integrata nel core di WordPress. L'aggiornamento modifica il modo in cui WordPress gestisce i file. Ora, prima di passare qualsiasi file a ImageMagick, la piattaforma ne analizza il contenuto reale (la sua "firma digitale"). In questo modo si assicura che un file .png sia davvero un'immagine e non un file PostScript mascherato. Questo blocco preventivo neutralizza completamente la minaccia.

Vulnerabilità RCE in WordPress: la prevenzione è la migliore difesa

Oltre all'aggiornamento, puoi adottare alcune buone pratiche per rafforzare la sicurezza del tuo sito e prevenire problemi futuri:

• Limita i permessi: assegna sempre il ruolo con i privilegi minimi necessari a ogni utente. Non tutti hanno bisogno di essere "Autori" o "Editor".
• Usa un plugin di sicurezza: strumenti come Wordfence o Sucuri possono monitorare i file caricati e bloccare i tentativi di attacco.
• Effettua backup regolari: avere un backup recente e funzionante è la tua migliore assicurazione contro qualsiasi disastro.

Non sottovalutare la sicurezza del tuo sito

La vulnerabilità RCE in WordPress ci ricorda una lezione fondamentale: anche le operazioni più comuni, come il caricamento di un'immagine, possono nascondere dei rischi.

La sicurezza informatica è un processo continuo di vigilanza e aggiornamento. Non rimandare: controlla subito la versione del tuo WordPress e, se non è l'ultima disponibile, procedi con l'aggiornamento. È un piccolo gesto che garantisce la protezione del tuo lavoro, dei tuoi dati e della fiducia dei tuoi utenti.

L'articolo Guida alla vulnerabilità RCE upload immagini in WordPress proviene da sicurezza.net.

PWNED Welcome, once again, to PWNED, the weekly column where we highlight others’ security failures. Hopefully, there’s a lesson in all this, but it could just be “stop shooting yourself in the foot.” Have a story about someone leaving a gaping hole in their network? Share it with us at pwned@sitpub.com. Anonymity is available upon request. Our story today comes courtesy of Siim Kostabi, co-founder of Pageloot, a company that provides QR codes businesses can use for marketing. Kostabi’s tale of tech terror reminds us that credentials, even for a staging server, have a lot of value in the wrong hands. He explains that his company brought in a contractor to help with some API integrations on the back end. That developer had the credentials for the staging environment and wanted to be able to view them across different devices they were using for the job. So what was the developer’s solution to the very common problem of keeping track of usernames and passwords? They could have chosen a password manager. They could have written the passwords down in a paper notebook and kept it hidden from prying eyes. They could have gotten a password tattoo. They could even have emailed the passwords to themselves and it would have been smarter than what they did. Instead, the outside developer decided to store their password in a Google Doc. And they set that Google Doc to be viewable by anyone on the internet who had the link. And then, one day, an employee at the company found the Google Doc with the staging credentials in it because Google Search had indexed it and offered it as a search suggestion. “A developer on our team was debugging something unrelated and typed our domain into Google Search,” Kostabi recalls. “The autocomplete surfaced one of our staging hostnames followed by what looked like a credential string. We checked, and there was a publicly accessible Docs URL.” Yikes! Just imagine that not only are your company’s credentials available to anyone online, but they are indexed in Google Search for the world to find! Once they discovered the problem, Kostabi’s company immediately cut access for that contractor and rotated all of its exposed credentials. They also set a new rule: no storing passwords on Google Docs, Slack, Notion, or other collaboration tools. In a separate incident, Kostabi heard from a Pageloot customer, a mid-size retailer, whose QR codes were suddenly directing users to a competitor’s site. After investigating, he found that a disgruntled ex-employee’s credentials had not been revoked and that the former employee had used that access to redirect all of the retailer’s URLs, costing it customers. The takeaway from both of these problems is that you need to carefully control access. Former employees should immediately lose access to everything and current contractors should be reasonably intelligent people you can trust. “Both situations were completely avoidable with basic hygiene,” Kostabi said. “Proper offboarding, access reviews, and not treating shared docs like private vaults.” ®

Researchers from Germany’s Helmholtz Center for Information Security have found processors made by China’s Loongson have leaky caches that attackers could use to seek specific data. Loongson has developed its own LoongArch instruction set architecture (ISA) that blends approaches used by MIPS and RISC-V. On a site called LoongLeakAttack.com, the researchers explain that they found the leaky cache using a fuzzer, then noticed that the LoongArch ISA manual mentions an instruction that leaves 32 bits of a memory register in an “uncertain” state. “Our analysis reveals that under certain circumstances, the ‘uncertain’ data originates from the L1 data cache,” the four researchers wrote. “Since this cache is not isolated between applications, LoongLeak can leak data from other applications and the operating system. Even worse, an attacker can prime the CPU’s internal state to target the leakage to a specific cache set.” In a paper [PDF] explaining their research, authors Lorenz Hetterich, Tristan Hornetz, Fabian Thomas, and Michael Schwarz share case studies that “include recovering full-disk AES keys from the kernel, partial root password hashes from user-space, and bypassing traditional software defenses such as ASLR and stack canaries, all within seconds.” In case that’s not scaring you enough, they also point out “LoongLeak can be exploited from unprivileged user space, containers, or virtual machines.” The flaw even means “LoongLeak can cross the virtual machine boundary and leak host data from inside a VM.” “As the leakage is architectural, it requires neither high-resolution timers nor traditional sidechannel amplification, and it grants the attacker precise control over cache set and line offset,” they add. And the cherry on top is that software mitigations aren’t possible. Users with chips that possess the flaw either need to replace them or make sure they don’t allow any private data to enter or remain in the L1 cache. Making that happen can require turning off one thread per core, effectively disabling hyperthreading. The news isn’t all bad, because Loongson fixed the flaw in an update to its model 3A6000 processor, and the mitigation of evicting cache data slows performance by just 1.4 percent in the worst case. The blast radius of this flaw is also likely to be limited, because Loongson chips are hardly used outside China. The company offers chips for PCs, servers, and appliances such as printers. China’s government promotes use of Loongson chips as part of its plan to reduce dependence on imported tech. Lenovo makes laptops that use Loongson chips but only sells them in China. The Register has discussed the company’s chips with other major PC-makers, who told us they would adopt Loongson product if users want them, or if doing so becomes necessary to participate in the Chinese hardware market. But we’ve not seen a non-Chinese company adopt the processors. China’s government, however, may be nervous about this research as it has instructed public sector buyers to buy local products. Perhaps some government agencies are running vulnerable devices? If that’s the case, Beijing has its work cut out spotting any attacks, because the researchers could find “no specific tools or methods to detect if LoongLeak is being exploited.” ®

Suspected Chinese cyber operatives used publicly available AI tools to compromise Taiwanese government systems before expanding the attack to its nuclear safety agency, supply-chain vendors, and at least seven energy companies in what security researchers called a "near-autonomous attack." Over the first four days of July, AI agents compromised 85 government user accounts and extracted more than 2,500 personnel records, according to Dream, an Israeli cybersecurity firm. Researchers uncovered evidence of the attack in a 160 MB online archive containing 1,395 files documenting the operation. Dream, in research published on Wednesday, detailed the intrusions and said that the suspected Chinese hackers hit “government entities in Asia” - but declined to say which government had been attacked. A person familiar with the attack confirmed to The Register that Taiwan was the target. The Financial Times first reported on Dream’s research and identified Taiwan. While the security firm doesn’t attribute the agentic attack to the Chinese government or a specific hacking group, the operational documentation “points to a Chinese-language operator,” the researchers said. According to Dream, the attack framework, built on open source Hermes and OpenClaw AI agents, deployed up to eight sub-agents, each assigned to its own targets and attack techniques, across 12 “attack waves” between July 1 and July 4. First, the agents mapped the entire government ecosystem, extracting embedded URLs, API endpoints, OAuth client IDs, and Keycloak configuration objects from a single government portal. This portal allowed the agents to identify 21 connected government systems and every supported authentication flow. “On one target alone, it discovered 36+ API endpoints spanning account management, user data retrieval, file upload, and administrative functions - many completely unauthenticated,” the Dream threat researchers wrote. “Critically, it found that one of the systems exposed its entire user database without any authentication - thousands of employee records including names, departments, and SSO account IDs.” Multiple entry points After mapping the government’s attack surface, the agents found multiple entry points including three hidden API endpoints that accepted any request body and returned a valid authenticated session without requiring user credentials. Using employee usernames harvested from an unauthenticated API, the agents broke into a government department’s office automation portal, solving its CAPTCHAs with 100 percent accuracy. The agents also tested predictable password patterns based on each employee’s ID, and cracked 85 accounts across multiple password-spray rounds. Eighty-four of the 85 cracked accounts successfully authenticated to the department's internal information system, giving the attackers access to internal dashboards, equipment management interfaces, and personnel statistics pages. In total, the illicit access allowed the agents to exfiltrate a ton of government information, including more than 2,564 personnel records, a full JSON export of all department system users, seven SSO client secrets, six internal database credentials across MSSQL, Oracle, and Sybase, and internal network IP ranges. But wait, there's more And then, the agents pivoted to the Taiwanese government’s supply chain. “It expanded the operation to government IT supply chain vendors, a nuclear safety agency, a government email system, and 7+ energy sector companies - scanning them all in parallel for misconfigurations, exposed admin interfaces, and exploitable vulnerabilities,” the researchers wrote. Notably, the attack framework implemented what the AI tools called “learning cycles.” These are autonomous sessions where the models search vulnerability databases, GitHub repositories, and other security research for specific techniques, CVEs, and common weaknesses to exploit in the targeted government's infrastructure. Additionally, when the AI framework made a mistake, it “self-corrected,” according to Dream, catching errors and fixing them through its own verification process. This near-autonomous attack comes as frontier model makers OpenAI, Anthropic, and Meta all admitted that their agents went rogue, escaped from their training environments, and autonomously hacked other organizations and people. OpenAI technical staffer Michael Dalton, in a Black Hat briefing last week about the Hugging Face attack, said “AI orchestrated, fully automated offensive attacks are real now.” “In the near future, we should expect that threat actors will intentionally deploy, optimize, weaponize, and use offensive agent collectives in the manner that you have just described here,” he added. It appears that the future is now. ®

If you thought that the famous Spectre security vulns were a relic of 2018, think again. Certain RISC-V chips are still very much subject to this hair-raising hole, researchers say. Spectre refers to a family of vulnerabilities related to speculative execution, a performance optimization technique based on predicting the flow of data before instructions have been executed. Incorrect predictions get rolled back without affecting running applications but nonetheless leave traces that can be recovered and exploited to violate memory protections and access secrets. Spectre flaws have dogged x86 and ARM chips for years, leading computer scientists to develop a series of defenses, including Indirect Branch Restricted Speculation (IBRS), Indirect Branch Prediction Barrier (IBPB), and Single Thread Indirect Branch Predictor (STIBP). Researchers affiliated with academic institutions in Belgium and Germany say that it's been popular to assume that the RISC-V chip architecture isn't affected by Spectre vulnerabilities because it's too simple. That assumption is incorrect, according to a paper accepted at the 35th Usenix Security Symposium, "Spectre on RISC-V Silicon: Attacks and Defenses on Commercial Out-of-Order Processors." It says that commercially available out-of-order RISC-V processors (SiFive P550 and T-Head Xuantie C910/C920) are vulnerable to all major Spectre variants. RISC-V processors that process instructions in-order (SiFive U74, Xuantie C906, C908) do not appear to be vulnerable. Prior research has shown that RISC-V processors used for academic research (e.g. BOOM, RiscyOO, RSD, Proteus, NaxRiscv, and NutShell) can be affected by one or more of the Spectre variants, but hasn't addressed commercial silicon. "We demonstrate proof-of-concept attacks on both processors using Spectre-PHT, Spectre-BTB, SpectreRSB, and Spectre-STL, achieving up to 100 percent recall with more than 97 percent precision," the paper states. Spectre-PHT involves mistraining the Pattern History Table; Spectre-BTB poisons the Branch Target Buffer; Spectre-RSB attacks the Return Stack Buffer; and Spectre-STL (Store To Load) exploits mispredicted store-to-load forwarding. To demonstrate the risk to RISC-V, they created a proof-of-concept Spectre exploit that leaks arbitrary Linux kernel memory on the Xuantie C910 at a rate of 338 B/s. Software-based defenses have been developed for these vulnerabilities on x86 and ARM hardware. Unfortunately, the researchers say, these don't necessarily transfer. They also call out RISC-V hardware for its lack of introspection interfaces, necessary to observe and reason about microarchitectural features. In addition, the authors argue, the diversity of the RISC-V hardware ecosystem means that no single mitigation strategy is likely to be effective across all systems. "RISC-V inherits the software and threat model of mature architectures without their accumulated hardening," the authors conclude. "Closing this gap is not a matter of porting individual mitigations, but of building the architectural primitives, hardware transparency, and ecosystemwide tooling that effective Spectre defense presupposes." The authors say they disclosed their findings responsibly last December. Three of their patches have been merged into mainline Linux and two others are under review. SiFive is said to have dealt with P550-specific findings and T-Head (Alibaba) is said to have committed to publishing ad-hoc speculation barriers for their processors at some point. The authors say they decided not to delay publication because Spectre has been around for eight years now. The paper was written by Lukas Gerlach (CISPA Helmholtz Center for Information Security), Marton Bognar, (DistriNet, KU Leuven), Daniel Weber and Michael Schwarz, (CISPA Helmholtz Center for Information Security), and Jo Van Bulck (DistriNet, KU Leuven). ®

L'attacco alla supply chain di WordPres tramite un'API avvelenata rappresenta una nuova e insidiosa frontiera negli attacchi alla sicurezza. Immagina questo scenario: hai installato plugin popolari e affidabili e mantieni tutto aggiornato, ma il tuo sito viene compromesso ugualmente. Come è possibile? Ora non stiamo più parlando di un classico plugin con una falla nel codice. La vulnerabilità, in questo caso, è molto più subdola e colpisce la cosiddetta "supply chain", ovvero la catena di fiducia su cui si basa l'intero ecosistema di WordPress. Infatti in recente incidente ha dimostrato come gli hacker possano sfruttare non il plugin in sé, ma le risorse esterne a cui si collega.

Analizziamo nel dettaglio come funziona questo attacco e, soprattutto, come puoi proteggere il tuo sito.

Come funziona l'attacco alla supply chain di WordPress?

L'attacco ha preso di mira diversi plugin molto noti sviluppati da BdThemes, tra cui Element Pack, Prime Slider e Ultimate Post Kit. Questi strumenti utilizzano un componente interno per mostrare banner promozionali nella bacheca di WordPress. Per farlo, si collegano a un server esterno e recuperano i dati da un semplice file JSON. Ed è proprio qui che si nasconde il problema.

Gli aggressori non hanno violato il repository di WordPress.org né hanno modificato il codice sorgente dei plugin. Hanno invece trovato il modo di compromettere il file JSON ospitato sul server esterno. In pratica, hanno "avvelenato" la fonte dei dati. Il componente del plugin, fidandosi ciecamente di questa fonte, recuperava le informazioni malevole.

A causa di una vulnerabilità di tipo cross-site scripting (XSS), il codice dannoso veniva eseguito direttamente nel browser dell'amministratore del sito non appena accedeva a una qualsiasi pagina del back-end. Un'operazione silenziosa, che si completa in pochi millisecondi e apre le porte del sito agli aggressori.

Per approfondire questo tema, leggi anche il nostro articolo "Attacchi alla supply chain: una minaccia in crescita".

Quali sono le conseguenze per i siti WordPress?

Una volta che il codice malevolo è in esecuzione, le conseguenze possono essere devastanti. L'attacco è progettato per ottenere il controllo completo e persistente del sito compromesso, agendo su più livelli.

Creazione di amministratori fantasma e backdoor

Il primo passo dello script è creare un nuovo account amministratore-truffa. Spesso questi account usano nomi utente prevedibili, come "bd_" seguito da una stringa di caratteri, garantendo agli aggressori un accesso privilegiato e diretto al sito. Successivamente, il malware installa un finto plugin con un nome innocuo, come "wp-smart-thumbnails". Al suo interno, però, si nasconde una webshell: un file, spesso chiamato emer-run.php, che permette agli hacker di eseguire comandi sul server da remoto, come se fossero seduti di fronte al tuo computer.

Meccanismi di persistenza e occultamento

Gli aggressori non si sono fermati al primo accesso, ma hanno puntato alla persistenza. Per assicurarsi di poter rientrare anche se l'account admin venisse scoperto, installavano dei Must-Use plugin. Si tratta di plugin speciali che sono sempre attivi e non possono essere disattivati dalla bacheca.

Infine, per rendere tutto più difficile da scoprire, il malware manipolava il database per nascondere l'account amministratore-truffa dalla normale lista degli utenti. Alterava persino il contatore totale per non destare sospetti: un'operazione studiata per eludere i controlli.

Come rilevare e mitigare l'attacco alla supply chain di WordPress

Anche se la fonte dell'attacco è stata bonificata, il tuo sito potrebbe essere già compromesso. Ecco una checklist pratica per verificare la sicurezza del tuo sito WordPress:

• Controlla gli account amministratore: vai nella sezione Utenti e cerca profili sospetti che non hai creato tu. Presta particolare attenzione a username che iniziano con "bd_" o che utilizzano email strane.
• Ispeziona i plugin installati: verifica la lista dei tuoi plugin e, se ne trovi uno che non ricordi di aver installato, indaga. Controlla anche la cartella mu-plugins tramite FTP o il File Manager del tuo hosting.
• Cerca file malevoli: esegui una scansione dei file del tuo sito alla ricerca di nomi sospetti come emer-run.php o file che iniziano con class-wp-query-.
• Verifica il database: se hai competenze tecniche, cerca nel database opzioni sospette, come fz_emer_login_tokens, che è legata a questo specifico attacco.

L'uso di un plugin di sicurezza affidabile può aiutarti ad automatizzare molte di queste verifiche e a ricevere notifiche in tempo reale.

Una lezione per il futuro: la fiducia non basta

Questo attacco alla supply chain di WordPress è un potente campanello d'allarme per tutta la community. Ci insegna che la sicurezza non riguarda solo il codice che installiamo sul nostro server, ma anche la catena di fiducia che si estende a servizi e API esterne. Infatti un plugin può essere scritto in modo impeccabile, ma se si affida a una risorsa esterna non sicura, diventa un cavallo di Troia. Inoltre questi attacchi non hanno colpito solo WordPress, ma in passato hanno coinvolto anche GitHub.

Per gli sviluppatori la lezione è chiara: ogni dato proveniente dall'esterno deve essere validato e sanificato prima di essere utilizzato. Per gli utenti, invece, la consapevolezza di questi nuovi vettori di attacco è il primo passo per una difesa più efficace.

Ricordati sempre che la sicurezza non è un'azione una tantum, ma un processo continuo di vigilanza e manutenzione.

L'articolo Attacco alla supply chain di WordPress tramite un'API malevola proviene da sicurezza.net.

Trovare i migliori servizi DNS protettivi (PDNS) è diventato un passo fondamentale per la sicurezza informatica di aziende e professionisti. Infatti un servizio PDNS agisce come un guardiano per le tue connessioni, analizzando ogni richiesta DNS e bloccando l'accesso a domini malevoli in modo automatico.

Oggi, strumenti che un tempo erano considerati una "best practice" sono diventati una necessità. Persino agenzie come la NSA e la CISA ne raccomandano l'adozione. Si tratta di una delle misure di sicurezza più efficaci e meno invasive che puoi implementare, perfettamente integrata nei moderni framework di sicurezza a "zero trust".

In questa guida, analizzeremo le 5 soluzioni più performanti sul mercato, con un verdetto rapido per chi ha fretta. Sei pronto a scoprire quale servizio si adatta meglio alle tue esigenze? Continua a leggere.

Cosa sono i servizi DNS protettivi (PDNS)?

Immagina il DNS (Domain Name System) come la rubrica di Internet. Quando digiti un sito web, il DNS traduce quel nome in un indirizzo IP numerico che i computer possono capire, migliorando la tua navigazione web.

Un servizio DNS protettivo fa un passo in più: prima di fornirti l'indirizzo, controlla se quel dominio è presente in una lista di minacce note. Se il dominio è associato a phishing, malware, ransomware o comandi C2 (Command and Control), il PDNS semplicemente rifiuta la connessione. In questo modo, la minaccia viene neutralizzata sul nascere, prima che possa causare danni. È un livello di protezione proattivo, essenziale per difendere ogni dispositivo connesso alla rete.

La nostra classifica dei migliori servizi DNS protettivi

Abbiamo valutato i principali servizi basandoci sui criteri raccomandati da NSA e CISA:

• Qualità e velocità di aggiornamento dei feed di minacce,
• Capacità di rilevamento avanzato (come DGA e tunneling),
• Opzioni di copertura per dispositivi fissi e mobili
• Integrazione con i sistemi di sicurezza esistenti (SOC).

1. Cisco Umbrella

Ideale per grandi aziende che cercano lo standard di riferimento del settore, collaudato e con integrazioni mature. Cisco Umbrella è considerato l'evoluzione di OpenDNS ed è da anni il punto di riferimento nel mercato PDNS. La sua forza risiede nell'intelligence fornita da Talos, uno dei team di ricerca sulle minacce più grandi al mondo. Offre funzionalità avanzate come il rilevamento di algoritmi di generazione di domini (DGA) e tunneling DNS, garantendo una protezione completa.

Caratteristiche principali:

• Intelligence sulle minacce fornita da Talos.
• Rilevamento di DGA e tunneling DNS.
• Integrazione con Active Directory per l'attribuzione interna degli IP.
• Client per la protezione dei dispositivi in mobilità.

Pro: Profondità dell'intelligence, scalabilità comprovata, vasto ecosistema di integrazioni.

Contro: Il costo può essere elevato e le funzioni più recenti tendono a integrarsi strettamente con l'ecosistema Cisco Secure Access.

2. DNSFilter

Ideale per piccole e medie imprese (PMI) e Managed Service Provider (MSP) che necessitano di una protezione efficace, veloce da implementare e con prezzi chiari. DNSFilter brilla per la sua trasparenza e semplicità. Utilizza il machine learning per categorizzare i domini in tempo reale e offre un modello di prezzo per utente chiaro e prevedibile. La sua console di gestione multi-tenant è un vero punto di forza per gli MSP che devono gestire la sicurezza di più clienti contemporaneamente.

Caratteristiche principali:

• Categorizzazione dei domini basata su ML in tempo reale.
• Prezzi pubblici e scalabili per utente.
• Piattaforma nativa per la gestione multi-tenant (MSP).
• Client inclusi per la copertura dei dispositivi mobili.

Pro: Prezzi trasparenti, onboarding rapidissimo (meno di un'ora), strumenti eccellenti per MSP.

Contro: Meno profondità nelle integrazioni enterprise rispetto a Cisco Umbrella.

3. Cloudflare Gateway

Ideale per chiunque voglia iniziare a proteggersi immediatamente, con un piano gratuito solido e un percorso di crescita verso funzionalità avanzate. Cloudflare Gateway sfrutta una delle reti di resolver DNS più veloci e resilienti al mondo. Offre un generoso piano gratuito che permette a chiunque di iniziare a filtrare le minacce in pochi minuti. Man mano che le esigenze crescono, è possibile passare a piani a pagamento che includono SWG, ZTNA e CASB, tutto dalla stessa dashboard. Non a caso, è la tecnologia scelta dal governo britannico per il suo PDNS nazionale.

Caratteristiche principali:

• Rete di resolver anycast enorme e veloce.
• Piano gratuito e piani Zero Trust a prezzi pubblici.
• Supporto nativo per DNS-over-HTTPS (DoH) e DNS-over-TLS (DoT).
• Client WARP per la protezione dei dispositivi in mobilità.

Pro: Si passa da zero a protetti in un pomeriggio, infrastruttura su scala globale, un percorso di crescita flessibile.

Contro: L'attribuzione avanzata tramite Active Directory richiede più configurazione rispetto a Umbrella.

4. Akamai

Ideale per governi, operatori di telecomunicazioni e grandi aziende che necessitano di una risoluzione protettiva su larghissima scala. Akamai Secure Internet Access opera su una delle piattaforme più grandi di Internet. È progettato per assorbire attacchi DDoS massicci e proteggere intere basi di abbonati per gli ISP. La sua forza sta nella vastità della sua infrastruttura e nella visibilità globale che ne deriva per la ricerca sulle minacce.

Pro: Scala e affidabilità massicce, ricerca sulle minacce di alto livello.

Contro: Pacchetti pensati per il mondo carrier/enterprise; il valore massimo si ottiene se si è già clienti Akamai.

5. Infoblox

Ideale per aziende con un'infrastruttura DNS interna complessa che vogliono fondere il PDNS con il contesto DDI (DNS, DHCP, IPAM). Infoblox adotta un approccio unico, applicando l'intelligence sulle minacce direttamente ai resolver DNS che già gestisci. Sfruttando il contesto IPAM, può dirti esattamente quale dispositivo ha effettuato una richiesta malevola e attivare risposte automatiche per metterlo in quarantena.

Pro: Attribuzione nativa delle minacce, applicazione delle policy a livello di infrastruttura.

Contro: Il modello di costo presume l'adozione della piattaforma DDI di Infoblox.

Come scegliere tra i migliori servizi DNS protettivi

La scelta dipende dalle tue esigenze specifiche.

Prima di decidere, poniti alcune domande chiave:

• Qualità delle minacce: Con quale velocità vengono bloccati i nuovi domini malevoli? Richiedi dati concreti.
• Copertura dei dispositivi: Hai bisogno di proteggere solo la rete dell'ufficio o anche i laptop dei dipendenti da remoto? Verifica la disponibilità di agenti per i dispositivi mobili.
• Gestione del DNS criptato: Il servizio offre i propri endpoint DoH/DoT per garantire che il traffico non bypassi la protezione?
• Logging e integrazione: Puoi esportare i log per analizzarli nel tuo SIEM?
• Prezzo: Il modello di costo è trasparente e adatto al tuo numero di utenti?

Confronta due o tre finalisti in base ai precedenti punti. La trasparenza dei prezzi di servizi come DNSFilter rende questo confronto molto più semplice.

Domande frequenti (FAQ) sui PDNS

L'argomento può essere complesso e la scelta può non essere ancora chiara, per questo abbiamo selezionate le domande più frequenti sul tema:

Cos'è esattamente un PDNS? È un servizio di risoluzione DNS che controlla ogni richiesta confrontandola con database di minacce. Se una richiesta è diretta a un dominio malevolo (phishing, malware), viene bloccata prima che la connessione venga stabilita.

Perché NSA e CISA lo raccomandano? Perché è una difesa ad alto impatto e a basso attrito. La maggior parte degli attacchi informatici utilizza il DNS in qualche fase. Bloccarli a questo livello è estremamente efficace e l'implementazione richiede solo di cambiare gli indirizzi dei resolver DNS.

Un PDNS può proteggere dispositivi senza agenti (IoT, stampanti)? Sì, questo è uno dei suoi maggiori vantaggi. Impostando il PDNS a livello di rete (es. nel router), ogni dispositivo che si connette, inclusi ospiti e dispositivi IoT, viene protetto automaticamente senza agenti.

Quanto costa un servizio DNS protettivo? I costi variano molto: si parte dai piani gratuiti di Cloudflare, si passa ai prezzi pubblici per utente di DNSFilter e si arriva alle quotazioni personalizzate per piattaforme enterprise come Cisco Umbrella o Akamai.

Qual è il verdetto finale?

In sintesi, possiamo dire che i migliori servizi DNS protettivi sono:

• Cisco Umbrella, che si conferma lo standard per le grandi aziende.
• DNSFilter, è la scelta di valore predefinita per PMI e MSP.
• Cloudflare Gateway, che offre un percorso incredibilmente versatile, perfetto per chiunque.
• Akamai, perfetto per la scala carrier.
• Infoblox, pensato per l'integrazione DDI.

Ogni servizio ha i suoi punti di forza e di debolezza, ma l'aspetto più importante è sempre quello di agire. Infatti implementare un PDNS è un passo che non puoi più rimandare per proteggere al meglio la tua attività.

L'articolo I 5 migliori servizi DNS protettivi (PDNS) del 2026 proviene da sicurezza.net.

Sembra proprio che tenere a bada i modelli IA sia complicatissimo e Anthropic sta accumulando una certa esperienza nel settore. L’azienda ha infatti rivelato che alcuni modelli della famiglia Claude sono riusciti ad accedere ai sistemi di tre organizzazioni reali durante esercitazioni di sicurezza, trasformando test che avrebbero dovuto svolgersi in ambienti controllati in vere […]

L'articolo Claude evade (di nuovo) e attacca tre aziende reali proviene da Securityinfo.it.

Analizzare i log del proprio sito web può rivelare sorprese inaspettate. Spesso, si notano centinaia di visite attribuite a "Googlebot", e la prima reazione è di sollievo: il crawler di Google sta indicizzando le pagine. Ma è davvero così? La realtà è che molti di questi accessi provengono da un falso Googlebot, poiché l'identità di chi si connette a un server è più facile da falsificare di quanto si pensi.

Perché i log registrano così tanti falsi Googlebot?

Molti bot si spacciano per Googlebot per una ragione semplice: gode di un trattamento privilegiato su quasi tutti i server. Gli amministratori di sistema, per non compromettere l'indicizzazione, evitano di bloccarlo. Questa situazione crea un'opportunità per software di terze parti. Infatti un bot malevolo o uno scraper ottiene enormi vantaggi semplicemente fingendosi il crawler ufficiale di Google, tra cui:

• Evitare i blocchi: numerosi sistemi di sicurezza e firewall sono configurati per lasciar passare senza filtri il traffico di Googlebot.
• Superare i limiti di richiesta: a Googlebot vengono spesso concessi limiti di frequenza (rate limiting) molto più ampi, che gli consentono di scansionare più pagine in meno tempo.
• Aggirare i CAPTCHA: un finto Googlebot può bypassare i controlli anti-automazione, accedendo a contenuti altrimenti protetti.

Un falso log da un Googlebot, trucco a costo zero, è particolarmente utile per chi fa scraping di prezzi, contenuti o dati sensibili, aprendo porte che dovrebbero rimanere chiuse.

Per approfondire l'argomento e capire quali altri tattiche usano gli hacker per accedere al tuo sito, leggi anche il nostro articolo sul tema.

User-agent: l'identità che chiunque può falsificare

Il problema nasce dal funzionamento dello user agent. Infatti si tratta di una semplice stringa di testo che un client, come un browser o un bot, invia al server per identificarsi. Il protocollo HTTP, tuttavia, non include alcun meccanismo per verificare che questa dichiarazione sia vera.

Un client può quindi presentarsi con una stringa apparentemente legittima: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) Vederla nei log fa pensare subito al crawler ufficiale, ma non stabilisce alcun legame crittografico o verificabile tra l'indirizzo IP della richiesta e l'infrastruttura reale di Google. In pratica, il falso log di un Googlebot è come se un estraneo si presentasse a una festa dichiarando un nome falso, senza che nessuno gli chieda un documento di identità.

Come verificare se un log di un Googlebot è falso?

Fortunatamente, esistono metodi affidabili per smascherare gli impostori, raccomandati da Google stessa.

Controllo degli intervalli IP di google

Il primo metodo è molto diretto. Google pubblica e aggiorna un elenco dei suoi intervalli IP ufficiali in un file JSON. È sufficiente programmare uno script per scaricare questo file e confrontare l'IP registrato nei log con le reti autorizzate (sia IPv4 che IPv6). Se l'indirizzo IP del visitatore non rientra in questi intervalli, si ha la certezza matematica che sia un falso log di un Googlebot.

La doppia verifica DNS

Questo secondo metodo è ancora più rigoroso e si basa su una sequenza di controlli DNS, considerata la prova definitiva.

1. Ricerca DNS inversa (PTR): si esegue una ricerca sul record PTR dell'IP di origine. Se è un vero crawler di Google, il nome host risultante deve terminare con googlebot.com o google.com.
2. Ricerca DNS diretta (A/AAAA): a questo punto, si esegue la verifica opposta. Si risolve il nome host ottenuto nel passaggio precedente e si controlla che l'indirizzo IP di partenza sia presente nella lista di IP restituiti.

Se entrambi i passaggi hanno successo, puoi essere assolutamente certo che la visita provenga da un crawler legittimo di Google.

Per approfondire l'argomento, prova anche a leggere questo nostro articolo: "Come rilevare e bloccare l'attività dei bot".

Cosa si scopre dopo una verifica di un falso Googlebot log?

Applicando questi controlli, il quadro del traffico sul proprio sito cambia radicalmente. Quella che sembrava un'intensa attività di indicizzazione si rivela spesso per quello che è: un'orda di bot sconosciuti. Un picco di traffico che credevi positivo potrebbe nascondere uno scraper aggressivo che sta rubando i tuoi contenuti tramite un falso log di un Googlebot.

In più un consumo di banda anomalo potrebbe essere causato da sistemi che mappano il sito alla ricerca di vulnerabilità. Analizzare i log con questi strumenti permette di distinguere il traffico prezioso da quello dannoso, proteggendo le tue risorse in modo efficace. La prossima volta che vedrai un'attività sospetta da "Googlebot", saprai esattamente come smascherare l'impostore.

L'articolo Falso Googlebot nei log: come riconoscere i crawler e proteggerti proviene da sicurezza.net.

Per anni l’idea di un attacco informatico condotto interamente da un agente di Intelligenza Artificiale è rimasta confinata ai laboratori di ricerca e alle presentazioni dei vendor. Oggi non è più così. La piattaforma Hugging Face, punto di riferimento mondiale per lo sviluppo e la distribuzione di modelli AI open source, ha confermato di essere […]

L'articolo Hugging Face violata da un agente AI: gli attacchi autonomi sono arrivati proviene da Securityinfo.it.

Gli strumenti di AI per lo sviluppo software promettono di aumentare la produttività degli sviluppatori, ma una recente analisi indipendente riaccende il dibattito sulla sicurezza dei dati affidati agli assistenti di coding. Al centro della vicenda c’è Grok Build, il tool a riga di comando di xAI, accusato di aver trasmesso (in chiaro) ai server […]

L'articolo Gli assistenti AI di coding sono sicuri? Il caso xAI proviene da Securityinfo.it.

La guerra in Ucraina non si combatte solo sul terreno, nel mare o nello spazio aereo. Il cyberspazio è uno degli scenari più attivi, dove vengono perpetrati quotidianamente decine di attacchi mirati alle infrastrutture civili e militari. Il continuo bersagliamento di infrastrutture energetiche, reti di comunicazione e servizi pubblici ha praticamente trasformato l’intero Paese in […]

L'articolo La guerra ucraina cambia la sicurezza delle infrastrutture critiche proviene da Securityinfo.it.

Oltre 300 sensori, terabyte di informazioni e simulazioni continue. La tecnologia NetApp collega pista, quartier generale e cloud, trasformando i dati in decisioni tecniche e strategiche

L’intelligenza artificiale sta entrando nelle aziende con una velocità che non ha precedenti, ma la sua diffusione sta facendo emergere una realtà che molti responsabili della sicurezza stanno iniziando a sperimentare direttamente: i tradizionali strumenti di difesa non sono stati progettati per proteggere sistemi che ragionano attraverso il linguaggio naturale. Firewall, Web Application Firewall e […]

L'articolo AI, il nuovo fronte della sicurezza: il red teaming diventa indispensabile proviene da Securityinfo.it.

L'eredità tecnologica è importante, ma non tutto è andato come ci si aspettava. Facciamo il punto su 5G, banda ultralarga e Fascicolo sanitario elettronico, tra le altre cose

Con il boom dell’intelligenza artificiale, la sicurezza informatica è diventata un territorio in cui la velocità di attacco e difesa è aumentata esponenzialmente. E sarà sempre più spesso un tema sotto gli occhi (e nelle case) di tutti

La rapida diffusione degli Agenti AI sta creando un ecosistema sempre più complesso nel quale modelli linguistici, strumenti esterni e componenti aggiuntivi collaborano per svolgere attività operative. Questa architettura modulare, però, sta aprendo una nuova superficie di attacco che ricorda da vicino le vulnerabilità già viste nel mondo open source e nei marketplace di applicazioni. […]

L'articolo Falsa skill elude gli scanner e a raggiunge più di 26.000 agenti AI proviene da Securityinfo.it.

Sebbene il numero di casi d’uso nel nostro Paese sia ancora molto basso, le previsioni di tutti gli esperti dicono che gli agenti AI diventeranno i veri “operatori” dell’automazione dei processi in azienda. Il problema è che chi dovrà gestirne la sicurezza non ha ancora l’esperienza necessaria per farsi un quadro chiaro di come questi […]

L'articolo Zscaler porta la Zero Trust nell’era degli agenti AI proviene da Securityinfo.it.

Il nuovo assetto geopolitico mondiale ha messo a nudo una serie di problematiche che sono state trascurate troppo a lungo. In pratica, quello che per anni abbiamo visto accadere nel software, ovvero l’entusiasmo per le nuove feature che andava a coprire la necessità di rendere sicuro il loro utilizzo, si è applicato anche in mille […]

L'articolo Infrastrutture Critiche e Geopolitica: è l’Era dell’Antifragilità proviene da Securityinfo.it.

Un gruppo cybercriminale di lingua cinese fino a poco tempo fa concentrato prevalentemente sul mercato asiatico sta ampliando rapidamente il proprio raggio d’azione verso Europa e Africa. Secondo le analisi pubblicate da Proofpoint, il gruppo chiamato TA4922 ha aumentato sensibilmente il volume delle proprie operazioni nel corso del 2026, prendendo di mira organizzazioni nel Regno […]

L'articolo Il gruppo criminale cinese TA4922 adesso punta anche all’Europa proviene da Securityinfo.it.

A leggere il nuovo “2026 Cloud Security Report” realizzato da Check Point insieme a Cybersecurity Insiders, sembra proprio che l’adozione dell’intelligenza artificiale nelle aziende stia crescendo più rapidamente della capacità delle organizzazioni di proteggerla. Il report, basato sulle risposte di 1.042 professionisti IT e cybersecurity provenienti da organizzazioni di tutto il mondo, mostra un quadro […]

L'articolo Il 78% delle aziende ha già subito o sospetta incidenti legati all’IA proviene da Securityinfo.it.