Blue Shield of California Faces Data Breach Amid Misconfigured Access to Google Ads Platform

Blue Shield of California, a nonprofit health insurance provider, is making headlines this week after revealing that its members’ personal data was compromised in a breach that may have been caused by a misconfiguration or insider threat. Over 4.7 million members are affected, with sensitive data fraudulently accessed by the Google Ads platform.

According to records obtained by Cybersecurity Insiders, Blue Shield was originally meant to share only anonymized data with Google Analytics for research and development purposes. This arrangement was designed to help the company gain insights into its services and improve user experience. However, an unexpected error—whether from a technical misconfiguration or an insider threat—resulted in Google’s advertising platform gaining unauthorized access to private member data. This could have allowed the internet giant to target affected individuals with highly specific, personalized ads.

The breach exposed a range of sensitive information, but fortunately, the situation could have been much worse. Initial investigations by Blue Shield confirm that while some personal data was accessed, critical personal identifiable information (PII), such as social security numbers, driver’s license details, banking information, and credit card numbers, were not compromised. This is because these types of data were securely stored on a separate server and were not part of the breach.

However, the data that was accessed still contains enough sensitive details to raise concerns. The compromised information includes:

A.) Insurance details, such as insurance numbers and types of coverage,

 B.) Demographic data, including the member’s city, zip code, and family size,

C.) Medical history, which could be used for profiling or even discriminatory purposes.

These details, while not as dangerous as full PII data, can still be used in ways that violate the privacy of Blue Shield’s members. The organization has since warned members to stay vigilant against possible identity theft attempts and to be cautious of phishing schemes or fraud that may arise from this breach.

Interestingly, this is not the first time Blue Shield has faced a major cybersecurity incident. Exactly one year ago, the company was targeted by a BlackSuit Ransomware attack, which was linked to Connexure (formerly Young Consulting), a company that provides software and services to healthcare providers, including Blue Shield. The nature of the attacks—along with the similarity in timing—raises questions about whether these events are part of a larger, coordinated effort to exploit vulnerabilities in the healthcare sector.

Despite the severity of the breach and the potential risks for its members, Blue Shield has yet to offer any identity theft protection services to those affected. This decision has drawn criticism from privacy advocates, as such protection is often considered a necessary measure following data breaches of this scale.

For now, Blue Shield is urging its members to remain alert and to monitor their financial accounts and healthcare records for any signs of misuse. However, the company has yet to explain why it has chosen not to extend further protective measures, leaving many members to question the adequacy of its response.

As cybersecurity incidents continue to rise across various industries, this breach serves as a stark reminder of the importance of safeguarding sensitive data, particularly in the highly regulated healthcare space. With the growing reliance on cloud services, analytics, and advertising platforms, organizations like Blue Shield must invest in robust security measures to ensure their data handling practices are both secure and compliant.

The post Blue Shield of California Faces Data Breach Amid Misconfigured Access to Google Ads Platform first appeared on Cybersecurity Insiders.

The post Blue Shield of California Faces Data Breach Amid Misconfigured Access to Google Ads Platform appeared first on Cybersecurity Insiders.

from Cybersecurity Insiders https://ift.tt/uGiaIzj
via IFTTT

In the works – New Availability Zone in Maryland for US East (Northern Virginia) Region

The US East (Northern Virginia) Region was the first Region launched by Amazon Web Services (AWS), and it has seen tremendous growth and customer adoption over the past several years. Now hosting active customers ranging from startups to large enterprises, AWS has steadily expanded the US East (Northern Virginia) Region infrastructure and capacity. The US East (Northern Virginia) Region consists of six Availability Zones, providing customers with enhanced redundancy and the ability to architect highly available applications.

Today, we’re announcing that a new Availability Zone located in Maryland will be added to the US East (Northern Virginia) Region, which is expected to open in 2026. This new Availability Zone will be connected to other Availability Zones by high-bandwidth, low-latency network connections over dedicated, fully redundant fiber. The upcoming Availability Zone in Maryland will also be instrumental in supporting the rapid growth of generative AI and advanced computing workloads in the US East (Northern Virginia) Region.

All Availability Zones are physically separated in a Region by a meaningful distance, many kilometers (km) from any other Availability Zone, although all are within 100 km (60 miles) of each other. The network performance is sufficient to accomplish synchronous replication between Availability Zones in Maryland and Virginia within the US East (Northern Virginia) Region. If your application is partitioned across multiple Availability Zones, your workloads are better isolated and protected from issues such as power outages, lightning strikes, tornadoes, earthquakes, and more.

With this announcement, AWS now has four new Regions in the works—New Zealand, Kingdom of Saudi Arabia, Taiwan, and the AWS European Sovereign Cloud—and 13 upcoming new Availability Zones.

Geographic information for the new Availability Zone
In March, we provided more granular visibility into the geographic location information of all AWS Regions and Availability Zones. We have updated the AWS Regions and Availability Zones page to reflect the new geographic information for this upcoming Availability Zone in Maryland. As shown in the following screenshot, the infrastructure for the upcoming Availability Zone will be located in Maryland, United States of America, for the US East (Northern Virginia) us-east-1 Region.

You can continue to use this geographic information to choose Availability Zones that align with your regulatory, compliance, and operational requirements.

After the new Availability Zone is launched, it will be available along with other Availability Zones in the US East (Northern Virginia) Region through the AWS Management Console, AWS Command Line Interface (AWS CLI), and AWS SDKs.

Stay tuned
We plan to make this new Availability Zone in the US East (Northern Virginia) Region generally available in 2026. As usual, check out the Regional news of the AWS News Blog so that you’ll be among the first to know when the new Availability Zone is open!

To learn more, visit the AWS Global Infrastructure Regions and Availability Zones page or AWS Regions and Availability Zones in the AWS documentation and send feedback to AWS re:Post or through your usual AWS Support contacts.

Channy


How is the News Blog doing? Take this 1 minute survey!

(This survey is hosted by an external company. AWS handles your information as described in the AWS Privacy Notice. AWS will own the data gathered via this survey and will not share the information collected with survey respondents.)

from AWS News Blog https://ift.tt/vPRCq07
via IFTTT

Enhance real-time applications with AWS AppSync Events data source integrations

Today, we are announcing that AWS AppSync Events now supports data source integrations for channel namespaces, enabling developers to create more sophisticated real-time applications. With this new capability you can associate AWS Lambda functions, Amazon DynamoDB tables, Amazon Aurora databases, and other data sources with channel namespace handlers. With AWS AppSync Events, you can build rich, real-time applications with features like data validation, event transformation, and persistent storage of events.

With these new capabilities, developers can create sophisticated event processing workflows by transforming and filtering events using Lambda functions or save batches of events to DynamoDB using the new AppSync_JS batch utilities. The integration enables complex interactive flows while reducing development time and operational overhead. For example, you can now automatically persist events to a database without writing complex integration code.

First look at data source integrations

Let’s walk through how to set up data source integrations using the AWS Management Console. First, I’ll navigate to AWS AppSync in the console and select my Event API (or create a new one).

Screenshot of the AWS Console

Persisting event data directly to DynamoDB

There are multiple kinds of data source integrations to choose from. For this first example, I’ll create a DynamoDB table as a data source. I’m going to need a DynamoDB table first, so I head over to DynamoDB in the console and create a new table called event-messages. For this example, all I need to do is create the table with a Partition Key called id. From here, I can click Create table and accept the default table configuration before I head back to AppSync in the console.

Screenshot of the AWS Console for DynamoDB

Back in the AppSync console, I return to the Event API I set up previously, select Data Sources from the tabbed navigation panel and click the Create data source button.

Screenshot of the AWS Console

After giving my Data Source a name, I select Amazon DynamoDB from the Data source drop down menu. This will reveal configuration options for DynamoDB.

Screenshot of the AWS Console

Once my data source is configured, I can implement the handler logic. Here’s an example of a Publish handler that persists events to DynamoDB:

import * as ddb from '@aws-appsync/utils/dynamodb'
import { util } from '@aws-appsync/utils'

const TABLE = 'events-messages'

export const onPublish = {
  request(ctx) {
    const channel = ctx.info.channel.path
    const timestamp = util.time.nowISO8601()
    return ddb.batchPut({
      tables: {
        [TABLE]: ctx.events.map(({id, payload}) => ({
          channel, id, timestamp, ...payload,
        })),
      },
    })
  },
  response(ctx) {
    return ctx.result.data[TABLE].map(({ id, ...payload }) => ({ id, payload }))
  },
}

To add the handler code, I go the tabbed navigation for Namespaces where I find a new default namespace already created for me. If I click to open the default namespace, I find the button that allows me to add an Event handler just below the configuration details.

Screenshot of the AWS Console

Clicking on Create event handlers brings me to a new dialog where I choose Code with data source as my configuration, and then select the DynamoDB data source as my publish configuration.

Screenshot of the AWS Console

After saving the handler, I can test the integration using the built-in testing tools in the console. The default values here should work, and as you can see below, I’ve successfully written two events to my DynamoDB table.

Screenshot of the AWS Console

Here’s all my messages captured in DynamoDB!

Screenshot of the AWS Console

Error handling and security

The new data source integrations include comprehensive error handling capabilities. For synchronous operations, you can return specific error messages that will be logged to Amazon CloudWatch, while maintaining security by not exposing sensitive backend information to clients. For authorization scenarios, you can implement custom validation logic using Lambda functions to control access to specific channels or message types.

Available now

AWS AppSync Events data source integrations are available today in all AWS Regions where AWS AppSync is available. You can start using these new features through the AWS AppSync console, AWS command line interface (CLI), or AWS SDKs. There is no additional cost for using data source integrations – you pay only for the underlying resources you use (such as Lambda invocations or DynamoDB operations) and your existing AppSync Events usage.

To learn more about AWS AppSync Events and data source integrations, visit the AWS AppSync Events documentation and get started building more powerful real-time applications today.

— Micah;


How is the News Blog doing? Take this 1 minute survey!

(This survey is hosted by an external company. AWS handles your information as described in the AWS Privacy Notice. AWS will own the data gathered via this survey and will not share the information collected with survey respondents.)

from AWS News Blog https://ift.tt/UuhHxTO
via IFTTT

Good Non-Human Identity Governance Means Maturing Your Enterprise Secrets Management

Learn why enterprise secrets management is a key component to building a robust non-human identity governance model and is required for securing the whole organization.

When you think of identity and access management (IAM), you traditionally think of humans. We’ve been managing human access management for decades and are getting progressively better at it. The cycle of onboarding a new employee or user, giving them access to the systems they need, and eventually safely offboarding them has a well-established set of best practices. The IAM tooling vendors re-enforce these governance policies for a good reason: they work.

Today, the enterprise is in a new era. Non-human identities (NHIs) outnumber human identities by a ratio of at least 50 to one. Some estimates put it as high as 100 to one in 2025. It is easy to find consensus that we should do something about NHIs, as the consequences of more and more breaches and leaks stemming from poor machine identity management, particularly credential management, mean we need to find a better path. The question a lot of leaders are asking themselves now is, “What does a good Non-Human Identity governance model look like, and how do we navigate our organizations there?”

The overlapping path of secrets management

There is one element of NHI management that has been studied for a while now, credential management. As all NHIs need a way to authenticate and the governance for storing and using those secrets is definitely part of the larger NHI story. Research into how companies evolve their secrets security practices produced the Secrets Management Maturity Model. 

The model describes organizations transitioning from Level 0, where no secrets security is in place, to Level 3, where enterprise vault technology becomes the standard, and secrets detection is automated at every level of the SDLC, including on the developer’s machine. The most mature organizations at Level 4 are working to remove credentials as much as possible, moving to alternative authentication and authorization strategies for their services and data. 

Secrets Management Maturity Level 0

Companies at the beginning of their journey don’t consistently implement controls around secrets. If they do, they were simple ENV files passed around in plain text. All too often, plaintext credentials are hardcoded into the code itself.

Secrets Management Maturity Level 1-2

As companies mature, secrets management becomes more of a recognized problem. We see the wider adoption of secret management tools, especially those built into cloud platforms like AWS, Azure, or Google Cloud. As long as a company standardizes on the same cloud provider for everything, these work well for putting your secrets somewhere safe, encrypted at rest, and programmatically addressable when needed. The adoption of secret discovery tools to continually find hardcoded credentials in code or surrounding systems has become commonplace, and developer tools to prevent secrets from being leaked in the first place have been introduced. All rotation and remediation efforts are still manual and reactive.

Secrets Management Maturity Level 2-3

Cross-platform centralized vault systems to properly store and manage secrets, such as HashiCorp Vault, Conjure by CyberArk, and Akeyless, get adopted at this stage. Automation becomes one of the main goals, particularly around credential rotation. The developers are involved early and throughout the remediation process as well.

Secrets Management Maturity Level 4

The most mature organizations actually seek to remove credentials as much as possible. Teams move to alternative authentication and authorization strategies for their services and data. These companies establish policies for rapid, possibly automated, remediation, which can only be possible with a sophisticated toolchain leveraged by coordinated teams across the entire organization.

Non-Human Identity Governance Maturity

While secrets management maturity gives us a solid base model and addresses one of the more serious security control concerns, it is not the whole story of NHI governance. We will need to think broader than just the storage and retrieval of the secrets and think about the entire life cycle, ownership, and risk management of our NHIs. But we need to start somewhere

The first step in any threat modeling or organizing exercise is the deceptively simple act of understanding what you have. Did you keep track of when they were introduced? Is there a dashboard or spreadsheet listing them all? While there are a lot of ways you can approach this, one method means properly mapping what secrets exist and understanding how they are used.

Once all of your secrets are discovered, then it’s time to enforce a centralized observable system to keep track of them, ideally in an enterprise secrets vault. A good secrets management platform can track when an NHI’s credential is created and when it’s rotated. They can report on what permissions the NHI holds. They can show when a credential was used and what it connects to. Ultimately, they can help you audit when a key is decommissioned.

It is critical to have this data before we think about broader policies for governance at scale.

Ownership is key

Once your NHIs are mapped and understood, we must address the daunting question of risk ownership. Who should own NHIs in the organization is a subject of much debate. Is it the developer who initially introduces the machine identity into the ecosystem? Is it the DevOps or Platform team who will need to utilize the secret for builds and deployments? Is it the security team, who is on the hook for breaches and incident response?

Today there is no clear consensus in the tech community on who actually should own this. Every company navigates this independently and comes to its own conclusions. No matter who gets ownership responsibility, they will only be successful if they are armed with the right data and insights into their systems.

Evolving IAM To Account For NHIs

The largest and most mature organizations have begun to account for NHIs as part of the overall IAM landscape. This trend will continue for the rest of the industry and at an accelerated pace. The NHI tooling market, which is rapidly emerging, is reacting to more and more leaders looking for a clear and sane way ahead.

Understanding the global lifecycle management of all your NHIs at scale is something that’s going to take a lot of work and alignment across organizations. This goes beyond anything that Security, IT, or DevOps can handle alone or without buy-in from the whole organization.

 

__

Author Bio

GitGuardian Security Advocate – Dwayne has been working as a Developer Relations professional since 2016 and has been involved in the wider tech community since 2005. He loves sharing his knowledge.

The post Good Non-Human Identity Governance Means Maturing Your Enterprise Secrets Management first appeared on Cybersecurity Insiders.

The post Good Non-Human Identity Governance Means Maturing Your Enterprise Secrets Management appeared first on Cybersecurity Insiders.

from Cybersecurity Insiders https://ift.tt/lsEpo1y
via IFTTT

Saudi Cyber Innovation: Redefining SOC Operations

Launch of COGNNA at RSA 2025

Security teams today face an unstoppable challenge—one that isn’t just about technology but about operational endurance. For years, SOC analysts have been inundated with alerts, struggling with fragmented tools and siloed systems that require constant manual oversight. The cybersecurity market has responded with a flood of automation solutions. Yet, many fail to bridge the fundamental gap: the need for a truly unified, intelligence-first approach that reduces noise without losing critical insights.

This problem isn’t unique to any one region or industry—it’s a global crisis in cybersecurity effectiveness. Yet, Saudi Arabia’s emerging leadership in the cybersecurity sector brings a fresh perspective, challenging legacy assumptions about how a SOC should operate.

Saudi Arabia’s Role 

Saudi Arabia is becoming a key player in cybersecurity innovation, driven by national security imperatives within the Kingdom, supported by large-scale investments in AI-led security solutions. This approach isn’t just theoretical—it’s being put into practice with Saudi-backed cybersecurity initiatives that integrate deep telemetry, real-time threat analysis, and AI-driven investigations. 

The Kingdom’s emphasis on scalable, compliance-ready security frameworks also reflects a broader industry need: to shift security operations centres (SOCS) away from reactive alert handling and toward autonomous, guided security operations. 

Why the U.S. Market Matters

As one of the most targeted cybersecurity landscapes, the United States plays a crucial role in validating next-generation security operations centre (SOC) architectures. Enterprises operating within the U.S. face relentless cyber threats, regulatory pressures, and increasing complexity across multi-cloud environments. Yet, many still rely on legacy SOC models that struggle to scale with modern attack surfaces.

Bringing Saudi-developed cybersecurity innovations into the U.S. market offers a unique opportunity to challenge entrenched inefficiencies and accelerate the shift toward proactive security. By adopting modular, AI-driven Security Operations Centre (SOC) frameworks, U.S. enterprises can move beyond outdated incident response models and embrace a future where security operations are driven by contextual intelligence, not just overwhelming volumes of data.

Introducing COGNNA

COGNNA was founded by Ibrahim Alshamrani, CEO, and Ziyad Alshehri, CTO, in 2022. Since then, it has become a leader in the Kingdom with the development of its intelligence-first SOC architecture. Unlike legacy or fragmented SOC solutions, COGNNA’s modular platform merges deep telemetry, autonomous investigations, and guided response into a seamless workflow—eliminating operational silos and enabling security teams to act with complete clarity. 

Designed with flexibility in mind, its architecture adapts to diverse security needs, from multi-tenant MSSPs to regulated financial enterprises. By integrating AI-driven threat analysis and contextual automation, COGNNA doesn’t just detect anomalies—it refines and elevates security insights so organizations can prioritize and respond with confidence.

The Future of SOC Innovation

The launch of COGNNA’s Nexus platform in the USA at RSA 2025 means that American companies will now have access to intelligence-driven, adaptable SOC solutions with AI at their core, helping security analysts within SOCS evolve from siloed, fragmented responses to unified action.

Saudi Arabia is playing a role in shaping the cybersecurity market. Its expertise, combined with the U.S. market’s demand for scalable and analyst-friendly solutions, sets the stage for a more resilient cybersecurity future. The question is no longer whether AI will enhance SOC operations—it’s how quickly organizations will embrace the shift toward intelligence-first security.

COGNNA will showcase the Nexus platform at the Saudi Arabia Pavilion in collaboration with the National Cybersecurity Authority (NCA), Booth 760 in the South Expo.

 

The post Saudi Cyber Innovation: Redefining SOC Operations first appeared on Cybersecurity Insiders.

The post Saudi Cyber Innovation: Redefining SOC Operations appeared first on Cybersecurity Insiders.

from Cybersecurity Insiders https://ift.tt/qPOe0jf
via IFTTT

Attackers hit security device defects hard in 2024

Attackers are having a field day with software defects in security devices, according to a new report released Wednesday by Mandiant 

Exploits were the most common initial infection vector, representing 1 of every 3 attacks in 2024, and the four most frequently exploited vulnerabilities were all contained in edge devices, such as VPNs, firewalls and routers, Mandiant said in its M-Trends report released Wednesday.

“Exploitation of these vulnerabilities represented slightly less than half of all observed vulnerability exploitation,” said Kirstie Failey, principal threat analyst at Google Threat Intelligence Group, under which the Mandiant brand operates.

Threat researchers and federal cyber authorities have been sounding the alarm about attacks targeting network edge devices for more than a year. Since 2024, security device exploits have resulted in attacks on government agencies and some of the most valuable publicly-traded companies in the world.

These lightweight devices and services are designed to improve defenses and prevent intrusions. Yet, because they don’t typically support third-party software, including endpoint detection and response capabilities, organizations are often caught off-guard when attackers gain access to their networks through a highly-privileged system.

“Three of the four vulnerabilities were first exploited as zero-days,” Mandiant said in the report. “While a broad selection of threat actors have recently targeted edge devices, Mandiant also specifically noted an increase in targeting from Russian and Chinese cyber espionage actors.”

A command injection vulnerability in the GlobalProtect feature of Palo Alto Networks’ PAN-OS, CVE-2024-3400, was the most frequently exploited defect across all of Mandiant’s incident response engagements last year. Mandiant said it observed one threat group exploit it as a zero-day, but malicious activities quickly escalated soon after.

Mandiant observed over a dozen threat groups exploiting the vulnerability within two weeks after Palo Alto Networks disclosed the CVE and published a proof-of-concept exploit code in April 2024. Among these was a Ransomhub affiliate, which used the vulnerability — rated a 10 on the CVSS scale — to gain initial access to organizations’ systems and launch a multifaceted extortion campaign.

The next most frequently exploited vulnerabilities in 2024 belong to a pair of defects — CVE-2023-46805 and CVE-2024-21887 — affecting Ivanti Connect Secure VPN and Ivanti Policy Secure appliances, according to Mandiant. Ivanti disclosed the vulnerabilities in January a month after UNC5221, a suspected China state-sponsored espionage group, exploited the vulnerabilities in the wild as zero-days.

Attackers achieved unauthenticated arbitrary command execution on systems by chaining the vulnerabilities together, Mandiant said in the report.

By mid-January 2024, Mandiant observed UNC5135, a group with suspected links to Volt Typhoon, scanning Ivanti Connect Secure appliances but did not observe successful exploitation. Eight distinct clusters, including five suspected Chinese espionage groups, exploited one or more of the Ivanti vulnerabilities, including a third defect tracked as CVE-2024-21893 by April 2024.

An SQL injection vulnerability in Fortinet’s FortiClient Endpoint Management Server, CVE-2023-48788, was the fourth-most frequently exploited vulnerability across all of Mandiant’s incident response engagements last year. 

A financially-motivated threat group exploited the vulnerability within two weeks of Fortinet’s disclosure in March 2024. At the back end of the year, in October and November, another financially motivated threat group tracked as FIN8 exploited the vulnerability to deploy ransomware and steal data.

“Mandiant observed dozens of organizations impacted by exploitation of these vulnerabilities, and our observations are almost certainly only a small fraction of the total number of organizations affected by this activity,” said Kelli Vanderlee, senior manager at Google Threat Intelligence Group. “These campaigns affected organizations across at least 13 industries, located in four different continents.”

Ransomware accounted for 21% of all Mandiant incident response activities last year. These ransomware-related attacks affected organizations in healthcare, local government, energy, technology, education and finance across the Americas, Europe, the Middle East, Asia Pacific and Japan, researchers said in the report.

Brute-force attacks, including password spraying, VPN compromise via default credentials and high-volume remote desktop protocol login attempts, were the most common initial access vector for ransomware attacks last year. Mandiant linked 26% of ransomware attacks to brute-force methods, 21% to stolen credentials, another 21% to exploits, 15% to prior compromise and 10% to third-party compromise.

Mandiant noted that potential deficiencies in enterprise logging and detection capabilities likely contributed to a considerable blind spot with respect to initial access vectors. The incident response firm was unable to determine an initial access vector for 34% of all intrusions.

Mandiant said its annual M-Trends report is based on 450,000 hours of incident response engagements throughout 2024.

The post Attackers hit security device defects hard in 2024 appeared first on CyberScoop.

from CyberScoop https://ift.tt/vuFf3TQ
via IFTTT

DOGE Worker’s Code Supports NLRB Whistleblower

A whistleblower at the National Labor Relations Board (NLRB) alleged last week that denizens of Elon Musk’s Department of Government Efficiency (DOGE) siphoned gigabytes of data from the agency’s sensitive case files in early March. The whistleblower said accounts created for DOGE at the NLRB downloaded three code repositories from GitHub. Further investigation into one of those code bundles shows it is remarkably similar to a program published in January 2025 by Marko Elez, a 25-year-old DOGE employee who has worked at a number of Musk’s companies.

A screenshot shared by NLRB whistleblower Daniel Berulis shows three downloads from GitHub.

According to a whistleblower complaint filed last week by Daniel J. Berulis, a 38-year-old security architect at the NLRB, officials from DOGE met with NLRB leaders on March 3 and demanded the creation of several all-powerful “tenant admin” accounts that were to be exempted from network logging activity that would otherwise keep a detailed record of all actions taken by those accounts.

Berulis said the new DOGE accounts had unrestricted permission to read, copy, and alter information contained in NLRB databases. The new accounts also could restrict log visibility, delay retention, route logs elsewhere, or even remove them entirely — top-tier user privileges that neither Berulis nor his boss possessed.

Berulis said he discovered one of the DOGE accounts had downloaded three external code libraries from GitHub that neither NLRB nor its contractors ever used. A “readme” file in one of the code bundles explained it was created to rotate connections through a large pool of cloud Internet addresses that serve “as a proxy to generate pseudo-infinite IPs for web scraping and brute forcing.” Brute force attacks involve automated login attempts that try many credential combinations in rapid sequence.

A search on that description in Google brings up a code repository at GitHub for a user with the account name “Ge0rg3” who published a program roughly four years ago called “requests-ip-rotator,” described as a library that will allow the user “to bypass IP-based rate-limits for sites and services.”

The README file from the GitHub user Ge0rg3’s page for requests-ip-rotator includes the exact wording of a program the whistleblower said was downloaded by one of the DOGE users. Marko Elez created an offshoot of this program in January 2025.

“A Python library to utilize AWS API Gateway’s large IP pool as a proxy to generate pseudo-infinite IPs for web scraping and brute forcing,” the description reads.

Ge0rg3’s code is “open source,” in that anyone can copy it and reuse it non-commercially. As it happens, there is a newer version of this project that was derived or “forked” from Ge0rg3’s code — called “async-ip-rotator” — and it was committed to GitHub in January 2025 by DOGE captain Marko Elez.

The whistleblower stated that one of the GitHub files downloaded by the DOGE employees who transferred sensitive files from an NLRB case database was an archive whose README file read: “Python library to utilize AWS API Gateway’s large IP pool as a proxy to generate pseudo-infinite IPs for web scraping and brute forcing.” Elez’s code pictured here was forked in January 2025 from a code library that shares the same description.

A key DOGE staff member who gained access to the Treasury Department’s central payments system, Elez has worked for a number of Musk companies, including X, SpaceX, and xAI. Elez was among the first DOGE employees to face public scrutiny, after The Wall Street Journal linked him to social media posts that advocated racism and eugenics.

Elez resigned after that brief scandal, but was rehired after President Donald Trump and Vice President JD Vance expressed support for him. Politico reports Elez is now a Labor Department aide detailed to multiple agencies, including the Department of Health and Human Services.

“During Elez’s initial stint at Treasury, he violated the agency’s information security policies by sending a spreadsheet containing names and payments information to officials at the General Services Administration,” Politico wrote, citing court filings.

KrebsOnSecurity sought comment from both the NLRB and DOGE, and will update this story if either responds.

The NLRB has been effectively hobbled since President Trump fired three board members, leaving the agency without the quorum it needs to function. Both Amazon and Musk’s SpaceX have been suing the NLRB over complaints the agency filed in disputes about workers’ rights and union organizing, arguing that the NLRB’s very existence is unconstitutional. On March 5, a U.S. appeals court unanimously rejected Musk’s claim that the NLRB’s structure somehow violates the Constitution.

Berulis’s complaint alleges the DOGE accounts at NLRB downloaded more than 10 gigabytes of data from the agency’s case files, a database that includes reams of sensitive records including information about employees who want to form unions and proprietary business documents. Berulis said he went public after higher-ups at the agency told him not to report the matter to the US-CERT, as they’d previously agreed.

Berulis told KrebsOnSecurity he worried the unauthorized data transfer by DOGE could unfairly advantage defendants in a number of ongoing labor disputes before the agency.

“If any company got the case data that would be an unfair advantage,” Berulis said. “They could identify and fire employees and union organizers without saying why.”

Marko Elez, in a photo from a social media profile.

Berulis said the other two GitHub archives that DOGE employees downloaded to NLRB systems included Integuru, a software framework designed to reverse engineer application programming interfaces (APIs) that websites use to fetch data; and a “headless” browser called Browserless, which is made for automating web-based tasks that require a pool of browsers, such as web scraping and automated testing.

On February 6, someone posted a lengthy and detailed critique of Elez’s code on the GitHub “issues” page for async-ip-rotator, calling it “insecure, unscalable and a fundamental engineering failure.”

“If this were a side project, it would just be bad code,” the reviewer wrote. “But if this is representative of how you build production systems, then there are much larger concerns. This implementation is fundamentally broken, and if anything similar to this is deployed in an environment handling sensitive data, it should be audited immediately.”

Further reading: Berulis’s complaint (PDF).

from Krebs on Security https://ift.tt/3f2WP9U
via IFTTT

Lattica Emerges from Stealth to Solve AI’s Biggest Privacy Challenge with FHE

Tel Aviv, Israel, April 23rd, 2025, CyberNewsWire

Lattica, an FHE-based platform enabling secure and private use of AI in the cloud, has emerged from stealth with $3.25 million in pre-seed funding. The round was led by Konstantin Lomashuk’s Cyber Fund, with participation from angel investor Sandeep Nailwal, co-founder of Polygon Network and Sentient: The Open AGI Foundation, among others.

Lattica’s technology represents a critical new standard for industries such as healthcare, finance, and government sectors, where data privacy and security concerns have limited AI adoption. According to Cisco’s 2025 AI Briefing: CEO Edition, 70% of CEOs surveyed admitted being concerned about the state of their networks due to the rising adoption of AI, with 34% citing security as a major barrier to adoption. 

Fully Homomorphic Encryption (FHE) – the “holy grail” of cryptography in the last decade – ensures all communication between AI providers and end users remains encrypted, without needing to decrypt it, but due to longstanding computational inefficiencies, FHE has yet to be widely adopted. By capitalizing on the latest breakthroughs in the AI acceleration stack, Lattica leverages advanced acceleration techniques to operationalize FHE. 

Led by founder and CEO, Dr. Rotem Tsabary, who holds a PhD in lattice-based cryptography from the Weizmann Institute of Science, Lattica takes advantage of the foundational mathematical similarities between FHE and machine learning to offer a hardware-agnostic, cloud-based platform that utilizes FHE to deliver secure and private use of AI.

A key differentiator powering Lattica’s solution is its Homomorphic Encryption Abstraction Layer (HEAL), which enhances FHE performance and standardizes its acceleration. A cloud-based service, HEAL serves as a universal bridge connecting FHE applications and AI algorithms across a diverse range of hardware, including GPUs, TPUs, and CPUs, as well as dedicated accelerators like ASICs and FPGAs.

“By combining the advancements of hardware acceleration with software-based optimization, we realized that not only could we improve FHE efficiency to the point of commercial viability, but use it to solve critical data dilemmas holding back AI’s adoption in sensitive industries,“ said Dr. Rotem Tsabary, founder and CEO of Lattica. “We’re enabling practical FHE by developing a solution that is tailor made for neural networks.”

As part of its emergence from stealth, Lattica has made demos of the platform available on its website, alongside insights from an in-depth survey within the FHE community. Survey results validate Lattica’s approach, revealing that a majority (71%) of respondents believe FHE adoption will be achieved through a combination of hardware and software. 

“Lattica is pushing the boundaries of Fully Homomorphic Encryption, solving one of the most critical challenges in AI security,” said Konstantin Lomashuk, Managing Partner at Cyber Fund. “Cyber Fund is proud to have led Lattica’s pre-seed round. This is the kind of deep-tech innovation that defines the future, and we’re excited to see Lattica leading the way.”

Lattica’s focus on healthcare and finance further underscores the platform’s relevance, with potential applications in secure data analysis for medical research and encrypted financial transactions.

“Lattica’s product-first approach fundamentally transforms sensitive data processing in the AI ecosystem,” said Sandeep Nailwal, co-founder of Polygon Network and investor in Lattica. “Lattica has made FHE a reality that is both practical and scalable, as Tsabary and her research team is proving that advances in the machine learning stack can significantly boost the performance of FHE and have an immediate impact on the market.”

About Lattica

Lattica enables querying AI models with Fully Homomorphic Encryption, offering FHE as a hardware-agnostic, cloud-based service. The platform leads in scientific innovation by ensuring that user queries remain encrypted throughout the entire machine learning inference process. Lattica’s Homomorphic Encryption Abstraction Layer (HEAL) connects FHE applications, algorithm implementations, and diverse hardware backends, making secure AI computation as accessible as traditional cloud-based AI services. The company is headquartered in Tel Aviv. For more information, users can visit www.lattica.ai.

Contact

Jordan Chaim
InboundJunction
jordan@inboundjunction.com

The post Lattica Emerges from Stealth to Solve AI’s Biggest Privacy Challenge with FHE first appeared on Cybersecurity Insiders.

The post Lattica Emerges from Stealth to Solve AI’s Biggest Privacy Challenge with FHE appeared first on Cybersecurity Insiders.

from Cybersecurity Insiders https://ift.tt/8dB9kOy
via IFTTT