phishing

Google claims win for everyone as text scammers lost their cloud server

e-z pass scam, Google, Lighthouse, phishing, Policy, text scams / DJ Henderson / November 15, 2025

The day after Google filed a lawsuit to end text scams primarily targeting Americans, the criminal network behind the phishing scams was “disrupted,” a Google spokesperson told Ars.

According to messages that the “ringleader” of the so-called “Lighthouse enterprise” posted on his Telegram channel, the phishing gang’s cloud server was “blocked due to malicious complaints.”

“We will restore it as soon as possible!” the leader posted on the channel—which Google’s lawsuit noted helps over 2,500 members coordinate phishing attacks that have resulted in losses of “over a billion dollars.”

Google has alleged that the Lighthouse enterprise is a “criminal group in China” that sells “phishing for dummies” kits that make it easier for scammers with little tech savvy to launch massive phishing campaigns. So far, “millions” of Americans have been harmed, Google alleged, as scammers disproportionately impersonate US institutions, like the Postal Service, as well as well-known brands like E-ZPass.

The company’s lawsuit seeks to dismantle the entire Lighthouse criminal enterprise, so the company was pleased to see Lighthouse communities go dark. In a statement, Halimah DeLaine Prado, Google’s general counsel, told Ars that “this shutdown of Lighthouse’s operations is a win for everyone.

Google claims win for everyone as text scammers lost their cloud server Read More »

Microsoft warns of new “Payroll Pirate” scam stealing employees’ direct deposits

Biz & IT, mfa, multi factor authentication, phishing, Security / Shannon Garcia / October 11, 2025

Microsoft is warning of an active scam that diverts employees’ paycheck payments to attacker-controlled accounts after first taking over their profiles on Workday or other cloud-based HR services.

Payroll Pirate, as Microsoft says the campaign has been dubbed, gains access to victims’ HR portals by sending them phishing emails that trick the recipients into providing their credentials for logging in to the cloud account. The scammers are able to recover multi-factor authentication codes by using adversary-in-the-middle tactics, which work by sitting between the victims and the site they think they’re logging in to, which is, in fact, a fake site operated by the attackers.

Not all MFA is created equal

The attackers then enter the intercepted credentials, including the MFA code, into the real site. This tactic, which has grown increasingly common in recent years, underscores the importance of adopting FIDO-compliant forms of MFA, which are immune to such attacks.

Once inside the employees’ accounts, the scammers make changes to payroll configurations within Workday. The changes cause direct-deposit payments to be diverted from accounts originally chosen by the employee and instead flow to an account controlled by the attackers. To block messages Workday automatically sends to users when such account details have been changed, the attackers create email rules that keep the messages from appearing in the inbox.

“The threat actor used realistic phishing emails, targeting accounts at multiple universities, to harvest credentials,” Microsoft said in a Thursday post. “Since March 2025, we’ve observed 11 successfully compromised accounts at three universities that were used to send phishing emails to nearly 6,000 email accounts across 25 universities.”

Microsoft warns of new “Payroll Pirate” scam stealing employees’ direct deposits Read More »

That annoying SMS phish you just got may have come from a box like this

Biz & IT, hacking, modems, phishing, Security, smishing, SMS / Mike M. / October 2, 2025

Scammers have been abusing unsecured cellular routers used in industrial settings to blast SMS-based phishing messages in campaigns that have been ongoing since 2023, researchers said.

The routers, manufactured by China-based Milesight IoT Co., Ltd., are rugged Internet of Things devices that use cellular networks to connect traffic lights, electric power meters, and other sorts of remote industrial devices to central hubs. They come equipped with SIM cards that work with 3G/4G/5G cellular networks and can be controlled by text message, Python scripts, and web interfaces.

An unsophisticated, yet effective, delivery vector

Security company Sekoia on Tuesday said that an analysis of “suspicious network traces” detected in its honeypots led to the discovery of a cellular router being abused to send SMS messages with phishing URLs. As company researchers investigated further, they identified more than 18,000 such routers accessible on the Internet, with at least 572 of them allowing free access to programming interfaces to anyone who took the time to look for them. The vast majority of the routers were running firmware versions that were more than three years out of date and had known vulnerabilities.

The researchers sent requests to the unauthenticated APIs that returned the contents of the routers’ SMS inboxes and outboxes. The contents revealed a series of campaigns dating back to October 2023 for “smishing”—a common term for SMS-based phishing. The fraudulent text messages were directed at phone numbers located in an array of countries, primarily Sweden, Belgium, and Italy. The messages instructed recipients to log in to various accounts, often related to government services, to verify the person’s identity. Links in the messages sent recipients to fraudulent websites that collected their credentials.

“In the case under analysis, the smishing campaigns appear to have been conducted through the exploitation of vulnerable cellular routers—a relatively unsophisticated, yet effective, delivery vector,” Sekoia researchers Jeremy Scion and Marc N. wrote. “These devices are particularly appealing to threat actors, as they enable decentralized SMS distribution across multiple countries, complicating both detection and takedown efforts.”

That annoying SMS phish you just got may have come from a box like this Read More »

Adult sites are stashing exploit code inside racy .svg files

Biz & IT, exploits, JavaScript, phishing, Scams, Security / Mike M. / August 10, 2025

The obfuscated code inside an .svg file downloaded from one of the porn sites. Credit: Malwarebytes

Once decoded, the script causes the browser to download a chain of additional obfuscated JavaScript. The final payload, a known malicious script called Trojan.JS.Likejack, induces the browser to like a specified Facebook post as long as a user has their account open.

“This Trojan, also written in Javascript, silently clicks a ‘Like’ button for a Facebook page without the user’s knowledge or consent, in this case the adult posts we found above,” Malwarebytes researcher Pieter Arntz wrote. “The user will have to be logged in on Facebook for this to work, but we know many people keep Facebook open for easy access.”

Malicious uses of the .svg format have been documented before. In 2023, pro-Russian hackers used an .svg tag to exploit a cross-site scripting bug in Roundcube, a server application that was used by more than 1,000 webmail services and millions of their end users. In June, researchers documented a phishing attack that used an .svg file to open a fake Microsoft login screen with the target’s email address already filled in.

Arntz said that Malwarebytes has identified dozens of porn sites, all running on the WordPress content management system, that are abusing the .svg files like this for hijacking likes. Facebook regularly shuts down accounts that engage in these sorts of abuse. The scofflaws regularly return using new profiles.

Adult sites are stashing exploit code inside racy .svg files Read More »

Phishers have found a way to downgrade—not bypass—FIDO MFA

Biz & IT, fido alliance, passkeys, phishing, Security / Shannon Garcia / July 19, 2025

Researchers recently reported encountering a phishing attack in the wild that bypasses a multifactor authentication scheme based on FIDO (Fast Identity Online), the industry-wide standard being adopted by thousands of sites and enterprises.

If true, the attack, reported in a blog post Thursday by security firm Expel, would be huge news, since FIDO is widely regarded as being immune to credential phishing attacks. After analyzing the Expel write-up, I’m confident that the attack doesn’t bypass FIDO protections, at least not in the sense that the word “bypass” is commonly used in security circles. Rather, the attack downgrades the MFA process to a weaker, non-FIDO-based process. As such, the attack is better described as a FIDO downgrade attack. More about that shortly. For now, let’s describe what Expel researchers reported.

Abusing cross-device sign-ins

Expel said the “novel attack technique” begins with an email that links to a fake login page from Okta, a widely used authentication provider. It prompts visitors to enter their valid user name and password. People who take the bait have now helped the attack group, which Expel said is named PoisonSeed, clear the first big hurdle in gaining unauthorized access to the Okta account.

The FIDO spec was designed to mitigate precisely these sorts of scenarios by requiring users to provide an additional factor of authentication in the form of a security key, which can be a passkey, or physical security key such as a smartphone or dedicated device such as a Yubikey. For this additional step, the passkey must use a unique cryptographic key embedded into the device to sign a challenge that the site (Okta, in this case) sends to the browser logging in.

One of the ways a user can provide this additional factor is by using a cross-device sign-in feature. In the event there is no passkey on the device being used to log in, a user can use a passkey for that site that’s already resident on a different device, which in most cases will be a phone. In these cases, the site being logged into will display a QR code. The user then scans the QR code with the phone, and the normal FIDO MFA process proceeds as normal.

Phishers have found a way to downgrade—not bypass—FIDO MFA Read More »

Microsoft’s new “passwordless by default” is great but comes at a cost

account takeovers, Biz & IT, passkeys, passwords, phishing, Security / Kelly Newman / May 3, 2025

Microsoft says it’s making passwordless logins the default means for signing in to new accounts, as the company helps drive an industry-wide push to transition away from passwords and the costly security problems they have created for companies and their users.

A key part of the “passwordless by default” initiative Microsoft announced on Thursday is encouraging the use of passkeys—the new alternative to passwords that Microsoft, Google, Apple, and a large roster of other companies are developing under the coordination of the FIDO Alliance.

Going forward, Microsoft will make passkeys the default means for new users to sign in. Existing users who have yet to enroll a passkey will be presented with a prompt to do so the next time they log in.

The push to passkeys is fueled by the tremendous costs associated with passwords. Creating and managing a sufficiently long, randomly generated password for each account is a burden on many users, a difficulty that often leads to weak choices and reused passwords. Leaked passwords have also been a chronic problem.

What’s more, over the past decade, attacks such as password spraying have grown increasingly effective at breaching sensitive networks, Microsoft’s own included.

Here’s the fine print

Left out of Microsoft’s announcement is that even after users create a passkey, they can’t go passwordless until they install the Microsoft Authenticator app on their phone. Microsoft has made Authy, Google Authenticator, and similar apps incompatible, a choice that needlessly inconveniences users and undermines the whole “passwordless by default” marketing message.

Using Microsoft Authenticator isn’t a requirement for using a passkey, but account holders who don’t have it will be unable to ditch their login passwords. With a password still associated with the account, many of the security benefits of passkeys are undermined.

Microsoft’s new “passwordless by default” is great but comes at a cost Read More »

What is device code phishing, and why are Russian spies so successful at it?

account takeovers, Biz & IT, device code authorization, phishing, russia, Security / Kelly Newman / February 15, 2025

Researchers have uncovered a sustained and ongoing campaign by Russian spies that uses a clever phishing technique to hijack Microsoft 365 accounts belonging to a wide range of targets, researchers warned.

The technique is known as device code phishing. It exploits “device code flow,” a form of authentication formalized in the industry-wide OAuth standard. Authentication through device code flow is designed for logging printers, smart TVs, and similar devices into accounts. These devices typically don’t support browsers, making it difficult to sign in using more standard forms of authentication, such as entering user names, passwords, and two-factor mechanisms.

Rather than authenticating the user directly, the input-constrained device displays an alphabetic or alphanumeric device code along with a link associated with the user account. The user opens the link on a computer or other device that’s easier to sign in with and enters the code. The remote server then sends a token to the input-constrained device that logs it into the account.

Device authorization relies on two paths: one from an app or code running on the input-constrained device seeking permission to log in and the other from the browser of the device the user normally uses for signing in.

A concerted effort

Advisories from both security firm Volexity and Microsoft are warning that threat actors working on behalf of the Russian government have been abusing this flow since at least last August to take over Microsoft 365 accounts. The threat actors masquerade as trusted, high-ranking officials and initiate conversations with a targeted user on a messenger app such as Signal, WhatsApp, and Microsoft Teams. Organizations impersonated include:

What is device code phishing, and why are Russian spies so successful at it? Read More »

Passkey technology is elegant, but it’s most definitely not usable security

Biz & IT, Features, login, passkeys, passwords, phishing, Security, signin / 9u50fv / December 30, 2024

NOT (QUITE) READY FOR PRIMETIME

Just in time for holiday tech-support sessions, here’s what to know about passkeys.

It’s that time again, when families and friends gather and implore the more technically inclined among them to troubleshoot problems they’re having behind the device screens all around them. One of the most vexing and most common problems is logging into accounts in a way that’s both secure and reliable.

Using the same password everywhere is easy, but in an age of mass data breaches and precision-orchestrated phishing attacks, it’s also highly unadvisable. Then again, creating hundreds of unique passwords, storing them securely, and keeping them out of the hands of phishers and database hackers is hard enough for experts, let alone Uncle Charlie, who got his first smartphone only a few years ago. No wonder this problem never goes away.

Passkeys—the much-talked-about password alternative to passwords that have been widely available for almost two years—was supposed to fix all that. When I wrote about passkeys two years ago, I was a big believer. I remain convinced that passkeys mount the steepest hurdle yet for phishers, SIM swappers, database plunderers, and other adversaries trying to hijack accounts. How and why is that?

Elegant, yes, but usable?

The FIDO2 specification and the overlapping WebAuthn predecessor that underpin passkeys are nothing short of pure elegance. Unfortunately, as support has become ubiquitous in browsers, operating systems, password managers, and other third-party offerings, the ease and simplicity envisioned have been undone—so much so that they can’t be considered usable security, a term I define as a security measure that’s as easy, or only incrementally harder, to use as less-secure alternatives.

“There are barriers at each turn that guide you through a developer’s idea of how you should use them,” William Brown, a software engineer specializing in authentication, wrote in an online interview. “None of them are deal-breaking, but they add up.”

Passkeys are now supported on hundreds of sites and roughly a dozen operating systems and browsers. The diverse ecosystem demonstrates the industry-wide support for passkeys, but it has also fostered a jumble of competing workflows, appearances, and capabilities that can vary greatly depending on the particular site, OS, and browser (or browser agents such as native iOS or Android apps). Rather than help users understand the dizzying number of options and choose the right one, each implementation strong-arms the user into choosing the vendor’s preferred choice.

The experience of logging into PayPal with a passkey on Windows will be different from logging into the same site on iOS or even logging into it with Edge on Android. And forget about trying to use a passkey to log into PayPal on Firefox. The payment site doesn’t support that browser on any OS.

Another example is when I create a passkey for my LinkedIn account on Firefox. Because I use a wide assortment of browsers on platforms, I have chosen to sync the passkey using my 1Password password manager. In theory, that choice allows me to automatically use this passkey anywhere I have access to my 1Password account, something that isn’t possible otherwise. But it’s not as simple as all that.

When I look at the passkey in LinkedIn settings, it shows as being created for Firefox on Mac OS X 10, even though it works on all the browsers and OSes I’m using.

Screenshot showing passkey is created for Firefox on Mac OS X 10.

Why is LinkedIn indicating otherwise? The answer is that there’s no way for LinkedIn to interoperate flexibly with the browsers and OSes and vice versa. Per the FIDO2 and WebAuthn specs, LinkedIn knows only the browser and OS I used when creating the credential. 1Password, meanwhile, has no way to coordinate with LinkedIn to ensure I’m presented with consistent information that will help me keep track of this. Suddenly, using passkeys is more confusing than it needs to be for there to be utility to ordinary users.

Things get more complicated still when I want to log into LinkedIn on Firefox for Android, and am presented with the following dialog box.

Screenshot showing a dialog box with the text: “You’re using on-device encryption. Unlock your passwords to sign in.”

At this point, I don’t know if it’s Google or Firefox that’s presenting me with this non-intuitive response. I just want to open LinkedIn using the passkey that’s being synced by 1Password to all my devices. Somehow, the mysterious entity responsible for this message (it’s Google in this case) has hijacked the process in an attempt to convince me to use its platform.

Also, consider the experience on WebAuthn.io, a site that demonstrates how the standard works under different scenarios. When a user wants to enroll a physical security key to log in on macOS, they receive a dialog that steers them toward using a passkey instead and to sync it through iCloud.

Dialog box showing macOS passkeys message.

The user just wants to enroll a security key in the form of a USB dongle or smartphone and can be used when logging in on any device. But instead, macOS preempts this task with directions for creating a passkey that will be synced through iCloud. What’s the user to do? Maybe click on the “other options” in small text at the very bottom? Let’s try and see.

The dialog box that appears after clicking “other options.”

Wait, why is it still offering the option for the passkey to be synced in iCloud, and how does that qualify as “other options”? And why is the most prominent suggestion that the user “continue with Touch ID”? It isn’t until selectng “security key” that the user will see that option they wanted all along—to store the credential on a security key. Only after this step—now three clicks in—does the light on a USB security key begin blinking, and the key is finally ready to be enrolled.

Dialog box finally allows the creation of a passkey on a security key.

The dueling dialogs in this example are by no means unique to macOS.

Too many cooks in the kitchen

“Most try to funnel you into a vendor’s sync passkey option, and don’t make it clear how you can use other things,” Brown noted. “Chrome, Apple, Windows, all try to force you to use their synced passkeys by default, and you have to click through prompts to use alternatives.”

Bruce Davie, another software engineer with expertise in authentication, agreed, writing in an October post that the current implementation of passkeys “seems to have failed the ‘make it easy for users’ test, which in my view is the whole point of passkeys.”

In April, Son Nguyen Kim, the product lead for the free Proton Pass password manager, penned a post titled Big Tech passkey implementations are a trap. In it, he complained that passkey implementations to date lock users into the platform they created the credential on.

“If you use Google Chrome as your browser on a Mac, it uses the Apple Keychain feature to store your passkeys,” he wrote. “This means you can’t sync your passkeys to your Chrome profile on other devices.” In an email last month, Kim said users can now override this option and choose to store their passkeys in Chrome. Even then, however, “passkeys created on Chrome on Mac don’t sync to Chrome in iPhone, so the user can’t use it seamlessly on Chrome on their iPhone.”

Other posts reciting similar complaints are here and here.

In short, there are too many cooks in the kitchen, and each one thinks they know the proper way to make pie.

I have put these and other criticisms to the test over the past four months. I have used them on a true heterogeneous environment that includes a MacBook Air, a Lenovo X1 ThinkPad, an iPhone, and a Pixel running Firefox, Chrome, Edge, Safari, and on the phones, a large number of apps, including those for LinkedIn, PayPal, eBay, Kayak, Gmail, Amazon, and Uber. My objective has been to understand how well passkey-based authentication works over the long term, particularly for cross-platform users.

I fully agree that syncing across different platforms is much harder than it should be. So is the messaging provided during the passkey enrollment phase. The dialogs users see are dictated arbitrarily by whatever OS or browser has control at the moment. There’s no way for previously made configuration choices to be communicated to tailor dialog boxes and workflow.

Another shortcoming: There’s no programming interface for Apple, Google, and Microsoft platforms to directly pass credentials from one to the other. The FIDO2 standard has devised a clever method in an attempt to bridge this gap. It typically involves joining two devices over a secure BLE connection and using a QR code so the already-authenticated device can vouch for the trustworthiness of the other. This process is easy for some people in some cases, but it can quickly become quirky and prone to failure, particularly when fussy devices can’t connect over BLE.

In many cases, however, critics overstate the severity of these sorts of problems. These are definitely things that unnecessarily confuse and complicate the use of passkeys. But often, they’re one-time events that can be overcome by creating multiple passkeys and bootstrapping them for each device. From then on, these unphishable, unstealable credentials live on both devices, in much the way some users allow credentials for their Gmail or Apple ID to be stored in two or more browsers or password managers for convenience.

More helpful still is using a cross-platform password manager to store and sync passkeys. I have been using 1Password to do just that for a month with no problems to report. Most other name-brand password managers would likely perform as well. In keeping with the FIDO2 spec, these credentials are end-to-end encrypted.

Halfway house for password managers

With my 1Password account running on my devices, I had no trouble using a passkey to log into any enrolled site on a device running any browser. The flow was fast and intuitive. In most cases, both iOS and Android had no problem passing the key from 1Password to an app for Uber, Amazon, Gmail, or another site. Signing into phone apps is one of the bigger hassles for me. Passkeys made this process much easier, and it did so while also allowing me the added security of MFA.

This reliance on a password manager, however, largely undermines a key value proposition of passkeys, which has been to provide an entirely new paradigm for authenticating ourselves. Using 1Password to sync a password is almost identical to syncing a passkey, so why bother? Worse still, the majority of people still don’t use password managers. I’m a big believer in password managers for the security they offer. Making them a condition for using a passkey would be a travesty.

I’m not the first person to voice this criticism. David Heinemeier Hansson said much the same thing in September.

“The problem with passkeys is that they’re essentially a halfway house to a password manager, but tied to a specific platform in ways that aren’t obvious to a user at all, and liable to easily leave them unable to access … their accounts,” wrote the Danish software engineer and programmer, who created Ruby on Rails and is the CTO of web-based software development firm 37signals. “Much the same way that two-factor authentication can do, but worse, since you’re not even aware of it.”

He continued:

Let’s take a simple example. You have an iPhone and a Windows computer. Chrome on Windows stores your passkeys in Windows Hello, so if you sign up for a service on Windows, and you then want to access it on iPhone, you’re going to be stuck (unless you’re so forward thinking as to add a second passkey, somehow, from the iPhone will on the Windows computer!). The passkey lives on the wrong device, if you’re away from the computer and want to login, and it’s not at all obvious to most users how they might fix that.

Even in the best case scenario, where you’re using an iPhone and a Mac that are synced with Keychain Access via iCloud, you’re still going to be stuck, if you need to access a service on a friend’s computer in a pinch. Or if you’re not using Keychain Access at all. There are plenty of pitfalls all over the flow. And the solutions, like scanning a QR code with a separate device, are cumbersome and alien to most users.

If you’re going to teach someone how to deal with all of this, and all the potential pitfalls that might lock them out of your service, you almost might as well teach them how to use a cross-platform password manager like 1Password.

Undermining security promises

The security benefits of passkeys at the moment are also undermined by an undeniable truth. Of the hundreds of sites supporting passkeys, there isn’t one I know of that allows users to ditch their password completely. The password is still mandatory. And with the exception of Google’s Advanced Protection Program, I know of no sites that won’t allow logins to fall back on passwords, often without any additional factor. Even then, all but Google APP accounts can be accessed using a recovery code.

This fallback on phishable, stealable credentials undoes some of the key selling points of passkeys. As soon as passkey adoption poses a meaningful hurdle in account takeovers, threat actors will devise hacks and social engineering attacks that exploit this shortcoming. Then we’re right back where we were before.

Christiaan Brandt, co-chair of the FIDO2 technical working group and an identity and security product manager at Google, said in an online interview that most users aren’t ready for true passwordless authentication.

“We have to meet users where they are,” he wrote. “When we tested messaging for passkeys, users balked at ‘replace your password with passkeys,’ but felt much more comfortable with more softened language like “you can now use a passkey to log in to your account too.’ Over time, we most definitely plan to wean users off phishable authentication factors, but we anticipate this journey to take multiple years. We really can only do it once users are so comfortable with passkeys that the fallback to passwords is (almost) never needed.”

A design choice further negating the security benefits of passkeys: Amazon, PayPal, Uber, and no small number of other sites supporting passkeys continue to rely on SMS texts for authentication even after passkeys are enrolled.

SMS-based MFA is among the weakest form of this protection. Not only can the texts be phished, but they’re also notoriously vulnerable to SIM swaps, in which an adversary gains control of a target’s phone number. As long as these less-secure fallbacks exist, passkeys aren’t much more than security theater.

I still think passkeys make sense in many cases. I’ll say more about that later. First, for a bit more context, readers should know:

Passkeys are defined in the WebAuthn spec as a “discoverable credential,” historically known as a “resident key.” The credential is in the form of a private-public key pair, which is created on the security key, which can be in the form of a FIDO-approved secure enclave embedded into a USB dongle, smartphone, or computer. The key pair is unique to each user account. The user creates the key pair after proving their identity to the website using an existing authentication method, typically a password. The private key never leaves the security key.

Going forward, when the user logs in, the site sends a security challenge to the user. The user then uses the locally stored private key to cryptographically sign the challenge and sends it to the website. The website then uses the public key it stores to verify the response is signed with the private key. With that, the user is logged in.

Under the FIDO2 spec, the passkey can never leave the security key, except as an encrypted blob of bits when the passkey is being synced from one device to another. The secret key can be unlocked only when the user authenticates to the physical key using a PIN, password, or most commonly a fingerprint or face scan. In the event the user authenticates with a biometric, it never leaves the security key, just as they never leave Android and iOS phones and computers running macOS or Windows.

Passkeys can be stored and synced using the same mechanisms millions of people already use for passwords—a password manager such as Bitwarden, Apple iCloud, Google Password Manager, or Microsoft’s cloud. Just like passwords, passkeys available in these managers are end-to-end encrypted using tried and true cryptographic algorithms.

The advent of this new paradigm was supposed to solve multiple problems at once—make authenticating ourselves online easier, eliminate the hassle of remembering passwords, and all but eradicate the most common forms of account takeovers.

When not encumbered by the problems mentioned earlier, this design provides multifactor authentication in a single stroke. The user logs in using something they have—the physical key, which must be near the device logging in. They must also use something they know—the PIN or password—or something they are—their face or fingerprint—to complete the credential transfer. The cryptographic secret never leaves the enclave embedded into the physical key.

What to tell Uncle Charlie?

In enterprise environments, passkeys can be a no-brainer alternative to passwords and authenticators. And even for Uncle Charlie—who has a single iPhone and Mac, and logs into only a handful of sites—passkeys may provide a simpler, less phishable path forward. Using a password manager to log into Gmail with a passkey ensures he’s protected by MFA. Using the password alone does not.

The takeaway from all of this—particularly for those recruited to provide technical support this week but also anyone trying to decide if it’s time to up their own authentication game: If a password manager isn’t already a part of the routine, see if it’s viable to add one now. Password managers make it practical to use a virtually unlimited number of long, randomly generated passwords that are unique to each site.

For some, particularly people with diminished capacity or less comfort being online, this step alone will be enough. Everyone else should also, whenever possible, opt into MFA, ideally using security keys or, if that’s not available, an authenticator app. I’m partial to 1Password as a password manager, Authy as an authenticator, and security keys from Yubico or Titan. There are plenty of other suitable alternatives.

I still think passkeys provide the greatest promise yet for filling the many security pitfalls of passwords and lowering the difficulty of remembering and storing them. For now, however, the hassles of using passkeys, coupled with their diminished security created by the presence of fallbacks, means no one should feel like a technophobe or laggard for sticking with their passwords. For now, passwords and key- or authenticator-based MFA remain essential.

With any luck, passkeys will someday be ready for the masses, but that day is not (yet) here.

Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Dan is based in San Francisco. Follow him at here on Mastodon and here on Bluesky. Contact him on Signal at DanArs.82.

Passkey technology is elegant, but it’s most definitely not usable security Read More »

Crypto scammers posing as real brands on X are easily hacking YouTubers

Cryptocurrency, cryptocurrency scam, fake x accounts, Gmail, Google, LinkedIn, phishing, Policy, Twitter, X, youtube / DJ Henderson / December 19, 2024

“I’m fighting with Google now,” Townsend told Ars. “I don’t expect any real answers from them.”

How YouTubers can avoid being targeted

As YouTube appears evasive, Townsend has been grateful for long-time subscribers commenting to show support, which may help get his videos amplified more by the algorithm. On YouTube, he also said that because “the outpouring of support was beyond anything” he could’ve expected, it kept him “sane” through sometimes 24-hour periods of silence without any updates on when his account would be restored.

Townsend told Ars that he rarely does sponsorships, but like many in the fighting game community, his inbox gets spammed with offers constantly, much of which he assumes are scams.

“If you are a YouTuber of any size,” Townsend explained in his YouTube video, “you are inundated with this stuff constantly,” so “my BS detector is like, okay, fake, fake, fake, fake, fake, fake, fake. But this one just, it looked real enough, like they had their own social media presence, lots of followers. Everything looked real.”

Brian_F echoed that in his video, which breaks down how the latest scam evolved from more obvious scams, tricking even skeptical YouTubers who have years of experience dodging phishing scams in their inboxes.

“The game has changed,” Brian_F said.

Townsend told Ars that sponsorships are rare in the fighting game community. YouTubers are used to carefully scanning supposed offers to weed out the real ones from the fakes. But Brian_F’s video pointed out that scammers copy/paste legitimate offer letters, so it’s already hard to distinguish between potential sources of income and cleverly masked phishing attacks using sponsorships as lures.

Part of the vetting process includes verifying links without clicking through and verifying identities of people submitting supposed offers. But if YouTubers are provided with legitimate links early on, receiving offers from brands they really like, and see that contacts match detailed LinkedIn profiles of authentic employees who market the brand, it’s much harder to detect a fake sponsorship offer without as many obvious red flags.

Crypto scammers posing as real brands on X are easily hacking YouTubers Read More »

Russia takes unusual route to hack Starlink-connected devices in Ukraine

backdoors, Biz & IT, nation state hacking, phishing, Security, turla / DJ Henderson / December 11, 2024

“Microsoft assesses that Secret Blizzard either used the Amadey malware as a service (MaaS) or accessed the Amadey command-and-control (C2) panels surreptitiously to download a PowerShell dropper on target devices,” Microsoft said. “The PowerShell dropper contained a Base64-encoded Amadey payload appended by code that invoked a request to Secret Blizzard C2 infrastructure.”

The ultimate objective was to install Tavdig, a backdoor Secret Blizzard used to conduct reconnaissance on targets of interest. The Amdey sample Microsoft uncovered collected information from device clipboards and harvested passwords from browsers. It would then go on to install a custom reconnaissance tool that was “selectively deployed to devices of further interest by the threat actor—for example, devices egressing from STARLINK IP addresses, a common signature of Ukrainian front-line military devices.”

When Secret Blizzard assessed a target was of high value, it would then install Tavdig to collect information, including “user info, netstat, and installed patches and to import registry settings into the compromised device.”

Earlier in the year, Microsoft said, company investigators observed Secret Blizzard using tools belonging to Storm-1887 to also target Ukrainian military personnel. Microsoft researchers wrote:

In January 2024, Microsoft observed a military-related device in Ukraine compromised by a Storm-1837 backdoor configured to use the Telegram API to launch a cmdlet with credentials (supplied as parameters) for an account on the file-sharing platform Mega. The cmdlet appeared to have facilitated remote connections to the account at Mega and likely invoked the download of commands or files for launch on the target device. When the Storm-1837 PowerShell backdoor launched, Microsoft noted a PowerShell dropper deployed to the device. The dropper was very similar to the one observed during the use of Amadey bots and contained two base64 encoded files containing the previously referenced Tavdig backdoor payload (rastls.dll) and the Symantec binary (kavp.exe).

As with the Amadey bot attack chain, Secret Blizzard used the Tavdig backdoor loaded into kavp.exe to conduct initial reconnaissance on the device. Secret Blizzard then used Tavdig to import a registry file, which was used to install and provide persistence for the KazuarV2 backdoor, which was subsequently observed launching on the affected device.

Although Microsoft did not directly observe the Storm-1837 PowerShell backdoor downloading the Tavdig loader, based on the temporal proximity between the execution of the Storm-1837 backdoor and the observation of the PowerShell dropper, Microsoft assesses that it is likely that the Storm-1837 backdoor was used by Secret Blizzard to deploy the Tavdig loader.

Wednesday’s post comes a week after both Microsoft and Lumen’s Black Lotus Labs reported that Secret Blizzard co-opted the tools of a Pakistan-based threat group tracked as Storm-0156 to install backdoors and collect intel on targets in South Asia. Microsoft first observed the activity in late 2022. In all, Microsoft said, Secret Blizzard has used the tools and infrastructure of at least six other threat groups in the past seven years.

Russia takes unusual route to hack Starlink-connected devices in Ukraine Read More »

Man gets 10 years for stealing $20M in nest eggs from 400 US home buyers

business email compromise, cybercrime, hackers, phishing, Policy, us housing / Mike M. / November 11, 2024

A Nigerian man living in the United Kingdom has been sentenced to 10 years for his role in a phishing scam that snatched more than $20 million from over 400 would-be home buyers in the US, including some savers who lost their entire nest eggs.

Late last week, the US Department of Justice confirmed that 33-year-old Babatunde Francis Ayeni pled guilty to conspiracy to commit wire fraud through “a sophisticated business email compromise scheme targeting real estate transactions” in the US.

To seize large down payments on homes, Ayeni and co-conspirators sent phishing emails to US title companies, real estate agents, and real estate attorneys. When unsuspecting employees clicked malicious attachments and links, a prompt appeared asking for login information that was then shared with the hackers.

Once the hackers were in, they could monitor their emails “for transactions where a buyer was scheduled to make a payment as part of a real estate transaction,” then swoop in to send wiring instructions to transfer funds to compromised accounts instead, the DOJ said. To help cover their tracks, co-conspirators then converted the money into Bitcoin on Coinbase.

The scam was seemingly uncovered after co-conspirators targeted a real estate title company in Gulf Shores, Alabama. More than half of the victims were unable to reverse the wire transactions. According to The Record, two victims who shared impact statements in court lost more than $114,000, including a man who “tried to buy his elderly father a home following a Parkinson’s diagnosis.”

Man gets 10 years for stealing $20M in nest eggs from 400 US home buyers Read More »

Ever wonder how crooks get the credentials to unlock stolen phones?

Biz & IT, lost phone, phishing, phishing-as-a-service, phone theft, Security / Kelly Newman / September 19, 2024

BUSTED —

iServer provided a simple service for phishing credentials to unlock phones.

Dan Goodin – Sep 19, 2024 9: 41 pm UTC

A coalition of law-enforcement agencies said it shut down a service that facilitated the unlocking of more than 1.2 million stolen or lost mobile phones so they could be used by someone other than their rightful owner.

The service was part of iServer, a phishing-as-a-service platform that has been operating since 2018. The Argentina-based iServer sold access to a platform that offered a host of phishing-related services through email, texts, and voice calls. One of the specialized services offered was designed to help people in possession of large numbers of stolen or lost mobile devices to obtain the credentials needed to bypass protections such as the lost mode for iPhones, which prevent a lost or stolen device from being used without entering its passcode.

iServer's phishing-as-a-service model. — Enlarge / iServer’s phishing-as-a-service model.

Group-IB

Catering to low-skilled thieves

An international operation coordinated by Europol’s European Cybercrime Center said it arrested the Argentinian national that was behind iServer and identified more than 2,000 “unlockers” who had enrolled in the phishing platform over the years. Investigators ultimately found that the criminal network had been used to unlock more than 1.2 million mobile phones. Officials said they also identified 483,000 phone owners who had received messages phishing for credentials for their lost or stolen devices.

According to Group-IB, the security firm that discovered the phone-unlocking racket and reported it to authorities, iServer provided a web interface that allowed low-skilled unlockers to phish the rightful device owners for the device passcodes, user credentials from cloud-based mobile platforms, and other personal information.

Group-IB wrote:

During its investigations into iServer’s criminal activities, Group-IB specialists also uncovered the structure and roles of criminal syndicates operating with the platform: the platform’s owner/developer sells access to “unlockers,” who in their turn provide phone unlocking services to other criminals with locked stolen devices. The phishing attacks are specifically designed to gather data that grants access to physical mobile devices, enabling criminals to acquire users’ credentials and local device passwords to unlock devices or unlink them from their owners. iServer automates the creation and delivery of phishing pages that imitate popular cloud-based mobile platforms, featuring several unique implementations that enhance its effectiveness as a cybercrime tool.

Unlockers obtain the necessary information for unlocking the mobile phones, such as IMEI, language, owner details, and contact information, often accessed through lost mode or via cloud-based mobile platforms. They utilize phishing domains provided by iServer or create their own to set up a phishing attack. After selecting an attack scenario, iServer creates a phishing page and sends an SMS with a malicious link to the victim.

Enlarge / An example phishing message sent.

When successful, iServer customers would receive the credentials through the web interface. The customers could then unlock a phone to disable the lost mode so the device could be used by someone new.

Ultimately, criminals received the stolen and validated credentials through the iServer web interface, enabling them to unlock a phone, turn off “Lost mode” and untie it from the owner’s account.

To better camouflage the ruse, iServer often disguised phishing pages as belonging to cloud-based services.

Enlarge / Phishing message asking for passcode.

Group-IB

Enlarge / Phishing message masquerades as a cloud-based service with a map once passcode is entered.

Group-IB

Besides the arrest, authorities also seized the iserver.com domain.

Enlarge / The iServer site as it appeared before the takedown.

Group-IB

Enlarge / The iServer website after the takedown.

Group-IB

The takedown and arrests occurred from September 10–17 in Spain, Argentina, Chile, Colombia, Ecuador, and Peru. Authorities in those countries began investigating the phishing service in 2022.

Ever wonder how crooks get the credentials to unlock stolen phones? Read More »