Who is Alleged Medibank Hacker Aleksandr Ermakov?

Authorities in Australia, the United Kingdom and the United States this week levied financial sanctions against a Russian man accused of stealing data on nearly 10 million customers of the Australian health insurance giant Medibank. 33-year-old Aleksandr Ermakov allegedly stole and leaked the Medibank data while working with one of Russia’s most destructive ransomware groups, but little more is shared about the accused. Here’s a closer look at the activities of Mr. Ermakov’s alleged hacker handles.

The allegations against Ermakov mark the first time Australia has sanctioned a cybercriminal. The documents released by the Australian government included multiple photos of Mr. Ermakov, and it was clear they wanted to send a message that this was personal.

It’s not hard to see why. The attackers who broke into Medibank in October 2022 stole 9.7 million records on current and former Medibank customers. When the company refused to pay a $10 million ransom demand, the hackers selectively leaked highly sensitive health records, including those tied to abortions, HIV and alcohol abuse.

The U.S. government says Ermakov and the other actors behind the Medibank hack are believed to be linked to the Russia-backed cybercrime gang REvil.

“REvil was among the most notorious cybercrime gangs in the world until July 2021 when they disappeared. REvil is a ransomware-as-a-service (RaaS) operation and generally motivated by financial gain,” a statement from the U.S. Department of the Treasury reads. “REvil ransomware has been deployed on approximately 175,000 computers worldwide, with at least $200 million paid in ransom.”

The sanctions say Ermakov went by multiple aliases on Russian cybercrime forums, including GustaveDore, JimJones, and Blade Runner. A search on the handle GustaveDore at the cyber intelligence platform Intel 471 shows this user created a ransomware affiliate program in November 2021 called Sugar (a.k.a. Encoded01), which focused on targeting single computers and end-users instead of corporations.

In November 2020, Intel 471 analysts concluded that GustaveDore’s alias JimJones “was using and operating several different ransomware strains, including a private undisclosed strain and one developed by the REvil gang.”

In 2020, GustaveDore advertised on several Russian discussion forums that he was part of a Russian technology firm called Shtazi, which could be hired for computer programming, web development, and “reputation management.” Shtazi’s website remains in operation today.

The third result when one searches for shtazi[.]ru in Google is an Instagram post from a user named Mikhail Borisovich Shefel, who promotes Shtazi’s services as if it were also his business. If this name sounds familiar, it’s because in December 2023 KrebsOnSecurity identified Mr. Shefel as “Rescator,” the cybercriminal identity tied to tens of millions of payment cards that were stolen in 2013 and 2014 from big box retailers Target and Home Depot, among others.

How close was the connection between GustaveDore and Mr. Shefel? The Treasury Department’s sanctions page says Ermakov used the email address ae.ermak@yandex.ru. A search for this email at DomainTools.com shows it was used to register just one domain name: millioner1[.]com. DomainTools further finds that a phone number tied to Mr. Shefel (79856696666) was used to register two domains: millioner[.]pw, and shtazi[.]net.

The December 2023 story here that outed Mr. Shefel as Rescator noted that Shefel recently changed his last name to “Lenin” and had launched a service called Lenin[.]biz that sells physical USSR-era Ruble notes bearing the image of Vladimir Lenin, the founding father of the Soviet Union. The Instagram account for Mr. Shefel includes images of stacked USSR-era Ruble notes, as well as multiple links to Shtazi.

Intel 471’s research revealed Ermakov was affiliated in some way with REvil because the stolen Medibank data was published on a blog that had one time been controlled by REvil affiliates who carried out attacks and paid an affiliate fee to the gang.

But by the time of the Medibank hack, the REvil group had mostly scattered after a series of high-profile attacks led to the group being disrupted by law enforcement. In November 2021, Europol announced it arrested seven REvil affiliates who collectively made more than $230 million worth of ransom demands since 2019. At the same time, U.S. authorities unsealed two indictments against a pair of accused REvil cybercriminals.

“The posting of Medibank’s data on that blog, however, indicated a connection with that group, although the connection wasn’t clear at the time,” Intel 471 wrote. “This makes sense in retrospect, as Ermakov’s group had also been a REvil affiliate.”

It is easy to dismiss sanctions like these as ineffective, because as long as Mr. Ermakov remains in Russia he has little to fear of arrest. However, his alleged role as an apparent top member of REvil paints a target on him as someone who likely possesses large sums of cryptocurrency, said Patrick Gray, the Australian co-host and founder of the security news podcast Risky Business.

“I’ve seen a few people poo-poohing the sanctions…but the sanctions component is actually less important than the doxing component,” Gray said. “Because this guy’s life just got a lot more complicated. He’s probably going to have to pay some bribes to stay out of trouble. Every single criminal in Russia now knows he is a vulnerable 33 year old with an absolute ton of bitcoin. So this is not a happy time for him.”

Update, Feb. 21, 1:10 p.m. ET: The Russian security firm F.A.C.C.T reports that Ermakov has been arrested in Russia, and charged with violating domestic laws that prohibit the creation, use and distribution of malicious computer programs.

“During the investigation, several defendants were identified who were not only promoting their ransomware, but also developing custom-made malicious software, creating phishing sites for online stores, and driving user traffic to fraudulent schemes popular in Russia and the CIS,” F.A.C.C.T. wrote. “Among those detained was the owner of the nicknames blade_runner, GistaveDore, GustaveDore, JimJones.”

NJ Man Hired Online to Firebomb, Shoot at Homes Gets 13 Years in Prison

A 22-year-old New Jersey man has been sentenced to more than 13 years in prison for participating in a firebombing and a shooting at homes in Pennsylvania last year. Patrick McGovern-Allen was the subject of a Sept. 4, 2022 story here about the emergence of “violence-as-a-service” offerings, where random people from the Internet hire themselves out to perform a variety of local, physical attacks, including firebombing a home, “bricking” windows, slashing tires, or performing a drive-by shooting at someone’s residence.

McGovern-Allen, of Egg Harbor Township, N.J., was arrested Aug. 12, 2022 on an FBI warrant, which showed he was part of a group of cybercriminals who are settling scores with one another by hiring people to carry out violent attacks on their rivals.

That Sept. 2022 story about his arrest included links to two videos released on Telegram that were recorded and shared by McGovern-Allen and/or a co-conspirator as “proof” that they had carried out the attacks as hired.

The first showed two young men tossing a Molotov Cocktail at the side of a residence in Abington Township, Pa, setting it ablaze. The second featured two men with handguns unloading multiple rounds haphazardly into the first story of a house in West Chester, Pa. Fortunately in both cases, the occupants of the homes were unharmed in the attacks.

Federal prosecutors said McGovern-Allen went by the alias “Tongue” on Discord, and that in one chat he was quite explicit about his violence-as-a-service offering.

“In the chats, [Tongue] tells other Discord users that he was the person who shot K.M.’s house and that he was willing to commit firebombings using Molotov Cocktails,” the complaint against McGovern-Allen explains. “For example, in one Discord chat from March 2022, [the defendant] states ‘if you need anything done for $ lmk [“let me know”]/I did a shooting/Molotov/but I can also do things for ur entertainment.”

The chat channels that Tongue frequented have hundreds to thousands of members each, and some of the more interesting solicitations on these communities are job offers for in-person assignments and tasks that can be found if one searches for posts titled, “If you live near,” or “IRL job” — short for “in real life” job. A number of these classified ads are in service of performing “brickings,” where someone is hired to visit a specific address and toss a brick through the target’s window.

McGovern-Allen was in the news not long ago. According to a Sept. 2020 story from The Press of Atlantic City, a then 19-year-old Patrick McGovern-Allen was injured after driving into a building and forcing residents from their home.

“Police found a 2007 Lexus, driven by Patrick McGovern-Allen, 19, that had lost control and left the road, crashing into the eastern end of the 1600 building,” the story recounted. “The car was driven through the steps that provide access to the second-floor apartments, destroying them, and also caused damage to the outer wall.”

A copy of McGovern-Allen’s sentencing statement says he pleaded guilty to three criminal counts, including two for stalking, and one for the use of fire in commission of a federal felony. The judge in the case gave McGovern-Allen 160 months in prison — about 13.3 years. After completing his sentence, McGovern-Allen will be on supervised release for three years.

Karma Catches Up to Global Phishing Service 16Shop

You’ve probably never heard of “16Shop,” but there’s a good chance someone using it has tried to phish you.

The international police organization INTERPOL said last week it had shuttered the notorious 16Shop, a popular phishing-as-a-service platform launched in 2017 that made it simple for even complete novices to conduct complex and convincing phishing scams. INTERPOL said authorities in Indonesia arrested the 21-year-old proprietor and one of his alleged facilitators, and that a third suspect was apprehended in Japan.

The INTERPOL statement says the platform sold hacking tools to compromise more than 70,000 users in 43 countries. Given how long 16Shop has been around and how many paying customers it enjoyed over the years, that number is almost certainly highly conservative.

Also, the sale of “hacking tools” doesn’t quite capture what 16Shop was all about: It was a fully automated phishing platform that gave its thousands of customers a series of brand-specific phishing kits to use, and provided the domain names needed to host the phishing pages and receive any stolen credentials.

Security experts investigating 16Shop found the service used an application programming interface (API) to manage its users, an innovation that allowed its proprietors to shut off access to customers who failed to pay a monthly fee, or for those attempting to copy or pirate the phishing kit.

16Shop also localized phishing pages in multiple languages, and the service would display relevant phishing content depending on the victim’s geolocation.

For example, in 2019 McAfee found that for targets in Japan, the 16Shop kit would also collect Web ID and Card Password, while US victims will be asked for their Social Security Number.

“Depending on location, 16Shop will also collect ID numbers (including Civil ID, National ID, and Citizen ID), passport numbers, social insurance numbers, sort codes, and credit limits,” McAfee wrote.

In addition, 16Shop employed various tricks to help its users’ phishing pages stay off the radar of security firms, including a local “blacklist” of Internet addresses tied to security companies, and a feature that allowed users to block entire Internet address ranges from accessing phishing pages.

The INTERPOL announcement does not name any of the suspects arrested in connection with the 16Shop investigation. However, a number of security firms — including Akamai, McAfee and ZeroFox, previously connected the service to a young Indonesian man named Riswanda Noor Saputra, who sold 16Shop under the hacker handle “Devilscream.”

According to the Indonesian security blog Cyberthreat.id, Saputra admitted being the administrator of 16Shop, but told the publication he handed the project off to others by early 2020.

Nevertheless, Cyberthreat reported that Devilscream was arrested by Indonesian police in late 2021 as part of a collaboration between INTERPOL and the U.S. Federal Bureau of Investigation (FBI). Still, researchers who tracked 16Shop since its inception say Devilscream was not the original proprietor of the phishing platform, and he may not be the last.

RIZKY BUSINESS

It is not uncommon for cybercriminals to accidentally infect their own machines with password-stealing malware, and that is exactly what seems to have happened with one of the more recent administrators of 16Shop.

Constella Intelligence, a data breach and threat actor research platform, now allows users to cross-reference popular cybercrime websites and denizens of these forums with inadvertent malware infections by information-stealing trojans. A search in Constella on 16Shop’s domain name shows that in mid-2022, a key administrator of the phishing service infected their Microsoft Windows desktop computer with the Redline information stealer trojan — apparently by downloading a cracked (and secretly backdoored) copy of Adobe Photoshop.

Redline infections steal gobs of data from the victim machine, including a list of recent downloads, stored passwords and authentication cookies, as well as browser bookmarks and auto-fill data. Those records indicate the 16Shop admin used the nicknames “Rudi” and “Rizki/Rizky,” and maintained several Facebook profiles under these monikers.

It appears this user’s full name (or at least part of it) is Rizky Mauluna Sidik, and they are from Bandung in West Java, Indonesia. One of this user’s Facebook pages says Rizky is the chief executive officer and founder of an entity called BandungXploiter, whose Facebook page indicates it is a group focused mainly on hacking and defacing websites.

A LinkedIn profile for Rizky says he is a backend Web developer in Bandung who earned a bachelor’s degree in information technology in 2020. Mr. Rizky did not respond to requests for comment.

CISA Order Highlights Persistent Risk at Network Edge

The U.S. government agency in charge of improving the nation’s cybersecurity posture is ordering all federal agencies to take new measures to restrict access to Internet-exposed networking equipment. The directive comes amid a surge in attacks targeting previously unknown vulnerabilities in widely used security and networking appliances.

Under a new order from the Cybersecurity and Infrastructure Security Agency (CISA), federal agencies will have 14 days to respond to any reports from CISA about misconfigured or Internet-exposed networking equipment. The directive applies to any networking devices — such as firewalls, routers and load balancers — that allow remote authentication or administration.

The order requires federal departments to limit access so that only authorized users on an agency’s local or internal network can reach the management interfaces of these devices. CISA’s mandate follows a slew of recent incidents wherein attackers exploited zero-day flaws in popular networking products to conduct ransomware and cyber espionage attacks on victim organizations.

Earlier today, incident response firm Mandiant revealed that since at least October 2022, Chinese cyber spies have been exploiting a zero-day vulnerability in many email security gateway (ESG) appliances sold by California-based Barracuda Networks to hoover up email from organizations using these devices.

Barracuda was alerted to the exploitation of a zero-day in its products in mid-May, and two days later the company pushed a security update to address the flaw in all affected devices. But last week, Barracuda took the highly unusual step of offering to replace compromised ESGs, evidently in response to malware that altered the systems in such a fundamental way that they could no longer be secured remotely with software updates.

According to Mandiant, a previously unidentified Chinese hacking group was responsible for exploiting the Barracuda flaw, and appeared to be searching through victim organization email records for accounts “belonging to individuals working for a government with political or strategic interest to [China] while this victim government was participating in high-level, diplomatic meetings with other countries.”

When security experts began raising the alarm about a possible zero-day in Barracuda’s products, the Chinese hacking group altered their tactics, techniques and procedures (TTPs) in response to Barracuda’s efforts to contain and remediate the incident, Mandiant found.

Mandiant said the attackers will continue to change their tactics and malware, “especially as network defenders continue to take action against this adversary and their activity is further exposed by the infosec community.”

Meanwhile, this week we learned more details about the ongoing exploitation of a zero-day flaw in a broad range of virtual private networking (VPN) products made by Fortinet — devices many organizations rely on to facilitate remote network access for employees.

On June 11, Fortinet released a half-dozen security updates for its FortiOS firmware, including a weakness that researchers said allows an attacker to run malware on virtually any Fortinet SSL VPN appliance. The researchers found that just being able to reach the management interface for a vulnerable Fortinet SSL VPN appliance was enough to completely compromise the devices.

“This is reachable pre-authentication, on every SSL VPN appliance,” French vulnerability researcher Charles Fol tweeted. “Patch your #Fortigate.”

In details published on June 12, Fortinet confirmed that one of the vulnerabilities (CVE-2023-27997) is being actively exploited. The company said it discovered the weakness in an internal code audit that began in January 2023 — when it learned that Chinese hackers were exploiting a different zero-day flaw in its products.

Shodan.io, the search engine made for finding Internet of Things devices, reports that there are currently more than a half-million vulnerable Fortinet devices reachable via the public Internet.

The new cybersecurity directive from CISA orders agencies to remove any networking device management interfaces from the internet by making them only accessible from an internal enterprise network (CISA recommends an isolated management network). CISA also says agencies should “deploy capabilities, as part of a Zero Trust Architecture, that enforce access control to the interface through a policy enforcement point separate from the interface itself (preferred action).”

Security experts say CISA’s directive highlights the reality that cyberspies and ransomware gangs are making it increasingly risky for organizations to expose any devices to the public Internet, because these groups have strong incentives to probe such devices for previously unknown security vulnerabilities.

The most glaring example of this dynamic can be seen in the frequency with which ransomware groups have discovered and pounced on zero-day flaws in widely-used file transfer applications. One ransomware gang in particular — Cl0p — has repeatedly exploited zero day bugs in various file transfer appliances to extort tens of millions of dollars from hundreds of ransomware victims.

On February 2, KrebsOnSecurity broke the news that attackers were exploiting a zero-day vulnerability in the GoAnywhere file transfer appliance by Fortra. By the time security updates were available to fix the vulnerability, Cl0p had already used it to steal data from more than a hundred organizations running Fortra’s appliance.

According to CISA, on May 27, Cl0p began exploiting a previously unknown flaw in MOVEit Transfer, a popular Internet-facing file transfer application. MOVEit parent Progress Software has since released security updates to address the weakness, but Cl0p claims to have already used it to compromise hundreds of victim organizations. TechCrunch has been tracking the fallout from victim organizations, which range from banks and insurance providers to universities and healthcare entities.

The always on-point weekly security news podcast Risky Business has recently been urging organizations to jettison any and all FTP appliances, noting that Cl0p (or another crime gang) is likely to visit the same treatment on other FTP appliance vendors.

But that sound advice doesn’t exactly scale for mid-tier networking devices like Barracuda ESGs or Fortinet SSL VPNs, which are particularly prominent in small to mid-sized organizations.

“It’s not like FTP services, you can’t tell an enterprise [to] turn off the VPN [because] the productivity hit of disconnecting the VPN is terminal, it’s a non-starter,” Risky Business co-host Adam Boileau said on this week’s show. “So how to mitigate the impact of having to use a domain-joined network appliance at the edge of your network that is going to get zero-day in it? There’s no good answer.”

Risky Business founder Patrick Gray said the COVID-19 pandemic breathed new life into entire classes of networking appliances that rely on code which was never designed with today’s threat models in mind.

“In the years leading up to the pandemic, the push towards identity-aware proxies and zero trust everything and moving away from this type of equipment was gradual, but it was happening,” Gray said. “And then COVID-19 hit and everybody had to go work from home, and there really was one option to get going quickly — which was to deploy VPN concentrators with enterprise features.”

Gray said the security industry had been focused on building the next generation of remote access tools that are more security-hardened, but when the pandemic hit organizations scrambled to cobble together whatever they could.

“The only stuff available in the market was all this old crap that is not QA’d properly, and every time you shake them CVEs fall out,” Gray remarked, calling the pandemic, “a shot in the arm” to companies like Fortinet and Barracuda.

“They sold so many VPNs through the pandemic and this is the hangover,” Gray said. “COVID-19 extended the life of these companies and technologies, and that’s unfortunate.”

Ask Fitis, the Bear: Real Crooks Sign Their Malware

Code-signing certificates are supposed to help authenticate the identity of software publishers, and provide cryptographic assurance that a signed piece of software has not been altered or tampered with. Both of these qualities make stolen or ill-gotten code-signing certificates attractive to cybercriminal groups, who prize their ability to add stealth and longevity to malicious software. This post is a deep dive on “Megatraffer,” a veteran Russian hacker who has practically cornered the underground market for malware focused code-signing certificates since 2015.

A review of Megatraffer’s posts on Russian crime forums shows this user began peddling individual stolen code-signing certs in 2015 on the Russian-language forum Exploit, and soon expanded to selling certificates for cryptographically signing applications and files designed to run in Microsoft Windows, Java, Adobe AIR, Mac and Microsoft Office.

Megatraffer explained that malware purveyors need a certificate because many antivirus products will be far more interested in unsigned software, and because signed files downloaded from the Internet don’t tend to get blocked by security features built into modern web browsers. Additionally, newer versions of Microsoft Windows will complain with a bright yellow or red alert message if users try to install a program that is not signed.

“Why do I need a certificate?” Megatraffer asked rhetorically in their Jan. 2016 sales thread on Exploit. “Antivirus software trusts signed programs more. For some types of software, a digital signature is mandatory.”

At the time, Megatraffer was selling unique code-signing certificates for $700 apiece, and charging more than twice that amount ($1,900) for an “extended validation” or EV code-signing cert, which is supposed to only come with additional identity vetting of the certificate holder. According to Megatraffer, EV certificates were a “must-have” if you wanted to sign malicious software or hardware drivers that would reliably work in newer Windows operating systems.

Megatraffer has continued to offer their code-signing services across more than a half-dozen other Russian-language cybercrime forums, mostly in the form of sporadically available EV and non-EV code-signing certificates from major vendors like Thawte and Comodo.

More recently, it appears Megatraffer has been working with ransomware groups to help improve the stealth of their malware. Shortly after Russia invaded Ukraine in February 2022, someone leaked several years of internal chat logs from the Conti ransomware gang, and those logs show Megatraffer was working with the group to help code-sign their malware between July and October 2020.

WHO IS MEGATRAFFER?

According to cyber intelligence firm Intel 471, Megatraffer has been active on more than a half-dozen crime forums from September 2009 to the present day. And on most of these identities, Megatraffer has used the email address 774748@gmail.com. That same email address also is tied to two forum accounts for a user with the handle “O.R.Z.”

Constella Intelligence, a company that tracks exposed databases, finds that 774748@gmail.com was used in connection with just a handful of passwords, but most frequently the password “featar24“. Pivoting off of that password reveals a handful of email addresses, including akafitis@gmail.com.

Intel 471 shows akafitis@gmail.com was used to register another O.R.Z. user account — this one on Verified[.]ru in 2008. Prior to that, akafitis@gmail.com was used as the email address for the account “Fitis,” which was active on Exploit between September 2006 and May 2007. Constella found the password “featar24” also was used in conjunction with the email address spampage@yandex.ru, which is tied to yet another O.R.Z. account on Carder[.]su from 2008.

The email address akafitis@gmail.com was used to create a Livejournal blog profile named Fitis that has a large bear as its avatar. In November 2009, Fitis wrote, “I am the perfect criminal. My fingerprints change beyond recognition every few days. At least my laptop is sure of it.”

Fitis’s real-life identity was exposed in 2010 after two of the biggest sponsors of pharmaceutical spam went to war with each other, and large volumes of internal documents, emails and chat records seized from both spam empires were leaked to this author. That protracted and public conflict formed the backdrop of my 2014 book — “Spam Nation: The Inside Story of Organized Cybercrime, from Global Epidemic to Your Front Door.”

One of the leaked documents included a Microsoft Excel spreadsheet containing the real names, addresses, phone numbers, emails, street addresses and WebMoney addresses for dozens of top earners in Spamit — at the time the most successful pharmaceutical spam affiliate program in the Russian hacking scene and one that employed most of the top Russian botmasters.

That document shows Fitis was one of Spamit’s most prolific recruiters, bringing more than 75 affiliates to the Spamit program over several years prior to its implosion in 2010 (and earning commissions on any future sales from all 75 affiliates).

The document also says Fitis got paid using a WebMoney account that was created when its owner presented a valid Russian passport for a Konstantin Evgenievich Fetisov, born Nov. 16, 1982 and residing in Moscow. Russian motor vehicle records show two different vehicles are registered to this person at the same Moscow address.

The most interesting domain name registered to the email address spampage@yahoo.com, fittingly enough, is fitis[.]ru, which DomainTools.com says was registered in 2005 to a Konstantin E. Fetisov from Moscow.

The Wayback Machine at archive.org has a handful of mostly blank pages indexed for fitis[.]ru in its early years, but for a brief period in 2007 it appears this website was inadvertently exposing all of its file directories to the Internet.

One of the exposed files — Glavmed.html — is a general invitation to the infamous Glavmed pharmacy affiliate program, a now-defunct scheme that paid tens of millions of dollars to affiliates who advertised online pill shops mainly by hacking websites and manipulating search engine results. Glavmed was operated by the same Russian cybercriminals who ran the Spamit program.

Archive.org shows the fitis[.]ru webpage with the Glavmed invitation was continuously updated with new invite codes. In their message to would-be Glavmed affiliates, the program administrator asked applicants to contact them at the ICQ number 165540027, which Intel 471 found was an instant messenger address previously used by Fitis on Exploit.

The exposed files in the archived version of fitis[.]ru include source code for malicious software, lists of compromised websites used for pharmacy spam, and a handful of what are apparently personal files and photos. Among the photos is a 2007 image labeled merely “fitis.jpg,” which shows a bespectacled, bearded young man with a ponytail standing next to what appears to be a newly-married couple at a wedding ceremony.

Mr. Fetisov did not respond to requests for comment.

As a veteran organizer of affiliate programs, Fitis did not waste much time building a new moneymaking collective after Spamit closed up shop. New York City-based cyber intelligence firm Flashpoint found that Megatraffer’s ICQ was the contact number for Himba[.]ru, a cost-per-acquisition (CPA) program launched in 2012 that paid handsomely for completed application forms tied to a variety of financial instruments, including consumer credit cards, insurance policies, and loans.

“Megatraffer’s entrenched presence on cybercrime forums strongly suggests that malicious means are used to source at least a portion of traffic delivered to HIMBA’s advertisers,” Flashpoint observed in a threat report on the actor.

Intel 471 finds that Himba was an active affiliate program until around May 2019, when it stopping paying its associates.

Flashpoint notes that in September 2015, Megatraffer posted a job ad on Exploit seeking experienced coders to work on browser plugins, installers and “loaders” — basically remote access trojans (RATs) that establish communication between the attacker and a compromised system.

“The actor specified that he is looking for full-time, onsite help either in his Moscow or Kiev locations,” Flashpoint wrote.

Feds Take Down 13 More DDoS-for-Hire Services

The U.S. Federal Bureau of Investigation (FBI) this week seized 13 domain names connected to “booter” services that let paying customers launch crippling distributed denial-of-service (DDoS) attacks. Ten of the domains are reincarnations of DDoS-for-hire services the FBI seized in December 2022, when it charged six U.S. men with computer crimes for allegedly operating booters.

Booter services are advertised through a variety of methods, including Dark Web forums, chat platforms and even youtube.com. They accept payment via PayPal, Google Wallet, and/or cryptocurrencies, and subscriptions can range in price from just a few dollars to several hundred per month. The services are generally priced according to the volume of traffic to be hurled at the target, the duration of each attack, and the number of concurrent attacks allowed.

The websites that saw their homepages replaced with seizure notices from the FBI this week include booter services like cyberstress[.]org and exoticbooter[.]com, which the feds say were used to launch millions of attacks against millions of victims.

“School districts, universities, financial institutions and government websites are among the victims who have been targeted in attacks launched by booter services,” federal prosecutors in Los Angeles said in a statement.

Purveyors of booters or “stressers” claim they are not responsible for how customers use their services, and that they aren’t breaking the law because — like most security tools — these services can be used for good or bad purposes. Most booter sites employ wordy “terms of use” agreements that require customers to agree they will only stress-test their own networks — and that they won’t use the service to attack others.

But the DOJ says these disclaimers usually ignore the fact that most booter services are heavily reliant on constantly scanning the Internet to commandeer misconfigured devices that are critical for maximizing the size and impact of DDoS attacks. What’s more, none of the services seized by the government required users to demonstrate that they own the Internet addresses being stress-tested, something a legitimate testing service would insist upon.

This is the third in a series of U.S. and international law enforcement actions targeting booter services. In December 2022, the feds seized four-dozen booter domains and charged six U.S. men with computer crimes related to their alleged ownership of the popular DDoS-for-hire services. In December 2018, the feds targeted 15 booter sites, and three booter store defendants who later pleaded guilty.

While the FBI’s repeated seizing of booter domains may seem like an endless game of virtual Whac-a-Mole, continuously taking these services offline imposes high enough costs for the operators that some of them will quit the business altogether, says Richard Clayton, director of Cambridge University’s Cybercrime Centre.

In 2020, Clayton and others published “Cybercrime is Mostly Boring,” an academic study on the quality and types of work needed to build, maintain and defend illicit enterprises that make up a large portion of the cybercrime-as-a-service market. The study found that operating a booter service effectively requires a mind-numbing amount of constant, tedious work that tends to produce high burnout rates for booter service operators — even when the service is operating efficiently and profitably.

For example, running an effective booter service requires a substantial amount of administrative work and maintenance, much of which involves constantly scanning for, commandeering and managing large collections of remote systems that can be used to amplify online attacks, Clayton said. On top of that, building brand recognition and customer loyalty takes time.

“If you’re running a booter and someone keeps taking your domain or hosting away, you have to then go through doing the same boring work all over again,” Clayton told KrebsOnSecurity. “One of the guys the FBI arrested in December [2022] spent six months moaning that he lost his servers, and could people please lend him some money to get it started again.”

In a statement released Wednesday, prosecutors in Los Angeles said four of the six men charged last year for running booter services have since pleaded guilty. However, at least one of the defendants from the 2022 booter bust-up — John M. Dobbs, 32, of Honolulu, HI — has pleaded not guilty and is signaling he intends to take his case to trial.

Dobbs is a computer science graduate student who for the past decade openly ran IPStresser[.]com, a popular and powerful attack-for-hire service that he registered with the state of Hawaii using his real name and address. Likewise, the domain was registered in Dobbs’s name and hometown in Pennsylvania. Prosecutors say Dobbs’ service attracted more than two million registered users, and was responsible for launching a staggering 30 million distinct DDoS attacks.

Many accused stresser site operators have pleaded guilty over the years after being hit with federal criminal charges. But the government’s core claim — that operating a booter site is a violation of U.S. computer crime laws — wasn’t properly tested in the courts until September 2021.

That was when a jury handed down a guilty verdict against Matthew Gatrel, a then 32-year-old St. Charles, Ill. man charged in the government’s first 2018 mass booter bust-up. Despite admitting to FBI agents that he ran two booter services (and turning over plenty of incriminating evidence in the process), Gatrel opted to take his case to trial, defended the entire time by court-appointed attorneys.

Gatrel was convicted on all three charges of violating the Computer Fraud and Abuse Act, including conspiracy to commit unauthorized impairment of a protected computer, conspiracy to commit wire fraud, and unauthorized impairment of a protected computer. He was sentenced to two years in prison.

A copy of the FBI’s booter seizure warrant is here (PDF). According to the DOJ, the defendants who pleaded guilty to operating booter sites include:

–Jeremiah Sam Evans Miller, aka “John The Dev,” 23, of San Antonio, Texas, who pleaded guilty on April 6 to conspiracy and violating the computer fraud and abuse act related to the operation of a booter service named RoyalStresser[.]com (formerly known as Supremesecurityteam[.]com);

–Angel Manuel Colon Jr., aka “Anonghost720” and “Anonghost1337,” 37, of Belleview, Florida, who pleaded guilty on February 13 to conspiracy and violating the computer fraud and abuse act related to the operation of a booter service named SecurityTeam[.]io;

–Shamar Shattock, 19, of Margate, Florida, who pleaded guilty on March 22 to conspiracy to violate the computer fraud and abuse act related to the operation of a booter service known as Astrostress[.]com;

–Cory Anthony Palmer, 23, of Lauderhill, Florida, who pleaded guilty on February 16 to conspiracy to violate the computer fraud and abuse act related to the operation of a booter service known as Booter[.]sx.

All four defendants are scheduled to be sentenced this summer.

The booter domains seized by the FBI this week include:

cyberstress[.]org
exoticbooter[.]com
layerstress[.]net
orbitalstress[.]xyz
redstresser[.]io
silentstress[.]wtf
sunstresser[.]net
silent[.]to
mythicalstress[.]net
dreams-stresser[.]org
stresserbest[.]io
stresserus[.]io
quantum-stress[.]org

Feds Charge NY Man as BreachForums Boss “Pompompurin”

The U.S. Federal Bureau of Investigation (FBI) this week arrested a New York man on suspicion of running BreachForums, a popular English-language cybercrime forum where some of the world biggest hacked databases routinely show up for sale. The forum’s administrator “Pompompurin” has been a thorn in the side of the FBI for years, and BreachForums is widely considered a reincarnation of RaidForums, a remarkably similar crime forum that the FBI infiltrated and dismantled in 2022.

In an affidavit filed with the District Court for the Southern District of New York, FBI Special Agent John Longmire said that at around 4:30 p.m. on March 15, 2023, he led a team of law enforcement agents that made a probable cause arrest of a Conor Brian Fitzpatrick in Peekskill, NY.

“When I arrested the defendant on March 15, 2023, he stated to me in substance and in part that: a) his name was Conor Brian Fitzpatrick; b) he used the alias ‘pompompurin/’ and c) he was the owner and administrator of ‘BreachForums’ the data breach website referenced in the Complaint,” Longmire wrote.

Pompompurin has been something of a nemesis to the FBI for several years. In November 2021, KrebsOnSecurity broke the news that thousands of fake emails about a cybercrime investigation were blasted out from the FBI’s email systems and Internet addresses.

Pompompurin took credit for that stunt, and said he was able to send the FBI email blast by exploiting a flaw in an FBI portal designed to share information with state and local law enforcement authorities. The FBI later acknowledged that a software misconfiguration allowed someone to send the fake emails.

In December, 2022, KrebsOnSecurity broke the news that hackers active on BreachForums had infiltrated the FBI’s InfraGard program, a vetted FBI program designed to build cyber and physical threat information sharing partnerships with experts in the private sector. The hackers impersonated the CEO of a major financial company, applied for InfraGard membership in the CEO’s name, and were granted admission to the community.

From there, the hackers plundered the InfraGard member database, and proceeded to sell contact information on more than 80,000 InfraGard members in an auction on BreachForums. The FBI responded by disabling the portal for some time, before ultimately forcing all InfraGard members to re-apply for membership.

More recently, BreachForums was the sales forum for data stolen from DC Health Link, a health insurance exchange based in Washington, D.C. that suffered a data breach this month. The sales thread initially said the data included the names, Social Security numbers, dates of birth, health plan and enrollee information and more on 170,000 individuals, although the official notice about the breach says 56,415 people were affected.

In April 2022, U.S. Justice Department seized the servers and domains for RaidForums, an extremely popular English-language cybercrime forum that sold access to more than 10 billion consumer records stolen in some of the world’s largest data breaches since 2015. As part of that operation, the feds also charged the alleged administrator, 21-year-old Diogo Santos Coelho of Portugal, with six criminal counts.

Coelho was arrested in the United Kingdom on Jan. 31, 2022. By that time, the new BreachForums had been live for just under a week, but with a familiar look.

BreachForums remains accessible online, and from reviewing the live chat stream on the site’s home page it appears the forum’s active users are only just becoming aware that their administrator — and the site’s database — is likely now in FBI hands:

“Wait if they arrested pom then doesn’t the FBI have all of our details we’ve registered with?” asked one worried BreachForums member.

“But we all have good VPNs I guess, right…right guys?” another denizen offered.

“Like pom would most likely do a plea bargain and cooperate with the feds as much as possible,” replied another.

Fitzpatrick could not be immediately reached for comment. The FBI declined to comment for this story.

There is only one page to the criminal complaint against Fitzpatrick (PDF), which charges him with one count of conspiracy to commit access device fraud. The affidavit on his arrest is available here (PDF).

Update: Corrected spelling of FBI agent’s last name.

Thinking of Hiring or Running a Booter Service? Think Again.

Most people who operate DDoS-for-hire businesses attempt to hide their true identities and location. Proprietors of these so-called “booter” or “stresser” services — designed to knock websites and users offline — have long operated in a legally murky area of cybercrime law. But until recently, their biggest concern wasn’t avoiding capture or shutdown by the feds: It was minimizing harassment from unhappy customers or victims, and insulating themselves against incessant attacks from competing DDoS-for-hire services.

And then there are booter store operators like John Dobbs, a 32-year-old computer science graduate student living in Honolulu, Hawaii. For at least a decade until late last year, Dobbs openly operated IPStresser[.]com, a popular and powerful attack-for-hire service that he registered with the state of Hawaii using his real name and address. Likewise, the domain was registered in Dobbs’s name and hometown in Pennsylvania.

The only work experience Dobbs listed on his resume was as a freelance developer from 2013 to the present day. Dobbs’s resume doesn’t name his booter service, but in it he brags about maintaining websites with half a million page views daily, and “designing server deployments for performance, high-availability and security.”

In December 2022, the U.S. Department of Justice seized Dobbs’s IPStresser website and charged him with one count of aiding and abetting computer intrusions. Prosecutors say his service attracted more than two million registered users, and was responsible for launching a staggering 30 million distinct DDoS attacks.

The government seized four-dozen booter domains, and criminally charged Dobbs and five other U.S. men for allegedly operating stresser services. This was the Justice Department’s second such mass takedown targeting DDoS-for-hire services and their accused operators. In 2018, the feds seized 15 stresser sites, and levied cybercrime charges against three men for their operation of booter services.

Many accused stresser site operators have pleaded guilty over the years after being hit with federal criminal charges. But the government’s core claim — that operating a booter site is a violation of U.S. computer crime laws — wasn’t properly tested in the courts until September 2021.

That was when a jury handed down a guilty verdict against Matthew Gatrel, a then 32-year-old St. Charles, Ill. man charged in the government’s first 2018 mass booter bust-up. Despite admitting to FBI agents that he ran two booter services (and turning over plenty of incriminating evidence in the process), Gatrel opted to take his case to trial, defended the entire time by court-appointed attorneys.

Prosecutors said Gatrel’s booter services — downthem[.]org and ampnode[.]com — helped some 2,000 paying customers launch debilitating digital assaults on more than 20,000 targets, including many government, banking, university and gaming websites.

Gatrel was convicted on all three charges of violating the Computer Fraud and Abuse Act, including conspiracy to commit unauthorized impairment of a protected computer, conspiracy to commit wire fraud, and unauthorized impairment of a protected computer. He was sentenced to two years in prison.

Now, it appears Dobbs is also planning to take his chances with a jury. On Jan. 4, Dobbs entered a plea of not guilty. Neither Dobbs nor his court-appointed attorney responded to requests for comment.

But as it happens, Dobbs himself provided some perspective on his thinking in an email exchange with KrebsOnSecurity back in 2020. I’d reached out to Dobbs because it was obvious he didn’t mind if people knew he operated one of the world’s most popular DDoS-for-hire sites, and I was genuinely curious why he was so unafraid of getting raided by the feds.

“Yes, I am the owner of the domain you listed, however you are not authorized to post an article containing said domain name, my name or this email address without my prior written permission,” Dobbs replied to my initial outreach on March 10, 2020 using his email address from the University of Hawaii at Manoa.

A few hours later, I received more strident instructions from Dobbs, this time via his official email address at ipstresser[.]com.

“I will state again for absolute clarity, you are not authorized to post an article containing ipstresser.com, my name, my GitHub profile and/or my hawaii.edu email address,” Dobbs wrote, as if taking dictation from a lawyer who doesn’t understand how the media works.

When pressed for particulars on his business, Dobbs replied that the number of IPStresser customers was “privileged information,” and said he didn’t even advertise the service. When asked whether he was concerned that many of his competitors were by then serving jail time for operating similar booter services, Dobbs maintained that the way he’d set up the business insulated him from any liability.

“I have been aware of the recent law enforcement actions against other operators of stress testing services,” Dobbs explained. “I cannot speak to the actions of these other services, but we take proactive measures to prevent misuse of our service and we work with law enforcement agencies regarding any reported abuse of our service.”

What were those proactive measures? In a 2015 interview with ZDNet France, Dobbs asserted that he was immune from liability because his clients all had to submit a digital signature attesting that they wouldn’t use the site for illegal purposes.

“Our terms of use are a legal document that protects us, among other things, from certain legal consequences,” Dobbs told ZDNet. “Most other sites are satisfied with a simple checkbox, but we ask for a digital signature in order to imply real consent from our customers.”

Dobbs told KrebsOnSecurity his service didn’t generate much of a profit, but rather that he was motivated by “filling a legitimate need.”

“My reason for offering the service is to provide the ability to test network security measures before someone with malicious intent attacks said network and causes downtime,” he said. “Sure, some people see only the negatives, but there is a long list of companies I have worked with over the years who would say my service is a godsend and has helped them prevent tens of thousands of dollars in downtime resulting from a malicious attack.”

“I do not believe that providing such a service is illegal, assuming proper due diligence to prevent malicious use of the service, as is the case for IPstresser[.]com,” Dobbs continued. “Someone using such a service to conduct unauthorized testing is illegal in many countries, however, the legal liability is that of the user, not of the service provider.”

Dobbs’s profile on GitHub includes more of his ideas about his work, including a curious piece on “software engineering ethics.” In his January 2020 treatise “My Software Engineering Journey,” Dobbs laments that nothing in his formal education prepared him for the reality that a great deal of his work would be so tedious and repetitive (this tracks closely with a 2020 piece here called Career Choice Tip: Cybercrime is Mostly Boring).

“One area of software engineering that I think should be covered more in university classes is maintenance,” Dobbs wrote. “Projects are often worked on for at most a few months, and students do not experience the maintenance aspect of software engineering until they reach the workplace. Let’s face it, ongoing maintenance of a project is boring; there is nothing like the euphoria of completing a project you have been working on for months and releasing it to the world, but I would say that half of my professional career has been related to maintenance.”

Allison Nixon is chief research officer at the New York-based cybersecurity firm Unit 221B. Nixon is part of a small group of researchers who have been closely tracking the DDoS-for-hire industry for years, and she said Dobbs’s claim that what he’s doing is legal makes sense given that it took years for the government to recognize the size of the problem.

“These guys are arguing that their services are legal because for a long time nothing happened to them,” Nixon said. “It’s difficult to argue something is illegal if no one has ever been arrested for it before.”

Nixon says the government’s fight against the booter services — and by extension other types of cybercrimes — is hampered by a legal system that often takes years to cycle through cybercrime cases.

“With cybercrime, the cycle between the crime and investigation and arrest can often take a year or more, and that’s for a really fast case,” Nixon said. “If someone robbed a store, we’d expect a police response within a few minutes. If someone robs a bank’s website, there might be some indication of police activity within a year.”

Nixon praised the 2022 and 2018 booter takedown operations as “huge steps forward,” but added that “there need to be more of them, and faster.”

“This time lag is part of the reason it’s so difficult to shut down the pipeline of new talent going into cybercrime,” she said. “They think what they’re doing is legal because nothing has happened, and because of the amount of time it takes to shut these things down. And it’s really a big problem, where we see a lot of people becoming criminals on the basis that what they’re doing isn’t really illegal because the cops won’t do anything.”

In December 2020, Dobbs filed an application with the state of Hawaii to withdraw IP Stresser Inc. from its roster of active companies. But according to prosecutors, Dobbs would continue to operate his DDoS-for-hire site until at least November 2022.

Two months after our 2020 email interview, Dobbs would earn his second bachelor’s degree (in computer science; his resume says he earned a bachelor’s in civil engineering from Drexel University in 2013). The federal charges against Dobbs came just as he was preparing to enter his final semester toward a master’s degree in computer science at the University of Hawaii.

Nixon says she has a message for anyone involved in operating a DDoS-for-hire service.

“Unless you are verifying that the target owns the infrastructure you’re targeting, there is no legal way to operate a DDoS-for-hire service,” she said. “There is no Terms of Service you could put on the site that would somehow make it legal.”

And her message to the customers of those booter services? It’s a compelling one to ponder, particularly now that investigators in the United States, U.K. and elsewhere have started going after booter service customers.

“When a booter service claims they don’t share logs, they’re lying because logs are legal leverage for when the booter service operator gets arrested,” Nixon said. “And when they do, you’re going to be the first people they throw under the bus.”

ConnectWise Quietly Patches Flaw That Helps Phishers

ConnectWise, which offers a self-hosted, remote desktop software application that is widely used by Managed Service Providers (MSPs), is warning about an unusually sophisticated phishing attack that can let attackers take remote control over user systems when recipients click the included link. The warning comes just weeks after the company quietly patched a vulnerability that makes it easier for phishers to launch these attacks.

ConnectWise Control is extremely popular among MSPs that manage, protect and service large numbers of computers remotely for client organizations. Their product provides a dynamic software client and hosted server that connects two or more computers together, and provides temporary or persistent remote access to those client systems.

When a support technician wants to use it to remotely administer a computer, the ConnectWise website generates an executable file that is digitally signed by ConnectWise and downloadable by the client via a hyperlink.

When the remote user in need of assistance clicks the link, their computer is then directly connected to the computer of the remote administrator, who can then control the client’s computer as if they were seated in front of it.

While modern Microsoft Windows operating systems by default will ask users whether they want to run a downloaded executable file, many systems set up for remote administration by MSPs disable that user account control feature for this particular application.

In October, security researcher Ken Pyle alerted ConnectWise that their client executable file gets generated based on client-controlled parameters. Meaning, an attacker could craft a ConnectWise Control client download link that would bounce or proxy the remote connection from the MSP’s servers to a server that the attacker controls.

This is dangerous because many organizations that rely on MSPs to manage their computers often set up their networks so that only remote assistance connections coming from their MSP’s networks are allowed.

Using a free ConnectWise trial account, Pyle showed the company how easy it was to create a client executable that is cryptographically signed by ConnectWise and can bypass those network restrictions by bouncing the connection through an attacker’s ConnectWise Control server.

“You as the attacker have full control over the link’s parameters, and that link gets injected into an executable file that is downloaded by the client through an unauthenticated Web interface,” said Pyle, a partner and exploit developer at the security firm Cybir. “I can send this link to a victim, they will click this link, and their workstation will connect back to my instance via a link on your site.”

On Nov. 29, roughly the same time Pyle published a blog post about his findings, ConnectWise issued an advisory warning users to be on guard against a new round email phishing attempts that mimic legitimate email alerts the company sends when it detects unusual activity on a customer account.

“We are aware of a phishing campaign that mimics ConnectWise Control New Login Alert emails and has the potential to lead to unauthorized access to legitimate Control instances,” the company said.

ConnectWise said it released software updates last month that included new protections against the misdirection vulnerability that Pyle reported.  But the company said there is no reason to believe the phishers they warned about are exploiting any of the issues reported by Pyle.

“Our team quickly triaged the report and determined the risk to partners to be minimal,” said Patrick Beggs, ConnectWise’s chief information security officer. “Nevertheless, the mitigation was simple and presented no risk to partner experience, so we put it into the then-stable 22.8 build and the then-canary 22.9 build, which were released as part of our normal release processes. Due to the low severity of the issue, we didn’t (and don’t plan to) issue a security advisory or alert, since we reserve those notifications for serious security issues.”

Beggs said the phishing attacks that sparked their advisory stemmed from an instance that was not hosted by ConnectWise.

“So we can confirm they are unrelated,” he said. “Unfortunately, phishing attacks happen far too regularly across a variety of industries and products. The timing of our advisory and Mr. Pyle’s blog were coincidental. That said, we’re all for raising more awareness of the seriousness of phishing attacks and the general importance of staying alert and aware of potentially dangerous content.”

The ConnectWise advisory warned users that before clicking any link that appears to come from their service, users should validate the content includes “domains owned by trusted sources,” and “links to go to places you recognize.”

But Pyle said this advice is not terribly useful for customers targeted in his attack scenario because the phishers can send emails directly from ConnectWise, and the short link that gets presented to the user is a wildcard domain that ends in ConnectWise Control’s own domain name — screenconnect.com. What’s more, examining the exceedingly long link generated by ConnectWise’s systems offers few insights to the average user.

“It’s signed by ConnectWise and comes from them, and if you sign up for a free trial instance, you can email people invites directly from them,” Pyle said.

ConnectWise’s warnings come amid breach reports from another major provider of remote support technologies: GoTo disclosed on Nov. 30 that it is investigating a security incident involving “unusual activity within our development environment and third-party cloud storage services. The third-party cloud storage service is currently shared by both GoTo and its affiliate, the password manager service LastPass.

In its own advisory on the incident, LastPass said they believe the intruders leveraged information stolen during a previous intrusion in August 2022 to gain access to “certain elements of our customers’ information.”  However, LastPass maintains that its “customer passwords remain safely encrypted due to LastPass’s Zero Knowledge architecture.”

In short, that architecture means if you lose or forget your all-important master LastPass password — the one needed to unlock access to all of your other passwords stored with them — LastPass can’t help you with that, because they don’t store it. But that same architecture theoretically means that hackers who might break into LastPass’s networks can’t access that information either.

Update, 7:25 p.m. ET: Included statement from ConnectWise CISO.

Why Continuous Security Testing is a Must for Organizations Today

The global cybersecurity market is flourishing. Experts at Gartner predict that the end-user spending for the information security and risk management market will grow from $172.5 billion in 2022 to $267.3 billion in 2026.  One big area of spending includes the art of putting cybersecurity defenses under pressure, commonly known as security testing. MarketsandMarkets forecasts the global

Firing Your Entire Cybersecurity Team? Are You Sure?

What on earth were they thinking? That's what we – and other security experts – were wondering when content giant Patreon recently dismissed its entire internal cybersecurity team in exchange for outsourced services. Of course, we don't know the true motivations for this move. But, as outsiders looking in, we can guess the cybersecurity implications of the decision would be inescapable for any

Botched Crypto Mugging Lands Three U.K. Men in Jail

Three men in the United Kingdom were arrested this month for attempting to assault a local man and steal his virtual currencies. The incident is the latest example of how certain cybercriminal communities are increasingly turning to physical violence to settle scores and disputes.

Shortly after 11 p.m. on September 6, a resident in the Spalding Common area in the district of Lincolnshire, U.K. phoned police to say three men were acting suspiciously, and had jumped a nearby fence.

“The three men made off in a VW Golf and were shortly stopped nearby,” reads a statement by the Lincolnshire Police. “The car was searched by officers who found an imitation firearm, taser, a baseball bat and police uniform in the boot.”

Thomas Green, 23, Rayhan Miah, 23, and Leonardo Sapiano, 24 were all charged with possession of the weapons, and “with intent to cause loss to another to make an unwarranted demand of Crypto Currency from a person.”

KrebsOnSecurity has learned that the defendants were in Spalding Common to pay a surprise visit to a 19-year-old hacker known by the handles “Discoli,” “Disco Dog,” and “Chinese.” In December 2020, Discoli took credit for hacking and leaking the user database for OGUsers, a forum overrun with people looking to buy, sell and trade access to compromised social media accounts.

Reached via Telegram, Discoli confirmed that police believe the trio was trying to force their way into his home in Spalding Common, and that one of them was wearing a police uniform when they approached his residence.

“They were obvious about being fake police, so much so that one of our neighbours called,” Discoli said in an instant message chat. “That call led to the arrests. Their intent was for robbery/blackmail of crypto, I just happened to not be home at the time.”

The Lincolnshire Police declined to comment for this story, citing an ongoing investigation.

Discoli said he didn’t know any of the men charged, but believes they were hired by one of his enemies. And he said his would-be assailants didn’t just target him specifically.

“They had a list of people they wanted to hit consecutively as far as I know,” he said.

The foiled robbery is the latest drama tied to members of certain criminal hacking communities who are targeting one another with physical violence, by making a standing offer to pay thousands of dollars to anyone in the target’s region who agrees to carry out the assaults.

Last month, a 21-year-old New Jersey man was arrested and charged with stalking in connection with a federal investigation into groups of cybercriminals who are settling scores by hiring people to carry out physical attacks on their rivals.

Prosecutors say Patrick McGovern-Allen recently participated in several of these schemes — including firing a handgun into a Pennsylvania home and torching a residence in another part of the state with a Molotov Cocktail.

McGovern-Allen and the three U.K. defendants are part of an online community that is at the forefront of a dangerous escalation in coercion and intimidation tactics increasingly used by competing cybercriminal groups to steal cryptocurrency from one another and to keep their rivals in check.

The Telegram chat channels where these young men transact have hundreds to thousands of members each, and some of the more interesting solicitations on these communities are job offers for in-person assignments and tasks that can be found if one searches for posts titled, “If you live near,” or “IRL job” — short for “in real life” job.

A number of these classified ads are in service of performing “brickings,” where someone is hired to visit a specific address and toss a brick through the target’s window. Indeed, prior to McGovern-Allen’s arrest, his alleged Telegram persona bragged that he’d carried out several brickings for hire.

Many of the individuals involved in paying others to commit these physical attacks are also frequent participants in Telegram chat channels focused singularly on SIM swapping, a crime in which identity thieves hijack a target’s mobile phone number and use that to wrest control over the victim’s various online accounts and identities.

Unsurprisingly, the vast majority of people currently being targeted for brickings and other real-life physical assaults via Telegram tend to be other cybercriminals involved in SIM swapping crimes (or individuals on the periphery of that scene).

The United Kingdom is home to a number of young men accused of stealing millions of dollars worth of cryptocurrencies via SIM swapping. Joseph James O’Connor, a.k.a. “Plugwalk Joe”, was arrested in Spain in July 2021 under an FBI warrant on 10 counts of offenses related to unauthorized computer access and cyber bullying. U.S. investigators say O’Connor also played a central role in the 2020 intrusion at Twitter, wherein Twitter accounts for top celebrities and public figures were forced to tweet out links to cryptocurrency scams. O’Connor is currently fighting extradition to the United States.

Robert Lewis Barr, a 25-year-old Scottish man who allegedly stole more than $8 million worth of crypto, was arrested on an FBI warrant last year and is also fighting his extradition. U.S. investigators say Barr SIM swapped a U.S. bitcoin broker in 2017, and that he spent much of the stolen funds throwing lavish parties at rented luxury apartments in central Glasgow.

In many ways, these violence-as-a-service incidents are a natural extension of “swatting,” wherein fake bomb threats, hostage situations and other violent scenarios are phoned in to police as part of a scheme to trick them into visiting potentially deadly force on a target’s address. According to prosecutors, both Barr and O’Connor have a history of swatting their enemies and their SIM swapping victims.

Violence-as-a-Service: Brickings, Firebombings & Shootings for Hire

A 21-year-old New Jersey man has been arrested and charged with stalking in connection with a federal investigation into groups of cybercriminals who are settling scores by hiring people to carry out physical attacks on their rivals. Prosecutors say the defendant recently participated in several of these schemes — including firing a handgun into a Pennsylvania home and torching a residence in another part of the state with a Molotov Cocktail.

Patrick McGovern-Allen of Egg Harbor Township, N.J. was arrested on Aug. 12 on a warrant from the U.S. Federal Bureau of Investigation. An FBI complaint alleges McGovern-Allen was part of a group of co-conspirators who are at the forefront of a dangerous escalation in coercion and intimidation tactics increasingly used by competing cybercriminal groups.

Prosecutors say that around 2 a.m. on Jan 2, 2022, McGovern-Allen and an unidentified co-conspirator fired multiple handgun rounds into a residence in West Chester, Pa. Fortunately, none of the residents inside the home at the time were injured. But prosecutors say the assailants actually recorded video of the attack as “proof” that the shooting had been carried out.

A copy of that video was obtained by KrebsOnSecurity. According to investigators, McGovern-Allen was one of the shooters, who yelled “Justin Active was here” as they haphazardly fired at least eight rounds into the lower story of the West Chester residence.

On Dec. 18, 2021, police in Abington Township, Pa., responded to reports of a house fire from homeowners who said it sounded like something was thrown at their residence just prior to the fire.

Weeks later, on the day of the shooting in West Chester, a detective with the Westtown East Goshen Police Department contacted the Abington police and shared another video that was circulating on several online message boards that appeared to show two individuals setting fire to the Abington Township residence. The criminal complaint said the two police officers agreed the same suspect was present in both videos.

A copy of that video also was obtained by KrebsOnSecurity, and it shows at least two individuals smashing a window, then lighting a rag-soaked Mad Dog 20/20 grape wine bottle and hurling it at the side of the home [Update: My apologies for the file download link, but YouTube just deleted both of the videos included in this story — for allegedly violating their community standards].

“The Molotov cocktail caused the immediate surrounding area to ignite, including the siding of the house, grass, and the wooden chair,” the government’s complaint against McGovern-Allen states. “The two suspects then fled on foot toward the street and begin yelling something when the video stops.”

The government mentions the victims only by their initials — “K.M.” in the shooting and “A.R.” in the firebombing — but said both had been the target of previous harassment by rival cybercriminal groups that included swatting attacks, wherein the perpetrators spoof a distress call to the police about a hostage situation, suicide or bomb threat with the goal of sending a heavily-armed police response to a targeted address.

A number of previous swatting incidents have turned deadly. But these more “hands-on” and first person attacks are becoming increasingly common within certain cybercriminal communities, particularly those engaged in SIM swapping, a crime in which identity thieves hijack a target’s mobile phone number and use that to wrest control over the victim’s various online accounts and identities.

The complaint mentions a handle and user ID allegedly used by McGovern-Allen’s online persona “Tongue” on the Discord chat service, (user: “Tongue#0001”).

“In the chats, [Tongue] tells other Discord users that he was the person who shot K.M.’s house and that he was willing to commit firebombings using Molotov Cocktails,” the complaint alleges. “For example, in one Discord chat from March 2022, [the defendant] states ‘if you need anything done for $ lmk [“let me know”]/I did a shooting/Molotov/but I can also do things for ur entertainment.”

KrebsOnsecurity reviewed hundreds of chat records tied to this Tongue alias, and it appears both attacks were motivated by a desire to get back at a rival cybercriminal by attacking the female friends of that rival.

Recall that the shooters in the West Chester, Pa. incident shouted “Justin Active was here.” Justin Active is the nickname of an individual who is just as active in the same cybercriminal channels, but who has vehemently denied knowledge of or participation in the shooting. Justin Active said on Telegram that the person targeted in the shooting was his ex-girlfriend, and that the firebombing targeted another friend of his.

Justin Active has claimed for months that McGovern-Allen was responsible for both attacks, saying they were intended as an intimidation tactic against him. “DO THE PATRICK MCGOVERN ALLEN RAID DANCE!,” Justin Active’s alias “Nutcase68” shouted on Telegram on Aug. 12, the same day McGovern-Allen was arrested by authorities.

Justin Active’s version of events seems to be supported by a reference in the criminal complaint to an April 2, 2022 chat in which Tongue explained the reason for the shooting.

“The video/is [K]’s house/getting shit/shot/justin active/ was her current bf/ the reason it happened,” Tongue explained. “So that’s why Justin active was there.”

The Telegram chat channels that Justin Active and Tongue both frequented have hundreds to thousands of members each, and some of the more interesting solicitations on these communities are job offers for in-person assignments and tasks that can be found if one searches for posts titled, “If you live near,” or “IRL job” — short for “in real life” job.

A number of these classified ads are in service of performing “brickings,” where someone is hired to visit a specific address and toss a brick through the target’s window.

“If you live near Edmonton Canada dm me need someone bricked,” reads on Telegram message on May 31, 2022.

“If you live near [address redacted] Lakewood, CA, dm [redacted] Paying 3k to slash the tires,” reads another help wanted ad in the same channel on Feb. 24, 2022. “If you live near here and can brick them, dm [address omitted] Richland, WA,” reads another from that same day.

McGovern-Allen was in the news not long ago. According to a Sept. 2020 story from The Press of Atlantic City, a then 19-year-old Patrick McGovern Allen was injured after driving into a building and forcing residents from their home.

“Police found a 2007 Lexus, driven by Patrick McGovern-Allen, 19, that had lost control and left the road, crashing into the eastern end of the 1600 building,” the story recounted. “The car was driven through the steps that provide access to the second-floor apartments, destroying them, and also caused damage to the outer wall.”

A search on the Inmate Locator of the U.S. Bureau of Prisons website shows that McGovern-Allen remains in federal custody at a detention facility in Philadelphia. He’s currently represented by a public defender who has not responded to requests for comment.

A copy of the criminal complaint against McGovern-Allen is available here (PDF).

ANALYSIS

Many of the individuals involved in paying others to commit these physical attacks are also frequent participants in several Telegram channels focused singularly on SIM swapping activity. As a result, the vast majority of the people being targeted for brickings and other real-life physical assaults tend to be other cybercriminals involved in SIM swapping crimes (or individuals on the periphery of that scene).

There are dozens of SIM swappers who are now teenage or 20-something millionaires, by virtue of having stolen vast sums of cryptocurrencies from SIM swapping victims. And now many of these same individuals are finding that communities like Telegram can be leveraged to hire physical harassment and intimidation of their rivals and competitors.

The primary barrier to hiring someone to brick a home or slash some tires seems to be the costs involved: A number of solicitations for these services advertised payment of $3,000 or more upon proof of successful completion, which usually involves recording the attack and hiring a getaway driver in the town where the crime is to take place (calling a cab or hailing an Uber from the scene of a bricking isn’t the brightest idea).

My fear is these violence-as-a-service offerings will at some point migrate outside of the SIM swapping communities. This is precisely what happened with swatting, which for years was a crime perpetrated almost exclusively against online gamers and people streaming their games online. These days, swatting attacks are commonly used by SIM swapping groups as a way to harass and extort regular Internet users into giving up prized social media account names that can be resold for thousands of dollars.

The Family That Mined the Pentagon's Data for Profit

The Freedom of Information Act helps Americans learn what the government is up to. The Poseys exploited it—and became unlikely defenders of transparency.

“Downthem” DDoS-for-Hire Boss Gets 2 Years in Prison

A 33-year-old Illinois man was sentenced to two years in prison today following his conviction last year for operating services that allowed paying customers to launch powerful distributed denial-of-service (DDoS) attacks against hundreds of thousands of Internet users and websites.

Matthew Gatrel of St. Charles, Ill. was found guilty for violations of the Computer Fraud and Abuse Act (CFAA) related to his operation of downthem[.]org and ampnode[.]com, two DDoS-for-hire services that had thousands of customers who paid to launch more than 200,000 attacks.

Despite admitting to FBI agents that he ran these so-called “booter” services (and turning over plenty of incriminating evidence in the process), Gatrel opted to take his case to trial, defended the entire time by public defenders. Gatrel’s co-defendant and partner in the business, Juan “Severon” Martinez of Pasadena, Calif., pleaded guilty just before the trial.

After a nine-day trial in the Central District of California, Gatrel was convicted on all three counts, including conspiracy to commit unauthorized impairment of a protected computer, conspiracy to commit wire fraud, and unauthorized impairment of a protected computer.

Prosecutors said Downthem sold subscriptions allowing customers to launch DDoS attacks, while AmpNode provided “bulletproof” server hosting to customers — with an emphasis on “spoofing” servers that could be pre-configured with DDoS attack scripts and lists of vulnerable “attack amplifiers” used to launch simultaneous cyberattacks on victims.

Booter and stresser services let customers pick from among a variety of attack methods, but almost universally the most powerful of these methods involves what’s known as a “reflective amplification attack.” In such assaults, the perpetrators leverage unmanaged Domain Name Servers (DNS) or other devices on the Web to create huge traffic floods.

Ideally, DNS servers only provide services to machines within a trusted domain — such as translating an Internet address from a series of numbers into a domain name, like example.com. But DNS reflection attacks rely on consumer and business routers and other devices equipped with DNS servers that are (mis)configured to accept queries from anywhere on the Web.

Attackers can send spoofed DNS queries to these DNS servers, forging the request so that it appears to come from the target’s network. That way, when the DNS servers respond, they reply to the spoofed (target) address.

The bad guys also can amplify a reflective attack by crafting DNS queries so that the responses are much bigger than the requests. For example, an attacker could compose a DNS request of less than 100 bytes, prompting a response that is 60-70 times as large. This “amplification” effect is especially pronounced if the perpetrators query dozens of DNS servers with these spoofed requests simultaneously.

The government charged that Gatrel and Martinez constantly scanned the Internet for these misconfigured devices, and then sold lists of Internet addresses tied to these devices to other booter service operators.

“Gatrel ran a criminal enterprise designed around launching hundreds of thousands of cyber-attacks on behalf of hundreds of customers,” prosecutors wrote in a memorandum submitted in advance of his sentencing. “He also provided infrastructure and resources for other cybercriminals to run their own businesses launching these same kinds of attacks. These attacks victimized wide swaths of American society and compromised computers around the world.”

The U.S. and United Kingdom have been trying to impress on would-be customers of these booter services that hiring them for DDoS attacks is illegal. The U.K. has even taken out Google ads to remind U.K. residents when they search online for terms common to booter services.

The case against Gatrel and Martinez was brought as part of a widespread crackdown on booter services in 2018, when the FBI joined law enforcement partners overseas to seize 15 different booter service domains.

Those actions have prompted a flurry of prosecutions, with wildly varying sentences when the booter service owners are invariably found guilty. However, DDoS experts say booter and stresser services that remain in operation continue to account for the vast majority of DDoS attacks launched daily around the globe.

Technical Analysis of CVE-2021-1732

Introduction

In February 2021, the company Dbappsecurity discovered a sample in the wild that exploited a zero-day vulnerability on Windows 10 x64.

The vulnerability, CVE-2021-1732, is a win32k window object type confusion leading to an OOB (out-of-bounds) write which can be used to create arbitrary memory read and write capabilities within the Windows kernel (local Elevation of Privilege (EoP)). Memory exploitation generally requires a read, write, and execute primitive to bypass modern exploit mitigations such as DEP, ASLR and CFG on hardened operating systems such as Windows 10. A data-only attack requires only a read and write primitive as it does not seek to execute malicious code in memory, but rather manipulates data structures used by the operating system to its advantage (i.e., to achieve elevated privileges).

Kernel exploits are usually the most sophisticated attack as they interact directly with the Windows kernel. When such attacks are successful, they are critical because they provide high privileges to the attacker, which can be used to increase the impact of the overall exploit chain. In this case the exploit is a Local Privilege Escalation (LPE) that targets 64-bit Windows 10 version 1909. The original sample discovered was compiled in May 2020 and reported to Microsoft in December 2020. While searching for additional findings we went through a public exploit published in March of 2021 by a researcher. Having this code publicly available may raise the potential for additional threat attackers. While we have not found clear evidence demonstrating malicious use of the proof-of-concept (POC), we did discover some variants being tested and uploaded to VirusTotal.

In this blog post, McAfee Advanced Threat Research (ATR) performed a deep dive into the analysis of the vulnerability, to identify the primitives for detection and protection. The exploit is novel in its use of a new win32k arbitrary kernel memory read primitive using the GetMenuBarInfo API, which to the best of our knowledge had not been previously known publicly.

CVE-2021-1732 Deep Dive

Exploitation of CVE-2021-1732 can be divided into six stages with the end goal of escalating a process’ privileges to System. The following diagram shows the stages.

Before we dive into the details, we must give some background to win32k exploitation primitives which are used in the exploitation of CVE-2021-1732.

Win32K Background

Win32k is a Graphical (GUI) component of the Microsoft Windows Subsystem, most of which exists in the kernel for performance reasons. It is used for graphical print of the Windows OS desktop. However, due to the win32k architecture, the kernel component of win32k still needs to be able to make calls to user mode through user-mode callback functions to facilitate window creation and management.

Kernel user-mode callbacks have been well researched as far back as 2008 and 2010, with a very comprehensive analysis in 2011 by Mandt. A win32k kernel function such as xxxCreateWindowEx will make a callback function such as xxxClientAllocWindowClassExtraBytes through the user process PEB KernelCallbackTable.

When the user-mode callback has completed, NtCallbackReturn executes and passes the expected return parameter back to the kernel. Due to the stateless nature of these callbacks, many vulnerabilities have been discovered related to the locking mechanisms on the objects leading to use-after-free (UAF) exploitation.

Win32k has been one of the most exploited components in the Windows kernel accounting for 63% of vulnerabilities from 2010 to 2018, due to its large attack surface of syscalls relative to ntdll syscalls. Win32k vulnerabilities are generally turned into data-only attacks using a read/write kernel primitive by using a desktop object known as a tagWND data structure.

There are two aspects to data-only attacks:

1. Discovering a vulnerability.
2. Leveraging existing or new read/write primitives using specific OS APIs on object fields such as tagWND.cbWndExtra.

The tagWND data structure has two fields which make it a prime target for reading/writing within kernel memory; tagWND.cbWndExtra and tagWND.ExtraBytes. When a window is created using CreateWindowEx, it is possible to request additional bytes of memory directly after the tagWND object in memory through the cbWndExtra field in the WNDCLASSEXA structure when registering the window class.

The number of extra bytes is controlled by the cbWndExtra field, and the allocated additional memory address is located at the ExtraBytes field. The read/write primitive is created as follows:

1. Discover a vulnerability such as a UAF, which will allow you to write to a tagWND object in memory called WND0.
2. Allocate another tagWND object called WND1 near the previously corrupted WND0 in memory.
3. Overwrite WND0.cbWndExtra to a large value such as 0xFFFFFFF.
4. Call an API such as SetWindowLongPtr on WND0 which will write OOB to fields within WND1.

Win32k kernel user-mode callbacks have been exploited many times by leveraging tagWND read/write capabilities within the Windows kernel for escalation of privileges such as CVE-2014-4113, CVE-2015-0057, MS15-061, CVE-2016-7255 and CVE-2019-0808.

Win32k Exploit Primitives

Several primitives have been observed in the CVE-2021-1732 exploit used by the attackers; additionally, it is worth mentioning that some of them are new and not previously seen in the wild.

Prior to Windows RS4 it was trivial to leak tagWND kernel addresses using multiple techniques, such as calling HMValidateHandle to copy tagWND objects from the kernel to user desktop heap. The latest version of Windows 10 has been hardened against such trivial techniques.

However, using the spmenu kernel address leak technique and relative tagWND desktop heap offsets, once a vulnerability is discovered to overwrite a tagWND.cbWndExtra field, it is possible to achieve kernel read/write capabilities without leaking the actual tagWND kernel addresses. The spmenu technique in this exploit was used here and here, but we are not aware of the GetMenuBarInfo API ever being used before in a win32k exploit.

The following diagram shows the primitives used in CVE-2021-1732.

Existing Windows OS Mitigations

Great work has been done to harden the security of win32k against EoP attacks with new and improved mitigations by the Microsoft OSR team, Mandt, Google Project Zero, Schenk and Dabah.  These mitigations include:

1. Type isolation (all same type objects tagWND being used).
2. Win32k filtering (limited to Edge browser and not process wide but since this research there have been many improvements on win32k API filtering capabilities such as the addition of _stub_UserSetWindowLong and _stub_UserSetWindowLongPtr _stub_UserGetMenuBarInfo in win32k.sys).
3. Fragmenting kernel desktop heap and removal of kernel addresses in the user desktop heap (can use relative offsets within user and desktop heaps described later in the blog).
4. Removal of data type symbols from win32k drivers (obfuscation rather than mitigation).

In the context of a malicious process exploiting CVE-2021-1732, the above mitigations provide no protection. However, it does not impact Google Chrome as it disallows win32k calls (Windows 8 and higher), or Microsoft Edge as it applies win32k filtering on the relevant APIs.

Triggering the Vulnerability and Patch Analysis

When a window is created using CreateWindowEx API, a tagWND object is created by the Windows operating system. This window, as explained above, can be created with a parameter to allocate extra memory using cbWndExtra.

During the windows creation process (CreateWindowEx API) a callback named xxxClientAllocWindowClassExtraBytes is triggered to allocate space in the user mode desktop heap for the tagWND.ExtraBytes (offset 0x128) per the tagWND.cbWndExtra (offset 0xc8) value size (see figure 3 and 4 below for WND1).

The location of this memory is stored as a user mode memory pointer to the desktop heap and placed at tagWND.ExtraBytes. It is then possible to convert the normal window to a console window using NtUserConsoleControl which will convert that user mode pointer at tagWND.ExtraBytes to an offset value which points into the kernel desktop heap (see figure 5 below for WND0). It is this change in value at tagWND.ExtraBytes (window type confusion) that can be exploited for an OOB write during the xxxClientAllocWindowClassExtraBytes callback window.

Per figure 6 above the following steps are required to trigger the vulnerability:

1. Get a pointer to the HMValidateHandle inline function within user32.dll.
2. Hook xxxClientAllocWindowClassExtraBytes within the PEB KernelCallBack table.
3. Create multiple windows (we will just use the first two WND0 and WND1 created), using the CreateWindowEx API, so that two windows are created in close memory proximity.
4. Call HMValidateHandle on WND0 and WND1 which will copy their objects from the kernel desktop heap to user desktop heap. At tagWND+0x8 an offset is stored into the desktop heap; this offset is the same for the user and kernel desktop heaps. The exploit uses these offset values to calculate the relative distance between WND0 and WND1 in the kernel desktop heap which is needed later for reading and writing OOB. Per table 1 below, by using these offsets there is no requirement to leak the actual WND0 and WND1 kernel addresses since read and writes can be done relative to the offsets (user and kernel desktop heaps have the same offsets).

5. WND0 is then converted to a console window by calling NtUserConsoleControl which converts WND0.ExtraBytes from a user desktop heap pointer to an offset within the kernel desktop heap. This is needed later so that WND0 can write OOB to WND1.

6. Create malicious window WND_Malicious using the CreateWindowEx API

• • During the window creation the callback xxxClientAllocWindowClassExtraBytes API is executed to request user mode to allocate memory for WND_Malicious.cbWndExtra and pass the user desktop heap pointer back to the kernel function win32kfull!xxxCreateWindowEx.
  • xxxClientAllocWindowClassExtraBytes has now been hooked and we do the following before returning to win32kfull!xxxCreateWindowEx:
    • Call NtUserConsoleControl to convert WND_Malicious to a console window so converting its WND_Malicious.cbWndExtra from a user desktop heap pointer to an offset within the kernel desktop heap.
    • Finally call NtCallbackReturn which completes the callback and returns a single value to xxxClientAllocWindowClassExtraBytes. Instead of passing the user desktop heap pointer as expected by xxxClientAllocWindowClassExtraBytes back to the kernel we pass the value at WND0+0x08 which is the kernel desktop heap offset to WND0 per figure 7 below. Now anytime we call SetWindowLongW on WND_Malicious we will be writing to WND0.

Patch Analysis

The vulnerability lies in the fact that win32kfull!xxxCreateWindowEx does not check whether the window type has changed between the time it initiates the xxxClientAllocWindowClassExtraBytes and gets the response from NtCallbackReturn.

When we call NtUserConsoleControl with WND_Malicious in the hook above, xxxConsoleControl checks if tagWND+0xE8 flag has been set to 0x800 to indicate a console window per figure  below. As WND_Malicious was created as a normal window, xxxConsoleControl allocates memory at an offset within the kernel desktop heap and then frees the user desktop heap pointer existing at WND_Malicious.ExtraBytes (0ffset 0x128). It then places the offset to this new allocation in the kernel heap at WND_Malicious.ExtraBytes (0ffset 0x128) and sets the tagWND+0xE8 flag to 0x800 to indicate it’s a console window.

After returning from the callback when we issued NtCallbackReturn above, xxxCreateWindowEx does not check that the window type has changed and places the WND0+0x08 at WND_Malicious.ExtraBytes per figure 9 below. The RedirectFieldpExtraBytes checks the WND_Malicious.ExtraBytes initialized value but it is too late as WND0+0x08 has already been written to WND_Malicious.ExtraBytes (offset 0x128).

The patched win32kfull.sys has updated xxxCreateWindowEx to now check the ExtraBytes initialized value before writing the returned value from user mode to tagWND. ExtraBytes (offset 0x128) per figure 10 below.

Figure 11 below shows that tagWND. ExtraBytes is initialized to zero within xxxCreateWindowEx during normal window creation.

Figure 12 below shows that tagWND. ExtraBytes is initialized to the new offset value in the kernel desktop heap within xxxConsoleControl during console window creation. RedirectFieldpExtraBytes simply checks this initialized value to determine if the window type has changed. In addition, Microsoft have also added telemetry for detecting changes to the window type flag in the patched version.

tagWND OOB Write

The vulnerability within the xxxCreateWindowEx API allowed the WND_Malicious.ExtraBytes field be to set to a value of WND0 offset within the kernel desktop heap. Now any time SetWindowLongW is called on WND_Malicious it will write to WND0. By supplying an offset of 0xc8, the function will overwrite the WND0.cbWndExtra field to a large value of 0XFFFFFFF per figures 13 and 14 below.

This means it can write beyond its tagWND structure and ExtraBytes in kernel memory to fields within WND1. In addition, WND0.ExtraBytes is also overwritten with the offset to itself so calls to SetWindowLongPtrA on WND0 will write to an offset in kernel desktop heap relative to the start of WND0.

Kernel Address Leak

Now that the WND0.cbWndExtra field has been set to a very large value (0xFFFFFFF), anytime SetWindowLongPtrA is called on WND0 it will write into the adjacent WND1 in kernel memory per figure 15 below. By writing to specific fields in WND1 we can create a kernel address memory leak as follows:

1. Write a value of 0x400000000000000 to WND1 style field to temporarily change it to a child window per figures 15 and 16 below.
2. Calling SetWindowLongPtrA API on WND0 with a value of -12 (GWLP_ID) now allows the spmenu field (type tagMENU) of WND1 to be overwritten with a fake spmenu data structure since we have changed it to be a child window per figure 15 and 17 below.
3. Per SetWindowLongPtrA API documentation, the return value will give us the original value at the offset overwritten, i.e., the spmenu data structure pointer which is a kernel memory address. So, we now have leaked a pointer to a spmenu (type tagMENU) data structure in kernel memory and replaced the pointer in WND1.spmenu with a fake spmenu data structure within user desktop heap per figure 17 below.

Kernel Arbitrary Read

Using the spmenu data structure kernel pointer leaked previously we can use the layout of this data structure and the GetMenuBarInfo API logic to turn it into an arbitrary kernel memory read per figures 18,19 and 20 below.

As you can see from the xxxGetMenuBarInfo function in figures 21 and 22 below, by placing our leaked kernel address at the right location in our fake spmenu data structure we can create an arbitrary kernel memory read when calling GetMenuBarInfo.

Kernel Arbitrary Write

An arbitrary kernel write primitive can be easily achieved now by writing our destination address to WND1.ExtraBytes field by calling SetWindowLongPtrA on WND0 which will write OOB to WND1 relative to the offset we specify per figure 23 below

In this case the offset is 0x128 which is ExtraBytes. Then simply calling SetWindowLongPtrA on WND1 will write a specified value at the address placed in the WND1.ExtraBytes field. The arbitrary write is achieved because WND1 is a normal window (has not been converted to a console window like WND0 and WND_Malicious) and so will write to whatever address we place in WND1.ExtraBytes.

Data Only Attack

The arbitrary kernel read and write primitives can be combined to perform a data-only attack to overwrite a malicious process EPROCESS token with that of PID 4 which is System for an escalation of privilege (EoP).

The original spmenu kernel address leaked previously has a pointer to WND1 at offset 0x50 per figures 24 and 25 below. Through multiple arbitrary reads using the GetMenuBarInfo on our fake spmenu data structure with this WND1 kernel address we can eventually read the PID 4 System EPROCESS token.

By placing the destination address (malicious process EPROCESS token) at WND1.ExtraBytes then the subsequent call to SetWindowLongPtrA will write the value (PID 4 – System EPROCESS token) to that address per figures 26 and 27 below.

The exploit then restores overwritten data structure values once the EoP is complete to prevent a BSOD (Blue Screen of Death).

Conclusion

In this report, we undertook a deep analysis of CVE-2021-1732 which is a Local Privilege Escalation on Windows 10. Windows kernel data-only attacks are difficult to defend against, as once a vulnerability is discovered they use legitimate and trusted code through specific APIs to manipulate data structures in kernel memory.

The win32k component has been hardened through great work by Microsoft against read/write primitives, but there are still opportunities for exploitation due to its large attack surface (syscalls and callbacks) and lack of win32k filtering on a process-wide basis. It would also be great to see a system wide win32k filtering policy capability within Windows 10.

Patching is always the best solution for vulnerabilities, but a strong defense strategy such as threat hunting is also required where patching may not be possible, and to detect variants of vulnerabilities/exploits being used by campaigns.

The post Technical Analysis of CVE-2021-1732 appeared first on McAfee Blog.

The Bug Report – December 2021

Your Cybersecurity Comic Relief 

Why am I here? 

If you’re reading these words, CONGRATULATIONS! You’ve made it to 2022! And even better, you found your way to ATR’s monthly security digest where we discuss our favorite vulnerabilities of the last 30 days. Feel free to pat yourself on the back, get yourself a nice cup of coffee, tea, LaCroix (you fancy!) or if you’d rather choose violence, you can go straight for the energy drink. And now that we are comfortable and energized, let’s get rolling!  

CVE-2021-43798: Grafana path traversal

What is it? 

Per its Wikipedia entry, Grafana is a multi-platform open-source analytics and interactive visualization web application that is widely used in the industry, with paying customers such as Bloomberg, eBay, PayPal, etc. It was revealed in early December that a path traversal vulnerability allowed an attacker to access local files due to an improper sanitization of “../../../” in its plugin path.  

It also showcases one of the tightest disclosure timelines known to man:  

Who cares? 

Ok, we can hardly blame you for hearing about ANY vulnerabilities except for Log4Shell in the last 30 days.  However, if your organization is using this software, you probably should have followed the disclosure last month, lest your “/etc/passwd” files are now known to the whole internet. Beyond that, there are two interesting points you can ponder while swirling your eggnog in its glass (side-rant on the disgustingness of eggnog redacted). Given how easy it is to exploit, the mere fact of the vendor fixing the bug via their public GitHub seems to have been enough to bring attention to it and get public working POCs for this vulnerability in less than 3 days following the fix. If you’re curious about how more mature open-source code bases deal with this risk, projects like Chromium rely on a separate bug tracking infrastructure that can restrict who can access the bug reports (that will spell out the security risks and test cases) combined with public commit messages with simple phrasing meant to avoid attracting the attention on the security commits.  

Another interesting tidbit, the root cause of this bug is the misuse of a Go API to sanitize paths as discussed in this Twitter thread. It turns out the filepath.Clean function used to sanitize the input processed by the vulnerable code only removes excessive “../../” if the path is absolute. This is a common case of an API behaving as expected but leading to dangerous consequences. Do you know for sure the codebase of your organization is free of these problems? The impact of unpatched vulnerabilities here could be the accessing or leaking of extremely sensitive data.  *pondering becomes frantic*  

What can I do? 

Obviously update the software if you’re using it, and you can also use Sigma rules to detect attack attempts. In an ideal world, your analytics platform should not be exposed to the wide internet, unlike these 87k instances, among whose 16k are still vulnerable according to Shodan. At minimum make sure your Grafana instance is behind a .htaccess prompt or similar. From a development perspective, security testing and unit tests should be leveraged to ensure the filtering you are putting in place is working the way it is intended to. And in the grand scheme of things, if you are going to process untrusted user input, don’t wing the filtering and apply thoroughly audited code patterns rather than disabling the warnings of your security tool…  

 

The Gold standard 

“Does the walker choose the path, or the path the walker?” may have mused Garth Nix in his novel Sabriel. One thing is certain though, the path described above won’t be “walked” nor traversed by an attacker for the McAfee Network Security Platform (NSP) customers. These lucky fellows are already protected against path traversal attacks via a generic rule and can even be bestowed further protection with the creation of “custom attack” rules.  

CVE 2021-44228: Log4Shell 

What is it? 

Who could have known that parsing—and sometimes even executing—untrusted input was a bad idea? Well it turns out that Apache’s log4j logging code does exactly that, and if the logged string contains the magic characters $(jdni:…) it may even fetch and execute untrusted Java code. Iterations on this attack have also highlighted the possibility to leak local secrets stored in environment variables—such as AWS keys—and given the recursiveness of the processing, it also offers many ways to evade pattern-matching detection. 

Who cares? 

Pretty much everyone. You write Java and are into logging things? Yep, you should be on top of this. You use Java based applications/servlets? Well, there’s probably some logging of untrusted user input in there. Your corporate employer uses Java based appliances or services? Pour one for your SOC and IT folks who are probably having a blast over their holiday “break”. You get it, this problem impacts the whole industry, and in all likelihood, its effects will probably keep rippling out for the years to come. To make things worse, the bug is really easy to exploit. From pen testers to SOC analysts, “script-kiddies” to nation state actors, nearly everyone has begun to explore this attack vector and we have observed massive on-going attacks with a wide gamut of payloads, ranging from cryptominers to “rm -rf /*” payloads and even a broken attempt to spread the Mirai worm. The worst is likely yet to come.  

What can I do? 

“Stranger Things” taught us that “You can’t spell America without Erica.” Similarly, you can’t spell Apache without Patch. Sort of.  Upgrade! Micro-patch. Monitor traffic. Hint: if you’re internal-only application suddenly makes LDAP requests towards a remote server in a country you have no operations in, maybe something fishy is going on…  

If you like chaos and and/or you are having a hard time convincing IT of the importance of this bug, get permission to demonstrate it for them! Then, set strings you can control (user-agent, twitter name, wifi SSID, …) to this $(jdni:ldap…) magic value and make it point to an IP:Port you control (or a third party service like Canarytoken if you trust them). If you detect hits on that address, you can start having a fun conversation about the necessity of upgrading their tech stack with the owners of the incoming addresses. This is where asking for permission first becomes extremely important, as if you indiscriminately put the magic string all over the places to see what happens (as you may have seen on various social media platforms), it’s likely that eventually someone will reach out to have a “fun” conversation with you and ask about that funky user-agent of yours. Obviously, before pulling a stunt like this consider that the last thing you want for Christmas is a CFAA (Computer Fraud and Abuse Act) complaint delivered right to your doorstep.  

The Gold standard 

McAfee Enterprise customers are protected from many different angles (for the specifics, please visit this Knowledge Base article):  

• Expert Rules on Endpoint Security (ENS) can pick-up dangerous patterns in memory as described in this blog.  

• Endpoint Security (ENS), VirusScan Enterprise (VSE), McAfee Web Gateway (MWG) can provide generic detection under the tile Exploit-CVE-2021-44228.C via a “Potentially Unwanted Software” detection. This detection is also augmented by a list of hashes of samples related to in-the-wild campaigns exploiting this vulnerability.   
• Network Security Platform (NSP) can also detect the attack via User-Defined signature (provided in the KB article linked previously) 
• MVISION Endpoint Detection and Response (EDR), McAfee Active Response (MAR) can also be used to look for vulnerable systems with Real-Time Search (RTS) queries 
• McAfee SIEM got an update (Exploit Content Pack version 4.1.0) that will raise an alarm on potential exploit attempts. MVISION Insights is also providing valuable information under the Threat Campaign “Log4Shell – A Log4j Vulnerability – CVE-2021-44228”. See Insight Preview. 

CVE-2021-43527: Big Sig 

What is it? 

Big Sig sounds like the nickname Freud’s mother gave him. This bug is no less compelling. Early this December, Google Project Zero blogged about a vulnerability they found in Mozilla’s Network Security Services (NSS) with a CVSS score of 9.8, according to NIST’s National vulnerability database page. There is a heap overflow in the processing of certain signatures (DER-encoded DSA and RSA-PSS signatures). To put it simply, the NSS is a collection of cryptographic libraries that enable developers to use safer/heavily tested implementations of cryptographic primitives and standards (for encryption of communication, verification of the authenticity of data, and so on). The feature where the bug was found is responsible for the verification of signatures that prove the authenticity of data using various public cryptography schemes. This type of function is typically used to sign emails or documents to confirm their actual authors. Something really interesting about this bug is its relative simplicity but also its long existence; according to Project Zero’s blog, this bug was exploitable going all the back to 2012. The vulnerable code path just happened to fall between the cracks where various fuzzers used by Mozilla overlap. 

Who cares? 

If you like your signatures to be verified, and rely on the NSS library to do so, you should definitely have a look at the advisory and use the latest version of the software (NSS version 3.73/3.681 ESR or later). Firefox seems unaffected, but other software that parses signatures might be impacted (Thunderbird, LibreOffice, Evolution, Evince and more).  

What can I do? 

As usual, you want to make sure any software you are using that might be vulnerable is updated to its latest version. The patch was released on December 1st so, for starters, you’d want to make sure potential vulnerable software received an update after this date. It would also help to know which software relies on this library; while there is no magic bullet, references to files such as nss3.dll on Windows or libnss3.so on Linux are a good starting point. Beyond that, the best call is to look at release notes and potential list of third-party libraries used in any given application you may use. If you use the vulnerable library in in your own product, update the code or backport the patch. 

The Gold standard 

Have you checked out our bulletins? They’re a great source of information for the critical vulnerabilities you may have missed! This may include applications that will be deploying fixes for CVE-2021-43527. 

The post The Bug Report – December 2021 appeared first on McAfee Blog.

Log4Shell Vulnerability is the Coal in our Stocking for 2021

Overview:

On December 9th, a vulnerability (CVE-2021-44228) was released on Twitter along with a POC on Github for the Apache Log4J logging library. The bug was originally disclosed to Apache on November 24th by Chen Zhaojun of Alibaba Cloud Security Team. The impact of this vulnerability has the potential to be massive due to its effect on any product which has integrated the log4j library into its applications. This includes products from internet giants such as Apple iCloud, Steam, Samsung Cloud storage, but thousands of additional products and services will likely be vulnerable. This is just the beginning as Java is heavily used in applications spanning nearly every industry.

What is it?

The vulnerability exists in the way the Java Naming and Directory Interface (JNDI) feature resolves variables.  When a JNDI reference is being written to a log, JNDI will fetch all requirements to resolve the variable. To complete this process, it will download and execute any remote classes required. This applies to both server-side and client-side applications since the main requirements for the vulnerability are any attacker-controlled input field and this input being passed to the log.

To orchestrate this attack, an attacker can use several different JNDI lookups. The most popular lookup currently being seen in both PoCs and active exploitation is utilizing LDAP; however, other lookups such as RMI and DNS are also viable attack vectors.  It’s worth noting that the simplistic LDAP/RMI attack vectors only work with older JDK versions. There are publications that have demonstrated methods to circumvent this limitation to achieve code execution, albeit with added complexity to the attack.

Java object deserialization vulnerabilities are not a new breed of vulnerabilities or attacks. Previous offensive research such as “marshalsec” can be applied to this vulnerability making code execution simplistic.

**Update 12/20/2021** 

On December 18th, a new denial of service (DOS) vulnerability, CVE-2021-45105 was discovered affecting versions 2.0-alpha1 through 2.16.0 of Log4j.  To mitigate the original Log4j vulnerability, Apache completely disabled JNDI lookups in version 2.16, however self-referential lookups remained a possibility under non-default configurations.  When a nested variable is substituted by the StrSubstitutor class, it recursively calls the substitute() class. When this nested variable recursively references the variable being replaced, it leads to an infinite recursion and a DoS condition on the server.  Current research shows this does not lead to code execution, like the previous vulnerabilities.  

**** 

**Update 12/14/2021**

It has been confirmed that Log4j version 1.2 is vulnerable to similar attacks through the JMSAppender component and has been issued CVE-2021-4104. It is important to note this is not as easily exploitable as version 2.x. For exploitation to occur, JMSAppender must be enabled, and set with TopicBindingName or TopicConnectionFactoryBindingName configurations allowing JMSAppender to perform JNDI requests. This is not the default configuration.

****

What can be done about this?

**Update 12/20/2021** 

Apache has released a new version of Log4j, version 2.17.0 to address the latest DOS vulnerability.  Two additional classes were created that inherit from StrSubstitutor to deal with parsing strings that may contain user input.  These additions do not allow recursive evaluation.  Due to exploitation of this vulnerability leading to a DOS, it is considered less critical than the previously reported Log4j vulnerabilities which can lead to remote code execution. It is important to note, for exploitation to be successful there are several non-standard conditions that need to be met.  As the Log4j situation is continuing to evolve, we recommend upgrading to version 2.17.0, where possible. 

*****

**Update 12/14/2021**

Apache has released a new version of Log4j, version 2.16.0. This update disables JDNI by default requiring a user to explicitly turn the JNDI feature on and completely removes support for message lookups. When considering mitigations strategies for the Log4Shell vulnerabilities this should be considered the preferred method of mitigation.

****

There is a lot of information about different ways to mitigate this vulnerability. The most important and complete mitigation is to update log4j to the stable release version 2.17.0. Some sources are reporting that Java versions 6u211, 7u201, 8u191, and 11.0.1 are not vulnerable to this attack. This is not entirely the case. These versions are more resilient to the LDAP attack vector; however, they do not completely mitigate the vulnerability and are still susceptible to attack. To determine if a Java application is running a vulnerable version, a list of the impacted JAR files can be determined based on the hashes linked here.

The McAfee Enterprise ATR (Advanced Threat Research) team has been closely tracking this vulnerability since it became known. Our initial goal was to determine the ease of exploitation using the public PoC, which we have reproduced and confirmed. This was done using the public Docker container, and a client/server architecture leveraging both LDAP and RMI, along with marshalsec to exploit log4j version 2.14.1. We have posted a short video to demonstrate the reproduction for anyone who is struggling with this.

Going forward we plan to test variations of the exploit delivered using additional services such as DNS. We may update this document accordingly with results.

In the meantime, McAfee Enterprise has released a network signature KB95088 for customers leveraging NSP (Network Security Platform). The signature detects attempts to exploit CVE-2021-44228 over LDAP. This signature may be expanded to include other protocols or services, and additional signatures may be released to complement coverage.

Full coverage for this vulnerability can be tracked from our Security Bulletin here.

What’s out there?

Resources for the issue continue to evolve and expand rapidly. A growing list of PoCs and tools can be found here:

https://github.com/tangxiaofeng7/apache-log4j-poc

https://github.com/christophetd/log4shell-vulnerable-app

https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

https://www.greynoise.io/viz/query/?gnql=tags%3A%22Apache%20Log4j%20RCE%20Attempt%22

https://rules.emergingthreatspro.com/open/

https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes

https://github.com/corretto/hotpatch-for-apache-log4j2

https://github.com/nccgroup/log4j-jndi-be-gone

The post Log4Shell Vulnerability is the Coal in our Stocking for 2021 appeared first on McAfee Blog.

The Bug Report – November Edition

Your Cybersecurity Comic Relief 

CVE-2021-20322: Of all the words of mice and men, the saddest are, “it was DNS again.” 

Why am I here? 

For all our newcomers, welcome to the Advanced Threat Research team’s monthly bug report – a digest of all the latest and greatest vulnerabilities from the last 30-ish days based on merits just a tad more nuanced than sorting NVD by “CVSS > 9.0.” Instead, we focus on qualitative and experience-based analysis, relying on over 100 years of combined industry experience within our team. 

To those who are returning after having read last month’s issue, I would like to congratulate you for being a Bug Report fan before it was cool – which it now most assuredly is, thanks in no small part to a litany of fascinating vulnerabilities. We encourage our veterans to stick around as long as possible, so that a year from now you can complain about how we’re washed up and how much better our early editions were. 

PAN GlobalProtect VPN: CVE-2021-3064 

What is it? 

Palo Alto Networks (PAN) firewalls that use its GlobalProtect Portal VPN running PAN-OS versions older than 8.1.17 are vulnerable to a cutting-edge, state-of-the-art style of vulnerability known as a “stack-based buffer overflow.” Although the vulnerable code is normally not reachable, when combined with an HTTP smuggling vulnerability, CVE-2021-3064 can be used to gain remote code execution, a remote shell, and even access to sensitive configuration data according to Randori Attack Team researchers. Randori discovered the vulnerability over a year ago but chose not to disclose it to PAN until September of this year, using it as part of its “continuous and automated red team platform” during the interim – I suppose we should be thankful that PAN has claimed in its security advisory that no evidence of exploitation of this vuln has been discovered, despite its age. 

Who cares? 

Absence of “in-the-wild” exploitation aside, we should also be grateful that the number of people who should care is rapidly dwindling (an ever-present theme of 2021). Randori initially reported over 70,000 internet-accessible PAN firewalls running vulnerable versions of PAN-OS according to Shodan, which it later amended to 10,000. As of this writing, that number has fallen to around 7,000. Even so, 7,000 vulnerable firewalls mean an even larger number of vulnerable clients at risk of an over-the-internet attack vector requiring zero authentication. Those connecting to PAN firewalls running on VMs have even greater cause for concern as these lack ASLR, a factoid I have chosen to add to my ever-growing “why is that a thing” list, right next to the Ghostbusters remake. 

What can I do? 

We suggest an experiment: open the Shodan search linked above and note the total number of devices running a vulnerable version of PAN-OS. Next, call up whoever manages your firewall and demand they power it down immediately – use threats if you must. Check the Shodan scan again: has the number gone down? If so, it’s probably time to update. If you’re an Arch user and the prospect of updating terrifies you, Palo Alto has also indicated that its signatures for Unique Threat IDs 91820 and 91855 should block exploitation of CVE-2021-3064. 

The Gold Standard 

Be sure to stay up to date on the latest CVEs – our security bulletins are a great resource for finding product information for all kinds of critical vulnerabilities. 

Linux Kernel: CVE-2021-20322 

What is it? 

Researchers at the University of California, Riverside have discovered a flaw in the way the Linux kernel handles “ICMP fragment needed” and “ICMP redirect” errors, allowing an attacker to quickly learn the randomized port number assigned to a UDP socket. What this description fails to convey is the big picture impact of this vulnerability, which is its use as a side-channel for the now-prehistoric DNS cache poisoning attack, in which an off-path malicious actor ‘poisons’ a DNS resolver’s cache with a false record, mapping a known domain (google.com) to an IP address of their choosing (98.136.144.138). Truly nefarious. 

Who cares? 

To be frank, just about everyone should be at least raising an eyebrow at this one. Although the researchers have indicated in their whitepaper that this particular side-channel only affects about 13.85% of open resolvers on the internet, it’s important to note that various security services rely on proof of domain ownership, including even the issuing of certificates, making the impact tremendous. Users of popular DNS service Quad9 have particular cause for concern, as the paper claims it falls under the vulnerable 13.85%. Linux users should also be concerned, and not just because their drivers refuse to work – DNS software such as BIND, Unbound, and dnsmasq running on their platform of choice are also vulnerable. 

What can I do? 

This is where things get tricky. DNS extensions that were standardized over two decades ago, such as DNSSEC and DNS cookies, should successfully mitigate this and all other DNS cache poisoning attack side channels. The unfortunate reality is that these features see very limited adoption due to backwards-compatibility concerns. While we wait for these dinosaurs holding back progress to die out, the authors of the aforementioned whitepaper have suggested some alternative mitigations, including enabling the IP_PMTUDISC_OMIT socket option, introducing additional randomization to the structure of the DNS exception cache, and configuring DNS servers with a singular default gateway to outright reject ICMP redirects. Further details can be found in section 8.4 of their paper. 

The Gold Standard 

Unfortunately, not every vulnerability can be adequately addressed by network security products, and this vulnerability happens to be one of those cases. Your best bet is to follow the mitigations mentioned above and keep your servers up to date. 

Just About All DRAM: CVE-2021-42114 aka Blacksmith 

What is it? 

Blacksmith, a name referring to both the vulnerability and the fuzzer created to exercise it, is a new implementation of the Rowhammer DRAM hardware vulnerability from 2014. The crux of Rowhammer is the use of high frequency read operations to induce bit flips in neighboring regions of physical memory, which can lead to the crossing of any security barrier if the attacker can massage memory so that critical data is stored in a vulnerable physical page. Modern DRAM hardware uses a technology called Target Row Refresh (TRR) to prematurely refresh regions of physical memory targeted by common Rowhammer attacks. Researchers at ETH Zurich and their associates discovered that TRR exploits the uniform nature of memory accesses used by existing Rowhammer attacks to “catch” them, and so devised a Rowhammer attack that used non-uniform accesses, arriving at CVE-2021-42114, which bypasses TRR and all other modern Rowhammer mitigations. 

Who cares? 

Everyone. Just about every common electronic device you can think of uses DRAM and of the DIMMs (RAM sticks) tested, the researchers did not find a single one that was completely safe. It might be easy to presume that hardware vulnerabilities such as this are academically fascinating but have little real-world impact, but research published since 2014 has shown Rowhammer attacks successfully escape JavaScript containers in the browser, cross VM boundaries in the cloud, and even achieve RCE across networks with high enough throughput. Perhaps the greatest tragedy of Blacksmith is that it arrived a month too late – it would have fit in perfectly with Halloween monsters like Freddy Krueger or Jason Voorhees who also see new iterations every few years and refuse to stay dead. 

What can I do? 

Hide your PC, hide your tablet, and hide your phone, ‘cause they’re hammerin’ everybody out there. Beyond that, there’s not much to be done besides wait for JEDEC to develop a fix and for DRAM manufacturers to begin supplying hardware with the new standard. 

The Gold Standard 

We at McAfee Enterprise are doing everything in our power to address this critical vulnerability. In other words, we’ll be waiting for that JEDEC fix right along with you. 

The post The Bug Report – November Edition appeared first on McAfee Blog.

Zero Care About Zero Days

The time to repurpose vulnerabilities into working exploits will be measured in hours and there’s nothing you can do about it… except patch

By Fred House

2021 is already being touted as one of the worst years on record with respect to the volume of zero-day vulnerabilities exploited in the wild. Some cite this as evidence of better detection by the industry while others credit improved disclosure by victims. Others will simply conclude that as the “upside” grows (e.g., REvil demanding $70M or Zerodium paying $2.5M for exploits) so too will the quantity and quality of players. But the scope of these exploitations, the diversity of targeted applications, and ultimately the consequences to organizations were notable as well. As we look to 2022, we expect these factors to drive an increase in the speed at which organizations respond.

If we look back at the past 12 months, we have seen notable breaches that highlight the need for organizations to improve response times:

ProxyLogon. When we first learned in 2020 that roughly 17,000 SolarWinds customers were affected, many reacted in shock at the pure scope of the compromise (it should be noted that a small subset of these customers are believed to have been compromised by follow-on activity). Unfortunately, 2021 brought its own notable increase in volume. Two weeks after Microsoft released a patch for ProxyLogon they reported that 30K Exchange servers were still vulnerable (less conservative estimates had the number at 60K).

ProxyShell. ProxyShell, a collection of three separate vulnerabilities (CVE-2021-31207, CVE-2021-34473 and CVE-2021-34523), was Exchange’s second major event of the year after ProxyLogon. In August, a Black Hat presentation outlining Exchange Server vulnerabilities was followed the next day by the release of an exploit POC, all of which had been patched by Microsoft months earlier in April/May. This analysis of data captured by Shodan one week after the exploit POC was released concluded that over 30K Exchange servers were still vulnerable, noting that the data may have underrepresented the full scope (i.e., Shodan hadn’t had time to scan the full Internet). In summary: patched in the Spring, exploited in the Fall. So, what happened in the interim you ask? The vulnerabilities in the Microsoft Client Access Service were exploited by threat actors who deployed web shells to execute arbitrary code on compromised mobile devices and web browsers.

vCenter Server. Another notable example occurred in May when VMWare released a patch for a remote code execution vulnerability in vCenter Server. This subsequent analysis concluded that over 4,000 systems remained vulnerable one week after the patch was released. Much like Exchange servers, where a typical company will only host a handful of servers, 4,000 vulnerable vCenter servers likely represents thousands of distinct companies.

Kaseya VSA. One bright spot may in fact be the Kaseya VSA breach. On July 2, REvil launched an unprecedented (anyone else tired of that word?) ransomware campaign against public facing VSA servers. Within two days the DIVD CSIRT reported that the number of exposed VSA servers had dropped from 2,200 to 140. Some estimates suggested that around 50 MSPs were compromised, affecting between 800 and 1500 business. While this doesn’t sound like much of a bright spot, patching 94% of the affected systems in two days surely helped reduce the success of REvil copycats.

So, what can we take away from all of this? Well, attackers and security researchers alike will continue to hone their craft until weaponized exploits and POCs are expected within hours of vulnerability disclosure. In turn however, and largely driven by the increased consequences of compromise, we can also expect renewed diligence around asset and patch management. From identifying public facing assets to quickly deploying patches despite potential business disruption, companies will have a renewed focus on reducing their “time to patch.”

Still not convinced? Well, the US government is. Checkout Binding Operational Directive 22-01 published on November 3^rd which compels all federal agencies to remediate known exploited vulnerabilities in two weeks or sooner “in the case of grave risk to the Federal Enterprise”. It’s no coincidence that CISA’s known exploited vulnerabilities catalog, which catalogues the vulnerabilities that must be remediated, includes every one of our examples above with a two-week remediation deadline. If the US government can do it, you can too!

The post Zero Care About Zero Days appeared first on McAfee Blog.

Cloud API Services, Apps and Containers Will Be Targeted in 2022

McAfee Enterprise and FireEye recently teamed to release their 2022 Threat Predictions. In this blog, we take a deeper dive into cloud security topics from these predictions focusing on the targeting of API services and apps exploitation of containers in 2022.

5G and IoT Traffic Between API Services and Apps Will Make Them Increasingly Lucrative Targets

Recent statistics suggest that more than 80% of all internet traffic belongs to API-based services. It’s the type of increased usage that grabs the attention of threat developers hunting for rewarding targets.

Feature-rich APIs have moved from being just a middleware to applications and have evolved to become the backbone of most modern applications that we consume today. Examples include:

• 5G mobile applications – 5G connectivity and deployment of IoT endpoints have increased dramatically providing higher capacity for broader connectivity needs.
• Internet of Things – More than 30.9 billion IoT devices are expected to be in use worldwide by 2025. The industrial IoT market was predicted to reach $124 billion in 2021
• Dynamic web-based productivity suites – Global cloud-based office productivity software market is expected to reach $50.7 billion by 2026

In most cases, attacks targeting APIs go undetected as they are generally considered as trusted paths and lack the same level of governance and security controls.

The following are some of the key risks that we see evolving in the future:

1. Misconfiguration of APIs resulting in unwanted exposure of information.
2. Exploitation of modern authentication mechanisms such as Oauth/Golden SAML to obtain access to APIs and persist within targeted environments.
3. Evolution of traditional malware attacks to use more of the cloud APIs, such as the Microsoft Graph API, to land and expand. We have already seen evidence of this in the SolarWinds attack as well as other threat actors such as APT40/ GADOLINIUM.
4. Potential misuse of the APIs to launch attacks on enterprise data, such as ransomware on cloud storage services like OneDrive, etc.
5. The usage of APIs for software-defined infrastructure also means potential misuse leading to complete infrastructure takeover or shadow infrastructure being created for malicious purposes.

Gaining visibility into application usage with the ability to look at consumed APIs should be a priority for organizations, with the goal of ultimately having a risk-based inventory of accessed APIs and a governance policy to control access to such services. Having visibility of non-user-based entities within the infrastructure such as service accounts and application principles that integrate APIs with the wider enterprise eco-system is also critical.

For developers, developing an effective threat model for their APIs and having a Zero Trust access control mechanism should be a priority alongside effective security logging and telemetry for better incident response and detection of malicious misuse.

Expanded Exploitation of Containers Will Lead to Endpoint Resource Takeovers

Containers have become the de facto platform of modern cloud applications. Organizations see benefits such as portability, efficiency and speed which can decrease time to deploy and manage applications that power innovation for the business. However, the accelerated use of containers increases the attack surface for an organization. Which techniques should you look out for, and which container risk groups will be targeted? Exploitation of public-facing applications (MITRE T1190) is a technique often used by APT and Ransomware groups. MITRE T1190 has become a common entry vector given that cyber criminals are often avid consumers of security news and are always on the lookout for a good exploit. There are numerous past examples in which vulnerabilities concerning remote access software, webservers, network edge equipment and firewalls have been used as an entry point.

The Cloud Security Alliance (CSA) identified multiple container risk groups including:

• Image risks
  • vulnerabilities
  • configuration defects
  • embedded malware
  • embedded clear text secrets
  • use of untrusted secrets
• Orchestrator
  • unbounded administrative access
  • unauthorized access
  • poorly separated inter-container network traffic
  • mixing of workload sensitivity levels
  • orchestrator node trust
• Registry
  • insecure connections to registries
  • stale images in registries
  • insufficient authentication and authorization restrictions
• Container
  • vulnerabilities within the runtime software
  • unbounded network access from containers
  • insecure container runtime configurations
  • app vulnerabilities
  • rogue containers
• Host OS Component
  • large attack surface
  • shared kernel
  • improper user access rights
  • host file system tampering
• Hardware

How do you protect yourself? Recommended mitigations include bringing security into the DevOps process through continuous posture assessment for misconfigurations, checks for integrity of images, and controlling administrative privileges. Use the Mitre ATT&CK Matrix for Containers to identify gaps in your cloud security architecture.

The post Cloud API Services, Apps and Containers Will Be Targeted in 2022 appeared first on McAfee Blog.

Windows RDP Client Porting Critical Vulnerabilities to Hyper-V Manager

This month brings us yet another critical RCE (Remote Code Execution) bug found in the RDP (Remote Desktop Protocol) Client which has also been ported to the Hyper-V Manager “Enhanced Session Mode” feature. User interaction is a prerequisite since the vulnerability lies within the RDP client, requiring a victim to connect to a malicious RDP server.

Vulnerability Analysis: CVE-2021-38666

This RCE bug is very closely related to CVE-2021-34535 and to CVE-2020-1374 , where there is a heap-based buffer overflow in mstscax.dll due to an attacker-controlled payload size field. The vulnerability can be triggered via the RDP Smart Card Virtual Channel Extension feature [MS-RDPESC], by leveraging the existing local RDPDR static virtual channel setup between the client and server. The RDP Smart Card Virtual Channel Extension feature [MS-RDPESC] functionality was leveraged in the “EsteemAudit” Exploit released by the “Shadow Brokers,” but that vulnerability targeted the RDP server and not the client. The functionality being exploited here is the ability to share a smart card reader between the client and server. The destination buffer intended for the IOCTL (I/O control) call to locate each host smart card reader is a fixed size, but the user-controlled size field can be altered to cause the client to perform an OOB (Out of Bounds) write. Seeing how simple it is to trigger this vulnerability, our team decided to mutate the test case to verify whether any other IOCTLs within the [MS-RDPESC] specification are vulnerable. Enumerating through the 60 other IOCTL calls tied to the smart card reader, we were able to find two additional unique crashes. All vulnerabilities discovered have been patched in the latest version of the mstscax.dll, which shows that the fix for this bug has mitigated other potentially vulnerable functions. The patched mstscax.dll now simply verifies that the bytes received over the wire do not exceed the user-supplied size field; it does this at the IOCTL dispatch table level before any IOCTL functions are called, so the single validation is applied to all IOCTLs.

This vulnerability has a CVSS (Common Vulnerability Scoring Standard) score of 8.8, dropped down from 9.8 because it requires user interaction in that a victim RDP client must connect to a malicious server.

Attack Scenario

This bug has the same attack scenario as that of CVE-2021-34535, which we also analyzed in depth:

1. It is a client-side vulnerability so not wormable
2. Requires a user to connect to a malicious RDP server
3. It impacts both the traditional RDP client over the network and the local Hyper-V Manager “Enhanced Session Mode” since they both use the vulnerable mstscax.dll
4. The vulnerability could be used for a guest-to-host escape on Hyper-V Windows 10

Looking Forward

We have seen a regular cadence of critical RDP vulnerabilities since BlueKeep (CVE-2019-0708), but what distinguishes the two vulnerabilities CVE-2021-38666 and CVE-2021-34535 is that they impact Hyper-V Manager “Enhanced Session Mode” and can thus be leveraged for guest-to-host escapes. While we do not rate these vulnerabilities as critical in the same manner as past RDP server-side RCE vulnerabilities, we are now clearly starting to see a trend of vulnerabilities emerging which impact Hyper-V Manager due to the porting of RDP. We recommend patching as a top priority as threat actors will potentially look to weaponize this common protocol for guest-to-host escapes on Windows 10 Hyper-V.

Microsoft has published a Knowledge Base article for this issue here with information regarding patching this vulnerability. As always, we recommend patching as a first course of action and we will continue to monitor this vulnerability for any exploitation in the wild.

For RDP security best practices please see: https://www.mcafee.com/blogs/other-blogs/mcafee-labs/rdp-security-explained/

The post Windows RDP Client Porting Critical Vulnerabilities to Hyper-V Manager appeared first on McAfee Blog.

‘Tis The Season for Holiday Cyber Threats Targeting Enterprises in a Pandemic World

The holiday season is upon us, and many are preparing to celebrate with family and friends both near and far. While we tend to look at consumer tendencies during the holidays, the season also presents a significant challenge to industries coping with the increase in consumer demands. McAfee Enterprise and FireEye recently conducted a global survey of IT professionals to better understand their cyber readiness, especially during peak times like the holiday season, and the impact the pandemic has had on their business. Most notably, 86% of organizations are anticipating a moderate-to-substantial increase in demand during the 2021 holiday season. The question is: Are they ready for that demand?

This year, the “everything shortage” is real – from a drop in available workforce to limited supplies to lack of delivery services. This creates an urgency for organizations to have actionable security plans and to effectively contain and respond to threats. Supply chain and logistics, e-commerce and retail, and the travel industry traditionally experience holiday seasonal increases in consumer and business activity, making them more vulnerable to cyber threats and leaving business, employee, and consumer data at risk. Here’s a statistical snapshot of these affected industries and how they can prepare for the anticipated increase in seasonal risks:

Supply Chain and Logistics

According to BCI’s Supply Chain Resilience Report 2021, 27.8% of organizations reported more than 20 supply chain disruptions during 2020, up from just 4.8% reporting the same number in 2019. The loss of manufacturing and logistics capacity, and employee-power in 2021 are expected to increase demand for goods, creating the perfect attack vector for cybercriminals: a potentially weak and vulnerable infrastructure to break through. Supply chain managers must identify risks, understand the potential downstream effects of a security breach or cyberattack, and prepare response plans so they can act quickly in the event of an incident.

E-Commerce and Retail

According to Adobe’s 2021 Digital Economy Index, global online spending is expected to increase by 11% in 2021 to $910 billion during the holiday season. With store closures and increases in online shopping, along with limited product availability and concerns about shipping, this industry is faced with more threats than before. According to McAfee Enterprise COVID-19 dashboard, the global retail industry accounts for 5.2% of the total detected cyber threats. Such threats include compromised payment credentials and cloud storage, as well as other forms of retail fraud and theft.

Travel

Cyber threats aren’t new to the travel industry with airports, airlines, travel sites and ride-sharing apps having been victims in years past. However, what sets this year apart is the travel industry enduring a holding pattern caused by pandemic-related health concerns and travel restrictions. According to the International Air Transport Association (IATA), coronavirus-related loss estimates for 2020 total $137.7 billion—with total industry losses in 2020-2022 expected to reach $201 billion. As demand for holiday travel is expected to increase over the coming months, cyber criminals are watching closely for vulnerabilities as the industry battles new related challenges – labor shortages, supply chain issues, travel bans, and vaccination requirements.

What Organizations Need to Know

McAfee Enterprise and FireEye threat findings unwrap the imminently crucial need for organizations to prioritize and strengthen their cybersecurity architecture through the holidays and end of 2021. Our research indicates that 81% of global organizations experienced increased cyber threats and 79% experienced downtime in the wake of previous cyberattacks.

While IT professionals know cyber threats have intensified, the findings prove that many organizations have not effectively prioritized security during COVID-19:

• 94% percent of IT professionals want their organization to improve its overall cyber readiness
• 60% saw an increase in online/web activity
• 33% have had their technology and security budgets reduced
• 56% have suffered from downtime due to a cyber concern, costing some over $100,000 USD
• 76% find maintaining a fully staffed security team/SOC even more challenging during peak periods

Proactively Guarding Against Emerging Holiday Threats

Organizations can be proactive in defending their networks, data, customers, and employees against the anticipated increase in holiday cybercrime by implementing security measures including, but not limited to:

1. Adopt industry-wide cybersecurity requirements designed to protect against the latest iterations of cyber threats, especially those known to target specific industries.
2. Provide cybersecurity awareness training for employees, especially when encountering holiday phishing emails or texts and suspicious URL campaigns designed to breach organizational databases
3. Develop an incident response plan capable of responding and remedying a security breach in minutes rather than hours

In addition, enterprises and commercial businesses can implement cloud-delivered security with MVISION Unified Cloud Edge (UCE) and FireEye Extended Detection and Response (XDR).

 Note: The research was conducted between September- October 2021 by MSI-ACI via an online questionnaire to 1,451 IT Security Professionals from nine countries.

The post ‘Tis The Season for Holiday Cyber Threats Targeting Enterprises in a Pandemic World appeared first on McAfee Blog.

Who Will Bend the Knee in RaaS Game of Thrones in 2022?

McAfee Enterprise and FireEye recently released its 2022 Threat Predictions. In this blog, we take a deeper dive into a Game of Thrones power struggle among Ransomware-as-a-Service bad actors in 2022.

Prediction: Self-reliant cybercrime groups will shift the balance of power within the RaaS eco-kingdom. 

For several years, ransomware attacks have dominated the headlines as arguably the most impactful cyber threats. The Ransomware-as-a-Service (RaaS) model at the time opened the cybercrime career path to lesser skilled criminals which eventually led to more breaches and higher criminal profits.

For a long time, RaaS admins and developers were prioritized as the top targets, often neglecting the affiliates since they were perceived as less skilled. This, combined with the lack of disruptions in the RaaS ecosystem, created an atmosphere where those lesser-skilled affiliates could thrive and grow into very competent cybercriminals, eventually with a mind of their own.

In a response to the Colonial Pipeline attack, the popular cybercrime forums have banned ransomware actors from advertising. Now, the RaaS groups no longer have a third-party platform on which to actively recruit, show their seniority, offer escrow, have their binaries tested by moderators, or settle disputes. The lack of visibility has made it harder for RaaS groups to establish or maintain credibility and will make it harder for RaaS developers to maintain their current top tier position in the underground.

These events have undermined their trusted position. Ransomware has generated billions of dollars in recent years and it’s only a matter of time before more individuals who believe they aren’t getting their fair share become unhappy.

The first signs of this happening are already visible as described in our blog on the Groove Gang, a cyber-criminal gang that branched off from classic RaaS to specialize in computer network exploitation (CNE), exfiltrate sensitive data and, if lucrative, partner with a ransomware team to encrypt the organization’s network. McAfee Enterprise ATR believes, with high confidence, that the Groove gang is associated with the Babuk gang, either as a former affiliate or subgroup. These cybercriminals are happy to put aside previous Ransomware-as-a-Service hierarchies to focus on the ill-gotten gains to be made from controlling victim’s networks, rather than the previous approach which prioritized control of the ransomware itself.

Trust in a few things remains important even among cybercriminals underground, such as keeping your word and paying people what they deserve. Cybercriminals aren’t immune from feeling like employees whose contributions aren’t being adequately rewarded. When this happens, these bad actors cause problems within the organization. Ransomware has been generating billions of dollars in recent years and with revenue like that, it was inevitable that some individuals who believe they aren’t getting their fair share become unhappy and let the cybercrime world know it.

Recently, a former Conti affiliate was unhappy with their financial portion and decided to disclose the complete Conti attack playbook and their Cobalt Strike infrastructure online. In the past, McAfee ATR has been approached by individuals affiliated with certain RaaS groups expressing grudges with other RaaS members and admins, claiming they haven’t been paid in time or that their share wasn’t proportionate to the amount of work they put in.

In 2022, expect more self-reliant cybercrime groups to rise and shift the balance of power within the RaaS eco-climate from those who control the ransomware to those who control the victim’s networks.

Less-skilled Operators Won’t Have to Bend the Knee in RaaS Model Power Shift

The Ransomware-as-a-Service eco system has evolved with the use of affiliates, the middlemen and women that work with the developers for a share of the profits. While this structure was honed during the growth of GandCrab, we are witnessing potential chasms in what is becoming a not-so-perfect union.

Historically, the ransomware developers, held the cards, thanks to their ability to selectively determine the affiliates in their operations, even holding “job interviews” to establish technical expertise. Using CTB locker as an example, prominence was placed on affiliates generating sufficient installs via a botnet, exploit kits or stolen credentials. But affiliates recently taking on the role and displaying the ability to penetrate and compromise a complete network using a variety of malicious and non-malicious tools essentially changed the typical affiliate profile towards a highly skilled pen-tester/sysadmin.

The hierarchy of a conventional organized crime group often is described as a pyramid structure. Historically, La Cosa Nostra, drug cartels and outlaw motor gangs were organized in such a fashion. However, due to further professionalization and specialization of the logistics involved with committing crime, groups have evolved into more opportunistic network-based groups that will work together more fluidly, according to their current needs.

While criminals collaborating in the world of cybercrime isn’t new, a RaaS group’s hierarchy has been more rigid compared to other forms of cybercrime, due to the power imbalance between the group’s developers/admins and affiliates. But things are changing. RaaS admins and developers were prioritized as the top targets, but often neglected the affiliates who they perceived to be less-skilled. This, combined with the lack of disruptions in the RaaS ecosystem, created an atmosphere where those lesser-skilled affiliates could thrive and grow into very competent cybercriminals.

As more ransomware players have entered the market, we suspect that the most talented affiliates are now able to auction their services for a bigger part of the profits, and maybe demand a broader say in operations. For example, the introduction of Active Directory enumeration within DarkSide ransomware could be intended to remove the dependency on the technical expertise of affiliates. These shifts signal a potential migration back to the early days of ransomware, with less-skilled operators increasing in demand using the expertise encoded by the ransomware developers.

Will this work? Frankly, it will be challenging to replicate the technical expertise of a skilled penetration tester, and maybe – just maybe – the impact will not be as severe as recent cases.

The post Who Will Bend the Knee in RaaS Game of Thrones in 2022? appeared first on McAfee Blog.

The Bug Report – October Edition

Your Cyber Security Comic Relief

Apache server version 2.4.50 (CVE-2021-42013)

Why am I here?

Regardless of the origins, you’ve arrived at Advanced Threat Research team’s monthly bug digest – an overview of what we believe to be the most noteworthy vulnerabilities over the last month. We don’t rely on a single scoring system like CVSS to determine what you need to know about; this is all about qualitative and experience-based analysis, relying on over 100 years of combined industry experience within our team. We look at characteristics such as wormability, ubiquity of the target, likelihood of exploitation and impact.  If you don’t agree with these picks, we encourage you to write a strongly worded letter to your local senator. In lieu of that, we present our top CVEs from the last month.

Apache: CVE-2021-41773 and CVE-2021-42013

What is it?
2 CVES / 1 Vuln – It appears Apache struggled a bit with this latest critical vulnerability, where it took two tries to fix a basic path traversal bug, which was introduced while patching last month’s SSRF mod_proxy vulnerability. As path traversal bugs do, this allows unauthorized users to access files outside the expected document root on the web server. But wait, there’s more! This can lead to remote code execution provided mod-cgi is enabled on the server.

Who cares?
A quick Shodan scan told me there are at least 111,000 server admins that should care! With Apache being the second largest market share holder of implemented webservers, there is a good chance your organization is using it somewhere. It’s always important to consider both internal and external facing assets when looking at your exposure. Apache is even commonly used as an embedded webserver to other applications and should be reviewed for use in any installed 3^rd party applications. Oh yeah – and if you overlook an instance you have installed somewhere, this IS currently being actively exploited in the wild – no pressure.

What can I do?
Oh! I know, use Microsoft IIS! If you’re not ready to completely abandon your webserver implementation, I suggest updating to Apache 2.4.51. Remember to avoid version 2.4.50 as it does not patch both vulnerabilities. If you have been an astute system admin and followed the Apache documentation using the default and pretty darn secure “require all denied” directive for all files outside the document root, kudos to you! Although patching is still highly recommended, you are not immediately vulnerable.

The Gold Standard
We recognize in some special cases patching is harder than compiling gcc from source, so McAfee Enterprise has you covered; we have been detecting path traversal attacks in our Network Security Platform (NSP) like it was going out of style since 1990 (and it was).

Win32k Driver: CVE-2021-40449

What is it?
Ain’t nothin’ free anymore! Except kernel module addresses on your Windows machines, thanks to Microsoft Windows CVE-2021-40449. This vulnerability is a use-after-free in the NtGdiResetDC function of the Win32k driver and can lead to attackers being able to locally elevate their privileges.

Who cares?
Are you currently reading this from a Microsoft Windows machine? Using Microsoft Server edition in your cloud? Local attacks are often given lower priority or downplayed. However, it is important to recognize that phishing attacks are still highly successfully as an initial point of entry, facilitating a need for privilege escalation bugs to obtain higher level access. So, unless you are a hardcore Linux and Mac-only shop, you may want to patch since this is actively being exploited by cybercriminals, according to our friends at Kaspersky.

What can I do?
That boring Microsoft patch Tuesday thing still works, or you could just use a superior operating system like FreeBSD.

The Gold Standard
Have you checked out the latest version of McAfee Enterprise ENS lately? Detecting exploitation and cybercriminal activity is sort of its thing, assuming you have grabbed the latest signatures.

Apple iOS: CVE-2021-30883

What is it?
An integer overflow vulnerability in the iOS “IOMobileFrameBuffer” component can allow an application to execute arbitrary code with kernel privileges. This has additionally been confirmed to be accessible from the browser.

Who cares?
Since Apple still reportedly holds 53% market share of all smartphone users, statistically speaking your organization should care too. It only takes one bad apple to hack your entire network, and with reported active exploitation in the wild it might happen sooner than you think.

What can I do?
You should be sensing a common theme in this section – and, in this case, you actually can take action! Stop reading this, plug that mobile device into a power source, and install the latest version of Apple iOS.

The Gold Standard
Since you stopped reading and updated already, congrats!

The post The Bug Report – October Edition appeared first on McAfee Blog.

Nation States Will Weaponize Social and Recruit Bad Guys with Benefits in 2022

McAfee Enterprise and FireEye recently released its 2022 Threat Predictions. In this blog, we take a deeper dive into the continuingly aggressive role Nation States will play in 2022.

Prediction: Lazarus Wants to Add You as a Friend

By Raj Samani

We love our social media. From beefs between popstars and professional pundits, to an open channel to the best jobs in the industry.

But guess what?

The threat actors know this, and our appetite toward accepting connections from people we have never met are all part of our relentless pursuit of the next 1,000 followers.

A result of this has seen the targeting of executives with promises of job offers from specific threat groups; and why not? After all, it is the most efficient method to bypass traditional security controls and directly communicate with targets at companies that are of interest to threat groups. Equally, direct messages have been used by groups to take control over influencer accounts to promote messaging of their own.

While this approach is not new, it is nearly as ubiquitous as alternate channels. After all, it does demand a level of research to “hook” the target into interactions and establishing fake profiles are more work than simply finding an open relay somewhere on the internet. That being said, targeting individuals has proven a very successful channel, and we predict the use of this vector could grow not only through espionage groups, but other threat actors looking to infiltrate organizations for their own criminal gain.

Potential Impacts & Implications
The potential impacts and implications for an executive or company that had their social media channels targeted by threat actors are endless. We began to see some nation state groups using platforms like LinkedIn to target executives, more specifically targeting the defense and aerospace industry. For years we’ve been accepting connections on LinkedIn to expand our network and threat actors are using this to their advantage with job adverts. Threat actors will find the executive they want to target in the company they want to go after and develop profiles that look like legitimate recruiters. By getting an executive on the hook, they could potentially convince them to download a job spec that is malware. These types of espionage campaigns can be carried out by other social networks as well, including Twitter, Instagram, Reddit, etc.

Techniques & Tactics
In the past, fake social profiles were relatively easy to spot, however in the case of DPRK, the cybercriminals spent time to setting up a profile, get hooked up into the infosec scene, gain followers and connections through LinkedIn, making it more difficult than before to detect a fraudulent account. When threat actors weaponize social media, they use techniques and tactics you see in the legitimate world. They diligently do their research into what types of jobs would be of interest to you and share an offer that will require you to open a document and trick you to carry out some type of action that will have you download malicious content onto your device.

Who Can Regulate?
We live in a world where we are governed by rules, territories, and jurisdictions; to hold a threat actor accountable, we would need digital evidence. We need to use regulations for digital investigations, and the bad guys don’t. While in territories where there isn’t an extradition treaty, threat actors can continue their malicious behaviors without any consequences. Unfortunately, cybercrime has nonrepudiation and threat actors can deny all knowledge and get away with it.

Prevention
Cybercrime will always be an issue and we need to be more aware of what threat actors are doing and what they’re after. It’s important to understand the threat and what is happening. At McAfee Enterprise and FireEye we work to track malicious actors and integrate intelligence into our products and make content available for CISO, CEO etc. to know what to do and what to look for in the event they are targeted.

Prediction: Help Wanted: Bad Guys with Benefits

By Christiaan Beek

With a focus on strategic intelligence, our team is not only monitoring activity, but also investigating and monitoring open-source-intelligence from a diversity of sources to gain more insights into threat-activities around the globe – and these include an increase in the blending of cybercrime and nation-state operations.

In many cases, a start-up company is formed, and a web of front companies or existing “technology” companies are involved in operations that are directed and controlled by the countries’ intelligence ministries.

In May 2021 for example, the U.S. government charged four Chinese nationals who were working for state-owned front companies. The front-companies facilitated hackers to create malware, attack targets of interest to gain business intelligence, trade-secrets, and information about sensitive technologies.

Not only China but also other nations such as Russia, North Korea, and Iran have applied these tactics. Hire hackers for operations, do not ask questions about their other operations if they do not harm the interests of their own country.

Where in the past specific malware families were tied to nation-state groups, the blurring starts to happen when hackers are hired to write code and conduct these operations.

The initial breach with tactics and tools could be similar as “regular” cybercrime operations, however it is important to monitor what is happening next and act fast. With the predicted increase of blurring between cybercrime and nation-state actors in 2022, companies should audit their visibility and learn from tactics and operations conducted by actors targeting their sector.

Potential Impacts & Implications
With more tools at their disposal, nation state actors are reshaping the cyberthreat landscape leaving destruction and disrupted operations in their wake. There have been many accusations of “spying” which poses as a major threat to economic and national security. The main aim of these attacks is to obtain intellectual property or business intelligence. We are seeing nation states devoting a significant number of resources, time and energy toward achieving strategic cyber advantages, resulting in the implications of divulging national interests, intelligence-gathering capabilities, and military strength through espionage, disruption and theft.

Techniques & Tactics
In May 2021 incident where four Chinese nationals were charged in a global hacking campaign; the indictment stated the threat actors used a front company to hide the Chinese government’s role in the information theft. We anticipate nation states will continue to team up with cybercriminals and create front companies to hide involvement and gain access to private information, military tactics, trade secrets and more. Adversaries will leverage techniques like phishing, known vulnerabilities, malware, crimeware and more to attain their goal.

On the blending of cybercrime/nation-state; understanding the functionalities of malware becomes more important than ever. Let me give an example, when you get a Trickbot infection, a part of the code will steal credentials, they could be sold to a ransomware crew with a possible ransomware attack as result, a complete cybercrime operation. But what if the Trickbot infection was ordered by a Nation State, the credentials are used for a long time operation; started as a crime, ends as a long APT.

Who Can Regulate?
It’s important for governments to hold actors accountable for cyber incidents. Government entities and researchers can likely assist public and private sector organizations in navigating this new cyber landscape by developing standards and/or template processes to drive cyber defense and maintaining operational resiliency.

Prevention
A threat actor’s goal is to gain access to data they can sell, leverage for ransom, or gain critical knowledge so it is important to properly encrypt critical data, rendering it unusable to unauthorized users. You should also maintain regular, offline backups and have an incident response plan ready. Maintaining and testing offline backups can similarly mitigate the impact of destructive malware.

The post Nation States Will Weaponize Social and Recruit Bad Guys with Benefits in 2022 appeared first on McAfee Blog.

McAfee Enterprise & FireEye 2022 Threat Predictions

What cyber security threats should enterprises look out for in 2022?

Ransomware, nation states, social media and the shifting reliance on a remote workforce made headlines in 2021. Bad actors will learn from this year’s successful tactics, retool, and pivot them into next year’s campaigns wielding the potential to wreak more havoc in all our lives.

Skilled engineers and security architects from McAfee Enterprise and FireEye offer a preview of how the threatscape might look in 2022 and how these new or evolving threats could potentially impact the security of enterprises, countries, and civilians.

“Over this past year, we have seen cybercriminals get smarter and quicker at retooling their tactics to follow new bad actor schemes – from ransomware to nation states – and we don’t anticipate that changing in 2022,” said Raj Samani, fellow and chief scientist of the combined company. “With the evolving threat landscape and continued impact of the global pandemic, it is crucial that enterprises stay aware of the cybersecurity trends so that they can be proactive and actionable in protecting their information.”

Lazarus Wants to Add You as a Friend

Nation States will weaponize social media to target more enterprise professionals

By Raj Samani

We love our social media. From beefs between popstars and professional pundits, to an open channel to the best jobs in the industry.

But guess what?

The threat actors know this, and our appetite toward accepting connections from people we have never met are all part of our relentless pursuit of the next 1,000 followers.

A result of this has seen the targeting of executives with promises of job offers from specific threat groups; and why not? After all, it is the most efficient method to bypass traditional security controls and directly communicate with targets at companies that are of interest to threat groups. Equally, direct messages have been used by groups to take control over influencer accounts to promote messaging of their own.

While this approach is not new, it is nearly as ubiquitous as alternate channels. After all, it does demand a level of research to “hook” the target into interactions and establishing fake profiles are more work than simply finding an open relay somewhere on the internet. That being said, targeting individuals has proven a very successful channel, and we predict the use of this vector could grow not only through espionage groups, but other threat actors looking to infiltrate organizations for their own criminal gain.

Help Wanted: Bad Guys with Benefits

Nation states will increase their offensive operations by leveraging cybercriminals

By Christiaan Beek

With a focus on strategic intelligence, our team is not only monitoring activity, but also investigating and monitoring open-source-intelligence from a diversity of sources to gain more insights into threat-activities around the globe – and these include an increase in the blending of cybercrime and nation-state operations.

In many cases, a start-up company is formed, and a web of front companies or existing “technology” companies are involved in operations that are directed and controlled by the countries’ intelligence ministries.

In May 2021 for example, the U.S. government charged four Chinese nationals who were working for state-owned front companies. The front-companies facilitated hackers to create malware, attack targets of interest to gain business intelligence, trade-secrets, and information about sensitive technologies.

Not only China but also other nations such as Russia, North Korea, and Iran have applied these tactics. Hire hackers for operations, do not ask questions about their other operations if they do not harm the interests of their own country.
Where in the past specific malware families were tied to nation-state groups, the blurring starts to happen when hackers are hired to write code and conduct these operations.

The initial breach with tactics and tools could be similar as “regular” cybercrime operations, however it is important to monitor what is happening next and act fast. With the predicted increase of blurring between cybercrime and nation-state actors in 2022, companies should audit their visibility and learn from tactics and operations conducted by actors targeting their sector.

Game of Ransomware Thrones

Self-reliant cybercrime groups will shift the balance of power within the RaaS eco-kingdom

By John Fokker

For several years, ransomware attacks have dominated the headlines as arguably the most impactful cyber threats. The Ransomware-as-a-Service (RaaS) model at the time opened the cybercrime career path to lesser skilled criminals which eventually led to more breaches and higher criminal profits.

For a long time, RaaS admins and developers were prioritized as the top targets, often neglecting the affiliates since they were perceived as less skilled. This, combined with the lack of disruptions in the RaaS ecosystem, created an atmosphere where those lesser-skilled affiliates could thrive and grow into very competent cybercriminals, eventually with a mind of their own.

In a response to the Colonial Pipeline attack, the popular cybercrime forums have banned ransomware actors from advertising. Now, the RaaS groups no longer have a third-party platform on which to actively recruit, show their seniority, offer escrow, have their binaries tested by moderators, or settle disputes. The lack of visibility has made it harder for RaaS groups to establish or maintain credibility and will make it harder for RaaS developers to maintain their current top tier position in the underground.

These events undermine their trusted position. Ransomware has generated billions of dollars in recent years and it’s only a matter of time before some individuals who believe they aren’t getting their fair share become unhappy.

The first signs of this happening are already visible as described in our blog on the Groove Gang, a cyber-criminal gang that branched off from classic RaaS to specialize in computer network exploitation (CNE), exfiltrate sensitive data and, if lucrative, partner with a ransomware team to encrypt the organization’s network.

In 2022, expect more self-reliant cybercrime groups to rise and shift the balance of power within the RaaS eco-climate from those who control the ransomware to those who control the victim’s networks.

Ransomware For Dummies

Less-skilled operators won’t have to bend the knee in RaaS model power shift

By Raj Samani

The Ransomware-as-a-Service eco system has evolved with the use of affiliates, the middlemen and women that work with the developers for a share of the profits. While this structure was honed during the growth of GandCrab, we are witnessing potential chasms in what is becoming a not-so-perfect union.

Historically, the ransomware developers, held the cards, thanks to their ability to selectively determine the affiliates in their operations, even holding “job interviews” to establish technical expertise. As more ransomware players have entered the market, we suspect that the most talented affiliates are now able to auction their services for a bigger part of the profits, and maybe demand a broader say in operations. For example, the introduction of Active Directory enumeration within DarkSide ransomware could be intended to remove the dependency on the technical expertise of affiliates. These shifts signal a potential migration back to the early days of ransomware, with less-skilled operators increasing in demand using the expertise encoded by the ransomware developers.

Will this work? Frankly, it will be challenging to replicate the technical expertise of a skilled penetration tester, and maybe – just maybe – the impact will not be as severe as recent cases.

Keep A Close Eye on API

5G and IoT traffic between API services and apps will make them increasingly lucrative targets

By Arnab Roy

Threat actors pay attention to enterprise statistics and trends, identifying services and applications offering increased risk potential. Cloud applications, irrespective of their flavor (SaaS, PaaS, or IaaS), have transformed how APIs are designed, consumed, and leveraged by software developers, be it a B2B scenario or B2C scenario. The reach and popularity of some of these cloud applications, as well as, the treasure trove of business-critical data and capabilities that typically lie behind these APIs, make them a lucrative target for threat actors. The connected nature of APIs potentially also introduces additional risks to businesses as they become an entry vector for wider supply chain attacks.

The following are some of the key risks that we see evolving in the future:

1. Misconfiguration of APIs
2. Exploitation of modern authentication mechanisms
3. Evolution of traditional malware attacks to use more of the cloud APIs
4. Potential misuse of the APIs to launch attacks on enterprise data
5. The usage of APIs for software-defined infrastructure also means potential misuse.

For developers, developing an effective threat model for their APIs and having a Zero Trust access control mechanism should be a priority alongside effective security logging and telemetry for better incident response and detection of malicious misuse.

Hijackers Will Target Your Application Containers

Expanded exploitation of containers will lead to endpoint resource takeovers

By Mo Cashman

Containers have become the de facto platform of modern cloud applications. Organizations see benefits such as portability, efficiency and speed which can decrease time to deploy and manage applications that power innovation for the business. However, the accelerated use of containers increases the attack surface for an organization. Which techniques should you look out for, and which container risk groups will be targeted? Exploitation of public-facing applications (MITRE T1190) is a technique often used by APT and Ransomware groups. The Cloud Security Alliance (CSA) identified multiple container risk groups including Image, Orchestrator, Registry, Container, Host OS and Hardware.

The following are some of the key risks groups we anticipate will be targeted for expanded exploitation in the future:

1. Orchestrator Risks: Increasing attacks on the orchestration layer, such as Kubernetes and associated API mainly driven by misconfigurations.
2. Image or Registry Risk: Increasing use of malicious or backdoored images through insufficient vulnerability checks.
3. Container Risks: Increasing attacks targeting vulnerable applications.

Expanded exploitation of the above vulnerabilities in 2022 could lead to endpoint resource hijacking through crypto-mining malware, spinning up other resources, data theft, attacker persistence, and container-escape to host systems.

Zero Cares About Zero-days

The time to repurpose vulnerabilities into working exploits will be measured in hours and there’s nothing you can do about it… except patch

By Fred House

2021 is already being touted as one of the worst years on record with respect to the volume of zero-day vulnerabilities exploited in the wild. The scope of these exploitations, the diversity of targeted applications, and ultimately the consequences to organizations were all notable. As we look to 2022, we expect these factors to drive an increase in the speed at which organizations respond.

When we first learned in 2020 that roughly 17,000 SolarWinds customers were compromised and an estimated 40 were subsequently targeted, many reacted in shock at the pure scope of the compromise. Unfortunately, 2021 brought its own notable increase in volume along with uninspiring response times by organizations. Case in point: two weeks after Microsoft patched ProxyLogon they reported that 30K Exchange servers were still vulnerable (less conservative estimates had the number at 60K).

ProxyShell later arrived as Exchange’s second major event of the year. In August, a Blackhat presentation detailing Exchange Server vulnerabilities was followed the next day by the release of an exploit POC, all of which had been patched by Microsoft months earlier in April/May. This analysis of data captured by Shodan one week after the exploit POC was released concluded that over 30K Exchange servers were still vulnerable, noting that the data may have underrepresented the full scope (i.e., Shodan hadn’t had time to scan the full Internet). In summary: patched in the Spring, exploited in the Fall.

So, what can we take away from all of this? Well, attackers and security researchers alike will continue to hone their craft until weaponized exploits and POCs are expected within hours of vulnerability disclosure. In turn however, and largely driven by the increased consequences of compromise, we can also expect renewed diligence around asset and patch management. From identifying public facing assets to quickly deploying patches despite potential business disruption, companies will have a renewed focus on reducing their “time to patch.” While we will inevitably continue to see high-impact exploitations, the scope of these exploitations will be reduced as more organizations get back to the basics.

The post McAfee Enterprise & FireEye 2022 Threat Predictions appeared first on McAfee Blog.

Is There Really Such a Thing as a Low-Paid Ransomware Operator?

Introduction

Going by recent headlines you could be forgiven for thinking all ransomware operators are raking in millions of ill-gotten dollars each year from their nefarious activities.

Lurking in the shadows of every large-scale attack by organized gangs of cybercriminals, however, there can be found a multitude of smaller actors who do not have access to the latest ransomware samples, the ability to be affiliates in the post-DarkSide RaaS world or the financial clout to tool up at speed.

So what is a low-paid ransomware operator to do in such circumstances?

By getting creative and looking out for the latest malware and builder leaks they can be just as devastating to their victims and, in this blog, we will track the criminal career of one such actor as they evolve from homemade ransomware to utilizing major ransomware through the use of publicly leaked builders.

The Rich Get Richer

For years, the McAfee Enterprise Advanced Threat Research (ATR) team has observed the proliferation of ransomware and the birth and (apparent) death of large organized gangs of operators. The most notorious of these gangs have extorted huge sums of money from their victims, by charging for decryption of data or by holding the data itself to ransom against the threat of publication on their ‘leak’ websites.

With the income of such tactics sometimes running into the millions of dollars, such as with the Netwalker ransomware that generated 25 million USD between 1 March and 27 July 2020, we speculate that much of those ill-gotten funds are subsequently used to build and maintain arsenals of offensive cyber tools, allowing the most successful cybercriminals to stay one step ahead of the chasing pack

Figure 1: Babuk group looking for a corporate VPN 0-Day

As seen in the image above, cybercriminals with access to underground forums and deep pockets have the means to pay top dollar for the tools they need to continually generate more income, with this particular Babuk operator offering up 50,000 USD for a 0-day targeting a corporate virtual private network (VPN) which would allow easy access to a new victim.

The Lowly-Paid Don’t Necessarily Stay That Way

For smaller ransomware operators, who do not have affiliation with a large group, the technical skills to create their own devastating malware or the financial muscle to buy what they need, the landscape looks rather different.

Unable to build equally effective attack chains, from initial access through to data exfiltration, their opportunities to make illegal profits are far slimmer in comparison to the behemoths of the ransomware market.

Away from the gaze of researchers who typically focus on the larger ransomware groups, many individuals and smaller groups are toiling in the background, attempting to evolve their own operations any way they can. One such method we have observed is through the use of leaks, such as the recent online posting of Babuk’s builder and source code.

Figure 2: Babuk builder public leak on Twitter

Figure 3: Babuk source code leak on underground forum

McAfee Enterprise ATR has seen two distinct types of cybercriminal taking advantage of leaks such as this. The first group, which we presume to be less tech-savvy, has merely copied and pasted the builder, substituting the Bitcoin address in the ransom note with their own. The second group has gone further, using the source material to iterate their own versions of Babuk, complete with additional features and new packers.

Thus, even those operators at the bottom of the ransomware food chain have the opportunity to build on others’ work, to stake their claim on a proportion of the money to be made from data exfiltration and extortion.

ATR’s Theory of Evolution

A Yara rule dedicated to Babuk ransomware triggered a new sample uploaded on VirusTotal, which brings us to our ‘lowly-paid’ ransomware actor.

From a quick glance at the sample we can deduce that it is a copied and pasted binary output from Babuk’s builder, with an edited ransom note naming the version “Delta Plus”, two recovery email addresses and a new Bitcoin address for payments:

Figure 4: Strings content of “Delta Plus” named version of Babuk

We’ve seen the two email recovery addresses before – they have been used to deliver random ransomware in the past and, by using them to pivot, we were able to delve into the actor’s resume:

The first email address, retrievedata300@gmail.com, has been used to drop a .NET ransomware mentioning “Delta Plus”:

Figure 5: Strings content of .NET ransomware related to previous Delta ransomware activities

Filename	Setup.exe
Compiled Time	Tue Sep  7 17:58:34 2021
FileType	Win32 EXE
FileSize	22.50 KB
Sha256	94fe0825f26234511b19d6f68999d8598a9c21d3e14953731ea0b5ae4ab93c4d

The ransomware is pretty simple to analyze; all mechanisms are declared, and command lines, registry modification, etc., are hardcoded in the binary.

Figure 6: .NET analysis with command line details

In fact, the actor’s own ransomware is so poorly developed (no packing, no obfuscation, command lines embedded in the binary and the fact that the .NET language is easy to analyze) that it is hardly surprising they started using the Babuk builder instead.

By way of contrast, their new project is well developed, easy to use and efficient, no to mention painful to analyze (as it is written in the Golang language) and provides executables for Windows, Linux and network attached storage (NAS) systems.

The second email address, deltapaymentbitcoin@gmail.com, has been used to drop an earlier version of the .NET ransomware

Figure 7: Strings content from first version of .NET ransomware

Filename	test2.exe
Compiled Time	Mon Aug 30 19:49:54 2021
FileType	Win32 EXE
FileSize	15.50 KB
Sha256	e1c449aa607f70a9677fe23822204817d0ff41ed3047d951d4f34fc9c502f761

Tactics, Techniques and Procedures

By checking the relationships between “Delta ransomware”, the Babuk iteration and the domains contacted during process execution, we can observe some domains related to our sample:

suporte01928492.redirectme.net

suporte20082021.sytes.net

24.152.38.205

Thanks to a misconfiguration, files hosted on those two domains are accessible through Open Directory (OpenDir), which is a list of direct links to files stored on a server:

Figure 8: Open Directories website where samples are hosted

• bat.rar: A PowerShell script used to perform several operations:
  • Try to disable Windows Defender
  • Bypass User Account Control (UAC)
  • Get system rights via runasti

Figure 9: Privilege escalation to get system rights

• exe.rar: Delta Plus ransomware
• reg.rar: Registry values used to disable Windows Defender

Figure 10: Registry value modifications to disable Windows Defender

Other domains where files are hosted contain different tools used during attack operations:

• We’ve found two methods employed by the operator, which we assume to be used for initial access: First, a fake Flash Player installer and, secondly, a fake Anydesk remote tool installer used to drop the ransomware. Our theory about Flash Player initial access has been confirmed by checking the IP that hosts most of the domains:

Figure 11: Fake Flash website used to download fake Flash installer

When logging in, the website warns you that your Flash Player version is outdated and tries to download the Fake Flash Player installer:

Figure 12: JavaScript variables used to drop fake Flash Installer

A secondary site appears to have also been utilized in propagating the fake Flash Player, though it is currently offline :

Figure 13: JavaScript function to download the fake Flash Installer from another website

• Portable Executable (PE) files used to launch PowerShell command lines to delete shadow copies, exclude Windows Defender and import registry keys from “Update.reg.rar” to disable Windows defender.
• A PE file used for several purposes: Exfiltrating files from the victim, keylogging, checking if the system has already been held to ransom, getting system information, obtaining user information and to create and stop processes.

Figure 14: Functions and C2 configuration from ransomware sample

(host used for extraction)

• In addition to the above, we also found evidence that this actor tried to leverage another ransomware builder leak, Chaos ransomware.

Infrastructure

The majority of domains used by this actor are hosted on the same IP: “24.152.38.205” (AS 270564 / MASTER DA WEB DATACENTER LTDA).

But as we saw by “analyzing” the extraction tool used by the actor, another IP is mentioned: “149.56147.236” (AS 16276 / OVH SAS). On this IP, some ports are open, such as FTP (probably used to store exfiltrated data), SSH, etc.

By looking at this IP with Shodan, we can get a dedicated hash for the SSH service, plus fingerprints to use on this IP, and then find other IPs used by the actor during their operations.

By using this hash, we were able to map the infrastructure by looking for other IPs sharing the same SSH key + fingerprintings.

At least 174 IPs are sharing the same SSH pattern (key, fingerprint, etc.); all findings are available in the IOCs section.

Some IPs are hosting different file types, maybe related to previous campaigns:

Figure 15: Open Directory website probably used by the same actor for previous campaigns

Bitcoin Interests

Most of the ransomware samples used by the actor mention different Bitcoin (BTC) addresses which we assume is an effort to obscure their activity.

By looking for transactions between those BTC addresses with CipherTrace, we can observe that all the addresses we extracted (see the circle highlighted with a yellow “1” below) from the samples we’ve found are related and eventually point to a single Bitcoin wallet, probably under control of the same threat actor.

From the three samples we researched, we were able to extract the following BTC addresses:

• 3JG36KY6abZTnHBdQCon1hheC3Wa2bdyqs
• 1Faiem4tYq7JQki1qeL1djjenSx3gCu1vk
• bc1q2n23xxx2u8hqsnvezl9rewh2t8myz4rqvmdzh2

Figure 16: Follow the money with CipherTrace

Ransomware Isn’t Just About Survival of the Fittest

As we have seen above, our example threat actor has evolved over time, moving from simplistic ransomware and demands in the hundreds of dollars, to toying with at least two builder leaks and ransom amounts in the thousands of dollars range.

While their activity to date suggests a low level of technical skill, the profits of their cybercrime may well prove large enough for them to make another level jump in the future.

Even if they stick with copy-pasting builders and crafting ‘stagers’, they will have the means at their disposal to create an efficient attack chain with which to compromise a company, extort money and improve their income to the point of becoming a bigger fish in a small pond, just like the larger RaaS crews.

In the meantime, such opportunitistic actors will continue to bait their hooks and catch any fish they can as, unlike affiliated ransomware operators, they do not have to follow any rules in return for support (pentest documentation, software, infrastructure, etc.) from the gang’s operators. Thus, they have a free hand to carry out their attacks and, if a victim wants to bite, they don’t care about ethics or who they target.

The good news for everyone else, however, is the fact that global law enforcement isn’t gonna need a bigger boat, as it already casts its nets far and wide.

 

Mitre Att&ck

Technique ID	Technique Description	Observable
T1189	Drive By Compromise	The actor is using a fake Flash website to spread fake a Flash installer.
T1059.001	Command Scripting Interpreter: PowerShell	PowerShell is used to launch command lines (delete shadow copies, etc.).
T1059.007	Command and Scripting Interpreter: JavaScript	JavaScript is used in the fake Flash website to download the fake Flash installer.
T1112	Modify Registry	To disable Windows Defender, the actor modifies registry. “HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender” and “HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection”.
T1083	File and Directory Discovery	The actor is listing files on the victim system.
T1057	Process Discovery	The actor is listing running processes on the victim system.
T1012	Query Registry	To perform some registry modifications, the actor is first querying registry path.
T1082	System Information Discovery	Before encrypting files, the actor is listing hard drives.
T1056.001	Input Capture: Keylogging	The exfiltration tool has the capability to log user keystrokes.
T1005	Data from Local System
T1571	Non-Standard Port	The actor is using port “1177” to exfiltrate data.
T1048	Exfiltration Over Alternative Protocol
T1486	Data Encrypted for Impact	Data encrypted by ransomware.
T1490	Inhibit System Recovery	Delete Shadow Copies.

 

Detection Mechanisms

Sigma Rules

–          Shadow Copies Deletion Using Operating Systems Utilities: https://github.com/SigmaHQ/sigma/blob/master/rules/windows/process_creation/win_shadow_copies_deletion.yml –          Drops Script at Startup Location: https://github.com/joesecurity/sigma-rules/blob/master/rules/dropsscriptatstartuplocation.yml –          File Created with System Process Name: https://github.com/SigmaHQ/sigma/blob/master/rules/windows/file_event/sysmon_creation_system_file.yml –          Suspicious Svchost Process: https://github.com/SigmaHQ/sigma/blob/master/rules/windows/process_creation/win_susp_svchost.yml –          System File Execution Location Anomaly: https://github.com/SigmaHQ/sigma/blob/master/rules/windows/process_creation/win_system_exe_anomaly.yml –          Delete Shadow copy via WMIC: https://github.com/joesecurity/sigma-rules/blob/master/rules/deleteshadowcopyviawmic.yml –          Always Install Elevated Windows Installer: https://github.com/SigmaHQ/sigma/blob/59000b993d6280d9bf063eefdcdf30ea0e83aa5e/rules/windows/process_creation/sysmon_always_install_elevated_windows_installer.yml

 

Yara Rules

Babuk Ransomware Windows

rule Ransom_Babuk { meta: description = “Rule to detect Babuk Locker” author = “TS @ McAfee Enterprise ATR” date = “2021-01-19” hash = “e10713a4a5f635767dcd54d609bed977” rule_version = “v2” malware_family = “Ransom:Win/Babuk” malware_type = “Ransom” mitre_attack = “T1027, T1083, T1057, T1082, T1129, T1490, T1543.003”   strings: $s1 = {005C0048006F007700200054006F00200052006500730074006F0072006500200059006F00750072002000460069006C00650073002E007400780074} //  \ How To Restore Your Files .txt $s2 = “delete shadows /all /quiet” fullword wide   $pattern1 = {006D656D74617300006D65706F63730000736F70686F730000766565616D0000006261636B7570000047785673730000004778426C7200 000047784657440000004778435644000000477843494D67720044656657617463680000000063634576744D67720000000063635365744D67720000000 0536176526F616D005254567363616E0051424643536572766963650051424944505365727669636500000000496E747569742E517569636B426F6F6B732E46435300} $pattern2 = {004163725363683253766300004163726F6E69734167656E74000000004341534144324457656253766300000043414152435570646174655376630000730071} $pattern3 = {FFB0154000C78584FDFFFFB8154000C78588FDFFFFC0154000C7858CFDFFFFC8154000C78590FDFFFFD0154000C78594FDFFFFD8154 000C78598FDFFFFE0154000C7859CFDFFFFE8154000C785A0FDFFFFF0154000C785A4FDFFFFF8154000C785A8FDFFFF00164000C785ACFDFFFF081640 00C785B0FDFFFF10164000C785B4FDFFFF18164000C785B8FDFFFF20164000C785BCFDFFFF28164000C785C0FDFFFF30164000C785C4FDFFFF3816400 0C785C8FDFFFF40164000C785CCFDFFFF48164000C785D0FDFFFF50164000C785D4FDFFFF581640} $pattern4 ={400010104000181040002010400028104000301040003810400040104000481040005010400058104000601040006C104000781040008 41040008C10400094104000A0104000B0104000C8104000DC104000E8104000F01040000011400008114000181140002411400038114000501140005C 11400064114000741140008C114000A8114000C0114000E0114000F4114000101240002812400034124000441240005412400064124000741240008C1 24000A0124000B8124000D4124000EC1240000C1340002813400054134000741340008C134000A4134000C4134000E8134000FC134000141440003C14 4000501440006C144000881440009C144000B4144000CC144000E8144000FC144000141540003415400048154000601540007815}   condition: filesize >= 15KB and filesize <= 90KB and 1 of ($s*) and 3 of ($pattern*) }

 

Exfiltration Tool

rule CRIME_Exfiltration_Tool_Oct2021 { meta: description = “Rule to detect tool used to exfiltrate data from victim systems” author = “TS @ McAfee Enterprise ATR” date = “2021-10-04” hash = “ceb0e01d96f87af0e9b61955792139f8672cf788d506c71da968ca172ebddccd”   strings: $pattern1 = {79FA442F5FB140695D7ED6FC6A61F3D52F37F24B2F454960F5D4810C05D7A83D4DD8E6118ABDE2055E4D CCFE28EBA2A11E981DB403C5A47EFB6E367C7EC48C5EC2999976B5BC80F25BEF5D2703A1E4C2E3B30CD26E92570DAF1F9BD7B48B38FB522358} $pattern2 = {B4A6D4DD1BBEA16473940FC2DA103CD64579DD1A7EBDF30638A59E547B136E5AD113835B8294F53B8C3A 435EB2A7F649A383AA0792DD14B9C26C1BCA348920DFD37DA3EF6260C57C546CA51925F684E91239152DC05D5161A9064434} $pattern3 = {262E476A45A14D4AFA448AF81894459F7296633644F5FD061A647C6EF1BA950FF1ED48436D1BD4976BF8 1EE84AE09D638BD2C2A01FA9E22D2015518280F6692EB976876C4045FADB71742B9579C13C7482A44A} $pattern4 = {F2A113713CCB049AFE352DB8F99160855125E5A045C9F6AC0DCA0AB615BD34367F2CA5156DCE5CA286CC C55E37DFCDC5AAD14ED9DAB3CDB9D15BA91DD79FF96E94588F30}   condition: 3 of ($pattern*) }

 

 

IOCs

Infrastructure URLs

http://atualziarsys.serveirc.com/Update4/ http://services5500.sytes.net/Update6/Update.exe.rar http://suporte20082021.sytes.net/Update5/ http://atualziarsys.serveirc.com/update4/update.exe.rar http://suporte20082021.sytes.net/Update3/ http://suporte01928492.redirectme.net/ http://atualziarsys.serveirc.com/Update3/ http://services5500.sytes.net/update8/update.exe.rar http://suporte20082021.sytes.net/update/ http://suporte20082021.sytes.net/Update5/Update.exe.rar http://suporte01928492.redirectme.net/AppMonitorPlugIn.rar http://suporte01928492.redirectme.net/Update5/Update.exe.rar http://services5500.sytes.net/update7/update.exe.rar http://services5500.sytes.net/Update8/Update.exe.rar http://services5500.sytes.net/Update8/Update.bat.rar http://suporte01092021.myftp.biz/update/ http://services5500.sytes.net/Update7/Update.exe.rar http://suporte01928492.redirectme.net/Update7/Update.bat.rar http://suporte01928492.redirectme.net/Update7/Update.exe.rar http://services5500.sytes.net/update6/update.exe.rar http://suporte01092021.myftp.biz/ http://services5500.sytes.net/Update6/Update.bat.rar http://suporte01928492.redirectme.net/update6/update.exe.rar http://suporte01928492.redirectme.net/update5/update.exe.rar http://services5500.sytes.net/ http://suporte01928492.redirectme.net/Update6/Update.exe.rar http://atualziarsys.serveirc.com/Update3 http://atualziarsys.serveirc.com/update3/update.reg.rar http://24.152.38.205/pt/flashplayer28_install.zip http://suporte01928492.redirectme.net/Update7 http://atualziarsys.serveirc.com/ http://atualziarsys.serveirc.com/update3/mylink.vbs.rar http://suporte01928492.redirectme.net/update7/update.exe.rar http://atualziarsys.serveirc.com/Update4/Update.exe.rar http://suporte01928492.redirectme.net/appmonitorplugin.rar http://atualziarsys.serveirc.com/update3/update.exe.rar http://suporte20082021.sytes.net/ http://suporte20082021.sytes.net/update3/update.exe.rar http://atualziarsys.serveirc.com/Update4/Update.exe2.rar http://suporte20082021.sytes.net/Update3/Update.exe.rar http://suporte20082021.sytes.net/Update5/Update.reg.rar http://atualziarsys.serveirc.com/Update4/Update.exe2.rar/ http://atualziarsys.serveirc.com/Update4 http://suporte01092021.myftp.biz/update/WindowsUpdate2.rar http://suporte01092021.myftp.biz/update http://atualziarsys.serveirc.com/Update3/Update.reg.rar/ http://atualziarsys.serveirc.com/Update3/Update.exe.rar http://suporte20082021.sytes.net/Update3/Update.exe.rar/ http://suporte01092021.myftp.biz/update/WindowsUpdate2.rar/ http://atualziarsys.serveirc.com/Update4/Update.exe.rar/ http://atualziarsys.serveirc.com/Update3/mylink.vbs.rar http://atualziarsys.serveirc.com/update4 http://atualziarsys.serveirc.com/update3 http://suporte01092021.myftp.biz/update/Update.rar http://suporte01928492.redirectme.net/AppMonitorPlugIn.rar/ http://suporte20082021.sytes.net/update5/update.exe.rar http://suporte01092021.myftp.biz/update5/update.exe.rar http://atualziarsys.serveirc.com/update4/update.exe2.rar http://suporte01092021.myftp.biz/update/windowsupdate2.rar http://suporte20082021.sytes.net/update2/update.exe.rar http://suporte20082021.sytes.net/update/windowsupdate2.rar http://atualziarsys.serveirc.com/Update4/mylink.vbs.rar http://atualziarsys.serveirc.com/favicon.ico http://24.152.38.205/1.rar http://24.152.38.205/1.exe http://appmonitorplugin.sytes.net/appmonitorplugin.rar http://suporte20082021.sytes.net/update/WindowsUpdate2.rar http://appmonitorplugin.sytes.net/ http://suporte20082021.sytes.net/appmonitorplugin.rar http://suportmicrowin.sytes.net/appmonitorplugin.rar http://suportmicrowin.sytes.net/ http://suportmicrowin.sytes.net/AppMonitorPlugIn.rar http://appmonitorplugin.sytes.net/AppMonitorPlugIn.rar http://24.152.38.205/pt/setup.zip

 

Infrastructure Domains

services5500.sytes.net atualziarsys.serveirc.com suporte01092021.myftp.biz suporte20082021.sytes.net suporte01928492.redirectme.net suportmicrowin.sytes.net appmonitorplugin.sytes.net

 

Infrastructure IPs

149.56.147.236 24.152.38.205 54.38.122.66 149.56.38.168 149.56.38.170 24.152.36.48 66.70.170.191 66.70.209.174 142.44.129.70 51.79.107.245 46.105.36.189 178.33.108.239 54.39.193.37 24.152.37.115 144.217.139.134 24.152.36.58 51.38.19.201 51.222.97.177 51.222.53.150 144.217.45.69 87.98.137.173 144.217.199.24 24.152.37.19 144.217.29.23 198.50.246.8 54.39.163.60 54.39.84.55 24.152.36.30 46.105.38.67 24.152.37.96 51.79.63.229 178.33.107.134 164.132.77.246 54.39.163.58 149.56.113.76 51.161.120.193 24.152.36.210 176.31.37.238 176.31.37.237 24.152.36.83 24.152.37.8 51.161.76.193 24.152.36.117 137.74.246.224 51.79.107.134 51.79.44.49 51.222.173.152 51.79.124.129 51.79.107.242 51.222.173.148 144.217.117.172 54.36.82.187 54.39.152.91 54.36.82.177 142.44.146.178 54.39.221.163 51.79.44.57 149.56.38.173 24.152.36.46 51.38.19.198 51.79.44.59 198.50.246.11 24.152.36.35 24.152.36.239 144.217.17.186 66.70.209.169 24.152.36.158 54.39.84.50 51.38.19.200 144.217.45.68 144.217.111.5 54.38.164.134 87.98.171.7 51.79.124.130 66.70.148.142 51.255.119.19 66.70.209.168 54.39.239.81 24.152.36.98 51.38.192.225 144.217.117.10 144.217.189.108 66.70.148.136 51.255.55.134 54.39.137.73 66.70.148.137 54.36.146.230 51.79.107.254 54.39.84.52 144.217.61.176 24.152.36.150 149.56.147.236 51.38.19.196 54.39.163.57 46.105.36.133 149.56.68.191 24.152.36.107 158.69.99.10 51.255.55.136 54.39.247.244 149.56.147.204 158.69.99.15 144.217.32.24 149.56.147.205 144.217.32.213 54.39.84.53 79.137.115.160 144.217.233.98 51.79.44.56 24.152.36.195 142.44.146.190 144.217.139.13 54.36.82.180 198.50.246.14 137.74.246.223 24.152.36.176 51.79.107.250 51.161.76.196 198.50.246.12 66.70.209.170 66.70.148.139 51.222.97.189 54.39.84.49 144.217.17.185 142.44.129.73 144.217.45.67 24.152.36.28 144.217.45.64 24.152.37.39 198.27.105.3 51.38.8.75 198.50.204.38 54.39.221.11 51.161.76.197 54.38.122.64 91.134.217.71 24.152.36.100 144.217.32.26 198.50.246.13 54.36.82.188 54.39.84.25 66.70.209.171 51.38.218.215 54.39.8.92 51.38.19.205 54.39.247.228 24.152.36.103 24.152.36.104 51.79.44.43 54.39.152.202 66.70.134.218 24.152.36.25 149.56.113.79 178.32.243.48 144.217.45.66 66.70.173.72 176.31.37.239 54.38.225.81 158.69.4.173 24.152.37.189 54.36.146.129 198.50.246.15 51.222.102.30 51.79.105.91 51.79.9.91 51.222.173.151 51.79.107.124 51.222.173.142 144.217.17.187 149.56.85.98 51.79.107.244 144.217.158.195 24.152.36.178 192.95.20.74 51.79.117.250

 

Ransomware Hashes

106118444e0a7405c13531f8cd70191f36356581d58789dfc5df3da7ba0f9223 e1c449aa607f70a9677fe23822204817d0ff41ed3047d951d4f34fc9c502f761 ae6020a06d2a95cbe91b439f4433e87d198547dec629ab0900ccfe17e729cff1 c3776649d9c0006caba5e654fa26d3f2c603e14463443ad4a5a08e4cf6a81994 63b6a51be736d253e26011f19bd16006d7093839b345363ef238eafcfe5e7e85 94fe0825f26234511b19d6f68999d8598a9c21d3e14953731ea0b5ae4ab93c4d c8d97269690d3b043fd6a47725a61c00b57e3ad8511430a0c6254f32d05f76d6 67bc70d4141d3f6aaf8f17963d56df5cee3727a81bc54407e90fdf1a6dc8fe2a 98a3ef26b346c4f47e5dfdba4e3e26d1ef6a4f15969f83272b918f53d456d099 c3c306b2d51e7e4f963a6b1905b564ba0114c8ae7e4bb4656c49d358c0f2b169

 

Bitcoin Addresses

3JG36KY6abZTnHBdQCon1hheC3Wa2bdyqs 1Faiem4tYq7JQki1qeL1djjenSx3gCu1vk bc1q2n23xxx2u8hqsnvezl9rewh2t8myz4rqvmdzh2

 

PDB

C:\Users\workdreams\Desktop\Testes\Crypt_FInal\Crazy_Crypt\Crazy\obj\Debug\AppMonitorPlugIn.pdb C:\Users\workdreams\Desktop\test\Nopyfy-Ransomware-master\Nopyfy-Ransomware\Nopyfy-Ransomware\obj\Debug\Nopyfy-Ransomware.pdb

 

PowerShell Script

a8d7b402e78721443d268b682f8c8313e69be945b12fd71e2f795ac0bcadb353

 

Exfiltration Tool

ceb0e01d96f87af0e9b61955792139f8672cf788d506c71da968ca172ebddccd c3323fbd0d075bc376869b0ee26be5c5f2cd4e53c5efca8ecb565afa8828fb53

 

Fake Flash Player installer

d6c35e23b90a7720bbe9609fe3c42b67d198bf8426a247cd3bb41d22d2de6a1f

 

Fake Anydesk Installer

e911c5934288567b57a6aa4f9344ed0f618ffa4f7dd3ba1221e0c42f17dd1390

 

 

The post Is There Really Such a Thing as a Low-Paid Ransomware Operator? appeared first on McAfee Blog.

McAfee Enterprise Advanced Threat Research Report: Ransomware’s Increasing Prevalence

The increasing prevalence of ransomware tops the findings of the McAfee Enterprise Advanced Threat Research Report: October 2021 released today.

While ransomware continues to hold cybersecurity headlines hostage, so much has changed since our last threat report. After shutting down the Colonial Pipeline, DarkSide created the appearance of walking away after attracting government scrutiny, thinking we would miss the (alleged) connection to BlackMatter.

Our Advanced Threat Research team also made a move to McAfee Enterprise, a newly dedicated Enterprise Cybersecurity company. While we will no longer publish our work under McAfee Labs, you can still find and follow our research on our new McAfee Enterprise ATR Twitter feed: @McAfee_ATR.

We’ve shifted the primary focus of our new Threat Report from frequency to prevalence. Our team is now paying attention to how often we see the threat around the globe and, more importantly, who it targets.

While DarkSide attempted to step out of the spotlight, other ransomware families including REvil/Sodinokibi, Ryuk, and Babuk wreaked havoc from among DarkSide’s shadow. In response, this threat report offers a deep dive into ransomware’s increasing prevalence including ransomware family detections and the delta of data between open-source intelligence and telemetry.

Our McAfee Enterprise team also offers research and analysis on relevant threat topics including:

• Cloud Threats – Continuing threat trends targeting a remote workforce
• B Braun – Our team’s uncovering of healthcare vulnerabilities in a globally used infusion pump
• MITRE ATT&CK Techniques – Top techniques used in Q2 2021
• How to Defend – Resources designed to help your enterprise defend itself from the latest threats

Once you’ve consumed the research and findings in this report, don’t forget our MVISION Insights preview dashboard which updates and profiles the most prevalent threats, offering a knowledge base that includes targeted countries and sectors along with proactive solutions to help your enterprise stay ahead of emerging threats.

We welcome your feedback about this threat report and what you would like to see in the next report.

Finding 0-days with Jackalope

Overview

On March 21^st, 2021, the McAfee Enterprise Advanced Threat Research (ATR) team released several vulnerabilities it discovered in the Netop Vision Pro Education software, a popular schooling software used by more than 9,000 school systems around the world. Netop was very responsive and released several updates to address many of the critical findings, creating a more secure product for our educators and children to use. During any vulnerability research project, as we continue to gain a deeper understanding on how a product works, additional threat vectors become apparent which may lead to additional findings; this proved once again true during the Netop research. In this blog we will highlight an additional finding: CVE-2021-36134, a vulnerability in the processing of JPEG images, on the Netop Vison Pro version 9.7.2 software. The main emphasis will focus on the process and techniques used during blackbox fuzzing of a Windows DLL.

Background

Fuzzing can be a challenging exercise and just knowing where to start can be cause for confusion. There are many different fuzzers on the market, many of them primarily designed to handle open-source projects on Linux. In late 2020 Google’s Project Zero team released a new fuzzer named Jackalope. Jackalope is a coverage-guided fuzzer, meaning it keeps track of code paths during testing and uses that information to guide its future mutations. Jackalope leverages a library called TinyInst for its code coverage and allows for command line parameters related to code coverage to be passed directly to TinyInst. What caught my attention about Jackalope was that it was designed with a blackbox, Windows and MacOS first mentality. It was built to fill a gap in Windows blackbox fuzzing, which has existed for some time and therefore warranted further investigation. During the time of Jackalope’s release, we were working on the Netop Vision Pro research which runs primarily on Windows, so it was logical to test Jackalope to see if we could discover any new vulnerabilities on Netop Vision Pro.

Setup

The Jackalope documentation does a great job of explaining the setup and build process to get started. For this setup we set up shop on a Windows 10 fully patched system and compiled Jackalope from the GitHub repo using Visual Studio 2019. In a short amount of time, it was time to test the setup. The repo provides a test binary which can be built with the source and therefore is the best place to understand how the fuzzer works. There are just under a few hundred lines of code, but how it works can be summed up in just a few lines, as seen in Figure 1.

Figure 1 test.cpp

Examining the test code, it becomes apparent the test binary simply crashes if it finds the word “test” in memory. It causes a crash by attempting to write the value “1” at an invalid memory address, “NULL”.  Therefore, to ensure the fuzzer is working properly we need to create a small input corpus. This can be done by creating an “in” directory and placing a couple of text files within it, one containing the word “test”. We are not looking for crashes or new vulnerabilities during this test, but simply making sure our setup is functioning as expected. The test run can be seen in Figure 2, where the command to execute the test case was taken from the Jackalope documentation.

Figure 2 Testing fuzzer

Target Selection

When selecting an overall target function, it’s first important to look at how an application takes input alongside with how the fuzzer can tailor that input. Jackalope is designed to provide either a file or a chunk of shared memory to the target. This gives a lot of flexibility since almost anything can be set up as shared memory including network packet payloads. The trick becomes how to pass the file or shared memory to the target. In larger applications on Windows, a typical approach is to determine what functionality you want to fuzz, find a DLL that exports a function within the target code path, and pass that function the input. The closer the exported function is to the end of the desired code path to fuzz, the less headaches, and better results you will have trying to exercise the desired code.

Through the research done on Netop, we had a deep insight into how the system functions and the very large number of DLLs that it contains along with the numerous amounts of exported functions. After review, the function MeImgLoadJpeg which is exported in MeImg.dll stuck out as a good place to get started.

Figure 3 MeImgLoadJpeg Header

What makes this a good candidate for fuzzing? First, how, and when this function is executed is important. This function gets executed on both the student and teacher machines whenever a JPEG image is loaded into the system. For students this is when an image is pushed over the network to them; for example: when a teacher uses the blank screen feature on a student. On the teacher’s machine this function is called when a teacher loads an image to send to the student. The key components here are that it is potentially executed often, input can come from a local file or a network file and it affects both components of our system.

Second, when investigating this function further, the parameters are fuzzing friendly. Through light reversing, it can easily be seen that it takes a file path and opens the file directly within the function. This makes fuzzing it with Jackalope very simple since it supports file fuzzing and we won’t need to open or manipulate the test file in memory. Also, very few parameters are passed, one of which (BITMAPINFOHEADER), is well documented by Microsoft, making it simpler to construct valid calls. This also is true for the return parameter, HBITMAP. This will make it easy to determine success and failure conditions. Lastly, the fuzzable component of this function is a JPEG file. JPEG is a well-documented format and a well-fuzzed format, making test corpus generation and potentially crash analysis simpler.

Writing the Test Harness

In most fuzzing setups, a custom program is necessary to setup the required structure and complete any initialization required by the target function. This is commonly referred to as the test harness. It is required any time your target for fuzzing is not the main binary or executable, which tends to be the case most of the time. For example, if you want to fuzz a small executable like the “file” command on Linux, you don’t always require a test harness, since the binary takes its input (a file) directly from the command line and there is little to no setup required to get to your desired state. However, in many cases, especially on Windows, it is common to be looking to fuzz part of the code that is often not as directly accessible or requires setup before it can be passed the fuzzed data. This is where a test harness comes into play. Using the Jackalope “test.cpp” file provided in the GitHub repo, it is easy to see an example of what is needed when writing a test harness. The harness needs to configure the incoming test case as ether a file or shared memory input, set up parameters for the target function, call the function, and, if needed, create a crash to indicate a found crash to Jackalope.

To get started we first must load the DLL which contains our target function. In Windows this is usually performed with a call to “LoadLibrary”. Since our entire purpose is to fuzz a function within this DLL, if it fails to load, we should just exit.

Figure 4 LoadLibrary

Now that the DLL is loaded into memory, we need to obtain the address of our target function. This is commonly done through “GetProcAddress”.

Figure 5 GetProcAddress

The next step, setting up the parameters for the target function, is arguably the most crucial and can be the most difficult step in building a test harness. The best trick to get this right is to find examples of your target function being called in the real application and then mimic this setup in your test harness.  In Netop, this function is only called by one other function. Figure 6 shows a slightly cleaned up version of a portion of the IDA decompilation of the function which calls MeImgLoadJpeg.

Figure 6 IDA Pro Decomplication of call to MeImgLoadJpeg

We can learn some key points from this call that are important to keep consistent if we want to find a useful crash. We know the first parameter (a2) is simply a file path. In our code, we do need to ensure our file path is in the format of a wide-character, since this is the typical format for a Windows file path. The second parameter (v8) is a Windows BITMAPINFOHEADER object. We can see from this code all the members of the BITMAPHEADER object are being set to 0 using a “memset”, except the “biSize”, which is being set to “40”. Since this is the only time this function is called in the Netop application, if we want to find a bug that has a chance to be leveraged through Netop, we need to follow this format. Why the value is set to 40 is less relevant for our purposes within the test harness; however, it may require investigation depending on any crashes found. The same principle holds true for the 3rd and final parameter. We see here it is hardcoded to zero, so we want to do the same. Could we test other values? Of course, but if Netop is hardcoded to zero we would never actually be able to pass anything else outside of our exercise. Using our additional understanding from Figure 6, we put the below code in Figure 7 into our harness.

Figure 7 Target Function Setup

With our parameters configured, we now need to simply call the function we want to fuzz. Where is the fuzzed data? In this case, our fuzzed data will be the jpeg file. The fuzzer will be passing a file path of a mutated jpeg file.

Figure 8 Calling MeImgLoadJpeg

This next step is highly dependent on the target function. If the target function will not fail in a manner that will crash your harness (throw an unhandled exception), then you need to create a crash for a failed test case. This can be seen in Figure 1 test.cpp. In this case, the target function has error handling and we are interested in any case which causes an unhandled exception within our DLL. If the DLL throws an unhandled exception, it will crash our test harness. As a result, we only need to check the return value for our own purposes to confirm things are working properly. This is good for initially testing, but we will want to remove any unnecessary code for our actual fuzz run. A non-null return value means the jpeg image was parsed and null means a handled error occurred, which is uninteresting for our case.

Figure 9 Checking the return value

With all this framework in place, we can run our harness with a valid image and confirm we get the expected result.

Figure 10 Test run

Performance Considerations

Although the above test harness code will successfully execute the target function and fully function within our fuzzer, we can make a few targeted changes to increase performance and results. One of the slowest operations in an application is printing to the screen, and this is true when fuzzing. Error checking is extremely helpful for development; however, printing “Result was not null” or the inverse every time will reduce our executions per second and doesn’t add anything to our fuzzer. Additionally, it is important not to introduce any extra code in our “fuzz” function which could potentially introduce additional code paths. This could cause the mutators to think that it found a new path of interesting code, when in fact it’s only the harness. As a result, you want your “fuzz” function to be the absolute bare minimum required to execute your code and perform other setup actions outside this function.

Selecting a Test Corpus

Now that we have a working test harness, we need to create a test corpus or input files for the fuzzer. The importance of this step for fuzzing cannot be overstated. The test cases produced by a fuzzer or only as good as the ones provided. In most cases, you are looking to create a set of minimal test inputs (and minimal size) that generate maximal code coverage.

Selecting or building a test corpus can be a complicated process. One of the advantages to using a known and popular format like JPEG is that there are many open-source corpora. Strongcourage’s corpus on GitHub is a great repo since it is many corpora combined and is the testing corpus that was used to find CVE-2021-36134. Jackalope does not recursively traverse directories when reading the input directory and does not throw an error in this regard, therefore it is important to make sure your corpus directory is only one level deep.

Results

Using this basic outlined method and running Jackalope in the same fashion as the example test binary, a write access violation crash is found in the MeImgLoadJpeg in just a few minutes. This write access violation bug is filed as CVE-2021-36134.

This violation occurs because of memory being allocated for the destination of a memory copy based on the default three color components of a JPEG image, instead of using the value provided in the input file’s JPEG header. The copy is using the values provided by the file to determine the address of where to copy the image in memory. A write access violation occurs when a malformed image reports having four color components instead of the default three and the memory allocated is not the same size as the actual image.

Given the extensive prior reports and full system vulnerabilities we submitted to NetOp before, we decided not to take the analysis further and determine if the bug was truly exploitable. The code path can be leveraged over the network, by utilizing the teacher’s blank student screen feature. It is worth noting this code runs on both the student and the teacher, so the teacher would be unable to load this image to send to a student without crashing their own system. An attacker could leverage the previously discovered and disclosed vulnerabilities to emulate a teacher and send this image to a student regardless.  Since the destination of the memory copy is being calculated based on image width and number of color components, it is plausible for an attacker to control where the “write” takes place; however, they would need to use an address space that could be calculated without invalidating the image further. In addition, the code is writing pixels from the image which is also under the attacker’s control. As a result, this could lead to a partial arbitrary write.

Conclusion

Fuzzing can be a fantastic tool for discovering new vulnerabilities in software. Although having source code can enhance fuzzing, it should not be considered a barrier of entry. Many tools and techniques exist which can be used to successfully fuzz blackbox targets and in turn help enhance the security of the industry.

One goal of the McAfee Enterprise Advanced Threat Research team is to identify and illuminate a broad spectrum of threats in today’s complex and constantly evolving landscape. Leveraging Google Project Zero team’s Jackalope and blackbox fuzzing techniques a JPEG parsing vulnerability, CVE-2021-36134 was discovered in Netop Vision Pro version 9.7.2. As per McAfee Enterprise’s vulnerability public disclosure policy, the ATR team informed Netop on June 25^th, 2021, and worked directly with the Netop team. This partnership resulted in the vendor working towards effective mitigations of the vulnerability detailed in this blog.

The post Finding 0-days with Jackalope appeared first on McAfee Blog.

Detecting Credential Stealing Attacks Through Active In-Network Defense

Executive Summary

Today, enterprises tend to use multiple layers of security defenses, ranging from perimeter defense on network entry points to host based security solutions deployed at the end user’s machines to counter the ever-increasing threats. This includes inline traffic filtering and management security solutions deployed at access and distribution layers in the network, as well as out of band solutions like NAC, SIEM or User Behavior Analysis to provide identity-based network access and gain more visibility into the user’s access to critical network resources. However, layered security defenses face the major and recurring challenge of detecting newer exploitation techniques as they heavily rely on known behaviors. Additionally, yet another significant challenge facing the enterprise network is detecting post-exploitation activities, after perimeter security is compromised.

Post initial compromise, to be able to execute meaningful attacks, attackers would need to steal credentials to move laterally inside the network, access critical network assets and eventually exfiltrate data. They will use several sophisticated techniques to perform internal reconnaissance and remote code execution on critical resources, which range from using legitimate operating system tools to discover network assets to using novel code execution techniques on the target. Consequently, differentiating between the legitimate and malicious use of Windows’ internal tools and services becomes a high priority for enterprise networks.

To tackle this long-standing problem of detecting lateral movement, enterprise networks must formulate active in-network defense strategies to effectively prevent attackers from accessing critical network resources. Network Deception is one such defensive approach which could potentially prove to be an effective solution to detect credential theft attacks. Detecting credential stealing attacks with deception essentially requires building the necessary infrastructure by placing the decoy systems within the same network as production assets and configuring them with decoy contents to lure the attackers towards the decoy machines and services. Accurately configuring and tuning the deceptive network can deflect the attacker’s lateral movement path towards the deceptive services, consequently allowing the attackers to engage with the deceptive network, helping enterprises protect production assets.

MITRE Shield, a knowledge base maintained by MITRE for active defense techniques highlights many of the methods in adversary engagement. Some of the techniques described by MITRE Shield Matrix with respect to network deception are as below:

MITRE Shield	Description	ATT&CK Technique
Decoy Account – DTE0010	A decoy account is created for defensive or deceptive purposes. The decoy account can be used to make a system, service, or software look more realistic or to entice an action	Account Discovery, Reconnaissance
Decoy Credentials – DTE0012	Seed a target system with credentials (such as username/password, browser tokens, and other forms of authentication data)	Credential Access, Privilege Escalation
Decoy Diversity – DTE0013	deployment of decoy systems with varying Operating Systems and software configurations	Reconnaissance
Decoy Network – DTE0014	Multiple computing resources that can be used for defensive or deceptive purposes	Initial Access
Decoy Personna – DTE0015	Used to establish background information about a user. In order to have the adversary believe they are operating against real targets	Initial Access, Discovery, Reconnaissance
Decoy System – DTE0017	Computing resources presented to the adversary in support of active defense	Reconnaissance

 

Over the course of this paper, we will discuss some of the widely adapted credential theft attacks executed by adversaries after the initial compromise and then move on to discuss defense techniques against the above MITRE Shield attacks and how to use them effectively to detect deceptive credential usage in the network.

Network Deception – An Active in-network defensive approach

• Most of the targeted attacks involve stealing credentials from the system at a certain point in time as attackers would use them to pivot to other systems in the network. Some of the credential stealing techniques like Golden Ticket attacks have been found to be used in multiple ransomwares armed with lateral movement capabilities.
• Active in-network defense strategies described by the MITRE Shield matrix are significant and play a critical role in detecting credential abuse in the network.
• Network Deception uses these active defense techniques to build the deceptive network infrastructure which could potentially lead to redirecting an attacker’s lateral movement path and engaging them to the decoy services without touching the critical production systems.
• It involves placing decoy systems, decoy credentials and decoy contents all throughout the production network essentially converting it into a trap, playing a crucial role in mitigating the attacks.

McAfee Protection

• McAfee MVISION Endpoint Security has the capabilities to protect against credential theft attacks like credential extraction from LSASS process memory via ATP rule 511. More details on configuring policies and a demo are available here.
• McAfee MVISION Endpoint Detection and Response (EDR) has the capabilities to detect credential access from tools like Mimikatz.
• With McAfee MVISION EDR and ENS integration with Attivo’s network and endpoint deception sensor, McAfee can manage its agents and receive alerts for detections in ePO and EDR.

Lateral Movement – Introduction

Lateral movement refers to the tools and techniques used by attackers to progressively expand their foothold within an enterprise network after gaining initial access. As shown in the figure below, lateral movement activity comprises of several stages starting from credential theft, target enumeration and discovery, privilege escalation, gaining access to network resources and eventually remote code execution on the target before exfiltrating data to accomplish a successful attack. Once inside the network, attackers will deploy a range of techniques at each stage of lateral movement to achieve their end goal. One of the primary challenges an attacker will face while moving laterally inside a network is to hide their activities in plain sight by generating a minimum volume of legitimate looking logs to be able to remain undetected. To achieve this, an attacker might choose to embed the tool within a malicious executable or use the operating system’s internal legitimate tools and services to perform its lateral movement operations, consequently making this network traffic harder to distinguish.

As per the Verizon DBIR report 2020, over 80% of data breaches involve credential theft attacks. Credential theft is one of the primary tasks attackers need to perform post-exploitation and after gaining initial control of the target machine. It will usually be the first step towards lateral movement strategies which will allow attackers to elevate their privileges and acquire access to other network resources. As indicated earlier, attackers have long been abusing Windows legitimate features like SMB, RPC over SMB, Windows Management Instrumentation, Windows Remote Management, and many other features to perform lateral movement activities. Figure 1 below highlights where lateral movement falls within the attack chain and its different stages. To remain stealthier, these activities would span a period ranging from many weeks to months.

Figure 1 – Stages of Lateral movement

To be able to distinguish between the admissible and malicious use of these inbuilt services, it is extremely critical for organizations to deploy advanced Threat Detection solutions. Over the course of this blog, we will discuss various credential theft techniques used by adversaries during lateral movement. We will also discuss an approach that can be used to effectively detect these techniques inside the network.

Credential Theft Attacks

Attackers use a variety of tools and techniques to execute credential theft attacks. Many of these tools are open source and readily available on the internet. Operating systems like Windows implement Single Sign On (SSO) functionality, which require the user’s credentials to be stored in memory, thereby allowing the OS to seamlessly access network resource without repeatedly asking the user to re-enter those credentials. Additionally, user credentials are stored in memory in a variety of formats like NTLM hashes, reversibly encrypted plaintext, Kerberos tickets, PINs, etc., which can be used to authenticate to services depending upon the supported authentication mechanism. These credentials can be acquired by attackers from memory by parsing appropriate credential storage structures or using the Windows credential enumeration APIs.  Consequently, these attacks pose major security concerns, especially in the domain environment if the attacker gains access to privileged credentials which can then be reused to access critical network resources. In the following sections, we discuss some of the widely adapted credential stealing techniques used by malware, with respect to the Windows operating system. Similar credential stealing techniques can also be used with other operating systems as well.

Stealing Credentials from LSASS Process Memory

The Local Security Authority Subsystem Service (LSASS) process manages and stores the credentials of all the users with active Windows sessions. These credentials stored in the LSASS process memory will allow users to access other network resource such as files shares, email servers and other remote services without asking them for the credentials again. LSASS process memory stores the credentials in many formats including reversibly encrypted plaintext, NTLM hashes, Kerberos Tickets (Ticket Granting Tickets, etc.). These credentials are generated and stored in the memory of the LSASS process when a user initiates the interactive logon to the machine such as console logon or RDP, runs a scheduled task or uses remote administration tools. The encryption and decryption of credentials is done using LsaProtectMemory and LsaUnProtectMemory respectively and hence a decryption tool using these APIs will be able to decrypt LSASS memory buffers and extract them. However, malware would need to execute with local administrator privileges and enable “SeDebugPrivilege” on the current process to be able access the LSASS process memory.

Below is a code snapshot from one of the famous credential harvesting tools, Mimikatz, enabling the required privileges on the calling thread before dumping the credentials.

Figure 2 – Checking for required privileges

We can see that the NTLM hash of the user’s credentials is revealed, and this can be brute forced offline as shown below. Many Windows services, such as SMB, support NTLM authentication and NTLM hashes can be used directly for authentication eliminating the need for the clear text passwords.

Figure 3 – Cracking NTLM Hashes offline

Attackers avoid using freely available tools like Mimikatz directly on the target machine to harvest credentials since they are easily detected by AVs. Instead, they use recompiled clones of it with minimal functionality to avoid noise. Below is one such instance where malware embeds recompiled Mimikatz code with the minimal required functionality.

Figure 4 – Credential extraction tool embedded inside malicious executable

Detection can also be avoided by using several “living off the land’ mechanisms, available in many post-exploitation frameworks, to execute the credential harvesting tools directly from memory using Reflective PE injection, where the binary is never written to the disk. Yet another approach is to dump the LSASS process memory using process dumping tools, exfiltrate the dump and extract the credentials offline. Microsoft has documented multiple ways to configure additional LSASS process protection which can prevent credentials being compromised.

Stealing Credentials from Security Accounts Manager (SAM) Database

The SAM database is a file on a local hard drive that stores the credentials for all local accounts on the Windows computer. NT hashes for all the accounts on the local machine, including the local administrator credential hash, are stored in the SAM database. The SAM database file is in %SystemRoot%system32/config and the hashes of the credentials are within the registry HKLM\SAM. Attackers need to acquire elevated privileges to be able to access the credentials from the SAM database. The example below demonstrates how the credentials from the SAM database can be revealed through a simple Meterpreter session.

Figure 5 – Dumping SAM database

Stealing Credentials from Windows Credential Manager (CredMan)

Windows Credential Manager stores the Web and SMB/RDP credentials of users if they choose to save them on the Windows machine, thereby preventing the authentication mechanism from asking for those passwords again on subsequent logins. These credentials are encrypted with Windows Data Protection APIs (DPAPI) CryptProtectData, either using the current user’s logon session or a generated master key, and then saved on the local hard drive. Consequently, any process running in the context of the logged in user will be able to decrypt the credentials using CryptUnProtectData DPAPI. In the domain environment, these credentials can be used by attackers to pivot to other systems in the network. Data Protection APIs provide the cryptographic functionalities that can be used to securely store credentials and keys. These APIs are used by several other Windows components like browsers (IE/Chrome), certificates and many other applications as well. Below is one example of how credential dumping tools like Mimikatz can be used to dump stored Chrome credentials.

Figure 6 – Dumping browser credentials

DPAPI can be abused in multiple ways. In the Active Directory domain joined environment, if other users have logged into the compromised machine, provided a malware is running with escalated privileges, it can extract other user’s master keys from the LSASS memory which can then be used to decrypt their secrets. Below is a screenshot of how the master key can be extracted by using the credential dumping tool.

Figure 7 – Extracting DPAPI Master Key

Malware also tends to use multiple variants of credential enumeration APIs available within Windows. These APIs can extract credentials from Windows Credential Manager. Below is one instance of the malware using CredEnumerateW API to retrieve credentials and then search for terminal services passwords which It would use to pivot to other systems.

Figure 8 – Extracting credentials using Windows API

Stealing Service Account Credentials Through Kerberoasting

In the domain joined environment, the Kerberos protocol has a significant role to play with respect to authentication and requesting access to services and applications. It provides Single-Sign-On functionality for accessing multiple shared resources within the enterprise network. The Kerberos authentication mechanism in Active Directory involves multiple requests and responses like Ticket Granting Ticket (TGT) and Ticket Granting Service (TGS) supported by a Key Distribution Server (KDC), usually a Domain Controller. Upon successful authentication, a user will be able to access the respective services.

Attackers gaining access to a system joined in the domain would usually look for high value assets like Active Directory Controller, Database server, SharePoint server, Web Server, etc., and these services are registered in the domain with the specific Service Principal Name (SPN) values, which is a unique identifier of the Service Account in the domain. These SPN values are used by Kerberos to map the instance with the logon account allowing the client to authenticate to the respective service. Well known SPN values are listed out here. Once the attacker is authenticated with any domain user credentials and has information about the SPN values of the services within the domain, they can initiate the Kerberos Ticket Granting Service request (TGS – REQ) to the Key Distribution Server with the specified SPN value. Details on how the SPN values are registered and used in Kerberos authentication is documented here. TGS response from the KDC will have the Kerberos Ticket encrypted with the hash of the service account. This ticket can be extracted from the memory and can be brute forced offline to acquire service account credentials, allowing a domain user to gain admin level access to the service.

Kerberoasting is a well-documented attack technique listed in MITRE ATT&CK and it essentially abuses the Kerberos authentication allowing adversaries to request the TGS Tickets for the valid service accounts and brute force the ticket offline to extract the plain text credentials of the service accounts, consequently enabling them to elevate their privileges from domain user to domain admin. As an initial step to this lateral movement technique, the attacker would perform an internal reconnaissance to gain information about the services registered in the domain and get SPN values. A simple PowerShell command after importing the Active Directory PowerShell module, as shown below, can initiate the LDAP query to get information about all the user accounts from the Domain Controller with the SPN value set.

Figure 9 – PowerShell command to generate LDAP query

Attackers can specifically choose to scan the domain for MSSQL service with the registered SPN value used for Kerberos authentication. PowerShell scripts like GetUserSPNs can scan all the user SPNs in the domain or MSSQL service registered in the domain with Discover-PSMSSQLServers or Invoke-Kerberoast scripts.  Following is an example output from the script:

Figure 10 – Kerberoasting PowerShell script output

Once an attacker has the SPN value of the SQL service, a Kerberos Ticket Granting Service Ticket request (TGS-REQ) can be initiated to the domain controller with the SPN value. This can be done by a couple of PowerShell commands generating KRB-TGS-REQ as shown below:

Figure 11 – Kerberos TGS request

Consequently, the Domain Controller sends the TGS-RESP with the ticket of the service account which will be cached in the memory and can be extracted by dumping tools like Mimikatz as a .kirbi document. This can be brute forced offline by tgsrespcrack, allowing the attacker to gain unrestricted access to the service with elevated privileges.

Stealing Credentials from Active Directory Domain Service (ntdis.dit) File

As indicted earlier, once an attacker has penetrated the domain network, it will be natural to progress towards targeting critical assets, such as the Active Directory controller. The Active Directory Database Services AD DS Ntds.dit file is one of the most overlooked attack vectors in the domain environment but can have significant impact if the attacker is able to gain the domain administrative rights leading to complete domain compromise.

The Ntds.dit file is the authoritative store of credentials for all the users in the domain joined environment, storing all the information about the users, groups and memberships, including credentials (NT Hashes) of all the users in the domain with historical passwords and user’s DPAPI backup master keys. An Attacker with domain admin rights can gain access to the Domain Controller’s file system and acquire credentials like hashes, Kerberos tickets and other reversibly encrypted passwords of all the users joined in the domain by dumping and exfiltrating the Ntds.dit file. These credentials can then be used by the attacker to further access resources by using attack techniques like PTH within the network since the credentials used across other shared resource could be same.

Multiple techniques can be used to dump the Ntds.dit file from the Domain Controller locally as well as remotely and extract the NTLM hashes/DPAPI backup keys for all the domain joined users. One of the techniques is to use the Volume Shadow Copy Service using the vssadmin command line utility and then extract the Ntds.dit file from the volume shadow copy as shown below.

Figure 12 – Dumping Volume shadow copy for C drive

Sensitive data on Active Directory is encrypted with the Boot Key (Syskey) stored in the SYSTEM registry hive and dumping the SYSTEM registry hive is a prerequisite as well to be able to extract all the credentials.

Publicly available Active Directory auditing frameworks like DSInternals provide PowerShell cmdlets to extract the Syskey from the SYSTEM registry hive and extract all the credentials from the Ntds.dit file.

Ntds.dit can also give access to the powerful service account within the Active Directory Domain, KRBTGT (Key Distribution Centre Service account). Acquiring the NTLM hash of this account can enable the attacker to execute a Golden Ticket attack leading to complete domain compromise with unrestricted access to any service on the domain joined system.

Stealing Credentials Through a DCSync Attack – From Domain user to Domain Admin

A DCSync attack is a method of credential acquisition which allows an attacker to impersonate the Domain Controller and can consequently replicate all the Active Directory objects to the impersonating client remotely, without requiring the user to logon to the DC or dumping the Ntds.dit file. By impersonating the Domain Controller, the attacker could acquire the NTLM hash of the KRBTGT service account, enabling them to gain access to all the shared resources and applications in the domain joined environment. To be able to execute this credential stealing technique, an attacker would have to compromise the user account with the required permissions, specifically DS-Replication-Get-Changes and DS-Replication-Get-Changes-All, as shown below.

Figure 13 – User with privileges

Once the attacker compromises the user account with the required privileges, Pass-The-Hash attacks can be executed to spawn a command shell with the forged logon session. Credential dumping tools like Mimikatz do this by enumerating all the user logon sessions and replacing the user credentials with the stolen usernames and NTLM hashes provided, in the current logon session. Behind the scenes, this is executed by duplicating the current process’s access token, replacing the user credentials pointed by duplicated access token and subsequently using the modified access token to start a new process with the stolen credentials which will be used for network authentication. This is as shown below for example user “DCPrivUser”.

Figure 14 – Pass-the-Hash attack

Further, as indicated below, any subsequent NTLM authentication from the logon session will use the stolen credentials to authenticate to domain joined systems like the Active Directory Controller.

Attackers can now initiate the AD user objects Replication request to the Domain Controller using Directory Replication Services Remote Protocol (DRSUAPI). DRSUAPI is the RPC protocol used for replication of AD objects. With DCERPC bind request to DRSUAPI, an RPC call to DSGetNCChanges will replicate all the user AD objects to the impersonating client. Attackers would usually target the KRBTGT account since acquiring the NTLM hash of this account will enable them to execute a Golden Ticket attack resulting in unrestricted access to domain services and applications.

Figure 15 – DCSync Attack

As indicated earlier, with the NTLM hash of the KRBTGT account, adversaries can initiate a Golden Ticket attack (Pass-the-Ticket) by injecting the forged Kerberos tickets into the current session which can be used to authenticate to any service with the client that supports pass the ticket (for instance, sqlcmd.exe connection to DB server, PsExec, etc.)

Figure 16 – Golden ticket with forged Kerberos ticket

Detecting Credential Stealing Attacks with Network Deception

The credential theft techniques we discussed in the previous sections are just the tip of the iceberg. Adversaries can use many other sophisticated credential stealing techniques to take advantage of system misconfigurations and legitimate administrative tools and protocols and, at the same time, remain undetected for a longer period. With many other event management solutions with SIEMs, used in conjunction with other network security solutions, it becomes a challenge for administrators to distinguish malicious use of legitimate tools and services from lateral movement. Perimeter solutions have their limitations in terms of visibility once the attacker crosses the network boundary and is inside the domain environment. It is extremely critical for organizations to protect and monitor critical network assets like the Domain Controller, Database server, Exchange Servers, build systems and other applications or services, as compromising these systems will result in significant damages. Therefore, enterprise networks must deploy a solution to detect credential stealing attacks as they can be used to pivot to other systems on the network and move laterally once an attacker establishes an attack path to a high value target. If the deployment of a solution within the critical zones of the network can detect the use of stolen credentials before adversaries can reach their target, the critical assets could still be prevented from being compromised.

Network Deception is one such deployment within the domain environment where, using the MITRE Shield techniques like decoy systems and network, decoy credentials, decoy accounts, decoy contents, could potentially help detect lateral movement early in the adversary’s attack path to the target asset and at the same time, report significantly low false detection rates. The idea of deception originates from the decades old honeypot systems but, unlike those, relies more on forging trust and giving adversaries what they are looking for. With its inbuilt proactiveness it is configured to lure attackers towards deceptive systems. As shown in the figure below, Network Deception consists of authentic looking decoy systems placed within the domain network, specifically in the network where the critical assets are placed. These decoy systems (could be virtual machines) are the full-fledged OS with configured applications or services and could be replicating the crucial services like Domain Controller, Exchange or DB server and other decoy machines that could lead to those systems. The image below highlights the key foundational aspects of the Network Deception

Figure 17 – Network Deception

Key Aspects of Network Deception

As visualized in the figure above, Network Deception comprises the following key basic facts with respect to the deployment in the domain joined environment:

• As a part of deployment, decoy/deceptive machines are planted within the network alongside production systems and critical assets. These decoy systems could be real systems or virtual systems with production grade operating systems with the required setup to make them blend well with real systems.
• As one of the key aspects, deceptive machines are configured to lure attackers towards the decoy services instead of the production services, thereby deflecting or misleading the attacker’s lateral movement path to the target asset.
• Many of the decoy machines could replicate critical services like Domain Controller, DB servers, Exchange/SharePoint servers and other critical services or applications within the data center.
• Any legitimate domain user should not be generating traffic to or communicating with the configured decoy machines unless there are some misconfigurations in the network, which need to be corrected.

Basic Decoy Network Setup

Since credential theft plays an important role in a successful targeted attack, deception essentially focuses on planting fake credentials on the production and decoy endpoints at multiple places within the OS and monitoring the use of these credentials to pivot to other systems. With respect to the network setup, the following are the key aspects, however this list is not exhaustive, and much more could be added:

• Replicating critical network assets and services with decoy machines: Replicating critical network services like Active Directory, DB services, etc., will make more sense since these are the most targeted systems in the network. The decoy Active Directory should be configured with deceptive AD objects (users, groups, SPNs, etc.). with deceptive contents for other replicated services.
• Planting authentic looking decoy machines in the production network: As indicated earlier, these decoy machines could be real or virtual machines with the production grade OS placed alongside production systems in the critical infrastructure to blend in well. These decoy machines should be joined to the decoy AD and configured with deceptive user accounts to monitor successful logon attempts to the systems.
• Injecting deceptive credentials on production endpoints: Production endpoints should be injected with deceptive credentials at multiple places like LSASS process memory, Credential Manager, browser credentials, etc., to increase the possibility of these credentials being picked up and used to pivot to decoy systems in the network. These endpoints could be public facing machines or their replicas as well.
• Decoy Machine runs client applications pointing to decoy services: Decoy machines may run the client with deceptive credentials and configured to point to the decoy services. These could be DB/FTP/Email clients and any other replicated decoy services.
• Mark decoy systems as “NO LANDING ZONE”: One of the key deployment aspects of deception is to mark all the decoy systems and services as “NO LANDING ZONE”, essentially meaning no legitimate domain users should be accessing decoys and any attempts to access these systems should be closely monitored.

Some of the other setup required for effective deployment of deception is as summarized below:

Figure 18 – Deceptive network setup – Basic requirements

Basic Decoy Systems Setup

To detect the use of deceptive credentials, setting up decoy machines is an essential part of the solution as well. Primarily, decoy machines should enable the access attackers are looking to have during the lateral movement phase. Decoys should also be configured to enable relevant auditing services to be able to generate events. For instance, the following enables the account logon events to be audited:

Decoy machines must be setup to run the log collector agent that can collect the access logs generated and forward them to the correlation server. However, in the domain joined environment, it is also essential to tune the decoy machines to forward only the relevant logs to the correlation server to minimize false positives.

The below highlights some of the auditing required to be enabled on the decoy systems for effective correlation.

Figure 19 – Basic decoy setup

Illustrating and Achieving Network Deception

The following sections describe some examples of how deception can be achieved in the domain network, along with a visualization of how credential theft can be detected.

Network Deception – Example 1: Injecting NETONLY credentials into LSASS process memory

LSASS process memory is one of the prime targets for attackers, as well as malware armed with lateral movement capabilities since it caches a variety of credentials. Credential extraction from the LSASS process requires opening a read handle to the process itself which is closely monitored by EDR products but there are stealthier ways around it.

One of the primary tasks towards achieving credential-based deception is to stage the deceptive credentials in LSASS process memory. This can be accomplished on the production and decoy systems by executing a trivial credential injection code which uses the CreateProcessWithLogonW Windows API with the specified crafted credentials. CreateProcessWithLogonW creates the new logon session using the caller process access token and spawns the process specified as a parameter in the security context of the specified deceptive credentials and it will be staged in the LSASS memory until the process runs in the background. The below shows the example code calling the API with the specified credentials which is also visible when credentials are extracted with Mimikatz.

Figure 20 – Injecting credentials into LSASS memory

One of the parameters to CreateProcessWithLogonW is “dwLogonFlags” which should be specified as LOGON_NETCREDENTIALS_ONLY as shown in the code above. This ensures the specified credentials are used only on the network and not for local logons. Additionally, NETONLY credentials used to create a logon session are not validated by the system. Below is a code snapshot from credential extraction tool Mimikatz, using a similar approach to forge a logon session and replacing the credentials with the supplied ones while executing Pass-the-Hash attacks.

Figure 21 – Mimikatz code for PTH attack

Network Deception – Example 2: Configure deceptive hostnames for decoy VMs

Attackers or malware moving laterally inside the network might do a recon for interesting hostnames via nbtstat/nbtscan. To deflect the lateral movement path, decoy systems can be configured with real looking hostnames that match the production systems. These hostnames will then be visible on NetBIOS scans as shown below.

Figure 22 – Deceptive host names pointing to decoy machines

These decoy systems can also run the relevant client applications pointing to the decoy services, with authentication directed to the decoy Domain Controller in the network. Detection of this attack path happens much earlier, however the decoy network setup keeps the adversaries engaged, helping admins to study their Tools and Techniques.

Figure 23 – Decoy machines running clients pointing to decoy services

A similar deception setup can also be done for the browsers where saved credentials can point to the decoy applications and services within the domain. For instance, Chrome saves the credentials in the SQLite format on the disk which can be decrypted using DPAPI as discussed earlier sections. The below examples demonstrate deceptive browser credentials which can lure adversaries towards the decoy services.

Figure 24 – Inserting deceptive browser credentials

In addition to some of the techniques discussed above, and many others highlighted in the previous sections, setting up deception involves much more advanced configuration of decoy systems to minimize false positives and needs to be tuned to the environment to accurately identify malicious activities. Deception can also be configured to address multiple other phases of lateral movement activity including reconnaissance and target discovery, essentially redirecting the adversaries and giving them a path to the target. Below is a high-level visualization of how the decoy network can look like the domain environment.

Figure 25 – Deception network setup

On the occasion where one of the domain-joined or public facing systems is compromised, authentication would be attempted to other domain joined systems in the network. If an authentication is attempted and any of the decoy systems are accessed and logged on, the use of these planted deceptive credentials should be a red flag and something which must be investigated. The visualization below shows the flow and an event being sent to an administrator on accessing one of the decoy systems.

Figure 26 – Deceptive credentials usage for authentication in the domain

One such example event of successfully logging on to the decoy system is as shown below:

Figure 27 – Alert send to administrator on using deceptive credentials

MITRE ATT&CK Techniques:

Credential theft attacks discussed here are mapped by MITRE as below:

Technique ID	Technique Name	Description
T1003.001	LSASS Process Memory	Attackers may attempt to access LSASS process memory to extract credentials as it stores a variety of credentials. Administrative privileges are required to access the process memory.
T1003.002	SAM Database	Accessing credentials from SAM database requires SYSTEM level privileges. Stores credentials for all the local user accounts on the machine.
T1003.003	NTDS.dit file	Contains credentials for all the domain users. File is present on the DC and domain admin privileges are required to access this file.
T1003.006	DCSync	Attacker can extract the credentials from the DC by impersonating the domain controller and use DRSUAPI protocol to replicate credentials from DC.
T1558.001	Golden Ticket	Attackers acquiring credentials for KRBTGT account can forge the Kerberos ticket called Golden Ticket, allowing them to get unrestricted access to any system in the domain
T1558.002	Silver Ticket	Allows attacker to get admin level access to the service accounts by abusing Kerberos authentication
T1558.003	Kerberoasting	Allows attackers to extract the Kerberos tickets for service accounts from memory and brute force offline to get credentials

Conclusion

As credential theft attacks play a significant role in an attacker’s lateral movement, so as in-network defense for the defenders. With attackers’ lateral movement tactics evolving and getting more stealthier, defenders will have to adapt to innovative ways of defending the critical network assets. In–network defense strategies like Deception could prove to be a promising and forward-looking approach towards detecting and mitigating data theft attacks. Strategic planting of decoy systems within the production network, inserting decoy credentials and decoy contents on calculative selection of endpoints and decoy systems and accurately setting up the logging and correlation via SIEMs for monitoring the use of decoy contents, could certainly detect and mitigate the attacks early in the lateral movement life cycle.

Endpoint solutions like User Entity Behavior Analytics (UEBA) and Endpoint Detection and Response (EDR) could also play a significant role in building the deception infrastructure. For instance, one of the ways UEBA solutions could prove useful is to baseline user behavior and monitor access to credential stores on the system. UEBA/EDR could raise the red flag on injection of forged Kerberos tickets in the memory. This can provide user level visibility to a greater extent when integrated with SIEM, playing a crucial role in mitigating credential theft attacks.

The post Detecting Credential Stealing Attacks Through Active In-Network Defense appeared first on McAfee Blog.

BlackMatter Ransomware Analysis; The Dark Side Returns

BlackMatter is a new ransomware threat discovered at the end of July 2021.

This malware started with a strong group of attacks and some advertising from its developers that claims they take the best parts of other malware, such as GandCrab, LockBit and DarkSide, despite also saying they are a new group of developers. We at McAfee Enterprise Advanced Threat Research (ATR), have serious doubts about this last statement as analysis shows the malware has a great deal in common with DarkSide, the malware associated with the Colonial Pipeline attack which caught the attention of the US government and law enforcement agencies around the world.

The main goal of BlackMatter is to encrypt files in the infected computer and demand a ransom for decrypting them. As with previous ransomware, the operators steal files and private information from compromised servers and request an additional ransom to not publish on the internet.

COVERAGE AND PROTECTION ADVICE

McAfee’s EPP solution covers BlackMatter ransomware with an array of prevention and detection techniques.

ENS ATP provides behavioral content focusing on proactively detecting the threat while also delivering known IoCs for both online and offline detections. For DAT based detections, the family will be reported as Ransom-BlackMatter!<hash>. ENS ATP adds 2 additional layers of protection thanks to JTI rules that provide attack surface reduction for generic ransomware behaviors and RealProtect (static and dynamic) with ML models targeting ransomware threats.

Updates on indicators are pushed through GTI, and customers of Insights will find a threat-profile on this ransomware family that is updated when new and relevant information becomes available.

TECHNICAL DETAILS

BlackMatter is typically seen as an EXE program and, in special cases, as a DLL (Dynamic Library) for Windows. Linux machines can be affected with special versions of it too but in this report, we will only be covering the Windows version.

This report will focus on version 1.2 of BlackMatter while also noting the important changes in the current version, 2.0.

BlackMatter is programmed in C++ and has a size of 67Kb.

FIGURE 1. Information about the malware

The compile date of this sample is the 23rd of July 2021. While these dates can be altered, we think it is correct; version 1.9 has a compile time of 12 August 2021 and the latest version, 2.0, has a date four days later, on the 16th of August 2021. Is clear that the malware developers are actively improving the code and making detection and analysis harder.

The first action performed by BlackMatter is preparation of some modules that will be needed later to get the required functions of Windows.

FIGURE 2. BlackMatter searching for functions

BlackMatter uses some tricks to try and make analysis harder and avoid debuggers. Instead of searching for module names it will check for hashes precalculated with a ROT13 algorithm. The modules needed are “kernel32.dll” and “ntdll.dll”. Both modules will try to get functions to reserve memory in the process heap. The APIs are searched using a combination of the PEB (Process Environment Block) of the module and the EAT (Export Table Address) and enumerating all function names. With these names it will calculate the custom hash and check against the target hashes.

FIGURE 3. BlackMatter detecting a debugger

At this point BlackMatter will make a special code to detect debuggers, checking the last 2 “DWORDS” after the memory is reserved, searching for the bytes “0xABABABAB”. These bytes always exist when a process reserves memory in the heap and, if the heap has one special flag (that by default is set when a process is in a debugger), the malware will avoid saving the pointer to the memory reserved so, in this case, the variables will keep a null pointer.

In Windows operating systems the memory has different conditions based on whether a program is running in normal mode (as usual) or in debugging mode (a mode used by programmers, for example). In this case, when the memory is reserved to keep information, if it is in debugging mode, Windows will mark the end of this memory with a special value, “0xABABABAB”. BlackMatter checks for this value and, if found, the debugger is detected. To avoid having it run normally it will destroy the function address that it gets before, meaning it will crash, thus avoiding the execution.

FIGURE 4. Preparing the protection stub function

After this check it will create a special stub in the reserved memory which is very simple but effective in making analysis harder as the stub will need to be executed to see which function is called and executed.

This procedure will be done with all functions that will be needed; the hashes are saved hardcoded in the middle of the “.text” section in little structs as data. The end of each struct will be recognized by a check against the “0xCCCCCCCC” value.

FIGURE 5. Hashes of the functions needed

This behavior highlights that the BlackMatter developers know some tricks to make analysis harder, though it is simple to defeat both by patching the binary.

After this, the ransomware will use another trick to avoid the use of debuggers. BlackMatter will call the function “ZwSetInformationThread” with the class argument of 0x11 which will hide the calling thread from the debuggers.

If the malware executes it correctly and a debugger is attached, the debugging session will finish immediately. This code is executed later in the threads that will be used to encrypt files.

FIGURE 6. Another way to detect a debugger

The next action is to check if the user that launched the process belongs to the local group of Administrators in the machine using the function “SHTestTokenMembership”. In the case that the user belongs to the administrator group the code will continue normally but in other cases it will get the operating system version using the PEB (to avoid using API functions that can alter the version) and, if it is available, will open the process and check the token to see if that belongs to the Administrators group.

FIGURE 7. BlackMatter checking if it has administrator rights

In the case that the user does not belong to the Administrator group the process token will use a clever trick to escalate privileges.

The first action is to prepare the string “dllhost.exe” and enumerate all modules loaded. For each module it will check one field in the initial structure that all executables have that keeps the base memory address where it will be loaded (for example, kernel32.dll in 0x7fff0000) and will compare with its own base address. If it is equal, it will change its name in the PEB fields and the path and arguments path to “dllhost.exe” (in the case of the path and argument path to the SYSTEM32 folder, where the legitimate “dllhost.exe” exists). This trick is used to try and mislead the user. For each module found it will check the base address of the module with its own base address and, at that moment, will change the name of the module loaded, the path, and arguments to mislead the user.

FIGURE 8. Decryption of the string “dllhost.exe”

The process name will be “dllhost.exe” and the path will be the system directory of the victim machine. This trick, besides not changing the name of the process in the TaskManager, can make a debugger “think” that another binary is loaded and remove all breakpoints (depending on the debugger used).

FIGURE 9. Changing the name and path in the PEB

The second action is to use one exploit using COM (Component Object Model) objects to try to elevate privileges before finishing its own instance using the “Terminate Process” function.

For detection, the module uses an undocumented function from NTDLL.DLL, “LoadedModulesLdrCallback” that lets the programmer set a function as a callback where it can get the arguments and check the PEB. In this callback the malware will set the new Unicode strings using “RtlInitUnicodeString”; the strings are the path to “dllhost.exe” in the system folder and “dllhost.exe” as the image name.

The exploit used to bypass the UAC (User Access Control), which is public, uses the COM interface of CMSTPLUA and the COM Elevation Moniker.

In the case that it has administrator rights or uses the exploit with success, it will continue making the new extension that will be used with the encrypted files. For this task it will read the registry key of “Machine Guid” in the cryptographic key (HKEY LOCAL MACHINE).

This entry and value exist in all versions of Windows and is unique for the machine; with this value it will make a custom hash and get the final string of nine characters.

FIGURE 10. Creating the new extension for the encrypted files

Next, the malware will create the ransom note name and calculate the integrity hash of it. The ransom note text is stored encrypted in the malware data. Usually the ransom note name is “%s.README.txt”, where the wildcard is filled with the new extension generated previously.

The next step is to get privileges that will be needed later; BlackMatter tries to get many privileges:

·         SE_BACKUP_PRIVILEGE ·         SE_DEBUG_PRIVILEGE, SE_IMPERSONATE_PRIVILEGE ·         SE_INC_BASE_PRIORITY_PRIVILEGE ·         SE_INCREASE_QUOTA_PRIVILEGE ·         SE_INC_WORKING_SET_PRIVILEGE ·         SE_MANAGE_VOLUME_PRIVILEGE ·         SE_PROF_SINGLE_PROCESS_PRIVILEGE ·         SE_RESTORE_PRIVILEGE ·         SE_SECURITY_PRIVILEGE ·         SE_SYSTEM_PROFILE_PRIVILEGE ·         SE_TAKE_OWNERSHIP_PRIVILEGE ·         SE_SHUTDOWN_PRIVILEGE

 

FIGURE 11. Setting special privileges

After getting the privileges it will check if it has SYSTEM privileges, checking the token of its own process. If it is SYSTEM, it will get the appropriate user for logon with the function “WTSQueryUserToken”. This function only can be used if the caller has “SeTcbPrivilege” that, by default, only SYSTEM has.

FIGURE 12. Obtaining the token of the logged on user

After getting the token of the logged on user the malware will open the Windows station and desktop.

In the case that it does not have SYSTEM permissions it will enumerate all processes in the system and try to duplicate the token from “explorer.exe” (the name is checked using a hardcoded hash), if it has rights it will continue normally, otherwise it will check again if the token that was duplicated has administrator rights.

In this case it will continue normally but in other cases it will check the operating system version and the CPU (Central Processing Unit) mode (32- or 64- bits). This check is done using the function “ZwQueryInformationProcess” with the class 0x1A (ProcessWow64Information).

FIGURE 13. Checking if the operating system is 32- or 64-bits

In the case that the system is 32-bits it will decrypt one little shellcode that will inject in one process that will enumerate using the typical “CreateRemoteThread” function. This shellcode will be used to get the token of the process and elevate privileges.

In the case that the system is 64-bits it will decrypt two different shellcodes and will execute the first one that gets the second shellcode as an argument.

FIGURE 14. BlackMatter preparing shellcodes to steal system token

These shellcodes will allow BlackMatter to elevate privileges in a clean way.

Is important to understand that to get the SYSTEM token BlackMatter will enumerate the processes and get “svchost.exe”, but not only will it check the name of the process, it will also check that the process has the privilege “SeTcbPrivilege”. As only SYSTEM has it by default (and it is one permission that cannot be removed from this “user”) it will be that this process is running under SYSTEM and so it becomes the perfect target to attack with the shellcodes and steal the token that will be duplicated and set for BlackMatter.

FIGURE 15. Checking if the target process is SYSTEM

After this it will decrypt the configuration that it has embedded in one section. BlackMatter has this configuration encrypted and encoded in base64.

This configuration has a remarkably similar structure to Darkside, offering another clear hint that the developers are one and the same, despite their claims to the contrary.

After decryption, the configuration can get this information:

RSA Key used to protect the Salsa20 keys used to encrypt the files. A 16-byte hex value that remarks the victim id. A 16-byte hex value that is the AES key that will be used to encrypt the information that will be sent to the C2. An 8/9-byte array with the behavior flags to control the ransomware behavior. A special array of DWORDs (values of 4 bytes each one) that keep the values to reach the critical points in the configuration. Different blocks encoded and, sometimes, encrypted again to offer the field more protection.

 

After getting the configuration and parsing it, BlackMatter will start checking if it needs to make a login with some user that is in the configuration. In this case it will use the function “LogonUser” with the information of the user(s) that are kept in the configuration; this information has one user and one password: “test@enterprise.com:12345” where “test” is the user, “@enterprise.com” is the domain and “12345” the password.

The next action will be to check with the flag to see if a mutex needs to be created to avoid having multiple instances.

This mutex is unique per machine and is based in the registry entry “MachineGuid” in the key “Cryptography”. If the system has this mutex already the malware will finish itself.

Making a vaccine with a mutex can sometimes be useful but not in this case as the developers change the algorithm and only need to set the flag to false to avoid creating it.

FIGURE 16. Creation of the mutex to avoid multiple instances

After, it will check if it needs to send information to the C2. If it does (usually, but not always) it will get information of the victim machine, such as username, computer name, size of the hard disks, and other information that is useful to the malware developers to know how many machines are infected.

This information is encoded with base64 and encrypted with AES using the key in the configuration.

FIGURE 17. Encrypted information sent to the C2

The C2 addresses are in the configuration (but not all samples have them, in this case the flag to send is false). The malware will try to connect to the C2 using a normal protocol or will use SSL checking the initial “http” of the string.

FIGURE 18. Get information of the victim machine and user

The information is prepared in some strings decrypted from the malware and sent in a POST message.

FIGURE 19. Choose to send by HTTP or HTTPS

The message has values to mislead checks and to try and hide the true information as garbage. This “fake” data is calculated randomly.

The C2 returns garbage data but the malware will check if it starts and ends with the characters “{“  and “}”; if it does the malware will ignore sending the information to another C2.

FIGURE 20. Checking for a reply from the C2 after sending

BlackMatter is a multithread application and the procedure to send data to the C2 is done by a secondary thread.

After that, BlackMatter will enumerate all units that are FIXED and REMOVABLE to destroy the recycle bin contents. The malware makes it for each unit that has it and are the correct type. One difference with DarkSide is that it has a flag for this behavior while  BlackMatter does not.

The next action is to delete the shadow volumes using COM to try and avoid detection using the normal programs to manage the shadow volumes. This differs with DarkSide that has a flag for this purpose.

FIGURE 21. Destruction of the shadow volumes using COM

BlackMatter will check another flag and will enumerate all services based on one list in the configuration and will stop target services and delete them.

This behavior is the same as DarkSide.

FIGURE 22. Stopping services and deleting them

Processes will be checked and terminated as with DarkSide, based on other configuration flags.

After terminating the processes BlackMatter will stop the threads from entering suspension or hibernating if someone is using the computer to prevent either of those outcomes occurring when it is encrypting files. This is done using the function “ZwSetThreadExecutionState”.

FIGURE 23. Preventing the machine being suspended or hibernated

The next action will be to enumerate all units, fixed and on the network, and create threads to encrypt the files. BlackMatter uses Salsa20 to encrypt some part of the file and will save a new block in the end of the file, protected with the RSA key embedded in the configuration with the Salsa20 keys used to encrypt it. This makes BlackMatter slower than many other ransomwares.

After the encryption it will send to the C2 all information about the encryption process, how many files were crypted, how many files failed, and so on. This information is sent in the manner previously described, but only if the config is set to true.

FIGURE 24. Release of the mutex

If one mutex was created in this moment it will be released. Later it will check the way that the machine boots with the function “GetSystemMetrics”. If the boot was done in Safe Mode BlackMatter will set some keys for persistence in the registry for the next reboot and then attack the system, changing the desktop wallpaper.

FIGURE 25. Determining whether the system boots in safe mode or normal mode

Of course, it will disable the safeboot options in the machine and reboot it (it is one of the reasons why it needs the privilege of shutdown).

To ensure it can launch in safe mode, the persistence key value with the path of the malware will start with a ‘*’.

FIGURE 26. Setting the persistance registry key

If the machine starts in the normal way, it will change the desktop wallpaper with an alternative generated in runtime with some text about the ransom note.

FIGURE 27. BlackMatter makes the new wallpaper in runtime

VERSIONS 1.9 AND 2.0

The new versions have some differences compared with versions 1.2 to 1.6:

• Changes in the stub generation code. Previously only one type of stub was used, but in more recent versions several types of stubs are employed, with one chosen randomly per function. Anyways the stubs can be removed without any problem by patching the binary.
• A new byte flag in the configuration that remarks if it needs to print the ransom note using the available printer in the system. Very similar to Ryuk but instead BlackMatter uses APIs from “winspool.drv”.
• Removed one C2 domain that was shut down by the provider.

Additional changes in version 2.0:

• This version changes the crypto algorithm to protect the configuration making it more complex to decrypt it.
• Removed the last C2 that was shut down by the provider.
• Added a new C2 domain.

These changes suggest the developers are active on social media, with an interest in malware and security researchers.

VACCINE

Unlike some ransomware we’ve seen in the past, such as GandCrab , BlackMatter has good code, but it does have some design flaws that can be used in some cases to avoid having the malware encrypt the files.

This vaccine is not intended to be used in the normal way, rather only in special cases as, while it works, other programs can be affected (we obviously cannot test all third party programs but potential issues are likely to include data corruption and unpredictable behavior), and the fix is not permanent.

Steps to make the vaccine (proceed at your own risk):

• Open regedit (or another registry editor) and go to the key in HKEY_LOCAL_MACHINE> Cryptography.
• In this key can be seen a string value named “MachineGuid” with a special value. This value is unique for the machine and is used for some applications to identify the machine. BlackMatter uses it to make the mutex and, very importantly, the new extension for the encrypted files.
• Make a new value of type string with a random name and put the same value as seen in “MachineGuid” to have a backup of it.
• Remove the “MachineGuid” value, and then make it again but with the binary type Instead of string type, with the same name, “MachineGuid”.
• Close the registry editor.

In this moment BlackMatter cannot affect the machine as it needs the registry key to make the ransom extension, and the most important thing is, if it cannot make it, it will return the function WITHOUT decrypting the config that is needed too. In this case it will destroy the recycle bin and shadow volumes anyways but later it will finish as it does not have any behavior to do, RSA Key to protect the files, or anything to send to the C2 as the flag was never read from the config (and the default values are false for all of them).

Though the behavior of other programs may be unpredictable, the vaccine is easy to make, and the system will boot, showing that the BlackMatter programmers made a mistake in the design of the code.

This vaccine works for all versions, including 2.0.

MITRE ATT&CK

The sample uses the following MITRE ATT&CK techniques:

Technique ID	Technique Description	Observable
T1134	Access Token Manipulation	BlackMatter accesses and manipulates different process tokens.
T1486	Data Encrypted for Impact	BlackMatter encrypts files using a custom Salsa20 algorithm and RSA.
T1083	File and Directory Discovery	BlackMatter uses native functions to enumerate files and directories searching for targets to encrypt.
T1222.001	Windows File and Directory Permissions Modification	BlackMatter executes the command icacls “<DriveLetter>:\*” /grant Everyone: F /T /C /Q to grant full access to the drive.
T1562.001	Disable or Modify Tools	BlackMatter stops services related to endpoint security software.
T1106	Native API	BlackMatter uses native API functions in all code.
T1057	Process Discovery	BlackMatter enumerates all processes to try to discover security programs and terminate them.
T1489	Service Stop	BlackMatter stops services.
T1497.001	System Checks	BlackMatter tries to detect debuggers, checking the memory reserved in the heap.
T1135	Network Share Discovery	BlackMatter will attempt to discover network shares by building a UNC path in the following format for each driver letter, from A to Z: \\<IP>\<drive letter>$
T1082	System Information Discovery	BlackMatter uses functions to retrieve information about the target system.
T1592	Gather Victim Host Information	BlackMatter retrieves information about the user and machine.
T1070	Valid Accounts	BlackMatter uses valid accounts to logon to the victim network.
T1547	Boot or Logon Autostart Execution	BlackMatter installs persistence in the registry.
T1102	Query Registry	BlackMatter queries the registry for information.
T1018	Remote System Discovery	BlackMatter enumerates remote machines in the domain.
T1112	Modify Registry	BlackMatter changes registry keys and values and sets new ones.

CONCLUSION

BlackMatter is a new threat in the ransomware field and its developers know full well how to use it to attack their targets. The coding style is remarkably similar to DarkSide and, in our opinion, the people behind it are either the same or have a very close relationship.

BlackMatter shares a lot of ideas, and to some degree code, with DarkSide:

• Configurations are remarkably similar, especially with the last version of Darkside, besides the change in the algorithm to protect it which, despite having less options, remains with the same structure. We do not think that the developers of BlackMatter achieved this similarity by reversing DarkSide as that level of coding skill would have allowed them to create an entirely new ransomware from the ground up. Also, the idea that the DarkSide developers gave or sold the original code to them does not make any sense as it is an old product.
• Dynamic functions are used in a similar way to DarkSide.
• It uses the same compression algorithm for the configuration.
• The victim id is kept in the same way as DarkSide.

It is important to keep your McAfee Enterprise products updated to the latest detections and avoid insecure remote desktop connections, maintain secure passwords that are changed on a regular basis, take precautions against phishing emails, and do not connect unnecessary devices to the enterprise network.

Despite some effective coding, mistakes have been made by the developers, allowing the program to be read, and a vaccine to be created, though we will stress again that it can affect other programs and is not a permanent solution and should be employed only if you accept the risks associated with it.

The post BlackMatter Ransomware Analysis; The Dark Side Returns appeared first on McAfee Blog.

The Bug Report | September 2021: CVE-2021-40444

Why am I here?

There’s a lot of information out there on critical vulnerabilities; this short bug report contains an overview of what we believe to be the most news and noteworthy vulnerabilities. We don’t rely on a single scoring system like CVSS to determine what you need to know about; this is all about qualitative and experience-based analysis, relying on over 100 years of combined industry experience within our team. We look at characteristics such as wormability, ubiquity of the target, likelihood of exploitation and impact. Today, we’ll be focusing on CVE-2021-40444.

CrossView: CVE-2021-40444

What is it?

CVE-2021-40444 is a vulnerability in Office applications which use protected view such as Word, PowerPoint and Excel which allows an attacker to achieve remote code execution (RCE). CVE-2021-40444 is a vulnerability which allows a carefully crafted ActiveX control and a malicious MS Cabinet (.cab) file to be launched from an Office document. 

Most importantly, this vulnerability impacts the applications themselves, as well as the Windows Explorer preview pane.

Who cares?

This is a great question! Pretty much anyone who uses any Microsoft Office applications, or has them installed, should be concerned.

Office is one of the most widely-used applications on the planet. Odds are good you have it open right now. While many companies have disabled macros within Office documents at the Group Policy level, it is unlikely ActiveX is treated similarly. This means that without proper data hygiene, a large proportion of Office users will be vulnerable to this exploit.

Fortunately, “spray and pray” style email campaigns are unlikely to gain traction with this exploit, as mail providers have started flagging malicious files (or at least known PoCs) as potential malware and removing them as attachments.

What can I do?

Good news! You aren’t necessarily completely helpless. By default, Windows uses a flag known as the “Mark of the Web” (MoTW) to enable Protected Mode in Office. Email attachments, web downloads, and similar all have this MoTW flag set, and Protected Mode prevents network operations, ActiveX controls, and macros embedded within a document from being executed, which effectively disables exploitation attempts for this vulnerability.

That said, users have become so inured to the Protected View message, they often dismiss it without considering the consequences. Much like “confirmation fatigue” can lead to installing malicious software, attackers can leverage this common human response to compromise the target machine.

Even more so, while exploitation can occur via the Office applications themselves and via the Explorer preview pane, the Outlook preview pane operates in a completely different manner which does not trigger the exploit. Exactly why this distinction exists only MS can explain, but the upshot is that Outlook users have to explicitly open malicious files to be exploited – the more hoops users have to jump through to open a malicious, the less likely they are to be pwned.

If I’m protected by default, why does this matter?

It depends entirely on how the file gets delivered and where the user saves it.

There are many ways of getting files beyond email and web downloads – flash cards for cameras, thumb drives, external hard drives, etc. Files opened from these sources (and many common applications[1]) don’t have MoTW flag set, meaning that attackers could bypass the protection entirely by sending a malicious file in a .7z archive, or as part of a disk image, or dropping a USB flash drive in your driveway. Convincing users to open such files is no harder than any other social engineering strategy, after all.

Another fun workaround for bypassing default protections is to make use of an RTF file – emailed, downloaded, or otherwise. From our testing, an RTF file saved from an email attachment does not bear the MoTW but can still be used as a vector of exploitation. Whether RTF files become the preferred option for this exploit remains to be seen.

TL;DR

Ha! We put the tl;dr near the end, which only makes sense when the information above is so important it’s worth reading. But if all you care about is what you can actively do to ensure you’re not vulnerable, this section is for you.

Mitigations:

• Apply the Patch! Available via Windows Update as of 9/14/2021, this is your best solution.
• Enable registry workaround to disable ActiveX – details can be found on Microsoft’s bulletin page and should effectively disable exploitation attempts until a formal patch can be applied.
• Confirm that Windows Explorer “Preview” pane is disabled (this is true by default). This only protects against the Preview pane exploitation in Explorer. Opening the file outside of Protected Mode (such as an RTF file) or explicitly disabling Protected Mode will still allow for exploitation.

The Gold Standard

In case you simply can’t apply the patch or have a “production patch cycle” or whatever, McAfee Enterprise has you covered. Per our KB we provide comprehensive coverage for this attack across our protection and detection technology stack of endpoint (ENS Expert Rules), network (NSP) and EDR.

https://kc.mcafee.com/corporate/index?page=content&id=KB94876

[1] 7zip, files from disk images or other container formats, FAT formatted volumes, etc.

The post The Bug Report | September 2021: CVE-2021-40444 appeared first on McAfee Blog.

Operation ‘Harvest’: A Deep Dive into a Long-term Campaign

A special thanks to our Professional Services’ IR team, ShadowServer, for historical context on C2 domains, and Thomas Roccia/Leandro Velasco for malware analysis support.

Executive Summary

Following a recent Incident Response, McAfee Enterprise‘s Advanced Threat Research (ATR) team worked with its Professional Services IR team to support a case that initially started as a malware incident but ultimately turned out to be a long-term cyber-attack.

From a cyber-intelligence perspective, one of the biggest challenges is having information on the tactics, techniques, and procedures (TTPs) an adversary is using and then keeping them up to date. Within ATR we typically monitor many adversaries for years and collect and store data, ranging from indicators of compromise (IOCs) to the TTPs.

In this report, ATR provides a deep insight into this long-term campaign where we will map out our findings against the Enterprise MITRE ATT&CK model. There will be parts that are censored since we respect the confidentiality of the victim. We will also zoom in and look at how the translation to the MITRE Techniques, historical context, and evidence artifacts like PlugX and Winnti malware led to a link with another campaign, which we highly trust to be executed by the same adversary.

IOCs that could be shared are at the end of this document.

McAfee customers are protected from the malware/tools described in this blog. MVISION Insights customers will have the full details, IOCs and TTPs shared via their dashboard. MVISION Endpoint, EDR and UCE platforms provide signature and behavior-based prevention and detection capability for many of the techniques used  in this attack. A more detailed blog with specific recommendations on using the McAfee portfolio and integrated partner solutions to defend against this attack can be found here.

Technical Analysis

Initial Infection Vectors [TA0001]

Forensic investigations identified that the actor established initial access by compromising the victim’s web server [T1190]. On the webserver, software was installed to maintain the presence and storage of tools [T1105] that would be used to gather information about the victim’s network [T1083] and lateral movement/execution of files [T1570] [T1569.002]. Examples of the tools discovered are PSexec, Procdump, and Mimikatz.

Privilege Escalation and Persistence [TA0004, TA0003]

The adversary has been observed using multiple privilege escalation and persistence techniques during the period of investigation and presence in the network. We will highlight a few in each category.

Besides the use of Mimikatz to dump credentials, the adversaries used two tools for privilege escalations [T1068]. One of the tools was “RottenPotato”. This is an open-source tool that is used to get a handle to a privileged token, for example, “NT AUTHORITY\SYSTEM”, to be able to execute tasks with System rights.

Example of RottenPotato on elevating these rights:

Figure 1 RottenPotato

The second tool discovered, “BadPotato”, is another open-source tool that can be used to elevate user rights towards System rights.

Figure 2 BadPotato

The BadPotato code can be found on GitHub where it is offered as a Visual Studio project. We inspected the adversary’s compiled version using DotPeek and hunted for artifacts in the code. Inspecting the File (COFF) header, we observed the file’s compilation timestamp:

TimeDateStamp: 05/12/2020 08:23:47  – Date and time the image was created

PlugX

Another major and characteristic privilege escalation technique the adversary used in this long-term campaign was the malware PlugX as a backdoor. PlugX makes use of the technique “DLL Sideloading” [T1574.002]. PlugX was observed as usual where a single (RAR) executable contained the three parts:

• Valid executable.
• Associated DLL with the hook towards the payload.
• Payload file with the config to communicate with Command & Control Server (C2).

The adversary used either the standalone version or distributed three files on different assets in the network to gain remote control of those assets. The samples discovered and analyzed were communicating towards two domains. Both domains were registered during the time of the campaign.

One of the PlugX samples consisted of the following three parts:

Filename	Hashes
HPCustPartic.exe	SHA256: 8857232077b4b0f0e4a2c3bb5717fd65079209784f41694f8e1b469e34754cf6
HPCustPartUI.dll	SHA256: 0ee5b19ea38bb52d8ba4c7f05fa1ddf95a4f9c2c93b05aa887c5854653248560
HPCustPartic.bin	SHA256: 008f7b98c2453507c45dacd4a7a7c1b372b5fafc9945db214c622c8d21d29775

The .exe file is a valid and signed executable and, in this case, an executable from HP (HP Customer participation). We also observed other valid executables being used, ranging from AV vendors to video software. When the executable is run, the DLL next to it is loaded. The DLL is valid but contains a small hook towards the payload which, in our case, is the .bin file. The DLL loads the PlugX config and injects it into a process.

We executed the samples in a test setup and dumped the memory of the machine to conduct memory analysis with volatility. After the basic forensically sound steps, we ran the malfind plugin to detect possible injected code in a process. From the redacted output of the plugin, we observed the following values for the process with possible injected code:

Process: svchost.exe Pid: 860 Address: 0xb50000

Process: explorer.exe Pid: 2752 Address: 0x56a000

Process: svchost.exe Pid: 1176 Address: 0x80000

Process: svchost.exe Pid: 1176 Address: 0x190000

Process: rundll32.exe Pid: 3784 Address: 0xd0000

Process: rundll32.exe Pid: 3784 Address: 0x220000

One observation is the mention of the SVCHOST process with a ProcessID value of 1176 that is mentioned twice but with different addresses. This is similar to the RUNDLL32.exe that is mentioned twice with PID 3785 and different addresses. One way to identify what malware may have been used is to dump these processes with the relevant PID using the procdump module, upload them to an online analysis service and wait for the results. Since this is a very sensitive case, we took a different approach. Using the best of both worlds (volatility and Yara) we used a ruleset that consists of malware patterns observed in memory over time. Running this ruleset over the data in the memory dump revealed the following (redacted for the sake of readability) output:

Figure 3 Output Yarascan memory dump

The output of the Yara rule scan (and there was way more output) confirmed the presence of PlugX module code in PID 1176 of the SVCHOST service. Also, the rule was triggered on PID 3784, which belonged to RUNDLL32.exe.

Investigating the dumps after dynamic analysis, we observed two domain names used for C2 traffic:

• sery.brushupdata.com
• dnssery.brushupdata.com

In particular, we saw the following hardcoded value that might be another payload being downloaded:

sery.brushupdata.com/CE1BC21B4340FEC2B8663B69

The PlugX families we observed used DNS [T1071.001] [T1071.004] as the transport channel for C2 traffic, in particular TXT queries. Investigating the traffic from our samples, we observed the check-in-signature (“20 2A 2F 2A 0D”) that is typical for PlugX network traffic:

00000000:            47 45 54 20 2F 42 34 42 42 44 43 43 30 32 39 45

00000010:            31 31 39 37 31 39 46 30 36 35 36 32 32 20 48 54

00000020:            54 50 2F 31 2E 31 0D 0A 41 63 63 65 70 74 3A 20

00000030:            2A 2F 2A 0D 0A 43 6F 6F 6B 69 65 3A 20 44 36 43

00000040:            57 50 2B 56 5A 47 6D 59 6B 6D 64 6D 64 64 58 55

00000050:            71 58 4D 31 71 31 6A 41 3D 0D 0A 55 73 65 72 2D

During our analysis of the different PlugX samples discovered, the domain names as mentioned above stayed the same, though the payload values were different. For example:

• hxxp://sery.brushupdata.com/B4BBDCC029E119719F065622
• hxxp://sery.brushupdata.com/07FDB1B97D22EE6AF2482B1B
• hxxp://sery.brushupdata.com/273CDC0B9C6218BC1187556D

Other PlugX samples we observed injected themselves into Windows Media Player and started a connection with the following two domains:

• center.asmlbigip.com
• sec.asmlbigip.com

Hello Winnti

Another mechanism observed was to start a program as a service [T1543.003] on the Operating System with the acquired System rights by using the *Potato tools. The file the adversary was using seemed to be a backdoor that was using the DLL file format (2458562ca2f6fabddae8385cb817c172).

The DLL is used to create a malicious service and its name is “service.dll”. The name of the created service, “SysmainUpdate”, is usurping the name of the legitimate service “SysMain” which is related to the legitimate DLL sysmain.dll and also to the Superfetch service. The dll is run using the command “rundll32.exe SuperFrtch.dll, #1”. The export function has the name “WwanSvcMain”.

The model uses the persistence technique utilizing svchost.exe with service.dll to install a rogue service. It appears that the dll employs several mechanisms to fingerprint the targeted system and avoid analysis in the sandbox, making analysis more difficult. The DLL embeds several obfuscated strings decoded when running. Once the fingerprinting has been done, the malware will install the malicious service using the API RegisterServiceHandlerA then SetServiceStatus, and finally CreateEventA. A description of the technique can be found here.

The malware also decrypts and injects the payload in memory. The following screenshot shows the decryption routine.

Figure 4 Decryption routine

When we analyzed this unique routine, we discovered similarities and the mention of it in a publication that can be read here. The malware described in the article is attributed to the Winnti malware family. The operating method and the code used in the DLL described in the article are very similar to our analysis and observations.

The process dump also revealed further indicators. Firstly, it revealed artifacts related to the DLL analyzed, “C:\ProgramData\Microsoft\Windows\SuperfRtch\SuperfRtch.dat”. We believe that this dat file might be the loaded payload.

Secondly, while investigating the process dump, we observed activities from the backdoor that are part of the data exfiltration attempts which we will describe in more detail in this analysis report.

A redacted snippet of the code would look like this:

Creating archive ***.rar

Adding   [data from location]

  0%

  OK

Another indicator of discovering Winnti malware was the following execution path we discovered in the command line dump of the memory:

cmd /c klcsngtgui.exe 1560413F7E <abbreviation-victim>.dat

What we observed here was the use of a valid executable, the AES 256 decryption key of the payload (.dat file). In this case, the payload file was named using an abbreviation of the victim company’s name. Unfortunately, the adversary had removed the payload file from the system. File carving did not work since the disk/unallocated space was overwritten. However, reconstructing traces from memory revealed that we were dealing with the Winnti 4.0 malware. The malware was injected into a SVCHOST process where a driver location pointed to the config file. We observed in the process dump the exfiltration of data on the system, such as OS, Processor (architecture), Domain, Username, etc.

Another clue that helped us was the use of DNS tunneling by Winnti which we discovered traces of in memory. The hardcoded 208.67.222.222 resolves to a legitimate OpenDNS DNS server. The IP is pushed into the list generated by the malware at runtime. At the start of the malware, it populates the list with the system’s DNS, and the OpenDNS server is only used as a backup to ensure that the C2 domain is resolved.

Another indicator in the process dump was the setup of the C2 connection including the User-Agent that has been observed being used by Winnti 4.0 malware:

Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36

Other Persistence Activities

WMI activity [T1546.003] was also observed to execute commands on the systems.

From a persistence point of view, scheduled tasks [T1053.005] and the use of valid accounts [T1078] acquired through the use of Mimikatz, or creating LSASS dumps, were observed being employed during the length of the campaign.

Lateral Movement

From a lateral movement perspective, the adversary used the obtained credentials to hop from asset to asset. In one particular case, we observed a familiar filename: “PsExec.exe”. This SysInternals tool is often observed being used in lateral movement by adversaries, however, it can also be used by the sysadmins of the network. In our case, the PsExec executable had a file size of 9.6 MB where the original PsExec (depending on 32- or 64-bit version) had a maximum file size of 1.3 MB. An initial static inspection of the file resulted in a blob of code that was present in the executable which had a very high entropy score (7.99). When running the file from the command line, the following output was observed:

Figure 5 PsExec output

The error notification and the ‘Impacket’ keyword tipped us off and, after digging around, we found more. The fake PsExec is an open-source Python script that is a PsExec alternative with shell/backdoor capability. It uses a script from this location: hxxps://github.com/SecureAuthCorp/impacket/blob/master/examples/psexec.pyi. The file is large since it incorporates a low-level protocol interaction from Impacket. The Python library combined with the script code is compiled with py2exe. The file was compiled during the time of the latest attack activities and signed with an expired certificate.

Data Exfiltration

From what we observed, the adversary had a long-term intention to stay present in the victim’s network. With high confidence, we believe that the adversary was interested in stealing proprietary intelligence that could be used for military or intellectual property/manufacturing purposes.

The adversary used several techniques to exfiltrate the data. In some cases, batch (.bat) scripts were created to gather information from certain network shares/folders and use the ‘rar’ tool to compress them to a certain size [T1020] [T1030]. Example of content in a batch script:

C:\Windows\web\rar.exe a -[redacted] -r -v50000 [Target-directory]

On other occasions, manual variants of the above command were discovered after using the custom backdoor as described earlier.

When the data was gathered on a local system using the backdoor, the files were exfiltrated over the backdoor and the rar files were deleted [T1070.004]. Where external facing assets were used, like a web server, the data was stored in a location in the Internet Information Services (IIS) web server and exfiltrated over HTTP using GET requests towards the exact file paths [T1041] [T1567] [T1071].

An example of the [redacted] web traffic in the IIS logfiles:

Date /Time		Request	TCP Src port	Source IP	User-Agent
Redacted	GET /****/[redacted].rar		80	180.50.*.*	MINIXL
redacted	GET /****/[redacted].rar		80	209.58.*.*	MINIXL

The source IP addresses discovered belonged to two different ISP/VPN providers based in Hong-Kong.

The User-Agent value is an interesting one, “MINIXL”. When we researched that value, we discovered a blog from Dell SecureWorks from 2015 that mentions the same User-Agent, but also a lot of the artifacts mentioned from the blog overlapped with the observations and TTPs of Operation Harvest [link].

What we could retrieve from open-source databases is that the use of this particular User-Agent is very limited and seems to originate from the APAC region.

Who did it?

That seems to be the one-million-dollar question to be asked. Within McAfee, attribution is not our main focus, protecting our customers is our priority. What we do care about is that if we learn about these techniques during an investigation, can we map them out and support our IR team on the ground, or a customer’s IR team, with the knowledge that can help determine which phase of the attack the evidence is pointing to and based on historical data and intelligence, assist in blocking the next phase and discover more evidence?

We started by mapping out all MITRE ATT&CK Enterprise techniques and sub-techniques, added the tools used, and did a comparison against historical technique data from the industry. We ended up with four groups that shared techniques and sub-techniques. The Winnti group was added by us since we discovered the unique encryption function in the custom backdoor and indicators of the use of the Winnti malware.

Figure 6 ATT&CK technique comparison

The diagram reflecting our outcome insinuated that APT27 and APT41 are the most likely candidates that overlap with the (sub-)techniques we observed.

Since all these groups are in a certain time zone, we extracted all timestamps from the forensic investigation with regards to:

• Registration of domain
• Compile timestamps of malware (considering deception)
• Timestamps of command-line activity
• Timestamps of data exfiltration
• Timestamps of malware interaction such as creation, deletion, etc.

When we converted all these timestamps from UTC to the aforementioned groups’ time zones, we ended up with the below scheme on activity:

Figure 7 Adversary’s time of operation

In this campaign, we observed how the adversary mostly seems to work from Monday to Thursday and typically during office hours, albeit with the occasional exception.

Correlating ATT&CK (sub-)techniques, timestamps, and tools like PlugX and Mimikatz are not the only evidence indicators that can help to identify a possible adversary. Command-line syntax, specific code similarity, actor capability over time versus other groups, and unique identifiers are at the top of the ‘pyramid of pain’ in threat intelligence. The bottom part of the pyramid is about hashes, URLs, and domains, areas that are very volatile and easy to change by an adversary.

Figure 8 Pyramid of Pain

Beyond investigating those artifacts, we also took possible geopolitical interests and potential deception into consideration when building our hypothesis. When we mapped out all of these, we believed that one of the two previously mentioned groups were responsible for the campaign we investigated.

Our focus was not about attribution though, but more around where the flow of the attack is, matches against previous attack flows from groups, and what techniques/tools they are using to block next steps, or where to locate them. The more details we can gather at the top of ‘the pyramid of pain’, the better we can determine the likely adversary and its TTP’s.

That’s all Folks!

Well, not really. While correlating the observed (sub-)techniques, the malware families and code, we discovered another targeted attack against a similar target in the same nation with the major motivation of gathering intelligence. In the following diagram we conducted a high-level comparison of the tools being used by the adversary:

Figure 9 Tools comparison

Although some of the tools are unique to each campaign, if taken into consideration over time with when they were used, it makes sense. It demonstrates the development of the actor and use of newer tools to conduct lateral movement and to obtain the required level of user rights on systems.

Overall, we observed the same modus operandi. Once an initial foothold was established, the adversary would deploy PlugX initially to create a few backdoors in the victim’s network in case they were discovered early on. After that, using Mimikatz and dumping lsass, they were looking to get valid accounts. Once valid accounts were acquired, several tools including some of their own tools were used to gain information about the victim’s network. From there, several shares/servers were accessed, and information gathered. That information was exfiltrated as rar files and placed on an internet-facing server to hide in the ‘normal’ traffic. We represent that in the following graphic:

Figure 10 Attack flow

In the 2019/2020 case we also observed the use of a malware sample that we would classify as part of the Winnti malware family. We discovered a couple of files that were executed by the following command:

Start Ins64.exe E370AA8DA0 Jumper64.dat

The Winnti loader ‘Ins64.exe’ uses the value ‘E370AA8DA0’ to decrypt the payload from the .dat file using the AES-256-CTR decryption algorithm and starts to execute.

After executing this command and analyzing the memory, we observed a process injection in one of the svchost processes whereby one particular file was loaded from the following path:

C:\programdata\microsoft\windows\caches\ieupdate.dll

Figure 11 Memory capture

The malware started to open up both UDP and TCP ports to connect with a C2 server.

UDP Port 20502

TCP Port  20501

Figure 12 Network connections to C2

Capturing the traffic from the malware we observed the following as an example:

Figure 13 Winnti HTTP traffic to C2

The packet data was customized and sent through a POST request with several headers towards the C2. In the above screenshot the numbers after “POST /” were randomly generated.

The User-Agent is a good network indicator to identify the Winnti malware since it is used in multiple variants:

Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.94 Safari/537.36

Indeed, the same User Agent value was discovered in the Winnti sample in Operation Harvest and seems to be typical for this malware family.

The cookie value consists of four Dword hex values that contain information about the customized packet size using a XOR value.

We learned more about the packet structure of Winnti from this link.

Applying what we learned about the handshake, we observed the following in our traffic sample:

Dword value 0 = 52 54 00 36

Dword value 1 = 3e ff 06 b2

Dword value 2 = 99 6d 78 fe

Dword value 3 = 08 00 45 00

Dword value 4 = 00 34 00 47

Initial handshake order:

Based on our cross-correlation with samples and other OSINT resources, we believe with a high confidence that this was a Winnti 4.0 sample that connects with a confirmed Winnti C2 server.

The identified C2 server was 185.161.211.97 TCP/80.

Timeline of Events

When analyzing the timestamps from this investigation, like we did for operation Harvest, we came to the below overview:

Figure 14 Beijing working hours case 2019/2020

Again, we observed that the adversary was operating Monday to Friday during office hours in the Beijing time-zone.

Conclusion

Operation Harvest has been a long-term operation whereby an adversary maintained access for multiple years to exfiltrate data. The exfiltrated data would have either been part of an intellectual property theft for economic purposes and/or would have provided insights that would be beneficial in case of military interventions. The adversaries made use of techniques very often observed in this kind of attack but also used distinctive new backdoors or variants of existing malware families. Combining all forensic artifacts and cross-correlation with historical and geopolitical data, we have high confidence that this operation was executed by an experienced APT actor.

After mapping out all data, TTP’s etc., we discovered a very strong overlap with a campaign observed in 2019/2020. A lot of the (in-depth) technical indicators and techniques match. Also putting it into perspective, and over time, it demonstrates the adversary is adapting skills and evolving the tools and techniques being used.

On a separate note, we observed the use of the Winnti malware. We deliberately mention the term ‘malware’ instead of group. The Winnti malware is known to be used by several actors. Within every nation-state cyber-offensive activity, there will be a department/unit responsible for the creation of the tools/malware, etc. We strongly believe that is exactly what we observe here as well. PlugX, Winnti and some other custom tools all point to a group that had access to the same tools. Whether we put name ‘X’ or ‘Y’ on the adversary, we strongly believe that we are dealing with a Chinese actor whose long-term objectives are persistence in their victims’ networks and the acquisition of the intelligence needed to make political/strategic or manufacturing decisions.

 

MITRE ATT&CK Techniques

Technique ID	Technique Title	Context Campaign
T1190	Exploit Public-facing application	Adversary exploited a web-facing server with application
T1105	Ingress Tool transfer	Tools were transferred to a compromised web-facing server
T1083	File & Directory Discovery	Adversary browsed several locations to search for the data they were after.
T1570	Lateral Tool Transfer	Adversary transferred tools/backdoors to maintain persistence
T1569.002	System Services: Service Execution	Adversary installed custom backdoor as a service
T1068	The exploitation of Privilege Escalation	Adversary used Rotten/Bad Potato to elevate user rights by abusing API calls in the Operating System.
T1574.002	Hijack Execution Flow: DLL Side-Loading	Adversary used PlugX malware that is famous for DLL-Side-Loading using a valid executable, a DLL with the hook towards a payload file.
T1543.003	Create or Modify System Process: Windows Service	Adversary launched backdoor and some tools as a Windows Service including adding of registry keys
T1546.003	Event-Triggered Execution: WMI Event Subscription	WMI was used for running commands on remote systems
T1053.005	Scheduled task	Adversary ran scheduled tasks for persistence of certain malware samples
T1078	Valid accounts	Using Mimikatz and dumping of lsass, the adversary gained credentials in the network
T1020	Automated exfiltration	The PlugX malware exfiltrated data towards a C2 and received commands to gather more information about the victim’s compromised host.
T1030	Data transfer size limits	Adversary limited the size of rar files for exfiltration
T1070.004	Indicator removal on host	Where in the beginning of the campaign the adversary was sloppy, during the last months of activity they became more careful and started to remove evidence
T1041	Exfiltration over C2 channel	Adversary used several C2 domains to interact with compromised hosts.
T1567	Exfiltration over Web Service	Gathered information was stored as ‘rar’ files on the internet-facing server, whereafter they were downloaded by a specific ip range.
T1071.004	Application layer protocol: DNS	Using DNS tunneling for the C2 traffic of the PlugX malware

 

Indicators of Compromise (IOCs)

Note: the indicators shared are to be used in a historical and timeline-based context, ranging from 2016 to March 2021.

Operation Harvest:

PlugX C2:

sery(.)brushupdata(.)com

Dnssery(.)brushupdata(.)com

Center(.)asmlbigip(.)com

 

Tools:

Mimikatz

PsExec

RottenPotato

BadPotato

 

Operation 2019/2020

PlugX malware:

f50de0fae860a5fd780d953a8af07450661458646293bfd0fed81a1ff9eb4498

26e448fe1105b5dadae9b7607e3cca366c6ba8eccf5b6efe67b87c312651db01

e9033a5db456af922a82e1d44afc3e8e4a5732efde3e9461c1d8f7629aa55caf

3124fcb79da0bdf9d0d1995e37b06f7929d83c1c4b60e38c104743be71170efe

 

Winnti:

800238bc27ca94279c7562f1f70241ef3a37937c15d051894472e97852ebe9f4

c3c8f6befa32edd09de3018a7be7f0b7144702cb7c626f9d8d8d9a77e201d104

df951bf75770b0f597f0296a644d96fbe9a3a8c556f4d2a2479a7bad39e7ad5f

 

Winnti C2: 185.161.211.97

 

Tools:

PSW64                  6e983477f72c8575f8f3ff5731b74e20877b3971fa2d47683aff11cfd71b48c6

NTDSDumpEx  6db8336794a351888636cb26ebefb52aeaa4b7f90dbb3e6440c2a28e4f13ef96

NBTSCAN             c9d5dc956841e000bfd8762e2f0b48b66c79b79500e894b4efa7fb9ba17e4e9e

NetSess                ddeeedc8ab9ab3b90c2e36340d4674fda3b458c0afd7514735b2857f26b14c6d

Smbexec              e781ce2d795c5dd6b0a5b849a414f5bd05bb99785f2ebf36edb70399205817ee

Wmiexec              14f0c4ce32821a7d25ea5e016ea26067d6615e3336c3baa854ea37a290a462a8

Mimikatz

RAR command-line

TCPdump

The post Operation ‘Harvest’: A Deep Dive into a Long-term Campaign appeared first on McAfee Blog.

McAfee Enterprise Defender’s Blog: Operation Harvest

Summary

McAfee Enterprise’s Advanced Threat Research (ATR) team provided deep insight into a long-term campaign Operation Harvest. In the blog, they detail the MITRE Tactics and Techniques the actors used in the attack. In this blog, our Pre-Sales network defenders describe how you can defend against a campaign like Operation Harvest with McAfee Enterprise’s MVISION Security Platform and security architecture best practices.

Defending Against Operation Harvest with McAfee

Operation Harvest, like other targeted attack campaigns, leverages multiple techniques to access the network and capture credentials before exfiltrating data. Therefore, as a Network Defender you have multiple opportunities to prevent, disrupt, or detect the malicious activity. Early prevention, identification and response to potentially malicious activity is critical for business resilience. Below is an overview of how you can defend against attacks like Operation Harvest with McAfee’s MVISION Security Architecture.

Throughout this blog, we will provide some examples of where MVISION Security Platform could help defend against this type of attack.

Get Prepared with the Latest Threat Intelligence

As Network Defenders our goal is to prevent, detect and contain the threat as early as possible in the attack chain. That starts with using threat intelligence, from blogs or solutions like MVISION Insights to get prepared and using tools like MITRE Attack Navigator to assess your defensive coverage. The ATR blog details the techniques, indicators and tools used by the attackers. Many of the tools used in Operation Harvest are common across other threat actors and detection details for PlugX, and Winnti are already documented in MVISION INSIGHTS.

Get a quick overview of the PlugX tool:

Easily search for or export PlugX IOCs right from MVISION Insights:

Get a quick overview of the Winnti tool:

Easily search for or export Winnti IOCs right from MVISION Insights:

Cross Platform Hunting Rules for Winnti:

MVISION Insights is also updated with the latest technical intelligence on Operation Harvest including a summary of the threat, prevalence, indicators of compromise and recommended defensive countermeasures.

Defending Against Initial Access

In this attack, the initial access involved a compromised web server. Over the last year we have seen attackers increasingly use initial access vectors beyond spear-phishing, such as compromising remote access systems or supply chains. The exploiting of public-facing vulnerabilities for Initial Access is a technique associated with Operation Harvest and other APT groups to gain entry. Detecting this activity and stopping it is critical to limiting the abilities of the threat actor to further their execution strategy. Along with detecting the ongoing activity, it is also imperative to verify critical vulnerabilities are patched and configurations are security best practice to prevent exploitation. MVISION UCE provides visibility into threats, vulnerabilities, and configuration audits mapped to the MITRE ATT&CK Framework for protection against suspicious activity.

Many customer-facing applications and web servers are hosted on cloud infrastructure. As a Network Defender, gaining visibility and monitoring for misconfigurations on the infrastructure platforms is critical as this is increasingly the entry point for an attacker. MVISION Cloud Native Application Protection Platform (CNAPP) provides a continuous assessment capability for multiple cloud platforms in a single console so you can quickly correct misconfigurations and harden the security posture across AWS, AZURE or Google Cloud Platforms.

Harden the Server or Endpoint Against Malicious Tool use

The attackers uploaded several known or potentially malicious tools to compromised systems. Many of these tools were detected on installation or execution by ENS Threat Prevention or Adaptative Threat Prevention Module. The following is a sample of the Threat Event log from ePolicy Orchestrator (ePO) from our testing.

You can easily search for these events in ePO and investigate any systems with detections.

For best protection turn on Global Threat Intelligence (GTI) for both Threat Prevention and Adaptive Threat Protection modules. Ensure ATP Rules 4 (GTI File Reputation) and 5 (URL Reputation) are enabled in ATP. Global Threat Intelligence is updated with the latest indicators for this attack as well.

Additionally, based on other observables in this attack, we believe there are several other Adaptive Threat Prevention Rules that could prevent or identify potentially malicious activity on the endpoint or server. Monitor especially for these ATP events in the ePO threat event logs:

Rule 269: Detects potentially malicious usage of WMI service to achieve persistence

Rule 329: Identify suspicious use of Scheduled Tasks

Rule 336: Detect suspicious payloads targeting network-related services or applications via dual use tools

Rule 500: Block lateral movement using utilities such as Psexec from an infected client to other machines in the network

Rule 511: Detect attempts to dump sensitive information related to credentials via lsaas

Analysis will continue and additional ATP rules we think relate will be added to mitigation guidance in MVISION Insights.

ENS with Expert Rules

Expert Rules are a powerful, customizable signature language within ENS Threat Prevention Module. For this attack, you could use Expert Rules to identify potential misuse of Psexec or prevent execution or creation of certain file types used such as .rar files.

Additional guidance on creating your own Expert Rules and link to our repository are here:

How to Use Expert Rules in ENS to Prevent Malicious Exploits

ATR Expert Rule Repository

Per standard practice, we recommend that customers test this rule in report mode before applying in block mode.

Preventing or Detecting Command and Control

Like other attacks exploiting critical vulnerabilities, attackers may gain command and control over exploited systems to deliver payloads or other actions. MVISION EDR can both identify many command-and-control techniques such as Cobalt Strike beacons. In this case, MVISION EDR would have logged the DNS and HTTP connection requests to the suspicious domains and an SOC analysts could use Real Time and Historical search to hunt proactively for compromised machines.

Additionally, Unified Cloud Edge (UCE – SWG) can prevent access to risky web sites using threat intelligence, URL reputation, behaviour analysis and remote browser isolation. Ensure you have a strong web security policy in place and are monitoring logs. This is a great control to identify potentially malicious C2 activity.

Monitoring for Privilege Escalation

The adversary used several techniques and tools to elevate privileges and run Mimikatz to steal credentials. In our simulation, MVISION EDR proactively identified the attempt to download and execute in memory a Mimikatz PowerShell script.

We simulated the attacker malicious attempt using potato tools reproducing a generic privilege escalation. From the EDR monitoring process tree we could observe the sequence of events with a change in terms of user name from a user account to SYSTEM.”

We started a guided investigation on the affected system. Analytics on the data identified anomalies in user behavior. Guided investigations make easier to visualize complex data sets and interconnections between artifacts and systems.

Identifying Commonly used Tools for Lateral Movement

The attackers used a common dual use system utility, in this case Psexec.exe, to move laterally. In many cases, the malicious use of legitimate system tools is difficult to detect with signature-based detection only. MVISION EDR uses a combination of behaviour analytics and threat intelligence to proactively identify and flag a high severity alert on malicious use of Psexec for lateral movement.

Psexec.exe used for lateral movement:

Mapping User and Data Anomalies to Detect Exfiltration

The threat actors behind Operation Harvest utilized various tools to elevate privileges and exfiltrate data out of the impacted environment. Visualizing anomalies in user activity and data movement can be used to detect out of the ordinary behavior that can point to malicious activity going on in your environment. MVISION UCE will monitor user behavior and provide anomalies for the security team to pinpoint areas of concern for insider or external adversarial threats.

Identifying User Access Anomalies with UCE:

Identifying Data Transfer Anomalies with UCE:

Summary

MVISION Security Platform provides defense in depth to prevent, disrupt or detect many of the techniques used in Operation Harvest. As a network defender, focus on early prevention or detection of the techniques to better protect your organization against cyber-attacks.

The post McAfee Enterprise Defender’s Blog: Operation Harvest appeared first on McAfee Blog.

How Groove Gang is Shaking up the Ransomware-as-a-Service Market to Empower Affiliates

Co-authored with Intel471 and McAfee Enterprise Advanced Threat Research (ATR) would also like to thank Coveware for its contribution.

Executive Summary

McAfee Enterprise ATR believes, with high confidence, that the Groove gang is associated with the Babuk gang, either as a former affiliate or subgroup. These cybercriminals are happy to put aside previous Ransomware-as-a-Service hierarchies to focus on the ill-gotten gains to be made from controlling victim’s networks, rather than the previous approach which prioritized control of the ransomware itself.

Introduction

For many years the world of Ransomware-as-a-Service (RaaS) was perceived as a somewhat hierarchical and structured organization. Ransomware developers would advertise their RaaS program on forums and gracefully open up slots for affiliates to join their team to commit crime. The RaaS admins would conduct interviews with potential affiliates to make sure they were skilled enough to participate. Historically, i.e., with CTB locker, the emphasis was on affiliates generating enough installs via a botnet, exploit kits or stolen credentials, but it has shifted in recent years to being able to penetrate and compromise a complete network using a variety of malicious and non-malicious tools. This essentially changed the typical affiliate profile towards a highly-skilled pen-tester/sysadmin.

Figure 1. Recruitment posting for CTB locker from 2014

Figure 2. Recruitment posting for REvil from 2020

Experts often describe the hierarchy of a conventional organized crime group as a pyramid structure. Historically, La Cosa Nostra, drug cartels and outlaw motor gangs were organized in such a fashion. However, due to further professionalization and specialization of the logistics involved with committing crime, groups have evolved into more opportunistic network-based groups that will work together more fluidly, according to their current needs.

While criminals collaborating in the world of cybercrime isn’t a novel concept, a RaaS group’s hierarchy is more rigid compared to other forms of cybercrime, due to the power imbalance between the group’s developers/admins and affiliates.

For a long time, RaaS admins and developers were prioritized as the top targets, often neglecting the affiliates since they were perceived as less-skilled. This, combined with the lack of disruptions in the RaaS ecosystem, created an atmosphere where those lesser-skilled affiliates could thrive and grow into very competent cybercriminals.

However, this growth isn’t without consequences. Recently we have observed certain events that might be the beginning of a new chapter in the RaaS ecosystem.

Cracks in the RaaS model

Trust in the cybercriminal underground is based on a few things, such as keeping your word and paying people what they deserve. Just like with legitimate jobs, when employees feel their contributions aren’t adequately rewarded, those people start causing friction within the organization. Ransomware has been generating billions of dollars in recent years and with revenue like that, it’s only a matter of time before some individuals who believe they aren’t getting their fair share become unhappy.

Recently, a former Conti affiliate was unhappy with their financial portion and decided to disclose the complete Conti attack playbook and their Cobalt Strike infrastructure online, as shown in the screenshot below.

Figure 3. Disgruntled Conti affiliate

In the past, ATR has been approached by individuals affiliated with certain RaaS groups expressing grudges with other RaaS members and admins, claiming they haven’t been paid in time or that their share wasn’t proportionate to the amount of work they put in.

Recently, security researcher Fabian Wosar opened a dedicated Jabber account for disgruntled cybercriminals to reach out anonymously and he stated that there was a high level of response.

Figure 4. Jabber group for unhappy threat actors

Moreover, the popular cybercrime forums have banned ransomware actors from advertising since the Colonial Pipeline attack. Now, the groups no longer have a platform on which to actively recruit, show their seniority, offer escrow, have their binaries tested by moderators, or settle disputes. The lack of visibility has made it harder for RaaS groups to establish or maintain credibility and will make it harder for RaaS developers to maintain their current top tier position in the underground.

Paying respects…. RAMP Forum and Orange

After a turbulent shutdown of Babuk and the fallout from the Colonial Pipeline and Kaseya attacks, it seems that some of the ransomware-affiliated cybercriminals have found a home in a forum known as RAMP.

Figure 5. RAMP posting by Orange, introducing Groove and explaining relationships

Translated Posting

When analyzing RAMP and looking at the posting above from the main admin Orange, it’s hard to ignore numerous references that are made: From the names chosen, to the avatar of Orange’s profile, which happens to be a picture of a legitimate cyber threat intelligence professional.

Orange

Hello, friends! I am happy to announce the first contest on Ramp.

Let’s make it clear that we don’t do anything without a reason, so at the end of the day, it’s us who will benefit most from this contest

Here’s the thing: besides my new projects and old, I have always had this unit called

GROOVE — I’ve never revealed its name before and it’s never been mentioned directly in the media, but it does exist — we’re like Mossad (we are few and aren’t hiring). It’s Groove whom the babuk ransomware needs to thank for its fame.

Groove rocks, and babuk stinks

Challenge: Using a PHP stack+MYSQL+Bootstrap, code a standard ransomware operators’ blog in THE RUSSIAN LANGUAGE with the following pages:

1) About us

The description of a group, which must be editable from the admin panel and use the same visual editor as our forum.

2) Leaks.

No hidden blogs, just leaks.

Use standard display, just like other ransomware operators’ blogs do.

3) News

A news page; it must be possible to add and edit news via the admin panel.

We’ll be accepting your submissions up to and including August 30.

Who will rate the entries and how?

There will be only one winner. I, Orange, will rate the usability and design of blogs. MRT will rate each entry’s source code and its security. In addition to USD 1k, the winner will most likely get a job in the RAMP team!

Now, for those of you who are interested in entirely different things:

1) No, we are not with the Kazakh intelligence agency.

https://www.fr.sogeti.com/globalassets/france/avis-dexperts–livres-blancs/cybersecchronicles_-_babuk.pdf

2) Groove has never had a ransomware product, nor will that ever change.

3) The babuk team doesn’t exist. We rented the ransomware from a coder who could not shoulder the responsibility, got too scared and decided to leave an error in the ESX builder — naturally, to give us a reason to chuck him out (his motives? Fxxx if I know)

babuk 2.0, which hit the headlines, is not to be taken seriously and must be regarded as nothing but a very stupid joke

4) GROOVE is first and foremost an aggressive financially motivated criminal organization dealing in industrial espionage for about two years. RANSOMWARE is no more than an additional source of income. We don’t care who we work with and how. You’ve got money? We’re in

RAMP Ransom Anon Mark[et] Place

RAMP was created in July 2021 by a threat actor TetyaSluha, who later changed their moniker to ‘Orange.’ This actor claimed the forum would specifically cater to other ransomware-related threat actors after they were ousted from major cybercrime forums for being too toxic, following the high-profile ransomware attacks against the Colonial Pipeline and Washington D.C.’s Metropolitan Police Department in the spring of 2021.

At the time of the initial launch, Orange claimed the forum’s name was a tribute to a now-defunct Russian-language underground drug marketplace, “Russian Anonymous Marketplace,” which was taken down by Russian law enforcement agencies in 2017.  The re-launched cybercrime forum’s name now supposedly stands for “Ransom Anon Mark[et] Place”.

The forum was initially launched on the same TOR-based resource that previously hosted a name-and-shame blog operated by the Babuk ransomware gang and the Payload.bin marketplace of leaked corporate data. The forum was later moved to a dedicated TOR-based resource and relaunched with a new layout and a revamped administrative team, where Orange acted as the admin, with other known actors MRT, 999 and KAJIT serving as moderators.

Why the name Orange?

Why the admin changed handles from TetyaSluha to Orange isn’t 100 percent clear. However, looking back, the early days of RAMP provides us some evidence on who this person has been affiliated with. We found a posting from  where the names Orange and Darkside are mentioned as potential monikers. Very shortly after that, TetyaSluha changed their handle to Orange. While the initial message has been removed from the forum itself, the content was saved thanks to Intel 471.

July 12^th 2021 by Mnemo

Congratulations on the successful beginning of struggle for the right to choose and not to be evicted. I hope, the community will soon fill with reasonable individuals.

Oh yeah, you’ve unexpectedly reminded everyone about the wonderful RAMP forum. Are the handles Orange and Darkside still free?

The name Darkside might sound more familiar than Orange but, as we saw with the naming of RAMP, TetyaSluha is one for cybercrime sentiment, so there is almost certainly some hidden meaning behind it.

Based on ATR’s previous research, we believe the name Orange was chosen as a tribute to REvil/GandCrab. People familiar with those campaigns have likely heard of the actor ‘UNKN’. However, there was a less well known REvil affiliate admin named Orange. A tribute seems fitting if Tetyasluha isn’t the notorious Orange as that moniker is tied to some successful ransomware families, GandCrab and REvil, that shaped the RaaS ecosystem as we know it today. 

In the past, UNKN was linked to several other monikers, however Orange was hardly mentioned since there wasn’t a matching public handle used on any particular cybercrime forum.  However, REvil insiders will recognize the name Orange as one of their admins.

Based on ATR’s closed-source underground research, we believe with a high level of confidence, that UNKN was indeed linked to the aforementioned accounts, as well as the infamous “Crab”handle used by GandCrab. Crab was one of the two affiliate-facing accounts that the GandCrab team had (The other being Funnycrab). We believe with a high level of confidence that after the closure of GandCrab, the individual behind the Funnycrab account changed to the account name to Orange and continued operations with REvil, with only a subset of skilled GandCrab affiliates, (as described in our Virus Bulletin 2019 whitepaper) since GandCrab grew too big and needed to shed some weight.

The posting in figure 5 is also shedding some light on the start of the Groove Gang, their relationship to Babuk and, subsequently, BlackMatter.

Groove Gang

In the post from Figure 5, “Orange” also claims to have always had a small group of people that the group collaborates with. Additionally, the actor claims that the name has not been mentioned in the media before, comparing the group to the Israeli secret service group Mossad. The group’s comparison to Mossad is extremely doubtful at best, given the drama that has publicly played out. Groove claims several of Babuk’s victims, including the Metropolitan Police Department, brought them a lot of attention. The several mentions to Babuk isn’t by mistake: we have evidence the two groups also have connections, which we’ve pieced together from examining the behavior of — and particularly the fallout between — the two groups.

Babuk’s Fallout

Originally, the Babuk gang paid affiliates by each victim they attacked. Yet on April 30, it was reported that the gang suddenly had stopped working with affiliates, including the act of encrypting a victim’s system. Instead, their focus shifted to data exfiltration and extortion of targeted organizations. That was followed by the group releasing the builder for the old versions of its ransomware as it pivoted to a new one for themselves.

The attention that Babuk drew by hacking and extorting the Metropolitan Police Department meant their brand name became widely known. It also meant that more firms and agencies were interested in finding out who was behind it. This kind of heat is unwanted by most gangs, as any loose ends that are out there can come back to bite them.

Then, on September 3, the threat actor with the handle ‘dyadka0220’ stated that they were the principal developer of Babuk ransomware and posted what they claimed was the Babuk ransomware source code. They claimed the reason they were sharing everything was due to being terminally ill with lung cancer.

Figure 6. Dyadka0220 was possibly the developer that Orange hinted at in the posting (Figure 5) mentioned above.

On September 7, the Groove gang responded with a blog on their own website, titled “Thoughts about the meaning”, which rhymes in Russian. In this blog, the gang (allegedly) provides information on several recent happenings. Per their statement, the illness of ‘dyadka0220’ is a lie. Additionally, their response alleges that the Groove gang never created the Babuk ransomware themselves, but worked with someone else to produce it.

The validity of the claims in Groove’s latest blog is hard to determine, although this does not matter too much: the Babuk group, including affiliates, had a fallout that caused the group to break up, causing the retaliation of several (ex-)members.

Observed Behavior

The ATR team has covered Babuk multiple times. The first blog, published last February, covers the initial observations of the group’s malware. The second blog, published last July, dives into the ESXi version of the ransomware and its issues. The group’s tactics, techniques, and procedures (TTPs) are in-line with commonly observed techniques from ransomware actors. The deployment of dual-use tools, which can be used for both benign and malicious purposes, is difficult to defend against, as intent is an unknown term for a machine. Together with other vendors we have narrowed down some of the TTPs observed by the Groove gang.

Initial Access

The actor needs to get a foothold within the targeted environment. The access can be bought, in terms of stolen (yet valid) credentials, or direct access in the form of a live backdoor on one or more of the victim’s systems. Alternatively, the actor can exploit publicly facing infrastructure using a known or unknown exploit. To ATR’s understanding, the latter has been used several times by exploiting vulnerable VPN servers.

Lateral Movement, Discovery and Privilege Escalation

Moving around within the network is an important step for the actor, for two reasons. Firstly, it allows the attacker to find as much data as possible, which is then exfiltrated. Secondly, access to all machines is required in order to deploy the ransomware at a later stage. By encrypting numerous devices at once, it becomes even harder to control the damage from a defender’s point of view. The actor uses commonly known tools, such as Ad-Find and NetScan, to gather information on the network. Based on the gathered information, the actor will move laterally through the network. One of the most frequently observed methods by this actor to do so, is by using RDP.

To work with more than user-level privileges, the actor has a variety of options to escalate their privilege to a domain administrator. Brute forcing RDP accounts, the dumping of credentials, and the use of legacy exploits such as EternalBlue (CVE-2017-0144), are ways to quickly obtain access to one or more privileged accounts. Once access to these systems is established, the next phase of the attack begins.

Data Exfiltration and Ransomware Deployment

The actor navigates through the machines on the network using the earlier obtained access. To exfiltrate the collected data, the attacker uses WinSCP. Note that other, similar, tools can also be used. Once all relevant data has been stolen, the attacker will execute the ransomware in bulk. This can be done in a variety of ways, ranging from manually starting the ransomware on the targeted machines, scheduling a task per machine, or using PsExec to launch the ransomware.

Linking Groove to Babuk and BlackMatter

As discussed above, there was a fallout within Babuk. From that fallout, a part of the group stayed together to form Groove. The server that Babuk used, which we will refer to as the “wyyad” server due to the ending of the onion URL, rebranded in late August 2021. The similarities can be seen in the two screenshots below.

Figure 7. The changes to the landing page from Babuk to Groove

Aside from this, data from old Babuk victims is still hosted on this server. The ATR team found, among others, leaks that belong to:

• a major US sports team,
• a British IT service provider,
• an Italian pharmaceutical company,
• a major US police department,
• a US based interior shop.

All these victims have previously been claimed by (and attributed to) Babuk.

Another gang, known as BlackMatter, uses a variety of locations to host their extorted files, which can be done out of convenience or to avoid a single notice and takedown to remove all offending files. Additionally, the ATR team assumes, with medium confidence, that different affiliates use different hosting locations.

The data of one of the BlackMatter gang’s victims, a Thai IT service provider, is stored on the “wyyad” server. As such, it can mean that the Groove gang worked as an affiliate for the BlackMatter gang. This is in line with their claim to work with anybody, as long as they profit from it. The image below shows the BlackMatter leak website linking to the “wyyad” server.

Figure 8. screenshot of BlackMatter, where the data is stored on the Groove server

The Groove gang’s website contains, at the time of writing, a single leak: data from a German printing company. Even though the website is accessible via a different address, the leaked data is stored on the “wyyad” server.

Figure 9. Another Groove victim but stored on their own page

The affected company does not meet BlackMatter’s “requirements,” the group has said it only goes after companies that make more than $US 100 million. This company’s annual revenue is estimated at $US 75 million, as seen in the below screenshot.

Figure 10. Posting on the Exploit forum by BlackMatter

At the end of Orange’s announcement comes a call to action and collaboration: “GROOVE is first and foremost an aggressive financially motivated criminal organization dealing in industrial espionage for about two years. RANSOMWARE is no more than an additional source of income. We don’t care who we work with and how. You’ve got money? We’re in”.

The group’s primary goal, making money, is not limited to ransomware. Inversely, ransomware would be the cherry on top. This is yet another indication of the ransomware group’s shift to a less hierarchical set-up and a more fluid and opportunistic network-based way of working.

In the Groove gang’s blog on September 7, a reference is made with regards to BlackMatter, and its links to DarkSide. If true, these insights show that the Groove gang has insider knowledge of the BlackMatter gang. This makes the collaboration between Groove and BlackMatter more likely. If these claims are false, it makes one wonder as to why the Groove gang felt the need to talk about other gangs, since they seem to want to make a name for themselves.

Due to the above outlined actions ATR believes, with high confidence, that the Groove gang is a former affiliate or subgroup of the Babuk gang, who are willing to collaborate with other parties, as long as there is financial gain for them. Thus, an affiliation with the BlackMatter gang is likely.

Conclusion

Ever since Ransomware-as-a-Service became a viable, and highly profitable, business model for cybercriminals, it has operated in much the same way with affiliates being the sometimes underpaid workhorses at the bottom of a rigid pyramid shaped hierarchy.

For some affiliates there was an opportunity to become competent cybercriminals while, for many others, the lack of recompense and appreciation for their efforts led to ill-feeling. Combined with underground forums banning ransomware actors, this created the perfect opportunity for the threat actor known as Orange to emerge, with the Groove gang in tow, with the offer of new ways of working where an associate’s worth was based entirely on their ability to earn money.

Time will tell if this approach enhances the reputation of the Groove gang to the level of the cybercriminals they seem to admire. One thing is clear though; with the manifestation of more self-reliant cybercrime groups the power balance within the RaaS eco-climate will change from he who controls the ransomware to he who controls the victim’s networks.

MITRE TTPs

We have compiled a list of TTPs based on older Babuk cases and some recent cases linked to Groove:

• T1190: Exploit Public-Facing Application (VPN services)
• T1003: OS Credential Dumping
• 002: Valid Accounts: Domain Accounts
• T1059: Command and Scripting Interpreter
• T1021:002: SMB/Windows Admin Shares
• T1210: Exploitation of Remote Services
• T1087: Account Discovery
• T1482: Domain Trust Discovery
• T1562: Impair Defense
• T1537: Transfer Data to Cloud Account
• T1567: Exfiltration Over Web Service

If a partnership is achieved with a Ransomware family:

• T1486 Data Encrypted for Impact

The post How Groove Gang is Shaking up the Ransomware-as-a-Service Market to Empower Affiliates appeared first on McAfee Blog.

Overmedicated: Breaking the Security Barrier of a Globally Deployed Infusion Pump

Cyberattacks on medical centers are one of the most despicable forms of cyber threat there is. For instance, on October 28th, 2020, a cyberattack at the University of Vermont Medical Center in Burlington VT led to 75% of the scheduled chemotherapy patients being turned away. Many of us have friends and loved ones who have had to undergo intensive treatments, and the last thing we want in this situation is for their critical care to be delayed due to on-going cyberattacks. Yet, as concerning as ransom attacks can be, what if the process of receiving the treatment was an even bigger threat than a system-wide ransomware event?

McAfee’s Enterprise Advanced Threat Research team, in partnership with Culinda, have discovered a set of vulnerabilities in B. Braun Infusomat Space Large Volume Pump and the B. Braun SpaceStation.

McAfee Enterprise ATR remotely hacks a B.Braun Infusomat Pump

These critical vulnerabilities could allow an attacker to conduct remote network attacks and modify the amount of medication a patient will receive through infusion. This modification could appear as a device malfunction and be noticed only after a substantial amount of drug has been dispensed to a patient, since the infusion pump displays exactly what was prescribed, all while dispensing potentially lethal doses of medication. This attack scenario is made possible through a chain of known and previously unknown vulnerabilities found by McAfee Enterprise ATR. A critical component of this attack is that the pump’s operating system does not verify who is sending commands or data to it, allowing an attacker to carry out remote attacks undetected. For those looking for a more technical analysis of the vulnerabilities, an in-depth blog can be found here.

History and Industry Insights

From the 1960’s to 2000, infusion pumps were mostly electromechanical devices with an embedded operating system, but the turn of the century delivered “smarter” devices with better safety mechanisms and the possibility to program them, which slowly opened the door to computer security challenges. Today, it is estimated that there are over 200 million IV infusions administered globally each year. The infusion pump market is a clear potential target for attackers. The market is valued at an estimated $54 billion in annual revenue, with 2020 sales of IV pumps in the US at $13.5 billion. IV pumps are inherently trusted to be secure and have over time become the mainstay for efficient and accurate infusion delivery of medication. B. Braun is one of the key market share holders in this rapidly growing market, emphasizing the impact of these vulnerability discoveries.

Industry personnel can be the best source of information for determining impact. Shaun Nordeck, M.D, an Interventional Radiology Resident Physician at a Level 1 Trauma Center, prior Army Medic and Allied Health Professional, with more than 20 years in the medical field, states that: “Major vulnerability findings like the ones reported by McAfee’s Enterprise Advanced Threat Research team are concerning for security and safety minded medical staff. The ability to remotely manipulate medical equipment undetected, with potential for patient harm, is effectively weaponizing these point of care devices. This is a scenario previously only plausible in Hollywood, yet now confirmed to be a real attack vector on a critical piece of equipment we use daily. The ransomware attacks that have targeted our industry rely on vulnerabilities just like these; and is exactly why this research is critical to understanding and thwarting attacks proactively.”

These vulnerabilities were reported to B. Braun beginning in January 2021 through McAfee’s responsible disclosure program. Through ongoing dialog, McAfee Enterprise ATR have learned that the latest version of the pump removes the initial network vector of the attack chain. Despite this, an attacker would simply need another network-based vulnerability and all remaining techniques and vulnerabilities reported could be used to compromise the pumps. Additionally, the vulnerable versions of software are still widely deployed across medical facilities and remain at risk of exploitation. Until a comprehensive suite of patches is produced and effectively adopted by B. Braun customers, we recommend medical facilities actively monitor these threats with special attention, and follow the mitigations and compensating controls provided by B. Braun Medical Inc. in their coordinated vulnerability disclosure documentation.

Call to Action

This concludes a research project which took two senior researchers a significant amount of time to showcase a life-threatening risk of a medical device being taken over by a remote attacker. For the time being, ransomware attacks are a more likely threat in the medical sector, but eventually these networks will be hardened against this type of attack and malicious actors will look for other lower-hanging fruits.

The unfortunate reality is that individuals can’t do much to prevent or mitigate these enterprise-level risks, outside of staying mindful of security issues and maintaining awareness of possible threats. However, the good news is that security researchers continue to propel this industry towards a safer future through responsible disclosure. We strongly encourage vendors to embrace vulnerability research and consumers to demand it. The medical industry has lagged severely behind others in the realm of security for many years – it’s time throw away the digital “band-aids” of slow and reactive patching, and embrace a holistic “cure” through a security-first mindset from the early stages of development, combined with a rapid and effective patch solution.

Braun Medical Inc. Statement

In May 2021, B. Braun Medical Inc. disclosed information to customers and the Health Information Sharing & Analysis Center (H-ISAC) that addressed the potential vulnerabilities raised in McAfee’s report, which were tied to a small number of devices utilizing older versions of B. Braun software. Our disclosure included clear mitigation steps for impacted customers, including the instructions necessary to receive the patch to eliminate material vulnerabilities.

Braun has not received any reports of exploitation or incidents associated with these vulnerabilities in a customer environment.

The post Overmedicated: Breaking the Security Barrier of a Globally Deployed Infusion Pump appeared first on McAfee Blog.

McAfee Enterprise ATR Uncovers Vulnerabilities in Globally Used B. Braun Infusion Pump

Overview

As part of our continued goal to provide safer products for enterprises and consumers, we at McAfee Advanced Threat Research (ATR) recently investigated the B. Braun Infusomat Space Large Volume Pump along with the B. Braun SpaceStation, which are designed for use in both adult and pediatric medical facilities. This research was done with support from Culinda – a trusted leader in the medical cyber-security space. Though this partnership, our research led us to discover five previously unreported vulnerabilities in the medical system which include:

1. CVE-2021-33886 – Use of Externally-Controlled Format String (CVSS 7.7)
2. CVE-2021-33885 – Insufficient Verification of Data Authenticity (CVSS 9.7)
3. CVE-2021-33882 – Missing Authentication for Critical Function (CVSS 8.2)
4. CVE-2021-33883 – Cleartext Transmission of Sensitive Information (CVSS 7.1)
5. CVE-2021-33884 – Unrestricted Upload of File with Dangerous Type (CVSS 5.8)

Together, these vulnerabilities could be used by a malicious actor to modify a pump’s configuration while the pump is in standby mode, resulting in an unexpected dose of medication being delivered to a patient on its next use – all with zero authentication.

Per McAfee’s vulnerability disclosure policy, we reported our initial findings to B. Braun on January 11, 2021. Shortly thereafter, they responded and began an ongoing dialogue with ATR while they worked to adopt the mitigations we outlined in our disclosure report.

This paper is intended to bring an overview and some technical detail of the most critical attack chain along with addressing unique challenges faced by the medical industry. For a brief overview please see our summary blog here.

Table of Contents

• Background
  • What are Infusion Pumps?
  • What Security Research has Already Been Performed?
• Project Motivation
• System Description
  • SpaceCom Functions and Software Components
• Critical Attack Scenario Details
  • Goals
  • Initial Access
  • Privilege Escalation
  • Crossing Systems
  • Understanding Critical Data
  • Final Attack Chain
  • Attack Prerequisites
• Impact
  • Demo
• Unique Considerations for Infusion Pump Hacking
  • Why we modified TUBE_HEADVOLUME
  • Operations in Hospitals and Consequences of Over-Infusing Drugs
• Common Pitfalls
  • Patching is Costly
  • Designed for Safety Rather than Security
  • Everything is Trusted
  • CAN gets Connected to WIFI
  • Technical Debt
• Conclusion
• CVE Details
  • CVE: CVE-2021-33882
  • CVE: CVE-2021-33883
  • CVE: CVE-2021-33884
  • CVE: CVE-2021-33885
  • CVE: CVE-2021-33886

Background

The most important part of any product assessment is a solid understanding of the purpose and function of the product under test. Without this it is simply too easy for research to produce less than meaningful results. Therefore, for this research it is first important to answer these few simple questions. What are infusion pumps? What security research has already been performed?

What are Infusion Pumps?

To start with the basics using a trusted resource – fda.gov says “An infusion pump is a medical device that delivers fluids, such as nutrients and medications, into a patient’s body in controlled amounts.” The FDA goes on to explain they are typically used by a “trained user who programs the rate and duration”. Infusion pumps can be simple, administering a single intravenous (IV) medication in the home setting, or complex, delivering multiple medications simultaneously in the ICU setting. From the 1960’s to 2000 infusion pumps were mostly electromechanical devices with some embedded electronics, but the turn of the century delivered “smarter” devices with better safety mechanisms and the possibility to program them, which slowly opened the door to information security challenges. Cross referencing the specific product we have chosen to look at, the Infusomat® Space® Large Volume Pump (Figure 1), we see that this pump is meant only for a medical setting and not designed for a home user. Infusion pumps exist mostly to remove the need to perform manual infusion, which requires dose conversion into drops per minute and visually counting drops to set a rate which is both time consuming and unreliable. It is estimated that there are over 200 million IV infusions administered globally each year, and 2020 sales of IV pumps in the US were at $13.5 billion. Clearly infusion pumps have cemented their place in the medical world.

Figure 1: B. Braun Infusomat Pump

What Security Research has Already Been Performed?

Since infusion pumps are such a large part of the medical field and there are several different types, it is reasonable to expect our team is not the first to inquire about their security. As expected, there have been many different research projects on infusion pumps over the years. Perhaps the most well-known research was presented in 2018 at Blackhat by Billy Rios and Johnathan Butts. The infusion pump portion of their research was focused on the Medtronic insulin pumps. They found they were able to remotely dose a patient with extra insulin due to cleartext traffic and the ability to issue a replay attack. Even earlier, in 2015 research was published on the Hospira Symbiq Infusion Pump showing that it was possible to modify drug library files and raise dose limits through “unanticipated operations”, although authentication was required.

Of course, for our purpose, the most important question remains – is there any previous research performed on our specific device. Initially the answer was no; however, during our research project a very large study, ManiMed, was released under the aegis of German authorities to examine the security of network-connected medical devices produced or in use in their country. This included research done on the B. Braun Infusomat pump. This is a fantastic piece of work which covers many network-connected devices. We will reference this study and talk about their findings where appropriate throughout this document, as we additionally explore our enhancements to this research and demonstrate a new attack that was previously called impossible.

Project Motivation

If we consider the Background section earlier, it becomes apparent there is still a large amount of critical research to be performed in this space. Infusion pumps are a prominent and continuously developing area within the medical device space, where previous research has only scratched the surface. Due to the potential critical impact and the state of medical device security, many previous projects didn’t need to dig very deep to find security issues or concerns. The infusion pump industry has numerous devices which have not been researched publicly at all, and even more that only received a cursory analysis from the information security community. For these reasons, we decided to have an in-depth look at one of the largest infusion pumps vendors, B. Braun, and specifically focus on one of their devices used worldwide to analyze it at a depth never seen before. Tackling every aspect of this pump, we wanted to answer the basic question: In a realistic scenario, leveraging original security vulnerabilities, could a malicious attacker impact human life?

System Description

For this research project our system consisted of three main components– a B. Braun Infusomat Large Volume Pump Model 871305U (the actual infusion pump), a SpaceStation Model 8713142U (a docking station holding up to 4 pumps) and a software component called SpaceCom version 012U000050. These models and the corresponding software for the B. Braun Infusomat system were released in 2017. In industries such as consumer electronics, this would be considered obsolete and therefore less relevant to research. However, as discussed above, in the medical field this is simply not the case. Since older devices are still widely used and perhaps originally developed with a less emphasis on security, it increases the importance of investigating them. For due diligence, we consulted and confirmed with our industry partners that this specific model was still actively being used in hospital systems across the country.

SpaceCom is an embedded Linux system that can run either on the pump from within its smart-battery pack or from inside the SpaceStation. However, when the pump is plugged into the SpaceStation, the pump’s SpaceCom gets disabled. We performed most of our research with the pump attached to the SpaceStation as we found this was the most common use case. If a SpaceStation was compromised, it could potentially affect multiple pumps at once. SpaceCom acts as the external communication module for the system and is separated from the pump’s internal operations, regardless of where it is running from.

If we consider the pump attached to the SpaceStation as one system, it has three separate operating systems running on three distinct chipsets. SpaceCom running on the SpaceStation runs a standard version of Linux on a PowerPC chipset. The WIFI module for the SpaceStation also runs a standard version of Linux on an ARM chipset and communicates over a PCI bus with SpaceCom. Lastly, the pump runs its own custom Real Time Operating System (RTOS) and firmware on a M32C microcontroller. An additional microcontroller is used to monitor the M32C microcontroller, but this goes beyond the scope of our research. Due to this modular and isolated design, the Spacecom communication module and the pump need a dedicated path for exchanging data. This is resolved via a CAN bus, shared throughout the SpaceStation, where it allows pumps and accessories to communicate with each other. This is what SpaceCom and any pump docked into the Space Station rely on for their exchange. An architecture diagram below helps demonstrates the system layout and design when a pump is present in the docking station.

Figure 2: System Architecture

SpaceCom Functions and Software Components

SpaceCom contains many different pieces of propriety software and applications to support the many functions of the larger B. Braun and medical facility ecosystem. Our team spent time analyzing each one in great detail; however, for the purpose of this paper we will only touch on key components which are important to the most critical findings mention in the opening summary.

An important function of SpaceCom is to be able to update the drug library and pump configuration stored on the pump. The drug library contains information such as ward and department, a list of pre-configured drugs with their default concentrations, information messages to be printed on the screen when selected, and more importantly, soft, and hard limits to prevent medication error. One of the biggest selling points of the smart infusion pumps is their ability to prevent incorrect dosing of drugs, which is partly done through the limits in the drug library. Another risk the drug library helps mitigate is human error. By having the most common dosage and infusion lengths preprogrammed into the pump, it eliminates errors associated with rate calculations, and drop counting previously mentioned, associated with manual infusion therapy.

The pump RTOS contains a database of over 1500 key/value pairs used during operation. This data consists of everything from status about current components, battery life, motor speed, alarms and values used for tube calibration. As such, this data would be considered extremely sensitive in the context of the pump’s operation and is not intended to have direct user interaction, nor is it presented to the user. A subset of the keys can be indirectly modified via a dedicated servicing software by certified technicians.

To interact with both the drug library and pump configuration on the pump from SpaceCom, a propriety binary called PCS is used. The PCS binary uses the canon binary to interface with the CAN bus to send commands to the pump’s system for both reading and writing values based on the drug library or pump configuration provided to it. The main interface to accomplish this task is via a propriety TCP networking protocol, which by default is sent over port 1500. This protocol is both unauthenticated and unencrypted and we relied heavily on these weaknesses for our research and attacks. Additionally, this resulted in the filing of CVE-2021-33882 and CVE-2021-33883 as stated in the overview above.

Critical Attack Scenario Details

Goals

What could be the goal of a malicious attacker? Realistically speaking, most attacks have been proven to be financially motivated. When translating this to our infusion pump, the question becomes: What would medical executives, without hesitation, pay large sums of money for? If we look at recent events, in May of 2021, Colonial Pipeline paid hackers 4.4 million dollars to get their oil pipeline running again from ransomware attacks. Attacks on healthcare settings are increasing with the FBI estimating a cyberattack using “Ryuk” ransomware took in $61 million over a 21-month period in 2018 and 2019. Attacks are now showing potential for patient harm with one example beginning on October 28^th, 2020. The University of Vermont Health Network was part of a larger coordinated attack on multiple US healthcare which resulted in a complete loss of their electronic medical record system for weeks. The results of the ransomware-based attack led to 75% of active chemotherapy patients being turned away, rerouting of ambulances, and delays in testing and treatment. Considering IV pumps are directly supporting human life in some cases, it is easy to suggest an attacker could demand any “ransom” amount leveraging threats to actual patients. To accomplish this an attacker would therefore need to control the operation of the pump.

This task is easier said than done when considering the design of the pump as outlined above. The traditional “getting root” on the network component (SpaceCom) proves ineffective. To make any changes to the pump itself, an attacker needs to interact with the pump’s RTOS, which is not network connected. In this section we provide an outline on how we were able to accomplish this goal by using the five reported CVEs.

Initial Access

Even though getting root access on SpaceCom will not provide us everything we need to accomplish the ultimate goal, it is still the first step. During our reconnaissance and enumeration of the system we discovered a remote interface listening at https://{ipaddress}/rpc. This interface was connected to a common open source service referred to as “json-dbus-bridge”. As described on GitHub, this service “is a fast-cgi application that provides access to D-Bus. It accepts JSON-RPC calls and translates these into D-Bus calls. Any response is converted back to JSON and sent to the client.” This piqued our interest since external access to the D-Bus subsystem could provide us access to internal communication, which may have a different level of security than typical external networking.

When doing any type of vulnerability research, product security assessment or evaluation it is critical to not forget to search for existing issues in any third-party components. This is even more important since we are working on a software released in 2017. While scouring GitHub pages for the json-dbus-bridge, we noticed a format string vulnerability that was patched in 2015. Of course, we had to test if the version we encountered had the existing vulnerability.

Figure 3: Format String Vulnerability Testing

The tests in Figure 3 confirmed the existence of the format sting vulnerability. While this format string vulnerability had been publicly discovered in 2015 in the json-dbus-bridge code, the update was never included in B. Braun’s software and hence satisfied the condition for a vendor specific zero-day vulnerability disclosure. This was filed as CVE-2021-33886 and was our first reported discovery to B. Braun. Over the next several weeks we were able to leverage this vulnerability and create a working exploit to gain www user level shell access to the device. Due to the potential impact to unpatched devices, the exact technical details of our exploit have not been included.

Privilege Escalation

Although user access is the first step, root access will be needed in order to interact with the CAN bus to communicate with the actual pump. A good target and well-known process for privilege escalation is to find a binary owned by root with the setuid bit enabled. We could not find one ready to use; however, the web interface has an option to backup and export settings which relies on tarring a folder containing a handful of files and encrypting it with AES using a user-provided password. The backup archive can then be downloaded for later restore of the settings. When restoring this backup, root is the user doing the untarring in such a way that file permissions are being preserved from the provided tar file. Thus, if we can tamper with the archive, we might be able to create a privilege escalation scenario.

To use this to our advantage we need to embed a binary in the backup archive owned by root with the “setuid” bit set so we can use it to elevate privileges. Ironically, the code responsible for the import/export of settings is already doing most of the work for us. The “configExport” binary located on the filesystem is a wrapper to call setuid/setgid (and sanitize inputs) which then calls execve on the script “/configExport/configExport.sh.” We can use a hex editor to change which script the “configExport” binary is running and replace “configExport.sh” with an attacker-controlled script, while also patching out the input sanitizing. We could absolutely have compiled our own binary instead, but this approach saves us from a couple of hours of PPC cross-compiling fun.

While we were working through this component of our attack chain, researchers working on the ManiMed project, in coordination with B. Braun, published a report which included this finding, listed as CVE-2020-16238 on B. Braun’s website. As described in section 4.6.2.2 of their report “An authenticated arbitrary file upload vulnerability combined with an unvalidated symbolic link and local privilege escalations enables attackers to execute commands as the root user.” We commend the ManiMed researchers for also discovering this vulnerability and practicing responsible disclosure.

Crossing Systems

The real work begins once root access is obtained. The challenge becomes how to affect change on the pump RTOS with root access on the SpaceCom communication module. One common approach would be to continue to look for vulnerabilities in the pump’s RTOS that would lead to code execution within its system. This method poses many challenges during black box testing and could lead to damaging our limited number of test devices.

Another approach which we have leveraged in past projects is hijacking the standard functionality of the device to further the attack. This can be more manageable, but it first requires a deep understanding of how the device works and the desired outcome. This also tests the device’s defense in depth and can prove to be very difficult depending on the security measures in place. In our case, this would force the question of how well-protected the area is surrounding the communication between the pump and SpaceCom.

As mentioned in the system description section above, the PCS binary is responsible for communicating with the pump’s system for two critical operations – updating the drug library and updating the pump config. These are key functions that would likely be of interest to an attacker. There are several different approaches which could be taken by an attacker to interact with these key operations, especially given root access. Considering the various alternatives, we chose to leverage our root access on SpaceCom to inject code into PCS’s memory and use existing functions and objects to communicate with the pump’s internal system.

Our chosen path required a deep understanding of the data structures and functions used to facilitate this communication. The key is to find the perfect place in a larger operation call stack where we can modify or inject the data we want, while still utilizing lower-level functions to avoid the need to unnecessarily create objects and data from scratch. To illustrate this point, consider if we want to send a simple signal to power off the pump from within PCS’s memory space. The fact that all data sent from SpaceCom to the pump’s RTOS is done through CAN messages, with root access meant that we could send CAN messages directly on the CAN bus. This would require an extensive knowledge and breakdown of the CAN message structure as the underlying protocol is designed by B. Braun and would have to be reverse engineered. Although possible, it is very difficult, especially with CAN’s data frame field having a lack of strict specifications. Inside PCS there is a call chain which builds this message. If we were to inject and utilize functions very low in the call chain, such as the trySend function which sends a CAN message (as seen in figure 4) , we would need to understand all of its arguments and the data format it uses. We’d essentially have the same problem as before.

Figure 4: trySend function

If we look higher in the call stack for a function that performs the operation we are interested in, switching off the device, we can instead let the rest of the call chain do the heavy lifting for us. Notice in Figure 5 below there is a function for just this purpose, which only requires one parameter to be passed.

Figure 5: switchOffDevice

Leveraging this concept, we are able to use the functions within PCS in a manner similar to an API to perform read and write operations to the pump’s database and force a change.

Understanding Critical Data

If we want to send and write data such as the drug library and pump config, we first need to understand the format of the data, how it is processed and any security measures in place which need to be accounted for. Our team spent extensive time reversing both the drug library and pump configuration data. A portion of the pump configuration is referred to as calibration and disposable data. Both can be modified through our attack chain; however, for this paper we will just touch on the more critical of the two the calibration and disposable data.

The calibration and disposable data are usually seen in the form of files that are living in SpaceCom. At a more granular level, they are a collection of key/value pairs that are meant to be read or written to the pump’s database. Each file can also be a large blob of data living on the pump flash. The physical location of each key within this blob is hardcoded in the pump and sometimes in PCS. This representation is relevant when it comes to computing various CRCs that operate on blobs of data rather than key pairs. These checksums are used heavily throughout the pump’s infrastructure with critical data to ensure the integrity of the data. This goes to ensure the safety of patients by ensuring data can’t be accidently modified or corrupted. Figure 6 shows an example of disposable data as contained in files on SpaceCom.

Figure 6: Disposable Data

Looking at the variable names inside the disposable data file and relevant code in the pump firmware led us to one key/value pair that specifies the “head volume” of the tube, which can be seen in the figure above. After extensive analysis, we determined that “head volume” is the parameter dictating the amount of medication being delivered per cycle to the patient. We determined that if this value was to be changed, it could be potentially harmful. We detail this analysis in section “Unique Consideration for Infusion Pump Hacking” below.

With a target key/value pair in mind, the next step would be to understand how to calculate the CRCs. Since the system is constantly checking the integrity of the data, if an attacker wanted to modify any value, they would also need to modify the CRCs which validate the changed data. Through reverse engineering we determined the CRC was a custom implementation of a CRC16, where the initial value is 0xFFFF and relies on a hardcoded polynomial table. We were able to extract this algorithm and write custom python scripts to compute the CRC needed for the disposable data.

With a basic understanding of the critical operational data and the ability to compute the CRCs, we are able to leverage the PCS binary, in an API fashion to send commands to the pump to modify this data. This holds true for both the drug library and the pump configuration data. Although CRCs are great for integrity checking, they provide no security or level of trust of the where the data is coming from.  This lack of origin verification is what led to the filing of CVE-2021-33885.

Final Attack Chain

If we review our attack chain, we can gain user-level access to the device without authentication or authorization. We can then escalate our privileges to root and leverage the existing functionality of the PCS binary to make modifications to the pump’s disposable data. Conceptually, the process is complete; however, we can do some additional housekeeping in order to make our attack chain slightly more realistic and efficient.

Since the proprietary protocol for the PCS binary is unauthenticated, there are certain configuration options which can be modified for an attacker to make their job even easier. One of these configuration options tells the pump which server is “trusted” to receive operational data from (such as the drug library). An attacker can send a command to SpaceCom which clears the current trusted server configuration and rewrites it to an attacker-controlled server. This is not required for this attack when leveraging the format string and privilege escalation path outlined above; however, it does provide alternative methods and simplifies the attack process.

Lastly, the pump has an audible and visual notification when any configuration or drug information has been modified on the pump. Once again in the spirit of a realistic attack, a malicious attacker is going to want to be as stealthy as possible. To accomplish this, it was worth determining a method in which to clear these notifications. This process turned out to be as simple as restarting the pump after our modifications were complete. The reboot operation happens in a matter of seconds, so by using this technique, all alerts to the end user were quickly cleared. The complete attack process can be seen outlined in the diagram below.

Figure 7: Complete Attack Chain

Attack Prerequisites

Although this attack chain presents a complete method to modify critical pump data, it is important to recognize the conditions required for this attack to be successful. These pumps are designed to be network connected to a local internal network. Therefore, under normal operating conditions an attacker would need to have found a method to gain access to the local network. Could this attack take place over the internet? Technically speaking, yes; however, it would be very unlikely to see a setup where a pump is directly internet-connected.

In addition to being on the local network, the pump does have safeguards in place to ensure no modifications can occur while the pump is operational. From what we discovered during our research, if the pump is actively administering medication, it ignores any request on the CAN bus to modify library or configuration data. This means the attack can only be successful when a pump is idle or in standby mode in between infusions.

Impact

The prerequisites for this attack are minimal and are not enough to mitigate the overall threat. In today’s world there are a wide range of documented and utilized methods for attackers to gain access to local networks. If we also consider that hospital or medical facilities are generally public places with little to no barriers to entry, it is easy to see how someone malicious can go unnoticed and obtain network access. Pumps are also not always actively administering mediation. Even in the busiest of hospitals there is downtime between patients or times when pumps are simply not in use.

With the ability to modify disposable and configuration data on the pump, there are a wide range of possibilities for which an attacker could choose to have an impact. An attacker could simply put the device in an unusable state or write arbitrary messages on the screen. We chose to focus on the disposable data, specifically the key/value pair labeled “TUBE_HEADVOLUME_A” since we determined it would demonstrate the greatest impact, bringing harm to a patient. In the below video you will first see the pump under normal operation. After demonstrating the system working as intended, we modify the configuration remotely using the attack chain explained above and then illustrate its effect on the pump when administering medication.

Demo

Unique Considerations for Infusion Pump Hacking

An interesting characteristic of this project is that its impact and consequences are inherently grounded in the physical world. Where common software hacks end with the ability to get root access or kernel privileges, in this project, the way the device is used by medical staff and how it can affect patient safety is crucial to the outcome. The next few sections will focus on various aspects of the project that fall under this umbrella.

Why we modified TUBE_HEADVOLUME

As described previously, our attack relies on modifying the disposable data that governs the way the pump is used to deliver medication. But why and how did we decide to go investigate this? An interesting side-effect of the pump being built to be safe is that most of the inputs and outputs it receives from the CAN bus are extensively checked against out-of-range access. From an attacker’s perspective who has already compromised SpaceCom, this would usually be the prime target for memory corruption bugs. Fuzzing and emulating the M32C architecture is cost-heavy in terms of upfront work, so instead, we started looking for a path of least resistance and searched for blind spots in the secure design.

In our case, we wanted to be able to affect the amount of drug being dispensed, preferably without having something on screen as that would indicate a malfunction or abnormality. Our original plan was to tamper with the device drug library, but it turns out that data we could alter would be displayed on screen, which could raise concern as medical staff verify the prescribed drug and rate against the order before, and immediately after starting the infusion. This would not be ideal for an attacker, so we kept investigating. The other files we could modify were the calibration data and the disposable data. These files are interesting as they describe internal parameters; the calibration one specifies the physical parameters of the device itself, while the disposable one is for the specifics regarding the tubing going through the pump. Anyone familiar with precision tools know how important a good calibration is. If the calibration is off it will lead to improper operations or results. From an operational standpoint this makes sense, but from an attacker perspective this has a strong likelihood of fitting the bill for the attack we had in mind: modifying an internal value so the pump thinks it is dispensing the right amount of drug, while it is actually incorrect in its calculations.

Looking at the variable names inside the disposable file and relevant code in the pump firmware led us to one that specifies the “head volume” of the tube. From our understanding, each time the pump pumps, it compresses the IV tubing thereby pushing a small quantity of drug towards the patient. Overall, there are many physical parameters that would govern this volume –the internal tube diameter, the length of the compressed region, how much the tube is being compressed, etc.—but in the end, it seemed that all these values were summed up in one variable. Cutting this value in half would make the pump believe it is pushing half the actual amount, and therefore would have to pump twice as fast to deliver it. We tried our hypothesis, and by doing so, the amount of drug dispensed doubled while the pump assumed everything was normal.

Operations in Hospitals and Consequences of Over-Infusing Drugs

Now that we have an idea of what happens to the device when we alter its internal configuration, we can consider how this could play out in the real world. As mentioned previously, medical staff are expected to be extra-careful when using these devices, ensuring the numbers match the doctor’s order. In the United States, both the Centers for Medicare and Medicaid Services (CMS) and the American Society of Clinical Oncology require standard of practice be followed with high risk or hazardous infusions like blood or chemotherapy. This standard requires two appropriately trained people (usually nurses), one who will be infusing the medication, and the other to verify the order and configuration prior to administration. Looking internationally, we were also  able to find this same protocol in use at an Irish hospital. It confirms the attention to detail and the requirement to double-check each value is correct. However, another document describing the adoption of a smart pump system in a Swedish hospital hints at concerns (p. 47) that invalid drug protocols might be followed if a nurse picked the wrong default settings on the pump. These documents are anecdotal, but the overall feeling is that strong checks are in place. Under pressure or with multiple infusions, mistakes can be made, which smart pumps should prevent.

One of our industry partners, Shaun Nordeck, M.D. is an Interventional Radiology Resident Physician at a Level 1 Trauma Center and prior, served as an Army Medic and Allied Health Professional. Leaning on more than 20 years in the medical field. Dr. Nordeck states “A high-pressure environment such as the ICU may be at increased risk for infusion errors since these critical and often medically complex patients have multiple infusions which are being adjusted frequently. Errors, however, are not limited to the ICU and may just as easily occur in the inpatient ward or outpatient settings. Essentially with each increase in variable (patient complexity or acuity, number of medications, rate changes, nurse to patient ratio, etc.) there is an increased risk for error.”

As a measure of safety, it is important to keep in mind that one can visually count the number of drops to verify the infusion rate (there’s even an optional module to do it automatically). However, depending on the parameters, a minor change of speed (e.g., halved or doubled) might not be immediately obvious but could still be deleterious. Dr. Nordeck further stated that “something as routine as correcting a person’s high blood sugar or sodium level too quickly can cause the brain to swell or damage the nerves which can lead to permanent disability or even death.” The FDA’s MAUDE database keeps track of adverse events involving medical devices and can be used to see what type of problems actually occurred in the field. Certain drugs are particularly potent, in which case the speed at which they are delivered matters. In this instance, an over-sedation at 4 times the intended rate led to the death of a patient a few hours after the incident occurred. Under-dosing can also be problematic as the required medication does not reach the patient in the appropriate quantity. These examples highlight that a pump not delivering the correct amount of drug occurs in the field and may remain unnoticed for multiple hours, which can lead to injury or death.

Common Pitfalls

Let’s now take a step back and consider some generic shortcomings that became apparent while looking at the infusion pump ecosystem. We believe these problems are not specific to a brand or a product but rather may be found across the entire medical field. This is because throughout the years, this vertical has only received a limited amount of attention from both malicious actors and the cybersecurity industry.  With the increased rate of cyber threats and the constant additions of new smart devices in private networks, new attack surfaces are being exposed and the hardening of many systems may turn into low hanging fruits for the ones lagging. The slower life cycle of smart medical devices means that best security practices and mitigations take longer to be adopted and deployed in the field. Awareness of this may help healthcare organizations, and their supporting IT administration have a more critical eye on the technology deployed in their environments while medical device vendors should remain vigilant of their “legacy” technologies and continually reassess the risk profile associated with legacy products in the current cybersecurity landscape.

Patching is Costly

Consumer products, both hardware and software are often nimbler than their counterparts in the medical industry. Your web-browser or operating system on your personal computer will auto-update immediately after a patch is released which come on a regular basis. This is radically different for medical devices which are often directly linked to patient safety and therefore need to undergo a more rigorous vetting process before applying updates. This often leads to the need to immobilize devices during updates, perform follow up tests and recalibrations. It is often very expensive and challenging for medical facilities to update products, resulting in deployed devices with firmware that is several years old. Because of this, “table stakes” security measures may never be fully adopted, and corresponding vulnerabilities may have a larger impact than in other industries.

Designed for Safety Rather than Security

When looking at the general architecture of the pump, it is obvious that it was designed with safety in mind. For instance, it relies on an application processor for the main processing but also has a control processor that makes sure nothing unexpected occurs by monitoring sensors output along with other components. Everything is CRC checked multiple times to flag memory corruption and every range is bounds-checked. All of this suggests that the design was intended to mitigate hardware and software faults, data accidentally being corrupted over the wire, and the flash module degrading which aligns with a high priority on safety.

However, it looks like preventing malicious intent was not given as much attention during the design process. Sometimes the difference between safety and security might be a little blurry. Preventing accidental memory corruption and out of bounds access due to faulty hardware will also make exploitation harder, yet an attacker will always attempt to escape these mitigations. Along the same lines, logic bugs that would be extremely unlikely to occur by chance might be the “keys to the kingdom” for an attacker. Internal audits and offensive security exercises can highlight the attacker mindset and bring valuable insights as how to harden existing safeguards to protect against intentional threats.

Everything is Trusted

When looking at how the pump and its communication module handles communication and file handling, we observed that critical files are not signed (CVE-2021-33885), most of the data exchanges are done in plain-text (CVE-2021-33883), and there is an overall lack of authentication (CVE-2021-33882) for the proprietary protocols being used. There are a few password-protected areas for user facing systems, but not as many for the behind-the-scenes internal systems. This might be because a login page on a website is an “obvious” necessity, along with having a proper authentication mechanism for FTP and SSH, while ad-hoc protocols designed more customized uses are not as obvious. There is also an evolving landscape at play and its related threat assessment; the risk of an unauthorized person tampering with a configuration file (calibration data, drug library, etc.) is fairly low if it also requires dedicated software and physical access to the device. However, if suddenly the device becomes network-connected, the attack surface is extended and the original assumptions may not be refreshed. Defense-in-depth would dictate that in any case, important files should not be easy to tamper with. However, security vs functionality comes with legitimate compromises and when it comes to embedded devices, limited resources and usability also need to be factored into the equation.

CAN gets Connected to WIFI

Originally, the CAN bus was reserved for communication between trusted components such as a Servicing PC used for maintenance or for connecting multiples devices within an older model of the Space Station that did not have SpaceCom built in. The latter would come as an optional module that could be plugged into the Space Station to offer external connectivity. Hence, the CAN bus was used for “internal” communication between trusted components and an external module, the SpaceCom, could be added for data reporting over the network. Over the following decade, technology improved and miniaturized to the point where everything got merged, so that even a battery module could provide WIFI connectivity and the SpaceCom functionalities. This opened new possibilities, such as having the built-in SpaceCom module provide similar capabilities as the servicing PC. From a user perspective this is great as it simplifies operations, but from a security perspective, this created a situation where a “trusted” internal network suddenly became bridged to an external network that could even be accessed wirelessly. What might have been an acceptable risk, where only a few proprietary devices with physical access could perform privileged operations, became much more questionable when a WIFI-connected Linux device started to offer the same capabilities.

This kind of problem has been faced by nearly every industry vertical that evolved from reliance on trusted physical networks which suddenly got connected to the internet or other untrusted networks. Smart connected devices are a double-edged sword: in the same way they offer greater flexibility and synergy between systems, they can also lead to emergent security issues that need to be considered holistically.

Technical Debt

When developing custom protocols and ad-hoc systems it’s natural to incur technical debt. This is even more true when the life cycle of a device is many years and when it is complicated and expensive to deploy patches and upgrades, leading to a heterogeneous customer base and multiple hardware revisions to support. This can cause situations where more obscure features are not looked at for years and their ownership might be lost or perfunctory. An example of this is the format string vulnerability affecting the json-dbus module. Its usage is obscure, and it was forked from an open-source project many years ago. The original repository fixed bugs that were security bugs but were not flagged as such which led them to fly under the radar for multiple years. Likely, at the time it was forked, the code served its purpose and was never revisited afterwards, leaving the security bug unnoticed. The same can be said for custom-designed protocols and file formats. It may be difficult to evolve them in line with the improvement of best security practices while avoiding breaking “legacy” deployments. In this scenario, mitigations might be the way to go; making sure the systems are isolated, unnecessary features can be disabled and their privilege and access limited to what’s needed. Future-proofing a system is a difficult challenge. If anything, transparency on how the system functions and the components it relies on, coupled with regular audits (code source review or black box audit) can help prevent components from falling in the cracks where they’re not checked against best practices for many years.

Conclusion

This concludes a research project which took two senior researchers a significant amount of time to showcase a life-threatening risk of a medical device being taken over by a remote attacker. For the time being, ransomware attacks are a more likely threat in the medical sector, but eventually these networks will be hardened against this type of attacks and malicious actors will look for other lower-hanging fruits. Given the lifespan of medical devices and the difficulties surrounding their updates, it is important to start planning now for tomorrow’s threats. We hope this research will help bring awareness to an area that has been a blind spot for far too long. Dr. Nordeck affirms the importance of this research stating: “The ability to manipulate medical equipment in a way that is potentially harmful to patients, without end-user detection, is effectively weaponizing the device and something only previously conceived by Hollywood yet, McAfee’s ATR team has confirmed is plausible. Device manufactures clearly aim to produce safe and secure products as evidenced by built-in safeguards. However, flaws may exist which allow the device to succumb to a ransom attack or potentially cause harm. Therefore, manufactures should collaborate with security professionals to independently test their products to detect and correct potential threats and thereby preserve patient safety and device security.”

Performing regular security audits, making it easier for medical professionals to keep their devices up to date and offering solid mitigations when this is not possible should really be on every medical vendor’s list of priorities. Medical professionals, policy makers and even the general public should also hold accountable the medical vendors and have them clearly articulate the risk profile of the devices they sell and demand better ways to keep their device secure. We recognize even with this mindset and a holistic approach to security, there will always be flaws that cannot be predetermined. In these cases, vendors should encourage and even seek out industry partners, embrace responsible disclosure and communicate broadly with researchers, stakeholders and customers alike.

From a security research perspective, it is crucial to understand how a device works at a holistic system level, and how each component interacts with each other, which components they can talk to, and so on. For manufacturers, it is important to read between the lines; something may not be in a design document or in the specifications, but sometimes emergent properties will occur as a side-effect of other design decisions.

An offensive project like ours is really meant to highlight structural weaknesses and point out risks. Now, defensive work is necessary to address these concerns. For instance, manufacturers should leverage cheaper and more powerful microcontrollers to implement proper authentication mechanisms. However, it is even more important to study and address the challenges hospitals face when it comes to keeping their devices up to date. This should come as both technical solutions from the vendors and advocacy to promote secure practices and raise awareness on the underlying risks associated with critical devices having outdated software. The FDA tried to lead the way in 2018 with its CyberMed Safety (Expert) Analysis Board (CYMSAB), but so far little progress has been made. The work the German BSI did with the ManiMed project is also extremely encouraging. We see this as an area of cybersecurity with lots of potential and need for attention and look forward to the information security industry taking on this challenge to make this critical sector always more secure.

One goal of the McAfee Advanced Threat Research team is to identify and illuminate a broad spectrum of threats in today’s complex and constantly evolving landscape. As per McAfee’s vulnerability public disclosure policy, McAfee’s ATR team informed and worked directly with the B.Braun team. This partnership resulted in the vendor working towards effective mitigations of the vulnerabilities detailed in this blog. We strongly recommend any businesses using the B.Braun Infusomat devices to update as soon as possible in line with your patch policy and testing strategy.

CVE Details

CVE: CVE-2021-33882

CVSSv3 Rating: 6.8/8.2

CVSS String: AV:N/AC:H/PR:N/UI:N/ S:C/C:N/I:H/A:N/CR:H/IR:H/AR:M/MAV:A

CVE Description: Missing Authentication for Critical Function vulnerability in BBraun SpaceCom2 prior to 012U000062 allows a remote attacker to reconfigure the device from an unknown source through lack of authentication on proprietary networking commands.

CVE: CVE-2021-33883

CVSSv3 Rating: 5.9/7.1

CVSS String: AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N/CR:H/IR:H/AR:M/MAV:A

CVE Description: Cleartext Transmission of Sensitive Information vulnerability in BBraun SpaceCom2 prior to 012U000062 allows a remote attacker to obtain sensitive information by snooping the network traffic.  The exposed data includes critical values for the pumps internal configuration.

CVE: CVE-2021-33884

CVSSv3 Rating: 7.3/5.8

CVSS String: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L/CR:M/IR:M/AR:L/MAV:A

CVE Description: Unrestricted Upload of File with Dangerous Type vulnerability in BBraun SpaceCom2 prior to 012U000062 allows remote attackers to upload any files to the /tmp directory of the device through the webpage API.  This can result in critical files being overwritten.

CVE: CVE-2021-33885

CVSSv3 Rating: 10.0/9.7

CVSS String: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N/CR:H/IR:H/AR:M/MAV:A

CVE Description: Insufficient Verification of Data Authenticity vulnerability in BBraun SpaceCom2 prior to 012U000062 allows a remote unauthenticated attacker to send malicious data to the device which will be used in place of the correct data.  This results in execution through lack of cryptographic signatures on critical data sets

CVE: CVE-2021-33886

CVSSv3 Rating: 8.1/7.7

CVSS String: AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N/RL:O/RC:C

CVE Description: Improper sanitization of input vulnerability in BBraun SpaceCom2 prior to 012U000062 allows a remote unauthenticated attacker to gain user level command line access through passing a raw external string straight through to printf statements.  The attacker is required to be on the same network as the device.

The post McAfee Enterprise ATR Uncovers Vulnerabilities in Globally Used B. Braun Infusion Pump appeared first on McAfee Blog.

Critical RDP Vulnerabilities Continue to Proliferate

This month’s Patch Tuesday brings us a relatively small number of CVEs being patched, but an abnormally high percentage of noteworthy critical vulnerabilities.

Vulnerability Analysis: CVE-2021-34535

One such vulnerability is identified as CVE-2021-34535, which is a remote code execution flaw in the Remote Desktop client software, observed in mstscax.dll, which is used by Microsoft’s built-in RDP client (mstsc.exe). The vulnerability is very closely related to a bug released in July of 2020, CVE-2020-1374, which also came through Microsoft’s Patch Tuesday process and had highly similar characteristics. The vulnerability is an integer overflow due to an attacker-controllable payload size field, which ultimately leads to a heap buffer overflow during memory allocation. The vulnerability can be triggered via the RDP Video Redirection Virtual Channel Extension feature [MS-RDPEV], which is typically deployed on port 3389, and is contained inside of compressed UDP payload and encrypted RDP using TLS.

But does this flaw, despite its impressive 9.9 CVSS score, rise to the level of past RDP vulnerabilities, including the infamous BlueKeep (CVE-2019-0708)? Not so fast – there are a few additional factors to take into consideration.

Attack Scenario

First and foremost, this is a client-side vulnerability, meaning there is no real ability for self-propagation, or “wormability” from an Internet perspective. The most likely attack scenario would be to convince a user to authenticate to a malicious RDP server, where the server could trigger the bug on the client side. During reproduction of the issue, we were able to easily trigger the crash and observe a later memcpy using the controlled overflow, which should facilitate exploitation. We think it is likely that exploits will be developed for this vulnerability but the availability of a patch prior to any known public exploitation helps to mitigate risks for organizations and individuals.

Secondly, thanks to the widespread proliferation and reach of BlueKeep and other related RDP vulnerabilities, a significant portion of RDP clients and servers have been disabled or moved from the network perimeter. This is less important given the client-side nature of the bug but does help with the overall attack surface.

In addition to Microsoft’s built-in RDP client (mstsc.exe), which is the more common Remote Desktop network connection, we have also confirmed that some lesser- known RDP vectors are affected by this vulnerability. Microsoft Hyper-V Manager “Enhanced Session Mode” and Microsoft Defender’s Application Guard (WDAG) both use RDP to screen share and present the secured browser respectively. This gives the end user a remote view of their isolated instance in the context of the host system. Rather than reimplementing the RDP session sharing capability, Microsoft ported the existing RDP client code base into Hyper-V and WDAG. Since the RDP client code is self-contained in mstscax.dll (an ActiveX COM object) it can simply be loaded into the Hyper-V (vmconnect.exe) and WDAG (hvsirdpclient.exe) processes to avail of the RDP client functionality. There does not appear to have been any attack surface reduction on this code base as the same DLL is loaded within all three processes mstsc.exe, vmconnect.exe and hvsirdpclient.exe. The impacted components are:

• Microsoft’s built-in RDP client mstsc.exe uses the vulnerable mstscax.dll when a client remotely connects to an RDP server over the network. We have confirmed mstsc.exe crashes and the vulnerability can be triggered then the client has authenticated to an RDP server.

Mitigation: Patch

• Microsoft’s Hyper-V Manager software also uses mstscax.dll where the vulnerable function resides. When using “Enhanced Session Mode” (enabled by default in Hyper-V Manager), the process vmconnect.exe loads mstscax.dll. We have confirmed through testing that triggering the vulnerability from inside a Hyper-V Windows 10 image will crash vmconnect.exe on the host. This means that it is subject to guest-to-host escapes using the vulnerability. (Hyper-V is disabled by Default on Windows 10).

Mitigation: Patch or disable “Enhanced Session Mode”

• Microsoft Defender’s Application Guard also uses mstscax.dll to present the user with a view of their containerized Edge and IE browser. When a “New Application Guard window” is navigated from Edge it launches the process hvsirdpclient.exe which loads mstscax.dll. We have not confirmed the WDAG process hvsirdpclient.exe crashes but it does use the same code base so we recommend patching if using WDAG (WDAG is disabled by Default on Windows 10).

Looking Forward

The built-in RDP client and Hyper-V/WDAG clients communicate over different transport mediums in the form of TCP/IP and VMBus but they both use the same RDP client protocol implementation. Given that the flaw is contained within mstscax.dll, and is self-contained, the vulnerability was ported to these two implementations along with the rest of the code base.

While the urgency for patching remains somewhat lower than past critical vulnerabilities, threat actors will look to weaponize any of these low-hanging fruit that leverage common network protocols. Patching should be a top priority, and furthermore, a comprehensive and ongoing review of internet-facing and internal networked RDP clients and servers would be highly recommended. Eliminating or reducing the attack surface is one of the best counter attacks to vulnerability exploitation.

Microsoft have published a Knowledge Base article for the issue here with corresponding patch information. In the meantime, we are continuing to monitor this vulnerability closely; if exploitation is observed we may release additional content for customers.

For RDP security best practices please see https://www.mcafee.com/blogs/other-blogs/mcafee-labs/rdp-security-explained/

 

With thanks to Cedric Cochin, McAfee.

The post Critical RDP Vulnerabilities Continue to Proliferate appeared first on McAfee Blogs.

See Ya Sharp: A Loader’s Tale

Introduction

The DotNet based CyaX-Sharp loader, also known as ReZer0, is known to spread commodity malware, such as AgentTesla. In recent years, this loader has been referenced numerous times, as it was used in campaigns across the globe. The tale of CyaX-Sharp is interesting, as the takeaways provide insight into the way actors prefer to use the loader. Additionally, it shines a light onto a spot that is not often illuminated: the inner workings of loaders.

This blog is split up into several segments, starting with a brief preface regarding the coverage of loaders in reports. After that, the origin of the loader’s name is explored. Next, the loader’s capabilities are discussed, as well as the automatic extraction of the embedded payload from the loader. Lastly, the bulk analysis of 513 unique loader samples is discussed.

Loaders and their Coverage in Blogs

To conceal the malware, actors often use a loader. The purpose of a loader is, as its name implies, to load and launch its payload, thereby starting the next stage in the process. There can be multiple loaders that are executed sequentially, much like a Russian Matryoshka doll in which the smallest doll, which is hidden inside numerous others, is the final payload. The “smallest doll” generally contains the malware’s main capabilities, such as stealing credentials, encrypting files, or providing remote access to the actor.

While there is a lot of research into the actions of the final payload, the earlier stages are just as interesting and relevant. Even though the earlier stages do not contain the capabilities of the malware that is eventually loaded, they provide insight as to what steps are taken to conceal the malware. Blogs generally mention the capabilities of a loader briefly, if at all. The downside here lies in the potential detection rules that others can create with the blog, as the focus is on the final step in the process, whereas the detection should start as soon as possible.

Per best security practices, organizations should protect themselves at every step along the way, rather than only focusing on the outside perimeter. These threat models are often referred to as the, respectively, onion and egg model. The egg’s hard shell is tough to break, but once inside, an attacker has free roam. The onion model opposes the attacker every step of the way, due to its layered approach. Knowing the behavior of the final payload is helpful to detect and block malware although, ideally, the malware would be detected as early on as possible.

This blog focuses on one specific loader family, but the takeaways are valid in a broader sense. The preferred configurations of the actors are useful to understand how loaders can be used in a variety of attacks.

Confusing Family Names

A recent blog by G Data’s Karsten Hahn provides a more in-depth look into malware families ambiguous naming schemes. This loader’s name is also ambiguous, as it is known by several names. Samples are often named based on distinctive characteristics in them. The name CyaX-Sharp is based upon the recurring string in samples. This is, however, exactly why it was also named ReZer0.

When looking at the most used names within the 513 obtained samples, 92 use CyaX-Sharp, whereas 215 use ReZer0. This would make it likely that the loader would be dubbed ReZer0, rather than CyaX-Sharp. However, when looking at the sample names over time, as can be seen in the graph below, the reason why CyaX-Sharp was chosen becomes apparent: the name ReZer0 was only introduced 8 months after the first CyaX-Sharp sample was discovered. Based on this, McAfee refers to this loader as CyaX-Sharp.

Within the settings, one will find V2 or V4. This is not a reference of the loader’s version, but rather the targeted DotNet Framework version. Within the sample set, 62% of the samples are compiled to run on V4, leaving 38% to run on V2.

The Loader’s Capabilities

Each version of the loader contains all core capabilities, which may or may not be executed during runtime, based on the loader’s configuration. The raw configurations are stored in a string, using two pipes as the delimiting value. The string is then converted into a string array using said delimiter. Based on the values at specific indices, certain capabilities are enabled. The screenshots below show, respectively, the raw configuration value, and some of the used indices in a sample (SHA-256: a15be1bd758d3cb61928ced6cdb1b9fa39643d2db272909037d5426748f3e7a4).

The loader can delay its execution by sleeping for a certain number of seconds, use a mutex to ensure it is not already running, display a message box with a custom message, persist itself as a scheduled task, and/or execute a given payload in several ways. The payload can be downloaded from an external location, after which it is started. Alternatively, or additionally, the embedded payload within the loader can be launched. This can be done directly from the loader’s memory with the help of reflective calls, or by hollowing a newly created process. The flowchart below visualizes the process. Note that the dotted line means the linked step can be skipped, depending on the loader’s configuration.

Process Hollowing

The newly created process is one of the following: MSBuild.exe, vbc.exe, RegSvcs.exe, or a new instance of the loader. The process hollowing code segment seems to be taken from NYAN-x-CAT’s GitHub, as the for-loop to start the process hollowing method is present in both the loader and the linked repository. The way an error is handled is not a standardized method, making the link between the publicly available code very likely. The first image below shows the original code from the repository, whereas the second image shows the code from the loader (SHA-256: a15be1bd758d3cb61928ced6cdb1b9fa39643d2db272909037d5426748f3e7a4)

The loop calls the process hollowing function several times to more easily handle exceptions. In the case of an exception during the process hollowing, the targeted process is killed and the function returns. To try several times, a loop is used.

Changes Over Time

Even though the loader has changed over time, it maintained the same core structure. Later versions introduced minor changes to existing features. Below, different loader versions will be described, where the length of the string array that contains the loader’s configuration is used to identify different versions. The graph shows the rise and fall for each of the versions.

There are two notable differences in versions where the config array’s size is larger than 29. Some specific samples have slightly different code when compared with others, but I did not consider these differences sizable enough to warrant a new version.

Firstly, the ability to enable or disable the delayed execution of a sample. If enabled, the execution is delayed by sleeping for a predefined number of seconds. In config_29, the delay functionality is always enabled. The duration of the delay is based on the System.Random object, which is instantiated using the default seed. The given lower and upper limits are 45,000 and 60,000, resulting in a value between these limits, which equals in the number of milliseconds the execution should be delayed.

Secondly, the feature to display a custom message in a prompt has been added. The config file contains the message box’ title, text, button style, and icon style. Prompts can be used to display a fake error message to the victim, which will appear to be legitimate e.g.  43d334c125968f73b71f3e9f15f96911a94e590c80955e0612a297c4a792ca07, which uses “You do not have the proper software to view this document” as its message.

Payload and Configuration Extraction

To automatically extract the payload and configuration of a given loader, one can recreate the decryption mechanism in a language of choice, get the encrypted data from the loader, and decrypt it. The downside here is the need for an exact copy of the decryption mechanism. If the key were to change, or a slightly different algorithm were to be used, the copy would also need to reflect those changes. To avoid dealing with the decryption method, a different approach can be taken.

This loader mistakenly uses static variables to store the decrypted payload and configuration in. In short, these variables are initialized prior to the execution of the main function of the loader. As such, it is possible to reflectively obtain the value of the two variables in question. A detailed how-to guide can be found on my personal website. The data that was extracted from the 513 samples in the set is discussed in the next section.

Bulk Analysis Results

The complete set consists of 513 samples, all of which were found using a single Yara rule. The rule focuses on the embedded resource which is used to persist the loader as a scheduled task on the victim’s system. In some cases, the Yara rule will not match a sample, as the embedded resource is obfuscated using ConfuserEx (one example being SHA-256 0427ebb4d26dfc456351aab28040a244c883077145b7b529b93621636663a812). To deobfuscate, one can use ViRb3’s de4dot-cex fork of de4dot. The Yara rule will match with the deobfuscated binary. The graph below shows the number of unique samples over time.

The dates are based on VirusTotal’s first seen date. Granted, this date does not need to represent the day the malware was first distributed. However, when talking about commodity malware that is distributed in bulk, the date is reliable enough.

The sample set that was used is smaller than the total amount of loaders that have been used in the wild. This loader is often not the first stage, but rather an in-memory stage launched by another loader. Practically, the sample set is sizable enough for this research, but it should be noted that there are more unique loader samples in the wild for the given date range than are used in this report.

It is useful to know what the capabilities of a single sample are, but the main area of interest of this research is based upon the analysis of all samples in the set. Several features will be discussed, along with thoughts on them. In this section, all percentages refer to the total of 513 unless otherwise specified.

Widespread Usage

The loader’s usage is widespread, without a direct correlation towards a specific group or geographical region. Even though some reports mention a specific actor using or creating this loader, the fact that at least one builder has leaked makes attribution to one or more actors difficult. Coupled with the wide variety of targeted industries, as well as the broad geographic targeted areas, it looks like several actors utilise this loader. The goal of this research is not to dig into the actors who utilise this loader, but rather to look at the sample set in general. Appendix A provides a non-exhaustive list of public articles that (at least) mention this loader, in descending chronological order.

Execution Methods

The two options to launch a payload, either reflectively or via process hollowing, are widely apart in usage: 90% of all loaders uses process hollowing, whereas only 10% of the samples are launched via reflection. Older versions of the loader sometimes used to reflectively load a decrypted stager from the loader’s resources, which would then launch the loader’s payload via process hollowing. The metrics below do not reflect this, meaning the actual percentage of direct launches might be slightly lower than is currently stated. The details can be viewed in the graph below.

Note that the reflective loading mechanism will default to the process hollowing of a new instance of the loader if any exception is thrown. Only DotNet based files can be loaded reflectively, meaning that other files that are executed this way will be loaded using a hollowed instance of the loader.

Persistence and Mutexes

The persistence method, which uses a scheduled task to start the loader once the computer boots, is used by 54% of the loaders. This does not mean that the other 46% of the samples are not persisted on the victim’s machine, as a different stage could provide persistence as well. Notable is the date within the scheduled task, which equals 2014-10-25T14:27:44.8929027. This date is, at the time of writing, nearly 2500 days ago. If any of the systems in an organization encounter a scheduled task with this exact date, it is wise to verify its origin, as well as the executable that it points to.

A third of all loaders are configured to avoid running when an instance is already active using a mutex. Similar to the persistence mechanism, a mutex could be present in a different stage, though this is not necessarily the case. The observed mutexes seem to consist of only unaccented alphabetical letters, or [a-zA-Z]+ when written as a regular expression.

Delayed Execution

Delayed execution is used by nearly 37% of the samples, roughly half of which are config_29, meaning this setting was not configurable when creating the sample. The samples where the delayed execution was configurable, equal nearly 19% of the total. On average, a 4 second delay is used. The highest observed delay is 600 seconds. The graph below shows the duration of the delay, and the frequency.

Note that one loader was configured to have a delay of 0 seconds, essentially not delaying the execution. In most cases, the delayed time is a value that can be divided by five, which is often seen as a round number by humans.

Environmental Awareness

Prior to launching the payload, the loader can perform several checks. A virtual environment can be detected, as well as a sandbox. Roughly 10% of the samples check for the presence of a virtual machine, whereas roughly 11% check if it is executed in a sandbox. Roughly 8% of the 513 samples check for the presence of both, prior to continuing their execution. In other words, 88% of the samples that try to detect a virtual machine, also attempted to detect a sandbox. Vice versa, 74% of the samples that attempted to detect the sandbox, attempted to detect if they were executed on a virtual machine.

The option to disable Windows Defender was mainly present in the earlier samples, which is why only 15% of the set attempts to disable it.

Payload Families

The loader’s final goal is to execute the next stage on the victim’s machine. Knowing what kind of malware families are often dropped can help to find the biggest pain points in your organization’s additional defensive measures. The chart below provides insight into the families that were observed the most. The segment named other contains all samples that would otherwise clutter the overview due to the few occurrences per family, such as the RedLine stealer, Azorult, or the lesser known MrFireMan keylogger.

The percentages in the graph are based on 447 total payloads, as 66 payloads were duplicates. In other words, 66 of the unique loaders dropped a non-unique payload. Of all families, AgentTesla is the most notable, both in terms of frequency and in terms of duplicate count. Of the 66 duplicates, 48 were related to AgentTesla.

Barely Utilized Capabilities

Two functions of the loader that are barely used are the message box and the download of a remote payload. The usage of both is, respectively, 1.3% and 0.8%. All of the remote payloads also contained an embedded payload, although one of the four remotely fetching loaders does not contain a URL to download the remote payload from. The external file can be used as an additional module for a next stage, a separate malicious payload, or it can be used to disable certain defense mechanisms on the victim’s device.

Conclusion

Companies using the aforementioned onion security model benefit greatly from the dissection of such a loader, as their internal detection rules can be improved with the provided details. This stops the malware’s execution in its tracks, as is shown in the sequential diagram of McAfee’s detection below.

The techniques that this loader uses are commonly abused, meaning that the detection of a technique such as process hollowing will also prevent the successful execution of numerous other malware families. McAfee’s Endpoint Security (ENS) and Endpoint Detection & Response (EDR) detect the CyaX-Sharp loader every step of the way, including the common techniques it uses. As such, customers are protected against a multitude of families based on a program’s heuristics.

Appendix A – Mentions of CyaX-Sharp and ReZer0

Below, a non-exhaustive chronologically descending list of relevant articles is given. Some articles contain information on the targeted industries and/or target geographical area.

• On the 12^th of January 2021, ESET mentioned the loader in its Operation Spalax blog
• On the 7^th of December 2020, ProofPoint wrote about the decryption mechanisms of several known .NET based packers
• On the 5^th of November 2020, Morphisec mentioned a packer that looks a lot like this loader
• On the 6^th of October 2020, G Data mentioned the packer (or a modified version)
• On the 29^th of September 2020, ZScaler mentioned the packer
• On the 17^th of September 2020, I wrote about the automatic payload and config extraction of the loader
• On the 16^th of September 2020, the Taiwanese CERT mentioned the loader in a digital COVID-19 threat case study
• On the 23^rd of July 2020, ClamAV mentioned the loader in a blog
• On the 14^th of May 2020, Security firm 360TotalSecurity links the loader to the threat actor Vendetta
• On the 21^st of April 2020, Fortinet provided insight into the loader’s inner workings
• On the 1^st of March 2020, RVSEC0N mentioned the loader
• On the 4^th of December 2019, Trend Micro provided a backstory to CyaX-Sharp
• On the 22^nd of March 2019, 360TotalSecurity gave insight into some of the loader’s features

Appendix B – Hashes

The hashes that are mentioned in this blog are listed below, in order of occurrence. The SHA-1 and SSDeep hashes are also included. A full list of hashes for all 513 samples and their payloads can be found here.

Sample 1

SHA-256: a15be1bd758d3cb61928ced6cdb1b9fa39643d2db272909037d5426748f3e7a4

SHA-1: 14b1a50c94c2751901f0584ec9953277c91c8fff

SSDeep: 12288:sT2BzlxlBrB7d1THL1KEZ0M4p+b6m0yn1MX8Xs1ax+XdjD3ka:O2zBrB7dlHxv0M4p+b50yn6MXsSovUa

Sample 2

SHA-256: 43d334c125968f73b71f3e9f15f96911a94e590c80955e0612a297c4a792ca07

SHA-1: d6dae3588a2a6ff124f693d9e23393c1c6bcef05

SSDeep: 24576:EyOxMKD09DLjhXKCfJIS7fGVZsjUDoX4h/Xh6EkRlVMd3P4eEL8PrZzgo0AqKx/6:EyycPJvTGVijUDlhfEEIUvEL8PrZx0AQ

Sample 3

SHA-256: 0427ebb4d26dfc456351aab28040a244c883077145b7b529b93621636663a812

SHA-1: 8d0bfb0026505e551a1d9e7409d01f42e7c8bf40

SSDeep: 12288:pOIcEfbJ4Fg9ELYTd24xkODnya1QFHWV5zSVPjgXSGHmI:EEj9E/va

 

The post See Ya Sharp: A Loader’s Tale appeared first on McAfee Blogs.