PhishCore™️ @PhishCore

Criminals are using AI voice agents to call people whose iPhones were stolen and trick them into giving up their Apple IDs The reason is simple A stolen iPhone isn't worth nearly as much to a thief when Activation Lock is still tied to the owner's account So instead of trying to break into the phone, criminals are now going after the person who owns it Researchers found an automated operation that can send phishing messages to stolen iPhone owners and then call them with an AI-generated voice pretending to be Apple Support The caller can tell the victim their iPhone has been located and walk them through a fake recovery process Then it starts asking for the information the attacker actually wants Their Apple Account credentials Their passcode And even their two-factor authentication code The frightening part is how cheap this is to operate Researchers recovered around 200 AI-powered calls made between August 2025 and May 2026 The entire operation cost roughly $19 That's less than 10 cents per call A human scammer would have to spend hours making these calls The AI can keep calling stolen-phone owners automatically And the criminals don't need to convince everyone They only need a small percentage of victims to hand over their credentials Once they do, the attacker may be able to remove the stolen iPhone from the owner's account, wipe it and resell it The phone was stolen first But the real target was the person who could unlock it Y'all stay safe out there

PhishCore™️ @PhishCore

2 days ago

AI Voice Bots Are Now Cold-Calling Stolen iPhone Owners to Phish Their Apple IDs.

0 0 12 13K 4

AI Voice Bots Are Now Cold-Calling Stolen iPhone Owners to Phish Their Apple IDs.

Can a phishing email come from a legitimate company account?

@rootshell0 @clamav Good one folks!

Can an email pass SPF, DKIM, and DMARC and still be malicious?

@zenturians Right

@Ankit_19june Correct 🔥

@ashshalawy Spot on!

@santhreal You’re right.

@rootshell0 🫡

YES. first, what these three actually do: SPF: confirms the email came from a server authorized to send for that domain. DKIM: confirms the email wasn't tampered with in transit. DMARC: ties the two together and tells receiving servers what to do if they fail. what none of them do: judge whether the content is safe. they authenticate the sender. not the intent. here's how attackers exploit that gap: Platform abuse An attacker registers a Calendly account sends a phishing lure through Calendly's notification system. the email comes from Calendly's infrastructure. Calendly is authorized to send for its own domain. SPF passes. DKIM passes. DMARC passes. Microsoft called this "authentication laundering" in a June 2026 warning about an active campaign targeting hotels across Europe and Asia the attacker registered a legitimate account on a trusted platform and used it as a relay. SPF, DKIM, and DMARC were never designed to stop that. legitimate platform, malicious payload attackers abused a real nonprofit fundraising platform to send fully authenticated phishing emails to K-12 school staff, the link inside routed victims to a credential harvesting page. your own account gets compromised if an attacker gets into a legitimate email account via OAuth phishing, credential stuffing, or password reuse and sends from it, every authentication check passes. because the email IS coming from the right server. from the right account. the signature is valid because it's real. SPF, DKIM, and DMARC were built to solve domain spoofing, which they did. Attackers stopped spoofing domains and started abusing real ones.

PhishCore™️ @PhishCore

5 days ago

Can an email pass SPF, DKIM, and DMARC and still be malicious?

6 1 12 24K 7

@SAP127001 @T3chFalcon phishcore.io/resources/phis…

You think you can spot a phishing email? Okay, prove it. We put together a Phishing IQ Test with realistic phishing scenarios. Some are obvious. Some are designed to make you hesitate. And one tiny detail could be the difference between safe and getting compromised. How good is your phishing detection actually? Take the test: phishcore.io/resources/phis… Share your score in the comments.

@CyberXash Spot on.

Can someone steal your session without stealing your password?

@_patriktang Supply chain attacks ✅

Can an attacker compromise you without installing malware?

@1cbyc 🫡

YES. 87% of successful cyberattacks in 2024 involved session hijacking after valid MFA logins. When you log into a website, your browser receives a session cookie. a small token that tells the site: this person already authenticated. like a wristband at a concert. you showed your ticket to get in. now you're inside and nobody checks again. an attacker doesn't need your password or your mfa code. they need the wristband. if they get the cookie, they become you. the server can't tell the difference. how they get it: — infostealer malware copies all cookies from your browser silently. Redline. Raccoon. Lumma. sold on dark web markets for a few dollars per infected machine. — adversary-in-the-middle phishing. you log in through a fake proxy that passes your credentials to the real site and captures your session token in real time. the real site thinks you logged in. the attacker now has your live session. — malicious browser extensions with permission to read all site data. Changing your password after a session hijack does nothing. the attacker's session token is still valid. still authenticated. the server doesn't know the session was stolen. it only knows it was issued. you have to explicitly invalidate all active sessions. most people skip this step because most people don't know it exists. what to actually do: — after any suspected compromise: go to account settings and sign out of all devices. not just change password. — use a password manager and check for malware before generating new credentials on an infected machine. — avoid browser extensions that request access to all sites. — for Google: myaccount.google.com/security → your devices → remove anything unfamiliar.

PhishCore™️ @PhishCore

a week ago

Can someone steal your session without stealing your password?

2 1 10 43K 3

YES. And this is one of the most important things most people do not understand about account security. Changing your password invalidates future login attempts using the old password. It does not invalidate sessions that already exist. Here is how session management actually works. When you log into an account the server generates a session token, a long random string, and stores it in your browser as a cookie. Every subsequent request you make sends that token to prove you are authenticated. The server validates the token, not your password, for every request after the initial login. Your password is only checked at the moment of authentication. Once a session token exists the password becomes irrelevant to that session. An attacker who stole your session cookie before you changed your password still holds a valid token. They are authenticated. Your password change happened at the credential layer. Their access exists at the session layer. Those are two different things and most platforms treat them independently. This is why session hijacking is such a powerful attack. The attacker does not need your new password. They do not need to log in again. They are already inside with a token that the server considers perfectly valid. The attack scenario plays out like this. Attacker steals your session cookie through malicious browser extension, public WiFi interception, XSS vulnerability, or malware. They import that cookie into their browser. They are now authenticated as you. You notice something wrong and change your password immediately. The attacker's session continues uninterrupted because the server never invalidated the existing token. Some platforms invalidate all existing sessions when a password change occurs. Google does this by default. Many platforms do not. Banking apps tend to handle this correctly. Consumer web applications are inconsistent. OAuth tokens and remember me tokens are a separate category that persist independently of password changes entirely. Third party applications that were granted access to your account through OAuth maintain that access through tokens that have their own expiry, often 30, 60, or 90 days, regardless of what happens to your main password. The correct response to a suspected account compromise is not just changing your password. It is changing the password and explicitly revoking all active sessions, reviewing and removing OAuth application access, and checking for any forwarding rules, recovery email changes, or account settings modifications the attacker may have made while inside. Most platforms offer a sign out of all devices option specifically for this reason. That action invalidates all existing session tokens and forces every device to reauthenticate with the new password. Password change stops future logins. Session revocation stops current access. You need both.

PhishCore™️ @PhishCore

a week ago

Can an attacker stay inside your account after you change your password?

1 0 11 45K 0

@divv_dev Good job! 👏🏼