Search This Blog

Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Latest News

PaperCut NG and MF Flaws Exploited in the Wild, Prompting Emergency Security Patch

  Malicious attackers are actively exploiting newly disclosed vulnerabilities in PaperCut NG and PaperCut MF that can allow unauthorized re...

All the recent news you need to know

Chrome, Edge Extensions Found Stealing Cryptocurrency and Browser Data

 



Nineteen browser extensions for Google Chrome and Microsoft Edge were used to deliver a modular malware framework capable of draining cryptocurrency wallets, stealing credentials and account data, extracting browser history, and displaying ClickFix-style lures.

Application security company Socket identified 18 malicious Chrome extensions and one Microsoft Edge extension as part of a campaign it says may have been operating since February 2024. The extensions contained separate JavaScript modules for different forms of data theft and could receive additional payloads from attacker-controlled infrastructure.

Several of the extensions initially provided the functionality described on their store listings and did not contain malicious code when first published. Socket found that five legitimate extensions were later acquired from their original developers and modified to include the malware. Malicious functionality was then distributed through updates, allowing existing users to receive the altered code without installing a new extension.

One affected extension, “Enable Right Click & Copy — Smart Unlock + OCR,” had at least 70,000 Chrome users when the malicious version appeared. Its Microsoft Edge version had around 10,000 users at the time.

The extensions connect to command-and-control servers through encrypted WebSocket connections. The servers can provide JavaScript modules to the extensions, allowing the operators to add or change functionality without replacing the entire extension. Socket found that the downloaded modules were encrypted before being stored locally and that the framework could use changing C2 infrastructure.

The malware also interferes with protections built into websites. It removes Content Security Policy headers from pages visited by the user, weakening restrictions that can prevent unauthorized scripts and other resources from executing. It then injects malicious JavaScript into websites using hidden HTML elements, giving the attackers a way to interact with pages opened by the victim.

Socket identified 16 malicious modules with different capabilities.

One group of modules targets cryptocurrency wallets across Ethereum Virtual Machine-compatible networks, Solana and Tron. The malware can interfere with legitimate “Connect Wallet” and “Swap” buttons, redirecting transactions or wallet connections to attacker-controlled destinations.

Another module targets users visiting Ledger and Trezor websites. Instead of allowing the legitimate pages to operate normally, the malware can replace them with convincing phishing pages designed to obtain wallet recovery seed phrases. Access to a seed phrase can give an attacker control over the associated cryptocurrency wallet.

The framework also targets cryptocurrency services including Coinbase, Binance, Kraken, OKX, MEXC, KuCoin, Bybit and MetaMask. Its modules can collect session information, authentication tokens, account details and wallet balances from these services.

Credential theft extends beyond cryptocurrency platforms. A separate component can record information entered into forms across websites, including usernames, passwords and other form data. Additional modules collect information associated with Facebook and LinkedIn accounts, while another extracts browser history.

The campaign also incorporates ClickFix-style social engineering. The malware can display fake browser-update messages that instruct users to perform actions on their computers. In the observed implementation, the attacker can place a command in the clipboard and persuade the victim to paste and execute it. This technique shifts part of the attack from automated browser compromise to user-assisted execution.

The extension acquisition strategy adds another layer to the campaign. Browser extensions can receive updates after installation, meaning users who originally downloaded a legitimate utility may later receive altered code. Chrome's extension update process can automatically check for and install updates, so the user does not necessarily need to revisit the Chrome Web Store for the malicious version to reach an existing installation.

Google removed the identified malicious extensions from the Chrome Web Store. Socket also reported the Microsoft Edge extension to Microsoft. At the time of Socket's investigation, however, the Edge version remained available and its operators had changed the C2 domain used by the malware.

Socket said the 16 modules it identified may not represent the framework's complete capabilities. Its modular design allows operators to introduce additional functionality and deploy new payloads through the C2 infrastructure.

Users who installed any of the affected extensions should remove them and treat credentials entered while the extensions were active as potentially exposed. Passwords for affected accounts should be changed, with additional authentication protections enabled where available.

Cryptocurrency users whose wallets may have been exposed should consider the wallet compromised and transfer remaining assets to a newly created wallet with a newly generated recovery phrase.

PaperCut Zero-Days Exploited, Emergency Patch Released

 

PaperCut Software has released a second emergency patch after confirming that attackers exploited two zero-day vulnerabilities in its NG and MF print management products. The flaws can be abused by unauthenticated attackers to bypass authentication and achieve remote code execution on affected PaperCut instances. 

The two issues are tracked as CVE-2026-81578 and CVE-2026-82078. CVE-2026-81578 is a high-severity authentication bypass that lets a remote attacker modify certain system configurations, while CVE-2026-82078 is a critical weakness tied to unsafe dynamic class loading in the database connection utilities. 

PaperCut said that if an attacker can manipulate system configuration parameters, arbitrary Java bytecode on the application classpath may execute under the security context of the PaperCut server process. The company first issued a security bulletin on August 27, then released an emergency patch on August 28 for versions 25 and 26, followed by a second patch later the same day to add more hardening, including support for version 24. 

Security firms monitoring the exploitation, including Huntress and WatchTowr, helped clarify that the incident involved two zero-days rather than one. WatchTowr said it found multiple patch bypasses and an additional authentication bypass flaw, which appears to have driven the need for the second emergency release. Huntress reported attacks against at least two customers, with the first exploitation attempts seen on August 26. The observed activity has so far focused on system discovery, and investigators have not seen secondary malware, command-and-control traffic, or signs of persistence from the recovered payload. 

PaperCut continues to update its advisory and is still working on a full official release that patches both vulnerabilities. The vendor also published indicators of compromise, giving defenders additional artifacts to search for across exposed systems. The wider risk is significant because PaperCut has been targeted before, and CISA’s Known Exploited Vulnerabilities catalog already includes three other PaperCut flaws, two of which were used in ransomware attacks. ShadowServer data suggests roughly 1,000 PaperCut instances are exposed on the internet, with most located in North America and Europe, making timely patching and exposure review essential for organizations running these print management platforms.

How We Find Critical Vulnerabilities with GLM 5.3 and Red Clippy

Over the last few months our red team exercises for BFSI customers have been run with an AI coding agent sitting in the loop. The findings that came out of them were the usual serious ones: broken authentication, unauthenticated access to sensitive data, an OTP bypass, SSRF, stored XSS, a login form that let us straight in with the password field left empty, a customer search that handed back the entire database when given a wildcard, and on one engagement a payment gateway secret key shipped inside a JavaScript bundle that every visitor's browser downloads.

None of that is exotic. Testers have been finding these things for twenty years. What changed for us was how the work got done, and more importantly, how it got kept.

Give a coding agent a shell and it turns into a fast, tireless tester. It runs the same tools you do. It will read a four megabyte minified bundle line by line without complaining, which is a thing no human on the team volunteers for. It will enumerate an API surface while you are still reading the scope document.

The trouble starts about forty minutes in. The context window fills up. The session compacts, or it ends and you start a fresh one the next morning, and the engagement goes with it. The new session re-scans hosts it already cleared. It re-tests things it already ruled out. Ask it which parts of the scope have been covered and it cannot tell you, because it does not know. And somewhere in a transcript nobody kept there is a confirmed injection that never made it into the report.

That is the problem Red Clippy(https://github.com/CSPF-Founder/red-clippy) exists to solve.

An engagement overview. All the screenshots here come from the project's demo database, not from a customer engagement.

It is not an AI pentesting framework

Red Clippy has no scanning engine of its own, no autonomous attack logic, and no opinion about what should be tested next. It will not find a vulnerability for you.

What it does is keep the record of an engagement while an agent does the testing and you direct it. Targets, scope, what has already been tested, findings, evidence. That is the whole job.

It is built for testers who already know what they are doing and want to use Claude Code, Codex CLI, or any other MCP-compatible client alongside their normal workflow. You define the target and scope in the panel, or paste the customer's scope list into the chat and let the agent enter it. From there you guide the agent however you like, the same way you would guide a junior on the team, and it writes down what it did as it goes.

That turns out to be useful for four things: knowing what has already been tested, checking the same finding across multiple domains and assets, keeping engagement history for periodic retesting, and not having to rely on the model remembering everything or on a folder of text files pretending to be a database.

The setup

Three pieces, all on one machine. GLM 5.3 from z.ai does the reasoning. Claude Code is the client, providing the shell, the file access and the agent loop. Red Clippy holds the record and connects to Claude Code over MCP.

Because it is a client rather than a model, and z.ai serves an Anthropic-compatible endpoint, you can point one at the other and keep the agent harness you already know. The setup is documented on the project page, so we will not repeat it here.

MCP runs client-side, so Red Clippy does not know which model is behind the agent and the tools behave the same either way. That means the discipline of the engagement is not tied to a model you happen to be using this quarter. If we move off GLM next year, the record, the coverage and the findings all survive the move.

The rules arrive before the first tool call

This is the part most people skip when they wire an agent into a workflow, and it is the one that changed our output the most.

An agent that has to ask for the rules of engagement generally will not bother. So Red Clippy hands over a Red Team Instructions document during the MCP handshake, before the agent makes its first tool call. It is one document, not a system prompt maintained in five places, and the most specific one wins: a per-engagement override if there is one, otherwise the organization default, otherwise the built-in.

The Red Team Instructions document, served to every agent on connect and overridable per organization and per engagement.

Most of it is unglamorous. The line that matters most on BFSI work is the one about taking the minimum access needed to show impact. An agent that proves an unauthenticated data exposure by retrieving three records and stopping has given you a finding. An agent that helpfully retrieves the whole table has given you a very different conversation with the customer.

The rest is tradecraft, and that is where several of our critical findings actually came from: read the main bundle rather than grepping it, trigger errors deliberately and read the whole response, strip the auth header and retry, then change the identifiers and see whose data comes back.

None of that is new methodology. It is what a competent tester does anyway. The difference is that it is in the agent's context on every connect, without anyone remembering to paste it in.

Setting up an engagement

You create the pentest, paste in the scope from the engagement letter, mark the in-scope domains and ranges, and mark the exclusions. You can type them yourself or let the agent enter them from the customer's list. Either way you read them before anything gets touched.

Scope units are assets, each with its own checklist, reachability marking and in or out of scope flag.

After that you drive, and the instructions are duller than people expect. "Do the initial recon first, subdomain enumeration across the in-scope domains." "Now go through the asset list, pick up whatever is still untested, and mark the checks off as you clear them." The agent runs its own tools from its own shell, the way it would anyway, and posts the results back as it works. Raw scanner output goes in with a single call and gets parsed automatically, whether it came from nmap, Burp, Nessus, OpenVAS, masscan, naabu or subfinder. The things you are actually testing become assets. Everything else stays an observation attached to an asset. Findings go in with severity, a CVSS vector, a proof of concept and the evidence that backs it.

There are 82 MCP tools, which is nearly everything the panel itself can do. That matters more than it sounds, because a tool set that only covers half the application forces you back into the browser mid-session to finish what the agent started. Anything the agent writes you can write yourself, and anything you write it can read. You can run the engagement entirely by hand, entirely through the agent, or switch between the two in the middle of a session.

What a record does that a transcript cannot

The interesting part is not that the agent is fast, although it is. It is that the work survives the session it was done in.

Recon noise stays out of the scope list, which is why it survives

Every content discovery run produces hundreds of paths. Every bundle you read produces endpoints, internal hostnames, technology fingerprints and, now and then, a secret. Throw all of that into an asset list and the asset list is useless by lunchtime.

Red Clippy separates the two. The things you are testing are assets. Everything else is an observation hanging off the asset it came from, with a kind and the tool that found it.


A few observations are findings in their own right, like a key that should never have been public. Most are leads, and the leads are what pay off later. On our engagements, unauthenticated access to sensitive data came from an API path pulled out of a bundle, called with no auth header, that returned data.

In a transcript that path scrolls away. As an observation it is still there tomorrow, attached to the right host, with the tool that found it recorded alongside.

Correlating things that happened days apart

The findings that matter are rarely one observation. They are usually two, made hours or days apart, that mean something together.

Reading the front-end bundle early in an engagement turns up internal hostnames. They go into the record and testing moves on. Days later, a parameter that fetches a remote image turns out to make outbound requests.

An SSRF is only worth what you can reach with it, and the hostnames from the first day are what you point it at. Making that connection requires the first day's record to still be there, and searchable, when you need it days later. That is exactly what a context window does not give you.

Red Clippy makes those joins explicit. Every finding carries tags for the asset it affects and the check it came from, so it files itself under both. The attack graph lets you link any two things, an observation, an asset or a finding, with a label of your own, then follow the links out from one or trace the route between two. The chain from "hostname found in the bundle" to "reachable through SSRF" to "admin interface behind it" is saved, rather than something to piece back together when the report is written.

Correlating across engagements

A customer is rarely one engagement. There is this quarter's, last quarter's, and the retest after that.

Because those engagements share a record, any host or IP can be asked about across all of them at once. Have we tested this before? What did we find? Was it reachable last time?

That pays off twice over. A critical bug in one API is a question about every other API the customer has: we confirmed one in a session, and a later session testing a different domain found the same bug there, because the first finding was something to check the new asset against rather than a paragraph in a transcript nobody reopened. And a host that was blocked last quarter but answers this one has almost never changed. It is a source address or a VPN, and knowing that saves an hour of chasing a WAF that is not there.

The same goes for paths. Whatever was recorded for a host in an earlier engagement can be pulled into the current one, so you get last round's content discovery for free and can see at once whether what you reported then is still live.

Coverage you can query instead of remember

There are 135 built-in checks mapped to OWASP WSTG, plus recon, network, cloud and OSINT checks, tracked per asset.


This is the best defence we have found against the way agent-driven testing actually goes wrong. It is not hallucination. It is skimming. An agent that stumbles onto an interesting SQL injection in the first twenty minutes will happily spend the rest of the session on it and then report a thoroughly successful engagement.

Asking what is left on an asset gives you the current state of every check, so "what have I not looked at on this host" becomes a question with an answer. Marking a check as not applicable counts as resolved, and that matters: "we looked, there is no file upload here" is a genuine testing outcome and belongs in the record rather than sitting in the untested pile forever.

The auth, authz and session categories are where OTP bypass and broken authentication live, and they are exactly the checks an excited agent skips on its way to something noisier. The blank password came out of exactly that part of the list: a login check nobody would call interesting, and a form that issued a valid session when the password field was submitted empty. Nothing would have gone back to that check if the record had not been sitting there saying it was untested. A count of resolved checks against the total is an honest statement about where an engagement stands. "I tested the application thoroughly" is not.

Findings that hold up to review

A finding has to stand on its own, because whoever reviews it will not have the tester sitting next to them explaining what they meant.



A finding carries severity and status, a CVSS vector, CWE and CVE, and separate fields for details, impact, proof of concept and remediation, because those are what a report needs and what a reviewer checks.


The proof of concept field is the one that does the work. It either contains steps that reproduce or it does not, and a reviewer can tell which without asking anyone. Evidence attaches to the finding itself rather than living in a folder someone has to match up later.


The rules for writing a finding sit inside the tool the agent calls to file one, so it reads them as it writes rather than somewhere far back in the session. They tell it to keep each field to a paragraph, keep hostnames out of the title, and say what needs to change in the remediation instead of pasting config and version numbers that may be wrong for the customer's stack.

What the human still does

The agent is fast and it is sometimes wrong, and the workflow assumes both. Everything it writes is an ordinary row in the browser that you can edit, reclassify or delete, and it picks up your corrections the next time it reads.

Three habits do the work. We read the findings themselves rather than the agent's account of them, because the finding rows are what the customer actually gets. We check the coverage before believing any of it, because an agent can come back with six findings having cleared nine checks out of 135. Findings are not coverage. And we set the severity ourselves, because whether something is a finding at all, and how bad it is, is a call a human should make.

The thing that does not change is responsibility. Scope marking and the Red Team Instructions are guardrails, not authorisation. Red team exercises run under a signed engagement letter, and the agent acts entirely on your authority. Everything it does is yours.

What the model does and what the record does

GLM 5.3 does the reasoning. Reading a minified bundle and noticing that a string is a live key. Stripping the auth header off a request and noticing the data still comes back. Putting a single wildcard into a customer search field, then reading the response closely enough to work out that it had returned every customer in the database rather than an error. Going back at an OTP flow after the obvious attempt failed. That is a model capability question, and a better model gives you better testing.

Red Clippy is what makes that add up to an engagement. It contributes memory, correlation, coverage and evidence discipline, and it contributes them identically regardless of what is driving the agent. The two together are why a session ending no longer takes the engagement with it.

Red Clippy was originally our own internal tool, built for our engagements. We have now put it out publicly, because we think other testers will get the same use out of it. It is open source, from the Cyber Security and Privacy Foundation. Source is at github.com/CSPF-Founder/red-clippy and the documentation, including how to set all of this up, is at cspf-founder.github.io/red-clippy. Bug reports and any other contributions are welcome.

Face ID and Fingerprint Unlocks May Put Your Privacy at Risk

 

Face ID and fingerprint unlock features allow for more convenient smartphone and account access but offer less privacy in the case of forced disclosure. According to PCMag , the police can compel an individual to unlock a phone using biometrics but not with a pin or password. The debate over the convenience versus safety of biometric verification became a heated topic this year after the FBI stormed the home of Washington Post reporter Hannah Natanson. 

The court records obtained by the 404 Media revealed that the bureau was unable to open Natanson’s iPhone due to it being protected by Lockdown mode. However, a federal judge later issued a warrant compelling Natanson to unlock her computer using fingerprint. Facial recognition and fingerprint scans are termed biometrics. They can be used to authorize access to computers, phones, and other technology. With passkeys, one can also digitally unlock online accounts and services. 

A passkey can be generated using biometrics or a passcode on a device with lock options. PCmag points out that there is nothing wrong with wanting convenience over security. On the contrary, those at higher risk of government and corporate surveillance and thus prone to coercion should consider using a passcode or passphrase instead of biometric verification. iPhone users can also consider using Lockdown mode. This setting is useful in preventing unauthorized access to the device by eliminating the option of attaching files through messages, installing device management configuration profiles, calls, and FaceTime. 

The option is available in Settings under Privacy and Security. Android also has a lockdown setting that can be used to disable biometric options to secure the smartphone in cases where the owner is fearful that their fingerprint or facial scan might be compromised. Android 13 and later versions offer Advanced Protection mode which requires hardware security keys or passkeys to access Google accounts. It also prevents the downloading of malicious apps and files and stops unauthorized access to Google services by third-party apps. Those wishing to turn off biometric verification can delete their prints or scans from their devices. 

According to PCmag , fingerprints and facial scans are saved on the phone or computer and not on the cloud. Android users can delete their biometric data by heading to Security and Privacy and tapping Device unlock/Biometrics and setting a passcode. iPhone users can go to Face ID/Touch ID & Passcode and reset Face ID or delete their fingerprint. 

PCMag contends that phone security is only a small component of personal security. One should also read the terms and conditions of technology companies, close online accounts that are not necessary, reduce digital footprints, and utilize different strong passwords to gain more control of personal data.

Hasbro Data Breach Impacts Employee Personal Information


The Hasbro Company has notified its employees that their personal information could have been exposed as a result of a data breach involving one of their compromised employee accounts. The company informed the Massachusetts Attorney General's Office of the incident in breach notification letters. 

As indicated in the notices, the information involved varies according to the individual and can include names, email addresses, postal addresses, phone numbers, national identification numbers, and financial information. Hasbro has not provided any information about the number of individuals affected or the date of discovery of the breach. It has been reported that, according to records published by the Massachusetts Attorney General's Office, 436 residents of the state were affected. 

The company has approximately 4,600 employees worldwide, with a significant number based in the United States. Hasbro may have suffered a cyber attack in late March that resulted in the company shutting down several systems. While working to contain the cyberattack, the disruption affected its operations. 

Immediately following the incident, Hasbro disabled the compromised employee account, terminated unauthorized access, and implemented additional security measures. There has been no public disclosure of how the account was compromised or whether attackers were able to access the exposed information. Among the information affected by the breach in Massachusetts was the social security number of the employee, financial account details, credit card information, and driver's license data. 

Details of Hasbro Breach Remain Limited 

It has not been disclosed by Hasbro how the employee account was compromised, the duration of the unauthorized access, or whether the information was actually removed from its systems. Based on the company's notification, it appears that the information involved differs between affected individuals, making it difficult to establish the exact scope of the exposure. Furthermore, it has been raised that the incident may have extended beyond employee records. 

Public reporting has not established whether customer information was accessed, nor has a ransom demand or the identity of the attackers been confirmed. The employee data incident occurs months after Hasbro released a separate cyberattack on March 28 that compromised its data. Due to that attack, some of the company's systems were taken offline, disrupting manufacturing, shipping and order processing. 

Hasbro warned that delays could continue for weeks and hired third-party forensic specialists to investigate the incident. Although there is no indication that the March attack was directly related to the employee data breach, the available reporting does not suggest a direct link. If Hasbro does not provide evidence linking the two incidents, it is more accurate to treat the two incidents as separate events. 

Hasbro's disruption extended beyond corporate systems, affecting the company's ability to produce products, ship orders, and process new orders as well. However, the March attack nonetheless illustrates the broader impact a compromise can have on a major manufacturer. In the case of employees whose Social Security numbers, financial details, payment card information, or driver's license data was compromised, the consequences could extend beyond the initial disclosure.

Identity theft, fraudulent transactions, targeted phishing campaigns, and attempts to gain access to other accounts can all be perpetrated using this information. As a result of the compromised employee account being disabled, unauthorized access was ended, and additional safeguards were implemented. There have been no additional public details provided by the company regarding the technical cause of this compromise or the procedure used to determine the full extent to which the data was exposed. 

Hasbro Provides Protection Services to Affected Employees

Upon conducting an investigation with the assistance of external cybersecurity specialists, Hasbro concluded that personal information belonging to current and former employees may have been accessed during the incident. Hasbro reported that there are no indications of misuse of the exposed information at the time. As a precaution, Hasbro is offering identity protection services to affected individuals through a third-party provider. 

The company advised those affected to monitor their account statements as well as obtain their free credit reports in order to detect any unusual activity. Following the investigation, Hasbro said additional safeguards were implemented. The circumstances surrounding the exposure remain unclear. Hasbro has not confirmed whether customer information was exposed, nor has it made any disclosure as to whether ransom was demanded by the attackers. 

A threat actor has also not been publicly identified by the company. A question was made regarding whether the employee-data exposure was related to the March cyberattack, but Hasbro did not confirm an association between the two incidents. Hasbro suffered significant financial losses as a result of the earlier attack. Approximately $25 million was lost from revenue as a result of operational disruptions, and approximately $11 million was spent responding to and cleaning up the incident directly. 

As no further information has been released regarding the compromised account or the number of individuals affected, it is unclear as to the extent of the employee-data exposure. Despite Hasbro's latest disclosure confirming employee information was compromised, key questions about the intrusion and its relationship with the earlier cyberattack remain unanswered. 

In light of this incident, it becomes evident that compromised employee accounts pose serious risks as well as the potential impact of unauthorized access to sensitive workforce data. In order to determine the full scope of the breach, Hasbro will need to conduct a thorough investigation and implement protective measures.

British Navy Drones Flagged Over China Link

 

British military drones have come under attention after a report claimed that Chinese-made cameras fitted in Royal Navy K3 surveillance drones were sending signals to an internet address in China. The drones were part of a defense package linked to Britain’s plans to help secure freedom of navigation in the Strait of Hormuz, and they had already been used in preparations for the Gulf mission. 

According to the report, the issue was found in drones used by the elite Royal Marines and supplied through Kraken Technology Group, a British defense contractor. The cameras were obtained from a third-party supplier that had given assurances about their security, but an investigation later found “heartbeat communications” from the devices to an IP address in China. Those signals were said to confirm that the cameras were online and functioning normally. 

The Ministry of Defence has rejected the suggestion that sensitive information was exposed. An MoD spokesperson said a routine cyber vulnerability assessment found an issue involving a Kraken Unmanned Surface Vessel subsystem, but that a thorough investigation found no evidence that MoD data or systems were accessed, compromised, or transmitted externally. After the problem was identified, internet connectivity was removed from the cameras. 

The report has revived wider concerns in Britain about Chinese-linked components in strategic systems. The K3 Scout model has also been bought by the US Special Operations Command and has taken part in NATO trials in the Baltic, which has added to the sensitivity around the case. Conservative figures have called for an urgent audit of military equipment for hidden Chinese parts and other vulnerabilities. 

The controversy also fits into a longer pattern of British security warnings about China. The UK banned Huawei from its 5G network in 2020 over national security concerns, while MI5 later warned lawmakers that Chinese intelligence services were trying to interfere with and influence Parliament. In that context, the drone-camera episode is likely to intensify pressure on the government to tighten supply-chain checks and reassure allies that Britain’s military systems remain secure.

Featured