Microsoft released NTLMv1 in the 1980s with the release of OS/2. In 1999, cryptanalyst Bruce Schneier and Mudge published research that exposed key weaknesses in the NTLMv1 underpinnings. At the 2012 Defcon 20 conference, researchers released a tool set that allowed attackers to move from untrusted network guest to admin in 60 seconds, by attacking the underlying weakness. With the 1998 release of Windows NT SP4 in 1998, Microsoft introduced NTLMv2, which fixed the weakness.
Organizations that rely on Windows networking aren’t the only laggards. Microsoft only announced plans to deprecate NTLMv1 last August.
Despite the public awareness that NTLMv1 is weak, “Mandiant consultants continue to identify its use in active environments,” the company said. “This legacy protocol leaves organizations vulnerable to trivial credential theft, yet it remains prevalent due to inertia and a lack of demonstrated immediate risk.”
The table first assists attackers in providing the proper answer to a challenge that Windows sends during the authentication process by using a known plaintext attack with the challenge 1122334455667788. Once the challenge has been solved, the attacker obtains the Net-NTLMv1 hash and uses the table to rapidly crack it. Typically tools including Responder, PetitPotam, and DFSCoerce are involved.
In a thread on Mastodon, researchers and admins applauded the move, because they said it would give them added ammunition when trying to convince decision makers to make the investments to move off the insecure function.
“I’ve had more than one instance in my (admittedly short) infosec career where I’ve had to prove the weakness of a system and it usually involves me dropping a sheet of paper on their desk with their password on it the next morning,” one person said. “These rainbow tables aren’t going to mean much for attackers as they’ve likely already got them or have far better methods, but where it will help is in making the argument that NTLMv1 is unsafe.”
The Mandiant post provides basic steps required to move off of NTLMv1. It links to more detailed instructions.
“Organizations should immediately disable the use of Net-NTLMv1,” Mandiant said. Organizations that get hacked because they failed to heed will have only themselves to blame.
Attackers have transformed hundreds of hacked sites running WordPress software into command-and-control servers that force visitors’ browsers to perform password-cracking attacks.
A web search for the JavaScript that performs the attack showed it was hosted on 708 sites at the time this post went live on Ars, up from 500 two days ago. Denis Sinegubko, the researcher who spotted the campaign, said at the time that he had seen thousands of visitor computers running the script, which caused them to reach out to thousands of domains in an attempt to guess the passwords of usernames with accounts on them.
Visitors unwittingly recruited
“This is how thousands of visitors across hundreds of infected websites unknowingly and simultaneously try to bruteforce thousands of other third-party WordPress sites,” Sinegubko wrote. “And since the requests come from the browsers of real visitors, you can imagine this is a challenge to filter and block such requests.”
Like the hacked websites hosting the malicious JavaScript, all the targeted domains are running the WordPress content management system. The script—just 3 kilobits in size—reaches out to an attacker-controlled getTaskURL, which in turn provides the name of a specific user on a specific WordPress site, along with 100 common passwords. When this data is fed into the browser visiting the hacked site, it attempts to log in to the targeted user account using the candidate passwords. The JavaScript operates in a loop, requesting tasks from the getTaskURL, reporting the results to the completeTaskURL, and then performing the steps again and again.
A snippet of the hosted JavaScript appears below, and below that, the resulting task:
With 418 password batches as of Tuesday, Sinegubko has concluded the attackers are trying 41,800 passwords against each targeted site.
Sinegubko wrote:
Attack stages and lifecycle
The attack consists of five key stages that allow a bad actor to leverage already compromised websites to launch distributed brute force attacks against thousands of other potential victim sites.
Stage 1: Obtain URLs of WordPress sites. The attackers either crawl the Internet themselves or use various search engines and databases to obtain lists of target WordPress sites.
Stage 2: Extract author usernames. Attackers then scan the target sites, extracting real usernames of authors that post on those domains.
Stage 3: Inject malicious scripts. Attackers then inject their dynamic-linx[.]com/chx.js script to websites that they have already compromised.
Stage 4: Brute force credentials. As normal site visitors open infected web pages, the malicious script is loaded. Behind the scenes, the visitors’ browsers conduct a distributed brute force attack on thousands of target sites without any active involvement from attackers.
Stage 5: Verify compromised credentials. Bad actors verify brute forced credentials and gain unauthorized access to sites targeted in stage 1.
So, how do attackers actually accomplish a distributed brute force attack from the browsers of completely innocent and unsuspecting website visitors? Let’s take a look at stage 4 in closer detail.
Distributed brute force attack steps:
When a site visitor opens an infected web page, the user’s browser requests a task from the hxxps://dynamic-linx[.]com/getTask.php URL.
If the task exists, it parses the data and obtains the URL of the site to attack along with a valid username and a list of 100 passwords to try.
For every password in the list, the visitor’s browser sends the wp.uploadFile XML-RPC API request to upload a file with encrypted credentials that were used to authenticate this specific request. That’s 100 API requests for each task! If authentication succeeds, a small text file with valid credentials is created in the WordPress uploads directory.
When all the passwords are checked, the script sends a notification to hxxps://dynamic-linx[.]com/completeTask.php that the task with a specific taskId (probably a unique site) and checkId (password batch) has been completed.
Finally, the script requests the next task and processes a new batch of passwords. And so on indefinitely while the infected page is open.
As of Tuesday, the researcher had observed “dozens of thousands of requests” to thousands of unique domains that checked for files uploaded by the visitor browsers. Most files reported 404 web errors, an indication that the login using the guessed password failed. Roughly 0.5 percent of cases returned a 200 response code, leaving open the possibility that password guesses may have been successful. On further inspection, only one of the sites was compromised. The others were using non-standard configurations that returned the 200 response, even for pages that weren’t available.
Over a four-day span ending Tuesday, Sinegubko recorded more than 1,200 unique IP addresses that tried to download the credentials file. Of those, five addresses accounted for over 85 percent of the requests:
IP
%
ASN
146.70.199.169
34.37%
M247, RO
138.199.60.23
28.13%
CDNEXT, GB
138.199.60.32
10.96%
CDNEXT, GB
138.199.60.19
6.54%
CDNEXT, GB
87.121.87.178
5.94%
SOUZA-AS, BR
Last month, the researcher observed one of the addresses—87.121.87.178—hosting a URL used in a cryptojacking attack. One possibility for the change is that the earlier campaign failed because the malicious URL it relied on wasn’t hosted on enough hacked sites and, in response, the same attacker is using the password-cracking script in an attempt to recruit more sites.
As Sinegubko notes, the more recent campaign is significant because it leverages the computers and Internet connections of unwitting visitors who have done nothing wrong. One way end users can stop this is to use NoScript or another tool that blocks JavaScript from running on unknown sites. NoScript breaks enough sites that it’s not suitable for less experienced users, and even those with more experience often find the hassle isn’t worth the benefit. One other possible remedy is to use certain ad blockers.
