Glupteba Botnet Evades Detection with Undocumented UEFI Bootkit

The Glupteba botnet has been found to incorporate a previously undocumented Unified Extensible Firmware Interface (UEFI) bootkit feature, adding another layer of sophistication and stealth to the malware. "This bootkit can intervene and control the [operating system] boot process, enabling Glupteba to hide itself and create a stealthy persistence that can be extremely difficult to

DirtyMoe Malware Infects 2,000+ Ukrainian Computers for DDoS and Cryptojacking

The Computer Emergency Response Team of Ukraine (CERT-UA) has warned that more than 2,000 computers in the country have been infected by a strain of malware called DirtyMoe. The agency attributed the campaign to a threat actor it calls UAC-0027. DirtyMoe, active since at least 2016, is capable of carrying out cryptojacking and distributed denial-of-service (DDoS) attacks. In March

Cryptominers Targeting Misconfigured Apache Hadoop and Flink with Rootkit in New Attacks

Cybersecurity researchers have identified a new attack that exploits misconfigurations in Apache Hadoop and Flink to deploy cryptocurrency miners within targeted environments. "This attack is particularly intriguing due to the attacker's use of packers and rootkits to conceal the malware," Aqua security researchers Nitzan Yaakov and Assaf Morag said in an analysis published earlier

New Stealthy 'Krasue' Linux Trojan Targeting Telecom Firms in Thailand

A previously unknown Linux remote access trojan called Krasue has been observed targeting telecom companies in Thailand by threat actors to main covert access to victim networks at lease since 2021. Named after a nocturnal female spirit of Southeast Asian folklore, the malware is "able to conceal its own presence during the initialization phase," Group-IB said in a report

Kinsing Hackers Exploit Apache ActiveMQ Vulnerability to Deploy Linux Rootkits

The Kinsing threat actors are actively exploiting a critical security flaw in vulnerable Apache ActiveMQ servers to infect Linux systems with cryptocurrency miners and rootkits. "Once Kinsing infects a system, it deploys a cryptocurrency mining script that exploits the host's resources to mine cryptocurrencies like Bitcoin, resulting in significant damage to the infrastructure and a negative

Qubitstrike Targets Jupyter Notebooks with Crypto Mining and Rootkit Campaign

A threat actor, presumably from Tunisia, has been linked to a new campaign targeting exposed Jupyter Notebooks in a two-fold attempt to illicitly mine cryptocurrency and breach cloud environments. Dubbed Qubitstrike by Cado, the intrusion set utilizes Telegram API to exfiltrate cloud service provider credentials following a successful compromise. "The payloads for the Qubitstrike campaign are

Rogue npm Package Deploys Open-Source Rootkit in New Supply Chain Attack

A new deceptive package hidden within the npm package registry has been uncovered deploying an open-source rootkit called r77, marking the first time a rogue package has delivered rootkit functionality. The package in question is node-hide-console-windows, which mimics the legitimate npm package node-hide-console-window in what's an instance of a typosquatting campaign. It was downloaded 704

Reptile Rootkit: Advanced Linux Malware Targeting South Korean Systems

Threat actors are using an open-source rootkit called Reptile to target Linux systems in South Korea. "Unlike other rootkit malware that typically only provide concealment capabilities, Reptile goes a step further by offering a reverse shell, allowing threat actors to easily take control of systems," the AhnLab Security Emergency Response Center (ASEC) said in a report published this week. "Port

Chinese Hackers Deploy Microsoft-Signed Rootkit to Target Gaming Sector

Cybersecurity researchers have unearthed a novel rootkit signed by Microsoft that's engineered to communicate with an actor-controlled attack infrastructure. Trend Micro has attributed the activity cluster to the same actor that was previously identified as behind the FiveSys rootkit, which came to light in October 2021. "This malicious actor originates from China and their main victims are the

CopperStealer Malware Crew Resurfaces with New Rootkit and Phishing Kit Modules

The threat actors behind the CopperStealer malware resurfaced with two new campaigns in March and April 2023 that are designed to deliver two novel payloads dubbed CopperStealth and CopperPhish. Trend Micro is tracking the financially motivated group under the name Water Orthrus. The adversary is also assessed to be behind another campaign known as Scranos, which was detailed by Bitdefender in

Adding ZONEMD Protections to the Root Zone

The Domain Name System (DNS) root zone will soon be getting a new record type, called ZONEMD, to further ensure the security, stability, and resiliency of the global DNS in the face of emerging new approaches to DNS operation. While this change will be unnoticeable for the vast majority of DNS operators (such as registrars, internet service providers, and organizations), it provides a valuable additional layer of cryptographic security to ensure the reliability of root zone data.

In this blog, we’ll discuss these new proposals, as well as ZONEMD. We’ll share deployment plans, how they may affect certain users, and what DNS operators need to be aware of beforehand to ensure little-to-no disruptions.

The Root Server System

The DNS root zone is the starting point for most domain name lookups on the internet. The root zone contains delegations to nearly 1,500 top-level domains, such as .com, .net, .org, and many others. Since its inception in 1984, various organizations known collectively as the Root Server Operators have provided the service for what we now call the Root Server System (RSS). In this system, a myriad of servers respond to approximately 80 billion root zone queries each day.

While the RSS continues to perform this function with a high degree of dependability, there are recent proposals to use the root zone in a slightly different way. These proposals create some efficiencies for DNS operators, but they also introduce new challenges.

New Proposals

In 2020, the Internet Engineering Task Force (IETF) published RFC 8806, titled “Running a Root Server Local to a Resolver.” Along the same lines, in 2021 the Internet Corporation for Assigned Names and Numbers (ICANN) Office of the Chief Technology Officer published OCTO-027, titled “Hyperlocal Root Zone Technical Analysis.” Both proposals share the idea that recursive name servers can receive and load the entire root zone locally and respond to root zone queries directly.

But in a scenario where the entire root zone is made available to millions of recursive name servers, a new question arises: how can consumers of zone data verify that zone content has not been modified before reaching their systems?

One might imagine that DNS Security Extensions (DNSSEC) could help. However, while the root zone is indeed signed with DNSSEC, most of the records in the zone are considered non-authoritative (i.e., all the NS and glue records) and therefore do not have signatures. What about something like a Pretty Good Privacy (PGP) signature on the root zone file? That comes with its own challenge: in PGP, the detached signature is easily separated from the data. For example, there is no way to include a PGP signature over DNS zone transfer, and there is no easy way to know which version of the zone goes with the signature.

Introducing ZONEMD

A solution to this problem comes from RFC 8976. Led by Verisign and titled “Message Digest for DNS Zones” (known colloquially as ZONEMD), this protocol calls for a cryptographic digest of the zone data to be embedded into the zone itself. This ZONEMD record can then be signed and verified by consumers of the zone data. Here’s how it works:

Each time a zone is updated, the publisher calculates the ZONEMD record by sorting and canonicalizing all the records in the zone and providing them as input to a message digest function. Sorting and canonicalization are the same as for DNSSEC. In fact, the ZONEMD calculation can be performed at the same time the zone is signed. Digest calculation necessarily excludes the ZONEMD record itself, so the final step is to update the ZONEMD record and its signatures.

A recipient of a zone that includes a ZONEMD record repeats the same calculation and compares its calculated digest value with the published digest. If the zone is signed, then the recipient can also validate the correctness of the published digest. In this way, recipients can verify the authenticity of zone data before using it.

A number of open-source DNS software products now, or soon will, include support for ZONEMD verification. These include Unbound (version 1.13.2), NSD (version 4.3.4), Knot DNS (version 3.1.0), PowerDNS Recursor (version 4.7.0) and BIND (version 9.19).

Who Is Affected?

Verisign, ICANN, and the Root Server Operators are taking steps to ensure that the addition of the ZONEMD record in no way impacts the ability of the root server system to receive zone updates and to respond to queries. As a result, most internet users are not affected by this change.

Anyone using RFC 8806, or a similar technique to load root zone data into their local resolver, is unlikely to be affected as well. Software products that implement those features should be able to fully process a zone that includes the new record type, especially for reasons described below. Once the record has been added, users can take advantage of ZONEMD verification to ensure root zone data is authentic.

Users most likely to be affected are those that receive root zone data from the internic.net servers (or some other source) and use custom software to parse the zone file. Depending on how such custom software is designed, there is a possibility that it will treat the new ZONEMD record as unexpected and lead to an error condition. Key objectives of this blog post are to raise awareness of this change, provide ample time to address software issues, and minimize the likelihood of disruptions for such users.

Deployment Plan

In 2020, Verisign asked the Root Zone Evolution Review Committee (RZERC) to consider a proposal for adding data protections to the root zone using ZONEMD. In 2021, the RZERC published its recommendations in RZERC003. One of those recommendations was for Verisign and ICANN to develop a deployment plan and make the community aware of the plan’s details. That plan is summarized in the remainder of this blog post.

Phased Rollout

One attribute of a ZONEMD record is the choice of a hash algorithm used to create the digest. RFC 8976 defines two standard hash algorithms – SHA-384 and SHA-512 – and a range of “private-use” algorithms.

Initially, the root zone’s ZONEMD record will have a private-use hash algorithm. This allows us to first include the record in the zone without anyone worrying about the validity of the digest values. Since the hash algorithm is from the private-use range, a consumer of the zone data will not know how to calculate the digest value. A similar technique, known as the “Deliberately Unvalidatable Root Zone,” was utilized when DNSSEC was added to the root zone in 2010.

After a period of more than two months, the ZONEMD record will transition to a standard hash algorithm.

Hash Algorithm

SHA-384 has been selected for the initial implementation for compatibility reasons.

The developers of BIND implemented the ZONEMD protocol based on an early Internet-Draft, some time before it was published as an RFC. Unfortunately, the initial BIND implementation only accepts ZONEMD records with a digest length of 48 bytes (i.e., the SHA-384 length). Since the versions of BIND with this behavior are in widespread use today, use of the SHA-512 hash algorithm would likely lead to problems for many BIND installations, possibly including some Root Server Operators.

Presentation Format

Distribution of the zone between the Root Zone Maintainer and Root Server Operators primarily takes place via the DNS zone transfer protocol. In this protocol, zone data is transmitted in “wire format.”

The root zone is also stored and served as a file on the internic.net FTP and web servers. Here, the zone data is in “presentation format.” The ZONEMD record will appear in these files using its native presentation format. For example:

. 86400 IN ZONEMD 2021101902 1 1 ( 7d016e7badfd8b9edbfb515deebe7a866bf972104fa06fec
e85402cc4ce9b69bd0cbd652cec4956a0f206998bfb34483 )

Some users of zone data received from the FTP and web servers might currently be using software that does not recognize the ZONEMD presentation format. These users might experience some problems when the ZONEMD record first appears. We did consider using a generic record format; however, in consultation with ICANN, we believe that the native format is a better long-term solution.

Schedule

Currently, we are targeting the initial deployment of ZONEMD in the root zone for September 13, 2023. As previously stated, the ZONEMD record will be published first with a private-use hash algorithm number. We are targeting December 6, 2023, as the date to begin using the SHA-384 hash algorithm, at which point the root zone ZONEMD record will become verifiable.

Conclusion

Deploying ZONEMD in the root zone helps to increase the security, stability, and resiliency of the DNS. Soon, recursive name servers that choose to serve root zone data locally will have stronger assurances as to the zone’s validity.

If you’re interested in following the ZONEMD deployment progress, please look for our announcements on the DNS Operations mailing list.

The post Adding ZONEMD Protections to the Root Zone appeared first on Verisign Blog.

Verisign’s Role in Securing the DNS Through Key Signing Ceremonies

Every few months, an important ceremony takes place. It’s not splashed all over the news, and it’s not attended by global dignitaries. It goes unnoticed by many, but its effects are felt across the globe. This ceremony helps make the internet more secure for billions of people.

This unique ceremony began in 2010 when Verisign, the Internet Corporation for Assigned Names and Numbers (ICANN), and the U.S. Department of Commerce’s National Telecommunications and Information Administration collaborated – with input from the global internet community – to deploy a technology called Domain Name System Security Extensions (DNSSEC) to the Domain Name System (DNS) root zone in a special ceremony. This wasn’t a one-off occurrence in the history of the DNS, though. Instead, these organizations developed a set of processes, procedures, and schedules that would be repeated for years to come. Today, these recurring ceremonies help ensure that the root zone is properly signed, and as a result, the DNS remains secure, stable, and resilient.

In this blog, we take the opportunity to explain these ceremonies in greater detail and describe the critical role that Verisign is honored to perform.

A Primer on DNSSEC, Key Signing Keys, and Zone Signing Keys

DNSSEC is a series of technical specifications that allow operators to build greater security into the DNS. Because the DNS was not initially designed as a secure system, DNSSEC represented an essential leap forward in securing DNS communications. Deploying DNSSEC allows operators to better protect their users, and it helps to prevent common threats such as “man-in-the-middle” attacks. DNSSEC works by using public key cryptography, which allows zone operators to cryptographically sign their zones. This allows anyone communicating with and validating a signed zone to know that their exchanges are genuine.

The root zone, like most signed zones, uses separate keys for zone signing and for key signing. The Key Signing Key (KSK) is separate from the Zone Signing Key (ZSK). However, unlike most zones, the root zone’s KSK and ZSK are operated by different organizations; ICANN serves as the KSK operator and Verisign as the ZSK operator. These separate roles for DNSSEC align naturally with ICANN as the Root Zone Manager and Verisign as the Root Zone Maintainer.

In practice, the KSK/ZSK split means that the KSK only signs the DNSSEC keys, and the ZSK signs all the other records in the zone. Signing with the KSK happens infrequently – only when the keys change. However, signing with the ZSK happens much more frequently – whenever any of the zone’s other data changes.

DNSSEC and Public Key Cryptography

Something to keep in mind before we go further: remember that DNSSEC utilizes public key cryptography, in which keys have both a private and public component. The private component is used to generate signatures and must be guarded closely. The public component is used to verify signatures and can be shared openly. Good cryptographic hygiene says that these keys should be changed (or “rolled”) periodically.

In DNSSEC, changing a KSK is generally difficult, whereas changing a ZSK is relatively easy. This is especially true for the root zone where a KSK rollover requires all validating recursive name servers to update their copy of the trust anchor. Whereas the first and only KSK rollover to date happened after a period of eight years, ZSK rollovers take place every three months. Not coincidentally, this is also how often root zone key signing ceremonies take place.

Why We Have Ceremonies

The notion of holding a “ceremony” for such an esoteric technical function may seem strange, but this ceremony is very different from what most people are used to. Our common understanding of the word “ceremony” brings to mind an event with speeches and formal attire. But in this case, the meaning refers simply to the formality and ritual aspects of the event.

There are two main reasons for holding key signing ceremonies. One is to bring participants together so that everyone may transparently witness the process. Ceremony participants include ICANN staff, Verisign staff, Trusted Community Representatives (TCRs), and external auditors, plus guests on occasion.

The other important reason, of course, is to generate DNSSEC signatures. Occasionally other activities take place as well, such as generating new keys, retiring equipment, and changing TCRs. In this post, we’ll focus only on the signature generation procedures.

The Key Signing Request

A month or two before each ceremony, Verisign generates a file called the Key Signing Request (KSR). This is an XML document which includes the set of public key records (both KSK and ZSK) to be signed and then used during the next calendar quarter. The KSR is securely transmitted from Verisign to the Internet Assigned Numbers Authority (IANA), which is a function of ICANN that performs root zone management. IANA securely stores the KSR until it is needed for the upcoming key signing ceremony.

Each quarter is divided into nine 10-day “slots” (for some quarters, the last slot is extended by a day or two) and the XML file contains nine key “bundles” to be signed. Each bundle, or slot, has a signature inception and expiration timestamp, such that they overlap by at least five days. The first and last slots in each quarter are used to perform ZSK rollovers. During these slots we publish two ZSKs and one KSK in the root zone.

At the Ceremony: Details Matter

The root zone KSK private component is held inside secure Hardware Security Modules (HSMs). These HSMs are stored inside locked safes, which in turn are kept inside locked rooms. At a key signing ceremony, the HSMs are taken out of their safes and activated for use. This all occurs according to a pre-defined script with many detailed steps, as shown in the figure below.

Also stored inside the safe is a laptop computer, its operating system on non-writable media (i.e., DVD), and a set of credentials for the TCRs, stored on smart cards and locked inside individual safe deposit boxes. Once all the necessary items are removed from the safes, the equipment can be turned on and activated.

The laptop computer is booted from its operating system DVD and the HSM is connected via Ethernet for data transfer and serial port for console logging. The TCR credentials are used to activate the HSM. Once activated, a USB thumb drive containing the KSR file is connected to the laptop and the signing program is started.

The signing program reads the KSR, validates it, and then displays information about the keys about to be signed. This includes the signature inception and expiration timestamps, and the ZSK key tag values.

Validate and Process KSR /media/KSR/KSK46/ksr-root-2022-q4-0.xml...
#  Inception           Expiration           ZSK Tags      KSK Tag(CKA_LABEL)
1  2022-10-01T00:00:00 2022-10-22T00:00:00  18733,20826
2  2022-10-11T00:00:00 2022-11-01T00:00:00  18733
3  2022-10-21T00:00:00 2022-11-11T00:00:00  18733
4  2022-10-31T00:00:00 2022-11-21T00:00:00  18733
5  2022-11-10T00:00:00 2022-12-01T00:00:00  18733
6  2022-11-20T00:00:00 2022-12-11T00:00:00  18733
7  2022-11-30T00:00:00 2022-12-21T00:00:00  18733
8  2022-12-10T00:00:00 2022-12-31T00:00:00  18733
9  2022-12-20T00:00:00 2023-01-10T00:00:00  00951,18733
...PASSED.

It also displays an SHA256 hash of the KSR file and a corresponding “PGP (Pretty Good Privacy) Word List.” The PGP Word List is a convenient and efficient way of verbally expressing hexadecimal values:

SHA256 hash of KSR:
ADCE9749F3DE4057AB680F2719B24A32B077DACA0F213AD2FB8223D5E8E7CDEC
>> ringbolt sardonic preshrunk dinosaur upset telephone crackdown Eskimo rhythm gravity artist celebrate bedlamp pioneer dogsled component ruffled inception surmount revenue artist Camelot cleanup sensation watchword Istanbul blowtorch specialist trauma truncated spindle unicorn <<

At this point, a Verisign representative comes forward to verify the KSR. The following actions then take place:

1. The representative’s identity and proof-of-employment are verified.
2. They verbalize the PGP Word List based on the KSR sent from Verisign.
3. TCRs and other ceremony participants compare the spoken list of words to those displayed on the screen.
4. When the checksum is confirmed to match, the ceremony administrator instructs the program to proceed with generating the signatures.

The signing program outputs a new XML document, called the Signed Key Response (SKR). This document contains signatures over the DNSKEY resource record sets in each of the nine slots. The SKR is saved to a USB thumb drive and given to a member of the Root Zone KSK Operations Security team. Usually sometime the next day, IANA securely transmits the SKR back to Verisign. Following several automatic and manual verification steps, the signature data is imported into Verisign’s root zone management system for use at the appropriate times in the next calendar quarter.

Why We Do It

Keeping the internet’s DNS secure, stable, and resilient is a crucial aspect of Verisign’s role as the Root Zone Maintainer. We are honored to participate in the key signing ceremonies with ICANN and the TCRs and do our part to help the DNS operate as it should.

For more information on root key signing ceremonies, visit the IANA website. Visitors can watch video recordings of previous ceremonies and even sign up to witness the next ceremony live. It’s a great resource, and a unique opportunity to take part in a process that helps keep the internet safe for all.

The post Verisign’s Role in Securing the DNS Through Key Signing Ceremonies appeared first on Verisign Blog.

Researchers Uncover UEFI Secure Boot Bypass in 3 Microsoft Signed Boot Loaders

A security feature bypass vulnerability has been uncovered in three signed third-party Unified Extensible Firmware Interface (UEFI) boot loaders that allow bypass of the UEFI Secure Boot feature. "These vulnerabilities can be exploited by mounting the EFI System Partition and replacing the existing bootloader with the vulnerable one, or modifying a UEFI variable to load the vulnerable loader

Experts Uncover New 'CosmicStrand' UEFI Firmware Rootkit Used by Chinese Hackers

An unknown Chinese-speaking threat actor has been attributed to a new kind of sophisticated Unified Extensible Firmware Interface (UEFI) firmware rootkit called CosmicStrand. "The rootkit is located in the firmware images of Gigabyte or ASUS motherboards, and we noticed that all these images are related to designs using the H81 chipset," Kaspersky researchers said in a new report published today

New Linux Malware Framework Lets Attackers Install Rootkit on Targeted Systems

A never-before-seen Linux malware has been dubbed a "Swiss Army Knife" for its modular architecture and its capability to install rootkits. This previously undetected Linux threat, called Lightning Framework by Intezer, is equipped with a plethora of features, making it one of the most intricate frameworks developed for targeting Linux systems. "The framework has both passive and active

New UEFI Firmware Vulnerabilities Impact Several Lenovo Notebook Models

Consumer electronics maker Lenovo on Tuesday rolled out fixes to contain three security flaws in its UEFI firmware affecting over 70 product models. "The vulnerabilities can be exploited to achieve arbitrary code execution in the early phases of the platform boot, possibly allowing the attackers to hijack the OS execution flow and disable some important security features," Slovak cybersecurity

The Link Between AWM Proxy & the Glupteba Botnet

On December 7, 2021, Google announced it was suing two Russian men allegedly responsible for operating the Glupteba botnet, a global malware menace that has infected millions of computers over the past decade. That same day, AWM Proxy — a 14-year-old anonymity service that rents hacked PCs to cybercriminals — suddenly went offline. Security experts had long seen a link between Glupteba and AWM Proxy, but new research shows AWM Proxy’s founder is one of the men being sued by Google.

Launched in March 2008, AWM Proxy quickly became the largest service for crooks seeking to route their malicious Web traffic through compromised devices. In 2011, researchers at Kaspersky Lab showed that virtually all of the hacked systems for rent at AWM Proxy had been compromised by TDSS (a.k.a TDL-4 and Alureon), a stealthy “rootkit” that installs deep within infected PCs and loads even before the underlying Windows operating system boots up.

In March 2011, security researchers at ESET found TDSS was being used to deploy Glupteba, another rootkit that steals passwords and other access credentials, disables security software, and tries to compromise other devices on the victim’s network — such as Internet routers and media storage servers — for use in relaying spam or other malicious traffic.

Like its predecessor TDSS, Glupteba is primarily distributed through “pay-per-install” or PPI networks, and via traffic purchased from traffic distribution systems (TDS). Pay-per-install networks try to match cybercriminals who already have access to large numbers of hacked PCs with other crooks seeking broader distribution of their malware.

In a typical PPI network, clients will submit their malware—a spambot or password-stealing Trojan, for example —to the service, which in turn charges per thousand successful installations, with the price depending on the requested geographic location of the desired victims. One of the most common ways PPI affiliates generate revenue is by secretly bundling the PPI network’s installer with pirated software titles that are widely available for download via the web or from file-sharing networks.

Over the past decade, both Glupteba and AWM Proxy have grown substantially. When KrebsOnSecurity first covered AWM Proxy in 2011, the service was selling access to roughly 24,000 infected PCs scattered across dozens of countries. Ten years later, AWM Proxy was offering 10 times that number of hacked systems on any given day, and Glupteba had grown to more than one million infected devices worldwide.

There is also ample evidence to suggest that Glupteba may have spawned Meris, a massive botnet of hacked Internet of Things (IoT) devices that surfaced in September 2021 and was responsible for some of the largest and most disruptive distributed denial-of-service (DDoS) attacks the Internet has ever seen.

But on Dec. 7, 2021, Google announced it had taken technical measures to dismantle the Glupteba botnet, and filed a civil lawsuit (PDF) against two Russian men thought to be responsible for operating the vast crime machine. AWM Proxy’s online storefront disappeared that same day.

AWM Proxy quickly alerted its customers that the service had moved to a new domain, with all customer balances, passwords and purchase histories seamlessly ported over to the new home. However, subsequent takedowns targeting AWM Proxy’s domains and other infrastructure have conspired to keep the service on the ropes and frequently switching domains ever since.

Earlier this month, the United States, Germany, the Netherlands and the U.K. dismantled the “RSOCKS” botnet, a competing proxy service that had been in operation since 2014. KrebsOnSecurity has identified the owner of RSOCKS as a 35-year-old from Omsk, Russia who runs the world’s largest forum catering to spammers.

Shortly after last week’s story on the RSOCKS founder, I heard from Riley Kilmer, co-founder of Spur.us, a startup that tracks criminal proxy services. Kilmer said RSOCKS was similarly disabled after Google’s combined legal sneak attack and technical takedown targeting Glupteba.

“The RSOCKS website gave you the estimated number of proxies in each of their subscription packages, and that number went down to zero on Dec. 7,” Kilmer said. “It’s not clear if that means the services were operated by the same people, or if they were just using the same sources (i.e., PPI programs) to generate new installations of their malware.”

Kilmer said each time his company tried to determine how many systems RSOCKS had for sale, they found each Internet address being sold by RSOCKS was also present in AWM Proxy’s network. In addition, Kilmer said, the application programming interfaces (APIs) used by both services to keep track of infected systems were virtually identical, once again suggesting strong collaboration.

“One hundred percent of the IPs we got back from RSOCKS we’d already identified in AWM,” Kilmer said. “And the IP port combinations they give you when you access an individual IP were the same as from AWM.”

In 2011, KrebsOnSecurity published an investigation that identified one of the founders of AWM Proxy, but Kilmer’s revelation prompted me to take a fresh look at the origins of this sprawling cybercriminal enterprise to determine if there were additional clues showing more concrete links between RSOCKS, AWM Proxy and Glupteba.

IF YOUR PLAN IS TO RIP OFF GOOGLE…

Supporting Kilmer’s theory that AWM Proxy and RSOCKS may simply be using the same PPI networks to spread, further research shows the RSOCKS owner also had an ownership stake in AD1[.]ru, an extremely popular Russian-language pay-per-install network that has been in operation for at least a decade.

Google took aim at Glupteba in part because its owners were using the botnet to divert and steal vast sums in online advertising revenue. So it’s more than a little ironic that the critical piece of evidence linking all of these operations begins with a Google Analytics code included in the HTML code for the original AWM Proxy back in 2008 (UA-3816536).

That analytics code also was present on a handful of other sites over the years, including the now-defunct Russian domain name registrar Domenadom[.]ru, and the website web-site[.]ru, which curiously was a Russian company operating a global real estate appraisal business called American Appraisal.

Two other domains connected to that Google Analytics code — Russian plastics manufacturers techplast[.]ru and tekhplast.ru — also shared a different Google Analytics code (UA-1838317) with web-site[.]ru and with the domain “starovikov[.]ru.”

The name on the WHOIS registration records for the plastics domains is an “Alexander I. Ukraincki,” whose personal information also is included in the domains tpos[.]ru and alphadisplay[.]ru, both apparently manufacturers of point-of-sale payment terminals in Russia.

Constella Intelligence, a security firm that indexes passwords and other personal information exposed in past data breaches, revealed dozens of variations on email addresses used by Alexander I. Ukraincki over the years. Most of those email addresses start with some variation of “uai@” followed by a domain from one of the many Russian email providers (e.g., yandex.ru, mail.ru). [Full disclosure: Constella is currently an advertiser on this website].

But Constella also shows those different email addresses all relied on a handful of passwords — most commonly “2222den” and “2222DEN.” Both of those passwords have been used almost exclusively in the past decade by the person who registered more than a dozen email addresses with the username “dennstr.”

The dennstr identity leads to several variations on the same name — Denis Strelinikov, or Denis Stranatka, from Ukraine, but those clues ultimately led nowhere promising. And maybe that was the point.

Things began looking brighter after I ran a search in DomainTools for web-site[.]ru’s original WHOIS records, which shows it was assigned in 2005 to a “private person” who used the email address lycefer@gmail.com. A search in Constella on that email address says it was used to register nearly two dozen domains, including starovikov.ru and starovikov[.]com.

A cached copy of the contact page for Starovikov[.]com shows that in 2008 it displayed the personal information for a Dmitry Starovikov, who listed his Skype username as “lycefer.”

Finally, Russian incorporation documents show the company LLC Website (web-site[.]ru)was registered in 2005 to two men, one of whom was named Dmitry Sergeevich Starovikov.

Bringing this full circle, Google says Starovikov is one of the two operators of the Glupteba botnet:

Mr. Starovikov did not respond to requests for comment. But attorneys for Starovikov and his co-defendant last month filed a response to Google’s complaint in the Southern District of New York, denying (PDF) their clients had any knowledge of the scheme.

Despite all of the disruption caused by Google’s legal and technical meddling, AWM is still around and nearly as healthy as ever, although the service has been branded with a new name and there are dubious claims of new owners. Advertising customer plans ranging from $50 a day to nearly $700 for “VIP access,” AWM Proxy says its malware has been running on approximately 175,000 systems worldwide over the last 24 hours, and that roughly 65,000 of these systems are currently online.

Meanwhile, the administrators of RSOCKS recently alerted customers that the service and any unspent balances will soon be migrated over to a new location.

Many people seem to equate spending time, money and effort to investigate and prosecute cybercriminals with the largely failed war on drugs, meaning there is an endless supply of up-and-coming crooks who will always fill in any gaps in the workforce whenever cybercriminals face justice.

While that may be true for many low-level cyber thieves today, investigations like these show once again how small the cybercriminal underground really is. It also shows how it makes a great deal of sense to focus efforts on targeting and disrupting the relatively small number of established hackers who remain the real force multipliers of cybercrime.

New Syslogk Linux Rootkit Lets Attackers Remotely Command It Using "Magic Packets"

A new covert Linux kernel rootkit named Syslogk has been spotted under development in the wild and cloaking a malicious payload that can be remotely commandeered by an adversary using a magic network traffic packet. "The Syslogk rootkit is heavily based on Adore-Ng but incorporates new functionalities making the user-mode application and the kernel rootkit hard to detect," Avast security

More Mysterious DNS Root Query Traffic from a Large Cloud/DNS Operator

This blog was also published by APNIC.

With so much traffic on the global internet day after day, it’s not always easy to spot the occasional irregularity. After all, there are numerous layers of complexity that go into the serving of webpages, with multiple companies, agencies and organizations each playing a role.

That’s why when something does catch our attention, it’s important that the various entities work together to explore the cause and, more importantly, try to identify whether it’s a malicious actor at work, a glitch in the process or maybe even something entirely intentional.

That’s what occurred last year when Internet Corporation for Assigned Names and Numbers staff and contractors were analyzing names in Domain Name System queries seen at the ICANN Managed Root Server, and the analysis program ran out of memory for one of their data files. After some investigating, they found the cause to be a very large number of mysterious queries for unique names such as f863zvv1xy2qf.surgery, bp639i-3nirf.hiphop, qo35jjk419gfm.net and yyif0aijr21gn.com.

While these were queries for names in existing top-level domains, the first label consisted of 12 or 13 random-looking characters. After ICANN shared their discovery with the other root server operators, Verisign took a closer look to help understand the situation.

Exploring the Mystery

One of the first things we noticed was that all of these mysterious queries were of type NS and came from one autonomous system network, AS 15169, assigned to Google LLC. Additionally, we confirmed that it was occurring consistently for numerous TLDs. (See Fig. 1)

Although this phenomenon was newly uncovered, analysis of historical data showed these traffic patterns actually began in late 2019. (See Fig. 2)

Perhaps the most interesting discovery, however, was that these specific query names were not also seen at the .com and .net name servers operated by Verisign. The data in Figure 3 shows the fraction of queried names that appear at A-root and J-root and also appear on the .com and .net name servers. For second-level labels of 12 and 13 characters, this fraction is essentially zero. The graphs also show that there appears to be queries for names with second-level label lengths of 10 and 11 characters, which are also absent from the TLD data.

The final mysterious aspect to this traffic is that it deviated from our normal expectation of caching. Remember that these are queries to a root name server, which returns a referral to the delegated name servers for a TLD. For example, when a root name server receives a query for yyif0aijr21gn.com, the response is a list of the name servers that are authoritative for the .com zone. The records in this response have a time to live of two days, meaning that the recursive name server can cache and reuse this data for that amount of time.

However, in this traffic we see queries for .com domain names from AS 15169 at the rate of about 30 million per day. (See Fig. 4) It is well known that Google Public DNS has thousands of backend servers and limits TTLs to a maximum of six hours. Assuming 4,000 backend servers each cached a .com referral for six hours, we might expect about 16,000 queries over a 24-hour period. The observed count is about 2,000 times higher by this back-of-the-envelope calculation.

From our initial analysis, it was unclear if these queries represented legitimate end-user activity, though we were confident that source IP address spoofing was not involved. However, since the query names shared some similarities to those used by botnets, we could not rule out malicious activity.

The Missing Piece

These findings were presented last year at the DNS-OARC 35a virtual meeting. In the conference chat room after the talk, the missing piece of this puzzle was mentioned by a conference participant. There is a Google webpage describing its public DNS service that talks about prepending nonce (i.e., random) labels for cache misses to increase entropy. In what came to be known as “the Kaminsky Attack,” an attacker can cause a recursive name server to emit queries for names chosen by the attacker. Prepending a nonce label adds unpredictability to the queries, making it very difficult to spoof a response. Note, however, that nonce prepending only works for queries where the reply is a referral.

In addition, Google DNS has implemented a form of query name minimization (see RFC 7816 and RFC 9156). As such, if a user requests the IP address of www.example.com and Google DNS decides this warrants a query to a root name server, it takes the name, strips all labels except for the TLD and then prepends a nonce string, resulting in something like u5vmt7xanb6rf.com. A root server’s response to that query is identical to one using the original query name.

The Mystery Explained

Now, we are able to explain nearly all of the mysterious aspects of this query traffic from Google. We see random second-level labels because of the nonce strings that are designed to prevent spoofing. The 12- and 13-character-long labels are most likely the result of converting a 64-bit random value into an unpadded ASCII label with encoding similar to Base32. We don’t observe the same queries at TLD name servers because of both the nonce prepending and query name minimization. The query type is always NS because of query name minimization.

With that said, there’s still one aspect that eludes explanation: the high query rate (2000x for .com) and apparent lack of caching. And so, this aspect of the mystery continues.

Wrapping Up

Even though we haven’t fully closed the books on this case, one thing is certain: without the community’s teamwork to put the pieces of the puzzle together, explanations for this strange traffic may have remained unknown today. The case of the mysterious DNS root query traffic is a perfect example of the collaboration that’s required to navigate today’s ever-changing cyber environment. We’re grateful and humbled to be part of such a dedicated community that is intent on ensuring the security, stability and resiliency of the internet, and we look forward to more productive teamwork in the future.

The post More Mysterious DNS Root Query Traffic from a Large Cloud/DNS Operator appeared first on Verisign Blog.

S3 Ep57: Europol v. Ransomware, Shrootless bug, and Linux browser flamewars [Podcast]

Latest episode - listen now!

Microsoft documents “SHROOTLESS” hack patched in latest Apple updates

We'd have called this bug "SHROOTMORE", but naming it wasn't our call.