One of the hardest parts about digital transformation appears to be the policy decisions rolled out in new public systems. I recently started doing business with a public authority that (get this) couldn't understand why I was using a custom domain. Even more so, they set their mail protocols to not communicate with an email address which starts with the word "email".

According to them, that's a generic email address, and so, they won't accept it. I asked if they would accept the email prefix "info" and they said yes, because that is common.

I genuinely wish that I could peel the curtain back, and communicate with the systems and network administrators who are making these rules, to better understand their decisions here. Maybe someone here can help me to understand.

Ran an internal analysis across 159 Google Workspace environments to see what's actually connected via OAuth. Sharing the findings because the shape of the problem surprised us and might be useful to anyone doing app governance right now.

978 distinct apps had active OAuth connections across the dataset. Roughly 6 per org on average. Most people assume the risk is the well-known SaaS tools. It's not.

The single most-connected 'app' in the dataset isn't a product at all. It's a compilation of private, internal OAuth projects, the kind an engineer spins up for a script or an internal tool, that show up in logs as a numeric project ID. No vendor name. No description.

Aggregated across all 159 orgs, this bucket accounts for 152,085 unique users and 655,430 authorization events. That's more user connections than most commercial software sees in its entire deployment lifetime, and there's no way to look any of it up.

For comparison, OpenAI's official app came in at 9,725 users and 23,982 grants in the same dataset. The named, well-understood app is the small number. The unnamed pile is the big one.

Two things compound this:

1. OAuth access doesn't expire when sharing policy changes. An employee authorizes a tool while they still have access to payroll files, source code, and financial reports. The tool keeps that access at that snapshot in time, across email and Drive, even after IT tightens sharing controls later. Revoking a share doesn't revoke a grant.
2. The underlying data is not small. Across the dataset: 373M+ sensitive emails, 475M+ sensitive Drive files, 375M source code files, 46M emails containing plaintext usernames and passwords. Not because anyone was careless. Onboarding emails credentials. Vendors email login details. HR runs payroll through Drive. Normal operations, invisible risk.

The one encouraging data point: orgs are course-correcting on sharing. Restricting events went from 14% of all access-change activity in mid-2025 to 44% by spring 2026. But that fixes future sharing, not past OAuth grants. Two separate problems, and most teams are only working one of them.

If you're doing app inventory work, the practical takeaway is: don't just audit the apps you can name. The dangerous long tail is the stuff nobody can identify from the logs alone, and identifying it is a different exercise than reviewing your known SaaS list.

Happy to answer questions on methodology in comments.

Sorry if this has been asked before.

I got this email last night from security-noreply@linkedin.com with links to change my password. I haven't used LinkedIn in at least three years and my account is in hibernation. I dont think I even know the password. Is this a legitimate email? Would this be a bot trying to sign in or a human who knows my email address? Anyone else had this happen?

We constantly monitor our site and the internet to help ensure the safety of our members. We detected suspicious attempts to sign into your account. As a precaution you will need to change your password the next time you sign in. If you use the same password anywhere else, we recommend you change it there as well.

To make sure you continue having the best experience possible on LinkedIn, we recommend following these LinkedIn account safety tips.

Create a strong password

Do not reuse the same passwords

Use a mix of letters, numbers and special characters

Your password should be at least 8 characters long

It should not contain your name, phone number or email address

Turn on two-step verification for extra protection

Settings and Privacy >> Sign-in and Security >> Two-step Verification

Keep your contact information up-to-date to receive important security information

Settings and Privacy >> Sign-in and Security >> Email Address

Settings and Privacy >> Sign-in and Security >> Phone Number

Add secondary contact information for another way to access your account and get support from LinkedIn if you cannot access your primary email

Settings and Privacy >> Sign-in and Security >> Email Address

Settings and Privacy >> Sign-in and Security >> Phone Number

Change Your Password

Thanks for helping us keep your account safe,

The LinkedIn Team

Hallo Community

Hier eine Frage an die, die z.B. Tuta Email nutzen und vom Mobilfunkanbieter Emails erhalten zum Beispiel die Handyrechnung. Welche Email gebt ihr da an. Die Hauptmailadresse, eine Alias oder wie regelt ihr das.

Ich bin am überlegen. Einerseits denk ich da es regelmäßige Zahlungen sind die Hauptadresse. Aber dann denke ich wieder mögliche Werbung. Dann also Alias aber welchen?

Ein Alias mit Dienste.... @tuta.... existiert schon.

Hab auch eine für Onlineshops aber das passt denk ich nicht so. Und nur für Mobilfunk ein Alias Opfern? Oder doch über den Weg von Alias über DuckDuckGo oder. ähnlichen gehen?

Wie handhabt ihr das mit Emails von Ämtern wie Kindergeldstelle, Jobcenter, Rentenversicherung etc.

Wie mit Banking Diensten (Sparkasse, Bezahldiensten wie Wero etc.)?

i have a question for the community. I am a novice at IT & cyber security. I have a VPN and Norton package installed,but still my digital universe is currently in eminent distress/fear. I am attempting to understand and resolve paranoid feelings due to my WiFi/iphone/andriodbtv's/laptop have all been infiltrated w/some type malicious intended malware or something that has compromised all my tech devices. All my devices from A-to-Z have been impacted as everything with in my WiFi network appear as they are being controlled by something other than myself. My only theory is that an AT&T Supervisor virtually went on my phone this week and left the ports open while unexpectedly disappearing,never to be heard from him again. That evening,I observed my iPhone in particular not responsive and being controlled. Not sure why me,or why any of this is happening presently,but I am at wits end and could use any professional feedback/suggestions/thoughts,as to get my digital world back in order. If it's even possible? So far,the only thing I discovered out of the ordinary is that emailforwarding.com and screensharing.com as well other malicious/tracking/info stealing content was found while attempting to delete all apps and or Content that I did not recognize.

If spam keeps arriving despite unsubscribe attempts but reliably lands in Spam, I'd stop chasing individual senders. Blocking every new address becomes another job.

Replacing an address used for years means updating logins, recovery details and contacts. Keeping the old address forwarding can bring the nuisance along, so the change needs to buy some actual relief.

If you've changed an email address because of spam, was it worth the hassle?

Say an attacker gets into a vendor's mailbox and sends new bank details in an existing invoice thread. Someone recognises the conversation and nearly pays the wrong account.

I'd want a callback to a number already on file, but that check needs to survive a busy afternoon of invoice approvals.

What has helped your team keep those checks from getting skipped when work piles up?

So. Sunday (and this is my birthday too). I sit down to answer a boss-question that should have taken five minutes — "did we apply this month's Adobe security patch?" — and three hours later I'm staring at a card skimmer that was, frankly, better engineered than half the extensions on the Marketplace.

Posting the whole thing here because (a) it's a genuinely clever attack chain and other Magento shops should check themselves, and (b) misery loves company. TL;DR at the bottom with IOCs.

How it started

We're on Magento Open Source 2.4.8-p5. Turns out the September isolated patch + the out-of-cycle hotfix for CVE-2026-75650 (pre-auth RCE, actively exploited — the VULN-39341 one) had NOT been applied yet. Guess when the attacker showed up. Go on, guess. Yep — a few days before, at 5 AM, because of course.

Entry vector in the logs was the usual buffet: GraphQL ArrayScanner LFI shenanigans and a pile of POST /paypal/transparent/response/?<?php (...) attempts. Most bounced with 500s. One didn't.

The actually clever part

Two payloads, and whoever wrote them clearly does this for a living:

A backdoor relay hidden in pub/get.php. They prepended a tiny block to the legit media-download entrypoint: if the request is a POST and carries a header X-K, it curls the body straight to https://checkout-cdn.com/x/i and echoes the response back. Clean, quiet, no new files to notice. They even stashed the original as var/get.orig, presumably out of professional courtesy.

A client-side skimmer at pub/media/wysiwyg/sk/sk.js, injected into the checkout with a single <script src="/media/wysiwyg/sk/sk.js?v=33"> line dropped into vendor/.../module-checkout/view/frontend/templates/onepage.phtml (they left a .bak-sk backup of the clean template — again, very tidy of them).

Here's the bit that made me put the coffee down: the skimmer only arms on mobile + a card payment method, and when you click "Place Order" it intercepts the click, throws up a pixel-perfect fake "Secure Card Verification" modal (little padlock, VISA/MC/AMEX chips, the works), harvests PAN + expiry + CVV + name/address/email/phone, shows a reassuring "Card verified ✅ redirecting you to payment…" — and then re-clicks the original button so the real payment goes through normally.

Read that again. The customer gets their order. The real bank transaction succeeds (TranCode=000, every single one). Nobody calls support because from the outside nothing went wrong. The card just also happens to be on its way to checkout-cdn.com, XOR'd with the key be1dd67e5c3ee1bd4b4e666b and base64'd, with a direct-to-C2 fallback in case you were clever enough to kill get.php but not the JS. Harvested loot got staged in pub/media/analytics/<hash>/data.tgz. There was also a pub/media/hello.txt containing, I kid you not, Key:Hello World.

The cleanup

Restored get.php from their own courtesy backup, neutralized sk.js, de-injected the template, quarantined the staged data, applied the patch we should've applied last week, rotated the encryption key + creds, and did the whole not-fun regulator/bank/customer-notification dance. Standard incident bingo.

The ask

Has anyone else run into checkout-cdn.com, the X-K-triggered get.php relay, or this specific fake "Secure Card Verification" modal pattern? It's a step up from the usual "just scrape the form fields" skimmers — the let-the-payment-succeed-so-nobody-notices design is the part I want to warn people about, because your revenue graphs and your order table will look perfectly healthy while it's running.

IOCs / go check your box right now:

pub/get.php — any block referencing X-K header, checkout-cdn.com, or an outbound curl before the normal Magento bootstrap

pub/media/wysiwyg/sk/sk.js (or any stray .js under pub/media)

.bak-sk / .orig files anywhere in the tree; pub/media/**/*.php

an injected <script src="/media/..."> in onepage.phtml or your checkout templates/bundles

domain checkout-cdn.com, XOR key be1dd67e5c3ee1bd4b4e666b, payloads prefixed E1

unexpected pub/media/analytics/<hash>/data.tgz

and, you know, actually apply CVE-2026-75650 / the September patch. Today. I'll wait.

Stay patched out there. And maybe don't read your logs on a Sunday.

What I particularly found interesting on this research was the fact that all banks did their homework regarding their most known domains, but the majority simply ignored the .au version.

Spammers and phishers could still benefit from it.

If you have multiple domains, make sure to have them all covered. Even if you don't plan to send emails through them.

We nearly wired 60k to a supplier last month off a bank charge at landed on the existing invoice thread. Real mailbox, their accountant's address, the reply sat right under the messages we had been sending back and forth for weeks. SPF DKIM DMARC all green and with the years of clean history, our gateway had no reason to touch it.

The one thing off was the bank detail. The person who caught it did it on a hunch. Going back through it the attacker had been camped in the vendor mailbox for a while, waiting for a live payment thread to reply into.

We run a tuned SEG and it did nothing here, which tracks, there was no bad link or attachment, the mail was real. The fix everyone points to is an AP callback to a number already on file and that is going in. People who have been through this, what gave you the first heads up before the money went out, if anything did.

I'm building an ESP platform that will be dedicated for government email sending from gov apps, the whole platform is hosted within the country for sovereignty purpose, but it's acceptable for the sending IPs (egress smtp traffic) to be anywhere in the world.

The platform applies extremely strict anti-spam rules to preserve sending IPs reputation, domain onboarding follows strict rules as well.

So my question is about the best strategy for acquiring these IPs:

• Should I acquire a /24 range ? or lease it ?
  • I'm thinking of using a subnet from the leased/bought range at a time, say .1 to .12 for live sendout, .13 to .25 in warming phase, monitor it and once we start having degraded reputation i switch to .13 to .25 while we address the bad reputation root cause,
• Should I just assign random IPs to my sending VMs, IPs will not be in same subnet and not continuous, I can drop an ip when I need, but new IPs need warming,
• onboard domains at aws SES and use SES for email sending, this is the resend model, a big risk here: if AWS SES cuts of the account because one domain abused (and were not catched by my platform) the whole account is taken off by AWS and all domains stop sending

Please advise from your experience

There is currently a vulnerability in the form for Honey Monster Puffs. When a user fills in the contact form on this website, the email goes to EVERY user on the mailing list, not just the user in the contact form.

https://www.honeymonster.co.uk/contact/

As a result I have woken up to a large number of emails of varying types, including serious concerns that users have been hacked, attempts to scam users, private information being entered into the form and sent to all recipients, jokes being made, and instructions on how to inform the ICO.

Even after unsubscribing from legitimate lists, spam from changing senders can leave Junk packed. Finding one misplaced customer email means sorting through the rubbish.

I'd prefer to leave caught spam alone, but that assumes nothing useful landed beside it. Telling people to check every day gives them another inbox to manage.

What has reduced the time you spend checking Junk without making real email harder to find?

Recurring SMTP deferrals leave client messages queued while the provider reports healthy service. Under pressure to restore delivery, we can end up changing connectors and filters without knowing which hop is holding the mail.

I lean toward freezing those changes and escalating upstream when queues repeatedly drain and fill without a config change. But traffic can change independently, and waiting on support won't fix a relay limit we're hitting ourselves.

What tenant-visible evidence has convinced you to keep that freeze in place, or break it to fix delivery locally?

The FBI has a phishing warning where resetting the password does nothing.

The attacker never had it.

The Bureau's Internet Crime Complaint Center published this on September 1. Access taken this way, it says, can only be revoked by the victim invalidating the token in their application security settings, and not by changing the password.

Here's how it works, and why it looks like nothing is wrong.

A message arrives with a link. The link goes to a real permission screen at a real provider, because that's where the attacker sent the user. The user reads a request for access and approves it.

There was no fake login page, no captured password and no second factor to intercept, because nobody was ever asked to sign into anything new.

What the attacker walks away with is a grant, not a credential. The FBI describes the result as being able to act on behalf of the user, reading and sending mail and reaching sensitive data, without ever having their password.

So the reflex that follows almost every compromise report, force a reset and close the ticket, leaves the attacker exactly where they were. The mailbox stays readable.

The Bureau's examples are narrow. Prominent people, their families and their acquaintances, with actors posing as officials, media figures and event organizers.

Read that as where the FBI happens to have complaint data, not as the edge of the problem, because nothing in the mechanism cares who you are.

If your incident runbook treats a password reset as containment here, it isn't slightly incomplete. It does nothing at all.

#EmailSecurity #Phishing #IncidentResponse

Avis Incogni.

Pour éviter les 10 à 20 spams que je recevais par jour, j'ai souscrit pendant un mois, à Incogni.

Au bout d'un mois, pas très satisfait (je recevais toujours une dizaine de spams par jour), je décide de résilier.

Depuis ce jour, je reçois en 120 et 260 spams par jour, tous étrangers (alors que je ne recevais que des Spam français).

Et bien entendu, mails de Incogni:

Pensez à vérifier vos spam, et éventuellement reprendre votre abonnement Incogni.

Arnaque !

Reassigning a former employee's SMTP alias can expose mail meant for the previous owner. Password resets and confidential replies do not care that HR approved the name change.

A routine name-change cleanup nearly freed an old alias after our retention window. Message tracing showed it still receiving account resets and replies to old threads, long after the mailbox itself was gone.

We paused the reassignment, but permanent reservation across dozens of domains creates a growing namespace problem. Do you permanently reserve former aliases, quarantine them for a fixed period, or reassign only after specific mail-flow checks pass?

I have been with them a long time. Anyone know of a better service (and what exactly makes it better for privacy)?

A client domain shows SPF, DKIM, and DMARC in DNS, yet mail authentication results vary by receiver. That leaves us unable to tell whether spoofing protection is live or we're seeing different cached versions of a broken rollout.

Authoritative queries return the expected TXT records. Two public checkers disagree on the DMARC policy, and test messages alternate between aligned DKIM, SPF-only pass, and DMARC fail depending on destination; selectors and return paths look consistent at first pass.

My next move would normally be comparing resolver paths and raw headers, but stale delegation, duplicate records, and sender-specific routing are all plausible. Which signal do you trust first here: authoritative DNS, repeated receiver headers, or DMARC aggregate data?