IT NEWS

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.

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.

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.

Last week on Malwarebytes Labs we discussed VPN Android apps, how even the FBI has to deal with insider threats, Chrome’s Incognito mode, new rules for critical infrastructure spurred by the Colonial Pipeline attack, how to delete your Twitter account, what encryption is, how healthcare service faces test of willpower with ransomware authors, how certified PDFs can be falsified and weaponized, how the threat actors behind SolarWinds are at it again, a threat spotlight about Conti ransomware, and what is RMM software?

In our podcast Lock and Code we shone a light on dark patterns with Carey Parker.

Other cybersecurity news:

• Eight arrests in Royal Mail text scam investigation. (Source: BBC News)
• Canada Post hit by data breach after supplier ransomware attack. (Source: BleepingComputer)
• Chinese cyber espionage hackers continue to target Pulse Secure VPN devices. (Source: The Hacker News)
• Studying the manipulation of security headers in browser extensions. ( Research pdf)
• Members of public send messages to cyber gang that attacked HSE. (Source: The Irish Times)
• WhatsApp sues Indian government over new regulations. (Source: TechCrunch)
• Report shows lack of visibility and control is leaving enterprises vulnerable. (Source: Absolute)
• VMware vCenter Server updates address remote code execution vulnerability in the vSphere Client. (Source: VMWare)

Stay safe, everyone!

The post A week in security (May 24 -30) appeared first on Malwarebytes Labs.

On the 14th of May, the Health Service Executive (HSE), Ireland’s publicly funded healthcare system, fell victim to a Conti ransomware attack, forcing the organization to shut down more than 80,000 affected endpoints and plunging them back to the age of pen and paper. This happened a week after DarkSide, another ransomware strain, hit the USA’s Colonial Pipeline systems.

More than 290 healthcare and first-responder organizations (of the 400 affacted worldwide) that fell victim to a Conti ransomware attack were based in the US. New Zealand, too, has reported of at least 5 hospitals shutting down their IT network in response to a similar attack.

In this blog, we’ll home in on Conti, the strain identified by some as the successor, cousin or relative of Ryuk ransomware, due to similarities in code use and distribution tactics.

Threat profile: Conti ransomware

Conti ransomware is created and distributed by a group the cybersecurity industry has named Wizard Spider, the same Russian cybercriminal group that created the infamous Ryuk ransomware. It is offered to trusted affiliates as Ransomware-as-a-service (RaaS).

According to Coveware, a company that offers incident response services to organizations impacted by ransomware attacks, Conti is the second most common ransomware family that victim organizations have reported in the first quarter of 2021. (The first is Ransom.Sodinokibi, which Malwarebytes has already profiled and has been detecting since 2019.)

There are several ways Conti ransomware could end up on a corporate network. As with other “big game” ransomware, the delivery method changes according to the preferences of the group operating it, but among the most common attack vectors are remote desktop protocol (RDP), phishing, and weaknesses in either software or hardware.

In the case of phishing campaigns, Wizard Spider and its affiliates have been known to use legitimate Google document URLs in the email body. Recipients are encouraged to click this link, which actually contains code that allows for the download and execution of either Bazar, a backdoor, or IcedID (aka BokBot), a Trojan.

Much like other RaaS tools, part of the overall Conti ransomware attack is human-operated, which means actors behind these attacks move laterally within compromised networks using tools like RDP, PsExec, and Cobalt Strike. The ransomware is executed manually in memory across all active endpoints, after as many files as possible have been exfiltrated. The files are then held for ransom and the victim is threatened by data loss, because of the encryption, and leaking of the exfiltrated data. Files are encrypted with a combination of AES-256 and RSA-4096 via the Microsoft CryptoAPI, as per CrowdStrike. Earlier versions appended the .CONTI extension to encrypted files. Newer versions now append a random 5-character string.

Below are screenshots of two of the four possible ransom notes that Conti ransomware leaves behind after fully encrypting affected endpoints. Known ransom note file names are CONTI.txt, R3ADM3.txt, readme.txt, and CONTI_README.txt.

All of your files are currently encrypted by CONTI ransomware.
If you try to use any additional recovery software – the files might be damaged or lost.

To make sure that we REALLY CAN discover data – we offer you to decrypt samples.

You can contact us for further instructions through our website :

TOR version :
(you should download and install TOR browser first https://torproject.org)

[redacted]

HTTPS VERSION :
[redacted]

YOU SHOULD BE AWARE!

Just in case, if you try to ignore us. We’ve downloaded your data and are ready to publish it on out [sic] news website if you do not respond. So it will be better for both sides if you contact us ASAP.

Your system is LOCKED. Write us on the emails:

[redacted]

[redacted]

DO NOT TRY to decrypt files using other software.

Conti is thought to be related to Ryuk ransomware somehow. In a conversation with BleepingComputer, threat hunter and CEO of Advanced Intelligence (AdvIntel) Vitali  Kremez said, “Based on multiple incident response matters and current assessment, it is believed that Conti ransomware is linked to the same Ryuk ransomware developer group based on the code reuse and unique TrickBot distribution. The same distribution attack vector is used widely by the Ryuk deployment group.”

Conti is unique in terms of its “lightning-fast” ability to encrypt files, and how much control it gives to its operator, according to Carbon Black’s Threat Analysis Unit (TAU). When encrypting, Conti uses 32 simultaneous CPU threads for speedier encryption—a huge number of threads compared to other ransomware families that also support multi-threaded operations.

Conti gives its controller the fine-grained option of skipping encrypting files on a local drive in favor of encrypting those on network shares by allowing a human to instruct it via a command-line interface.

Lastly, Conti misuses the Windows Restart Manager to free up files being used by applications—whether they are writing to or reading them—at time of infection by safely terminating these apps so Conti can encrypt the freed files as well.

Malwarebytes’ signature-less protection detects all known variants of Conti.

Adversary profile: Wizard Spider

Wizard Spider is a cybercrime group affiliated with a what is sometimes called the Ransomware Cartel, a collective of underground groups identified by threat intelligence company Analyst1. The group is known to operate a roster of technical tools it created and will willingly let other crime groups use—as long as they are trustworthy enough. When it first surfaced in September 2016, they were using TrickBot, aka TrickLoader, a highly popular banking Trojan.

They changed their tactics in 2018 and started using ransomware in the form of Ryuk. They are perhaps one of the early groups that got into “big game” attacks—and Ryuk was designed for this very purpose. Two years later, the group moved to using Conti, in May 2020.

It is believed that some members of Wizard Spider were once associated with the Dyre/Dyreza group. If you may recall, the group behind Dyre was responsible for attacking Sherwin-Williams, an Ohio-based building materials and paint company.

Unlike some other underground cybercriminal gangs, Wizard Spider doesn’t openly advertise on underground forums, perhaps for security reasons.

The sophisticated tools Wizard Spider have created tell us something of the threat group’s character: they’re resilient, persistent, adaptive, determined, and overall, very efficient.

Prepare for hard battles ahead

The Conti attack against the HSE has poleaxed Ireland’s healthcare system. Fifteen days after the attack, the Irish Independent reports that about half of outpatient appointments are being cancelled daily. At the time of writing, that adds up to just over 100,000 appointments cancelled so far. HSE head Paul Reid estimates that the cost of restoring and updating its systems could reach €100m.

Ransomware attacks, after all, are not just about systems getting crippled and files being held hostage for a fee. It’s also knowingly putting lives at risk to satisfy a deep, insatiable want for money.

Indeed, hard battles are ahead. And as much as we’d like to think that HSE might be a step too far, even for ruthless threat groups like Wizard Spider, it’s not. We should continue to expect the worst, and remember that prevention is better than attempting to apply a cure after the attackers arrive.

Below is a list of recommended mitigations from the FBI, which it issued along with an alert on Conti ransomware late last week:

• Regularly back up data, air gap, and password protect backup copies offline. Ensure copies of critical data are not accessible for modification or deletion from the system where the data resides.
• Implement network segmentation.
• Implement a recovery plan to maintain and retain multiple copies of sensitive or proprietary data and servers in a physically separate, segmented, secure location (i.e., hard drive, storage device, the cloud).
• Install updates/patch operating systems, software, and firmware as soon as they are released.
• Use multi-factor authentication where possible.
• Use strong passwords and regularly change passwords to network systems and accounts, implementing the shortest acceptable timeframe for password changes. Avoid reusing passwords for multiple accounts.
• Disable unused remote access/RDP ports and monitor remote access/RDP logs.
• Require administrator credentials to install software.
• Audit user accounts with administrative privileges and configure access controls with least privilege in mind.
• Install and regularly update anti-virus/anti-malware software on all hosts.
• Only use secure networks and avoid using public Wi-Fi networks. Consider installing and using a VPN.
• Consider adding an email banner to messages coming from outside your organizations.
• Disable hyperlinks in received emails.
• Focus on cyber security awareness and training. Regularly provide users with training on information security principles and techniques as well as overall emerging cybersecurity risks and vulnerabilities (i.e., ransomware and phishing scams).

The post Threat spotlight: Conti, the ransomware used in the HSE healthcare attack appeared first on Malwarebytes Labs.

Nobelium is a synthetic chemical element with the symbol No and atomic number 102. It is named in honor of Alfred Nobel. But it is also the name given to the threat actor that is behind the attacks against SolarWinds, the Sunburst backdoor, TEARDROP malware, GoldMax malware, other related components.

Microsoft Threat Intelligence Center (MSTIC) has issued a warning stating that it has uncovered a wide-scale malicious email campaign operated by NOBELIUM. In this campaign NOBELIUM leveraged the legitimate mass-mailing service Constant Contact. This allowed the threat actor to masquerade as a US-based development organization to distribute malicious URLs to a wide variety of organizations and industry verticals.

The campaign

This new wide-scale email campaign leverages the legitimate service Constant Contact to send malicious links that are disguised since they are obscured behind the mailing service’s URL. Many similar services use this type of mechanism to simplify the sharing of files while providing insights into by who and when links are clicked.

Finding the most effective delivery method

The early beginnings of these campaigns were first noticed January 28, 2021, when the actor was seemingly performing early reconnaissance by only sending the tracking portion of the email, leveraging Firebase URLs to record targets who clicked. Malicious payloads were not observed during this early activity.

In the next evolution of the campaign, MSTIC says it observed NOBELIUM attempting to compromise systems through an HTML file attached to a spear-phishing email. If a receiver opened the HTML attachment, embedded JavaScript  code in the HTML wrote an ISO file to disc and encouraged the target to open it.

Similar spear-phishing campaigns were detected throughout March, which included the NOBELIUM actor making several alterations to the HTML document based on the intended target. MSTIC says it observed the actor encoding the ISO within the HTML document itself; redirecting from the HTML document to an ISO, which contained an RTF document, with the malicious Cobalt Strike Beacon DLL encoded within it; and replacing the HTML with a URL that led to a website that spoofed the targeted organization and hosted the ISO file.

The ISO payload

As we noted above, the payload is delivered via an ISO file. When ISO files are opened they are mounted much like an external or network drive. Threat actors may deploy a container into an environment to facilitate execution or evade defenses. And sometimes they will deploy a new container to execute processes associated with a particular image or deployment, such as processes that execute or download malware. In others, a threat actor may deploy a new container configured without network rules, user limitations, etc. to bypass existing defenses within the environment. In this case, a shortcut file (.lnk) would execute an accompanying DLL, which would result in a Cobalt Strike Beacon executing on the host. It is worth noting that the DLL is a hidden file. Cobalt Strike Beacons call out to the attacker’s infrastructure via port 443.

Experimenting with the payload

The delivery method was not the only evolving factor in the campaign. In one of the more targeted waves, no ISO payload was delivered, but additional profiling of the target device was performed by an actor-controlled web server after a user clicked the link. If the device targeted was an Apple iOS device, the user was redirected to another server under NOBELIUM control, where the since-patched zero-day exploit for CVE-2021-1879 was served.

During the waves in April, the threat actor stopped using Firebase, and no longer tracked users. Their techniques shifted to encoding the ISO inside the HTML document. Target host details were now stored by the payload on a remote server via the use of the api.ipify.org service. The threat actor would sometimes employ checks for specific internal Active Directory domains that would terminate execution of the malicious process if it identified an unintended environment.

The latest surge

On May 25, the NOBELIUM campaign was noticed to escalate significantly, attempting to target around 3,000 individual accounts across more than 150 organizations. Due to the high volume of emails distributed in this campaign, many automated email threat detection systems blocked most of the malicious emails and marked them as spam. However, some automated threat detection systems may have successfully delivered some of the earlier emails to recipients either due to configuration and policy settings or prior to detections being in place.

The goal

The successful deployment of the payload enables NOBELIUM to gain persistent access to the compromised machines. The successful execution of these malicious payloads would also enable NOBELIUM to conduct further malicious activity, such as lateral movement, data exfiltration, and delivery of additional malware.

Indiciators of compromise (IOCs)

In its warning, MSTIC provides a list of indicators of compromise from the large-scale campaign that launched on May 25, 2021. The organization notes that the attack is still active, these indicators should not be considered exhaustive for this observed activity.

Stay safe, everyone!

The post SolarWinds attackers launch new campaign appeared first on Malwarebytes Labs.