Several Apple customers recently reported being targeted in elaborate phishing attacks that involve what appears to be a bug in Apple’s password reset feature. In this scenario, a target’s Apple devices are forced to display dozens of system-level prompts that prevent the devices from being used until the recipient responds “Allow” or “Don’t Allow” to each prompt. Assuming the user manages not to fat-finger the wrong button on the umpteenth password reset request, the scammers will then call the victim while spoofing Apple support in the caller ID, saying the user’s account is under attack and that Apple support needs to “verify” a one-time code.
Some of the many notifications Patel says he received from Apple all at once.
Parth Patel is an entrepreneur who is trying to build a startup in the conversational AI space. On March 23, Patel documented on Twitter/X a recent phishing campaign targeting him that involved what’s known as a “push bombing” or “MFA fatigue” attack, wherein the phishers abuse a feature or weakness of a multi-factor authentication (MFA) system in a way that inundates the target’s device(s) with alerts to approve a password change or login.
“All of my devices started blowing up, my watch, laptop and phone,” Patel told KrebsOnSecurity. “It was like this system notification from Apple to approve [a reset of the account password], but I couldn’t do anything else with my phone. I had to go through and decline like 100-plus notifications.”
Some people confronted with such a deluge may eventually click “Allow” to the incessant password reset prompts — just so they can use their phone again. Others may inadvertently approve one of these prompts, which will also appear on a user’s Apple watch if they have one.
But the attackers in this campaign had an ace up their sleeves: Patel said after denying all of the password reset prompts from Apple, he received a call on his iPhone that said it was from Apple Support (the number displayed was 1-800-275-2273, Apple’s real customer support line).
“I pick up the phone and I’m super suspicious,” Patel recalled. “So I ask them if they can verify some information about me, and after hearing some aggressive typing on his end he gives me all this information about me and it’s totally accurate.”
All of it, that is, except his real name. Patel said when he asked the fake Apple support rep to validate the name they had on file for the Apple account, the caller gave a name that was not his but rather one that Patel has only seen in background reports about him that are for sale at a people-search website called PeopleDataLabs.
Patel said he has worked fairly hard to remove his information from multiple people-search websites, and he found PeopleDataLabs uniquely and consistently listed this inaccurate name as an alias on his consumer profile.
“For some reason, PeopleDataLabs has three profiles that come up when you search for my info, and two of them are mine but one is an elementary school teacher from the midwest,” Patel said. “I asked them to verify my name and they said Anthony.”
Patel said the goal of the voice phishers is to trigger an Apple ID reset code to be sent to the user’s device, which is a text message that includes a one-time password. If the user supplies that one-time code, the attackers can then reset the password on the account and lock the user out. They can also then remotely wipe all of the user’s Apple devices.
THE PHONE NUMBER IS KEY
Chris is a cryptocurrency hedge fund owner who asked that only his first name be used so as not to paint a bigger target on himself. Chris told KrebsOnSecurity he experienced a remarkably similar phishing attempt in late February.
“The first alert I got I hit ‘Don’t Allow’, but then right after that I got like 30 more notifications in a row,” Chris said. “I figured maybe I sat on my phone weird, or was accidentally pushing some button that was causing these, and so I just denied them all.”
Chris says the attackers persisted hitting his devices with the reset notifications for several days after that, and at one point he received a call on his iPhone that said it was from Apple support.
“I said I would call them back and hung up,” Chris said, demonstrating the proper response to such unbidden solicitations. “When I called back to the real Apple, they couldn’t say whether anyone had been in a support call with me just then. They just said Apple states very clearly that it will never initiate outbound calls to customers — unless the customer requests to be contacted.”
Massively freaking out that someone was trying to hijack his digital life, Chris said he changed his passwords and then went to an Apple store and bought a new iPhone. From there, he created a new Apple iCloud account using a brand new email address.
Chris said he then proceeded to get even more system alerts on his new iPhone and iCloud account — all the while still sitting at the local Apple Genius Bar.
Chris told KrebsOnSecurity his Genius Bar tech was mystified about the source of the alerts, but Chris said he suspects that whatever the phishers are abusing to rapidly generate these Apple system alerts requires knowing the phone number on file for the target’s Apple account. After all, that was the only aspect of Chris’s new iPhone and iCloud account that hadn’t changed.
WATCH OUT!
“Ken” is a security industry veteran who spoke on condition of anonymity. Ken said he first began receiving these unsolicited system alerts on his Apple devices earlier this year, but that he has not received any phony Apple support calls as others have reported.
“This recently happened to me in the middle of the night at 12:30 a.m.,” Ken said. “And even though I have my Apple watch set to remain quiet during the time I’m usually sleeping at night, it woke me up with one of these alerts. Thank god I didn’t press ‘Allow,’ which was the first option shown on my watch. I had to scroll watch the wheel to see and press the ‘Don’t Allow’ button.”
Ken shared this photo he took of an alert on his watch that woke him up at 12:30 a.m. Ken said he had to scroll on the watch face to see the “Don’t Allow” button.
Ken didn’t know it when all this was happening (and it’s not at all obvious from the Apple prompts), but clicking “Allow” would not have allowed the attackers to change Ken’s password. Rather, clicking “Allow” displays a six digit PIN that must be entered on Ken’s device — allowing Ken to change his password. It appears that these rapid password reset prompts are being used to make a subsequent inbound phone call spoofing Apple more believable.
Ken said he contacted the real Apple support and was eventually escalated to a senior Apple engineer. The engineer assured Ken that turning on an Apple Recovery Key for his account would stop the notifications once and for all.
A recovery key is an optional security feature that Apple says “helps improve the security of your Apple ID account.” It is a randomly generated 28-character code, and when you enable a recovery key it is supposed to disable Apple’s standard account recovery process. The thing is, enabling it is not a simple process, and if you ever lose that code in addition to all of your Apple devices you will be permanently locked out.
Ken said he enabled a recovery key for his account as instructed, but that it hasn’t stopped the unbidden system alerts from appearing on all of his devices every few days.
KrebsOnSecurity tested Ken’s experience, and can confirm that enabling a recovery key does nothing to stop a password reset prompt from being sent to associated Apple devices. Visiting Apple’s “forgot password” page — https://iforgot.apple.com — asks for an email address and for the visitor to solve a CAPTCHA.
After that, the page will display the last two digits of the phone number tied to the Apple account. Filling in the missing digits and hitting submit on that form will send a system alert, whether or not the user has enabled an Apple Recovery Key.
The password reset page at iforgot.apple.com.
RATE LIMITS
What sanely designed authentication system would send dozens of requests for a password change in the span of a few moments, when the first requests haven’t even been acted on by the user? Could this be the result of a bug in Apple’s systems?
Apple has not yet responded to requests for comment.
Throughout 2022, a criminal hacking group known as LAPSUS$ used MFA bombing to great effect in intrusions at Cisco, Microsoft and Uber. In response, Microsoft began enforcing “MFA number matching,” a feature that displays a series of numbers to a user attempting to log in with their credentials. These numbers must then be entered into the account owner’s Microsoft authenticator app on their mobile device to verify they are logging into the account.
Kishan Bagaria is a hobbyist security researcher and engineer who founded the website texts.com (now owned by Automattic), and he’s convinced Apple has a problem on its end. In August 2019, Bagaria reported to Apple a bug that allowed an exploit he dubbed “AirDoS” because it could be used to let an attacker infinitely spam all nearby iOS devices with a system-level prompt to share a file via AirDrop — a file-sharing capability built into Apple products.
Apple fixed that bug nearly four months later in December 2019, thanking Bagaria in the associated security bulletin. Bagaria said Apple’s fix was to add stricter rate limiting on AirDrop requests, and he suspects that someone has figured out a way to bypass Apple’s rate limit on how many of these password reset requests can be sent in a given timeframe.
“I think this could be a legit Apple rate limit bug that should be reported,” Bagaria said.
WHAT CAN YOU DO?
Apple seems requires a phone number to be on file for your account, but after you’ve set up the account it doesn’t have to be a mobile phone number. KrebsOnSecurity’s testing shows Apple will accept a VOIP number (like Google Voice). So, changing your account phone number to a VOIP number that isn’t widely known would be one mitigation here.
One caveat with the VOIP number idea: Unless you include a real mobile number, Apple’s iMessage and Facetime applications will be disabled for that device. This might a bonus for those concerned about reducing the overall attack surface of their Apple devices, since zero-click zero-days in these applications have repeatedly been used by spyware purveyors.
Also, it appears Apple’s password reset system will accept and respect email aliases. Adding a “+” character after the username portion of your email address — followed by a notation specific to the site you’re signing up at — lets you create an infinite number of unique email addresses tied to the same account.
For instance, if I were signing up at example.com, I might give my email address as krebsonsecurity+example@gmail.com. Then, I simply go back to my inbox and create a corresponding folder called “Example,” along with a new filter that sends any email addressed to that alias to the Example folder. In this case, however, perhaps a less obvious alias than “+apple” would be advisable.
Update, March 27, 5:06 p.m. ET: Added perspective on Ken’s experience. Also included a What Can You Do? section.
This is why I use and trust Apple security:
1. if there is an issue it gets highlighted.
2. Apple usually fixes it promptly.
All the others are too obscure, with smaller user bases, and spotty reporting. Much less visibility. And while Apple doesn’t disclose all details it may be better, but at least no worse, than alternative platforms and security solutions.
Good article Brian! Looking forward to see how this develops/resolves.
I must disagree with you, RWKOS. In contrast, I think some of these reasons are why one should *not* trust Apple’s security model. In fact, higher user bases are often directly correlated to more malware, more bad actors specifically targeting the software, etc. And since Apple shrouds their mobile software ecosystem in secrecy, users must develop an unhealthy dependency and reliance on developers at Apple to find the vulnerability, fix it, and push an emergency update. That, as opposed to an open-source ecosystem where anybody can read the source code, and anybody can contribute to its security and features. This is why most of these catastrophic stories rarely bare the word “Linux” in it’s title. And, please excuse me, but with that being said, I find it kind of ironic that you say “Much less visibility”.
With proprietary software like iOS, nobody but Apple can read the source code, but anybody could use open-source reverse-engineering apps to find and exploit vulnerabilities.
I’ve been able to exploit vulnerabilities in open-source software more easily than in closed-source because of their public history of patches and fixes, and especially because of highly detailed descriptions about how to exploit such vulnerabilities. Everything is available in their GitHub repositories, even with some sample code!
Security should not rely on obscurity, and while I applaud and completely support open-source software, let’s stop saying that it is safer because “anybody can read the source code, and anybody can contribute to its security and features.” The reality is that very few individuals are actually able to read and understand the complexity of modern software, and in order to be able to contribute to such repos, you will need to have a deep knowledge of the project’s objectives, philosophy, and its inner workings.
Theres much less incentive to exploit open source software though. OSS is commonly obscure, and not many use it, so theres less of a payout for malware authors and users. I agree that there’s no universal truth to OSS being safer, but I can comfortably infer that the odds are in my favor and that I’ll be more secure, compared to using a proprietary software/service provided by a tech behemoth that is most likely being targeted by a much larger number of bad actors.
not to take sides, but goog play store has maybe 1000x the malicious apps of itune at any given time . Not that I care for either, but goog is a poor example of opensource security in the long run. (I made my guesstimate based on software removed numbers, on a yearly basis of each)
The play store is filled with open source software. But Android is another prime target for bad actors, I mean it’s the second largest smartphone operating system in the world. More users = more people to exploit. But… that makes us all kind of backed into a corner. I mean you only have a few options for alternative smartphones that have unlocked bootloaders, and come with a mobile linux distro(that isn’t android). It’s the way of the world, sadly. I think more than anything I’m trying to be like a jehovas witness, wanting to encourage people to take control of their digital presence and interaction. I think I’m mostly more comfortable with OSS because I am technically inclined, and I can skim thru the source code before I use it. With Apple? Microsoft? I don’t have that control. I have to blindly trust a company that views me as a financial asset.
It is those few individuals that can that make a huge difference. Theyre contributing because their passionate about the project, and often doing so in their free time. In tech corporations, the larger incentive for developers, in my opinion, is more about promotions and gaining ground in the company. I think when a developer is working out of passion, they are more aligned to doing what is right. Whereas in a corporate environment, they may be willing to cut corners or pull strings to meet deadlines or whatever, regardless of the robustness or quality of the product.
@ Dylan. Although I generally agree with the points you make, I want to disagree on one. “Anybody” can not really check open source software. Me, for example. I do not have the knowledge and will never attain it. I am just as dependent on open source coders to fix a problem as I am on Apple coders.
I think Linux in these headlines because the user base is minuscule. As you noted, Apple’s huge user base makes it a prime target. The same logic applies to why Linux isn’t a prime target.
Linux may continue to be very small (~ 3%) but recently growing share of the desktop, but it’s a very large share of servers (e.g. > 96% of the top 1,000,000 web servers (cf. https://www.enterpriseappstoday.com/stats/linux-statistics.html ).
Linux doesn’t have a phone, really.
There is one good phone for linux called the PinePhone
What is an iPhone use supposed to do?
Keep hitting don’t allow?
It seems like the only thing you can do is change the mobile number on your account to something that is not publicly tied to your identity or email address. But I think it also has to be a real number (non-voip). I need to check if you can remove the phone number entirely.
Looking forward to more updates on this and hoping Apple does something quickly. I thought Apple required a phone number for things like Apple Pay, which leaves…what?…having to have a separate phone line with your carrier that you only use for Apple? 🙁 I hope I am misunderstanding this.
Apple introduce hardware bug into GPU used by spyware to compomise your so well payed iphone… right choise status simbol of insecurity.
Show us the secure phone Erik Prince / Obama!
VOIP numbers work, and are arguably a best practice even aside from this issue to mitigate SIM jacking attacks.
Why not power off your phone for a while?
Changing your phone number should completely resolve it.
What does a non-IT nor tech savvy person do to protect themselves?
Excellent question, Carolyn.
I hope someone replies.
@Carolyn,
At the end of the day, the success of this attack depends on you handing over the reset code to the caller on the phone, assuming you survive the “MFA bombing” attack. Just hang up the call though it appears to be a number from Apple. Caller ID spoofing is easy and it has been around for many years.
There is an app called TM-check on the app store which gives you a free second phone number. You might use that second phone number to sign up for apps and services, which would secure your primary phone number if that service you sign up for gets compromised.
This should be higher profile news. I was hit by this once on my work-managed macbook pro, and then again on my personal iphone. It wasn’t repetitive, just a single prompt on each device within a day or two of each other. I ignored them or clicked through them without giving any credential to just get rid of them because i was busy. I didn’t think too much about it, figured it was something Apple was doing to our cloud keychains or something. I can’t imagine how many naive users are succumbing to this.
Would Lockdown Mode help prevent or stop the MFA bombs?
Don’t think so, lockdown mode does not AFAIK prevent a pw change request…
This is a bug on the Apple side that users really can’t do anything about yet.
Changing your phone number is not an option that makes sense for most.
https://support.apple.com/en-us/105120 – No mention of PW change.
Clicking Allow does *not* grant the attacker any access, so this is wrong:
“Unnerved by the idea that he could have rolled over on his watch while sleeping and allowed criminals to take over his Apple account”
Clicking Allow will bring up a password reset screen on the device and if you reset the password, the attacker will not be granted any access to your account.
Please think logically: Apple is not going to make it trivial to accidentally provide access to an account.
Yea but the regular person probably doesn’t know what happens if you click allow or don’t because they’ve never seen that before and/or didn’t ask for it. Nobody is going to click allow when they have no idea what’s going to happen next.
Seems like the whole point of the reset notifications isn’t to hijack the password, but to set the user up for a targeted phishing call over the phone. But that’s hard to know as a victim.
It’s unclear if this is a required step in a chain leading to a more serious exploit. Apple has humans writing massively complicated software, so there are vulnerabilities that even Apple isn’t aware of, or doesn’t yet understand.
If it’s innocuous, then we need an explanation for why the attacker sent the requests at all.
Pretty sure so far it’s the phone call… If they get the 6 digit conf code from the device (via user interaction), PW is changed and user hosed. Clicking “allow” isn’t (AFAIK?) the final step in the attack, and the spamming of MFA bombs may be just poorly coordinated attack automation… or, what, an annoyance campaign to make Apple users freak out, or prod them into trying to change their PW via unsecured/compromised 2nd device, that they’ve previously infected? A lot of unknowns so far.
This happened to me in 2022!
I had a similar experience with an email provider years ago. Someone was doing repeated password resets and entering my email address. Then I would get an email from “support” asking me to click on a suspect link. Oddly, I did hear from the actual provider support.. asking me to change my password because my account was under attack. This happened three times before I told the provider I refused to change my password again. My password was already 25 characters and complex as hell. I tried to suggest that they needed some sort of rate limit on password operations, but they had no idea what that was.
Best thing you can do with such a provider is to:
– move to a competent provider
– migrate all mails to new, delete from old
– tell folks your new email address
One of our executives was (unsuccessfully) targeted with this exact method in May 2022: mass push notifications followed by a spoofed inbound call from Apple Support. All the attackers need to know is the email address and phone number associated with your iCloud account, so it is surprising it hasn’t been more common. Since Apple ties your iMessage phone number to your account, unless you want to stop using iMessage, it is probably easier to change your Apple ID email address.
You can also add a second Trusted Number to the account. Then an attacker can not request access without knowing the email address and both phone numbers.
Have you actually tried what happens when you click “Allow”?
I just did.
Clicking ALLOW lets me change the password ON MY DEVICE.
But NOT in the WEB BROWSER the attacker uses.
The web browser just says to use your devices or go into the 72-hour waiting period for account recovery.
Did I miss something? Can you clarify?
I tried to replicate this on my own devices. I could trigger the message “Use this iPhone to reset your Apple ID password”, but clicking “Allow” only takes me to the password reset page which required I to have a linked Apple device to reset the pw, or wait days/week to verify the identity. I was also never able to trigger the one time passcode in a text message format as Parth posted about. From Apple support, it seems that a passcode like that could be generated if someone’s trying to sign in from a different device not linked to the account (https://support.apple.com/en-us/HT204974). How do you think the attacker triggered the One Time passcode? Is it possible that the attacker was somehow able to reset his password from a different device, and that passcode was sent by Apple when the attacker tried to sign in from the other device?
I can’t thank you enough for sharing such an amazing blog with us. It’s been enlightening!
I’d like to see a flowchart of what happens in this scenario and what exactly is the correct response to avoid getting hacked!
don’t give out a 6 digit code to anyone and Apple support will never call you asking for a 6 digit code
Unless they trick you by offering horoscope. Then…
What’s a horoscope got to do with it ?
If you get bombed with reset prompts, can you just reboot the phone to make them go away?
Apple has a history of convincing their end users that their products are immune. Unfortunately this was only true when Apple products had a smaller overall market share. I generally feel Apple convinced themselves they were not exposed and never really focused on security. Now Apple is playing a reactive game in which they much try and play wack a mole to these attacks. Who knows how many weaknesses are in Apple products, but I will bet that we will find out.
Apple never claimed immunity.
They say never hacked at scale.
They make mistakes like others.
They usually fix them fast.
That’s about all one should hope for.
Umm … no. See, this is a reactive space. Apple (or whoever) does the best they can but they somehow have to get everything 100% right AND predict the future if they want to totally prevent attacks. Does that sound possible to you? Remember: the defender has to get it 100% right 100% of the time while the attacker just needs to get it right once. No matter how prepared you are and how good a job your team of developers, testers and auditors does, someone out there is gonna find a hole. It actually sort of reflects nature and evolution if you think about it. But that’s another discussion for another time. And one I’m not likely to have.
Same scenario here. A pain in the Tuchus.
Apple device is well build for security
This error is a end to end Encryption using Apple keychain and iCloud syn
I don’t believe he call Apple
Or seen a call from
And this part is totally fake
This has been happening to me on and off since fall of 2023. There was also other fraud attempts on my non apple accounts at the same time. My guess is people are getting info in data breaches and then trying to go phishing with it to see if the info is associated with an icloud account. So far I’ve only seen the password change dialogs. I haven’t gotten any fake apple support calls.
After going through this read-up, it seems there might have been an oversight.
Should the owner of the iPhone accidentally tap “allow”, this does not allow the attacker to change the victims password in their web browser immediately.
When a user taps Allow on their device, they are shown a 6-digit pin…on their device…that the attacker *must* obtain to actually be granted access. Otherwise, they will be unable to proceed.
The attacker would need to call the victim, either by using some spoofed Apple phone number [to look at least somewhat legitimate] and have the victim provide the 6-digit pin.
Without 6-digit pin, the attacker will not be granted access. At most, it will be an annoyance for both parties.
I was going to mention that myself, good point. OTOH, what % of neophyte users would get the scam phone call from “apple support” and do the smart thing of hanging up and dialing the number manually, rather than just trusting the spoofed caller ID and due to being flustered/busy/inattentive just hand over the 6 digit code to the “representative” anyway? There is a lot of low-lying security PEBCAK in the Apple userbase IMO. But I think you’re right that “allow” isn’t the final step.
From reading the story and the comments, I expect the alerts on the phone are Only to make you concerned, the fake apple support phone call is the rub, that’s when they ask you for the code – that is what they need to attempt account take over.
Yes been happening to me for 3 years I believe. But I know where it was coming from. He should of stopped the damn lying and just tell me and he could of had it going on. But no, so he had my iphone locked up.
Wow! And where are all the ISPs and Common Carriers? The only parties that know where calls originate from are the ISPs and Common Carriers. I’ve had this discussion so many times with my carrier. But they don’t appear to want to spend the money to stop the activity. It’s something convenient called 42USC230. As a true life example, when I got calls I can hear is from a call center and they are speaking Hindi in the background, and the guy comes on about hawking some scam speaking Mumbai British, the common carrier has to know that call is entering the system from an overseas trunk and is not from my area code, LOL. So why does the crap come up as my area code? Better yet, if the common carrier knows that that phone number is out of service in my calling area because the account is closed, why are they allowing a call from that number into the system?
China can have a Great Firewall, but in America scammers from all over the world can dial in. Does nobody see a problem with this?
If you knew what China uses that Great Firewall for and how a great many of their citizens feel about it, well, you wouldn’t be touting it as an example of the good, lol. As an example, why don’t you look up a new show that’s very popular called 3 Body Problem. It’s on Netflix. Uhh, well, unless you’re in China. Cuz the first scene shows a professor being beaten because he defied the government. Yeah. They can keep it and, if you want it, you can move.
That’s not the point of the comment. Of course the Great Firewall is bad. But the point of the analogy is that it works. Scans in that direction render the sounds of Mandarin crickets. America could implement such a system in a benign fashion (and the little voice on the left shoulder says:”Yea, right, whom are you trying to kid?”).
I really have to give huge kudos to Microsoft for enabling MFA Number Matching on Microsoft accounts. It totally defeats the usefulness MFA Bombing attacks. It’s not often Microsoft does something that deserves a positive commendation and this one most certainly does. Apple can learn something from Microsoft here.
Just today I encountered something similar with Whatsapp – “Whatsapp registration code was requested for your phone number” – but I had no codes emailed or texted to me (my phone has been off since a suspected hack last month, and only noticed this Whatsapp notification after turning it on).
I’ve since enabled 2FA on my Whatsapp account, and put my email on the account.
Something doesn’t pass the smell test with this “scam”. Indulge me…
So an attacker learns my Apple ID email address (or any email associated with the Apple ID) and my phone number.
They visit iforgot.apple.com and force a password notification reset to be sent to all my devices logged into said Apple ID.
I click Allow and am taken to the Change Password screen in the IOS settings app ON MY DEVICE. I can cancel from this screen and leave my password unchanged or I could change it.
How in the flippity heck does this give the Attacker access to my account from their end via a web browser?
My action of clicking Allow does NOT in any way give feedback to the iforgot website. Thus, how does this help an Attacker compromise the account?
That being said, multiple password reset notifications sent to a target will usually prime the target to suspect someone is trying to get into their account. When followed by a well-timed phone call that appears to be from Apple via a spoofed caller ID, some targets can be socially engineered at this point.
But, even if an attacker has gained possession of a one-time verification code from Apple, what can they do with it?
For an attacker to “lock out” a customer they would first have to log into the account (appleid.apple.com) with a KNOWN password and then obtain the one-time verification code sent by Apple (system notification or text message), then the attacker can change the password and phone number to effectively lock out the customer. If the customer has opted to use a Security Key instead of one-time verification codes, it’s game over as the attacker will NOT be able to log into the account.
So is there a nugget of information missing in the article?
Does the Attacker need to possess more than an email and phone number?
Do they need to know the current account password?
There are a lot of holes and unanswered questions about this scam.
Since Krebs is leading the charge with this story vis-a-vis, most other affiliates are crediting Krebs as the source, I defer here for my questions.
I did a year on the phones for Apple support working on IOS tech support issues. More than half of our calls are Apple account access-related issues.
I’m having a hard time trying to fathom how this scam, as described, would work, but I’m open-minded and want to learn if I’m missing something.
*Bonus – My $0.02 on hardening your Apple account.
1) Set up an email that is ONLY used for your Apple ID. Don’t publish this email address. You can change your Apple ID email address so don’t create a new Apple ID if you change your email.
2) If you are a legacy account holder and haven’t already enabled 2FA on your Apple ID, do it NOW!
3) Make sure you have a strong password that isn’t used ANYWHERE else!
4) Add at least one additional trusted phone number to give you some options for account recovery.
5) Create a Recovery Key for your account and store it in your password manager and offline in a secure location.
6) Add a Security Key to your Apple account. This will require a piece of hardware if anyone wants to log into your Apple ID account (even if they know the password). They are commodity priced so get one.
7) Finally, use a Password manager to store your secrets and assist with generating passwords. I recommend 1Password (I’m not affiliated, just a happy user). It is reasonably priced at $38 annually. Software is available for all major desktop and mobile OSs.
Peace
bleepingcomputer.com/news/security/1password-discloses-security-incident-linked-to-okta-breach/
So close.
This article is interesting:
How To Detect A Keylogger On An iPhone
https://www.certosoftware.com/insights/how-to-detect-a-keylogger-on-an-iphone
I am NOT promoting certosoftware. The author makes practical suggestions:
Check for custom keyboards
On your iPhone, go to Settings > General > Keyboard > Keyboards. For most devices, you should see two keyboards called something like:
English (US).
Emoji.
If you see any other keyboards listed that you don’t recognize, it’s possible that it could be a keylogger.
and more.
The password reset prompts are just to fatigue you… once fatigued you may then click on a similar looking multi-factor login verification link. Not sure if Apple sends those, or if you have to enter a number/code into the page. That attack would be the attacker using stolen username/password to login. If multi-factor is on, they may send you a link or a code to enter to complete the login. It’s that bit the attacker needs.
If only Apple could give ID’s that the user could re-generate at anytime, plus some recovery key that the user could re-generate at any time, and also allow to have FIDO2/ WebAuthn/ Passkeys associated as second-factor just in case the person wants some additional security.
Those would stop these scammers/ attackers alerts nuisance (at best) and way to get in (at worst), since they wouldn’t know those exclusive ID’s and recovery keys, and definitely wouldn’t have access to the FIDO2/ WebAuthn/ Passkeys associated (if used).
FIDO2/ WebAuthn/ Passkeys should avoid the user somehow giving the necessary data to the attackers… of course they would need to be outside of Apple ecosystem such that even if some hacker somehow associated himself to the account (or stolen your iPhone and make you give them the password to unlock the device) couldn’t have access to the account to a point in where they could make permanent damage.
Of course Apple would need to have options to disable the use of phone number and/ or the e-mail associated to initiate the recovery process.
Only an Apple user would think buying a new iPhone is the solution to a password reset attack. Even if Apple limits the reset requests to every X minutes, you’ll still need to change the phone number or email used for your Apple ID and avoid exposing that information to avoid such attacks. This is security 101-type stuff, not Pegasus.
Is it the case that just turning off “allow websites to ask permission to send notifications” in Safari Settings>Websites>Notifications should stop the repetitive bombardment (which could be REALLY annoying, even if the target doesn’t fall for the request in the subsequent bogus phone call)?
Apple could just add a line to that dialogue box “Apple will never call you unless you call us first.” Won’t stop the repeats but will warn people about the phishing phone call.
It’s a flaw in Apple’s password reset workflow that they need to address. Simply knowing Phone#/e-mail should NOT be enough to initiate the password reset process. Perhaps a generated recovery key serves that purpose. It should take e-mail/phone# + Recovery Key to initiate a password reset 2FA/Push notification to a device. For those who did not generate a recovery key and you receive a 2FA/Push password reset notification you did not initiate: Selecting Deny will auto-deny/ban any future password reset requests from that IP address. Any non-response to the 2FA/Push notification results in a time-delay/cooldown before an additional request can be sent: 1min, 2 min, 4 min, 8 min, 16 min, 32 min. etc.