Man-in-the-Middle Phishing Attack

Here’s a phishing campaign that uses a man-in-the-middle attack to defeat multi-factor authentication:

Microsoft observed a campaign that inserted an attacker-controlled proxy site between the account users and the work server they attempted to log into. When the user entered a password into the proxy site, the proxy site sent it to the real server and then relayed the real server’s response back to the user. Once the authentication was completed, the threat actor stole the session cookie the legitimate site sent, so the user doesn’t need to be reauthenticated at every new page visited. The campaign began with a phishing email with an HTML attachment leading to the proxy server.

Posted on August 25, 2022 at 6:45 AM29 Comments


Clive Robinson August 25, 2022 8:50 AM

@ ALL,

Re : Sour wine in new bottles.

This problem is an old one and is not likely to go away time soon, because of one or more of,

1, Lazyness.
2, Stupidity.
3, Poor business choices.
4, Failing to learn from history.

So a little ICT History,

Back in the early days of Online Banking they

“Authenticated the connection not the transaction.”

With the result that people had things of value stolen.

Well even though 2FA is being used, it’s only being used to,

“Authenticate the connection”

Because of stupidity, lazyness, or poor business choices or all three Microsoft are not,

“Authenticating the transaction”

Just checking for an unchanging session ticket. Which back in the early days of the Web were easily stolen due to the way POST or GET methods worked.

Seriously folks, this is in reality a Three decade old attack method, with just a couple of wrinkles to get around HTTPS usage.

In short,

1, Utterly Predictable
2, Is a known attack method
3, Has happened to MS before
4, Shows MS is happy to allow known vulnerabilities to continue indefinatelt, for probably “business reasons”.

Which is why using the cloud for user activities is still a realy bad idea security wise, and will continue to be so, for quite a long time to come.

But hey, don’t let me stop people making the same mistake endlessly…

I’m unkikeky to be around in another three decades, but what is the betting the same mistake will continue to happen even then?

Clive Robinson August 25, 2022 9:31 AM

@ ALL,

The ARS article written by Dan Goodin, as well as some of the comments are “barking up the wrong tree” when it comes to a solution to this vulnarability.

For instance look for,

“I’m David Turner, Director of Standards Development at the FIDO Alliance. I think I can answer your question.”

He then goes on to only talk about how a 2FA token will make setting up the “man in the middle” harder. That is make the “connection” harder not the “transaction” vulnerability which remains unchanged…

So it in no way solves the real problem which remains at Microsoft’s servers…

To see why, if I put a “Man in the middle” attack on a network router either just upstream of you or the cloud server then I can still get at the “transaction ticket” so can make the attack work again…

The only solution that will work is as I’ve said for decades now,

“Authenticate the transaction.”

Which has to be done on Microsft’s servers.

The reason nobody is talking about it is probably because it is a hard problem to solve with our current technology design and usage.

Worse any solution will have serious “privacy” implications. Which might be acceptable to your employers managment.

But what about your “Privacy” as an individual?

Oh and remember if you read inbetween the lines a little, you can be set up for all sorts of crimes and be blackmailed.

For instance an early form of blackmail attack was to hide some sexualy explicit if not criminal images on your harddrive, then demand money…

This attack as the ARS and Microsoft articles mention alows the attacker to hide received Emails marked as read on your account. That is the attacker can send you stuff from a highly questionable sexplotation site and make it look like you’ve not just read them but viewed the images repeatedly as well…

Just one of very many ways you can be attacked via cloud services where,

“Transactions are not correctly authenticated.”

And people wonder why I don’t have Social Media, Email or similar and don’t use cloud based services…

Matt August 25, 2022 10:01 AM

“The reason nobody is talking about it is probably because it is a hard problem to solve with our current technology design and usage.”

Think you could provide an actual practical solution suggestion instead of ranting about how everyone else is stupider than you?

Winter August 25, 2022 10:57 AM


Think you could provide an actual practical solution suggestion instead of ranting about how everyone else is stupider than you?

When I visit a fake site, my password safe will refuse to give my credentials. Why do companies not require the use of a protection layer that checks the addresses of the landing site? MS will have certificates for everything.

I know Google Chrome does check all Google certificates if you try to log into Google. Why does Edge not do this?

Tricia August 25, 2022 10:58 AM

@ Clive Robinson,

So it in no way solves the real problem which remains at Microsoft’s servers…

I don’t really agree with that.

The article’s screenshots reminded me of a former employer. At some point, without advance notice, we started getting emailed links (to company policies etc.) via some Microsoft domain. I opened the link in a VM and it prompted me for a company login! Looking more closely at the page—exactly the page from the Ars screenshot—I saw that it was only asking for an e-mail address, not a password; when I gave a company email address, it redirected me back to a login page on our intranet. I e-mailed the information security department, saying basically “what the fuck? I think this might be legitimate, but it’s exactly a ‘phishing’ workflow and you guys are gonna be dealing with fallout eventually.” They told me not to worry, ’cause if I look closely it’s actually a secure internal page requesting my password, and it would redirect me back to the Microsoft service after it’s done. Kind of missing the point—how many other employees would notice such a minor thing, in a workflow with at least 2 redirects involving an external service nobody’d even told us about? And… it’s an external service just to give us a damn PDF file? (And of course I had to turn on Javascript, ’cause it’s not like we had some self-hosted technology to accept login data and return a binary file before 1995…)

The same group would often bitch about how many people failed the periodic phishing tests. Which looked and worked just like the company policy training emails, and some other official ones, similarly redirecting to a site we’d never heard of that wanted a password. (So, I reported all of these as phishing to the security people, and they’d tell me which were legitimate.) They should’ve asked Microsoft to temporarily put a password field on the first login page, to see how many people would just give their company password directly to MS. I bet it would be more than 90%. Hell, why not put the 2FA box right there too?

The particularly crazy thing was that a few of the intranet web servers had Kerberos authentication enabled (via RFC4559, I think), so with proper browser configuration wouldn’t even prompt for a password. It worked for this MS login flow, and IMAP/SMTP too—a great example of where improving security can also improve usability. But the default OS installation didn’t configure any browser that way, and most of the intranet servers didn’t support it, and I couldn’t persuade the security people to change either of those things. Anyway, I never heard of any other person in the company even trying to use that login method, despite my repeatedly preaching about it.

Honestly, I’m shocked that it apparently took upwards of 5 years for the criminals to notice what was immediately obvious to me. Or took that long for security people to notice that the criminals had noticed.

The “real problem”, as I see it, is that nobody really seems to give a shit. At least at that company, with respect to security, everyone was just doing the minimum to make stuff work and not get fired. Nobody was thinking about overall user experience (like having to re-enter the ostensibly “single sign-on” password all day whenever some intranet server asks) and its effect on security. VPN login was the only place we needed a 2-factor-authentication code. I’ll bet it was only because someone said it was a “best practice”, and they’ll add 2FA to the Kerberos login only when some auditor or book says the same about that (or when some update of the Microsoft Active Directory software strongly pushes administrators to enable it—like a non-evil version of the Windows installer forcing people to create Microsoft accounts unless they disconnect from the internet first). And users will probably still need to re-enter the exact same data when they start the VPN.

Clive Robinson August 25, 2022 11:20 AM

@ Matt,

You have a question and an insult…

To answer your question of,

“Think you could provide an actual practical solution suggestion”

I already have on this back in the late 1990’s, and have mentioned it before on this blog repeatedly, including how one attempt trying not to use a token device failed[1].

What you need is an “authentication chain” that includes,

1, The human.
2, A Token.

The token generates a session sensitive continuously changing authentication token rather than Microsoft’s pointless session independent fixed token.

To include the human in the chain you have to provide a positive action on their input, that has minimal load on them.

One way to start addressing this problem is to seperate the user interface devices (keyboard, screen etc) from the communications interface device (computer) and have the transaction authentication token sit between them.

The nearest we have in moderate usage so far is keyboards with Smart Card interfaces where the key presses are encrypted through the smart card. The trouble is it generally is only used to authenticate a login which is back to authenticating the connection, not the individual transactions.

Extending it to include the transactions could be relatively trivial but secure once the token has been properly placed in the chain.

I hope that answers your question?

P.S. As for your insult, you do not need to insult me for me to give you an answer just a polite enquiry is usually more than sufficient. Also when you think about it, many other readers here know that. So in effect you are diminishing your own standing in their eyes, not mine.

[1] The reason we need a token is the failing of the human mind, which was never designed for such activities. Very few of us can remember even a “weak password” by modern attack standards. As for calculating hashes and checking them in our heads… So I looked for something humans were reasonably adept at that computers were not. Back then “captcha” systems were new and computer image recognition poor, so it looked like a potential way out of having to use a token. What I had not reconed on was in effect “slave usage” of the human mind as a “mechanical turk”. It was economically viable to sit a person infront of a computer in China and forward the captcha image to them and have them solve it in near real time. These days computer image recognition is more than sufficient for the original captcha images. I suspect it’s also now sufficient for the likes of Googles reCAPTCHA images as well.

fib August 25, 2022 1:22 PM

@ Clive Robinson

Some sources present transaction authentication as having to do with a greater user involvement in the process [or awareness, if you prefer]. The process then would be based on ‘something you understand’ [0]

Transaction Authentication – the new factor for factor-based authentication – as a way to establish informed consent in the authentication and authorization process for online security.

However, you seem to refer to a programatic token that is constantly updated during the session – ie dynamically?

Micrapsoft does offer what they call “Primary Refresh Token”[1], but I don’t think that’s what you’re talking about. Btw, across the Internet you see people referring loosely and interchangeably the processes of connection, transaction.

I hate to show my ignorance on certain subjects, but I would like to know more about it.




lurker August 25, 2022 1:45 PM

The Ars headline is a giveaway:

Ongoing phishing campaign can hack you even when you’re protected with MFA

If MFA is to be a silver bullet it has to be used properly. This attack looks like it could be adaptable to gmail.

re Chrome checking Google Certificates,

I used a mail client that checked certs, and told me when they changed. Google declared that app unwelcome.

AlanS August 25, 2022 2:45 PM


What you need is an “authentication chain” that includes,
1, The human.
2, A Token.
The token generates a session sensitive continuously changing authentication token rather than Microsoft’s pointless session independent fixed token.

Unless I am missing something, can’t FIDO security keys sort of work that way anyway? On Bank of America’s site the security key isn’t just for login but also some transactions after you are logged in. If you want to add a transfer recipient then you have to authorize it by touching the key again which will involve a different challenge response than the original login. (None of these authentications will work with MitM.)

Whatever the case, I think it is important to not let the perfect be the enemy of the good. FIDO is better that most other options and will no doubt continue to develop as attacks evolve but most sites and users are still using much weaker forms of MFA that are readily susceptible to phishing and other types of attacks because they depend on shared secrets.

Gabriel August 25, 2022 3:22 PM

And then we have tools like MSxTeams or some mobile apps, we the user is unable to validate the visited url, if it’s from Teams and authenticating against MS AD or not.

AlanS August 25, 2022 4:54 PM

Microsoft (July 2022): From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud:

The AiTM phishing process can currently be automated using open-source phishing toolkits and other online resources. Among the widely-used kits include Evilginx2, Modlishka, and Muraena.

Which makes this Microsoft analysis back in late 2019 interesting. They discuss Modlishka and the relative effectiveness (or lack thereof) of different types of MFA in preventing this type of attack: All your creds are belong to us! The analysis and comparison are quite good but the conclusion is bat-shit crazy:

Given an overall strong authentication rate of only about 10%, doing any form of MFA takes you out of reach of most attacks. MFA (using any mechanism) is just too costly to break – unless a highly motivated attacker is after that high value account or asset. [emphasis in original]

. A few paragraphs earlier they had written:

Tools like Modlishka are making it easy

At the time Evilginx was already in existence as well. (The presentation linked to in my earlier post above was just a couple of months after this blog post.) So not “too costly to break”. The cost of doing this type of sophisticated phishing at the time of this post in 2019 was already essentially zero. It was available to any script kiddie; not just a “highly motivated attacker”. But no urgency for phishing-resistant MFA?!

Clive Robinson August 25, 2022 5:25 PM

@ AlanS,

Re : trandaction authentication

“On Bank of America’s site the security key isn’t just for login but also some transactions after you are logged in.”

All authentication processes can be used over and over again. Obviously something that is data visable to an attacker is effectively worthless. Which is what the MITM Attack does.

Worse if the authenticating token is
invarient and not tied to the data as is the case with Microsoft’s system, then an attacker can just jump in when a sessionless protocol like HTTP(S) is used.

But transaction level authentication has to be supported correctly by the server. Microsoft does not do this.

The simplest way to do primative authenticate of all transactions in the communications channel is to use nested encryption channels,

1, Authenticate the outer channel using what ever 2FA system you have.
2, Then use a “shared secret” to make a new unique encryption key and initialisation vector pair.
3, Set up a CBC encrypted communications channel inside the outer channel and send one or more “numbers used once”(nonces) down it.


A, Shared secret is never disclosed.
B, Key and IV generation process is secure.
C, Client and server are secure.

Any MITM attack fails as you switch to using the inner encrypted channel after step 3.

But the reality is the encryption is not authenticating transactions but the communications within a communications channel[1] In effect it is authenticating all traffic but weakly as it is vulnerable to certain attacks so is not as strong as it could be.

The service provider needs to decide what a single transaction is and additionally use crypto hashes as part of “Secure Transaction Authentication Codes”(STACs) for each one.

Whilst it can be hard to get your head around a written description, making a drawing of it usually makes understanding easy.

[1] language can be fun… A “communications channel” carries “communications” in exactly the same way a “water pipe” carries “water”. But it should be obvious a “water pipe” is not “water”. Only as a communications channel actually is an information carrier you can nest communications channels inside other communications channels as many deep as you like.

AlanS August 25, 2022 8:36 PM


“it can be hard to get your head around a written description”

Yes, I may need Tylenol!

The MitM attack using Evilginx (or similar) just doesn’t work from the very beginning in this case if you are using U2F or Webauthn because the challenge-response detects the MitM. Well, your username and password are captured but the MFA fails and you instantly know your password has been compromised and needs to be changed. The water never starts to flow because the pipe is never opened. The problem with the sites that do support these protocols is that most of them allow and require that SMS and OTP MFA are retained as options/fallbacks.

“The shared secret is never disclosed”. I think it is the nature of shared secrets that they are often disclosed.

Ted August 25, 2022 10:17 PM

From Microsoft’s blog post:

…The following days after the cookie theft, the attacker accessed finance-related emails and file attachments files every few hours.

Do Microsoft services (Azure Active Directory, Outlook online, Outlook Web App) not use session cookies with expiration attributes? Is this how attackers are able to gain access days later?

A Bleeping Computer article said attackers could add their own MFA device to an account as soon as they got access. Then even if a session cookie expired, they would still have the username, password, and a linked MFA device.

Other than this, Microsoft seems to offer a plethora of mitigation suggestions.

Markc August 26, 2022 4:22 AM

Amazing that this is still a problem today. As @Clive says this is an old problem that was solved ages ago. We discussed this on this forum several times over a decade ago. It can be solved with the aid of a dedicated hardware security device that has its own UI.

Ha ha, I think my old gadget idea is still applicable today. For anyone interested there is a non-paywall link if you search for “in-the-wire authentication”

Essentially the idea was a USB gadget that controlled the computer’s TLS connections (like a proxy). It provided UI for entering passwords, account numbers, etc. directly on the gadget allowing “in-the-wire” authentication directly with the service provider.

Clive Robinson August 26, 2022 4:22 AM

@ Ted,

Re : Suggestions ar not solutions.

“Microsoft seems to offer a plethora of mitigation suggestions.”

But what do they mitigate?

Currently our entire security struccture rests on the notion of “shared secrets” also called a “root of trust”.

Authentication between two parties when analysed is a multi-step process.

Anything prior to the correct use of a shared secret is vulnerable to a variety of “man in the middle attacks”.

Security even after the correct use of a shared secret is at best only ever conditional.

One issue is obviously the shared secret becoming known in some way.

One way is for the plaintext of the shared secret to become visable to an attacker.

Back in the very early days of networking the Telnet protocol was used. This was a plaintext protocol therefore the users “username” and “password” were seen as plaintext on the wire.

Later the VNC protocol used DES encryption. But whilst the plaintext was nolonger directly visable on the wire the VNC prorocol used the same embedded crypto key. So even though the plaintext was not on the wire it was trivially recoverable.

People changed VNC to alow the crypto key to be changed, but this is a difficult problem to solve with a gotcha in it.

A multiuser system has no way to know who is connecting to the system untill they securely identify themselves. Thus this first step has no shared secret and is vulnerable to a man in the middle attack and is not secure by definition.

How do you establish a secure connection. Well one way is with a game of encryption ping pong.

In the simplest case anyone can claim to be jo1234 but if jo1234 and the system share a secret then that can be established by a challenge and response protocol. Lets assume the shared secret is used as an encryption key. The system encrypts a piece of plaintext and sends it to the user as a challenge. The user decrypts the challenge and performs some transform on it and returns it to the system as a response. If it’s returned as plaintext then an evesdropper can see it and over time work out any correlation such as if the server only has a repertoire of say six different challenges for the user. But the same applies even with an encrypted response if the encryption is used incorrectly (as it often has been).

But also consider another issue that of temporal divides. If you were using a plaintext protocol or weak ciphertext protocol then switch to a strong protocal later, but do not change the shared secret at the same time… Then an attacker can carry forward the fact that they know the shared secret even though the strong protocol would stop them finding it.

I could go on with a long long list of such issues but I think I’ve made the point that they are there in great number and some can be not immediately obviouse.

Now remember a mitigation is not a solution, but a work around. As a general case a mitigation only works around a single instance of a vulnarability, not a class of vulnarabilities or multiple classes of vulnerabilities.

As I pointed out there are two known vulnarabilities in this attack,

1, Man in the middle
2, Invarient token

Both are actually “class vulnarabilities” with an unknown number of attack instances possible.

Mitigating one instance of just one class is not going to solve the problem.

You need correct solutions to both classes of vulnarability.

What's in a name August 26, 2022 6:05 AM

Never follow links in an email.

Even if it’s a company you do business with, go to their site from your bookmark or by typing into the url box or by using your password manager. Never by the link in an email.

AlanS August 26, 2022 8:36 AM


Currently our entire security struccture rests on the notion of “shared secrets”

Which is, of course, hugely problematic and why FIDO doesn’t use shared secrets and has defenses against extraction and cloning.

SpaceLifeForm August 28, 2022 3:05 PM

@ AlanS

The FIDO key may be secured, but that does not prevent the MITM.

If the networking implementation does not force per-transaction authentication, then having a session cookie becomes problematic with a MITM.

Even if the authentication is forced per transaction (eliminating session cookies), it does not preclude a MITM winning a race.

Ultimately, you must trust the TLS to not fail. I do not believe one can trust that.

It is all Security Theatre. Cash is King.

Clive Robinson August 28, 2022 9:25 PM

@ SpaceLifeForm, AlanS, ALL,

“Ultimately, you must trust the TLS to not fail. I do not believe one can trust that.”

To trust a TLS you require as a minimum “reliable”[1],

1, End to End Encryption (E2EE)
2, A route of trust (shared secret)
3, A plaintext protection mechanism.
4, A ciphertext protection mechanism

You also need “reliable”,

5, User Interface issolation.
6, Communications interface issolation.

If any are “unreliable”[1] then no you can not trust it.

The simple fact is none of the systems we use today are even remotely close to being side channel free[2], which has significant implications[3] in how we currently operate.

The simple fact is if we wish to be secure we need a major “Change in sea state” to the way we behave, and the resistance will be significant.

For one thing it means ditching nearly all “cloud” or “XXX as a Service”(XaaS) systems. Which is happening in a very limited way with “edge” or “fog” computing architectures which almost go back to the ideas of “data warehousing”.

[1] Reliable means a lot more than theoretical security, it means implementation and use security. For instance AES as an algorithm is theoreticaly secure to some measure. But at one point most implementations of the AES algorithm had significant side channel issues[2] that leaked information. Likewise the modes AES have been used in have had similar issues. But as we now know there are real issues in the CPU hardware and below that have introduced other significant side channels. Thus it is safe to assume there are still side channels to yet be found, therefore any encryption system is “unreliable” and should be fully mitigated.

[2] Most of the side channels we have found so far are time based and mainly due to pitching “Efficiency -v- Security” during design. But it’s not just “time based” side channels there are others based around a number of energy transport domains, of which the most known is the “Power Domain” but there are still others yet to be exploited. It’s why I talk about using Cryptography in fully “Off-line” mode where you only do encryption functions on an “unconnected system” that is fully issolated (Energy Gapped). Then shift files (data at rest) across the issolation barrier to an “On-line” system for onwards communications. That way the encryption and decryption can not leak information by side channels.

[3] The problem is that nearly all web systems have be designed to be used in “on-line” mode for transactions and that is bad for security and always will be. Especially with OS’s so weak that all security can be bypassed by simply getting at the user interface in an “end run attack” around the security end point. Which is why as I’ve said earlier and back into the last century the “token” needs to issolate the User Interface from the Communications interface.

AlanS August 30, 2022 11:34 AM


Point taken. But the practical reality at the moment is that FIDO (unlike nearly all other forms of MFA) is highly effective against current MitM phishing attacks. That might not always be the case. I am sure the attacks will evolve.

Cloudflare’s discussion of a current phishing campaign: The mechanics of a sophisticated phishing scam and how we stopped it

We confirmed that three Cloudflare employees fell for the phishing message and entered their credentials. However, Cloudflare does not use TOTP codes. Instead, every employee at the company is issued a FIDO2-compliant security key from a vendor like YubiKey. Since the hard keys are tied to users and implement origin binding, even a sophisticated, real-time phishing operation like this cannot gather the information necessary to log in to any of our systems. While the attacker attempted to log in to our systems with the compromised username and password credentials, they could not get past the hard key requirement….Like Google, we have not seen any successful phishing attacks since rolling hard keys out.

Other companies not using FIDO security keys did not fare so well.

Also, as I think it was mentioned earlier but there is nothing to stop a website from requiring FIDO for transaction confirmation. (e.g. money transfers to external accounts) within an authorized session. If the session was compromised through a TLS or some other means, a transaction confirmation requirement could severely limit what the attacker could do. The FIDO Alliance have a white paper on transaction confirmation:

The European Banking Authority (EBA) Payment Services Directive 2 (PSD2) mandates Strong Customer Authentication (SCA) for all remote transactions that are more than EUR 30. SCA requires the use of dynamic linking, which means multifactor authentication at the transaction, not just the session. This ensures that the authentication elements dynamically link the transaction to an amount and a payee specified by the payer when initiating the transaction. FIDO Transaction Confirmation can directly address this need. In particular, FIDO Transaction Confirmation enables securely displaying transaction details (amount and payee) during all phases of an online payment as it is mandated by the PSD2 Regulatory Technical Standards (RTS)….

A variety of attacks including man-in-the-browser, remote Trojans, cross-site scripts, JavaScript injection, and session hijacking can be used to create or manipulate transactions. The consumer cannot easily detect these attacks, so they think they are safe, but they can be tricked into paying the wrong amount or paying the wrong party. For example, banking Trojans like Anubis or Panda can provide remote access to an account holder’s system and allow an attacker to initiate a payment in an existing session. Transaction Confirmation should thwart these attacks by binding the authentication to the transaction through a user gesture and letting the consumer trust the amount and payee.

SpaceLifeForm August 30, 2022 4:27 PM

@ AlanS, Clive, ALL

I totally agree that using FIDO2 is a good thing. It helps you not become low hanging fruit for the attackers.

Like Cisco and Twilio, and SMS Fatigue.

I still can not believe that one can fall for SMS Fatigue if one is in a network security role. I am not buying that excuse. If you keep getting SMS asking you to verify your account, that should be a huge red flag. You call your NOC if you are trying to sleep, and find out what the hell is going on.

You verify.

If you can not do that, no matter how tired or hungover you are, then you should be fired. Flat out. Full Stop.

There is absolutely no excuse to ignore your role. You need to be the Canary in the coal mine.

That said, I hope you realize that CloudFlare is a de facto MITM.




AlanS August 30, 2022 5:58 PM



MitM is everywhere. Media moguls either of the old type, like Murdoch, or the new type, like Zuckerberg, insert themselves in the middle as power brokers. Murdock’s companies, of course literally hacked phones to intercept private messages, but in the broader sense it’s about controlling the messaging, as the old headline put it, “It’s the Sun Wot Won It”.

lurker August 30, 2022 6:25 PM

@SpaceLifeForm, All
re SMS & other so-called 2FA

I had been doing business with an outfit who were quite happy to accept me as an anonymous user. Foolishly I thought an account with them might simplify transactions. Now whenever I want to log in, they send me a verification code by email, “to ensure it really is your computer logging in.” ???

SpaceLifeForm August 31, 2022 2:57 PM

@ lurker

You screwed up, sorry to say. You were never anonymous in the first place once you used used your credit card. At some point, you gave them your email addy. Boom, you now have given them more correlated data, they know who you are, where you live, and then you will likely see UCE, customized with your name and address, just to appear legit.

If you did not get UCE after that, consider yourself lucky. Maybe the vendor is actually trustable. But, that may not last.

The bad actors want your phone number and/or email. Do not give them out for just any old excuse or reason. Always ask yourself, why do they need this?

Cash is King.

Recently, I was carded for a purchase. With cash. The clerks knew me by sight, and knew I was over 21.

This particular store had been pushing a rewards program for about a year. I always decline rewards programs. Apparently, it was not working out for them in a profitable manner.

So, they asked me for ID. I asked, when did this start? Answer: Today.

I should have walked out. The clerk scanned my ID (DL), and never even looked at it.

They collected my PII. It had nothing to do with age verification. It is about collecting PII and selling it to data brokers.

Needless to say, I have not been back and will never go there again. They have lost my business.

Your PII is probably worth $1K per year, minimum.

lurker August 31, 2022 6:57 PM


Regardless of the hard setting on my spam filter, I accept spam from these guys because I find it interesting. What’s less amusing and more annoying is the use of email as a pseudo 2FA.

Leave a comment


Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via

Sidebar photo of Bruce Schneier by Joe MacInnis.