Notifying Our Users of Attacks by Suspected State-Sponsored Actors
yahoo-security.tumblr.com
yahoo-security.tumblr.com
In context, and in the security industry in general, "state actor" refers to active (although often broadly cast) penetration attempts by groups thought to be operated by foreign governments. These groups do not have significant surveillance capabilities, so they're trying to build it by doing things like getting access to the email of potentially interesting people, often via credential stealing malware or plain old phishing. Their methods are often not particularly sophisticated, but they're more persistent and better funded than most other threat actors. On the other hand, their methods sometimes are very sophisticated, so it's good to detect a problem as early as possible, as Yahoo is trying to help users do.
Receiving SPF, DKIM validated spam from Yahoo's email systems, then discovering there's absolutely no way in hell to kick it back to them, sours one rather rapidly.
Trying to send mail to Yahoo has been roughly equally annoying for about as long.
-- The Yahoo! Mail TeamThey also host a spam FAQ which has a link to a form to submit spam reports: https://help.yahoo.com/kb/SLN3402.html
This goes back years, I've not tried recently, status may have changed. But again, the long, long term experience has been pretty sour.
> Submit your report using our "Got Spam?" form if your email provider doesn't offer a spam reporting feature.
The "Got Spam?" link takes you to a form where you can supply the headers and content of the spam message sent from Yahoo.
The web-form workflow breaks in many ways: console tools (which I use for email), mobile, and more.
The fact that I can simply "bounce" the whole message at Yahoo's spamtraps, if they had such a thing, and they can sort the message's legitimacy and structure themselves, but they don't allow this, speaks volumes.
And again, this shit for a decade or more.
Now, if Yahoo wanted to creat CLI tools to incorporate into mailflows for those of us who know what we're doing to slot into their systems, great.
But ultimately, their problems aren't mine, I've washed my hands.
My experience with Yahoo mail is that there are tons of false positives on spam, and that none of the headers matter much... preference is given to a small number of whitelisted sending companies.
Anyways...
> "Yahoo doesn't consider a properly DKIM or Domainkeys email something that should not just end up in the spam folder"
Nor should they. There's plenty of actual spam that passes SPF and DKIM checks -- which brings us back to my original point (the amount of spam that I receive from Yahoo!). A message should not be treated as non-spam just because it passes those checks -- they are merely one factor to consider.
Of course not as the only criterion. But the messages in question were not spam, they were legitimate emails with DKIM, Domainkeys, SPF, long term non-spam IP address, etc.
It's no doubt interesting to know that your account is being targeted by your own or some other government, but identification seems secondary to detection and response.
So I turned on two factor auth and the warnings stopped.
I wish I knew which state and why my account was being attacked? I'm guessing it was not a specific attack but perhaps the attacker was trying credentials found in some other breach.
Considering that Google cooperates with the USG, I'd guess that it was some state other than the US, but who knows. I'm not aware of having done anything that would be of concern to any government.
It's great if one is a dissenter in Egypt and the authorities there go after their Yahoo! account but what about a US citizen's account being attacked by the FBI or NSA?
This passed along with the budget bill at the end of last week. It establishes a system whereby the US defense department shares with corporations their signals for detecting state-sponsored attacks, and companies are allowed to opt in to sharing anonymized attack information with the DoD
There have always been other methods for determining if an attacker is state sponsored. One example: Seeing your account, and a number of dissident or activists being attacked from a block of IPs or similar password attempts, probably means the attack is state sponsored.
That being said, in security, attribution is a very hard problem, and the methods used to determine state sponsored attacks are also quite hard to design.
There's a reason why companies won't elaborate on how they do this, but it is usually a combination of login/account intelligence and threat feeds.
Used to work at a fairly large global corporation. One day I was chatting up one of the senior sys admins. He was talking about the incredible traffic that bombards their server everyday. I was pretty naive back then and said, "Cmon man, it can't be that much!"
He opened his terminal and ran a simple monitoring tool, then opened one another terminal. In one was the constant traffic to several of their applications that were from a specific block of IP addresses he thought he had traced back to China. The other window was a running queue of mistyped password attempts. It was like clockwork. They'd try three, get kicked out of the system, then in an instant, you'd see a flurry of new IP addresses from the same block, then some more attempts to guess the password. Kicked out, rinse, repeat.
In the span of five minutes, I must have seen two dozen failed attempts to try and do a dictionary password attack on their login page. He guessed it was some kind of a bot that was running the tests considering how mechanical and orderly the attacks were.
It really opened my eyes as to how often and how many businesses these governments go after for intellectual property.
In previous jobs, I've been involved with various ISACs and while there was some sharing of information from the government, it was often "watered down", vague, and mostly unactionable.
State sponsored don't do it for the money.
These TTPs may consist of known attack infrastructure, email payloads, even things as simple as an email subject line if the attacker leaves it fairly static. They may also be as complicated as artifacts of dynamic analysis of malware, software engineering techniques and tools, language use, etc.
Attribution to state actors comes via similar techniques, generally tying attacks back to infrastructure known to be owned by state agencies or companies operated by the same. The line between state actors and higher-end criminal groups can be very blurry, both in that attribution may be difficult and in that the groups actually overlap in many areas. But still, you can often make a pretty confident guess.
These attribution techniques are well-established in the security industry, and I'm not surprised to see these big providers starting to automate it where possible.
https://news.ycombinator.com/item?id=10722633
That contains the text in the discussion, and links to the text, etc.
It would be good if these notifications said where the attacks appeared to originate.