iCloud XXX@icloud.com hacked

[rsouldad]

I just received an e-mail from my own e-mail account XXX@icloud.com that says I've been hacked. Normally this would just go to spam as another ransomware (the boilerplate template gives it away). But the thing that disturbed me is the "from" address looks legitimate unlike most spam. It's not an address I use regularly, so it's out of the ordinary.

I can still login to apple.com, use 2 factor authentication and changed the password. The only thing I can guess is my remote computer was hacked and they are using that to send me e-mail. So I've asked the service provider to power it off completely until I can figure out what happened.

Has anyone else encountered this recently?

 

[bob_zz123]

Happened to me the other day, they're spam; those message headers are easy to manipulate, I know my account and devices are secure, I just ignore them. There's some other examples on Reddit r/Scams.

One thing I did notice from looking at the raw headers was that address was actually:
bob@icIoud.com
(rather than icloud.com)

But if you use the Mail app then the fact it uses a non-serif font for the I hides that because it sort of looks like a lower case L.

 

[jb310]

I also got an email that looked like it was sent from my own address, except it was

lcloud and not icloud

I think most people will wisely ignore it, but all it takes is one person to panic and give in to demands to make it worth the scammer's time. 🤷‍♀️

 

[adrianlondon]

It's spam. Delete it and forget about it.

 

[maflynn]

Any time I see something like this, regarding my email, credit card bank account ,etc. I go to the site directly NOT the link in the email. If you think you were hacked then definitely change your password and if you hadn't done it, enable some form of MFA

 

[rsouldad]

Thanks for the feedback. I follow all the same approaches and looked for the same tell-tell signs. I'm a computer engineer with HPE, and have seen e-mail spam ever since the inception 25 years ago. I'm definately ignoring it.

What bothers me most is it doesn't match those normal patterns of using a different domain. I've never seen that kind of attack before where they were able to spoof the domain name. Which means someone can masquerade as me sending to someone else.

Here's the full header:

Return-path: <rXXXXr@mac.com>
Original-recipient: rfc822;rXXXXr@icloud.com
Received: from mr44p00im-qukt02171902.me.com by p45-mailgateway-smtp-7bb4cd649-wkdzc (mailgateway 2415B105) with SMTP id 59b5fd12-ba25-478e-93f2-34a9171ad21c for <rXXXXr@icloud.com>; Wed, 1 May 2024 19:54:11 GMT
X-Apple-MoveToFolder: Junk
X-Apple-Action: DMARCINFO/Junk
X-Apple-UUID: 59b5fd12-ba25-478e-93f2-34a9171ad21c
Received: from icloud54.org (unknown [154.194.104.227]) by mr44p00im-qukt02171902.me.com (Postfix) with ESMTPS id 981773D8011C for <rXXXXr@icloud.com>; Wed, 1 May 2024 19:54:07 +0000 (UTC)
X-ICL-SCORE: 4.224034040041
X-ICL-INFO: GAtbVUweBFBBSVVDSAQGUkFIRFcUWUIPAApbVRYSFhEAREQTFVFEAVdZAxNFEkQRGgwKHh1Cdg8U GkgUF10UQhMdW1UVUVVMFhYLVVhDXxJIW1dCTB4HW0FXV0dMHgRQQltGHx1cWV9XEAUbF0VSV0FX CQUfEhYSAQtbVSMBA1ZbSF9DVgEGVltLVEAlEhYGEUREAhZbWA0CF0RXFVlSX1dFXkBKBgBSFhtR E04IAwNASFFPQQJSAEJJXkNOBVMEEEwAQE8EAVQRQSYaGVMYARoUWFVYQlVfVwsVGA1cXwcHOQ8U FF9DBlsaCRpa
x-spam-flag: yes
x-suspected-spam: true
Authentication-Results: bimi.icloud.com; bimi=skipped reason="insufficient dmarc"
X-ARC-Info: policy=fail; arc=none
Authentication-Results: arc.icloud.com; arc=none
Authentication-Results: dmarc.icloud.com; dmarc=fail header.from=mac.com
X-DMARC-Info: pass=fail; dmarc-policy=quarantine; s=r0; d=r0; pdomain=mac.com
X-DMARC-Policy: v=DMARC1; p=quarantine; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;
Authentication-Results: dkim-verifier.icloud.com; dkim=none
Authentication-Results: spf.icloud.com; spf=none (spf.icloud.com: rXXXXr@mac.com does not designate permitted sender hosts) smtp.mailfrom=rXXXXr@mac.com
Received-SPF: none (spf.icloud.com: rXXXXr@mac.com does not designate permitted sender hosts) receiver=spf.icloud.com; client-ip=154.194.104.227; helo=icloud54.org; envelope-from=rXXXXr@mac.com
Message-ID: <872660cb7d685a517892db708465efe5f77476d8@mac.com>
From: "rXXXXr@icloud.com" <rXXXXr@mac.com>
To: rXXXXr@icloud.com
Subject: You have been hacked
Date: Wed, 1 May 2024 12:54:05 -0700
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-CLX-Shades: Junk
X-MANTSH: 1TFkXBxsaGhgRCllEF2hZHHxZeR5wZl0eEQpZTRdgX0RBEQpfWRcHExMTEQpfTRd 4T0BPSV4RCllJFwcYHxpxGwYHHxoadwYHGBIbBhoGBxsaGkIdBgcfGgYacRoQGncGBxgfGgYHG BoaBhoGGgYaBhpxGhAadwYaEQpZXhdjY3kRCkNOF1xOZnp7c19fclt5R00eR2lpGVBlYWNva0Z lenMHXRNmEQpYXBcZBBoEHxoFGxoEGxIYBBgbGQQbHRAbHhofGhEKXlkXTktvYBIRCk1cFwceG xgRCkxaF2xeaVpyZREKTU4XaXkRCkxGF2hra2tNaxEKQ1oXGx8eBBsTHgQbGh4EGBgdEQpCXhc bEQpCRRdsEkB6ZG9yRFNpAREKQk4XaEZCQB9IeR1HH2QRCkJMF2AFQBlFWGlGRxhvEQpCbhdsY HN4cmFeY2JDTxEKQmwXZxgdRwVCXF5Cf0sRCkJAF2lkGV9MRBhTUkdrEQpCWBdnGB1HBUJcXkJ /SxEKWlgXGxEKcGgXYX8aGhtzQEljEnAQBxkfHhEKcGgXbm0bfX1DeVBSTV0QBxkfHhEKcGgXZ WheYnkfRwFDXVkQBxkfHhEKcGgXZk1ERxNaZEVfa28QBxkYHxEKcGgXb0EFYUhdHURFQ3AQBxk fHhEKcGgXaElwSUJfU3pJfmQQBxkbGxEKcGgXaVIeUhgFUAVDbBoQBxkfHhEKcGgXZX98XV0df BNCGWgQBxkfHhEKcGwXaWFNGEtmfUNEeF0QBx0aEQptfhcaEQpYTRdLEQ==
X-Proofpoint-GUID: vdLPQYuuXqSmg4mCC3zOKIEAlOPY-w9L
X-Proofpoint-ORIG-GUID: vdLPQYuuXqSmg4mCC3zOKIEAlOPY-w9L

 

[bob_zz123]

It's easily done and has been for a long time, nowadays we have SPF and DKIM where domain owners can add DNS records to specify which hosts are allowed to send mail from their domain and sign outgoing messages with a public key (also specified in the domain DNS).

It doesn't stop domain spoofing but these two techniques are combined with DMARC - so this is again set by the domain owner and is a policy (specified in DNS) for what the recipient system does with the message if it fails SPF and/or DKIM.

So in this case, if you look at the X-DMARC-Info line you can see that the message failed the checks and the policy (specified by the domain owner) was to ask the recipient e-mail system to quarantine the message (You can see the policy on the next line). Also the domain owner can ask for a "ping" (in this case to d@rua.agari.com) which I guess is for reporting purposes and allows domain owners to get some insight.

Obviously it is up to recipient e-mail systems whether they respect this and how they do this, it might get routed to a spam folder or (as is common with Office 365) it goes to a hidden quarantine and Microsoft sends you a periodic message with your quarantine items and asks what you want to do with them.

I think this is probably as good as we can get without major architectural changes to the global e-mail system, this type of malicious activity was probably not even envisaged when it was being designed.

 

[rsouldad]

It's easily done and has been for a long time, nowadays we have SPF and DKIM where domain owners can add DNS records to specify which hosts are allowed to send mail from their domain and sign outgoing messages with a public key (also specified in the domain DNS).

It doesn't stop domain spoofing but these two techniques are combined with DMARC - so this is again set by the domain owner and is a policy (specified in DNS) for what the recipient system does with the message if it fails SPF and/or DKIM.

So in this case, if you look at the X-DMARC-Info line you can see that the message failed the checks and the policy (specified by the domain owner) was to ask the recipient e-mail system to quarantine the message (You can see the policy on the next line). Also the domain owner can ask for a "ping" (in this case to d@rua.agari.com) which I guess is for reporting purposes and allows domain owners to get some insight.

Obviously it is up to recipient e-mail systems whether they respect this and how they do this, it might get routed to a spam folder or (as is common with Office 365) it goes to a hidden quarantine and Microsoft sends you a periodic message with your quarantine items and asks what you want to do with them.

I think this is probably as good as we can get without major architectural changes to the global e-mail system, this type of malicious activity was probably not even envisaged when it was being designed.

Thanks so much for the insights!