Article Summary: If your business is hit by a cyberattack, the first hour matters. Disconnect the affected devices from the network instead of powering them off, call your IT provider by phone, and leave the evidence in place. If money was wired to a scammer, call your bank right away. This post is the step-by-step plan, plus where to report an attack in the US, UK, and Australia.
If a cyberattack hits your business, what you do in the first hour really matters.
It’s also the easiest time to make a costly mistake, like turning off the wrong machine, deleting evidence, or replying from an email account the attacker is already reading.
The steps below tell you what to do, in order, so you’re not guessing in the moment.
Doing these steps doesn’t require technical knowledge.
Before anything else: don’t make it worse
Before you touch anything, avoid these:
Don’t turn the affected computer off, if you can avoid it. Disconnecting it from the network is better, because powering it down can wipe evidence that helps work out what happened.
Don’t delete anything. Leave the ransom note, the suspicious email, and any alerts exactly where they are. They’re what your IT team and investigators will need.
Don’t pay a ransom on the spot.
Don’t use the hacked email or accounts to talk about the attack. If an attacker is in your inbox, they can read those messages. Switch to phone calls or a different account.
The step by step
Work through these in order, starting the moment you notice something’s wrong.
Disconnect the affected devices from the network. Unplug the network cable and turn off Wi-Fi on anything that looks affected. This stops the problem spreading to other computers and to your backups. CISA’s guidance is to isolate devices rather than power them off where you can, and to shut a device down only if you can’t get it off the network any other way.
Call your IT provider straight away, by phone. Don’t email, in case the attacker is watching your inbox. If you have cyber insurance, call them next, because many policies require you to involve their incident team early.
Leave the evidence alone. Don’t wipe, reinstall, or tidy up the affected machines yet. Screenshots of the ransom note or suspicious emails are useful, but keep the originals too.
If money was sent, call your bank immediately. Ask them to recall the transfer and freeze it if they can. With wire and bank fraud, acting in the first few hours makes the biggest difference.
Reset passwords from a clean device, and turn on multi-factor authentication. Start with email and any admin accounts, and use a device you know isn’t affected.
Report it. That can help you recover, and it’s sometimes legally required. Where to report depends on your country.
Where to report it
You’ve reaWhere you report depends on where you are:
United Kingdom: report through the NCSC, and to Action Fraud.
Australia: report through ReportCyber, or call the 24/7 hotline on 1300 CYBER1.
If money was wired to a scammer, report it fast.
The FBI says reporting wire fraud to IC3 within 72 hours gives its Recovery Asset Team the best chance of clawing it back, and that team recovers funds in about 70% of the cases reported in time.
If personal data about your customers or staff was exposed, you may be legally required to notify a regulator and the people affected, sometimes within 72 hours.
The rules depend on where you operate, like GDPR in the UK and Europe, state breach-notification laws in the US, and the Notifiable Data Breaches scheme in Australia.
Ask your lawyer or IT provider early so you don’t miss a deadline.
Should you pay the ransom?
If it’s ransomware, the big question is whether to pay.
The FBI does not recommend it. Paying doesn’t guarantee you get your files back, it marks you as a business that pays, and the money funds more attacks.
It’s ultimately your decision, but it’s one to make with law enforcement, your IT or incident-response team, and your insurer, not alone in the first panicked hour.
Sometimes a free decryption tool already exists for the exact ransomware that hit you, which is one more reason to get the experts involved before you pay anyone.
The best time to prepare is before it happens
All of this is far easier if you’ve decided some of it in advance. You don’t need a thick binder, just a simple plan that covers:
Who to call first (your IT provider, your insurer) and their numbers, kept somewhere you can reach without your main systems.
Where your backups are, and proof they’ve been tested by restoring from them.
Which accounts and devices matter most, so you know what to protect first.
A single page covering those is enough for most small businesses, and it’ll save you a lot of scrambling if the day ever comes.
Frequently Asked Questions
What’s the first thing to do in a cyberattack?
Disconnect the affected devices from the network, by unplugging the network cable and turning off Wi-Fi, then call your IT provider by phone. Getting the device off the network stops the problem spreading while you get help.
Should I turn off the computer if I get ransomware?
If you can, disconnect it from the network instead of powering it off. Shutting it down can wipe evidence stored in memory that helps work out what happened. Only power a device off if you can’t get it off the network any other way.
Should I pay the ransom?
The FBI does not recommend it. Paying doesn’t guarantee you get your data back, and it funds more attacks. Make that decision with law enforcement, your IT or incident-response team, and your insurer, and check whether a free decryption tool already exists first.
We wired money to a scammer. What do we do?
Call your bank immediately and ask them to recall the transfer. If you’re in the US, report it to the FBI’s IC3 within 72 hours, because reported quickly, their Recovery Asset Team recovers the money in about 70% of cases. In other countries, contact your bank and your national reporting service straight away.
Who do I report a cyberattack to?
In the US, the FBI’s IC3 and CISA. In the UK, the NCSC and Action Fraud. In Australia, ReportCyber. Also tell your cyber insurer, and check whether you have a legal duty to notify a regulator if personal data was exposed.
Article Summary: A passkey lets you sign in to an app or website using the same fingerprint, face, or PIN you use to unlock your phone or laptop, with no password to type. It’s built on a security standard called FIDO that can’t be phished, because the passkey only works on the real site and there’s no password to steal or reuse. Most major platforms and a growing list of business tools support passkeys, and Microsoft 365 includes them at no extra cost. For most businesses, it’s worth starting to roll them out, beginning with the most sensitive accounts.
Passwords are the weak point in most businesses.
People reuse them across accounts, write them on sticky notes, and type them into convincing fake login pages without realizing it.
Passkeys are the technology built to replace passwords, and they fix the parts that cause the most trouble.
A passkey lets you sign in with the same fingerprint, face scan, or PIN you already use to unlock your phone or laptop. There’s no password to type, so there’s nothing for an attacker to steal, guess, or trick out of you.
Let’s look at what passkeys are, why they’re so much harder to attack than passwords, and whether your business should start using them.
What is a passkey?
A passkey replaces your password with your device’s own security.
Instead of typing a password, you prove it’s you the same way you unlock your phone: a fingerprint, a face scan, or a PIN.
When you set up a passkey for a website, your device creates two matching keys.
The private key stays locked on your device and never leaves it.
The public key is stored by the website.
When you sign in, the site sends a challenge that only your private key can answer, your device answers it once you confirm with your fingerprint or PIN, and you’re in. The website never sees a password, because there isn’t one. This approach comes from a standard called FIDO, which Apple, Google, and Microsoft all build on.
Why passkeys are harder to attack than passwords
A password is a secret you share with the website every time you log in, and that’s exactly what attackers go after.
A passkey has no shared secret. That one difference fixes the biggest problems with passwords.
They can’t be phished. A passkey only works on the real website it was created for. Land on a convincing fake, and the passkey simply won’t work, so there’s nothing to hand over. That matters, because phishing is how most break-ins start.
There’s no password to steal in a breach. The website only keeps your public key, which is useless on its own. If the company gets hacked, there’s no password list to grab and try on your other accounts.
Nothing to reuse or forget. Each passkey is unique to one site and made automatically, so reused and weak passwords stop being a problem.
Older methods like text-message codes and app approval prompts can still be tricked out of people.
Where you can use passkeys already
Support has spread fast.
You can already sign in with passkeys to Microsoft, Google, and Apple accounts, plus a growing list of banks, password managers, and business tools.
Apple, Google, and Microsoft have built passkeys into their phones, laptops, and browsers, so the device in your pocket can already store and use them.
There are two types worth knowing.
A synced passkey is backed up to your Apple, Google, or Microsoft account, so it works across all your devices and you’re covered if you lose one.
A device-bound passkey stays on a single device, like a physical security key you plug in, which is the most locked-down option and a common pick for sensitive accounts.
Should your business use them?
For most businesses, yes, and you can start small. There’s no need to switch everything overnight or drop passwords on day one.
If you use Microsoft 365, passkeys are already available through Microsoft Entra.
Staff can sign in with a passkey stored in the Microsoft Authenticator app, a security key, or their own device. Google Workspace supports them too.
They’re also just faster. Microsoft says signing in with a synced passkey takes about 3 seconds, against roughly 69 seconds for a password plus a traditional MFA code. Across a whole team, that adds up.
Here’s how you can start using passkeys:
Turn passkeys on for your most sensitive accounts first: administrators, finance, and anyone who can move money or change systems.
Let everyone else add a passkey as a faster, safer way to sign in, alongside their normal login at first.
Make sure each person has a backup, like a second device or a security key, so a lost phone doesn’t lock anyone out.
Your IT provider can switch this on and run the rollout so nobody gets locked out along the way.
What to watch out for
Passkeys aren’t magic, and a few things are worth planning for.
Account recovery. If someone loses the only device with their passkey and has no backup, they can get locked out. A synced passkey or a second registered device fixes this, but you have to set it up ahead of time.
Not everything supports them yet. Support is growing fast, but some older systems and smaller vendors still rely on passwords, so you’ll run both side by side for a while.
Shared devices and logins. Passkeys are tied to a person and their device, so any shared computers or shared accounts need their own plan.
Frequently Asked Questions
What is a passkey in simple terms?
It’s a way to log in using your fingerprint, face, or PIN instead of a password. Your device proves it’s you to the website, and no password is ever typed or stored.
Are passkeys safer than passwords?
Yes. They can’t be phished, there’s no password for a hacker to steal in a data breach, and there’s nothing to reuse or forget. Security agencies like CISA recommend FIDO-based logins, which is what passkeys are, as the strongest widely available option.
What happens if I lose the device with my passkey?
If it was a synced passkey, it’s backed up to your Apple, Google, or Microsoft account and still available on your other devices. If it was device-bound and you have no backup, you’d use a recovery method to get back in, which is why setting up a second passkey or device in advance matters.
Does Microsoft 365 support passkeys?
Yes. Passkeys are available through Microsoft Entra at no extra cost, including the free tier. Staff can use a passkey in the Microsoft Authenticator app, a security key, or their device.
Do passkeys replace multi-factor authentication?
A passkey can count as multi-factor authentication on its own. Unlocking it needs both your device (something you have) and your fingerprint, face, or PIN (something you are or know), so it covers two factors in one step and can replace the old password-plus-text-code routine.
Article Summary: Email spoofing is when a scammer sends a message that appears to come from your domain, often to trick your clients or staff into paying a fake invoice or changing banking details. Three DNS records (SPF, DKIM, and DMARC) prove that a message really came from you and tell receiving mail servers to reject the ones that didn’t. The catch is that DMARC only protects you once it’s set to “quarantine” or “reject,” and a lot of businesses leave it on “none,” which monitors but does not block.
Right now, with no special tools, someone could send an email that looks like it came from your company.
The From line would show your domain, your logo could be pasted into the message, and it could ask one of your clients to pay an invoice or update banking details. This is called email spoofing, and it is one of the most common ways fraud against your clients and suppliers begins.
There are three settings you can add to your domain that make this much harder to pull off.
They’re called SPF, DKIM, and DMARC.
Most businesses have one or two of them set up and the third missing.
That’s usually all it takes to let a spoofed email through. This post explains what each one does, the setting most businesses get wrong, and how to check your own domain.
Why scammers can send email in your company’s name
Email was built in a more trusting time.
The system that delivers mail does not, on its own, check that the sender is who they claim to be. The From address on an email is about as trustworthy as the return address handwritten on an envelope. Anyone can write anything there, and the mail still gets delivered.
Spoofing takes advantage of that.
A scammer puts your domain in the From field, sends the message, and unless your domain is set up to prevent it, the receiving mail server has no reason to question it. The message lands in your client’s inbox looking like it came from you. The UK’s National Cyber Security Centre publishes anti-spoofing guidance for exactly this reason.
The three records that stop email spoofing
Three DNS records work together to prove an email really came from your domain. You add them once, at your domain registrar or DNS host, and receiving mail servers check them on every message you send.
SPF (Sender Policy Framework)<
SPF is a list of the mail servers allowed to send email for your domain, published as a DNS record. When a receiving server gets a message claiming to be from you, it checks whether the sending server is on that list. If a server that isn’t on the list tries to send as your domain, SPF flags it.
DKIM (DomainKeys Identified Mail)
DKIM adds a tamper-proof signature to every message you send. Your mail server signs outgoing email with a private key, and the matching public key sits in your DNS. The receiving server checks the signature to confirm two things: the message really came from your domain, and nobody altered it along the way.
DMARC (Domain-based Message Authentication, Reporting and Conformance)
DMARC ties the other two together and tells receiving servers what to do when a message fails the check. It also confirms that the domain in the visible From address matches the domain SPF and DKIM verified, which is the part that stops someone forging your exact address.
And it sends you reports showing who is sending email using your domain, including the senders who shouldn’t be.
The DMARC setting most businesses get wrong
DMARC has three policy settings, and choosing the wrong one is a common mistake.
p=none tells receiving servers to do nothing when a message fails. It only monitors and sends you reports. Your domain can still be spoofed.
p=quarantine tells them to send failing messages to the junk folder.
p=reject tells them to block failing messages before they ever arrive.
A lot of businesses set up DMARC at p=none, watch the reports come in, and never move past it. At p=none, you get reports but your domain still isn’t protected.
Real protection only starts at quarantine or reject.
Microsoft’s own guidance is to work toward p=reject once you’ve confirmed your legitimate mail passes.
What SPF, DKIM, and DMARC don’t stop
These records stop someone from forging your exact domain.
There are two things they don’t catch, though, and both are worth knowing about.
Lookalike domains. A scammer can register a domain that resembles yours, like yourcompany-invoices.com, or yourcompany.co instead of .com, and send from that. Your records protect your real domain, not a different one the attacker owns.
Display-name spoofing. The name shown in the From line can read “Your Company Accounts” while the real address behind it is a random Gmail account. DMARC checks the domain, not the display name.
For those, you still need the habits that catch any phishing attempt: check the full email address rather than just the display name, and verify any request to change payment details by calling a known number, not one from the email.
Why this matters even if you don’t send bulk email
The first reason is protection.
These records stop scammers from impersonating your domain to your clients, your suppliers, and your own staff.
The second is deliverability.
The major mailbox providers now require these records from anyone sending in volume.
Since February 2024, Google and Yahoo have required bulk senders, meaning those sending more than 5,000 messages a day, to use SPF, DKIM, and DMARC.
Microsoft began applying similar requirements to Outlook.com and Hotmail in 2025, routing non-compliant high-volume mail to junk and then rejecting it.
Even below those thresholds, a domain with proper authentication is more likely to reach the inbox than the spam folder.
How to check and fix your domain
You can get a rough sense of where you stand without any technical work.
Several free DMARC and SPF checkers let you type in your domain and see which records exist. That tells you whether the records are present, though not whether they’re configured correctly.
Fixing them properly is a job for whoever manages your IT or your domain.
The records live in your DNS, and a mistake can send your own legitimate email to spam, so the rollout is done in stages:
Publish SPF and DKIM so all of your real mail sources are covered.
Add DMARC at p=none and read the reports to confirm your legitimate mail passes.
Move DMARC to p=quarantine, then to p=reject, once the reports look clean.
Microsoft recommends this same gradual path, starting at none and working toward reject, so you protect the domain without blocking your own mail on the way.
Frequently Asked Questions
What is email spoofing?
Email spoofing is when someone sends a message with your domain in the From address to make it look like it came from your company. It’s used to trick your clients, suppliers, or staff into paying fake invoices, changing banking details, or handing over information.
What are SPF, DKIM, and DMARC in simple terms?
SPF is a list of servers allowed to send email for your domain. DKIM is a signature that proves a message came from you and wasn’t altered. DMARC ties the two together, tells receiving servers to reject messages that fail, and reports who is sending email as your domain.
Does DMARC stop all email impersonation?
No. DMARC stops someone forging your exact domain. It does not stop lookalike domains (like yourcompany-invoices.com) or display-name spoofing, where the sender’s name says your company but the address behind it is different. Those still need staff awareness and payment-verification habits.
Will setting up DMARC block my own emails?
Not if you roll it out gradually. Starting at p=none lets you watch the reports and confirm your legitimate mail passes before you move to quarantine and then reject. Skipping straight to reject without checking first is what causes problems.
Do I need these records if I don’t send many emails?
Yes. They protect your domain from being spoofed regardless of how much email you send, and they help your messages reach the inbox. Google, Yahoo, and Microsoft now expect proper authentication, and mail without it is more likely to be filtered.
Article Summary: A QR code scam, sometimes called quishing, hides a malicious web link inside a QR code. Because the link is buried in an image instead of written as text, it slips past the email filters that normally catch bad links, and scanning the code usually moves the victim onto a personal phone that sits outside the company’s security. Microsoft reported a 146% rise in QR code phishing during the first quarter of 2026.
QR codes are part of normal business now.
You scan them to see a menu, pay for parking, connect to Wi-Fi, or open a shared document.
Attackers know that, and they have started hiding malicious links inside QR codes to get past the security tools that would normally catch a bad link in an email.
The technique has a name, quishing, and it works because a QR code is just an image.
Your email filter reads text, so a link encoded into a QR code can pass straight through. When you scan it, you usually do so on your phone, which sits outside most of the protection your work computer has.
This post covers what a QR code scam is, why it gets past your security, what the common ones look like, and the habits that protect your business.
What is a QR code scam?
A QR code scam is a phishing attack that uses a QR code in place of a written link.
Instead of a clickable URL your email security can inspect, the attacker encodes the web address into a square image.
You scan it with your phone camera, your phone opens the link, and you land on a page built to steal your login or your payment details.
The page on the other end is the same kind of fake you would see in any phishing attack, a login screen made to look like Microsoft 365 or a payment form that copies your bank. The QR code is only the delivery method that gets you there.
Why QR code scams get past your security
Two things make these scams effective.
First, the malicious link is hidden inside an image.
Most email security tools scan the text of a message for known bad links. A QR code is a picture, so the link inside it is not text the filter can read.
The UK’s National Cyber Security Centre points out that not all phishing-detection tools scan images, which is the reason criminals started using QR codes to disguise their links in the first place.
Second, scanning a code moves you onto your phone.
Your work computer probably has web filtering, endpoint protection, and DNS controls that block known bad sites.
Your personal phone usually has none of that. So the moment you scan, you step outside the protection your business pays for, often without realizing it happened.
How common are QR code scams?
The volume is climbing fast. In its report on email threats for the first quarter of 2026, Microsoft said it detected around 8.3 billion email-based phishing threats in those three months.
QR code phishing rose 146% across the quarter, from 7.6 million attacks in January to 18.7 million in March.
By the end of the quarter it had reached its highest monthly volume in at least a year.
Microsoft also found that most of these attacks arrived as PDF attachments, growing from 65% of QR code attacks in January to 70% in March.
The QR code sits inside a PDF, the PDF is attached to an email, and the whole thing looks like an ordinary document until someone scans it.
What QR code scams look like
These are the QR code scams that come up most often.
A “security” email. You get a message that looks like it is from Microsoft or your IT team, telling you to scan a code to re-enroll your multi-factor authentication or keep your account active. The code leads to a fake login page.
A shared document. An email says a colleague or client has shared a file, and you need to scan the code to view it. The page asks you to sign in first.
A fake invoice. A PDF invoice includes a QR code “to pay faster.” The code routes your payment to the attacker.
A delivery notice. A text or email about a missed package asks you to scan a code to reschedule. The US Federal Trade Commission has warned about this exact scam.
A sticker in the real world. Attackers print QR code stickers and place them over legitimate ones on parking meters, posters, and payment terminals. You think you are paying for parking, and instead you are handing your card details to a stranger.
How to protect your business from QR code scams
Protecting yourself against Quishing comes down to a few habits:
Be suspicious of QR codes in emails. A code that arrives by email, especially one that asks you to log in or pay, deserves the same caution as a strange link. The NCSC’s advice is to be wary of scanning QR codes inside emails, even though codes in places like restaurants are usually fine.
Check the web address before you act. When you scan a code, your phone shows the link before it opens. Read it. If the address is not the official site you expected, close it.
Go direct instead of scanning. If an email says your Microsoft account needs attention, open your browser and type the address yourself, or use a bookmark. Don’t rely on the code to take you to the right place.
Watch for urgency. Messages that threaten account closure or a fine “within 24 hours” are trying to rush you past your own judgment. That pressure is itself a warning sign.
Use phishing-resistant MFA. If a scam does capture a password, phishing-resistant multi-factor authentication (a passkey, a hardware key, or number-matching in an authenticator app) makes that password much harder to use.
Check physical codes for tampering. Before scanning a code on a parking meter or payment terminal, look for a sticker placed over the original.
Tell your team. Most people have never been warned about QR code scams. Send your staff a short message with a real example so they know what to watch for.
What to do if someone already scanned one
If you or someone on your team scanned a QR code and entered details on the page that opened:
Change the password for that account right away, along with any other account that used the same password.
Confirm multi-factor authentication is turned on for the account.
Tell whoever manages your IT, so they can check for unusual sign-ins.
If card or banking details were entered, call the bank and watch the account closely.
Acting quickly limits what an attacker can do with the details they captured.
Frequently Asked Questions
Are QR codes safe to use?
Most QR codes are safe. A code on a restaurant table or an official payment terminal is usually fine. The risk comes from codes sent in unexpected emails or texts, and from stickers placed over real codes in public. Treat those with caution.
What is quishing?
Quishing is phishing that uses a QR code instead of a written link. The word combines “QR” and “phishing.” The goal is the same as any phishing attack: to get you onto a fake page that captures your login or payment information.
Can antivirus or email filters stop QR code scams?
Not always. Many email security tools scan the text of a message for bad links, and a QR code hides its link inside an image, so it can slip through. Some products now scan images for codes, but you should not assume the scam will be caught before it reaches you.
Why is a QR code in an email more dangerous than a normal link?
A written link can be inspected by your email security and opened on a managed work computer. A QR code hides the link from those tools and pushes you to scan with your phone, which usually has far less protection than your work device.
What should I do if I scanned a scam QR code but didn’t enter anything?
If you closed the page without typing anything, the risk is low. Close it, don’t go back, and let your IT contact know so they can keep an eye out. If you did enter a password or payment details, follow the recovery steps above.
Small businesses are the most common ransomware target by volume of incidents, even though many small business owners assume hackers focus on larger organizations. A 22-person company has enough revenue to be worth attacking, no dedicated security team to defend it, and a publicly traceable footprint that takes about an hour to research.
What follows is a step-by-step walkthrough of how a small business gets attacked, written from the attacker’s side. The company in this account is composite, but the methods are accurate to current threat intelligence reporting. After the walkthrough, you’ll see five specific points where the attack would have been stopped by controls that come bundled with security tools most small businesses already pay for.
Monday: how I picked you
I work regular hours and run a small volume operation. My spreadsheet has about 40 prospects per month, and I prefer businesses between 10 and 50 staff. The reason for that range is economics. Large enterprises have security teams, incident response contracts, and lawyers who make recovery expensive on my end. At the other end of the scale, sole traders rarely have enough at stake to bother with. A 22-person commercial services company sits in the right zone: payroll, customer database, project files, supplier relationships, and an owner who will pay to get the lot back. The return per hour is better at this size than at either extreme.
I did not find you through a breach or a tip. I found you on a public business records portal. State business registries, federal contract awards, and county-level licensing databases publish enough detail for me to identify your company, look up your name, estimate your revenue, and pick the most useful person inside the business. One search told me your company name, your registered agent, the contract value of a recent municipal job, and the named contact on the submission.
The fact that nothing has gone wrong at your company yet is the strongest signal I get. It tells me your credentials are probably still valid, your staff has not been trained to spot anything, and nobody has had a reason to change a password. A clean record is the first indicator I look for.
Tuesday: building your org chart for free
I spend about 40 minutes researching your company today using only a browser.
LinkedIn gives me eight of your current employees with their job titles listed. Your office manager has been there for six years and lists “accounts payable, payroll, and supplier invoicing” in her profile summary. Your second admin joined 14 months ago. You list yourself as director, with a sparse profile and a low connection count, which tells me you are unlikely to notice when someone unusual starts engaging with your profile or your company’s social media.
Public business filings confirm your registered business name and your full legal name. A “meet the team” post from two years ago on your Facebook page lists first names and photos, including someone described as helping out in the office a couple of days a week. One of the commenters shares your surname.
I now know who handles your money, what their name is, how long they have been there, what software they probably use (I will check your job ads on Indeed for the phrase “experience with QuickBooks or Sage”), and who in your business has the authority to approve a payment without a second signature.
That last person is my primary target. You are harder to reach and probably more cautious. Your office manager has system access, handles supplier payments, and is busy enough that one more email in her inbox does not get scrutinized the way it might if she had nothing else to do.
I have not spent a dollar yet.
Wednesday: I bought your credentials for $14
Stealer logs are credential packages harvested by infostealer malware that infected someone’s personal device, often months or years earlier. The malware records every username and password typed into the machine, then bundles the data for sale. Marketplaces on Telegram channels and forums let buyers search these logs by company email domain.
I search for your company’s email domain. Two results come back. One is your office manager’s work email, with a password that looks like it was saved in her browser. The other is a personal Gmail address that appears to belong to a family member of yours, probably from a device that shared a home network.
I pay $14 for the package. It takes four minutes.
Your office manager’s password follows a common pattern: a pet or child’s name combined with a year and an exclamation mark. I check it against HaveIBeenPwned, which is the same free database security professionals use, and find that it appeared in a credential dump from a retail loyalty program breach three years earlier. The password has not been changed since.
Your family member’s credentials are more interesting than they look at first. The same password, with minor variations, shows up across a streaming service, a gaming account, and your company’s Microsoft 365 login. The password works. The only thing standing between me and the inbox is the second factor.
Total spend so far: $14.
Thursday: getting past your MFA
Multi-factor authentication stops a lot of attacks, but the implementation matters more than the checkbox.
Simple push-notification fatigue does not work against your office manager’s account. Microsoft enabled number matching by default for all Microsoft Authenticator push notifications in May 2023, which means she would have to type a code from her login screen rather than just tap approve. Push bombing fails against that configuration.
What still works is adversary-in-the-middle (AiTM) phishing. I send your office manager an email designed to look like a routine Microsoft 365 password reset notification, citing the breach that her password appeared in (the same breach I found her credentials in earlier in the week). The link in the email takes her to a page that mirrors the real Microsoft sign-in screen. That page is a proxy I control.
When she enters her password and approves her MFA prompt, my proxy forwards both to the real Microsoft login server. Microsoft validates the credentials, completes the MFA challenge, and issues a session token back to my proxy. I capture the token. She sees a normal login experience on what she thinks is the real Microsoft site, then a “password updated successfully” message.
I am now signed in as her. The MFA prompt succeeded, and the session token sits in my browser instead of hers. Microsoft sees a valid authenticated session and treats my activity as legitimate.
I had a backup plan in case the email did not get clicked. Earlier in the day, I called your office posing as your IT support company, using a name I found in a Google review you had left 18 months earlier. I told your receptionist that we were seeing unusual login activity on the office manager’s account and that I would need her to approve a verification push in the next few minutes. She said the office manager was not at her desk. I said no problem, I would try again later. The call cost me nothing.
By Thursday night, I am inside your office manager’s Microsoft 365 account. I set up an inbox forwarding rule so her emails copy to an address I control without notifying her, then I wait.
Friday 2:47pm: why I waited 36 hours before encrypting
I spend 36 hours reading email before I encrypt anything. That dwell time is how I size the ransom correctly.
In those 36 hours, I find your cyber insurance policy attached to an email from your broker, with a cyber liability sub-limit of $250,000. A bank reconciliation your office manager sent you two weeks ago shows your business account at around $180,000 at month end. Your customer list sits in a quote template she emailed to herself, and a message thread with a municipal project manager mentions a job starting in three weeks with a hard deadline you cannot afford to miss.
I set my ransom at $65,000 in cryptocurrency. That figure is low enough that you will pay rather than fight it, high enough that it is worth my time, and well within what I know you can access. Ransoms set above 10 percent of visible liquid assets tend to get contested. The figure I picked sits below that line.
I deploy the encryption payload at 2:47pm on Friday. The timing is deliberate. Your bookkeeper finishes at 3pm on Fridays, which I know from an out-of-office reply I saw in the forwarded emails. You are on a job site, with your calendar synced to the shared inbox. The person most likely to notice something wrong and call for help is already gone, and the person with the authority to make decisions is unreachable.
By the time anyone understands what has happened, it is a Friday evening, every file on your shared drive is encrypted, and a ransom note sits on every screen in your office.
Total cost to me: $14 for credentials and about six hours of work spread across the week.
Five places this attack would have died
The attack on your business worked because five ordinary things were not in place. None of them were expensive. Most were already bundled into security tools you already pay for.
1. The credential purchase on Wednesday.
HaveIBeenPwned is free. Microsoft Entra password protection can detect and block reused or commonly-compromised passwords across your accounts. Enforcing unique passwords per account, through a password manager and through Entra’s policies, makes a stolen credential purchase useless for me.
2. The MFA bypass on Thursday night.
Microsoft already blocks the simpler push-bombing attack, because number matching has been enabled by default for all Microsoft Authenticator push notifications since May 2023. The current dominant credential-based bypass is adversary-in-the-middle phishing. Defenses include phishing-resistant MFA (FIDO2 hardware keys, passkeys, or Windows Hello for Business), Conditional Access policies that require a compliant or hybrid-joined device, and anti-phishing protection in Microsoft Defender for Office 365. Any one of these would have either prevented the session token capture or made the captured token unusable from my IP address.
3. The inbox forwarding rule.
Microsoft 365 allows admins to block external email forwarding rules at the tenant level. With that block in place, the inbox forwarding rule I used to read 36 hours of email would not have worked. I might have encrypted anyway, but I would have been guessing on the ransom size.
4. The 36-hour dwell time.
Microsoft Defender for Business, included in Microsoft 365 Business Premium, generates an alert when a new inbox forwarding rule is created. If anyone had been watching those alerts, or if the alerts had been routed somewhere visible, I would have been detected on Thursday night. The most impactful change for a business your size is rarely a new product purchase. The improvement comes from someone reviewing the security alerts that the tools you already pay for are already generating.
5. The public business records.
You cannot unpublish a state contracting registry or a federal contract award. That data will stay public. What you can control is what your team chooses to post about their specific responsibilities. Your office manager’s LinkedIn profile listed her financial responsibilities in enough detail to make her the obvious target. That detail is worth a conversation with your team, framed as practical security awareness rather than a rule about what people can post.
Three questions to send your IT provider
These three questions cover most of where the example attack failed. Each one corresponds to a control that comes bundled with security tools you most likely already pay for.
Are we using phishing-resistant MFA (FIDO2 keys, passkeys, or Windows Hello for Business) for finance, admin, and executive logins?
Is external email forwarding blocked at the tenant level?
Are our security alerts going somewhere, and is someone reviewing them?
Frequently asked questions
Do hackers target small businesses?
Yes. Most ransomware operations target small and mid-sized businesses because the ratio of payout potential to defensive resources is higher than at either extreme of company size. The volume sweet spot is roughly 10 to 50 staff, where there are assets worth encrypting but no dedicated security team to defend them.
What is adversary-in-the-middle (AiTM) phishing?
AiTM phishing is a technique where the attacker hosts a proxy page that mirrors a real login screen, such as Microsoft 365 or Google Workspace. When the user enters credentials and approves the MFA prompt, the proxy captures the resulting session token. The legitimate service treats the login as successful, but the session token ends up in the attacker’s browser. AiTM has become the dominant credential-based attack vector against Microsoft 365 tenants after the default rollout of number matching ended simpler push-bombing attacks.
What is a stealer log?
A stealer log is a package of credentials harvested by infostealer malware from an infected personal device. The logs include browser-saved passwords, session cookies, and stored authentication tokens, and they are sold on underground markets for $10 to $20 per package. The malware that creates them typically infects personal computers through pirated software or malicious browser extensions.
How much does it cost an attacker to compromise a small business?
In the example walkthrough above, the total spend was $14 for stolen credentials and about six hours of work. Costs vary, but the threshold to attempt the kind of attack described in this post sits well below $100.
Are there free tools that would have stopped this attack?
Several of the controls referenced in the walkthrough come bundled with Microsoft 365 Business Premium licenses that businesses in this size range typically already hold. External forwarding restrictions and Defender for Business alerts are configuration changes rather than new purchases. HaveIBeenPwned is a free check available to anyone. Phishing-resistant MFA hardware keys are a small per-user cost compared with the cost of a successful ransomware incident.
If any of this walkthrough sounded uncomfortably similar to your environment, the three questions above are a good starting point. Your IT provider should be able to confirm what is in place and what is not within an hour or two. And if you don’t have an IT provider, feel free to reach out to us and we’ll help you sort it.
Most cyberattacks do not start with a sophisticated intrusion. They start with a click on a personal email, a reused password, or a file uploaded to a familiar cloud service because the approved option felt slower.
Not a zero-day exploit. Not a brute-force attack on a hardened system. Human behavior, in the course of an ordinary working day.
For businesses running cloud-based workflows across multiple devices, the personal and professional overlap is now the rule. Understanding where that overlap creates risk is no longer optional. It is a core part of modern security strategy.
The Risk Sitting Outside Your Security Stack
Personal web habits are not reckless behavior. They are normal behavior.
Checking a personal inbox on a work laptop. Logging into a social account during a break. Saving a work password in a browser already loaded with personal accounts. Uploading a document to a storage service because it is faster than the approved option.
None of these feel like security decisions in the moment. But each creates a connection between personal digital activity and business systems, and that connection sits outside most traditional security controls.
Hardening systems, deploying tools, and locking down networks addresses part of the problem. The rest moves with the people.
How Personal Web Habits Create Business Exposure
Personal channels are phishing’s preferred territory
Personal inboxes, messaging platforms, and social media feeds are where phishing thrives.
These environments are harder to filter, easier to spoof, and loaded with the emotional triggers that make people act before they think.
When those channels share a device or browser with business systems, a single click can cross the boundary instantly.
Phishing is the most common entry method for attackers precisely because it exploits distraction rather than technical weakness. The target does not need to be careless. They just need to be busy.
Password reuse turns personal breaches into work incidents
Password reuse is one of the most direct connections between personal and professional exposure.
When credentials from a personal account are compromised, attackers run them against business systems automatically. This technique, credential stuffing, is low-effort and highly effective because so many people use the same password across multiple accounts.
Unique credentials for every account, combined with multi-factor authentication, break that chain.
A personal breach has nowhere to go when the work account requires a second factor that the attacker cannot relay.
Shadow IT is usually about convenience, not defiance
Most unauthorized tool usage does not begin with disregard for IT policy. It begins with a productivity gap. Employees use personal cloud storage, consumer messaging apps, or AI tools because they are faster and more familiar than the approved alternative.
The security risk is not the intention behind the choice. It is what happens to the data.
Once business information moves into platforms that IT cannot see, audit, or secure, it falls outside every control in place. The tool usage is predictable. The data exposure is not.
Why Blocking Behavior Doesn’t Work
The instinct is to lock things down: block personal apps, restrict browsing, enforce strict device policies.
In practice, blanket restrictions rarely stop the behavior. They relocate it. Users find workarounds. Unapproved tools move to personal devices. IT teams lose visibility into exactly the activity they were trying to manage.
The risk does not disappear. It moves somewhere harder to see.
Security strategies that assume perfect compliance perform poorly in real workplaces. The goal is not eliminating the overlap between personal and professional digital activity. It is managing it without breaking how people work.
What Actually Reduces Risk
The controls that work are the ones that match how people actually operate.
Separate contexts, not people
The simplest way to reduce crossover risk is to reduce crossover.
Separate browser profiles for work and personal activity, clear guidance on where business accounts should be accessed, and identity boundaries that prevent accidental mixing all reduce exposure without restricting what people do with their time.
This is not about surveillance. It is about creating enough distance between personal and professional digital activity that a compromise in one does not automatically reach the other.
Design for credential failure
Assume passwords will eventually be exposed somewhere. Design for that outcome rather than hoping to prevent it.
CISA reports that enabling multi-factor authentication makes accounts 99% less likely to be compromised, even when the underlying password has already been stolen.
MFA converts the most common attack path into a dead end.
Stolen credentials from a personal breach cannot reach a work account that requires a second factor. A password manager handles unique credentials across every account, making that protection sustainable without placing an unrealistic burden on users.
Make secure behavior easier than unsafe behavior
Personal web habits are not dangerous by default. Ignoring the risk they create is. The most secure environments today are not the most restrictive. They are the most realistic: built around how people actually work, designed to contain failure when it happens, and focused on making safer behavior the path of least resistance.
Helping clients reduce human-driven security risk is one of the most impactful services an MSP can offer.
Contact us or schedule a consultation to review current controls and identify where the most important gaps are.
It’s a statistic that sends a shiver down the backs of SME owners, managers and employees.
According to the FBI’s 2025 Internet Crime Report, business email compromise (BEC) cost US businesses more than $3 billion last year.
This makes it one of the most financially damaging cybercrimes on record.
AI has made these attacks harder to detect. The question for AP teams is no longer whether they can identify suspicious requests. It is whether the processes around payments make fraud difficult regardless of how convincing it looks.
Why AP Teams Are in the Crosshairs
Accounts payable sits at the intersection of trust and timing. AP teams process invoices, manage supplier details, and execute payments, often under pressure to keep operations running smoothly.
For attackers, that combination is ideal.
Most successful fraud does not involve breaking into systems.
The FBI’s Internet Crime Complaint Center (IC3) has consistently found that BEC attacks rely on impersonation. This involves posing as a trusted executive, supplier, or internal colleague to redirect payments or update bank details before anyone notices.
AI has made that impersonation dramatically more scalable.
Where it once required skill and time to craft a convincing request, tools are now widely available that automate the research, writing, and contextual tailoring that make fraud blend into normal AP workflows.
Traditional phishing relied on volume and imperfection. AI has changed that.
Modern BEC emails are grammatically correct and written in the specific tone of the executive or supplier being impersonated. They reference active projects, current invoice numbers, and upcoming payment runs.
For AP teams processing high volumes of routine communications, that level of familiarity is exactly what lowers the guard.
Invoice and payment redirection
One of the most common AP fraud patterns involves payment redirection.
Attackers may intercept a legitimate invoice exchange and quietly alter the destination account. They then send a short message claiming a supplier has updated its banking details, or re-issue a real invoice with minor modifications.
The surrounding content looks entirely legitimate because, in many cases, it is drawn from real correspondence.
Voice cloning and executive impersonation
Email isn’t the only channel being exploited.
AI voice-cloning tools can replicate a person’s voice from a short audio sample. That makes it possible to leave convincing voicemails or place calls that sound like a known executive.
For AP teams accustomed to verbal approvals on high-value or urgent payments, this removes one of the few remaining verification methods that email security alone cannot address.
Why Traditional Checks No Longer Work
Security awareness training still matters, and investing in it remains worthwhile. But AI has changed what AP teams are up against.
Attacks no longer contain the signals that training programs once focused on: awkward phrasing, mismatched logos, odd sender addresses, or generic greetings.
Modern fraud emails can reference the recipient’s organization, active suppliers, and current invoice values drawn from publicly available or previously intercepted sources.
When a fraudulent request is indistinguishable from a legitimate one, placing the burden of detection on the AP team puts it in the wrong place.
The organizations that reduce risk are not asking staff to be more suspicious. They are building verification processes that work independent of how a message looks.
Building Process Around the Risk
The most effective defense is not sharper instincts. It is removing ambiguity from high-risk actions.
Out-of-band verification as standard
Any request to change supplier bank details or approve an urgent payment outside the normal cycle should require secondary confirmation through a known, independent channel — not a reply to the same email thread. Calling a supplier on a number already on file, or confirming with a colleague directly, breaks the impersonation chain regardless of how convincing the original request appeared. This step does not require technology. It requires a written procedure and the team’s habit of following it.
Layered access and authentication controls
Restricting access to financial systems and enforcing multi-factor authentication limits the damage a compromised account can cause. If an attacker gains access to a vendor’s email, MFA requirements on the receiving end create friction that can slow or stop a fraudulent change before any money moves.
A culture that supports slowing down
Fraud prevention improves when staff feel safe questioning requests, including from senior leadership.
A team member who pauses a payment to verify it is not being obstructive. They are doing exactly what good process requires.
Building that culture starts with leadership modeling the behavior and making clear that slowing down on high-risk actions is always the right call.
The FBI’s 2025 Internet Crime Report included a dedicated AI section for the first time, logging more than $893 million in AI-enabled scam losses across more than 22,000 complaints.
When verification is standard and questioning is encouraged, AI-enhanced fraud loses much of its advantage.
The technology attackers use is advancing quickly, but the process controls that contain the damage do not have to be complicated. They have to be consistent.
Shift the Burden From People to Process
Concerned about AI-enhanced fraud targeting your finance teams or clients?
Contact us or schedule a consultation to review your current controls and identify where the most important gaps are.
You click a link, sign in, approve the MFA prompt, and get on with your day. Completely unaware that someone else just logged into your account at the same moment.
That scenario surprises many businesses, particularly those that rely on multi-factor authentication (MFA) to protect cloud accounts. But this is exactly how Adversary-in-the-Middle (AiTM) phishing attacks work.
Rather than stealing passwords for later use, these attacks silently hijack an already-authenticated session in real time.
MFA remains a core control, and getting it implemented correctly is still a critical first step for any business.
But AiTM attacks exploit something MFA was never designed to protect: the trusted session that exists after authentication has already completed.
Phishing Has Moved Beyond Passwords
Phishing remains the most common starting point for account compromise, but the objective has changed.
Traditional phishing collected usernames and passwords. Modern phishing is after something more immediately useful: the authenticated session itself.
Security researchers have documented a significant shift toward session and token theft, where attackers intercept the authentication process as it happens.
Rather than reusing stolen credentials, which MFA typically blocks, they wait until the user successfully completes login, then steal the session token that proves it already occurred.
The technique has matured quickly. Phishing-as-a-Service (PhaaS) platforms now supply ready-made proxy toolkits that let even low-skilled attackers run AiTM campaigns targeting Microsoft 365 and Google Workspace.
How AiTM Attacks Actually Work
The fake login page that isn’t fake
An AiTM phishing site is not a basic replica of a login page. It is a live reverse proxy.
The attacker’s infrastructure sits between the user and the real authentication service. Every keystroke, redirect, and server response flows through the attacker’s system in real time. From the user’s perspective, nothing looks wrong.
The page behaves exactly like the real service, with correct branding, working redirects, and a functioning MFA prompt. In most cases, the only clue is a slightly altered URL that goes unnoticed on a mobile screen or when someone is under time pressure.
Why MFA doesn’t stop it
This is where many security assumptions fall apart.
MFA protects the moment of authentication, not what comes after it.
Once a user successfully completes MFA, the service issues a session cookie. What this means is that the cookie signals to the application that the user is already verified. From that point, no password or MFA prompt is required. The system trusts the token. Whoever holds the cookie holds the access.
AiTM attacks simply wait for that cookie to be issued then steal it.
Microsoft tracked a 146% rise in AiTM attacks over the past year, as cybercriminals increasingly shift focus to accounts already protected by MFA.
Much of this increase is driven by PhaaS platforms like Evilginx that allow even low-skilled attackers to run convincing reverse-proxy campaigns at scale, targeting major cloud identity providers with minimal setup.
Session cookies
Session tokens act as bearer credentials. So, whoever possesses the token can access the account, with no password or MFA challenge required.
Once the cookie is stolen, the attacker imports it into their own browser and immediately resumes the session.
This is a session replay attack. The attacker does not log in. They pick up where the legitimate user left off, inside a fully trusted, already-verified session.
What Happens After a Session Is Stolen
The aftermath of an AiTM attack tends to be quiet, which is precisely what makes it dangerous.
The attacker is operating inside a legitimate, authenticated session. There are no failed MFA attempts, no unusual login alerts, and nothing in standard sign-in logs to signal a problem.
Research from Proofpoint shows that attackers who gain access through session hijacking commonly create hidden inbox rules to redirect mail, register additional MFA methods to lock in persistent access, monitor email threads for financial conversations, and use the trusted account to launch phishing campaigns against internal colleagues or finance teams.
These follow-on actions are a key reason AiTM attacks are frequently uncovered late, after financial fraud, data exposure, or wider network compromise has already begun.
Reducing Your Exposure
MFA is still essential. Building strong authentication practices remains the starting baseline. But reducing AiTM risk requires controls that extend beyond the login event itself.
Adopt phishing-resistant MFA
Methods like FIDO2 hardware keys and passkeys bind authentication to the specific device and the legitimate domain. A proxy in the middle cannot relay them: the process fails if the URL is not the real one.
The Canadian Centre for Cyber Security analyzed over 100 AiTM campaigns targeting Microsoft Entra ID accounts. It found that phishing-resistant MFA consistently blocked session theft where standard MFA methods (including push notifications and one-time passcodes) did not.
Tighten Conditional Access policies
Risk-based access controls evaluate additional signals, including device compliance, IP location, and session behavior, rather than treating every authenticated session as permanently trusted.
Configured correctly, these policies can detect and block anomalous access even when a stolen session token appears valid.
Monitor for post-login anomalies
Detecting AiTM compromise typically means watching for activity after login: new MFA method registrations, inbox rules created outside business hours, access from unfamiliar locations, or unusual data activity.
Authentication logs alone will not surface the problem.
Train users on URL awareness
Employees who understand that a working MFA prompt on an unfamiliar-looking page still represents a risk are better positioned to pause, check the URL, and report before a session is compromised. A brief team walkthrough of what AiTM lures look like in Microsoft 365 contexts can meaningfully reduce exposure.
Stop Protecting Just the Login Screen
MFA is a baseline, not a finish line. The businesses that reduce AiTM risk are the ones that understand how sessions, tokens, and identity trust actually work . And they build controls around each layer, not just the login screen.
Want to review your identity security controls?
Contact us or schedule a consultation to identify the gaps that matter most before an incident does it for you.
MFA is a strong front-door lock. But it’s not the only thing that decides whether someone can get in.
After you sign in, your browser keeps you logged in using a session token (often stored as a cookie). It’s the digital version of a wristband at an event: once you’ve been checked, the wristband proves you belong there. If an attacker steals that wristband, they may not need to beat your MFA prompt at all.
That’s the core of session cookie hijacking. The attacker isn’t “cracking” MFA. They’re skipping it by replaying your already authenticated session.
This isn’t a reason to stop using MFA. It’s a reason to stop treating MFA as the finish line.
When sessions can be stolen, the practical defence shifts to layered controls: phishing-resistant sign-ins, device hygiene, tighter session policies, and detection that catches suspicious access early.
Why MFA Isn’t a “Game Over” Control
MFA is still one of the best upgrades most businesses can make, but it doesn’t end an attack on its own. The reason is that attackers don’t always try to beat the login step. They try to go around it.
Cloudflare notes that “attackers are finding new ways to circumvent MFA” and that modern incidents are rarely one isolated technique. They’re “part of a chain of attacks.”
In other words, MFA can block a lot of credential theft, but it doesn’t automatically protect what happens after a user successfully signs in.
That’s where session cookie hijacking comes in.
Microsoft has described adversary-in-the-middle phishing campaigns where attackers use a reverse-proxy site to “steal and intercept” a user’s password and the session cookie that proves they have an authenticated session.
This is “not a vulnerability in MFA.” The attacker isn’t breaking the MFA. They’re reusing the session.
What a Session Cookie Is and Why Attackers Want It
When you sign into a web app, the site needs a way to remember that you’ve already proved who you are. That’s what a session is: a temporary “logged-in” state that saves you from entering your password and MFA code on every click.
Kaspersky explains that session hijacking is “sometimes called cookie hijacking” because cookies are commonly used to store the session identifier that keeps you authenticated.
Attackers want that session identifier because it’s the shortcut.
Proofpoint describes session tokens as digital “keys” that let a user stay authenticated. It warns that stealing valid tokens lets attackers impersonate legitimate users and potentially bypass authentication measures “like MFA.”
That’s why session cookie hijacking is so highly leveraged.
If an attacker can steal the cookie or token that represents your active session, they’re not trying to defeat the login process. They’re attempting to reuse what you already completed, and access the same apps and data as if they were sitting at your keyboard.
How Session Cookie Hijacking Actually Happens
A lot of teams picture “account takeover” as someone guessing a password or tricking a user into approving an MFA prompt.
Session cookie hijacking is different. The attacker’s goal is to steal the proof that you’re already logged in, then reuse it, often without triggering another sign-in challenge.
1.) AiTM phishing
Adversary-in-the-middle (AiTM) phishing is the “proxy login” trap.
You think you’re signing into a normal service, but you’re actually signing into a lookalike page that sits between you and the real site. The attacker relays the login in real time, so everything appears to work, including MFA.
Attackers use AiTM phishing sites to “steal and intercept” a user’s password and the session cookie that proves the authenticated session. This is “not a vulnerability in MFA.” The attacker isn’t breaking the MFA. They’re capturing the session after MFA is completed and reusing it.
Browser-in-the-middle (BitM) is similar in spirit, but it’s even more “hands-on” from the attacker’s side.
Instead of stealing a password and running away, the attacker effectively places themselves in control of the browsing session.
Google’s threat intelligence says, “Stealing this session token is the equivalent of stealing the authenticated session.” Once the token is stolen, “an adversary would no longer need to perform the MFA challenge.”
In other words, the attacker isn’t trying to authenticate instead of you. They’re trying to ride along after you’ve authenticated.
3.) Cookie theft from the endpoint
Not every session hijack starts with a fancy proxy. Sometimes the attacker simply steals session data from the device itself.
Stealing valid session tokens allows attackers to impersonate legitimate users. Tokens act like digital “keys.” If an endpoint is compromised, those “keys” can be extracted and reused.
Invicti explains that an attacker steals HTTP cookies and can gain access. The goal is often to obtain sensitive information stored in cookies.
MFA Is a Baseline, Not a Finish Line
MFA is still essential. It blocks a huge amount of credential theft and makes basic account takeover harder. But session cookie hijacking is a reminder that attackers don’t always try to defeat the login step. Sometimes they reuse what happens after it.
The practical response is layered and realistic. Make phishing harder to pull off, and treat device health as part of identity. Tighten session behaviour for high-risk apps. Watch for suspicious access patterns that suggest a session is being replayed.
When those controls work together, MFA stops being a comforting checkbox and becomes what it should be: a strong baseline that’s backed by protections around the session itself.
Contact us today for help protecting your login sessions from hijacking.
Browser add-ons have a funny reputation. They feel “small”. A quick install. A tiny productivity boost. A harmless little helper that lives in your toolbar.
But in practice, a browser extension is more like a micro-SaaS vendor sitting inside your browser session. It can see what you see, interact with the pages you open, and sometimes access the same cloud apps your business runs on all day.
That’s why a browser extension security check matters.
Not because every extension is bad, but because it only takes one over-permissioned add-on or one bad update to turn “helpful” into exposure.
The good news is you don’t need a 40-page policy to reduce the risk. A simple five-minute check can prevent most extension problems before they start.
Why Browser Extensions Are a High-Leverage Risk
Browser extensions sit in the most sensitive place in modern work: the browser tab where your staff live all day.
That matters because extensions aren’t just “apps”. They’re granted special authorisations inside the browser. That makes them attractive targets and gives them leverage that’s disproportionate to how “small” they feel.
UC Berkeley’s guidance says extensions get “special authorisations,” and the more you install, the bigger the attack surface becomes.
The risk is often permission-based. OWASP calls out “permissions overreach” as a core problem. Extensions can request more access than they need, including access to “all tabs, browsing history, and even sensitive user data.”
When an extension can read and modify what happens in the browser, it can potentially see data in cloud tools, capture what’s typed into forms, or alter content on a page.
It’s also a “change over time” risk. A useful extension today can become a different extension tomorrow.
The 5-Minute Browser Extension Security Check
This browser extension security check is designed to be fast, repeatable, and realistic. It helps staff make safe decisions in minutes without turning every extension into a big IT ticket.
Vet the developer like a real vendor
If you wouldn’t give a random supplier access to your customer records, don’t give a random extension access to your browser.
Start with the basics:
Confirm the developer has a real website, support details, and a consistent name across listings
Look for a track record (other products, a clear company presence, updates that look normal)
Prefer official stores and trusted sources over “download this .zip” links
Read the description like a contract
Treat the store listing as a mini security disclosure. It should clearly explain what the extension does and why it needs access.
What to look for:
Specific, concrete function
Clear explanation of what data it touches
Any hint of tracking, analytics, or data sharing that doesn’t match the core feature.
Permission sanity check
Permissions are the whole game. This is where a “helpful tool” can become a high-leverage risk.
Microsoft’s Edge Add-ons policies say extensions “must only request those permissions that are essential for functioning,” and requesting permissions for “future proofing” is “not allowed.”
How to do a fast check:
Ask: “Does this permission match the feature?” If not, it’s a red flag.
Be cautious of anything that effectively means “read and change everything you do in the browser.”
Remember: Google even publishes guidance for admins to “evaluate the security risk” of different extension permissions.
Check updates and change risk
Extensions aren’t static. They update. And updates can change what the extension can do.
Two things to watch:
Permission creep: If an extension suddenly requests new permissions, you should be wary. And if you can’t justify it, “it’s probably better to uninstall”
Update abuse: Treat unexpected permission changes or sudden feature shifts as a reason to pause and escalate
Decide: approve, avoid, or escalate
You don’t need a committee for every install.
You need a simple decision tree:
Approve when the vendor is credible, the purpose is clear, and permissions are tight and match the feature
Avoid when the extension is vague, over-permissioned, or feels like it wants access “just in case”
Escalate when it’s genuinely useful but touches sensitive systems or asks for broad permissions.
Have IT review it and, if approved, add it to an allowlist
From “Quick Install” to Clear Standards
Browser extensions aren’t “bad”. Unvetted extensions are the problem.
A simple browser extension security check turns installs from impulse decisions into repeatable standards.
You’re not trying to slow people down. You’re trying to make sure the tools that live inside your browser have a clear purpose, tight permissions, and a vendor you’d actually trust.
Start small. Reduce extension sprawl, treat permission changes as a red flag, and escalate anything that touches sensitive systems.
Then make it easier for staff to do the right thing by default with an approved list and browser-level controls. When installs are standardised, extensions stop being a hidden risk and become just another managed part of the environment.
Contact us today to schedule a browser extension audit.
Cybersecurity
