Microsoft Blames Russia For Failure To Enforce Its Vendors Account Security

There are again claims that a run-of-the-mill computer incident was caused by ‘Russian hacking’ even as no evidence is provided for it.

The New York Times hacks immediately turn that evidence free claim that into a ‘challenge’ for the U.S. president even as there is nothing political about the incident.

Russia Challenges Biden Again With Broad Cybersurveillance Operation

Russia’s premier intelligence agency has launched another campaign to pierce thousands of U.S. government, corporate and think-tank computer networks, Microsoft officials and cybersecurity experts warned on Sunday, only months after President Biden imposed sanctions on Moscow in response to a series of sophisticated spy operations it had conducted around the world.

The new effort is “very large, and it is ongoing,” Tom Burt, one of Microsoft’s top security officers, said in an interview. Government officials confirmed that the operation, apparently aimed at acquiring data stored in the cloud, seemed to come out of the S.V.R., the Russian intelligence agency that was the first to enter the Democratic National Committee’s networks during the 2016 election.

While Microsoft insisted that the percentage of successful breaches was small, it did not provide enough information to accurately measure the severity of the theft.

Earlier this year, the White House blamed the S.V.R. for the so-called SolarWinds hacking, a highly sophisticated effort to alter software used by government agencies and the nation’s largest companies, giving the Russians broad access to 18,000 users.

As typical for such incidents they get exaggerated – “very large, and it is ongoing” – and downplayed – “the percentage of successful breaches was small” – at the same time. The attribution to Russia – “seemed to come out of the S.V.R.” – is extraordinary weak.

To compare the current incident, which turns out to have been a primitive ‘brute force’ attack on user logins, to the very sophisticated Solarwinds hack, makes little sense.

If it was indeed the S.V.R. which has done the Solarwinds attack, which is also an unproven assertion, then it is hard to believe that the current rather primitive incident can be attributed to the same entity.

Here is how the new attempts are described:

Microsoft said it recently notified more than 600 organizations that they had been the target of about 23,000 attempts to enter their systems.

Microsoft said the attack was focused on its “resellers,” firms that customize the use of the cloud for companies or academic institutions.

As described by Microsoft, the incursion primarily involved deploying a huge database of stolen passwords in automated attacks intended to get Russian government hackers into Microsoft’s cloud services.

So someone took a database of typically used passwords (there are many of these available for free) and used it for automated login attempts to some 600 accounts of Microsoft cloud resellers. Gaining such access could then allow to attack the customers of that reseller. Such brute force attacks are a simple script kiddie task that require less than ten lines of code. To claim that the organization that managed the Solarwinds hack would now use such a most primitive way to gain access to accounts is pretty hilarious.

Consider the Solarwinds details:

As part of the attack, the threat actors gained access to the SolarWinds Orion build system and added a backdoor to the legitimate SolarWinds.Orion.Core.BusinessLayer.dll DLL file. This DLL was then distributed to SolarWinds customers in a supply chain attack via an automatic update platform used to push out new software updates.

This DLL backdoor is known as Sunburst (FireEye) or Solorigate (Microsoft, and is loaded by the SolarWinds.BusinessLayerHost.exe program. Once loaded, it will connect back to the remote command & control server at a subdomain of avsvmcloud[.]com to receive “jobs,” or tasks, to execute on the infected computer.

The backdoor’s command control server’s DNS name is created utilizing a domain generation algorithm (DGA) to create an encoded subdomain of avsvmcloud[.]com. FireEye states that the subdomain is created by “concatenating a victim userId with a reversible encoding of the victims local machine domain name,” and then hashed. For example, a subdomain used in this attack is ‘1btcr12b62me0buden60ceudo1uv2f0i.appsync-api.us-east-2[.]avsvmcloud.com.’

It is unknown what tasks were executed, but it could be anything from giving remote access to the threat actors, downloading and installing further malware, or stealing data.

The Solarwinds attack required intimate knowledge of the company’s development, build and distribution process, several complex software modifications, command and control tools and a well managed infrastructure.


Source: Microsoft – bigger
I have no problem to believe that the Solarwinds hack was done by a well resourced state actor. But no public evidence was provided that it was a Russian one. One should at least acknowledge that dozens of other countries have similar capabilities and could also lay false traces to point to other actors.

But no such well resourced state actor would use simple brute force attacks on account logins because they are considered to be a waste of time. Such attacks are way too easy to detect and defended against and therefore the least attractive method to use. They are most often used by amateur criminals.

This incident certainly does not point to a ‘Russian attack’ but to rather flimsy security policy provided by Microsoft and its resellers:

American officials confirmed that the operation, which they consider routine spying, was underway. But they insisted that if it was successful, it was Microsoft and similar providers of cloud services who bore much of the blame.

A senior administration official called the latest attacks “unsophisticated, run-of-the mill operations that could have been prevented if the cloud service providers had implemented baseline cybersecurity practices.”

“We can do a lot of things,” the official said, “but the responsibility to implement simple cybersecurity practices to lock their — and by extension, our — digital doors rests with the private sector.”

The Microsoft’s description of the incident makes the unfounded claims that Russia’s S.V.R. was behind it. But it also acknowledges that its shoddy security policy was the real culprit in this:

The attacks we’ve observed in the recent campaign against resellers and service providers have not attempted to exploit any flaw or vulnerability in software but rather used well-known techniques, like password spray and phishing, to steal legitimate credentials and gain privileged access.

Microsoft admits that while it had asked its resellers to use multi-factor authentication for logins it did not, up to now, enforce that policy:

We have long maintained and evolved the security requirements and policies we enforce with service providers that sell or support Microsoft technology. For example, in September 2020, we updated contracts with our resellers to expand Microsoft’s abilities and rights to address reseller security incidents and to require that resellers implement specific security protections for their environments, such as restricting Partner Portal access and requiring that resellers enable multi-factor authentication (MFA) in accessing our cloud portals and underlying services, and we will take the necessary and appropriate steps to enforce these security commitments.

Had Microsoft taken those “necessary and appropriate steps” earlier no hack could have had occurred. But it was Microsoft which let its cloud resellers get away with providing less security to their customers than Twitter provides for my @MoonofA account.

To blame Russia for the resulting mess is obviously just a diversion from Microsoft’s culpability. To manipulate that into a politically charged international incident that ‘challenges’ the U.S. president is dangerous warmongering.

Via https://www.moonofalabama.org/2021/10/microsoft-blames-russia-for-failure-to-enforce-its-vendors-account-security.html#more