IT News

If you use a Let’s Encrypt SSL/TLS certificate, you may wish to check your account over the coming days. Revocation is coming, and you’ve only got until tomorrow to figure things out.

What’s the deal with free certificates?

If you’re running a website, you want to make sure that it’s HTTPs. It means the visitor’s connection to the site is secure, and snoopers can’t see what they’re doing. This is good for you and most definitely good for them. Browsers typically let you know the site is secure by displaying a padlock in your URL bar.

It used to be fairly expensive to get your hands on a HTTPs certificate, and for years there were problems with using custom domains on certain services. Try as you might, certificates simply wouldn’t work in some cases.

It’s a lot easier these days, and a lot cheaper too. How cheap? Well, free can definitely be considered cheap.

There’s quite a few providers out there offering free HTTPs, and this is a good thing. The onset of mass free HTTPS certificates has, interestingly, meant a few tweaks being applied to infosec advice realms. For example, many organisations now point out that the free certs boom means a rise in phishing sites using HTTPs, so you mustn’t let your guard down. Even so, having more sites with HTTPs than without is a baseline we should be striving for.

What’s happened with Let’s Encrypt?

Emails started landing in customer mailboxes the past few days, like so:

The mail reads as follows:

Please immediately renew your TLS certificate(s) that were issued from Let’s Encrypt using the TLS-ALPN-01 validation method.

We’ve determined that an error made it possible for TLS-ALPN-01 challenges, completed before today, to not comply with certificate issuance requirements. We have remediated this problem and will revoke all unexpired certificates that used this validation method at 16:00 UTC on 28 January 2022. Please renew your certificates now to ensure an uninterrupted experience for your site visitors.

At the same time, the Let’s Encrypt team posted up an initial notification about what had taken place.

At 16:48 UTC on Tuesday Jan 25, 2022, a third party informed Let’s Encrypt / ISRG that, while examining the Boulder codebase, they had noticed two instances of specification non-compliance in our implementation of the “TLS Using ALPN” validation method.

All active certificates that were issued and validated with the TLS-ALPN-01 challenge before 00:48 UTC on 26 January 2022 when our fix was deployed are considered mis-issued. In compliance with the Let’s Encrypt CP, we have 5-days to revoke and will begin to revoke certificates at 16:00 UTC on 28 January 2022. We estimate <1% of active certificates are affected.

It’s worth highlighting that you may be affected even if you don’t have a valid mail address on file. They also have a longer thread complete with questions and answers in the comments section.

The numbers game

They mention that fewer than 1% of active certificates are affected. However, Bleeping Computer has done some digging into numbers and the impact may still be pretty big. According to their statistics, active certificates “surpassed 221 million” as of November 2021 so 1% of that is not to be laughed at.

Users of free SSL services are typically used to ongoing notifications about problems and issues. With any luck, they’ll be just as prepared for this one. That being said, if you use the service mentioned above and this is the first you’ve heard about it, you may wish to get a move on and dig into the issue sooner rather than later.

The clock is most definitely ticking, and you’ve only got one more day to get your certificate affairs in order.

The post Let’s Encrypt to revoke “mis-issued” certificates appeared first on Malwarebytes Labs.

Apple has released patches for iOS 15.3, iPadOS 15.3, and macOS Monterey 12.2 and is urging users to update. The most significant reasons are two actively exploited zero-day vulnerabilities, one of which has a publicly disclosed Proof-of-Concept (PoC).

Using this vulnerability, designated CVE-2022-22587, a malicious app could execute random code with kernel privileges.

Why did it take so long

The zero-day appears to have been found and reported by at least two researchers independently of each other. Apple acknowledged an anonymous researcher, Meysam Firouzi (@R00tkitSMM) of MBition – Mercedes-Benz Innovation Lab, and Siddharth Aeri (@b1n4r1b01) for having reported this flaw.

The two researchers both stated that it took a long time for this bug to be acknowledged and fixed. One of them posted a Proof-of-Concept (PoC) on January 1st.

The other researcher reported the issue through the Zero-Day-Initiative (ZDI) three months ago, waited for two months and then decided to report to Apple directly.

The Zero Day Initiative (ZDI) was created to encourage the reporting of zero-day vulnerabilities privately to the affected vendors by financially rewarding researchers, although there has been some complaints from researchers that they didn’t feel they were taken seriously by the ZDI.

IOMobileFrameBuffer

CVE-2022-22587 is a memory corruption bug in the IOMobileFrameBuffer that affects iOS, iPadOS, and macOS Monterey. IOMobileFrameBuffer is a kernel extension for managing the screen FrameBuffer. An earlier vulnerability in this extension, listed as CVE-2021-30807, was tied to the Pegasus spyware. Another one was listed as CVE-2021-30883 and also allowed an application to execute arbitrary code with kernel privileges. We hope that the input validation has now been curated to makes this impossible in the future.

Actively exploited

Apple acknowledged that it was aware of a report that this issue may have been actively exploited.

Safari Webkit bug

The second zero-day is the Safari WebKit bug in iOS and iPadOS that allowed websites to track your browsing activity and users’ identities in real-time. After a researcher of FingerprintJS disclosed the bug in November, it was assigned the CVE-2022-22594 and has been fixed.

Updates

iOS 15.3 and iPadOS 15.3 fixes a total of ten security bugs. The updates are available for iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation).

macOS Monterey 12.2 patches a total of 13 vulnerabilities in total. The latter also promises to bring smoother scrolling to MacBooks, fixing a previously reported scrolling issue in Safari.

Apple also released security fixes for legacy versions of macOS Big Sur and Catalina.

Stay safe, everyone!

The post Update now! Apple patches another actively used zero-day 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.