Clever PayPal-based Attack

Do not call that number!

This attack is brilliant. It uses a legitimate PayPal email message about a bogus payment to trick you into phoning a bogus PayPal phone number.

I have received several of them this week with various names for the company sending the money request. Different emails contain different subjects and different phone numbers to call. All went to an email address probably scraped off the Web.

Let’s look at the example email I’ve included.

The first red flag is the text about calling PayPal. It appears in a field marked “Note from Schreiber Group,” the name of the company allegedly sending the email. Here is what Schreiber Group is telling us:

Fraud Alert, Didn’t made this order? Call PayPal Immediately 1-888-462-1325

The red flag: PayPal did not provide this text. The author of the money request wrote it. Isn’t it strange that the company asking for payment starts their request with “Fraud Alert”?

Question: Did someone set up these accounts just for this scam?

Answer: Maybe or maybe not. These may be old accounts abandoned by legitimate businesses that were hacked. PayPal tries to make it difficult for fraudsters to produce a lot of accounts to support a fraud, but the fraudsters may have found a shortcut.

Another detail: the bottom of the email contains information about potential fraud and contacting PayPal, but provides no phone numbers. Right under the Pay Now button is a warning that any victims probably wouldn’t notice: PayPal does not contact people through these payment requests.

Question: Is the email really from PayPal?

The short answer is Yes.

You can find out a lot about an email by looking at its headers. We will examine the detailed email headers from the email above. These details help us trace the email’s path through different email servers on the Internet.

Headers are usually hidden by the app that shows us our email, but a good app will show them all to you. The first interesting items are easily visible: the From and To headers:

From: "service@paypal.com" <service@paypal.com>
To: Billingdepartments1@zodu.onmicrosoft.com

The From header suggests that this is a genuine email from PayPal. We’ll look at that some more in a moment. The To header does not contain my email address. It is not the name of a mailing list I subscribed to, either. Somewhere the To address redirected this email to my email address.

It’s hard to detect bogus emails because an email message may pass through several email servers before it reaches the recipient’s mailbox. Each server adds its own Received header to each message. If we look at the detailed headers, we find this message has almost a dozen Received headers, each from a separate server.

Email systems divide different tasks between different servers. Some receive incoming mail. Some detect spam and malware. Others determine the next destination, and some deliver outgoing messages. To avoid scrambling an email’s contents, each server adds its header to the front of the email message. When you look at a series of email headers, they appear newest to oldest.

Question: Can we trust the contents of the email headers?

Answer: It’s complicated.

We can probably trust the contents of the newest headers, as long as they were added by servers we trust. A simple header contains some host names, addresses, time stamps, and other details. These are easy to forge if the email passes through a subverted server. Subsequent headers added by servers we trust are probably genuine.

Other headers contain cryptographic protection, like a digital signature. We can verify these without trusting the servers that carried them.

This email apparently went through three major transfers:

Sent from paypal.com to zodu.onmicrosoft.com
Remailed by the mailbox Billingdepartments1
Received by Fastmail (my email service) via their server messagingengine.com

The name “zodu.onmicrosoft.com” was apparently created by a Microsoft Outlook user. Customers who don’t have their own domains may use this to create a personalized subdomain to receive their email.

Question: Is the owner of “zodu” the author of this scam?

Answer: There’s no way to tell. The short name suggests it’s an older name. It’s possible that a dormant account was hacked and used for this scam.

While the From and To addresses plus the email’s destination give us three sets of email servers, each “set” contains several servers, each with differing domain names. While the email was addressed to the host “zodu.onmicrosoft.com,” it passed through servers whose domain names included “outlook.com” and “exchangelabs.com.”

Now let’s look at the From address. Spam detectors often mark as spam any message with a bogus From address. Some email clients make it very easy to customize the From address. When teaching security classes in the past, I demonstrated this by sending emails to the class from the address “potus@whitehouse.gov.”

In the past, email servers paid no serious attention to From field. These days they are more careful. Bogus From headers suggest an attempted scam, which suggests spam or phishing. Modern servers use two mechanisms to authenticate an email’s From address:

Sender Policy Framework (SPF): a list of Internet host addresses who are allowed to send email containing a particular domain name.
DomainKeys Identified Mail (DKIM): a digital signature placed in an email headers by the sending domain. Other email servers can check the DKIM signature to confirm the source and possibly the contents of the email.

An email server only makes an SPF test when when it receives an email from the sending host and/or domain.

Since this email was sent from PayPal to an Outlook server, the first Outlook server performs the SPF check. The first header below shows the SPF check. The second is the Received header created when the Outlook server retrieved the email from PayPal. Remember that email headers appear newest to oldest. The Received header was added first, and then the SPF header was added.

Received-SPF: Pass (protection.outlook.com: domain of paypal.com 
 designates 173.0.84.235 as permitted sender) 
 receiver=protection.outlook.com;
 client-ip=173.0.84.235; helo=mx11.slc.paypal.com; pr=C
Received: from mx11.slc.paypal.com (173.0.84.235) by
 SG1PEPF000082E6.mail.protection.outlook.com (10.167.240.9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8158.14 via Frontend Transport; Wed, 13 Nov 2024 13:24:22 +0000

Can we trust the contents of this SPF header? This was applied by the first server to handle the email after it left PayPal. If the email was touched by a subverted server before arriving at Fastmail, then we can’t trust any of these older headers. Except: if a header contains a digital signature, other email servers can verify the header by verifying the signature.

A DKIM header includes a digital signature to verify the domain in the From field and, optionally, some of the message contents. Below is the DKIM signature header for this message. PayPal added this to the email before sending it to the Outlook server. Any server can verify the domain name in the header (PayPal.com) by checking the digital signature with a cryptographic public key retrieved from PayPal.com. Digital signatures are fairly large because a larger signature is harder to forge.

DKIM-Signature: v=1; a=rsa-sha256; d=paypal.com; s=pp-dkim1; 
  c=relaxed/relaxed; q=dns/txt; i=@paypal.com; t=1731504261;
  h=From:From:Subject:Date:To:MIME-Version:Content-Type;
  bh=YCNHN6kLWHvQtXs7oTM+/cQrjUidPgpHDLkiniWeKVo=;
  b=GWlAFC3TX3PTuHGgy353poLCidJ8AL7tHn3tx4s+dAt24oUqjiAew4+xfaZZMu1m
  IrUJ/md8gnZoKRX+4GRwgP8kYGpBNM0t2Jk/ctk3o5Z1aSRva6x559olFuhF9EOP
  mUjf0+PcwQMjygYBFKN+OYgWIeRdEzyqYxYFKprOnBW2WQhOrc7Uxa6eeQoaEtjy
  dqZcHS/mFK1CM01f3waLrXuP2l2ZLVvu4Hkrb91iwmFjEA3Y7t3befIK/RhLMA1M
  lctWkxQ0I9rM+/RA6TpyFJzPRJOGxAfHj5fC3BfenhGWFGbCX4RF75q62mnof3ON
  QleykH1iBym90DNSEKB9+A==;

Even if we don’t trust the Outlook servers that transferred the message, Fastmail can check the digital signature and verify that PayPal sent the original message.

The headers don’t show how this email addressed to an Outlook mailbox with one email address arrived in my own Fastmail mailbox for my own email address. The culprit is probably an automatic redirection. Outlook provides several ways to receive email at one address and automatically redirect (“forward”) it to another. A clever attacker may have programmed the Outlook mailbox to automatically send the email as spam to a list of emails. Outlook does not provide a header to record this redirection. The one shred of evidence is a header showing a call to “mapi,” Microsoft’s mail API for Outlook. I’m not an expert on Microsoft’s internals, so I may have missed something.

Below is the Received header showing when the email arrived at Fastmail.com.

Received: from SEYPR02CU001.outbound.protection.outlook.com
 (mail-koreacentralazlp17013076.outbound.protection.outlook.com
 [40.93.138.76]) (using TLSv1.3 with cipher
 TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (secp384r1) server-signature RSA-PSS
 (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by phl-mx-03.messagingengine.com (Postfix) with ESMTPS
 id 8B66910000CF for <xx@cryptosmith.com>; Wed, 13 Nov 2024
 08:30:04 -0500 (EST)

This is the first time my own email address shows up in a header. It must have been added by one of the Outlook servers. Below is a header added by an authentication process performed by this server.

Authentication-Results: phl-mx-03.messagingengine.com;
    dkim=pass (2048-bit rsa key sha256) header.d=paypal.com
      header.i=@paypal.com header.b=GWlAFC3T header.a=rsa-sha256
      header.s=pp-dkim1; 
    dmarc=pass policy.dwl=pass 
      policy.published-domain-policy=reject
      policy.applied-disposition=none 
      policy.evaluated-disposition=none (p=reject,d=none,d.eval=none) 
      policy.policy-from=p header.from=paypal.com;
    iprev=pass smtp.remote-ip=40.93.138.76
      (mail-koreacentralazlp17013076.outbound.protection.outlook.com); 
    spf=pass smtp.mailfrom="bounces+SRS=qalJr=SI@zodu.onmicrosoft.com"
      smtp.helo=SEYPR02CU001.outbound.protection.outlook.com

The header contains four results. Here are what they say:

DKIM: the message originated from the PayPal domain. This is accurate because the server used PayPal’s public key to verify the signature.
DMARC: this gives instructions on how to apply authentication results to a message. The recipient should reject the message if the domain authentication tests fail. The tests did not fail.
IPREV: a very early attempt to identify bogus senders by comparing the numerical Internet address of the server to its domain name.
SPF: Verifies the “reply to” email address provided by the Outlook servers. This succeeds since the reply’s domain name matches the mailbox that forwarded the email.

I believe the DKIM result because I believe headers produced by Fastmail.

Question: How did the fraudsters set this up?

I don’t know but I can guess. They acquired lists of compromised user IDs for both PayPal and for Microsoft Outlook. The accounts had already been stripped of valuables, if any, so the compromised IDs and passwords were probably sold cheaply. They also needed a list of email addresses to use; this may have been bought or manufactured by scraping email addresses from web pages.

Then the fraudsters point payment requests from PayPal to the Outlook accounts. The Outlook accounts are programmed to redirect the emails they receive to the list of email spam targets.

This seems like a simpleminded brute-force approach. No doubt a professional group found implementation shortcuts.

Cryptosmith