A data breach doesn’t have to hit the company you shopped with directly to put your information at risk. 

That’s the lesson from this week’s Pokémon Center breach. Customers in the United Kingdom and Germany are being notified that personal and order information was exposed after attackers compromised CEVA Logistics, the third-party company used to fulfill and ship Pokémon Center orders. 

The good news: Pokémon Center says CEVA did not have access to customers’ payment-card information.  

The bigger concern is what criminals could potentially do with the information that was exposed, particularly when it can make a phishing message look unusually convincing. 

What Happened in the Pokémon Center Data Breach? 

According to breach notifications reviewed by BleepingComputer, attackers may have obtained Pokémon Center customers’ full names, mailing addresses, phone numbers, email addresses, and information about the products they ordered. The affected customers were in the UK and Germany. 

The intrusion occurred at CEVA Logistics rather than Pokémon Center itself. Reporting indicates attackers accessed CEVA systems between late July and August 1, disrupting operations at eight European warehouses and affecting multiple retailers. Valve previously notified European Steam hardware customers that their information had also been exposed through the CEVA incident. 

Why Does Shipping Data Matter to Scammers? 

A name and email address may not seem as sensitive as a credit-card number. But when criminals also know your address, phone number, and what you recently bought, they have something valuable: context. 

Context helps scammers make phishing messages believable. 

Phishing is when a criminal pretends to be a trusted company or person to persuade you to click a malicious link, hand over a password, share personal information, or send money. 

After a breach like this, criminals could potentially impersonate Pokémon Center, a delivery company, or another retailer and reference details that make their message feel legitimate. 

They might claim an order needs to be rescheduled, a delivery fee must be paid, or a refund is waiting. Knowing that you really placed an order can make the bait much harder to spot. 

Importantly, there is currently no evidence that the stolen Pokémon Center information is being used in such a campaign. But personalized phishing is a common reason breached contact and transaction information deserves attention. 

Key Takeaways 

Pokémon Center says the breach occurred at its logistics provider, CEVA, not its own shopping platform. 

  Names, addresses, phone numbers, email addresses, and order details may have been exposed. 

  Pokémon Center says payment-card information was not available to CEVA. 

  Real order details could make future phishing or delivery scams appear more credible. 

  Customers should independently verify unexpected messages about refunds, cancellations, or deliveries. 

3 Easy Safety Actions to Take If Your Information Is Exposed in a Data Breach 

Getting a breach notification doesn’t necessarily mean someone has already misused your information. It does mean you should take a few steps to make that information harder to use against you. 

1) Find out exactly what was exposed. Read the company’s breach notice carefully. An exposed email address calls for different precautions than a stolen password, Social Security number, financial information, or medical record.

2) Secure the accounts that could be at risk. Change any exposed or reused passwords, use a unique password for every account, and turn on multi-factor authentication where it’s available. If sensitive financial or identity information was stolen, consider a credit freeze or fraud alert as well.

3) Be extra skeptical of messages that know something about you. Breached information can help scammers create convincing emails, texts, and calls. A message that knows your name, address, recent purchase, or other real details isn’t necessarily legitimate. Go directly to the company’s website or app to verify unexpected requests rather than clicking a link or calling a number in the message.  

How McAfee Protects Against Breaches 

Before a breach  

Personal Data Cleanup reduces your digital footprint by removing your personal information from many data broker sites, making it harder for scammers to find and target you.  

Online Account Cleanup scans for accounts you no longer use and helps you delete them, along with your personal info.  

During a breach  

Identity Monitoring watches for your personal information, including email addresses, driver’s license numbers, passport numbers, bank accounts, credit cards, Social Security numbers, phone numbers, and more, across the dark web and known data leaks.   

Plus, we alert users on average up to 10 months earlier than similar services, so you can act fast when your personal information appears where it shouldn’t.  

After a breach  

Scam Detector identifies suspicious texts, emails, and links that often follow major breaches, while web protection blocks malicious websites designed to steal even more of your information. 

Other Scam and Security News This Week 

FBI warns about callers impersonating federal agents. The FBI’s Boston Division is warning about scammers who spoof its real phone number, pretend victims are connected to crimes, and then try to move conversations onto encrypted messaging apps. The key reminder: caller ID can be faked, and the FBI says it will not call private citizens to demand payment, threaten arrest, or request sensitive information. 

(Source: FBI Boston) 

CareCloud breach grows to more than 3.75 million patients. Healthcare technology company CareCloud has confirmed with federal regulators that hackers stole personal and medical information belonging to more than 3.75 million people, including Social Security numbers, health information, government-issued ID numbers, and some financial data. Because medical and identity information cannot simply be replaced like a password, affected people should take breach notifications particularly seriously. 

(Source: TechCrunch) 

Hacker claims millions of corporate directory records were stolen. A cybercriminal known as “TheHatman” is offering databases allegedly taken from the Microsoft Azure and Entra environments of several major companies, although some named organizations dispute that their current systems were breached and say portions of the information appear old. Even older employee information can still be useful for impersonation and targeted phishing, so the claims are worth watching without treating every advertised dataset as independently confirmed. 

(Source: TechRadar) 

This Week’s Safety Tips 

✓ Treat unexpected delivery messages with caution. Open the retailer or carrier’s official app or website instead of following a link in a text or email. 

✓ Don’t trust caller ID alone. Scammers can spoof a legitimate organization’s real phone number. 

✓ Use unique passwords and multi-factor authentication. Stolen personal information becomes more dangerous when criminals can also get into your accounts. 

✓ Pay attention to breach notices. Knowing exactly what information was exposed helps you recognize the scams criminals may try next. 

And we’ll be back next week with more cybersecurity news and scam alerts. 

The post Pokémon Center Breach Shows Why Your Delivery Data Matters: This Week in Scams appeared first on McAfee Blog.

One of the best ways to lower your AWS bill by 99 percent or more is by not checking your keys into public GitHub repositories. Many of us have done this inadvertently over the years, and the defenses against it have improved dramatically (my personal favorite being "using non-ephemeral credentials derived from OIDC or SSO is an anti-pattern"), but it still happens. On Friday, BleepingComputer reported on a Truffle Security finding that hundreds of leaked AWS keys are root keys and are somehow still active and valid. AWS Security is full of very smart people who care deeply about a number of things, including "not abetting crime." If they detect (usually via automated means) that a credential has been leaked, they're quick to apply a Quarantine Policy to it. Trouble is, that policy enumerates a bunch of bad behaviors in an ever-expanding graph of principals and associated behaviors. AWS' considered position on this is that they don't want to break customer environments: "The policy aims to limit the potential damage that may be caused by fraud-related activity leading to unauthorized charges, while not impacting the existing resources." AWS' considered position on this is wrong. If I get access to your credentials (much less a root credential, good god), deactivating them may very well break your workload because anything that relies on those credentials will start failing. Until you rotate them, those workloads will continue to fail. That's not good! But I promise you, as a bad actor, I can do far worse to you. Hold my tea Go ahead and apply a quarantine policy to a credential set and toss it my way. I won't be able to buy savings plans, read your S3 data, modify Lambda functions, and do a host of other things. But here's what I can do. Anything I damn well feel like on RDS. You don't have anything important in databases, right? ssm:SendCommand / ssm:StartSession are permitted, which means I can run commands as root on EC2 instances, which will in turn invoke with that instance role’s permissions. sts:AssumeRole means that I can assume any other role in the account and get its permissions, rendering the entire restriction list potentially moot. I can use autoscaling:CreateAutoScalingGroup / UpdateAutoScalingGroup to launch instances via the Auto Scaling service-linked role, so the ec2:RunInstances deny never applies. cloudtrail:LookupEvents gets denied (that'll stop you from... reading the audit log), but I can call both cloudtrail:StopLogging and DeleteTrail which do exactly what you expect; you don't have an audit log anymore. SES denies ses:GetSendQuota / ListIdentities actions, but y'know what's missing? SendEmail, so I can blast my spam out to your entire list. sns:GetSMSAttributes means I can't get your SMS configuration, but I can absolutely sns:Publish to send fraudulent text messages wherever I'd like. s3:DeleteObject gets denied, but s3:PutObject is allowed. I can't delete your data, but I can fill a bucket to petabytes. Next, they fail to block s3:PutBucketVersioning, s3:PutObjectLockConfiguration, s3:PutObjectRetention, and s3:PutObjectLegalHold. So on any existing bucket, like that one I just stuffed petabytes into, I can enable versioning, turn on Object Lock, and set a bucket-default COMPLIANCE-mode retention out to 2126, or alternatively slap it on per object. COMPLIANCE retention can't be shortened or removed by anyone, including the account root and AWS Support. The only way to remove it is to delete the entire AWS account. secretsmanager:GetSecretValue, ssm:GetParameter* (WithDecryption), and kms:Decrypt are all unencumbered, so your secrets are now my secrets. Sharing is good! Backups are important, so it's a shame you don't have any. Well, not after I kick off backup:DeleteRecoveryPoint / DeleteBackupVault, and rds:DeleteDBSnapshot. If you're using CloudFormation, and for some things you almost certainly are, cloudformation:DeleteStack going unmentioned means you're not using it anymore and all of your stacks are gone. I would make different choices This isn't a comprehensive list - just a few things that occurred to me over the course of about an hour. I'm not a bad actor; I'm almost positive that I'm missing a whole bunch. AWS is almost certainly going to change this. My question for them is simply, "how big of a customer incident needs to happen before you do?" ®

Hackers slipped malware into several popular Rust packages this week, turning routine software builds into a route onto developers' machines. The Rust Security Response Team disclosed the supply chain attack on Thursday after receiving a tip about a crate called proc-macro1. An investigation found that its build script fetched malware from a remote server. The attack extended beyond a single dodgy crate. Someone had published a new version of arrayref, a legitimate and widely used Rust package, with proc-macro1 added as a dependency. The attacker had also yanked recent legitimate releases of arrayref, helping steer users toward the poisoned release. The Rust team does not believe arrayref's maintainer was responsible. It suspects the developer's computer or credentials were compromised and locked the account while attempting to contact them. The attacker also published malicious versions of two other crates maintained by the same developer, internment and append-only-vec. The poisoned releases weren't around for long. Arrayref 0.3.10 was available on crates.io for 86 minutes, internment 0.8.7 for 90 minutes, and append-only-vec 0.1.9 for 107 minutes before they were removed. That's a narrow window, but arrayref is hardly some forgotten package gathering dust in the registry. Security firm Aikido, which separately analyzed the attack, puts arrayref at roughly 245 million lifetime downloads and append-only-vec at more than 4 million. However, those figures don't tell us how many developers pulled the malicious versions during the brief period they were live. Aikido found that the attacker largely left the legitimate source code untouched, adding only a dependency on proc-macro1, a typosquat of the legitimate proc-macro2 package. The malicious code was tucked inside proc-macro1's build.rs file. Cargo, Rust's package manager, runs build scripts during compilation. This allowed proc-macro1 to identify the operating system and processor architecture of the developer or build machine, download a matching payload, and execute it. Aikido found malware built for Linux, Windows, Intel Macs, and Apple Silicon Macs. The second-stage payload was more than a simple downloader. Aikido found code targeting Chromium-based browser data, including profiles for Google Chrome, Brave, and Microsoft Edge, as well as browser extension storage used by cryptocurrency wallets. It also found functionality to establish persistence and receive commands from the attacker's server. The Rust team also deleted proc-macro-en, aovine, arone, aronenao, and tinymember, warning that every version of those crates should be considered malicious. Developers have been urged to check their Cargo lockfiles and local registry caches for the affected packages. Rust credits Nextron Systems' research team with initially discovering and reporting the attack. It has not said how the legitimate maintainer was compromised, how many developers downloaded the poisoned releases, or how many systems ultimately executed the payload. The malicious packages may have lasted less than two hours on crates.io, but whoever was behind them chose a well-traveled route into developers' machines. ®