IT NEWS

You’ve heard about ransomware, where attackers lock up your files and demand a payment for the decryption key. You may also have heard about ransomware attackers not only locking up your files, but also threatening to release the stolen data in an attempt to get you to pay up.

What you may not have heard about is a relatively new tactic that ransomware attackers are using. Recent reports say attackers are using the stolen data to contact individuals (by social media, email or phone) that have been compromised in the attack.

Ransomware groups are using these direct contact tactics as extra leverage for victims to pay up. They contact staff or customers whose data was exfiltrated in the attack and get them to persuade the victim to pay up, threatening with the release of their personal information if they don’t.

Earlier this week, NBC news published a story about a parent of a child who attended a school overseen by a district that was the victim of a ransomware attack. The attackers emailed the parent and asked him to put pressure on the district to pay up or all the exfiltrated files, including information on him and his son, would be released on the dark web.

Allen School District

Ransomware attackers are always looking for low-hanging fruit. And schools have always been easy targets for ransomware, because of their limited budgets, especially for security. All of which was made worse by the demand for distance learning created by the Coronavirus pandemic.

In September 2021, Allen ISD was hit with a cyberattack, and later the subject of an attempted extortion by the culprits. Allen ISD serves nearly 22,000 K-12 students about 30 miles north of Dallas, Texas.

After consulting external cybersecurity experts, the school officials decide to refuse to pay the hackers’ demands, and even told local media there was no evidence that data had been exfiltrated. That’s despite the fact that the ransomware group said it had obtained personal information from district students, families and staff and attempted to extort Allen ISD out of millions of dollars.

Often, cybercriminals will follow the media coverage about how the incident is being portrayed and if they feel like the victim is not truthful, or misrepresents the situation, they have been known to escalate.

Personal contact

According to the person interviewed by NBC, the district did not tell parents or many staff that they had fallen victim to an attack, at least not before the contact was made by the attackers themselves.

The attackers use whatever contact information they can find, such as employee directories or customer databases, to identify individuals they can pressure. Learning about such an incident from the mouth of the attacker can be extra scary for those that had no clue whatsoever.

Enlist insiders

Another tactic that ransomware attackers use is to contact workers at a company in the reconnaissance stages of an attack to see if they can skip the infiltration stages by using an insider threat.

A new poll from identity protection company Hitachi ID Systems found that 65% of surveyed IT and security executives or their employees have been approached to assist in ransomware cyberattacks. This represents a 17% increase from a similar survey that was done a year earlier. In most cases, the attackers used email and social media to contact employees, but 27% of their approach efforts were conducted via phone calls, a direct and brazen means of contact.

Many ransomware gangs operate as a Ransomware-as-a-Service, which consists of a core group of developers, who maintain the ransomware and payment sites, and recruited affiliates who breach victims’ networks and encrypt devices. Using an insider threat, the developers can save splitting the money with the affiliates, or an affiliate can hand over an accomplished breach without having to use any complicated tools or skip the part of going through failed attempts with the chance of getting detected.

A prime example of this is LockBit which has been known to change the Windows wallpaper placed on encrypted devices to offer “millions of dollars” for corporate insiders who provide access to other networks where they have an account.

Insider risk mitigation

For those that are worried by the thought of possible insider threats, the Cybersecurity & Infrastructure Security Agency (CISA) has created an insider risk self-assessment tool, with which owners and operators or organizations, especially small and mid-sized ones who may not have in-house security departments, can gauge their vulnerability to an insider threat incident.

Stay safe, everyone!

The post Ransomware gangs are recruiting breached individuals to persuade companies to pay up appeared first on Malwarebytes Labs.

Four Attorneys General (AG) from the District of Columbia and the states of Indiana, Texas, and Washington have filed separate lawsuits agains Google for allegedly misleading its users into believing that they are no longer tracking their location when they deliberately pause the “Location History” setting on mobile devices.

All four AG’s allege that users are still being tracked by Google without them knowing unless they also turn off the settings in the Web & App Activity section, too. The deception, they say, happened between 2014 and 2019.

What moved AGs to go after Google

These allegations were based on an exclusive Associate Press report back in 2018 where it was revealed that many Google services on both Android and iPhone devices can store location data even when users set their devices not to. The AP proved this by conducting its own investigation and had its findings confirmed by Princeton computer science researchers.

Google has been upfront, for the most part, about asking permission to use one’s location information, according to the report. However, it’s seen as deceptive that Google explicitly mentions in its own support page that places that the user has been are no longer stored once they turn off Location History, but still somehow tracks users via other apps (e.g. weather apps) without their consent.

The article also mentions that using Google Search on a phone’s browser, something that shouldn’t really rely on a user’s location data, can accurately pinpoint one’s precise latitude and longitude and save it to their Google account.

“If you’re going to allow users to turn off something called ‘Location History,’ then all the places where you maintain location history should be turned off,” Jonathan Mayer, a computer scientist from Princeton, had been quoted saying. “This seems like a pretty straightforward position to have.”

A Yale Privacy Lab researcher, Sean O’Brien, was also referenced saying it is “disingenuous” for the seach giant to continue to record locations even when users disable Location History.

According to the suit, Google employees expressed surprise upon learning that their company is still collecting data via the Web & App Activity setting.

Homing in on dark patterns

The four lawsuits focused on how Google relies on dark patterns, which is defined as subtle cues or tactics that urges one to make choices that might be to their detriment.

You can listen more about dark patterns in our S02E09 Lock & Code podcast episode entitled
“Shining a light on dark patterns with Carey Parker”

One example, with regard to this case, is the repeated prompting to enable location in certain apps while simultaneously claiming that the app won’t function the way it’s intended to if location is not enabled.

“Google also uses dark patterns in ‘in-product’ prompts to enable Google Account settings—i.e., prompts to enable these settings when a user begins to use Google apps and services on a device,” the report reads, “However, these products could properly function without users agreeing to constant tracking. For example, Maps and Google Now did not “need” Location History in order to perform its basic functions and, in fact, both products would continue to function if the user later took a series of actions to disable Location History.”

“Because Google’s statements falsely implied that users were not free to decline Google Account settings if they wished to use certain (often preinstalled) Google products as they were intended, users were left with effectively no choice but to enable these settings.”

The AG also criticized the way the search giant designed the set-up process of its products, which limits or takes away the user’s ability to decide on whether they consent to Google tracking them or not as they use these products.

“Google falsely led consumers to believe that changing their account and device settings would allow customers to protect their privacy and control what personal data the company could access,” said Attorney General Karl Racine of the District of Columbia in a statement. “The truth is that contrary to Google’s representations it continues to systematically surveil customers and profit from customer data.”

Speaking on behalf of Google, José Castañeda said in an email statement: “The Attorneys General are bringing a case based on inaccurate claims and outdated assertions about our settings.”

“We have always built privacy features into our products and provided robust controls for location data. We will vigorously defend ourselves and set the record straight.”

A similar past lawsuit won the day

This isn’t the first time Google received a lawsuit regarding location tracking. In 2020, Attorney General Mark Brnovich of Arizona filed a similar lawsuit to stop Google from continuously tracking its consumers in the state, in spite of them disabling location tracking, so they can be targeted with ads.

A state judge has recently given the suit the green light to move towards trial.

“Great win for Arizona consumers today,” Brnovich said in a statement, “For too long, the company has used deceptive and unfair practices to allegedly obtain users’ location data to help fund its lucrative advertising business. We will not stand by as Big Tech continues to invade Arizonans’ personal privacy.”

The post Google sued over deceptive location tracking appeared first on Malwarebytes Labs.

The American Innovation and Choice Online Act (AICOA), a bill that forbids Big Tech platforms like Apple, Alphabet (Google’s parent company), and Amazon from generally behaving in an anti-competitive manner, was approved by the Senate Judiciary Committee late last week with a 16-6 vote.

US Senator Amy Klobuchar of Minnesota, a primary sponsor of the bill, called this “the first time that a major tech bill on competition has advanced to the Senate floor since the dawn of the internet.”

What is antitrust law?

Antitrust law is a set of statutes aimed at protecting consumers by ensuring that no single company or group of companies gain so much power that they can tip market prices in their favor, or warp the competitive market. In the United States, the Federal Trade Commission (FTC)—in tandem with the Bureau of Economics—is the governing agency that enforces antitrust laws.

Antitrust laws protect against tactics that don’t promote innovation and competition. Countries all over the world have their own version of these laws, such as the Competition and Consumer Act 2010 (CCA) (Australia), the Brazilian Antitrust Law [PDF] (Brazil), the Anti-Monopoly Law of the People’s Republic of China (China), and the Antimonopoly Act (Japan).

Countries with antitrust laws enforce it their own way. The US Department of Justice (DOJ), for example, can file a civil or criminal charge against the companies or the executives heading them.

About AICOA and its possible effects

The American Innovation and Choice Act is a bill aimed at breaking up Big Tech firms and curbing their allegedly monopolistic behavior. It was first introduced by Rep. David Cicilline of Rhode Island and Rep. Ken Buck of Colorado in June 2021 along with four other bills, namely: the Platform Competition and Opportunity Act, the Ending Platform Monopolies Act, the Augmenting Compatibility and Competition by Enabling Service Switching (ACCESS) Act, (which we wrote about previously) and the Merger Filing Fee Modernization Act.

“Right now, unregulated tech monopolies have too much power over our economy,” Cicilline said in a press release last year. “They are in a unique position to pick winners and losers, destroy small businesses, raise prices on consumers, and put folks out of work. Our agenda will level the playing field and ensure the wealthiest, most powerful tech monopolies play by the same rules as the rest of us.”

Unfortunately, AICOA was voted out of the House Judiciary Committee.

In October 2021, three months later, Senators Klobuchar and Chuck Grassley—of Iowa—introduced a similar bill that shares the same name and broad features of Cicilline’s bill. This, eventually, resurrected AICOA from the grave.

This bill prohibits companies—which fit in a criteria that would be set out by the FTC pertaining (but perhaps not limited) to active userbase and market cap—from discriminating against other businesses that rely on their platform by favoring their own products and services.

If the Senate passes the bill, it would make it illegal for companies with their own marketplace, such as Amazon, Apple, and Google, from favouring their own products and services over other competitors. Amazon, for example, would be barred from ranking its AmazonBasics brand higher than other brands in search results on the Amazon market.

But AICOA’s implications could go beyond this, as many have pointed out on Twitter:

With the American Innovation and Choice Act passing a Senate committee vote and making its way to the full Senate, in spite of its many, many criticisms, you can expect the fiery debate to go on from both sides. Note, however, that the current administration has yet to take a stance on this matter.

The post Senate Committee passes new antitrust bill aimed at Big Tech companies appeared first on Malwarebytes Labs.

This blog post was authored by Roberto Santos

KONNI is a Remote Administration Tool that has being used for at least 8 years. The North Korean threat actor that is using this piece of malware has being identified under the Kimsuky umbrella. This group has been very busy, attacking political institutions located in Russia and South Korea. The last known attack where KONNI Rat was used was described here.

We found that KONNI Rat is being actively developed, and new samples are now including significant updates. In this blog post, we will cover some of the major changes and explain why the security community should keep a close eye on it.

Simplified Attack Chain

The attack usually starts leveraging a malicious Office document. When this document is opened by the victim, a multistage attack is started, involving various steps. But these steps are just the way that the attackers manage to accomplish tasks to elevate privileges, evade detection and deploy required files. As we described in a previous blog post, the attack chain could be summarized in the following diagram:

The attack usually starts leveraging a malicious Office document. When this document is opened by the victim, a multistage attack is started, involving various steps. But these steps are just the way that the attackers manage to accomplish tasks to elevate privileges, evade detection and deploy required files.

The final goal of the attack is installing what is called KONNI Rat, which is a .dll file supported by an .ini file. In a nutshell, the .dll file contains the functionality of the RAT, and the .ini file contains the address of the first C&C server. KONNI Rat’s general behavior remains almost the same as previous versions, but there are changes we will cover below.

Rundll no longer supported

In previous KONNI Rat samples there were two branches. One handles if the malware was launched using a Windows service, and the other handles the execution through rundll. The next image shows these two old branches, with the strings svchost.exe and rundll32.exe visible:

However, new samples will not show these strings. In fact, rundll is no longer a valid way to execute the sample. Instead, when an execution attempt occurs using rundll, an exception is thrown in the early stages.

In early stages of our analysis, we thought that they were using the classic process name check, or any other usual technique. The reality is far simpler and brilliant; the actual export just implements the SvcMain prototype so the program will break at some point when accessing one of the arguments.

In the previous image we see the state of the machine at the moment that this exception is thrown. RDI at that point should contain a pointer to the service name. The exception happens because the Service Main function meets one prototype and rundll32 will expect another different prototype:

VOID WINAPI SvcMain( DWORD dwArgc, LPTSTR *lpszArgv )

VOID WINAPI runnableExport(HWND hwnd, HINSTANCE hinst, LPSTR lpszCmdLine, int nCmdShow)

Basically, at some point of the execution, hinst will be treated as lspzArgv, causing the exception. But why did the attackers delete that functionality? There are multiple benefits.

First of all, we have not seen any recent attack that used rundll. In fact, the only way that the attackers launched KONNI Rat in recent campaigns involves registering a Windows service. So the rundll32 branch wasn’t being used in real world attacks.

But there is another big reason in how sandboxes will fail in collecting the real behavior of the sample, as it just cannot execute that way.

Strings are now protected using AES

Multiple malware families protect their strings in order to defeat most basic string analysis. KONNI wasn’t an exception, and also used this technique. Old samples were using base64 for obfuscation means. Also, they were using a custom alphabet. This custom alphabet was changed from time to time in order to make the decoding task more difficult:

Now, the attackers made a major change in that regard by protecting the strings using AES encryption. The algorithm followed by new Konni RAT samples could be represented as follows:

The reason behind that change is clear. As the key used for decryption is the service name, samples run by different service names will not work properly. Moreover, having only the sample without knowing the service name becomes useless, as these strings contain core information about the sample behavior.

Files are also protected using AES

KONNI Rat makes use of various support files when it is executed. One of these files is the .ini file, which contains the primary C&C server, but there are others like the .dat file that is supposed to be dropped eventually, and temporal files that are used to send some basic information about the computer.

Our tests reveal that all of these files are dropped and protected using AES. Cleverly, they reused the algorithm used for string protection, making the file layout identical to the protected strings layout, as they appear in raw memory:

As can be seen from the diagram, the file itself contains the IV and the encrypted data. The key used is extracted from its original filename. In some cases, the names match with the service name, so the keys used in the .ini and the .dat files are the result of applying a SHA256 to the service name as well.

Also, files sent to the C&C server are protected using AES. The IV is generated using a QueryPerformanceCounter API CALL. Filenames are generated concatenating 2 letters that represent the data with the current timestamp, followed by the extension. Furthermore, they will use this newly generated name as AES key, so they send this name through the request to the C&C server.

In that regard, as the filename is generated automatically using the timestamp, identical files will produce different request contents, as they were encrypted using that filename. Network signatures could also fail to detect the malicious activity, due to that.

Other obfuscation techniques

As we found some samples that were protected just by the means that we described before, we also have found others that were making use of an unidentified packer. We would like to share some of our notes regarding that packer, as others could find it useful in identification and attribution tasks.

Contiguous instruction obfuscation

The flow of the obfuscated program will make use of series of push-call pairs of instructions, where the pushed values will indicate the actions that the program will take. An image can better explain that:

In particular, we find it interesting that the attackers have placed random bytes between these pairs. This silly trick causes wrong code interpretation for decompilers that will assume that bytes after the push instruction are part of the next instruction. The image below shows how IDA fails in analyzing the code:

Obfuscated program flow

The used packer will obfuscate the original program flow. This is accomplished in various steps. The first required step is to find the Image Base value, placed in a fixed location and the RIP (Instruction Pointer) value.

Once the packer knows these two values, it will start jumping from one place to another, making analysis harder. For that, it will store in some register value of the next address to jump in registers. The value of these registers is calculated right after the jmp instruction, using structures like POP [reg] – JMP [reg] or ADD [reg1, reg2] – JMP [reg1]. Note that decompilers will fail in displaying the real flow, as the jumping address is determined by a somehow undefined register.

The combination of these simple techniques ends in the packer being now in control of the flow, but statically the decompiler cannot represent the path that the code will follow. Finally, the packer will execute a big amount of junk instructions and eventually will execute the real interesting code. For instance, the original code will take no more than 20 instructions between GetProcAddress calls in IAT building tasks. but the packed code executes more than 30,000 instructions.

According to our threat intel data, most recent attacks are not making use of that packer anymore.

Conclusion

As we have seen, KONNI Rat is far from being abandoned. The authors are constantly making code improvements. In our point of view, their efforts are aimed at breaking the typical flow recorded by sandboxes and making detection harder, especially via regular signatures as critical parts of the executable are now encrypted.

Malwarebytes users are protected against this attack.

IOCs

A3CD08AFD7317D1619FBA83C109F268B4B60429B4EB7C97FC274F92FF4FE17A2
F702DFDDBC5B4F1D5A5A9DB0A2C013900D30515E69A09420A7C3F6EAAC901B12

The post KONNI evolves into stealthier RAT appeared first on Malwarebytes Labs.

DazzleSpy, a piece of malware that attacks macOS, was discovered last fall by researchers at ESET, and now those researchers have released more detailed findings.

DazzleSpy, according to the researchers at ESET, was being spread via watering hole attacks via pro-democracy websites in China. It infected machines using a combination of two vulnerabilities, one in WebKit (the framework that powers Safari) and one in macOS (a privilege escalation vulnerability).

Now, if this sounds familiar, it’s because you’ve been paying attention—this is exactly the same technique as that used by the CDDS (aka Macma) malware that was described by Google in November, even down to spreading through Chinese pro-democracy sites.

The new malware got a foothold via CVE-2021-1789, exploited via a JavaScript file named mac.js loaded by the malicious site. This led to the in-memory execution of native Mac code, which exploits CVE-2021-30869 to gain root privileges. With this high level of privileges, the malware drops its payload onto the machine.

That payload is a very full-featured backdoor, providing the attacker the capability to run any arbitrary command on the infected Mac, start a remote screen viewing session, download files from the Mac, steal the keychain, send synthetic mouse clicks, etc. The full list of capabilities is a bit different than what Google described for CDDS, but it’s important to keep in mind that arbitrary shell command execution is an extremely powerful capability. Although the DazzleSpy implant doesn’t directly support taking screenshots, for example, that’s not hard to do via the screencapture command in the shell.

Are CDDS and DazzleSpy the same?

These two pieces of malware are quite different. The code is very different, and the capabilities are different. They’re also very different in terms of what gets installed. CDDS, for example, distributes multiple executable files across a couple different folders, while the DazzleSpy payload is a single, smaller file (which may optionally also install the open-source KeySteal exploit on older systems, in order to steal keychain data).

Thus, there’s little doubt that these are distinctly different malware, written from different code bases.

However, since both were distributed through the same two macOS vulnerabilities, through pro-democracy websites in China, it’s highly likely these are made by the same folks. The most likely scenario is that this is Chinese government malware, being used for the purpose of tracking democracy advocates.

Why there would be a need for two different pieces of malware is unclear. Perhaps there was some dissatisfaction with the CDDS code, so new malware was written. Perhaps both were run concurrently to see which performed better. Perhaps it’s part of a plan to change the code periodically as a means of avoiding detection.

Then again, perhaps the similarities in usage don’t actually indicate anything at all.

Can we blame the Chinese government?

Attribution is hard, and it’s very difficult to say where a particular malware sample originated without a lot of corroborating data. For example, threat actors have been known to insert Chinese- or Russian-language strings into executables in an attempt at misdirection.

However, there’s a long history of suspected Chinese government use of malware to track oppressed groups, spanning many years. To cite one example, a very similar case occurred in early 2012, in which two different pieces of malware were discovered using Java vulnerabilities to infect Macs. Tibet (aka MaControl), discovered in March 2012, and Sabpab, discovered in April 2012, were both used to target Tibetan activists, at a time when Tibetan protests of Chinese government oppression were at a peak.

In the case of DazzleSpy, the presence of Chinese strings in the executable are far from incontrovertible evidence of Chinese government involvement. The pattern of usage, though, makes it extremely likely.

Mac malware gets an early start in 2022

DazzleSpy is actually not the first new Mac malware to appear so far this year, despite the fact that it’s only January. SysJoker coverage appeared a couple weeks before. Discovered by Intezer during an investigation into a Linux server infection, this was the official first Mac malware of 2022. However, there are some questions about whether this is actually in the wild – questions that are borne out by the lack of any detections at all in the wild. This may have been a proof-of-concept for Mac that hadn’t actually been released yet. (Malware creators sometimes upload early builds of their malware to VirusTotal, to see if any antivirus engines detect them, which can lead to discovery of those pre-release programs by researchers.)

It’s too early to make any assumptions about what this means for malware in 2022, though. It’s not uncommon for Mac malware research to follow a pattern of multiple discoveries early in the new year, followed by less frequent discoveries as the year continues.

Conclusion

If you have visited a pro-democracy Chinese website and think you might be infected, run a scan with Malwarebytes. It will detect this as OSX.DazzleSpy.

Alternately, you can also look for it manually. The items you’re most likely to see are:

/var/root/Library/LaunchAgents/com.apple.softwareupdate.plist
/var/root/.local/

This plist file and the .local folder are created by the malware when run as root, and the vulnerabilities used to drop the malware do involve root escalation. This is also a good place to drop these files, as it’s a location you cannot view within the Finder. You can only access the contents of /var/root/ by using something that operates as the root user, such as sudo on the command line.

However, it’s also possible the malware could get dropped into the user folder, in which case you’ll see these paths instead:

~/Library/LaunchAgents/com.apple.softwareupdate.plist
~/.local/

The post New DazzleSpy malware attacks macOS appeared first on Malwarebytes Labs.

Microsoft has published a list of 25 group policies that administrators should not use in Windows 10 and Windows 11 as they do not provide optimal behavior or cause unexpected results.

Since November 2015 when Windows 10 was first introduced, there have been many changes and some of them have caused Windows Update policies to interfere with performance, while others have been replaced with different versions.

Microsoft has identified which older policies have become irrelevant or replaced with a better option. The policies in this article are all more or less tied to Windows updates. Notifications, the ability to dictate the behavior of update downloads, installation, and restarts, and the settings experience have all shifted dramatically from what was originally released in the early Windows 10 versions.

This posting from Microsoft helps bring clarity to many years of frustration experienced by IT admins and Windows enthusiasts that wanted or needed to control the Windows Update experience.

As Alex Smith, Technical Product Manager at Malwarebytes, puts it:

“I am happy to see Microsoft finally clear the air on Group Policies for Windows Update. IT admins and Windows enthusiasts like myself have been frustrated trying to control the Windows Update experience on managed devices for years. At times, we questioned our technical sanity since the results wouldn’t align with the group policies being used. Now, that will be a thing of the past.”

Group policies

Administrators can work with Group Policy Objects (GPO) to customize a computer’s functions and the user experience. Designed to be used mostly by network administrators, group policies define what specific users or a group of users can do on machines in their network, restricting or allowing features as necessary.

Where can I find the policies?

To change the Group Policies’ settings you will typically use the Group Policy Editor. The Group Policy Editor is a utility that allows you to configure Group Policy settings for a Windows PC or a group of PCs. Note that this is only available for Windows Pro versions.

Probably the easiest way to open the Group Policy Editor is by using search in the Start menu. First, click the Start button, and when it pops up, type gpedit and hit Enter when you see an entry called Edit Group Policy in the list of results.

Windows 11

To make life easier for Windows 11 users, Microsoft created a sub-folder under Windows Update to specify Legacy Policies. Please note that these sub-folders are only available in the Windows 11 ADMX templates. ADMX files are XML‑based administrative template files, that are language‑neutral and support multilingual display of policy settings. Microsoft Windows manages ADMX files from the central store that is a central location in the domain.

While admins need to select an OS-specific set of ADMX files for the central store, Microsoft has provided a method that admins can use to manage the policies for the other operating systems in their environment.

Deprecated policies

You can find the complete list of deprecated policies and suggested replacements in Microsoft‘s article. This list shows which policies are not recommended, why they are not recommended, and how to get the same or similar behavior with either default settings or recommended policies. This list can really help Windows administrators to review their existing group policy configurations and replace outdated policies with newer variants that provide more control and expected behavior.

A quick overview was provided in a tweet by Aria Carley (@ariaupdated) who wrote the article.

The post Windows Update has changed over the years. Here are 25 group policies to avoid appeared first on Malwarebytes Labs.

Last week on Malwarebytes Labs:

• CISA calls for urgent action against critical threats
• Red Cross begs attackers to “Do the right thing” after family reunion service compromised
• Update now! Chrome patches critical RCE vulnerability in Safe Browsing
• Combatting SMS and phone fraud: UK government issues guidance
• Open Subtitles breach: The dangers of password reuse
• Steer clear of gift card balance scams
• Browsers on iOS, iPadOS and Mac leak your browsing activity and personal identifiers
• Mac users, update now! “Powerdir” flaw could allow attackers to spy on you
• Campaign launched to delay social media end-to-end encryption
• Cybercriminals’ friend VPNLab.net shut down by law enforcement
• Why we don’t patch, with Jess Dodson: Lock and Code S03E02
• Nintendo warns of imitation websites and suspicious hardware
• Infamous dark net carding site UniCC to close
• REvil ransomware gang busted by Russian Federal Security Service

Stay safe!

The post A week in security (January 17 – 23) appeared first on Malwarebytes Labs.

Back in October 2021, Microsoft announced in an email to customers that it planned to disable Excel 4.0 macros by default to protect customers from malicious documents.

Last week—after three decades of macro viruses, and three decades of trying to convince every single Excel user individually to disable macros—Microsoft made the change.

Good news

Excel 4.0 macros, aka XLM macros, were first added to Excel in 1992. They allowed users to add commands into spreadsheet cells that were then executed to perform a task. Unfortunately, we soon learned that (like any code) macros could be made to perform malicious tasks. Office documents have been a favorite hiding place of malicious code ever since.

In July 2021, Microsoft released a new Excel Trust Center setting option to restrict the usage of Excel 4.0 (XLM) macros. As planned, this setting is now the default when opening Excel 4.0 (XLM) macros.

Administrators also have the option to completely block all XLM macro usage (including in new user-created files) by enabling the Group Policy, “Prevent Excel from running XLM macros”, which is configurable via Group Policy Editor or registry key.

Backward compatibility

For backward compatibility reasons the feature was never removed, despite being superseded by Visual Basic for Applications (VBA) just one year after XLM macros were introduced.

I understand the argument in favor of keeping it back then, but why keep it enabled by default for so long after, when so few people use it? Microsoft could have made it so that those that needed Excel 4.0 macros had to turn the feature on, and the rest of us (the overwhelming majority of Excel users) could have been more secure without having to remember to turn it off.

Will you miss it?

It is very, very unlikely you will miss Excel 4.0 macros. XLM was the default macro language for Excel through Excel 4.0, but beginning with version 5.0, Excel recorded macros in VBA by default, although XLM recording was still allowed as an option. After version 5.0 that option was discontinued. All versions of Excel are capable of running XLM macros, though Microsoft discourages their use.

Now—almost 30 years after they were made obsolete—it’s fair to stay that the biggest users of Excel 4.0 macros are probably malicious threat actors.

Abuse cases

Attackers have always liked Office macros because they provide a simple and reliable method to spread malware using legitimate features, and without relying on any vulnerability or exploit. XLM macros have been used to drop many well-known malware families, including ZLoader, TrickBot, BitRat, QBot, Dridex, FormBook and StrRat, among others.

But this does not mean that now all documents are safe to open now. Malware authors are moving on to use other vulnerabilities like CVE-2017-11882.

Security over backward compatibility

Despite the shared joy about this security enhancing rollout, it raises the question of when security should overrule backward compatibility? Microsoft must have better things to do than fix obsolete features from the past century.

Wouldn’t it have been preferable if the step up to VBA in 1993 had been less steep, so we could all forget about 4.0 and move on to the latest version without having to look over our shoulder? Or perhaps Microsoft could have disabled this potentially dangerous feature decades ago and left it to those who actually wanted it to turn it back on?

If history has taught us anything, it’s that the incentive to enable something you need is a lot stronger than the incentive to disable something that might be potentially dangerous.

Stay safe, everyone!

The post Microsoft is now disabling Excel 4.0 macros by default appeared first on Malwarebytes Labs.

Avid readers of the Malwarebytes Labs blog will be well aware of QR code scams.

Take, for example, that QR code scam in the Netherlands that victimized at least a dozen (and definitely more) car owners. It went like this: Someone approaches you and says they want to pay for their parking but can’t find payment terminals that accept cash. They then ask you to kindly pay on their behalf—say, $5 USD—by scanning a QR code with their bank’s app after they hand you the money. Sadly, that ends up with you parting with a lot more than $5.

And then last week, the Austin Police Department in Texas released a scam alert on Twitter about “pay-to-park” scams involving a QR code that directs users to a phish.

Now, the FBI has released a public service announcement (PSA) about criminals using malicious QR codes.

Be extra vigilant when faced with a QR code

QR codes provide contactless access to a product or service, and they’ve proven useful and very convenient especially with the pandemic still ongoing. The problem is that there’s no way of distinguishing between a genuine code and a malicious one. Cybercriminals know this too and have capitalized on it.

“Cybercriminals tamper with both digital and physical QR codes to replace legitimate codes with malicious codes,” notes the FBI alert. “A victim scans what they think to be a legitimate code but the tampered code directs victims to a malicious site, which prompts them to enter login and financial information. Access to this victim information gives the cybercriminal the ability to potentially steal funds through victim accounts.”

QR codes can also be embedded with malware. Once scanned, the malware can be dropped onto the device and executed. Depending on the malware, criminals could steal personal and financial information (if you bank using your smartphone) from you, make your device part of a botnet, or spy on you.

Criminals can also replace legitimate QR codes in establishments to mislead users and direct them to a potentially malicious site. In certain cases where a contactless way of paying is available but does not use QR codes, it would be easy for criminals to just add their QR code sticker and make users believe that they should scan it.

This is exactly what happened in the fraudulent “pay-to-park” scheme.

How to protect yourself from QR code scams

The FBI has recommended the following steps that users should keep in mind:

• Check the URL to ensure you’re being directed to a site where you’re supposed to be directed once you scan a QR code. Watch out for misspellings in the URL.
• When you see a QR code in a shop and want to scan it, make sure you check for signs of tampering, such as a sticker over the QR code itself.
• Download an app from your go-to app store, not from a QR code.
• Use the built-in scanner through your smartphone’s camera to scan for QR codes. There is no need to download another one from the app store as there are fake QR code scanners, too.
• If you receive a QR code either in the mail or sent to you by a friend, get in touch with them first and verify if they have indeed sent you the code.
• If you can, avoid making payments via a QR code. There are better and more secure ways of paying.

Stay safe!

The post Warning issued over tampered QR codes appeared first on Malwarebytes Labs.

It’s not been a great couple of weeks for people looking to get in on NFTs. Missing apes, rug-pulls, it’s all go in non-fungible token land. The latest mishap has come to light, in the shape of bad planning and the slowly shifting impermanence of link ownership.

Rockstar Ozzy Osbourne announced “CryptoBatz” just a week or so ago. Whoever put the marketing campaign together deserves some sliver of credit for self-consciously poking fun at aspects of NFT culture in the promo video.

“He started thinking, started working…locked away in his library for weeks working on something big. He teamed up with a company called Sutter Systems. Their mission was to create an NFT project that wasn’t another celebrity rug pull.”

Well, they didn’t end up with a rug pull but they did end up with an accidental phish-ball rolling unstoppably downhill. But how?

Minting some Batz

Close to 10,000 digital NFT bats were supposed to be put up for grabs on an NFT marketplace. The bats reference a rather infamous moment in Osbourne’s career, and allow the owner to “breed” them with NFT images from other collections. A bit like Pokemon on the blockchain, perhaps.

As with any NFT project looking to gain leeway with the general public, it has a Discord server. There’s a good chance pretty much any digital project has a similar setup, and this is nothing unusual. However, things started to go wrong in a hurry – and it’s all down to the CryptoBatz Discord.

Discord in Discord Land

Not long after the bats went on sale, people started to complain about phishing links from official sources. Could it be true? Had this somehow turned into an incredibly bizarre rug-pull? The answer is no. It was something much more mundane.

The CryptoBatz project had, at some point, changed at least one of the URLs it was working with. They switched out the old Discord vanity URL for a new one, but didn’t delete old tweets containing the now outdated URL. Can you guess what the scammers did?

As per the above tweet, the scammers set up a new Discord server using the old CryptoBatz vanity URL. As potential victims naturally came across tweets with the old link in it, they were then directed to the (bogus) Discord server.

From there, it’s a short step to having their cryptocurrency wallets connected to things they shouldn’t be. End result: drained wallets, lost funds, CryptoBatz everywhere.

The financial impact of a cryptocurrency phish

According to this Verge article, the scammers made off with quite a bit of bank. Transactions to the tune of around $40,000 were sent to a digital wallet containing “more than $150,000”. The team behind the project claim they’re not responsible for “scammers exploiting Discord”, though it’s hard to argue against them having simply deleted outdated links in the first place. No links, no scam able to take place.

All the same: the back and forth doesn’t really help the victims. Even a project fronted by known entities can easily wander into a bad NFT situation, an area of digital business where it’s all a bit Wild West by default.

I suppose we must now add “Always check the most up-to-date link on any social feed related to NFT sales” to the growing list of tips to avoid gracing your digital wallet with an Electric Funeral.

The post Discord scammers go CryptoBatz phishing appeared first on Malwarebytes Labs.