Login
Similarities with newly discovered Linux malware used in Operation DreamJob corroborate the theory that the infamous North Korea-aligned group is behind the 3CX supply-chain attack
The post Linux malware strengthens links between Lazarus and the 3CX supply‑chain attack appeared first on WeLiveSecurity
We learned some remarkable new details this week about the recent supply-chain attack on VoIP software provider 3CX. The lengthy, complex intrusion has all the makings of a cyberpunk spy novel: North Korean hackers using legions of fake executive accounts on LinkedIn to lure people into opening malware disguised as a job offer; malware targeting Mac and Linux users working at defense and cryptocurrency firms; and software supply-chain attacks nested within earlier supply chain attacks.
Researchers at ESET say this job offer from a phony HSBC recruiter on LinkedIn was North Korean malware masquerading as a PDF file.
In late March 2023, 3CX disclosed that its desktop applications for both Windows and macOS were compromised with malicious code that gave attackers the ability to download and run code on all machines where the app was installed. 3CX says it has more than 600,000 customers and 12 million users in a broad range of industries, including aerospace, healthcare and hospitality.
3CX hired incident response firm Mandiant, which released a report on Wednesday that said the compromise began in 2022 when a 3CX employee installed a malware-laced software package distributed via an earlier software supply chain compromise that began with a tampered installer for X_TRADER, a software package provided by Trading Technologies.
“This is the first time Mandiant has seen a software supply chain attack lead to another software supply chain attack,” reads the April 20 Mandiant report.
Mandiant found the earliest evidence of compromise uncovered within 3CX’s network was through the VPN using the employee’s corporate credentials, two days after the employee’s personal computer was compromised.
“Eventually, the threat actor was able to compromise both the Windows and macOS build environments,” 3CX said in an April 20 update on their blog.
Mandiant concluded that the 3CX attack was orchestrated by the North Korean state-sponsored hacking group known as Lazarus, a determination that was independently reached earlier by researchers at Kaspersky Lab and Elastic Security.
Mandiant found the compromised 3CX software would download malware that sought out new instructions by consulting encrypted icon files hosted on GitHub. The decrypted icon files revealed the location of the malware’s control server, which was then queried for a third stage of the malware compromise — a password stealing program dubbed ICONICSTEALER.
The double supply chain compromise that led to malware being pushed out to some 3CX customers. Image: Mandiant.
Meanwhile, the security firm ESET today published research showing remarkable similarities between the malware used in the 3CX supply chain attack and Linux-based malware that was recently deployed via fake job offers from phony executive profiles on LinkedIn. The researchers said this was the first time Lazarus had been spotted deploying malware aimed at Linux users.
As reported in a series last summer here, LinkedIn has been inundated this past year by fake executive profiles for people supposedly employed at a range of technology, defense, energy and financial companies. In many cases, the phony profiles spoofed chief information security officers at major corporations, and some attracted quite a few connections before their accounts were terminated.
Mandiant, Proofpoint and other experts say Lazarus has long used these bogus LinkedIn profiles to lure targets into opening a malware-laced document that is often disguised as a job offer. This ongoing North Korean espionage campaign using LinkedIn was first documented in August 2020 by ClearSky Security, which said the Lazarus group operates dozens of researchers and intelligence personnel to maintain the campaign globally.
Microsoft Corp., which owns LinkedIn, said in September 2022 that it had detected a wide range of social engineering campaigns using a proliferation of phony LinkedIn accounts. Microsoft said the accounts were used to impersonate recruiters at technology, defense and media companies, and to entice people into opening a malicious file. Microsoft found the attackers often disguised their malware as legitimate open-source software like Sumatra PDF and the SSH client Putty.
Microsoft attributed those attacks to North Korea’s Lazarus hacking group, although they’ve traditionally referred to this group as “ZINC“. That is, until earlier this month, when Redmond completely revamped the way it names threat groups; Microsoft now references ZINC as “Diamond Sleet.”
The ESET researchers said they found a new fake job lure tied to an ongoing Lazarus campaign on LinkedIn designed to compromise Linux operating systems. The malware was found inside of a document that offered an employment contract at the multinational bank HSBC.
“A few weeks ago, a native Linux payload was found on VirusTotal with an HSBC-themed PDF lure,” wrote ESET researchers Peter Kalnai and Marc-Etienne M.Leveille. “This completes Lazarus’s ability to target all major desktop operating systems. In this case, we were able to reconstruct the full chain, from the ZIP file that delivers a fake HSBC job offer as a decoy, up until the final payload.”
ESET said the malicious PDF file used in the scheme appeared to have a file extension of “.pdf,” but that this was a ruse. ESET discovered that the dot in the filename wasn’t a normal period but instead a Unicode character (U+2024) representing a “leader dot,” which is often used in tables of contents to connect section headings with the page numbers on which those sections begin.
“The use of the leader dot in the filename was probably an attempt to trick the file manager into treating the file as an executable instead of a PDF,” the researchers continued. “This could cause the file to run when double-clicked instead of opening it with a PDF viewer.”
ESET said anyone who opened the file would see a decoy PDF with a job offer from HSBC, but in the background the executable file would download additional malware payloads. The ESET team also found the malware was able to manipulate the program icon displayed by the malicious PDF, possibly because fiddling with the file extension could cause the user’s system to display a blank icon for the malware lure.
Kim Zetter, a veteran Wired.com reporter and now independent security journalist, interviewed Mandiant researchers who said they expect “many more victims” will be discovered among the customers of Trading Technologies and 3CX now that news of the compromised software programs is public.
“Mandiant informed Trading Technologies on April 11 that its X_Trader software had been compromised, but the software maker says it has not had time to investigate and verify Mandiant’s assertions,” Zetter wrote in her Zero Day newsletter on Substack. For now, it remains unclear whether the compromised X_Trader software was downloaded by people at other software firms.
If there’s a silver lining here, the X_Trader software had been decommissioned in April 2020 — two years before the hackers allegedly embedded malware in it.
“The company hadn’t released new versions of the software since that time and had stopped providing support for the product, making it a less-than-ideal vector for the North Korean hackers to infect customers,” Zetter wrote.
The legislation aims to bolster the Union’s cyber-resilience and enhance its capabilities to prepare for, detect and respond to incidents
The post The EU’s Cyber Solidarity Act: Security Operations Centers to the rescue! appeared first on WeLiveSecurity
For the past seven years, a malware-based proxy service known as “Faceless” has sold anonymity to countless cybercriminals. For less than a dollar per day, Faceless customers can route their malicious traffic through tens of thousands of compromised systems advertised on the service. In this post we’ll examine clues left behind over the past decade by the proprietor of Faceless, including some that may help put a face to the name.
The proxy lookup page inside the malware-based anonymity service Faceless. Image: spur.us.
Riley Kilmer is co-founder of Spur.us, a company that tracks thousands of VPN and proxy networks, and helps customers identify traffic coming through these anonymity services. Kilmer said Faceless has emerged as one of the underground’s most reliable malware-based proxy services, mainly because its proxy network has traditionally included a great many compromised “Internet of Things” devices — such as media sharing servers — that are seldom included on malware or spam block lists.
Kilmer said when Spur first started looking into Faceless, they noticed almost every Internet address that Faceless advertised for rent also showed up in the IoT search engine Shodan.io as a media sharing device on a local network that was somehow exposed to the Internet.
“We could reliably look up the [fingerprint] for these media sharing devices in Shodan and find those same systems for sale on Faceless,” Kilmer said.
In January 2023, the Faceless service website said it was willing to pay for information about previously undocumented security vulnerabilities in IoT devices. Those with IoT zero-days could expect payment if their exploit involved at least 5,000 systems that could be identified through Shodan.
Notices posted for Faceless users, advertising an email flooding service and soliciting zero-day vulnerabilities in Internet of Things devices.
Recently, Faceless has shown ambitions beyond just selling access to poorly-secured IoT devices. In February, Faceless re-launched a service that lets users drop an email bomb on someone — causing the target’s inbox to be filled with tens of thousands of junk messages.
And in March 2023, Faceless started marketing a service for looking up Social Security Numbers (SSNs) that claims to provide access to “the largest SSN database on the market with a very high hit rate.”
Kilmer said Faceless wants to become a one-stop-fraud-shop for cybercriminals who are seeking stolen or synthetic identities from which to transact online, and a temporary proxy that is geographically close to the identity being sold. Faceless currently sells this bundled product for $9 — $8 for the identity and $1 for the proxy.
“They’re trying to be this one-stop shop for anonymity and personas,” Kilmer said. “The service basically says ‘here’s an SSN and proxy connection that should correspond to that user’s location and make sense to different websites.'”
Faceless is a project from MrMurza, a particularly talkative member of more than a dozen Russian-language cybercrime forums over the past decade. According to cyber intelligence firm Flashpoint, MrMurza has been active in the Russian underground since at least September 2012. Flashpoint said MrMurza appears to be extensively involved in botnet activity and “drops” — fraudulent bank accounts created using stolen identity data that are often used in money laundering and cash-out schemes.
Faceless grew out of a popular anonymity service called iSocks, which was launched in 2014 and advertised on multiple Russian crime forums as a proxy service that customers could use to route their malicious Web traffic through compromised computers.
Flashpoint says that in the months before iSocks went online, MrMurza posted on the Russian language crime forum Verified asking for a serious partner to assist in opening a proxy service, noting they had a botnet that was powered by malware that collected proxies with a 70 percent infection rate.
MrMurza’s Faceless advertised on the Russian-language cybercrime forum ProCrd. Image: Darkbeast/Ke-la.com.
In September 2016, MrMurza sent a message to all iSocks users saying the service would soon be phased out in favor of Faceless, and that existing iSocks users could register at Faceless for free if they did so quickly — before Faceless began charging new users registration fees between $50 and $100.
Verified and other Russian language crime forums where MrMurza had a presence have been hacked over the years, with contact details and private messages leaked online. In a 2014 private message to the administrator of Verified explaining his bona fides, MrMurza said he received years of positive feedback as a seller of stolen Italian credit cards and a vendor of drops services.
MrMurza told the Verified admin that he used the nickname AccessApproved on multiple other forums over the years. MrMurza also told the admin that his account number at the now-defunct virtual currency Liberty Reserve was U1018928.
According to cyber intelligence firm Intel 471, the user AccessApproved joined the Russian crime forum Zloy in Jan. 2012, from an Internet address in Magnitogorsk, RU. In a 2012 private message where AccessApproved was arguing with another cybercriminal over a deal gone bad, AccessApproved asked to be paid at the Liberty Reserve address U1018928.
In 2013, U.S. federal investigators seized Liberty Reserve and charged its founders with facilitating billions of dollars in money laundering tied to cybercrime. The Liberty Reserve case was prosecuted out of the Southern District of New York, which in 2016 published a list of account information (PDF) tied to thousands of Liberty Reserve addresses the government asserts were involved in money laundering.
That document indicates the Liberty Reserve account claimed by MrMurza/AccessApproved — U1018928 — was assigned in 2011 to a “Vadim Panov” who used the email address lesstroy@mgn.ru.
Constella Intelligence, a threat intelligence firm that tracks breached databases, says lesstroy@mgn.ru was used for an account “Hackerok” at the accounting service klerk.ru that was created from an Internet address in Magnitogorsk. The password chosen by this user was “1232.”
In addition to selling access to hacked computers and bank accounts, both MrMurza and AccessApproved ran side hustles on the crime forums selling clothing from popular retailers that refused to ship directly to Russia.
On one cybercrime forum where AccessApproved had clothing customers, denizens of the forum created a lengthy discussion thread to help users identify incoming emails associated with various reshipping services advertised within their community. Reshippers tend to rely on a large number of people in the United States and Europe helping to forward packages overseas, but in many cases the notifications about purchases and shipping details would be forwarded to reshipping service customers from a consistent email account.
That thread said AccessApproved’s clothing reshipping service forwarded confirmation emails from the address panov-v@mail.ru. This address is associated with accounts on two Russian cybercrime forums registered from Magnitogorsk in 2010 using the handle “Omega^gg4u.”
This Omega^gg4u identity sold software that can rapidly check the validity of large batches of stolen credit cards. Interestingly, both Omega^gg4u and AccessApproved also had another niche: Reselling heavily controlled substances — such as human growth hormone and anabolic steroids — from chemical suppliers in China.
A search in Constella on the address panov-v@mail.ru and many variations on that address shows these accounts cycled through the same passwords, including 055752403k, asus666, 01091987h, and the relatively weak password 1232 (recall that 1232 was picked by whoever registered the lesstroy@mgn.ru account at Klerk.ru).
Constella says the email address asus666@yandex.ru relied on the passwords asus666 and 01091987h. The 01091987h password also was used by asus666@mail.ru, which also favored the password 24587256.
Constella further reports that whoever owned the much shorter address asus@mail.ru also used the password 24587256. In addition, it found the password 2318922479 was tied to both asus666@mail.ru and asus@mail.ru.
The email addresses asus@mail.ru, asus2504@mail.ru, and zaxar2504@rambler.ru were all used to register Vkontakte social media accounts for a Denis ***@VIP*** Pankov. There are a number of other Vkontakte accounts registered to asus@mail.ru and many variations of this address under a different name. But none of those other profiles appear tied to real-life identities.
A mind map simplifying the research detailed here.
Constella’s data shows the email addresses asus2504@mail.ru and zaxar2504@rambler.ru used the rather unique password denis250485, which was also used by the email address denispankov@yandex.ru and almost a dozen variations at other Russian-language email providers.
Russian vehicle registration records from 2016 show the email address denispankov@yandex.ru belongs to Denis Viktorovich Pankov, born on April 25, 1985. That explains the “250485” portion of Pankov’s favored password. The registration records further indicate that in 2016 Pankov’s vehicle was registered in a suburb of Moscow.
Russian incorporation records show that denispankov@yandex.com is tied to IP Pankov Denis Viktorovich, a now-defunct transportation company in the Volograd Oblast, a region in southern Russia that shares a long border with western Kazazkhstan.
More recent records for IP Pankov Denis Viktorovich show a microenterprise with this name in Omsk that described its main activity as “retail sale by mail or via the Internet.” Russian corporate records indicate this entity was liquidated in 2021.
A reverse password search on “denis250485” via Constella shows this password was used by more than 75 email addresses, most of which are some variation of gaihnik@mail.ru — such as gaihnik25@mail.ru, or gaihnik2504@rambler.ru.
In 2012, someone posted answers to a questionnaire on behalf of Denis Viktorovich Pankov to a Russian-language discussion forum on Chinese crested dog breeds. The message said Pankov was seeking a puppy of a specific breed and was a resident of Krasnogorsk, a city that is adjacent to the northwestern boundary of Moscow.
The message said Pankov was a then 27-year-old manager in an advertising company, and could be reached at the email address gaihnik@mail.ru.
Constella Intelligence shows gaihnik@mail.ru registered at the now-defunct email marketing service Smart Responder from an address in Gagarin, which is about 115 miles west of Moscow.
Back in 2015, the user Gaihnik25 was banned from the online game World of Tanks for violating the game’s terms that prohibit “bot farming,” or the automated use of large numbers of player accounts to win some advantage that is usually related to cashing out game accounts or inventory.
For the past few years, someone using the nickname Gaihnik25 has been posting messages to the Russian-language hacking forum Gerki[.]pw, on discussion threads regarding software designed to “brute force” or mass-check online accounts for weak or compromised passwords.
A new member of the Russian hacking forum Nohide[.]Space using the handle Gaihnik has been commenting recently about proxy services, credential checking software, and the sale of hacked mailing lists. Gaihnik’s first post on the forum concerned private software for checking World of Tanks accounts.
The address gaihnik@mail.ru shows how so many email addresses tied to Pankov were also connected to apparently misleading identities on Vkontakte and elsewhere. Constella found this address was tied to a Vkontakte account for a Dmitriy Zakarov.
Microsoft’s Bing search engine says gaihnik@mail.ru belongs to 37-year-old Denis Pankov, yet clicking the Mail.ru profile for that user brings up a profile for a much older man by the name Gavril Zakarov. However, when you log in to a Mail.ru account and view that profile, it shows that most of the account’s profile photos are of a much younger man.
Many of those same photos show up in an online dating profile at dating.ru for the user Gaihnik, a.k.a “Denchik,” who says he is a 37-year-old Taurus from Gagarin who enjoys going for walks in nature, staying up late, and being on the Internet.
Mr. Pankov did not respond to multiple requests for comment sent to all of the email addresses mentioned in this story. However, some of those addresses produced detailed error responses; Mail.ru reported that the users panov-v@mail.ru, asus666@mail.ru, and asus2504@mail.ru were terminated, and that gaihnik25@mail.ru is now disabled.
Messages sent to many other email addresses connected via passwords to Pankov and using some variation of asus####@mail.ru also returned similar account termination messages.
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 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.
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.
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).
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.
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.
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.
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.
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:
FreshRSS 
. 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.
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.
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.
When decommissioning their old hardware, many companies 'throw the baby out with the bathwater'
The post Discarded, not destroyed: Old routers reveal corporate secrets appeared first on WeLiveSecurity
A bit late this week as I've prioritised time out with the family doing as many New Zealand adventure things as we can. And we've seriously maxed out the time, as you can see via the FB link below. But that hasn't stopped a couple of new data breaches flowing into HIBP nor me having some pretty direct thoughts on the premise that the vast bulk of IT pros are being told not to report data breaches. I hope you enjoy this impromptu vid from a faraway location at an odd time, I'll be back to normal again next week.
