IT NEWS

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.

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.

As cybersecurity products evolve to better protect against new forms of malware, trickier evasion techniques, and more organized cybercrime campaigns, the practice of cybersecurity evolves, too, providing simple, streamlined methods to manage hundreds of endpoints through one tool: RMM software.

What is RMM?

Remote Monitoring and Management (RMM) software is one of the go-to products for the types of IT shops that externally support small-to-medium-sized businesses, from dentists’ offices to independent newspapers to small retail shops. RMM tools allow those external IT shops—called “Managed Service Providers” or MSPs—to do much of their work remotely.

That means that, with a good RMM, the IT experts working at an MSP do not need to physically visit a client to fix their computer or to address any help tickets. It also means that MSPs can fix critical problems for their clients as they arise, rather than having to take scheduled, physical trips on a rotating basis just to find out whether a client’s machines and networks are operating smoothly.

But the benefit of these tools extends further than basic maintenance, as RMM software can also give MSPs an option to monitor cybersecurity protection to their clients all at once. Years ago, MSPs would have to install antivirus software on each client machine, and then individually run antivirus scans or remediation tools. For an MSP supporting just a few clients that each have 100 machines, this laborious process could eat up entire days. Thankfully, many cybersecurity tools have begun to integrate directly with RMM products, so that IT experts can directly run security scans from their RMM portal.

Essentially, an RMM can be a toolbox for any successful MSP, as they house and provide direct access to the most essential tools necessary for IT experts today.

Selecting an RMM solution for an MSP’s business needs

Picking an RMM solution is trickier than picking a product for just yourself because you need to consider both the success of your business and the safety of your clients. Imagine using an RMM platform that integrates seamlessly with top-tier cybersecurity software, but itself is open to ransomware and brute force attacks. Sure, you’ve done the right thing by giving your clients up-to-date cybersecurity protection, but your own systems could be compromised.

For MSPs considering how to select an RMM solution, there are a few features that could help their own business, including 24/7 support, a cloud-based model, data protection and restoration services, and integration with another type of tool called “professional services automation,” which boost the administration process of running an MSP, like finding potential new customers, chatting with clients, drawing up invoices, and making sure the bills get paid.

MSPs should also ask themselves a series of questions about how they want their RMM to help their business stay successful. As we wrote about last time, some helpful questions to consider when selecting an RMM solution include:

• Does this vendor take security seriously as much as we do?
• Does this RMM adapt to new demands and scale well with the changing trends?
• Does the vendor provide proactive patching and show momentum in improving?
• How easily can my employees use this platform?
• Can the platform be accessed via mobile devices?

Remember, an RMM solution needs to both provide for easier management of your clients endpoints and it needs to support your business as an MSP. A solution that’s clunky and hard to use won’t set your IT experts up for success. A solution that refuses to update its offering—with cybersecurity integration, for example—likely won’t help you run your business for more than a year or two. And with so much of today’s work being on-the-go, an RMM solution that can be accessed through a mobile app could greatly benefit your team.

None of this is easy work, and finding the right tool can, and should, take serious consideration. But the benefits of an RMM are proven. Just make sure you’re finding one for your business needs in the future, not just today.

The post RMM software: What is it and do you need it? appeared first on Malwarebytes Labs.

Healthcare and ransomware are in the news in a big way. Data leaks are inevitable, but those are typically associated with accidents by the general public. Possibly the most malicious type of data spillage is when people compromising said data decide to do the spilling. It’s one thing to accidentally leave a database exposed; it’s quite another for someone else to grab it, then blackmail the data owners to pay up or else.

Well, we have our “pay up or else” business model and have done for some time; it’s called ransomware. We also have our latest pay up or else story, in the form a of New Zealand health system compromise.

The background

Last week, a part of New Zealand’s health service was brought down. Specifically, one district’s “entire IT network” which caused appointment cancellations, postponed surgeries, and deferred outpatient activity at rural hospitals. Disruptions during normal times…remember those?…are bad enough. Anything interfering with hospitals during the pandemic is as danger-filled as it gets.

Let’s not forget that with lockdowns easing off, there’s lots of people out there with severely delayed non-Covid treatments waiting. Imagine wait to be seen for a year or more, finally landing an appointment, and then it’s cancelled because of people breaking into computer systems. Worse, Covid-19 infection numbers aren’t exactly stable. People could lose their slot, discover their area’s had a sudden outbreak, and then they’re left waiting…again.

The human cost of any attack on health services is absolutely horrendous. As far as the attack in New Zealand goes, the ITPro article mentions investigators suspect the “initial incursion” came about via a bogus email attachment. However, the Health Service newsroom page doesn’t mention this or go into further details while investigations are taking place.

The fallout

Being shut out of systems is bad enough. Having to cancel appointments, or (for example) lose access to crucial patient data, is also a disaster. The promise of attackers dropping confidential information across the internet or putting it up for sale is the icing on a terrible slice of cake.

Where ransomware is concerned, this can happen should victims refuse to pay up. “Best” case scenario, they’re permanently locked out of encrypted files once the payment deadline passes. Worst case, they pay up and the files remain encrypted. Or, they refuse to pay and then the documents start to leak, and drip, into places they should never go.

It seems the group behind the ransomware have indeed done some leaky dripping, because the victims refuse to pay. Private patient information has found its way to media outlets, according to Reuters. Documents purportedly include names, addresses, and phone numbers of patients and / or staff.

Pay up…or else (maybe)

Passing this information to media outlets feels very much like the warning shot across the bow. If the situation here is the attackers are holding out for payment, the next step will be a dump of data to more public locations.

Note that nobody bar the affected organisation knows for sure at this stage. They won’t reveal if this initial leak is off the back of a request for payment, or some other demand. This is because they’re concerned that discussing details publicly could shape the attacker’s next steps. As a result, we’re all waiting to see what happens next (or, quite possibly, doesn’t).

A critical mass approaching

Ransomware is increasingly in the news for causing severe harm and disruption. If it isn’t hospitals and healthcare, it’s incredibly important oil pipelines. These attacks are now generating levels of heat towards attackers perhaps not seen before. If things keep going like this, who knows where things will end up. When critical infrastructure, healthcare, and other important functions are impacted, you can bet governments won’t sit idly by. The question is: Who will win this digital arms race?

The post Healthcare service faces test of willpower with Ransomware authors appeared first on Malwarebytes Labs.

The Portable Document Format (PDF) file type is one of the most common file formats in use today. It’s value comes from the fact that PDFs always print the same way, and that PDFs are supposed to be read-only (unlike a Word document, say, which is designed to be easy to edit). This immutability can be assured by password protection and digital signing.

PDFs are used extensively in the legal, medical and real-estate industries, but are also seen in education, small businesses and other sectors. The format’s popularity really took off when Adobe released it as an open standard in around 2008, which untethered it from the company’s Acrobat software.

PDF security

PDF files can be password protected so that only people with the password can read the content of the file. However, for anyone that knows the password it’s trivial to remove the password or create an identical file that is not password protected.

Certified PDFs

PDFs can be digital signed, which indicates that the signer approves of its contents. The PDF specification defines two different types of digital signatures to guarantee the authenticity and integrity of documents:

• Approval signatures testify one specific state of the PDF document. If the document is changed the signature becomes invalid.
• Certification signatures allow for specific changes to a signed document without invalidating the signature. You can specify the types of changes that are permitted for the document to remain certified. For example, a sender can specify that a signature from a receiver in the designated field does not invalidate the certification. This way the sender can be sure that when they receive the signed copy that the signature was the only change in the document. Certifying signatures can be visible or invisible.

Digital signatures

You cannot remove a digital signature from a PDF unless you are the one who placed it and you have the digital ID for signing it installed. Each time a document is signed using a certificate, a signed version of the PDF at that time is saved with the PDF. Each version is saved as append-only and the original cannot be modified. After a document is signed, you can display a list of the changes made to the document after the last version.

Secretly changing signed documents

Researchers working at the Ruhr University Bochum (Germany) however, have presented two possible attacks where the content of the PDF document can be altered by the receiver in such a way that the changes are undetectable, either in all PDF applications or in a subset of them. The names that they gave to these two attacks are:

• Evil Annotation Attack (EAA)
• Sneaky Signature Attack (SSA)

Both vulnerabilities allow an attacker to change the visible content of a PDF document by displaying unauthorized content over the certified content. However, the certification remains valid and the application shows no warnings that unauthorized changes were made.

The success of these attacks depends on the specific PDF viewer. These applications are supposed to alert the reader to any unauthorized changes. The researchers evaluated 26 popular PDF viewers. They were able to break the security of certified documents in 15 of them with EAA. Eight applications were vulnerable to SSA. Only two were not fooled by either attack. The researchers responsibly disclosed these issues and supported the vendors to fix the vulnerabilities.

An additional code injection attack

An incremental update introduces a possibility to extend a PDF by appending new information at the end of the file. The original document stays unmodified and a revision history of all document changes is kept. An example of an Incremental Update is the inclusion of an certification, signature, annotation, or the filling out forms within a PDF.

Only certified documents are allowed to execute high privileged JavaScript code in Adobe products, but the research shows that such code is also executed if it is added as an allowed incremental update. This  allows attackers to directly embed malicious code into a certified document. If you’re wondering why that’s bad, consider that we are now into our fourth decade of malicious Microsoft Office macros.

Permission levels for certified documents

The certifier has a choice of three different permission levels to allow different modifications:

• P1: No modifications on the document are allowed.
• P2: Filling out forms, and digitally signing the document are allowed.
• P3: In addition to P2, annotations are also allowed.

Annotations introduce a different method for a user input by allowing a user to put remarks in a PDF document like text highlighting, strikeouts, or sticky notes. Annotations are not limited to predefined places within the PDF and can be applied everywhere within the document.

Evil Annotation Attack (EAA) breaks P3

The researchers found three types of annotations capable of hiding and adding text and images. All three can be used to stealthily modify a certified document and inject malicious content. To execute the attack, the attacker modifies a certified document by including the annotation with the malicious content at a position of the attacker’s choice. According to the researchers, a victim would have to manually inspect UI-Layer 3 or click on the annotation to detect the modification. And the attacker could even lock an annotation to disable clicking on it.

Sneaky Signature Attack (SSA) breaks P2

The idea of the Sneaky Signature Attack is to manipulate the appearance of arbitrary content within the PDF by adding overlaying signature elements to a PDF document that is certified at level P2. The attacker modifies a certified document by including a signature field with the malicious content at a position of an attacker’s choice. The attacker then needs to sign the document, but does not need to possess a trusted key. A self-signed certificate for SSA is sufficient.

Vulnerabilities

The researchers used additional techniques to make their attacks even less easy to detect. What the attacks reveal is that signatures and annotations can:

• Be customized to appear as a normal text/images above the signed content.
• Be made indistinguishable from the original content.
• And their indications can be hidden from UI layers.

Using EAA and SSA to inject JavaScript

For annotations and signature fields, it is possible to pass a reference to an object containing JavaScript. It is possible to trigger the code execution when opening the page. The victim is unable to prevent this. The attack is not limited to calling up a website but can execute any high privileged JavaScript code. The only requirement is that the victim fully trusts the certificate used to certify the PDF document.

PDF specification

By design, certified documents enable complex and highly desired use-cases and the devil here seems to be in the specification details, which runs to 994 pages! The specification will need to be updated to address the issues found by these researchers. It perhaps also needs simplifying, to avoid further unintended consequences.

For more technical details and the research methodology we advise interested readers to go over the original paper (pdf). You will also be able to find out how your favorite application handles these issues.

The post Falsifying and weaponizing certified PDFs appeared first on Malwarebytes Labs.

You may decide to delete your Twitter account, because social media isn’t for everyone. Perhaps you set up an account to see what the big deal is. Maybe you wanted to hang out with friends but you’re all moving to a new platform. It’s possible the service just isn’t very good and filled with trolls or bad content. Some folks also discover that they’ve posted a little too much personal information down the years and would like a clean break.

Whatever your reason, if you’re looking to delete your account, you’ve come to the right place.

How to delete your Twitter account permanently

Deleting your account on Twitter can be a confusing subject for some, because the process is actually a little more involved and called something else: deactivation. If you don’t follow the steps below, your account won’t be going anywhere. Settle in as we lead you through the process.

Twitter account deactivation

“Deactivation” is a kind of halfway-house for deletion. When you deactivate, Twitter places you in a deletion queue for 30 days.

For that 30 day period, your profile is not visible to anybody and references to it by other people won’t tie back to your account. Eventually, your username is released back into the wild for others to use.

We’re using the web version of Twitter (not mobile, no apps) to give you the most vanilla description possible. These steps may differ slightly from app to platform, but in the main they should be mostly identical.

Directly above the “Tweet” button on the lower left hand side, is a “More” option. Click that, and then click into the “Settings and Privacy” option. Under “Your account”, select “Deactivate your account”.

You now have to confirm and reconfirm a few times to let Twitter know you definitely want to do this. After reading the deactivation information, Twitter will pop a password prompt and then ask you one final time to deactivate the account.

Deleting Twitter accounts from your phone

It’s important to note there are two possible aspects to this on a mobile device, and they don’t have the same end result. You may mean deleting the app from your phone, as opposed to your account itself. If this is the case, remove the app the way you’d normally delete an app from your phone. This is typically whatever form of App Manager your flavour of device is using. Important: This will not delete your Twitter account, it will only remove the app from your mobile. Your account will still be out there, on Twitter.

To delete your account, the steps listed further up will work in the same way if on mobile web. Please note there may still be variance if you’re using various types of Twitter app to manage your account.

How to delete an old Twitter account you cannot access

If you’ve lost access to the email account tied to your Twitter profile, support won’t be able to do anything about it. Not great, but this is one way to prevent trolls simply causing account deletions galore for innocent parties. Apart from anything else, it’s good practice to secure email accounts anyway. Lock them down with two-factor authentication (2FA). Anything which tightens the security of your email will also strengthen Twitter accounts connected to it. Win win!

When your account vanishes, Twitter may retain some data to “ensure the safety and security of its platform and users”. They link to this article as an explanation of what they might keep.

Otherwise, that’s it! You’re all done, and your account is gone…or at least, it will be once the 30 day window passes. Note that the usual Internet rules apply. Old Tweets may well be cached in search engines. Portions or all of your account could be saved in the Internet Archive, screenshots on other people’s computers, by Reddit data archivers, or even on sites like Politwoops. While cached search engine results will likely eventually vanish, and you’ll need to contact the Internet Archive directly to see if there’s anything it can do to help, the rest are out of your hands.

The post How to delete your Twitter account: the deactivation process appeared first on Malwarebytes Labs.