2

My parents use AOL (there's no point trying to migrate them at this stage) with two factor authentication. My father let me know that he recently received an identity log in verification email that looks suspicious.

The resolved client location in the email my dad received is marked as Brazil, which would imply to me his password's compromised by someone routing through Brazil and we should rotate his password and review his security.

However, the verification email itself is a bit suspicious to me. Maybe I'm being paranoid, but I resurrected my old AOL account, which also has TFA, so that I could trigger a verification email to compare it. There are some odd variations I circled in red.

side by side comparison of suspect and known legitimate AOL verification emails

In the suspect email (left) there is no "name" in the salutation (maybe just bad email templating), and the verification code is 8 characters long. In my trusted verification email (right) the verification code is 4 characters. Also, my name appears in the salutation (though purposefully obfuscated).

Although I'm sure AOL could be using variable length codes, their challenge form specifies 4 characters even when I used a couple different browsers/devices. Maybe our accounts are flagged for different verification code lengths somehow, but I keep consistently getting 4 characters. I tried and failed to find any literature on pros/cons of variable verification code length or any official word on what length AOL uses.

challenge form for 4 digit code from AOL

The safe route seems to be to rotate his password and move on. However...

Is there anything possibly nefarious about the "suspicious" verification email?

The sender information, links, and overall formatting seem to imply the email is in fact legitimate. It's just weird to notice those irregularities.

3
  • 3
    Have you first tried to report this to Aol's security team (help.aol.com/articles/contacting-aol-security-team)? They could easily confirm if this e-mail is valid or not. Speculating about it will probably lead to nowhere. Nov 23 '20 at 21:44
  • My old Verizon email became effectively AoL since Verizon purchased AoL. I've noted within the past year or so Client IP addresses are no longer in the raw mail headers, only AoL infrastructure IPs. If you are seeing a Client IP (Brazil or otherwise) I can't help but wonder if this came from AoL at all? Do the raw headers show AoL servers? Does the apparent HTTPS link actually resolve to what it says? Nov 23 '20 at 23:13
  • Interesting to note that AOL's security vulnerability/researcher page appears to be invalid/broken imgur.com/a/qiBiZkG
    – Will Haley
    Nov 24 '20 at 4:21
1

Per Filipe dos Santos' note in the comments I reached out to AOL support. It took some prodding, but it sounds like 4/8/variable length TFA codes are possible, "For more security"

screenshot of chat with AOL support regarding the question in this post

The missing salutation is odd, but probably more to do with poor formatting.

I'd say in this particular case there's nothing nefarious/suspect. This experience reinforces for me that consistent behavior and user messaging helps encourage trustworthiness.

0

There are two telltale signs I'd seek in this sort of message.

First is the links. Never click any of them. If a link doesn't go to the obvious destination, in this case something whose host is aol.com or ends in .aol.com (or another recognizable and appropriate Verizon-owned domain), be very suspicious. If that link is the one they want you to click on, it's a phishing attack for sure (or the team that composed that message is inept; Verizon shouldn't have this problem).

Just as when you're verifying somebody's authenticity over the phone (ask for how to be directed to a verifying source at a phone line but independently find the phone number), you need to go to the login page through a more trustworthy channel, like a bookmark or manually entering aol.com in your browser (not as a Google search). There shouldn't be much harm in entering a fake MFA challenge into the real site.

Second is to check the anti-spoofing measures used by the message. This is more tedious and requires more technical chops. Open up the message's full header view and seek out the Received headers. This should be sent directly from AOL to you. If it comes from anywhere else, you'll have to look up to see if they're a security partner (this is complicated). One shortcut you can take is to use a tool like Google Admin Toolbox Messageheader and paste your headers in there. It'll tell you what each relay means and give you a much more human-friendly view to review (iirc, they assume you're using Google infrastructure, so ignore those warnings if you're not using Google).

If it passes DMARC (though I don't recall if this tool checks DMARC), you can be sure the message comes from the domain used in the From header address.

Otherwise, you should check DKIM or SPF and then manually verify its alignment (a DMARC term).

If it passes DKIM, check that the DKIM-Signature header includes a d=DOMAIN where DOMAIN is has the same public suffix (paid-level domain) as the From header address's domain (e.g. security.aol.com is the same as aol.com but foo.co.uk is not the same as co.uk; see the Public Suffix List).

If it only passes SPF, that's slightly more tedious since you'll have to verify that the SMTP mail from command has the same public suffix as the From header, which isn't obvious.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.