DEV Community: Ahsan Luqman

Comic C-MoA Confirms 319 Leaked Member Records, 4.2M Logs

Ahsan Luqman — Thu, 22 Oct 2026 00:00:00 +0000

I run AliasFleet, an email-alias service: one forwarding address per site, so a leak names its source. NTT Solmare's Comic C-MoA notice has two numbers. The 4.2 million matters least (company caveat: the logs may duplicate users). The 319 emails carry hashed passwords; fear those.

The numbers behind the fourth notice

Comic C-MoA is a major Japanese ebook store; Nikkei puts its monthly user base above 40 million. The fourth notice landed on 21 October, six days after the store halted all service at 11:35 JST on 15 October. The second notice (16 October) confirmed a member-data leak; the third (18 October) said system log files had been viewed and taken. The fourth turns those "under investigation" counts into concrete numbers, with the rocket-boys security lab filling in the timeline that evening.

The member database lost 319 records. The fields: email address, hashed password, nickname, date of birth, sex. The notice explains hashing as storing the password in a form where the original cannot be read. That is a delay, not safety. A weak password can still be cracked out of a hash.

Then the log files: up to about 4.2 million records, holding email addresses, nicknames, dates of birth and sex, with no passwords at all. Not every record holds every field, and the company's own caveat stands: the count may include duplicates of the same user, so it is a record count, not a count of unique people.

Two negatives matter. The affected system never held credit card information. Purchase history did not leak, and MY bookshelf data neither leaked nor was damaged. NTT Solmare says the attack path and method have been identified and containment is complete, but the technique stays undisclosed. The company will contact affected users individually by email.

No resumption date yet. On resumption every user must reset their password; readily viewed works and the unlimited-reading service return first, purchases and payment functions after further safety checks. Unlimited-reading and monthly-plan members should not be billed for the dead period, and points that expired during the outage may be reissued. That settles the money questions. It does not change the security picture.

Two columns, because the notice draws the line itself: what the investigators confirmed, and what nobody has said yet.

Confirmed	Still unknown
319 member records: email, hashed password, nickname, date of birth, sex	How many unique people sit behind the ~4.2M log records
Up to ~4.2M log records: email, nickname, date of birth, sex, no passwords; the company's own duplication caveat applies	Whether the 319 member records overlap with the log records (possible per the rocket-boys analysis; the notice does not say)
Service stopped 15 October at 11:35 JST after suspected unauthorised access	When the intrusion began
Attack path and method identified; containment complete	The attack technique, deliberately undisclosed
No credit cards held; purchase history and MY bookshelf intact	Whether any of the leaked data has been misused or traded
All users must reset passwords on resumption	The resumption date, and how the forced reset will work

The big number cannot be replayed

Every headline will carry 4.2 million, and the notice deflates it fast. Logs are verbose: one person browsing the store can leave many rows, and the company gave no deduplicated count. So the figure measures the attacker's reach into the logging system, not a victim count.

Then the contents. No passwords. Emails, nicknames, dates of birth, sex, with fields varying from record to record. That is still personal data, and still useful for phishing. But nothing in it can be typed into another site's login form.

And the figure is an upper bound: "up to" about 4.2 million records, the maximum the investigators could not rule out. With the company's duplication caveat on top, the wide reading is the correct one: a large reach into the logs, an unknown number of people, no passwords. The notice confirms the leak. It does not confirm misuse.

The 319 that can

Each of the 319 is a complete login record: an email address paired with a hashed password, plus the nickname, date of birth and sex that make a phishing message feel personal. Hashing slows an attacker; it does not stop one who works the weak passwords out of the file first, and a hash is only as strong as the password behind it.

The tell is in what NTT Solmare asked victims to do. The notice explicitly tells anyone who reused the same email and password combination on other services to change it there. Companies write that sentence when they expect the pairing to be replayed. Replay needs two halves. The up-to-4.2M log records, a record count and not a count of unique people by the company's own caveat, have no passwords, so they cannot be replayed. The 319 have both halves. That asymmetry is the whole story.

This is also the part with a live phishing pipeline attached. NTT Solmare is emailing affected users individually, and attackers now hold the exact fields the genuine notice will reference: nickname, date of birth, sex. A forged company notice that greets you by nickname no longer takes any skill to write. This is how phishing uses your leaked email: your own details, read back to you, doing the attacker's credibility work for them. The company warns about exactly this: suspicious mail impersonating the company or its partners, and fake sites asking for personal information.

NTT Solmare is contacting affected users by email, and the attackers hold the nickname, date of birth and sex fields the real messages will reference. Do not click a link in any message about this breach. Go to the NTT Solmare notice yourself. A message that reads your own details back to you proves it has the file, not that it is the company.

One address per manga store

The email address you gave Comic C-MoA is the one field in this leak you could have made worthless to everyone but the store. An email alias dedicated to the manga store, forwarding to your real inbox, removes the cross-site pairing the attacker needs. That is what I built AliasFleet for: managed, persistent aliases, one per site. Not disposable addresses.

Picture the replay attempt with the alias in place. The attacker cracks a weak password and pairs it with the Comic C-MoA alias. They type that pair into a dozen other sites. Nothing matches anywhere. The email half works on exactly one site, because the alias was never typed anywhere else. Credential stuffing runs on the assumption that your address is the same everywhere. A per-site alias breaks that assumption at the root.

Then there is tracing. A phishing message landing on the Comic C-MoA alias tells you immediately which company's breach is feeding it, because nobody else ever had that address. That is the leak-tracing mechanism doing exactly what it exists for. And the setup guide takes about two minutes.

One limit, stated plainly: an alias does not change your nickname, your date of birth or your sex, and it cannot stop a company from writing those fields into a log file. What it protects is the replay path. In this breach, the replay path is where the real danger sits.

If you read manga on Comic C-MoA, do this

Change the reused passwords first. If your Comic C-MoA email and password matched anything on another site, change them on the other site now. That pairing is the attack the company's own notice warned about.
Expect impersonation mail and do not click it. The company is contacting affected users by email, so go to the official NTT Solmare notice yourself instead of following any link in a message about this breach.
Take the forced reset when it comes. Every user must reset their password on resumption. Use a password you have never used anywhere else.
Watch for phishing that knows your nickname. Your nickname plus your birthday is enough to make a fake support message feel personal. Anyone reading your own details back to you is proving they have the file, not that they are NTT Solmare.
Turn on two-factor authentication on your email account. Leaked names, birthdays and email addresses are the raw material of account-recovery flows. 2FA is the part the attacker cannot talk their way past.
Check Have I Been Pwned once the incident is listed, and walk the breach-response order of operations.

What NTT Solmare still has not said

Three things to watch. First, whether the 319 hashed passwords get cracked at scale, which would surface as credential-stuffing waves against other Japanese services. Second, whether the attack technique gets disclosed: the path is identified and contained, but every other ebook store is betting its own incident response on details it cannot see. Third, the resumption mechanics: the date, how the forced reset actually works, and what happens to accounts that never complete it. The notice confirms the leak. It does not confirm misuse. The same week brought Lawson's confirmation of a 2.155 million-member breach: Japanese consumer platforms are having a rough October.

SBI confirms dark-web leak of 3,897 customer records

Ahsan Luqman — Thu, 22 Oct 2026 00:00:00 +0000

SBI told the stock exchanges its dark-web data leak has no material impact on the bank. Nothing in the filing tells the 3,897 customers named in the data what to do. I run AliasFleet, an email-alias service: one forwarding address per site, so a leak names its source. This is not an account-takeover kit. It is an impersonation kit, and no one is coming to warn the people inside it.

The disclosure arrived Wednesday, 21 October, as a Regulation 30 filing under the SEBI (Listing Obligations and Disclosure Requirements) Regulations, 2015, titled "Incident involving Data Loss", reported by the Indian Express.

The filing answered the wrong question

The filing's headline message was written for one audience. SBI's own words:

"No material impact on core business operations, financial performance or business continuity."

That is the only question a listing regulation asks a bank to answer: are the shareholders hurt. The customers named in the file are not in that sentence.

What the bank was reacting to: on 16 October it received alerts from three separate sources, its Threat Intelligence Service Provider, the Defence Cyber Agency, and CERT-In, about suspected customer data on the dark web. Investigators examined roughly 375,000 records and identified 3,897 customer records containing personally identifiable information. The fields, per the filing: registered mobile numbers, dates of birth, names, gender, email IDs, residential addresses, branch and Customer Information File (CIF) identifiers, lead IDs, and metadata tied to loan and lead records plus other related files.

Read the passwords line carefully. The filing does not list passwords, PINs or one-time passwords among the exposed data, and no stolen funds have been reported. That describes the filing's contents. It is not a clean bill of health for any system.

The honest split:

Confirmed	Still unconfirmed
The disclosure: SBI's own Regulation 30 filing dated 21 October 2026	What the remaining roughly 371,000 records contain or whom they concern; SBI says a detailed assessment is underway
The alert date: 16 October, from three sources including CERT-In	The source of exposure; the filing names no entry point, vulnerability or compromised server
3,897 customer records containing PII identified in the preliminary analysis	Whether 3,897 records means 3,897 unique customers; SBI has not said
Data types listed: names, mobile numbers, DOB, email IDs, addresses, CIF identifiers, loan metadata	Whether SBI's core banking systems were touched at all
CERT-In-empanelled independent agency engaged; incident response protocols activated	Whether any affected customer has been or will be notified; SBI has not said

Five days before the filing, an actor calling itself Siriusim claimed on BreachForums to have released 3.75 lakh rows of SBI-linked data in CSV format, along with 2,722 PDF documents described as loan applications, supporting documents and account-opening applications. The claim was flagged on X by the monitoring account CyberPulse56 and picked up by YourStory and the Economic Times before SBI said anything. It is unverified, and SBI's findings do not attribute the incident to any named attacker. Treat the actor name and the 3.75 lakh figure as claims, not facts. The Free Press Journal examined four sample records the actor posted and found the phone numbers real, according to YourStory's reporting. That is a report, not a verification.

Who tells the 3,897?

The Internet Freedom Foundation went looking for a customer notice, a press release or an advisory from SBI and found none. So IFF wrote to SBI's chairman, with copies to the RBI governor and the CERT-In director general, demanding that every affected customer be told directly by SMS, email and letter, that a helpline and a self-check facility be set up, and that the bank disclose what the 2,722 PDF documents contain and whether KYC documents like Aadhaar or PAN copies are in them.

Indian law will not close this gap in time. Section 8(6) of the Digital Personal Data Protection Act, 2023, which would require a data fiduciary to notify each affected person of a breach, takes effect only in May 2027 under the staggered commencement, per IFF's analysis. The RBI's Advisory No. 3/2026 of March 2026 recommends banks notify affected customers, but it is non-binding. A bank can meet every reporting obligation on paper and still leave its customers uninformed. That is exactly what this picture looks like.

So assume no one calls you with a warning. If the phone rings and the caller quotes your branch, your CIF number and your loan application, you will have had no official notice to check them against. Prepare for the call, not for the press coverage.

A caller who reads your name, date of birth, branch and loan details back to you is proving they hold the file, not that they are SBI. Hang up and call the bank on the number printed on your card. No legitimate bank process starts with a stranger proving they know you.

The field you could have made traceable

Your name, your date of birth, your mobile number and your CIF identifier are not fields you can rotate. Once they circulate, they circulate. Your email address was the exception: the one field in this leak you could have made expendable before anything happened.

The mechanism is an email alias dedicated to the bank, forwarding to your real inbox. Daily use changes nothing; the bank's mail arrives as normal. The impersonation math changes completely. The real SBI holds exactly one address for you: the alias. A "security alert" that lands on any other address has identified itself as the forgery, because the bank never had that address. And when the leaked data circulates with the alias inside it, the alias names the source: that is the leak-tracing mechanism. Aliases are managed, persistent identities, one per service, kept for as long as the service needs them.

Plain limits. An alias does not take back this breach. The phone numbers and the loan metadata are out no matter which address the bank held, and the impersonation call will come over the phone, not the inbox. What the alias buys is a channel test for the bank's own messages and a source label on every message that arrives after the leak. One defensive layer, not the whole answer.

If you bank with SBI

Expect the call that knows too much. Anyone reading your own details back to you is proving they have the file, not that they are SBI. Hang up and call the bank through the number on your card or the official app.
Click nothing about this breach. Open the SBI app or type the address yourself. The phishing wave will quote the filing's real language to look credible.
Never share OTPs, PINs or passwords with a caller. SBI never asks for those. Hang up.
Watch your statements for unauthorised transactions. Report them to SBI on 1800 1111 09 or report.phishing@sbi.co.in, and to the national cybercrime helpline on 1930 or at cybercrime.gov.in (helplines via IFF).
Change reused passwords. The filing lists no passwords, but credential stuffing pairs your leaked email with passwords from other breaches. If your banking password matches one used anywhere else, change it there now.
Check Have I Been Pwned once the incident is listed and turn on its breach notifications. Then walk the breach-response order of operations.

What the investigation still owes

Three open threads. First, whether SBI upgrades the preliminary analysis to confirmed exfiltration and clarifies whether the 3,897 records are 3,897 unique customers, and what the remaining roughly 371,000 records contain. Second, the 2,722 PDFs: if those really are loan and account-opening applications, the affected population is far larger than 3,897, and the KYC question IFF asked, Aadhaar and PAN copies, gets serious. Keep the hedge in view: the PDF claim is the actor's, unverified, and the filing says nothing about it. Third, the source. IFF flagged that lead IDs and loan metadata point toward the lead-management side of lending, where vendors and direct selling agents handle customer data. If the investigation confirms that, the question becomes which third party held this much identity data, and under what contract.

Then there is the pattern. Bank of Baroda disclosed a cybersecurity incident to the exchanges in late July 2026, in near-identical regulatory language, after an anonymous communication claiming access to its data; its preliminary cause was "potential business email compromise", and the forensic investigation was still establishing scope when Cyber Security News covered it. Two state-owned banks in three months, both learning about their customer data from the outside, both telling the exchanges first. The customer finds out from the filing, if at all.

Your Inbox Is a Postcard: Eight Things You Must Never Email

Ahsan Luqman — Wed, 21 Oct 2026 00:00:00 +0000

Email is a postcard, not a sealed letter. I run AliasFleet, an email-alias service, and that is the mechanism behind everything on this list: every message you send rests readable on servers you will never see, copied into backups, forwarded threads, and inboxes you do not control. Some things should never go through that channel, and the eight below are the worst offenders.

What happens to your mail after you hit send

Your provider reads it. Google ended Gmail ad personalisation scanning in 2017, but its terms still let automated systems analyse what you send, receive, and store. Spam filtering and malware detection need that access, and so does anyone with a warrant. So did whoever breached the provider: the August 2013 Yahoo breach eventually reached all 3 billion accounts, and every old email sitting in Yahoo's archives went along for the ride.

The trip there is not sealed either. SMTP was built as cleartext, and the STARTTLS bolt-on asks the receiving server whether it supports encryption, then silently falls back to plaintext when the answer is no, or when an attacker strips the question out of the conversation. DigiCert's STRIPTLS write-up walks through the downgrade; APNIC's 2024 audit shows it in practice. Google's own transparency numbers, cited in that audit, put about 2 percent of Gmail's outbound mail in the unencrypted bucket. Two percent of Gmail is a mountain of postcards.

Have I Been Pwned currently lists 1,047 breached sites and more than 17.8 billion exposed addresses (haveibeenpwned.com). If your address is ten years old, assume your sent folder has been photocopied. The items below are the ones where the photocopy hurts.

1. Passwords

Day one. The new hire needs the Wi-Fi password, so you email it to her. Ten years later it is still sitting in your sent folder, in her inbox, and in the backups of both providers, on terms neither of you chose.

When either side is breached, that address plus password joins the lists feeding credential stuffing: automated login attempts replayed against banks, shops, and inboxes while the attacker sleeps. Nobody sends one password by email. They send them for years and forget every one.

Share credentials through a password manager's shared vault instead, or an encrypted one-time secret link that burns after a single read. If someone emails you a password, change it the moment it works, then delete the message. If you have ever emailed one to yourself "for safekeeping", change it now. Your inbox is the master key to every account you own, which is why this one matters more than the rest.

2. One-time codes

The code lands in the same inbox that receives your password resets. NIST treats that as a structural failure: under SP 800-63B, email is not a valid out-of-band channel, because an inbox is an account you can reach from anywhere. Avatier's 2026 walkthrough of the standard puts it bluntly. An emailed code usually collapses the second factor back into "something you know".

Where a site offers an authenticator app or a passkey, take it. Where email codes are the only option, switch them on anyway, because a weak second factor still beats none, and hand that site a per-site alias so the code lands somewhere other than your main address. The full ranking of email codes against stronger factors is a separate deep dive.

3. ID scans and identity documents

The letting agent replies with the line everyone has heard a hundred times: just email over a scan of your passport. Landlords, employers, hotels, and visa agents all ask, and everyone complies. That scan then sits in two inboxes and their backups, searchable forever. Paired with the name and address already in the thread, it is most of an identity-theft kit in a single file. The full chain is ugly: one leaked document to fraudulent accounts.

Use the recipient's secure upload portal where one exists. Where it does not, an encrypted share link that expires beats an attachment, because the file never takes up permanent residence in two email archives. For the highest-stakes documents, verify in person. A passport scan in an email should feel as wrong as it is.

4. Bank and card numbers

A supplier emails: send your card details to hold the order. The number you type out lands in your sent folder for good, and the recipient's copy drags their environment into the same compliance problem. One breached inbox on either side and the number is in a dump. Stripe's PCI DSS checklist states it as a flat rule: "Never send card numbers over email or unencrypted channels." (source)

Use the bank's secure messaging inside its own app, a compliant payment link, or the phone. Call a number you found yourself on the bank's own site, and read the details out. Never send them to a number or address that contacted you first. If a business asks for card details by email, that request tells you everything about how they handle data. Pay someone else.

5. Wire instructions and payment changes

The most expensive item on this list. The standard move in business email compromise: a message, often from a spoofed or compromised account, carrying "updated bank details" or "new wire instructions". The victim sends a real payment to the attacker's account. The money is gone before anyone checks. In 2024 the FBI's Internet Crime Complaint Center logged 21,442 of these complaints, with losses close to $2.8 billion (via Nacha's summary of the IC3 report).

The rule is absolute. Confirm every payment instruction by voice, on a number you already had, before money moves. Treat any emailed change of account details as hostile until a human voice you recognise says otherwise. House purchases, supplier invoices, salary payments: no exceptions. The post-breach phishing playbook is the same forgery in different clothes: content you were told to expect, arriving through a channel you cannot verify by reading.

6. Your real email address

This one surprises people. Your address is the one identifier that appears in nearly every breach file. Hand it to a hundred sites and a hundred databases hold the string that ties your accounts together. The journey a signup address takes after you submit runs through trackers, ad platforms, data brokers, and eventually someone's breach dump.

Where a site does not need your real address, hand it a dedicated email alias instead. One alias per site means the next breach exposes an address that belongs to that site alone, and you pause it in one click. That is the one-address-per-site habit; the set-up guide takes a couple of minutes. The limit belongs in the same breath: an alias changes who holds your address, not how email works. Aliased mail travels the same postcard channel as everything else.

7. Private photos and videos

Open your sent folder and scroll back. Years of private photos are sitting there, in sent threads and received threads, on both ends. An account takeover exposes all of it, not just new mail, and every forwarded copy made another one you will never find. If that sentence made your stomach drop, check whether the old address is already circulating.

For anything you would not publish, use end-to-end encrypted messaging, where the provider cannot read the content at rest and no searchable server-side archive waits to be breached. The archive is the feature that makes email dangerous here. The same system that keeps your receipts findable keeps everything else findable too.

8. Health records and test results

Lab results, diagnoses, prescriptions, insurance claims. In the US, the HIPAA Security Rule only lets providers send health data to patients by unencrypted email after warning them of the risk and getting their agreement (Holland and Hart's HIPAA email analysis walks through the HHS position). Your own emails carrying health data get none of that protection. They sit in inboxes that employers, insurers, and attackers would all find interesting.

Use the patient portal. Clinics, labs, and insurers all run them now, and they exist precisely because email is the wrong channel. If a provider insists on email for health documents, ask for the portal or an encrypted alternative before you comply.

The postcard test

Before you send anything on this list, run the postcard test: imagine the message printed out and readable by everyone who handled the servers between you and the recipient. If that is fine, send it; if it is not, use the alternative from the table.

Never send this by email	Send it this way instead
Passwords	Password manager shared vault, one-time secret link
One-time / 2FA codes	Authenticator app, passkey
ID scans and identity documents	Secure upload portal, expiring share link, in person
Bank and card numbers	Bank app secure messaging, compliant payment link, phone call you initiated
Wire instructions and payment changes	Verbal confirmation on a known number, every time
Your real email address	A dedicated alias per site
Private photos and videos	End-to-end encrypted messaging
Health records and test results	Patient portal, encrypted email service

You cannot un-send the mail that is already out there. You can still contain what comes next. Work through the breach-response checklist, lock the inbox itself down hard, and stop handing new sites the address that is already everywhere (the honest answer on giving your email to websites). The postcard system is not going away. What you write on the postcard is still your call.

Signs Your Email Was Hacked, and Where to Check Them

Ahsan Luqman — Wed, 21 Oct 2026 00:00:00 +0000

A hacked inbox announces itself. The proof sits in your own settings and activity log, not in breach news, and almost nobody checks there. I run AliasFleet, an email-alias service, and this guide is the detection half of the job: how to know someone is inside your inbox, before you do anything about it.

Most people check backwards. A breach hits the news, they run their address through Have I Been Pwned, and stop there. That database tells you which stolen files contain your address. It says nothing about who is reading your mail right now. Google's own hacked-account checklist starts somewhere else entirely: changes you did not make, inside your own account.

The signs arrive in your own inbox first

Start with the mail itself. Two minutes of looking beats an hour of worrying.

Sent mail you did not write. Open the Sent folder and scan for anything you do not recognise. Attackers use a hijacked inbox to phish the contact list, then delete the evidence, so Sent is the first witness. Ask a contact as well. Google's checklist names "your friends say they got spam or unusual emails from you" as one of the core signs.

Mail that never arrived. Google lists "you no longer receive emails" and "your emails were deleted from your inbox and are not found in Trash" as signs of compromise. If expected mail stops landing, do not assume the sender forgot. Check Trash and Spam, then check the settings panels in the next section. Missing mail is usually a filter doing its work, not a delivery failure.

The password-reset flood. A wave of reset emails you never requested proves someone is trying. It does not prove they got in. Which? reports three causes: deliberate targeting, an automated attack working through a leaked credential list from an older breach, or a stranger who mistyped their own address. Their key line: one request does not mean the attempt succeeded. With a strong unique password and two-factor switched on, a one-off is usually safe to ignore. A pattern of them is not.

Security alerts that ride on real fear. Expect one more shape: the alert that looks like Google or Microsoft and urges you to click. Some are genuine. Some are the attack itself. The rule survives both cases. Never click the link. Open a new tab, type the provider's address yourself, and check the security panel directly.

The forwarding rule you never set

This is the quietest sign, and the one most guides skip. An attacker inside your inbox sets up automatic forwarding to their own address. After that they never need to log in again. They just read.

Gmail warns you, but only briefly. For the first week after forwarding is turned on, a banner reads: "You are forwarding your email to [email address]." Gmail's own forwarding help says that if you see that notice and never set it up, someone else might have access, and you should change your password immediately, then turn forwarding off in Settings. The banner expires after a week. The rule does not.

The check is manual and takes thirty seconds. In Gmail on a computer: Settings, then See all settings, then the Forwarding and POP/IMAP tab. A forwarding address you did not add is your answer. Then check the second hiding place, Filters and Blocked Addresses, where a filter can forward, archive, or delete mail without ever showing a banner. Google's hacked-account checklist tells you outright to remove any labels, filters, or forwarding rules you did not set up.

This audit has to be separate from the password step. A new password closes the password route. It does not remove a forwarding rule or a filter. Those settings survive a password change, which is exactly why Google lists them as a separate action.

A hacked inbox does not have to mean a hacked life

Stated plainly: aliases do not stop an inbox from being hacked. Nothing about a forwarding address hardens the mailbox itself. The fit is containment, and it works after the lockdown, not instead of it.

When every site holds a different alias, a compromised inbox stops being a master key. Kill the one alias the attacker harvested and the leak stops spreading: their mail bounces, the address is worthless, and your real inbox and every other alias keep working. Spam landing on one alias also names the site that leaked the address, which is the mechanism our leak-tracing guide walks through. For the mechanics, what an email alias actually is and the two-minute setup are the starting points, and the one-alias-per-site habit is the full argument.

With one alias per site, a "security alert" from your bank arriving on any address other than your bank alias is fake by definition. You do not need to inspect headers or hover over links. The wrong address is the whole tell.

Sessions and devices you do not recognise

An attacker cannot use your inbox without appearing on the device and activity lists. Every major provider keeps one.

Gmail first, since that is where most readers live. Scroll to the very bottom of the inbox on a computer and click Details next to "Last account activity". The popup lists every recent access: IP address, rough location, browser or device type, time. A country you have not visited is a flag. From there, TechCrunch's detection guide walks through Security Checkup, which puts your signed-in devices and Recent security activity on one screen.

Outlook hides its evidence one level deeper. Open your Microsoft account, go to Security, and find the sign-in activity view. Microsoft's Recent activity page covers the last 30 days; each entry expands to location, IP address, device type, and browser or app. Unusual activity gets its own section with "This was me" and "This wasn't me" buttons. Scan the event types even when nothing looks wrong: Password changed, Alias added or deleted, App password created, Permission given to an application, Sign-in blocked (Account compromised). Microsoft adds two caveats of its own: the page shows significant events only, not everything, and mobile networks route through odd locations, so one strange location on a phone network is not proof of anything.

Yahoo gets a shorter treatment, for a sourcing reason. Its My Account Overview has a "Review recent activity" view showing password changes, added phone numbers, connected devices, and IP addresses. Yahoo's own help pages were unreachable while I researched this, so the click path comes from TechCrunch's guide rather than Yahoo's docs. If the menu names have shifted, take the closest match in the account settings.

Apple is the simplest check of the four. On an iPhone, open Settings, tap your name, scroll to the device list. Apple's device-list guide spells out what a signed-in device can do: change your password, receive two-factor verification codes, edit your personal information, sync with iCloud. A device you do not recognise is not a curiosity. Remove from Account.

"these methods don't guarantee that you haven't been compromised."

TechCrunch's caveat, and it applies to every panel above. They catch the common cases. A careful attacker leaves little trace, so clean panels are good news, not a verdict.

Provider	Where the evidence lives
Gmail / Google	Inbox bottom: "Last account activity" > Details; Security Checkup: devices and Recent security activity
Outlook / Microsoft	Microsoft account > Security > sign-in activity; Recent activity page covers the last 30 days
Yahoo	My Account Overview > Review recent activity: password changes, devices, IPs
Apple Account	Settings > your name > device list; Remove from Account for anything unknown

What a breach check cannot tell you

Run the breach check anyway. Our walkthrough of reading a Have I Been Pwned result shows how to do it properly, breach by breach. Then keep the two questions apart:

Breach news answers: has my address appeared in a stolen file?
Your account activity answers: is someone inside my inbox right now?

A breach does not mean your inbox is hacked. A hacked inbox does not require a breach. Most takeovers start with phishing, password reuse, or malware on your own machine, and none of those appear in a breach database. Run the breach check, then answer the harder question in your own settings.

If you find something, recovery is the next job

Detection and recovery are two different jobs. If the checks above turned up anything, a forwarding rule you never set, unknown sessions, mail you did not send, do not stop at changing the password. Our recovery guide walks the full eviction: sessions, recovery methods, planted mail rules, connected apps, and the alias rotation that finishes the job. If the trail leads back to a breach rather than a takeover, the breach-response order of operations picks up from there.

The audit itself is cheap. Twenty minutes, the four panels above, once in a while. Your inbox will tell you it is hacked long before the news does. Just be the one who looks.

How to Report a Phishing Email in Gmail and Outlook

Ahsan Luqman — Wed, 21 Oct 2026 00:00:00 +0000

Delete a phishing email and you protect yourself. Report it and you protect a few thousand strangers as well. That is the whole argument of this page: reporting is the one click that protects everyone else, not just you. Deleting ends the story at your inbox. Reporting feeds the message to the filters at Google and Microsoft and into the takedown pipelines that shut campaigns down.

Why the report matters more than the delete

A phishing campaign runs on volume. One wave hits thousands of inboxes in an afternoon, while the link is fresh and the filters have not seen it yet. Every report teaches the filter what this wave looks like. The faster the filter learns, the shorter the wave lives.

The numbers back this up. The US Federal Trade Commission says email was the number one way scammers reached people in 2024. Google's own help page says that when you report in Gmail, it receives the message and can analyse it and its attachments to protect users from spam and abuse. Microsoft says the same about its end: the report reaches its security systems and improves the filters, so everyone sees fewer of these messages.

And the report does not stop at the provider. The UK's National Cyber Security Centre says it has removed 454.8k scam URLs as of July 2026, working from emails the public forwards to it, and it confirms it acts on every message received. The Anti-Phishing Working Group runs the clearinghouse that security firms and law enforcement use to track campaigns. The FTC shares reports with more than 2,000 law enforcement partners. One email, several machines, all of them real.

Report it in Gmail

Google's documented steps, from its own help page:

On a computer, open the message. Read it. Touch nothing inside it.
Click More (the three dots) next to the Reply button.
Click Report phishing. Gmail asks you to confirm; confirm.

The message leaves your inbox and Google gets a copy to analyse. That is the entire procedure.

One note on where this is documented: Google's page describes the computer path. The mobile app has the same reporting options, but if your version lays them out differently, the desktop steps above are the ones Google guarantees. And if the email was never flagged and sits in your inbox looking ordinary, that is exactly when the manual button earns its keep. Reporting an unflagged message is what it is for.

Gmail also puts warnings on messages it already suspects. Those warnings deserve respect. Google's rule on its own page is plain: pay attention to them, and never enter your password after clicking a link in a message. If a security email looks like it came from Google and you are not sure, open your Google account's security page yourself and check recent activity there, instead of trusting the email.

Report it in Outlook

Microsoft's current steps for Outlook.com, from its own help page:

In the message list, select the message. You can select several at once, and you do not need to open it.
Above the reading pane, select Report, then Report phishing.

Microsoft 365's desktop app uses the same path: select the message, then Report > Report phishing from the ribbon. Microsoft's page covers both the classic and simplified ribbon layouts, so whichever one you have, the steps hold (its broader guide repeats them).

Two things worth knowing. The reported message is removed from your inbox. And reporting does not block the sender: Microsoft says this directly, and to stop that address reaching you again you add it to your blocked senders list separately.

Report it from the alias that received it

Most reporting guides miss this part. That is the reason this piece is on an alias blog.

When you report a phishing email, one of the most useful facts in the report is where the message landed. If you use one email alias per site, the receiving address names the source. A "bank" email arriving on the alias you gave only to a bookshop has convicted itself before you read a word. It also tells the report something specific: the address that escaped came from the bookshop.

Each alias is a separate forwarding address tied to one site, so the To field on a phishing email is a record of who held that address (the leak-tracing piece walks through how that works). In a report, that attribution is evidence. It says the campaign is working from a list that leaked out of a specific place. That is precisely what the takedown teams need to trace a campaign to its source.

So report from the alias. Do not tidy the email first: the headers and the receiving address are the useful part. If you want this machinery in place before the next wave, the set-up guide takes a couple of minutes, and you can start with the ten free aliases on AliasFleet.

Send it to the people who take campaigns down

The provider buttons feed filters. These addresses feed the people who remove the infrastructure. The cheat sheet:

Who you are	Where the report goes
Gmail user	More > Report phishing in the message, then delete
Outlook.com / Microsoft 365 user	Report > Report phishing, then block the sender separately
Other email client	Attach the message to phish@office365.microsoft.com, do not forward it
US resident	reportphishing@apwg.org, then ReportFraud.ftc.gov
UK resident	report@phishing.gov.uk (skip mail already in your spam folder)
Target of a tech-support scam	microsoft.com/reportascam

The details behind the table:

United States: forward the phishing email to the Anti-Phishing Working Group at reportphishing@apwg.org, then file the attempt at ReportFraud.ftc.gov. That is the FTC's own guidance, spelled out in its consumer alert.
United Kingdom: forward suspicious emails to report@phishing.gov.uk. The NCSC's reporting page asks you not to bother with anything already sitting in your spam folder, and the wider GOV.UK guidance lists 7726 for scam texts too.
Tech support scams: Microsoft runs a dedicated form at microsoft.com/reportascam for scammers posing as Microsoft or another tech company.
If you use a client other than Outlook: Microsoft asks you to attach the phishing message (never forward it) to a new email to phish@office365.microsoft.com, so it can examine the original headers. That is the documented route on Microsoft's own support page, and the APWG is where the attached message counts most for campaign tracking.

What never to do with it

Short list. All of it matters.

Do not click anything inside the email. Not the links, not the attachments, and not even the unsubscribe link. Google's rule is blunt: never click links from strangers or untrustworthy sources. An unsubscribe click on scam mail confirms your address is live, and the spam-harvesting piece explains why live addresses are the ones that get traded.
Do not reply. A reply confirms the address is active and hands the attacker a sample of your writing. Microsoft's advice on the same page: never use anything inside the message to verify the message.
Do not forward it to your contacts as a warning. A normal forward sends live, clickable links to your friends. If you want to warn someone, send a screenshot with the links broken or typed out, and tell them to verify through the company's own app. The phishing-check guide covers the verification drill. And if you are tempted to post the email online, crop your own address out first. A screenshot with your address visible puts it one more place where it can be harvested.
Do not enter your password after clicking a link. If you already clicked through to a login page, close it and go to the site by typing the address yourself. Google's help page states this exact rule for Gmail users.

Never use a phone number, link, or reply address inside a suspicious message to verify that message. They all lead back to the attacker. Verify through a route the message cannot touch: the company's app, a number on your card or statement, or an address you type yourself into a fresh browser tab.

Already clicked something?

Act now, in this order:

Close the page. Enter nothing more.
If you entered a password, change it on the real site (typed by you, not linked), then everywhere else you reused it. Turn on two-factor authentication.
If you shared payment details, call your card issuer on the number printed on the card.
If a work or school account was involved, tell your IT support people about the possible attack. Microsoft lists this as a step on its own page, and it matters because the attacker may have moved sideways into your workplace. If money changed hands or identity data was handed over, report it to local law enforcement too.
Check Have I Been Pwned to see what else is circulating, then run the leak check properly and work through the full breach-response checklist.

Said plainly, since nobody else will say it: I honestly cannot tell you whether your single report took down one specific campaign. Nobody can, and anyone who promises otherwise is guessing. What the numbers show is that the machinery your report feeds is real: hundreds of thousands of scam URLs removed, filters retrained, reports shared with thousands of investigators. The click is small. The machinery behind it is not.

Stolen UpdraftCentral Keys Are Backdooring WordPress Sites

Ahsan Luqman — Wed, 21 Oct 2026 00:00:00 +0000

TeamUpdraft disclosed on Monday that attackers accessed its customer database over the weekend of 17-18 October. Stolen UpdraftCentral keys are already being used to backdoor fully patched WordPress sites with properly signed commands. I run AliasFleet, an email-alias service: one forwarding address per site, so a leak names its source. The database is not the dangerous part of this breach. The keys are.

What the vendor confirmed

The vendor notice went up on 19 October at 11:57 UTC and was last updated on 20 October at 16:25 BST. The page is still moving.

Confirmed	Still unconfirmed
Attackers reached teamupdraft.com during the weekend of 17-18 October 2026	Whether the customer database was actually exfiltrated; TeamUpdraft says it "believes" it was accessed
Data at risk: names, email addresses, billing addresses, order history, hashed passwords, 2FA settings, connection keys for UpdraftCentral, UpdraftVault and UpdraftClone	How many customers are in the database; no customer count has been published
No card details stored; Stripe and PayPal handle all payments	How the attacker got in; the notice cites a fix for an "underlying weakness" and says nothing more
The UpdraftPlus plugin and its downloads were untouched; self-hosted UpdraftCentral was untouched; backups sent to customers' own storage were untouched	Whether the stolen data will surface publicly or be sold
UpdraftPlus 1.26.13 (free) / 2.26.13 (Premium) released the evening of 19 October; every UpdraftVault site disconnected; every UpdraftClone client key replaced; the incident reported to the UK ICO	Whether keys outside the vendor's stated cutoff were used on sites that never deleted them

One line in the notice tells you what the company fears most: "We will never ask for your password or keys." It is there because TeamUpdraft knows the names and email addresses in that database are now the raw material for a phishing wave wearing its own branding.

The keys are the story

UpdraftCentral is TeamUpdraft's remote management service, and the client comes bundled in every copy of UpdraftPlus, free and premium alike. A site holding a key executes any command signed with the matching dashboard private key. Those private keys never touch the connected sites; they sit with the UpdraftCentral cloud service. Which means the safety of every connected site hangs on one assumption: that the keys never leave there.

They left. The database held them, and attackers put them to work within hours.

Slovak security firm Nethemba found the campaign on three of its own WordPress sites in the early hours of 19 October and published the first analysis the same day. Patchstack confirmed the findings and extended them. Its telemetry recorded backdoor installs running from 15:32 on 18 October to 09:23 on 19 October (times read as UTC from the page context). It counted 99 different backdoor plugin names. One detail does the detection work: every sample carries the identical plugin description "Small maintenance toolkit: keeps option storage tidy.", and the name "Site Health Cache" is reused repeatedly.

This is not a plugin vulnerability. The commands are correctly encrypted and signed with genuine dashboard private keys. From the site's point of view the instruction is legitimate, so every check in the plugin passes. Patchstack rates it 9.8 CVSS and issued no CVE. There is no code flaw to patch. Every UpdraftPlus version is affected the same way: 4M+ active installs per wordpress.org, free and premium. Updating the plugin does not stop the attack. The fix is deleting the UpdraftCentral key stored on the site. Removing the site from the UpdraftCentral dashboard is not enough, because the key that matters lives on the site.

Nethemba's sites were fully patched and running Wordfence, Patchstack and Cloudflare. None of it stopped a signed command. Nethemba ruled out every site-side explanation in turn: plugin files byte-identical to the official release, key fingerprints matching daily backups back to 15 October, sound cryptography, no unauthorised admin or plugin upload in the logs. The requests even carried the wrong fingerprint. Genuine dashboard traffic identifies itself with a library version and a teamupdraft.com URL. These came from the attacker's own server. Nethemba CEO Pavol Luptak put it plainly: "Whoever holds them can install and run arbitrary code on every connected site without the owner knowing."

The backdoor is built to survive. It watches for a secret URL parameter carrying a 32-character token, then creates an account with a hardcoded password, assigns it the Editor role, and grants manage_options and install_plugins on top. It logs the attacker in with a persistent cookie, so the login form, two-factor authentication and attempt limits never run. The account shows as an Editor, so a glance at the administrator list misses it. Removing the plugin does not remove the account, and the attacker knows its password. Early variants threw HTTP 500 on uncached requests, which is how the first victims noticed within minutes. Do not repair such a plugin. Fixing the error switches the backdoor on. Remove it. One later variant hides from the plugin list entirely.

Then the finding that widens the victim pool. The teamupdraft.com account screen carries a checkbox reading "Add this website to UpdraftCentral (remote, centralised control) - free for up to 5 sites", ticked by default. Leave it ticked and a successful login creates an UpdraftCentral key. Plenty of sites hold keys nobody deliberately created, and keys do not expire: keys issued in November 2025 still worked in October 2026. An estimate Nethemba cites from the vendor's June disclosures puts the share of users holding an UpdraftCentral or Migrator key under 10%, which still means up to roughly 400,000 sites in the exposed surface. Hosting provider Levamo put it at more than 100 compromised sites by Monday, with the attacks still in progress.

If you have ever bought or registered anything through TeamUpdraft, assume your name and email address are in that database. Check Have I Been Pwned once the incident is listed, and walk the breach-response order of operations. Now expect emails wearing TeamUpdraft's name asking you to confirm your password or keys. TeamUpdraft says it will never ask for those. Do not click any link in such a message; type teamupdraft.com into your browser yourself.

What to do today if you run UpdraftPlus

Work through this list in order, logged into each site's own WordPress dashboard. Never through UpdraftCentral.

Update to UpdraftPlus 1.26.13 (free) or 2.26.13 (Premium). Not 1.26.12. Nethemba read the code and found 1.26.12 deletes zero keys because of a bug, which the vendor repaired the same evening in 1.26.13. The vendor says 1.26.13 automatically disconnects UpdraftCentral connections made before 22:00 BST on 18 October.
Mind the revocation gap. Nethemba's code review found that 1.26.13 deletes only keys created before 12:07 UTC on 18 October. Keys created between 12:07 and 21:00 UTC that day remain on the site. Remove them by hand: Settings, UpdraftPlus Backups, Advanced Tools, UpdraftCentral, delete every key. That finding is Nethemba's reading of the code, not the vendor's claim. Act on it anyway.
Check every site for a key, including ones that never used UpdraftCentral. The default-ticked checkbox means keys exist where nobody created them on purpose. Any output from wp option get updraft_central_localkeys means the site holds one.
Walk through Plugins, must-use tab included, and flag anything you do not recognise. The strongest indicator is the description "Small maintenance toolkit: keeps option storage tidy." Delete anything suspicious. Never try to repair it.
Review Users by capability, not by role. The backdoor account looks like an Editor while holding manage_options and install_plugins. Remove it, and drop the _sync_token database option if it is there.
Change every administrator password, end existing sessions, and change your teamupdraft.com password from a clean device. If two-factor is on at teamupdraft.com, reset it in My Account.
If you find anything suspicious, consider restoring from a backup taken before 17 October, then re-secure the site before reconnecting anything.
Wordfence shipped an emergency firewall rule as a temporary kill switch for the UpdraftCentral command channel, to Premium customers first and Free users a few hours later. Refresh your firewall rules manually. The rule cannot undo anything that happened before it landed, and it temporarily blocks legitimate UpdraftCentral commands too.
Do not reconnect to UpdraftCentral until the vendor explains how the keys left its database. Patchstack's advice is to leave the channel dead. Backups keep working after key deletion. Only remote management stops.

The address you can wall off

The second half of this breach is aimed at you personally. The customer database holds your name, your email address, your billing address and your order history. That is a complete phishing kit: real names, real context, and now the perfect pretext, because every UpdraftPlus customer has a reason to expect an urgent email about keys and passwords.

Give TeamUpdraft a dedicated email alias instead of your real address, forwarding to your inbox. The mechanism is simple. The alias belongs to exactly one vendor, so every message on it is either from TeamUpdraft or from the attacker, and there is no third option. A "security update" demanding your password, arriving on an address TeamUpdraft never had, has identified itself as the forgery without you inspecting a single header. That is the leak-tracing mechanism: the alias names the source. Kill the alias and the impersonation channel dies while your real inbox stays clean. The set-up guide takes about two minutes. If you already handed TeamUpdraft your real address, move the account to a fresh alias now, because this database will circulate. Securing your email account is the other half of the work.

Plugin vendors are the inbox nobody thinks to protect. You connect an account to activate a licence. The vendor stores your email next to the keys to your server. One weekend later, both are in someone else's hands.

What to watch next

Three things. First, the entry point. TeamUpdraft says it fixed the "underlying weakness" but has not said what it was. A vendor that cannot name the door cannot promise it is closed. Second, the customer count. No number has been published, and 99 backdoor plugin names is a count of names, not of compromised sites. Third, the 12:07-21:00 UTC gap. The vendor's 20 October update says the unauthorised access was resolved and 1.26.13 revoked the keys, but Nethemba's warning stands: stolen keys keep working until the site deletes them. Any site with a key created in that window is still an open door. The investigation continues. So does the impersonation.

Your Email Address Is Semi-Public, So Audit Where It Leaks

Ahsan Luqman — Wed, 21 Oct 2026 00:00:00 +0000

Is your email address public? Wrong question. It is semi-public by design: handed to companies on signup forms, scraped off public pages, traded through broker chains, and dumped whenever one of those companies gets breached. I run AliasFleet, an email-alias service, and this page is the audit I point people at. The question that matters is not whether your address is out there. It is which of your addresses is exposed, and whether you can kill that one without touching the rest.

You probably have one address you have used for everything since 2014. That is the one we are auditing. And the fix at the end is structural: one address per site, so each exposure names its source and can be switched off. First, the map of the damage.

Breach dumps are the biggest supply line

Have I Been Pwned currently lists 1,047 breached websites holding 17,846,550,965 compromised addresses. Every one of those addresses came from someone typing it into a signup form. That is what makes a breached address valuable: it is known-active. The signup you made in 2014 is still working for someone in 2026, because breach files do not expire. They get copied, sold, and re-sold for years, and the same address keeps producing junk long after the company involved has moved on.

Start there because it is the easiest to check and the hardest to fix. Our guide to checking whether your email leaked walks through reading each result properly, including the breach flags HIBP attaches. For how these files escape companies in the first place, see how data breaches happen. And if typing your own address into a breach search feels wrong, we answered that separately.

The brokers who never met you

Separate from the criminals, there is a legal industry that assembles your address without any hacking. The FTC's 2014 study of nine data brokers found one broker holding 1.4 billion consumer transactions and 700 billion data elements, with another adding 3 billion data points every month. Seven of the nine were sharing data with another broker in the study. Your address rides along with loyalty-card purchases, warranty registrations, magazine subscriptions, and public records, then lands in a people-search profile on a site you never visited. Three or four companies can handle your address before the first spam arrives, and none of them ever met you.

Enforcement is real and slow. In May 2026 the FTC moved to permanently bar broker Kochava from selling precise location data without explicit consent. In 2020 the UK's ICO ordered Experian to fundamentally change its marketing data business after finding "invisible processing" of people's data. Our data broker explainer covers the full chain.

The FTC can fine a broker and the ICO can order one rebuilt. Neither action deletes your address from the files already sold and re-sold. Cleanup after the fact is your job. That is what the audit below is for.

Harvester bots read the open web

Before breach databases existed, there were bots. The documented harvesting sources include public forums, staff directories, mailing-list archives (Google Groups is named explicitly), Usenet posts, and WHOIS records. A plain-text address on a public page is the oldest feed there is: a 2016 walkthrough of spammer methods still describes the web as the first place spammers look.

Programmers get a special mention here. Every public commit you pushed to GitHub with your personal email in the git config is still associated with that address; GitHub's own docs confirm that old commits keep the old email even after you change it.

The craftier variant never touches a public page at all. Direct marketers match your name and postal address to an email, a practice called e-pending, and some sites sell your form data to spammers through an HTTP POST the moment you hit submit, splitting the revenue. The harvesting literature calls these the best addresses spammers can get: fresh, and from someone who just proved they buy things.

Google already indexes half of it

Type your address into Google inside quotation marks and you see the public surface exactly as a stranger would: forum profiles, old mailing-list posts, PDF newsletters, directory listings. Google's quoted-search syntax does exact matching, so the results are precise.

Then switch on Google's Results about you. You register your email addresses, and Google monitors search results for them, lets you request removal, and notifies you when new matches appear. Read the fine print on that page before you celebrate: removal only takes the result out of Search. The source page survives. And Google declines removal for results from government and educational sites and newspapers.

The counter you handed it over at

One channel has no leak in it at all, because nothing leaked: you handed the address over and the site sold it. The form-data-sold-at-submit practice from the harvesting literature is the freshest supply traders get, because the person just proved they engage. No breach check finds this, because no breach happened. No broker opt-out touches it, because the transaction was the signup itself. This is the channel that makes "one address for everything" expensive: a single address, reused for a decade, is a single asset you keep giving away.

Make exposure containable, not permanent

You cannot un-publish the past. You can stop every new exposure from being your main address. An email alias is a separate forwarding address that exists for one relationship: one site gets one address, and mail to it lands in your inbox. The privacy logic is simple, and it runs on the sources above in reverse. The piece that mapped where spammers get their addresses shows the other side of the same trade: the resale market only works because one address shows up everywhere. When a breach dump surfaces, the breached address belongs to exactly one site, so you know who leaked it. When a broker profile includes an address that was only ever given to one store, you know who sold it. Our leak-tracing guide shows the mechanism: the To field names the source before you even open the mail. And when an address goes noisy, you switch it off in one click without touching your real inbox.

The sources above all feed on one thing: the same address, everywhere, forever. Break that pattern and each leak becomes small, traceable, and killable. That is the entire model behind AliasFleet: managed, persistent aliases, one per site, under your control. Setting one up takes a couple of minutes, and the one-address-per-site habit is the whole system. It does not scrub a decade of exposure. It makes every exposure from today forward somebody else's dead end.

Run the 15-minute exposure audit

Fifteen minutes, one address at a time. Work in this order.

Step 1: Google the address in quotes. Fastest public-surface scan. Note every page that shows it. Remove or edit anything you control; the rest becomes the URL list you need in step 3.

Step 2: Run Have I Been Pwned. Type the address in, read each breach it names: the date, the count, the data classes. Turn on breach notifications while you are there, so the next one finds you instead of the other way round.

Step 3: Set up Results about you and file removals. Register the address on Google's Results about you tool (linked above), review the matches, and request removal for anything that should not be indexed. Keep expectations honest: de-listing is not deletion.

Step 4: Check the people-search sites and opt out. Search the big brokers for your name and city. When you find a profile, use the opt-out flow. Whitepages' suppression requests are representative of the genre: find your profile, submit, confirm by email, wait, then verify the listing is actually gone a month later. Every broker has its own version, and re-listing is common, so this is maintenance, not a one-time fix.

Step 5: Inventory every account tied to the address. The account-linkage walkthrough shows how to list what you signed up for. Anything dormant that you will never use again: delete the account, or at least change its email to something else. If that address has been yours for a decade, this part stings a little. That is the point of the audit.

Source	What to check	What actually works
Breach dumps	Have I Been Pwned search plus notifications	Change reused passwords; nothing removes the address from the dump
Brokers	People-search sites, opt-out pages	Opt out per broker; re-check, listings come back
Scraped pages	Quoted Google search	Remove what you control; Google removal requests for the rest
Mailing lists	Quoted search for list archives	Ask the list admin to redact; removal requests as backup
Your own signups	Account inventory	Delete dormant accounts; stop reusing the address going forward

What the audit cannot undo

A broker file holding your 2016 address is still circulating after you opt out of that broker's website. A Google removal takes the result out of the index, not off the source page. And HIBP's line about absence of evidence applies to the whole audit: a clean scan means nothing found, not nothing out there. The one move that survives all of this is structural. The address you hand out from now on should never be the address you cannot afford to lose. Everything above is triage. The habit is the cure.

Furusato Choice Breach Exposes 4.45 Million Donor Records

Ahsan Luqman — Wed, 21 Oct 2026 00:00:00 +0000

Trustbank confirmed on Tuesday that attackers exfiltrated 4,454,097 Furusato Choice member records, including a deduction figure TV Asahi says can partly reveal each donor's income, and Trustbank's own victim advice describes the exact damage one email per service would have absorbed. I run AliasFleet, an email-alias service: one forwarding address per site, so a leak names its source. A charity signup behaving like a bank statement.

What Trustbank confirmed

The disclosure came on 20 October from Trustbank and its parent Change Holdings, covered by Reuters, Impress Watch, TV Asahi/ANN and Nikkei.

Furusato Choice is Japan's big hometown-tax donation portal. About 1,700 municipalities, more than 760,000 thank-you gifts listed, per Asahi Shimbun. The sequence, from Impress Watch:

17 October: unauthorised third-party access.
19 October: Trustbank spotted the abnormal access, then confirmed the 17 October intrusion and the data exfiltration.
19 October, 15:50 JST: related services suspended to stop further damage. No restart date.
20 October: public disclosure, and a report filed with the Personal Information Protection Commission.
21 October: police victim report scheduled.

Six fields went out, per Impress Watch: names, email addresses, addresses, phone numbers, hashed passwords, and donation-deduction trial-calculation amounts. Trustbank has not said the 4,454,097 is a deduplicated count of people, so member records is the safe term. The company says the count and the contents may change as the investigation continues.

Confirmed	Still open
4,454,097 member records confirmed exfiltrated	Whether the number moves as the investigation continues
Names, emails, addresses, phone numbers in the file	Whether every record held all six fields
Passwords stored hashed, in unreadable form (Nikkei)	The hash algorithm; Trustbank has not named it
Trial deduction amounts per donor	How the attacker got in on 17 October
PPC report filed 20 October; police report due 21 October	Whether the dataset has surfaced publicly or been traded
No card data: the operator processes no payments	Any confirmed secondary misuse; none reported yet

The deduction figure is the unusual part

Most breach files hold contact details and credentials. This one also holds each donor's 寄附控除試算額: the trial calculation of the largest donation that keeps the donor's own payment at 2,000 yen. TV Asahi/ANN reported the figure could let attackers partly work backwards to a member's annual income.

Look at the file from the attacker's side. Names and addresses already sort 4.45 million rows by location. Add a partly recoverable income estimate and the sorting gets a second axis: which households are worth a carefully written forged message, which ones are worth a phone call. A donor list becomes a priority list.

And here is the sharper point. Furusato Choice is not a financial service. It processes no payments and held no card numbers. Donors treated the signup the way people treat charity signups, not bank accounts. The file behaves like a bank statement anyway. That is what separates this breach from the usual names-and-emails spill: income-adjacent data, shipped by a site nobody would call financial.

What members were told to do

Trustbank's guidance to members, per Impress Watch:

If you reused the same email and password combination on other services, change those passwords.
Treat mail, SMS, calls and letters claiming to be Trustbank or its affiliates as suspect. Do not open links or attachments in suspicious mail, and do not enter personal information on suspicious sites.
Send inquiries to the company by email.

The reuse advice is the tell. Passwords were hashed, not plaintext, so the credential risk here rides on passwords reused across sites, paired with the leaked email. If that mechanism is unfamiliar, how credential stuffing works explains it.

The impersonation warning is the second tell. The attacker holds the victim list, the names and the real context. A forged Trustbank notice quoting the breach back at you, asking you to click, confirm or re-enter details, should be treated as hostile until proven otherwise through a channel you typed yourself. How phishing uses your leaked email covers the pattern.

If Furusato Choice held your address, check it on Have I Been Pwned once the incident is listed, and turn on breach notifications. Then change every password you reused with that address, starting with your email account itself.

A real Trustbank notice and a forged one now look identical: same apology, same context, same request to act. The forged version just adds a link. Verify through Trustbank's own site, typed by you. No link in any email about this breach is worth clicking, including the real one.

One email per service contains exactly this

The email addresses in this file are the reusable identity. One email alias per service, a forwarding address used only for Furusato Choice, changes the impersonation math.

Every message landing on that alias is either from Trustbank or from the attacker. No third option. A breach notice on an address nobody but Trustbank ever had, quoting the real apology and asking for a password reset or personal details, has identified itself as the forgery. Kill the alias and the whole channel dies while the real inbox stays clean. That is the leak-tracing mechanism aimed at this exact attack, and the set-up guide takes about two minutes.

One thing the alias does not do: it does not stop the breach, and it does not hide the donor's name or the income-adjacent deduction figure. What it does is narrow the blast radius to the single channel the attacker was given.

What to do if your address was in the file

Change the password on every service where you reused the Furusato Choice combination, starting with your email account. Credential stuffing pairs the leaked address with passwords from other breaches.
Do not click links in any message about this breach. Open Trustbank's site by typing it, or use Furusato Choice's own channel. This applies to the genuine notice too: a habit that catches the forgeries has to catch the real ones.
Expect forged notices that know your name and your donation history. Anyone quoting the breach back at you is proving they have the file, not that they are Trustbank.
Check Have I Been Pwned once the incident is listed and switch on its breach notifications.
Walk the breach-response order of operations. It is written for exactly this situation.
For the next signup, use a unique alias per service, so the next leak names its source.

What the investigation still has to answer

Three things. First, whether the 4,454,097 figure moves as the investigation continues, and whether Trustbank clarifies the per-record field mix. Second, whether the dataset surfaces publicly or gets traded, which turns a confirmed exfiltration into a circulating one. Third, the entry vector: Trustbank says it is investigating with outside experts, but nothing has been said about how the attacker got in on 17 October.

Also watch the inbox angle. Trustbank warned members about forged notices, and its own inquiries run by email. If forged Trustbank messages start landing at scale, they will be the first real-world test of this file's targeting value. The file is out. The advice is out. Now it is a question of how far the file travels.

Use a Separate Alias per Social Platform to Contain Leaks

Ahsan Luqman — Tue, 20 Oct 2026 00:00:00 +0000

One alias per platform. That is the whole answer, and the receipts are three of the largest leaks in history: Facebook gave up 533 million profiles, LinkedIn offered up 700 million, and Twitter spilled the addresses of more than 200 million users.

I run AliasFleet, an email-alias service: one forwarding address per site, so a leak names its source. We already made the general case for a different address on every website. This piece is about why social media deserves its own answer. A social account is not an order history. It is an identity record, and the identity record is the raw material every later attack is built from.

A social account is an identity record, not a shop

A shop leak hands the attacker your purchase history and your shoe size. A social leak hands them the record that ties your real name to your face to your phone number to your employer to everyone you know. Facebook, LinkedIn and Twitter are not databases of customers. They are databases of people.

So the email on a social account plays a different role than the email on a loyalty card. It is the primary key of the record, and in every one of these dumps it is also the join key: the field a buyer of the file uses to stitch your Facebook profile to your LinkedIn profile to the data broker's file on you. Run one address across all of them and you have handed every platform the same join key.

Three leaks, one playbook

April 2021. A file of 533 million Facebook profiles lands on a hacker forum. Facebook says it was scraped through the "contact importer" feature before September 2019, and that no passwords or financial data were in it. Almost every record had a mobile number, a Facebook ID, a name and a gender, according to BleepingComputer's look at the samples. The Irish regulator was not satisfied with the explanation: in November 2022 it fined Meta 265 million euros over the scrape, reporting that the contact importer tools were exploited between May 2018 and September 2019.

Two months later, LinkedIn's turn. 700 million profiles go up for sale in June 2021: over 90% of the platform's roughly 760 million users at the time, with fields ranging from names and emails to phone numbers, physical addresses, geolocation and inferred salaries. LinkedIn insisted this was not a breach at all, because the data was scraped rather than stolen from its systems (Computer Weekly's report). The seller, calling himself Tom Liner, told the BBC the same technique produced the Facebook 533 million dataset, and that he sold the LinkedIn data for around $5,000 (SecurityMagazine). LinkedIn's history makes it worse: 117 million email-and-password combinations from a 2012 breach were sold in 2016, and another 500 million profiles surfaced in a separate scrape in April 2021 (Cloudskope's timeline). Three exposure events in a decade, from one company.

Then Twitter, January 2023: a dataset of email addresses linked to more than 200 million users leaks on a hacker forum. Twitter denied the data came from exploiting its systems, but it had already confirmed a 5.4 million-user leak from an API vulnerability patched in January 2022, and Ireland's regulator had fined it 450,000 euros in 2020 for missing the 72-hour breach notification window (BleepingComputer). Troy Hunt noted that 98% of the email addresses in the Twitter dump were already sitting in Have I Been Pwned. One number, one shape of the problem: your address is not being leaked once. It is being leaked repeatedly.

"Data loss is data loss, and attackers will find the simplest way to obtain the data they need to fund their operations." Tim Mackey, Synopsys, on the LinkedIn scraping, quoted by Computer Weekly.

Every platform reaches for the same word: scraped, not breached. As if that comforts anyone holding the file.

Scraping is the business model

Here is the uncomfortable part. Nobody cracked Facebook's database. The 533 million records came from a feature that helped people find friends by uploading phone numbers, and the contact importer would gladly confirm which of those numbers belonged to a Facebook user. The LinkedIn 700 million came through the platform's own APIs, the same endpoints recruiters and sales tools hit every day. The platforms built machines for answering "who is this" at scale, and the attackers just asked at scale.

Scraping is not a flaw in the plan. It is the plan, used by the wrong people. So the "we fixed the specific issue" statements should not reassure you. Tom Liner's technique ran on LinkedIn for months before anyone noticed, and researchers say scrapers are nearly impossible to tell apart from legitimate API traffic. The next scrape of a major platform is a matter of when, not whether.

What the joined address buys the attacker

The leaked email does not sit in a drawer. It gets stitched to everything else. A Facebook record supplies the name, the face and the friend network. A LinkedIn record supplies the employer and the job title. Merge them on the shared email and the phishing profile writes itself: your name, your workplace, your phone number, delivered to the address you have had for a decade.

Three attacks follow from there. Credential stuffing first: the email is your username almost everywhere, so it goes straight into the stuffing lists. Then targeted phishing that quotes your own details back at you, because the dump has them. Then the exposure of anonymous accounts: PCWorld pointed out that the Twitter leak could unmask people who had been using the site anonymously, because their private email addresses were now tied to their handles.

Once you run per-platform aliases, a "security alert" that does not arrive on that platform's alias is fake by definition. A phish pretending to be Facebook that lands on any address other than your Facebook alias has outsourced its own detection. This is the mechanism from our leak-tracing piece, aimed at the phishing half of the problem.

The kill switch, in practice

The setup is simple: one email alias for Facebook, one for LinkedIn, one for X, one for every platform you use. Each forwards to the inbox you already open. No platform ever sees your real address, and no two platforms see the same address.

Now picture the morning after the next dump drops. You open your inbox and the phish and the spam are arriving on the Twitter alias. Nothing else in your life has ever used that address. No investigation needed, no guessing which breach it came from: the address names the source by itself. You pause the alias and the whole channel dies. Your real inbox never flinched.

Walk it through and the containment is airtight. The address in the dump belongs to Twitter and nothing else, so it cannot be joined to your LinkedIn record, because LinkedIn holds a different address. It cannot be stuffed into your bank's login page, because your bank never saw it. That is the mechanism the general piece covers in full, aimed at the accounts holding the richest identity data you own.

Where the alias stops helping

Four limits, stated plainly. A unique address per platform does nothing for a reused password. If your password is identical on Facebook and LinkedIn, the attacker does not need to chain anything. Pair the aliases with a password manager, or you have built half a system.

It does not un-leak the address you already handed out. The real address you used on Facebook for ten years is in the 2021 file, and nothing you do now pulls it back. Aliases stop the list growing. They do not shrink it.

Some platforms may reject alias addresses at signup. I have not verified every social platform's acceptance policy, so test each signup instead of assuming it works. One platform that needs the plain address does not cancel the protection on the rest.

And it does not encrypt your mail or hide the path it travelled. It changes the address a sender holds. Nothing else. For what aliases cannot do in general, the second-email piece argues a second inbox is the wrong tool and aliases are the right one.

Start with the next signup

Do not try to migrate everything today. That is not the work that matters: the old address is already out there, and retrofitting a decade of signups will not change that. The work that matters is the next signup.

Pick the next platform account you create, or the next one you touch for any reason, and hand it a fresh alias instead of your real address. The setup guide takes about two minutes. Send a test, watch it land, move on. Then run the HIBP check and walk the breach-response order of operations for whatever it finds.

The platforms will not stop being scraped. The only variable you control is what the scrape gets. Make it an address that belongs to that platform alone, with a switch you can flip.

Check Any Email for Phishing in 60 Seconds With Three Checks

Ahsan Luqman — Tue, 20 Oct 2026 00:00:00 +0000

Your bank emails you, but the message lands on the alias you gave only to a bookshop. Delete it. The bank never had that address, so the claim dies before you read a word. I run AliasFleet, an email-alias service that gives every site its own forwarding address, and that one comparison is the fastest phishing test there is: hold the sender's claim against the address it arrived on. The attacker controls the message. He never controlled the address. When the two don't match, you're done.

For everything that passes that test, or for anyone not on aliases yet, run the drill below. Sender domain first. Link destinations second. The ask last. The order is the point: the cheap mechanical checks come first, the judgment call comes last. Verizon's research, quoted by CNIC Solutions, puts the median click on a malicious link at 21 seconds, with 28 more seconds to enter data. The attack finishes inside a minute. The check fits inside the same minute.

Check one: the sender domain, read character by character

The name at the top is typed text. Anyone can write "Your Bank" as the display name; the mail system just carries it. What counts is the domain after the @. Tap or click the sender name to expose the real address, then read that domain letter by letter. Slowly. This is the whole check.

The fakes recycle a small set of tricks. Attackers are not creative here; they're just patient. A public mailbox doing company business: your "bank" writing from a @gmail.com address. A lookalike domain: CISA's own example is amazan.com; the working constructions run to letter-for-number swaps like paypa1.com or micros0ft-teams.net. And the brand name buried inside a longer address, billing@security-microsoft-update.com, where the real domain is security-microsoft-update.com and the word "microsoft" in the middle is decoration.

Then glance at Reply-To. It decides where your answer goes, and it can point somewhere the sender never mentioned. A convincing From address with replies routed elsewhere has identified itself; GingerSec's walkthrough flags the mismatch as a standalone tell.

The From header has a deeper story than a guide like this has room for. It is a claim, not a verified fact, and the authentication protocols behind it each check something narrower than most people assume. That mechanism is covered separately. For the 60-second drill, the summary holds: read the domain, not the name.

The alias test: compare the claim against the address

With one alias per site, the To line answers before you start thinking. A message claiming to be your bank, sitting on the alias you handed only to a bookshop, is forged on arrival. The bookshop is the only holder of that address. The bank never had it. There is no content analysis to do.

This isn't an AliasFleet invention. Apple's own guidance lists it as a phishing sign in plain terms: the email or phone used to contact you is different from the one you gave that company. The per-site habit just turns that advice into machinery. The address itself is the record of who was supposed to hold it, and it checks itself every time.

Two limits keep this honest. An alias cannot vouch for the sender: a forgery can still reach the correct alias if the attacker already knows it. And it only works going forward. The address map starts the day you begin; the personal address you've used for a decade sits in hundreds of databases, and no new habit retroactively sorts it. For the mechanics of addresses and leak tracing, see which website leaked my email and what an email alias is.

Check two: where every link actually points

The visible words on a link mean nothing. Blue underlined text can say your bank's name and point anywhere. The destination is the truth, and you can read it before clicking. On a computer, hover and read the address that appears. On a phone, press and hold to preview it, then cancel. Nesswick's guide documents the move for desktop and mobile; it takes two seconds and attackers hate it.

Read the destination's domain the way you read the sender: slowly. In secure-login.example-alerts.net/yourbank, the site is example-alerts.net, and "yourbank" after the slash is scenery. A link can look right while the URL doesn't match the company's site, which is the whole of the check.

Shortened links and QR codes hide where they go by design. That isn't proof of a forgery, but it's a reason to reach the company another way: the NCSC warns that criminals increasingly hide QR codes in phishing emails to get phones onto scam sites, where the address bar is harder to inspect.

One rule from Google closes this section: never enter a password after clicking a link in a message. If a click lands you on a login page, close it and type the address yourself. A padlock or HTTPS badge doesn't make a page trustworthy either. Certificates are free; anyone can get one for a fake domain.

Check three: what the message asks you to do

Every phishing email tells a story to get you to act. The FTC's guide lists the standards: suspicious activity on your account, a problem with your payment details, an invoice you don't recognise, a government refund, a prize you never entered. Hold the ask against one fact: legitimate companies do not email you a link to update your payment information. That sentence is nearly verbatim from the FTC, and on its own it kills most forgeries.

Pressure is the second tell. Urgency, suspension threats, a countdown clock: the message is trying to close the gap between reading and clicking before you think. A real organisation that needs something will let you walk in through the front door on your own schedule.

Two old tells are retired. Generic greetings like "Dear customer" prove little, since plenty of legitimate bulk mail is impersonal too. And bad spelling is dead as a signal: CISA says plainly that AI tools now write perfect grammar, so a well-written email proves nothing. Judge the sender, the links, and the request. Never the prose.

Picture the careful version of the mistake. You don't click the link in the "bank" email because you know better. Instead you call the number printed at the bottom of the message to check. A polite voice answers, asks you to confirm your card number and the code from your texts, and thanks you. You have just handed everything to the same attacker, because the number, the link, and the reply address were all his. That is why the rule underneath the other three checks is absolute.

When the three checks are not enough

A clean domain, clean links, and a plausible ask can still be a forgery, and the commonest case is the real template in the wrong hands. Post-breach phishing copies the genuine notice word for word, so content checks stop working and only the channel decides. That case is covered separately. For one suspicious message, two escalation paths remain.

The deeper evidence lives in the headers: the Received chain and the authentication verdicts. The header guide walks through opening them in Gmail and Outlook and reading them in about a minute. If the headers still leave doubt, treat the doubt as the answer and use the independent channel anyway.

Then report it. In Gmail, open the message, click More next to Reply, and choose Report phishing; Google feeds it into its filters. The FTC asks that phishing mail be forwarded to reportphishing@apwg.org and reported at ReportFraud.ftc.gov. In the UK, the NCSC asks people to forward suspicious mail to its dedicated reporting address. Reporting takes under a minute and sharpens the filters for everyone behind you.

If you already clicked: close the page and enter nothing more. If you entered a password, change it on the real site, and everywhere else you reused it, through the official app or an address you type yourself, never the link. Switch on two-factor authentication. If you shared payment details, call your card issuer on the number printed on the card. Then run the address through Have I Been Pwned and watch the accounts for a few weeks.

What this check cannot catch

Three gaps stay open, and saying so is part of the deal. A forgery can land on the correct alias if the attacker already holds that address; the alias names the source, it doesn't vouch for the sender. A message from a compromised real account passes every reader-side check, because the sender is genuine even though the content isn't. And no 60-second routine replaces the independent channel: when the message matters, open the app or type the address yourself, which is the same rule the University of Reading's phishing checklist ends on. The check above catches the common case. The channel habit catches the rest.

If you want the habit that makes the alias test automatic, the set-up guide takes about two minutes per method. One alias per site, and the To line starts running check one before you do.

Is Outlook Safe? Strong Security, Weak Privacy, Harden It

Ahsan Luqman — Tue, 20 Oct 2026 00:00:00 +0000

Is Outlook safe? The security is strong; the privacy is not. Microsoft guards the account well: passkeys, two-step verification, unusual sign-in alerts. Your mail sits on Microsoft's servers in readable form, one address reused everywhere is the real risk, and account recovery is the weak link.

That is the split this article runs with. Is Gmail safe did the same job for Google's inbox, from scratch. The verdict rhymes: strong security, weak privacy. The Microsoft details differ in ways that matter.

The account protection is the strong half

Start where Microsoft earns it: passkeys, which reached consumer accounts in May 2024, let you sign in with your face, a fingerprint, a PIN or a security key. No secret to phish. Microsoft's security blog says it blocks 7,000 password attacks per second, and that adversary-in-the-middle phishing rose 146% year over year, which is the entire reason passkeys exist. A passkey sign-in runs about three times faster than a password and lands 98% of the time against 32% for passwords, per Microsoft's numbers. Since 2022 you can drop the account password entirely.

Two-step verification is the move most people should actually make. Microsoft's guide walks through it: Security tab at account.microsoft.com/security, Manage how I sign in, Additional security, Two-step verification. Two details on that page matter. Microsoft strongly recommends three pieces of security info, not one, because losing your only verification method can cost you the account. And Microsoft is phasing out SMS as an authentication and recovery method for personal accounts. Overdue: SIM swapping made SMS the weakest second factor years ago.

The cheapest habit in this article is reading the unusual sign-in alerts, because a sign-in from a new location or device triggers an email and an SMS, and the real alerts come from one address: account-security-noreply@accountprotection.microsoft.com. Microsoft's unusual sign-in page says to open Recent activity yourself and mark anything you do not recognise. Two minutes. Costs nothing.

Outlook.com, the Outlook app, and your work mailbox are three different questions

"Outlook" names three different things, and the safety answer changes with each. Outlook.com is the free consumer mailbox, the subject of this article. The Outlook apps are clients: they read whatever mailbox you connect, and their safety is the safety of the account behind them.

The work mailbox is the one that catches people out. If your address runs on your employer's Microsoft 365, an admin can reset your password from the admin centre. The walkthrough is public: Users, Active users, Reset password. That is normal IT practice, not a scandal. It also means your work inbox was never private from your employer. Questions about a work mailbox are questions about your IT department, not about Microsoft.

Storm-0558 tested the secure claim

Microsoft's security record took a real hit in 2023, and people have not forgotten it. Microsoft's write-up of the Storm-0558 incident says that from May 15, 2023, a China-based actor forged authentication tokens with a stolen Microsoft consumer signing key and read mail from roughly 25 organisations, government agencies among them, plus a small number of related consumer accounts. Microsoft says mitigation is complete for all customers.

Confirmed	Not confirmed for your mailbox
The window: access began May 15, 2023	Whether your account was among the consumer accounts touched
The method: forged tokens, not stolen passwords. Two-step verification would not have stopped it	Exactly how the signing key was acquired; Microsoft's crash-dump theory was later walked back
The scope: about 25 organisations plus related consumer accounts	Nothing points to a broad consumer Outlook.com compromise beyond that

One more incident, one paragraph, because the two get mixed up. In January 2024 Microsoft disclosed that Midnight Blizzard, the Russian actor behind SolarWinds, password-sprayed a legacy non-production test tenant and reached a small slice of Microsoft's own corporate mail: senior leadership, cybersecurity, legal, per Dark Reading's report. That was the vendor's corporate mail, not your Outlook.com inbox. Storm-0558 touched customer mail; Midnight Blizzard only embarrassed the vendor. Keep the two apart.

The lesson: a mailbox's threat model is nation-state actors plus your own recovery settings, and Microsoft's own history says the first half is real.

Privacy is the half Outlook loses

This is where the split lands. On the one privacy question people actually ask, Outlook.com has held the line for a decade: it does not scan your mail to target ads. In 2014 the UK advertising watchdog cleared a Microsoft radio ad claiming exactly that, while noting that scanning for viruses and spam is standard practice everywhere. The ASA decision is old, but Microsoft has never reversed the stance.

Everything else is standard inbox economics. A free Outlook.com mailbox gets opportunistic TLS. Microsoft's support page states the limit in one sentence:

TLS encrypts the connection, not the message.

Read that twice. Every server along the way holds a readable copy. Real message encryption, the Encrypt and Do Not Forward buttons in the compose ribbon, ships only with a paid Microsoft 365 Personal or Family subscription. Microsoft's encryption page states both the paywall and the TLS default plainly.

So the privacy verdict runs like this: no ad scanning, ordinary transport encryption, real encryption behind a paywall, and your mail sits on Microsoft's servers, scanned for spam and viruses like everyone else's. If your requirement is that no company holds your correspondence, Outlook.com fails it. If your requirement is that your mail is not mined for ads, it passes.

Microsoft's own aliases are capped by design

Microsoft does offer aliases: extra addresses that work with the same Microsoft account. The support page explains the mechanism. But the limits live in Microsoft's own support answers, not the official spec: 10 active aliases per account, 10 created per rolling 12 months, 2 per rolling 7-day period, per the community answers. Remove an @outlook.com alias and you cannot get it back.

Ten aliases is a few identities, not a strategy. Ten sites, ten aliases, done for the year. And every alias is also a sign-in name for the same account: a leaked alias tells an attacker exactly which account to attack. That is the design, and it is why Microsoft's aliases cannot do the job.

A dedicated email alias per site runs the other way: it forwards to your inbox but never signs into anything, so killing it ends the channel while the account stays untouched. Setting one up takes minutes, and the risks deserve a straight read. Plus addressing is not the same thing: Gmail's plus-addressing limits show why the tag trick does not hold up.

Keep the real Outlook address for people you know, your bank, and the handful of accounts where that address is your identity. Everything else gets a forwarding identity of its own.

Recovery is the weak link, and Microsoft admits it

Now the half of the security story that cuts the other way. Lose access to a Microsoft account and the account recovery form is fully automated. You answer questions about your contacts, exact email subject lines, old passwords, even your Xbox console's hardware ID, and Microsoft responds within 24 hours. Two attempts per day, and wrong answers do not count against you. The page states the limit plainly: support agents cannot send password reset links, and they cannot touch your account details.

If two-step verification is on and you cannot reach any of your verification methods, Microsoft's own support page says it cannot help you, sorry. The recovery form is automated and the agents cannot bypass it. That is strong security doing its job against the owner too, which is why three pieces of security info and a saved recovery code are not optional.

Change your security info and a 30-day wait can apply before the new info works. Deliberate: a hijacker cannot swap the recovery details and walk straight in. The direction is clear. Microsoft is pushing everyone toward authenticator apps and passkeys, and the recovery path for everyone else is slow on purpose. Set the account up as if you will need to recover it one day, because the recovery process assumes you planned ahead.

Five moves that harden a Microsoft account

Do these once, in order.

Add a passkey. Security settings, add a sign-in method, then your face, fingerprint, PIN or security key. Nothing to type, nothing to phish.
Turn on two-step verification with an authenticator app, and keep SMS out of it. Microsoft is phasing it out anyway.
Register three pieces of security info: the authenticator app, a backup email on a different provider, a phone number. Microsoft recommends three for the day one method fails.
Save the recovery code somewhere offline. It is the one fallback the automated form cannot replace.
Act on the unusual sign-in alerts. Open Recent activity, expand the entry, mark what was not you, change the password. The alerts only work if you do.

What Outlook cannot fix

The hardened account still has the hole every hardened inbox has. Microsoft guards the mailbox. Nothing guards the address. Every site holding your Outlook address holds a copy of the key to your inbox, and one breach later your address sits in a file next to your name. Attackers run two familiar plays: credential stuffing, which tries the leaked password and its near cousins against your Microsoft account, and phishing, which sends mail that knows your name and your service and links to a forged sign-in page. Two-step verification stops the first play cold. It does nothing against a phish that gets you to approve the sign-in yourself.

Check whether the address already circulates at Have I Been Pwned. A hit there is not a failure of Outlook's security. It is the price of one address everywhere, and the phishing playbook built on leaked email shows what attackers do with it next. If you want to know which site lost it, leak tracing through aliases answers that question by construction, and the breach-response order of operations covers the rest. For the question of whether an email address is safe to hand out in the first place, this piece on giving your email to websites makes the longer case.

Outlook is safe in the sense the question usually means. The account protection is genuinely strong, stronger than most people use, and it is not private in the sense people fear: ordinary transport encryption, real encryption paywalled, mail held by Microsoft. Harden the account with the five moves and stop handing out the raw address. That is the whole answer.

A Hacked Email Means Two Jobs: Get Back In, Then Evict Them

Ahsan Luqman — Tue, 20 Oct 2026 00:00:00 +0000

You are locked out of your own inbox and someone else is in it. That is a sick feeling, and I am not going to tell you to calm down. A hacked inbox does not mean a hacked identity everywhere: kill the compromised alias and the leak stops spreading. I run AliasFleet, an email-alias service, and I will tell you this instead: recovering a hacked inbox is two jobs, not one. Job one is getting back in. Job two is evicting the intruder. Most guides walk you through the first and stop, and that is exactly where recoveries quietly fail.

The intruder had whatever got them through the door: your password, your recovery phone, a keylogger on your machine. A new password locks the front door again. It does nothing about the side doors they built while they were inside: their sessions, their forwarding rules, their recovery email, their app access. Those footholds are built to survive a password change, and they do. So work the two jobs in this order, and finish both.

Before you start, one piece of the machinery. An email alias is a separate forwarding address per site, all landing in your one inbox. One address reused everywhere is why a hacked inbox feels like a hacked life. One address per site shrinks the blast radius to that site alone. Hold that thought. It is the final step, once the intruder is out.

One scope note: this guide covers Gmail and Outlook (Microsoft 365), the two most common inboxes, and not Yahoo, AOL or Apple Mail, whose recovery paths I have not walked through here.

Job one: get back into the inbox

Do the first job from a device you trust, not the one you were using when things went wrong. Microsoft's recovery page tells you to run a full antivirus scan before you change the password, and the order is the whole point. On a machine with a keylogger, the new password belongs to the attacker the moment you type it. If you do not have a clean device, borrow one, and park the suspect machine until it is cleaned.

Microsoft's official order is malware scan first, password change second, because an infected machine reads the replacement password the moment you type it. No clean device at hand? Run the entire recovery on a different one and treat the suspect machine as out of service until it is cleaned.

Gmail: the recovery form, on ground it recognises

If the attacker changed your password, your recovery phone or deleted the account, Google's account recovery page is the official route, and Google's hacked-account guide starts there. Two things move the odds in your favour. Do it from a device you have signed in on before, on the network you normally use. Google's recovery checks lean hard on recognised devices and locations, and one independent recovery guide reports that rapid failed attempts make the model stricter, so space your attempts out instead of hammering the form. Still signed in on one device? That session is your control point. Run the whole lockdown from there; that is how hacked.com frames it: take the ground you hold, then clean the rest.

Outlook and Microsoft accounts: the form is the only door

Microsoft's route is the sign-in helper first, then the account recovery form if the normal reset will not let you in. Microsoft's help page for the form is blunt about two things. Fill it in from a device you have used before, somewhere Microsoft will recognise, like home or work. And if it rejects you, keep going, up to twice a day; wrong guesses do not count against you, and Microsoft reviews each submission within 24 hours. Nobody at support can bypass the identity checks or send you a reset link. The form is the only door in.

Work address on Google Workspace? Skip the personal flow and call your domain admin. Admins hold tools the self-service route does not.

Job two: throw the intruder out

Back inside does not mean they left. Anyone who held your inbox for a while tried to build a way back in. These footholds are built to survive a password change, so work them in this order.

1. Kill their sessions

Open the account security page and sign out of everything you do not recognise. On Google that is the Your devices section; on a Microsoft account it is recent activity and devices. If anything looks wrong at all, do not pick through the list: sign out everywhere and sign back in only from the device you trust. Changing your Google password already signs out most other sessions, which starts invalidating stolen session cookies (this phishing playbook documents the mechanics), but verify it yourself. Never assume.

2. Take back the recovery methods

Check the recovery email and recovery phone in the settings and make sure both are yours. This is the quietest back door after a takeover: an attacker who added their own recovery address can walk back through "forgot password" next week and lock you out the week after. Remove anything you did not add, and add a second recovery method of your own if the provider allows it. Our piece on whether changing your password stops hackers walks the full list of doors a new password misses. Recovery takeover is the one nobody notices.

3. Hunt for what they planted inside the mailbox

Most guides skip this step. Do not. The intruder's persistence lives in mail settings, not in the password, so it survives the password change. Work the panels in full, on a computer; the mobile apps hide some of the settings.

Open Settings, then See all settings, and check three tabs. Under Forwarding and POP/IMAP, remove any forwarding address you did not add. Attackers set silent auto-forwarding to siphon a copy of every message, and stripping it is exactly what Google's hacked-account guide tells you to do. Under Filters and Blocked Addresses, delete every filter you did not create, and read hardest the ones matching "security", "password" or your bank's name: that is how attackers hide Google's own alerts so you never see the warning. Under Accounts and Import, check the send-as addresses and the delegation list for anyone else able to send or read your mail, then remove them.

Open Outlook on the web, then Settings, then Mail (labels can shift with UI updates). Under Rules, delete anything you did not create, especially rules that forward or redirect mail to an unfamiliar address. Under Forwarding, make sure no external address is listed. If a rule keeps reappearing after you delete it, the attacker still has access or the rule sits at admin level, and you need to re-run the full account lockdown. Also check the blocked senders list, since attackers sometimes block addresses to make legitimate mail vanish, a pattern this Microsoft community thread documents.

4. Revoke their app access

Two things with confusingly similar names, and the attacker can use either. App passwords are credentials you generated so older apps could sign in; each one bypasses two-factor, so review the list and delete every one you do not actively use. Third-party connections (OAuth) are apps you granted permission to read your mail, calendar or files; remove anything you do not recognise or no longer use. Revoking stops the app reading your account from that moment. It does not delete data it already took. On the Microsoft side, check whether the attacker was sending through SMTP or a connected app rather than the web interface, because that traffic skips the Sent folder entirely. An account can look quiet and still be working.

5. Regenerate what they might have copied

If you use two-factor backup codes, generate a fresh set now. The new set kills the old one, so any codes the attacker saw turn to dust. Give the authenticator app entries tied to the account the same review. Then switch two-factor on if it was off before, and take the strongest method on offer: a passkey or security key beats an authenticator app, which beats a texted code. If the account holds anything high-value, Google's Advanced Protection Program is free and demands a passkey or security key at sign-in, which keeps an attacker out even with your password in hand.

Take back the address they know

When job two is done, the inbox is yours and the intruder is out. The remaining problem is that the address they now know is still the address every site on earth holds for you, and the next attack starts from that list.

This is where per-site aliases change the shape of the damage. When the address the attacker harvested belongs to exactly one site, killing that alias kills the channel: their mail bounces, your real address and every other alias keep working. The setup takes about two minutes per method, and the one-alias-per-site habit turns the next incident from a crisis into a ten-second pause.

Stated plainly: aliases do not evict someone from an inbox they already control. That was jobs one and two, which you just did. Aliases do the job after eviction, which is making the address the intruder walked away with worth nothing. A hacked inbox does not have to mean a hacked identity everywhere.

Lock the rest of your life out of it too

Your inbox is the reset path for everything else, so the job is not finished at the inbox. Change every password the inbox password shared, starting with the accounts that lean on this inbox for resets: banking, your other email accounts, social, shopping. Have I Been Pwned tells you whether the address already circulates in known breaches, and our walkthrough of reading its result shows how to work each breach it names.

Two things left, then you are done. Warn your contacts that the account was compromised and to ignore the phishing it may have sent; inbox takeovers are routinely followed by scam mail to the contact list. And run our full audit of every account linked to the email, because the forgotten forum account with the same password is the intruder's next try. When the whole pass is finished, our hardening guide keeps the account in that state, and the pricing page covers the free tier if you want the alias habit: 10 active aliases, enough for the accounts that matter most.