Please STOP trusting email.

It is now Anno Domini 2025, and for some reason, people keep trusting email. That needs to stop. Let’s talk about why–but first, let’s talk about why I’m telling you this now.

All things happen in cycles, including grifting. And folks, we are at an absolute peak of griftitude right now, similar to the days of snake oil peddlers traveling town to town and selling bottled garbage from the back of a wagon.

One type of fraud that’s peaking right now is payroll/escrow fraud, and it depends very much on people trusting email for things they shouldn’t. It’s an easy grift with a decent success rate and potentially massive payoffs.

Anatomy of an email-based grift

First, you discover an existing payer/payee relationship. This is usually public information and not all that hard to figure out. For example, you might discover that Architect A won a public bid for a construction project. That project will usually have publicly disclosed target dates for completion of various stages as well as the project as a whole–if a stage is nearing completion, this is a potential target, so you do a little more research.

Next, you discover that Architect A is using electrical vendor B to handle the lighting. Typically, the architectural firm gets paid first, and subs out the rest of the contractors. So now, you want to figure out who the accounts payable and receivable folks are at both A and B–again, usually publicly accessible information, not hard to figure out.

Now, you’d like to actually compromise somebody at either A or B, and both if possible. If you can manage it, your odds get a lot better, and you might be able to figure out a way to score bigger and possibly multiple payoffs. But it’s not strictly necessary. Let’s say you were not able to get into the actual email of anybody at either firm–you’re still in the ball game, no worries.

Next step, you know that the lighting for the project is done, and you know who accounts receivable at electrical engineer B is, and who the accounts payable at architect A is. So, you spoof some email from B to A. First, you say that B’s banking information has changed–and you “correct” it to a short-lived account you’re using for the grift.

If you timed it right–and if the accounts payable person at A is a useful idiot–the payment for engineering firm B winds up in your own account, and you immediately move the funds out of that account to someplace offshore and crime-friendly. If it takes more than 48 hours for A and/or B to figure out the money went to the wrong place, you’re home free–they can’t get the funds back, once they’ve moved offshore.

This doesn’t need to be an architect and an engineering sub–another common example is real estate firms and closing attorneys. Real estate sales are also publicly posted data, and you can impersonate a real estate firm and ask the closing attorney to wire the escrow (money put down prior to a purchase completing) to a different bank account. It’s the same grift, with the same potentially enormous one-time payout.

The same technique works for payroll

For construction projects, this can be a single score worth potentially millions of dollars. But what if you got some intel on a business that isn’t a construction, architectural, or real estate related business?

No problem–you’ll need to downshift and look for a smaller payout, but payroll fraud works the same way and requires even less research.

All you need for this one is to know who handles the payroll for a business, and who grants bonuses in a business. Now you impersonate the person authorized to grant bonuses, email the payroll person, and authorize a bonus–usually between $3,000 and $10,000–to one or more employees.

Since you already impersonated those employees and changed their ACH target the day before, those several-thousand dollar “bonuses” go to you, not the employees… who weren’t expecting a bonus, and therefore don’t get alerted by it not showing up.

Generally speaking, you target this one in between paydays, because an individual employee who doesn’t get a paycheck they’re expecting will ring the alarm fast.

Impersonation is incredibly easy

It’s tempting to think this is super high tech information security stuff, but it’s anything but–because email was never designed as a secure protocol in the first place.

Let’s look at physical, postal mail first. What happens if you write “President of the United States of America, 1600 Pennsylvania Ave, Washington DC 20500” in the upper left corner of the envelope?

Your letter gets delivered, is what happens. The postal office does not attempt to verify the “return address” in any way whatsoever–it’s not a form of authentication. It’s on you to realize that this dinky little envelope with a kitten stamp and a postmark from Slapout, AL did not actually originate in the Oval Office.

Email works the same way! Anybody can write anything they like in the FROM: section of an email. It is not validated, in any way, period. If you blindly trust an email based on the FROM: you are making the same mistake as somebody who blindly trusts a postal letter based on what’s scrawled in the upper left corner of the envelope.

Infiltration isn’t that much harder

So far, we’ve talked about how grifters can separate fools from thousands or millions of dollars with nothing but publicly available information–and that is, by far, the most common form of grift in my experience as a very senior IT person.

An advanced attacker might aim a little further north, though, and try to genuinely compromise a target’s email account. If the attacker can gain control of a target’s email account, the attacker can now gain access to private information which makes that crucial attack scheduling far more accurate.

In our first example, we were banking that electrical firm B will have completed the lighting phase of the project on the stated date when the building plans were first announced. If that date slipped badly–or, wonder of wonders, the firm finished early–the critical email to change the ACH target might arrive too early (and be discovered) or too late (and the payment was already made).

But if the attacker can actually compromise the accounts receivable person–or a C-level–at electrical firm B, the attacker can just monitor that email and wait to act until the exact right time. The attempt is also more likely to succeed because even a paranoid IT expert can verify that the email came from the legitimate account of the target–but the improvement in timing the attack is frankly far more important than the improvement in “legitimacy” of the attack itself.

How can I verify that an email is legitimate?

If you’re expecting a bunch of highly technical stuff about email headers, I’m going to disappoint you–because the correct answer is “you can’t.”

Yes, a sufficiently cautious and well-informed person can first force their mail client to display the normally-hidden message headers, then verify each step the message has taken across the internet. (This is the electronic version of reading all the postmarks on a physical envelope.)

However, the vast majority of targets are neither sufficiently cautious nor sufficiently well-informed, nor will they ever be. And more importantly, while this sort of sleuthery might be accurate enough to tell you whether a message came from a particular server, it can’t tell you anything about whether the message originated with the human it should have.

So the real answer here is, when money is on the line, don’t trust email. If you get an email asking you to move a significant amount of money, or to give someone access to an account (banking, telephone, online gaming, email, or anything else) you’d be upset at losing control over, don’t do it–instead, call that person, ask to speak to an actual human, and verify the legitimacy of the request.

And, this is important… don’t use the contents of the email to contact that person or organization. If you don’t already know their phone number, website address, etc–close the email, look the contact information up from scratch, then contact them that way to inquire about the validity of the message you received.

How do I protect myself from being scammed?

We’ve already covered “you shouldn’t trust email,” so we won’t belabor that point… but we will now point out that you need to make sure that the other people you associate with aren’t trusting “your” emails either.

If you’re responsible for the movement of significant amounts of money on a regular basis, check the policies of the people and the firms who you expect to pay or to be paid. Make sure they know–preferably, in writing–that you will not act on unverified email instructions, and that you will not issue unverified email instructions either.

This is important, because an entity that screws up and sends your money somewhere else based on an email “from” you will frequently try to make it your problem. As far as they’re concerned, they sent that $10,000 somewhere, so they “paid” and if you didn’t get it, well “that’s on you.”

You might be thinking “well, that’s obviously stupid.” Sure, sometimes it’s obviously stupid. Other times, it’s obviously dishonest. Either way, if you don’t have a written policy statement on file that you will not be held responsible for actions taken on unverified email, you might be left on the hook–and court actions will typically cost more than the amount of money in play, so you don’t want to rely on litigation as a solution here.

 

 

TPM errors in Windows 11

The last several machines I’ve built–and several long-running machines with nothing wrong with them–have suddenly started displaying strange errors regarding Microsoft 365. The affected machines can neither register Office365 apps to the entire machine successfully, nor will they accept user logins to the Outlook desktop app.

Although you don’t get any obvious errors when Outlook refuses to accept a valid password–confirmed by entering the same password successfully to log into Outlook on the Web in the same machine’s browser–scouring Event Viewer carefully enough will lead you to notice TPM related warnings and errors in the System log, occurring each time you attempt to log into desktop Outlook or attempt to register Office365 apps globally.

The extremely poorly documented actual fix requires at least one and sometimes up to three steps, followed by a reboot. If you want to perform all three steps pre-emptively then reboot, fine–but if you find you need to perform more steps, please realize you will need to reboot again following those additional steps!

Step one: regedit

First, you need to update two registry keys (you may save this text as a .reg file and add it to your Registry directly; the key names have been the same on the ten or so machines I’ve fixed in the last several weeks, despite looking like there might be GUIDs there):

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity\Identities]
"EnableADAL"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb]
"ProtectionPolicy"=dword:00000001

Step two: (DANGER!) clear TPM (DANGER!)

Next, consider deleting the values currently stored in your TPM. 

WARNING WARNING WARNING: if you are using Bitlocker, make certain you will still be able to decrypt the drive after destroying the secrets in your TPM! At a minimum, this means making sure you’ve got scratch codes available. If you don’t have a full backup available that you are prepared and ready to use, strongly consider decrypting the drive before destroying the data in your TPM–if you turn out not to have the scratch codes, or have the wrong scratch codes, etc etc etc, there is no turning back.

If you have decided to go ahead and clear out your TPM now, click Start, type in tpm.msc, and hit Enter. The TPM settings dialog will pop up. Click “clear TPM.” 

Again, do not blindly clear your TPM if you are using BitLocker!

Once you have decided whether or not to pre-emptively clear your TPM, reboot the system, and check to see if your Microsoft 365 woes have been resolved. If they have not, and you haven’t cleared the TPM yet, you’ll need to make arrangements to ensure safety of your data, then clear the TPM, reboot once more, and try again.

If you still have no joy after completing both steps one and two and rebooting, it’s unfortunately time for the last and most obnoxious step.

Step three: create a new, clean Windows user profile

If you’ve added the registry keys and manually cleared the TPM, then rebooted, and your Microsoft 365 login and registration problems still aren’t fixed, the problem is very likely in an undiagnosed area of your user profile.

I only needed to perform this step on two of the ten or so machines I’ve resolved these TPM errors on in the last few weeks–but on those two machines, there was no getting around it; the whole user profile had to go.

The good news is, you can test whether this is necessary before actually destroying anything! Create a new local user on your system (or log in with a different domain user which has never logged into the local system, in an Active Directory environment), log out as the current user, and log in as the brand-new user profile.

Now, try to first activate Office365, then set up Outlook to access the affected user’s email. If you already completed steps one and two, this attempt should succeed with no issues. Once you’ve successfully both registered Office 365 to the affected user’s email account, and successfully logged into that user’s email account in desktop Outlook, you know your problem really was in the original Windows user profile.

At this point, you can do one of three things. You can:

  • Either continue setting up the new Windows profile for regular use, move the user’s data to the new profile, then destroy the old profile
  • Or you can back up the user’s data, destroy the user’s old profile, create a new profile with the same username / log into Active Directory with the same user credentials, then restore the user’s data
  • Or you can get out your Mad Scientist toolkit and start feverishly trying to analyze the broken profile and figure out why it’s broken (I have had no luck with this approach, myself).

Conclusion

I don’t know what’s going on at Microsoft right now, but these TPM errors have been a plague for quite a while, and Microsoft keeps failing to either fix the issue or even provide the sort of comprehensive workaround I’m documenting here.

The good news is, despite needing to fix ten or so machines and counting so far, the majority of the affected machines were fine after nothing but Step 1 (add registry keys) and a reboot, and most of the rest were okay with only adding Step 2 (clear TPM values) and a reboot.

Again, I beg, plead, warn, scream at you: do not blindly clear the TPM without considering the impact on associated services, especially BitLocker.

Finally, of the two machines that still refused to work properly after clearing the TPM, Step 3 (blowing away the user’s Windows profile, then either manually recreating it from scratch or logging in again into an AD environment to recreate it from scratch) worked a treat.

So far, I have not encountered any machine that wouldn’t resume O365 functionality after following this guide. (Knock on wood). Good luck, fellow sysadmin or helldesk veteran, and may the Force be with you…

And please, please, please do not blindly clear the TPM without considering the consequences to associated services such as but not limited to BitLocker!

Troubleshooting Exchange 2007/2010: a quick guide

This is mostly intended for myself… but if it helps you, you’re welcome.

Exchange 2007/2010 with Outlook 2007 clients is a hellkitten to get right, and I do not say this affectionately.  You need to get RPC over HTTP working, or the Out-Of-Office Assistant will not work, and neither will the offline Address Book (or, very likely, the GAL).

In order to get RPC over HTTP working, you must have several virtual directories running right in IIS, you must have client certificates ignored on those virtual directories, you must have both Basic AND Integrated authentication on those directories, and you must have a proper SSL certificate on the site.  On a standard Exchange setup, this will be the (Default Web Site).  On an SBS setup, this will be the (SBS Web Applications) site.

Definition of “proper” SSL certificate: you must have both the internal domain name AND any external domain names ON THE SAME CERT.  If your internal domain is “domain.local” or something like that, this probably means you’re going to have to use self-signed certs (and deal with security warnings on clients outside the local domain).  If you have an FQDN, you ought to be able to get everything on one UCC certificate… you will need, at a minimum, internaldomain.com, mail.internaldomain.com, externaldomain.com, and mail.externaldomain.com.  If possible, you also want autodiscover.externaldomain.com and autodiscover.internal.com, but they aren’t strictly necessary.

Here are some incredibly brief tips toward finagling the virtual directories and the certificates.  Except where specified otherwise, these are all commandlets run from the Exchange Management Shell – there is very little you can or should be doing from the Exchange Management Console for working with these issues.

Testing from Outlook:
control-right-click the Outlook icon in the system tray, and you will have options for “Connection Status…” and “Test E-Mail Autoconfiguration…” available.  Your ultimate goal here is to get the “Test E-Mail Autoconfiguration…” option working.  If you DON’T get this working, you’re not going to have a fully functional Exchange setup, regardless of what anything in the “Connection Status…” tells you.  To get this working, you will need to have either mail.yourdommainname.com or autodiscover.yourdomainname.com both in DNS and on the SSL certificate bound to the site in IIS which hosts the virtual directories for Available Services, the OAB, UM, and OWA.  If you specified both internalurls and externalurls in your virtual directory setup, both
of them need to work properly from inside the domain or local clients will not work; you can’t really control whether they decide to use the internalurl or the externalurl, and in my experience, they will frequently choose to use the externalurl, even if they’re plugged into the same switch and sitting physically right next to the Exchange server.

If your “Testing Autoconfiguration…” comes up with failures, you’ve got problems with your certificates, your virtual directories, your settings for URLs to your virtual directories, or all three… head to the tips below to examine and troubleshoot.

A word of warning about the Exchange Management Shell:
The EMS commandlets sometimes use Uri and sometimes use Url for their argument names… so be careful; even though they both mean the same thing, you have to get the right arbitrary spelling for the right arbitrary commandlets.  (Thanks for that, Microsoft…)

Another word of warning about the EMS:
you can get away with using all lower case for the commandlets themselves, but argument names for the commandlets require CamelCase as shown in the examples below.

A third and final word of warning about the EMS:
The examples I’ve shown below are extremely terse, and assume that, once pointed to examples of working usage, you can figure out the gist of what they mean, what they do, and likely useful ways to do related things just from seeing the syntax shown.  If you don’t feel comfortably that this is the case, then for the love of working systems stop right now and hire a (more experienced) professional!

And now, on to the actual EMS usages:


test basic RPC proxy connectivity:
rpcping -t ncacn_http -s servername -o RpcProxy=proxyservername -P "user,domain,pass" -I "user,domain,pass" -H 2 -u 10 -a connect -F 3 -v 3 -E -R none
test RPC proxy through to Information Store default port on back-end:
rpcping -t ncacn_http -s servername -o RpcProxy=proxyservername -P "user,domain,pass" -I "user,domain,pass" -H 1 -F 3 -a connect -u 10 -v 3 -e 6001
test RPC proxy through to IS backend default port using Mutual auth:
RpcPing –t ncacn_http –s ExchangeMBXServer  -o RpcProxy=RpcProxyServer -P "user,domain,password" -I "user,domain,password" -H 1 –F 3 –a connect –u 10 –v 3 –e 6001 –B msstd:server_certificate_subject
test all web services:
Test-OutlookWebServices
setting the Exchange cert: (note that not all services may be installed)
enable-ExchangeCertificate -thumbprint "thumbprintfromcert" -services "IIS,IMAP,POP,SMTP,UM"
if private key is missing: get serial number from cert and…
certutil -repairstore my "serialnumberfromcert"
Autodiscover:
Get-ClientAccessServer | Select Name, *Internal* | fl
Set-ClientAccessServer -Identity servername -AutoDiscoverServiceInternalUri: https://mydomain.com/Autodiscover/Autodiscover.xml
OAB:

in EMS, Server Configuration -> Client Access -> select server in top window -> click Offline Address Book Distribution tab in bottom window -> click OAB properties in right window, under Actions; set internal and external URLs from there

Web Services:
Get-WebServicesVirtualDirectory | Select name, *url* | fl
Set-WebServicesVirtualDirectory –Identity “<EWS Name>” –InternalUrl: https://url.domain.local/EWS/Exchange.asmx
Unified Messaging:
Get-UMVirtualDirectory | Select Name, *url* | fl
Set-UMVirtualDirectory –Identity: “<UM Virtual Directory>” –InternalURL: <URL/UnifiedMessaging/Service.asmx>