IT NEWS

If you’re running Windows 10, it’s time to stop delaying those patches and bring your systems up to date as soon as possible.

Bleeping Computer reports that a researcher has come up with a bypass for an older bug, which could serve up some major headaches if left to fester. Those headaches will take the form of unauthorised admin privileges in Windows 10, alongside creating new admin accounts and more besides.

What happened the first time round?

Back in 2021, Microsoft patched an exploit which had been in use since mid-2020. Classed as “high-severity”, “CVE-2021-1732 – Windows Win32k Elevation of Privilege Vulnerability” allowed attackers to elevate privileges to admin level.

Fooling potential victims by having them open bogus email attachments is all it would take to get one foot in the door via code execution. It popped up in a targeted attack related to the Bitter APT campaign. According to the report, numbers were “very limited” and struck victims in China.

What’s happening now?

Multiple exploits have dropped for another elevation of privilege vulnerability known as CVE-2022-21882. This is a bypass for the previously mentioned CVE-2021-1732 which was fixed back in February 2021. CVE-2022-21882 was fixed by Microsoft via updates from January 2022. However, sys admins out there may well have skipped the updates due to various bugs which came along for the update ride.

Time to get fixing things?

It is absolutely time to get fixing things. The exploit is now out there in the wild, and as Bleeping Computer notes, it “affects all supported support versions of Windows 10 before the January 2022 Patch Tuesday updates”. 

Writers at Bleeping Computer were able to get it to work in testing, and others have confirmed it for themselves:

Is there any reason to wait for February’s Patch Tuesday?

If you’re one of the hold-outs who ran into errors last time around, waiting isn’t advisable. Microsoft already issued an OOB (out of band) update to address the multiple errors caused by the January patch. As per Microsoft’s January 17th notification about the release:

“Microsoft is releasing Out-of-band (OOB) updates today, January 17, 2022, for some versions of Windows. This update addresses issues related to VPN connectivity, Windows Server Domain Controllers restarting, Virtual Machines start failures, and ReFS-formatted removable media failing to mount.”

Things being what they are, it’s likely time to get in there and apply the OOB update (if you haven’t already) and put this one to rest.

Microsoft is putting a fair bit of work into figuring out where weak points lie in the patching process, making use of its Update Connectivity data. The current estimate is a device needs a minimum of two continuous connected hours, and six total connected hours after an update is released to reliably make it through the updating process.

If this sounds like your network, and if you’re still waiting to take the plunge, you’ve hopefully got little to lose by making that big update splash as soon as you possibly can.

The post Apply those updates now: CVE bypass offers up admin privileges for Windows 10 appeared first on Malwarebytes Labs.

Last week on Malwarebytes Labs:

• QNAP update stops Deadbolt ransomware, annoys some users, starts debate
• Big Mother is watching: What parents REALLY think about tracking their kids
• Update now! Apple patches another actively used zero-day
• Let’s Encrypt to revoke “mis-issued” certificates
• North Korea’s Lazarus APT leverages Windows Update client, GitHub in latest campaign
• Ransomware gangs are recruiting breached individuals to persuade companies to pay up
• Apple fixes Mac bug that could have allowed takeover of webcams and browser tabs
• New DazzleSpy malware attacks macOS
• KONNI evolves into stealthier RAT
• Senate Committee passes new antitrust bill aimed at Big Tech companies
• Google sued over deceptive location
• Windows Update has changed over the years. Here are 25 group policies to avoid
• Microsoft warns of phishy OAuth apps
• Cyberinsurance companies don’t want to pay out for “acts of war”
• Dark Souls servers taken offline over hacking fears
• Discord scammers go CryptoBatz phishing
• Warning issued over tampered QR codes
• Microsoft is now disabling Excel 4.0 macros by default
• Segway store compromised with Magecart skimmer
• Data Privacy Day: Know your rights, and the right tools to stay private

Stay safe!

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

When we refer to hijacked verified profiles on Twitter, it’s most commonly some sort of Elon Musk themed scam. The hijackers compromise the account, switch the picture to Elon, and then start spamming cryptocurrency links. Alternatively, they may keep the account as it is and spam images claiming Elon has approved a giveaway or something similar.

Well, times have changed on the big blue bird app. Whisper it, but Elon tributes may no longer be the hottest way on the block to earn some scam money. Instead, we’re seeing verified profiles compromised to promote and sell NFTs instead.

Forging a new career in pixel art

At some point on Thursday a verified profile belonging to Siobhán McSweeney, well known Irish actor, started to behave a little unusually. That is to say, promoting a range of pixel art cats known as “GrumpyKatz”.

The tweet reads as follows:

Giveaway time!

I am working with @grumpykatznfts to giveaway 15 SOL ($1500)

To enter:

• Follow me & @GrumpyKatzNFT
• Like & RT
• Tag 3 friends

We don’t know if the linked pixel art project is “genuine” or not, as there’s very little to go on from the profile itself. Another tweet (now deleted) suggested people should send a direct message to the account. Whoever was running this scam would likely have phished hopefuls via the hijacked Twitter account.

A short while after, the profile finally completed its full transformation. Behold the weirdly drawn ape of doom set as the profile picture:

You’ll notice the bio blurb has been altered to fit in with the general NFT theme taking place. It says:

Building an NFT community | 450,000 supporters | NFT promoter | DM for promo

The profile location has also been set to “Metaverse”, because of course it has.

Getting up to some monkey business

Followers of the actor were initially a bit surprised by the sudden interest in all things cryptocurrency. Had she decided to hop on the bandwagon? Or was something else at work? People weren’t sure and there was no 100% confirmed answer until a little earlier today.

This blog is safe for work so if you wish to see her, um, very enthusiastic condemnation of the account compromise, click here. At time of writing, some of the NFT/metaverse related Tweets are still on her profile.

What caused this, and how can you protect your Twitter account?

As to how it happened, there’s no indication just yet.

Verified profile accounts need to have two-factor authentication (2FA) enabled to be verified in the first place. But we’ve seen enough sneaky examples of people bypassing 2FA on different platforms previously.

Twitter offers a variety of options where it’s concerned: mobile, app, and security key. Perhaps the actor is using SMS codes and somebody performed a SIM swap attack. Maybe she uses an auth app but was taken to a phishing page which also asks for the time sensitive code.

I suspect we won’t find out. Even so, this is a good time to go check your login and verification settings on Twitter whether verified or not. You don’t want to accidentally wander into whatever currently passes for a metaverse, no matter how many free cats they claim to be giving away.

The post Actor’s verified Twitter profile hijacked to spam NFT giveaways appeared first on Malwarebytes Labs.

You’ve likely fallen for it before—a simulated test sent by your own company to determine whether or not its employees are vulnerable to one of the most pernicious online threats today: Phishing.

Phishing has evolved in recent history, and as scammers have rolled out increasingly clever—and increasingly complex—phishing lures, companies have had to respond with increasingly better defenses. Most employees at large companies have a phishing “reporting” button that is embedded directly into their email client, and nearly just as many employees might have a phishing email detection system integrated into their email client, so that when a “fishy” email comes through (sorry), they are warned with a small notification at the top of the email.

But one of the primary defenses used today by countless companies is the practice called “contextual” or “embedded” training, and it’s a practice that, as we learn today on the Malwarebytes podcast Lock and Code with host David Ruiz, might not work.

It could be a little worse than that, actually—this practice could make things worse.

That’s one interpretation coming out of a 15-month long study run by several PhD candidates at the ETH Zurich university in Switzerland. By working with a company of tens of thousands of employees, these researchers were able to test what phishing defenses actually provided the best results, and after experimenting with embedded and contextual training in a voluntary format, they learned that the phishing resilience of those test subjects actually diminished.

Daniele Lain, who helped conduct the phishing research, told us:

“What we saw is that, very interestingly, if you do it like this—when you get training appearing when you fall for simulated emails—somehow it becomes much more likely that you actually fall for the subsequent phishing attempts.”

Daniele Lain

To say it’s a surprise is an understatement.

Tune in to hear all this and more on this week’s Lock and Code podcast by Malwarebytes Labs.

You can also find us on Apple Podcasts, Spotify, and Google Podcasts, plus whatever preferred podcast platform you use.

The post How a few PhD students revealed that phishing trainings might just not work: Lock and Code S03E03 appeared first on Malwarebytes Labs.

Every year on Data Privacy Day, we’re greeted with countless arguments about the absolute merits of data privacy (protections good, invasions bad), but we rarely see a faithful, factual accounting for the biggest data privacy conundrum facing billions of people every single day: Should parents invade the data privacy of their children and digitally track their activity in order to provide them with a little more safety?  

On Data Privacy Day this year, we decided to investigate the issue ourselves, and we found that, for the majority of parents we asked, the answer was a simple “Yes.”  

But there’s some nuance here, as parents revealed that their invasions of data privacy against their children typically happened when their children began to face new threats, whether online or in the real world. If a kid is old enough to enter a URL into a web browser, then they’re old enough to have that web browsing activity tracked, our parents revealed, and the same goes for opening a social media account, watching YouTube, and potentially just moving about the neighborhood, which could be tracked through GPS locations.  

Privacy invasions, then, are reactionary, and not planned. They are a response to a changing, frightening world that every parent has faced before, but that only parents today can push back against through the use of modern, digital tracking. 

Our survey

To learn more about what parents believe, earlier this month we asked our newsletter subscribers to fill in a short, anonymous survey about the monitoring they do of their kids.

We asked parents if they monitored their children’s location (GPS), web browsing, computer games, YouTube activity, social media posts, email, or WhatsApp or other message apps; the ages they started and stopped the monitoring; whether they told their children they were being monitored or not; and the age they thought children should be allowed to start using social media.

As with any online survey, you should understand the potential biases of the population involved: The respondents were a self-selecting group of individuals who care enough about technology, security, and privacy to have subscribed to a newsletter about it, and to respond to a survey about parental attitudes to electronic monitoring.

899 parents filled in the survey, and most of them had children aged nine years old or older.

Digital tracking is the norm

The survey suggests that using some form of electronic monitoring to keep tabs on children is the norm.

84% of our respondents admitted to some form of electronic monitoring of their children, 70% used at least one form of monitoring they had told their child about, and 36% used at least one form of monitoring they had not told their child about.

Parents who monitor tend to use more than one kind of monitoring, whether they tell their children or not. 54% of parents use at least two forms of monitoring with their child’s knowledge, and 24% of parents use at least two forms of monitoring without their child’s knowledge.

As you would expect, the number of parents monitoring multiple activities declines as the number of activities increases—more parents monitor one activity than two, more monitor two than three, and so on. There is one exception though. About 7% of the parents we surveyed monitored all seven of the different activites we asked about without their child’s knowledge.

What parents monitor

There is surprisingly little variation in the amount of parents monitoring each activity we asked about, with every individual activity being monitored by between about 30% and 40% of parents. The most common thing for parents to monitor electronically was their child’s physical location (GPS), and the least common thing to monitor was messaging apps. This may reflect where parents see the most potential harm, or it may simply reflect how easy some kinds of monitoring are compared to others. Of the activities we surveyed parents about, GPS is probably the easiest thing to monitor, and messaging apps the hardest.

Almost a quarter of the parents surveyed said they monitored their children’s web browsing without telling them.

When monitoring starts

As you might expect, the age at which parents start different types of electronic monitoring tends to reflect the ages at which children gain some level of independence in different areas of their lives.

Some parents start using electronic monitoring when their children are 3-5 years old, and others wait until their children are in their late teens, but the most common time to start electronic monitoring is when children are between 9 and 11, although it skews a little younger for computer games, and a little older for social media.

When monitoring ends

While there is lots of variation in the age when monitoring starts, there isn’t in when it stops. Parents, it seems, are very unlikely to stop monitoring their children before their eighteenth birthday.

Social media

Our respondents were also aksed when they thought children should be allowed to open Facebook, Twitter, Instagram, TikTok, and YouTube accounts.

Most of the popular social media platforms have a minimum age limit of 13 years, but only about 30% of our respondents thought that children were old enough to open a social media account at that age or younger. While more parents thought 15-17 was a better age, the biggest cohort by far—between about 40 and 50% of all the parents surveyed, depending on the platform—thought the minimum age should be 18 or older.

YouTube, which is popular with kids and has very different functionality than the other platforms in our list, skewed a little younger. And TikTok, the newest platform and perhaps the least well understood by parents, attracted the most caution, with more than 50% of parents putting saying children should be 18 years or older to open an account.

Conclusions

For our survey respondents, using electronic monitoring to keep tabs on their children is normal, and monitoring children without their knowledge is common. Parents that monitor their children tend to employ more than one method, and the most common age for each form of monitoring to start is—very roughly—the point where we might expect children to be given some independence in that area.

Most of the parents we surveyed think that children should be at least 15 before they open social media accounts, with 18+ the prefered age for about half of all parents. This puts social media platforms like Instagram, TikTok, and Twitter on a par with common minimum ages for things like sexual intercourse, driving, smoking, and drinking: Potantially dangerous activities reserved for children on the cusp of adulthood.

In short, our survey suggests that when it comes to privacy in the family, parents are conservative (in the “small c”, apolitical sense of the word) in their attitudes. Our survey says nothing about parents’ concern for children’s privacy in general, but it suggests that providing children with a space in which to be private from their parents plays a distant second fiddle to the responsibility parents feel for keeping them safe.

The post Big Mother is watching: What parents REALLY think about tracking their kids appeared first on Malwarebytes Labs.

Earlier this week (25 January, 2022) news broke that a ransomware group was targeting QNAP Network Attached Storage (NAS) devices. The threat actors claimed the attack was based on a zero-day vulnerability specific to the devices.

Today QNAP® Systems, Inc. (QNAP) pushed out an automatic, forced, update with firmware containing the latest security updates to protect against the attackers’ “DeadBolt” ransomware.

You might think that that is a good thing—if not exactly cause for celebration, at least a cause for relief—but some customers aren’t happy.

Deadbolt

The ransomware group responsible for this attack is calling themselves Deadbolt. They also use the same name in the file extension of the encrypted files their ransomware generates. Rather then using the habitual method of dropping ransom notes in each folder on a affected device, Deadbolt ransomware hijacks the QNAP device’s login page. The hijacked screen starts with “WARNING: Your files have been locked by DeadBolt”. The complete ransom message is shown below:

WARNING: YOUR FILES HAVE BEEN LOCKED BY DEADBOLT

? What happened?

All your files have been encrypted. This includes (but is not limited to) Photos, Documents and Spreadsheets.

? Why me?

This is not a personal] attack. You have been targeted because of the inadequate security
provided by your vendor (QNAP).

? What now?

You can sake a paywent of (exactly) 0.030000 bitcoin to the following address:
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

Once the payment has been made we'll follow up with a transaction to the same address,
this transaction will include the decryption key as part of the transaction details.[more information]

You can enter the decryption key below to start the decryption process and get access to
all your files again.

important message for QNAP

Reportedly, the ransomware has already affected at least 3,600 victims. Besides urging individual victims to pay for a decryption key, the ransomware gang is also trying to sell the full details of the alleged zero-day vulnerability to QNAP for five bitcoins, and is apparently also willing to sell QNAP the master decryption key that can decrypt the files for all affected victims, and the zero-day info, for 50 bitcoins. There are many good reasons for not giving in to ransomware gangs’ demands, and QNAP doesn’t need the zero-day information because it has already created an update to thwart the vulnerability. However, the update hasn’t been as welcome as you might expect.

Forced update

The day after the news broke (26 January) QNAP issued a statement in response to the ransomware. It urged NAS users to follow the recommended security setting instructions to ensure the security of their routers, and immediately update to the latest version of QTS—the Linux based operating system developed by QNAP to run on their devices.

Later that day, QNAP took more drastic action and force-updated the firmware for all customers’ NAS devices to version 5.0.0.1891, the latest universal firmware which has been available since December 23rd, 2021.

Problems

As you might expect after a forced update, a number of unexpected side-effects arose, making users that were affected by these problems unhappy.

Some users reporteded losing their devices’ ISCSI connections (ISCSI is a networking standard for linking data storage facilities), and some adaperts were apparently left disabled by the update. The firmware update removed the ransomware executable and the ransom screen used to initiate decryption, which apparently caused some victims who had paid the ransom to be unable to proceed with decrypting the files after the update.

When warnings alone are not enough

As we all know, there is often a lawning gap between when a patch becomes available and when it’s actually applied. In this case, QNAP seems to have decided that closing that gap is the lesser of two evils.

And in all fairness, QNAP has been urging users to secure their devices since 7 January, 2022, with elaborate instructions on how to check whether their NAS devices are exposed to the Internet, how to disable the Port Forwarding function of the router, and how to disable the UPnP function.

This is just good advice either way since QNAP NAS owners were already being targeted by other ransomware operations like Qlocker and eCh0raix. Rather ironic, since many NAS owners use their devices to store backups in case their main systems become dislabed by things like ransomware.

In response to criticism about the unannounced forced update, QNAP support stated:

“I know there are arguments both ways as to whether or not we should do this. It is a hard decision to make. But it is because of deadbolt and our desire to stop this attack as soon as possible that we did this.”

We are curious as to how our readers feel about this. Let us know in the comments. Should device vendors be allowed to push updates when there is a clear and imminent danger?

Unless both business and conusmer users get to grips with patching sooner, we can probably expect to see more of these kind of forced updates.

The post QNAP update stops Deadbolt ransomware, annoys some users, starts debate appeared first on Malwarebytes Labs.

A researcher has picked up a $100,500 bounty from Apple after discovering a rather nasty method of gaining control of other people’s Macs. The issue, discovered lurking in Safari by Ryan Pickren, could make use of rogue websites to perform a number of dubious actions.

It begins, as so many attacks do, with a single click.

“Check out my website…”

The attacker starts by steering the victim to a specific website and getting them to click on a “play” button via a popup. The bug then deploys files which gives the attacker full control. There’s a peripheral angle, and a browsing angle, to this attack.

First off, the peripheral angle. Falling foul of this one activates the Mac’s webcam and allows an attacker to spy on you. This is, of course, never a good thing in the privacy stakes.

This is actually the second webcam bug found by this researcher. In 2020, Pickren found a zero-day which granted camera access, which Apple fixed. Turns out there’s always another way to get things done, and this is why webcam covers are, at a minimum, a very good idea.

Secondly, we have the browsing angle. It’s not just possible to hijack the webcam with this one. The attacker could also access and interact with anything open in Safari. Essentially, this is a full account takeover in a suddenly very hostile web browsing experience. Have your email account open? The attacker can access it. Social media pages? Same again. About to comment on a local news story involving a lost kitten and a tree? Buckle up, because what’s posted may not be to your liking.

So how did our intrepid student researcher achieve this?

The mighty power of UXSS (Universal cross-site scripting bugs)

The answer is via UXSS, something Google feels to be one of the nastier things floating around the exploit realm. As per the document:

Bugs leading to UXSS attacks are among the most significant threats for users of any browser. From an attacker perspective, a UXSS exploit may be almost as valuable as a Remote Code Execution (RCE) exploit with the sandbox escape.

If you save a website locally, you have the option of saving as webarchive files instead of HTML. As the writeup states, these files specify the web origin that the downloaded content should be rendered in. If attackers are able to modify the file somehow, they’ve as good as reached UXSS nirvana.

The researcher combined this with URI exploration, eventually settling on something called “ShareBear”.

Sharing is bearing

ShareBear leaps into action whenever some remote content needs to be grabbed. This is set in motion via iCloud-sharing: and this has the ability to create a public share link. Taking this link and exchanging “https” for “icloud-sharing” is enough to automatically open ShareBear.

This is where the “Open file” popup mentioned earlier comes into play.

If it’s the first time you’ve seen the popup, then hitting “Open” downloads the file and automatically opens it. The popup is gone forever; the after effects, not so much.

Any website in Safari, via ShareBear, has the ability to launch this file. The creator can alter it however they wish at their end after you said “yes” to opening it, and it’ll download and update the file on the victim’s PC automatically.

As the discoverer of this technique put it:

Agreed to view my PNG file yesterday? Well today it’s an executable binary that will be automatically launched whenever I want.

Apple has already fixed this issue, so you should be safe from oversharing bears and webcam indiscretions.

The post Apple fixes Mac bug that could have allowed takeover of webcams and browser tabs appeared first on Malwarebytes Labs.

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.

This blog was authored by Ankur Saini and Hossein Jazi

Lazarus Group is one of the most sophisticated North Korean APTs that has been active since 2009. The group is responsible for many high profile attacks in the past and has gained worldwide attention. The Malwarebytes Threat Intelligence team is actively monitoring its activities and was able to spot a new campaign on Jan 18th 2022.

In this campaign, Lazarus conducted spear phishing attacks weaponized with malicious documents that use their known job opportunities theme. We identified two decoy documents masquerading as American global security and aerospace giant Lockheed Martin.

In this blog post, we provide technical analysis of this latest attack including a clever use of Windows Update to execute the malicious payload and GitHub as a command and control server. We have reported the rogue GitHub account for harmful content.

Analysis

The two macro-embedded documents seem to be luring the targets about new job opportunities at Lockheed Martin:

• Lockheed_Martin_JobOpportunities.docx
• Salary_Lockheed_Martin_job_opportunities_confidential.doc

The compilation time for both of these documents is 2020-04-24, but we have enough indicators that confirm that they have been used in a campaign around late December 2021 and early 2022. Some of the indicators that shows this attack operated recently are the domains used by the threat actor.

Both of the documents use the same attack theme and have some common things like embedded macros but the full attack chain seems to be totally different. The analysis provided in the blog is mainly based on the “Lockheed_Martin_JobOpportunities.docx” document but we also provide brief analysis for the second document (Salary_Lockheed_Martin_job_opportunities_confidential.doc) at the end of this blog.

Attack Process

The below image shows the full attack process which we will discuss in detail in this article. The attack starts by executing the malicious macros that are embedded in the Word document. The malware performs a series of injections and achieves startup persistence in the target system. In the next section we will provide technical details about various stages of this attack and its payload capabilities.

Macros: Control flow hijacking through KernelCallbackTable

The above code uses a very unusual and lesser known technique to hijack the control flow and execute malicious code. The malware retrieves the address of the “WMIsAvailableOffline” function from “wmvcore.dll”, then it changes the memory protection permissions for code in “WMIsAvailableOffline” and proceeds to overwrite the code in memory with the malicious base64 decoded shell-code.

Another interesting thing happening in the above code is the control flow hijacking through the KernelCallbackTable member of the PEB. A call to NtQueryInformationProcess is made with ProcessBasicInformation class as the parameter which helps the malware to retrieve the address of PEB and thus retrieving the KernelCallbackTable pointer.

KernelCallbackTable is initialized to an array of callback functions when user32.dll is loaded into memory, which are used whenever a graphical call (GDI) is made by the process. To hijack the control flow, malware replaces the USER32!_fnDWORD callback in the table with the malicious WMIsAvailableOffline function. Once the flow is hijacked and malicious code is executed the rest of the code takes care of restoring the KernelCallbackTable to its original state.

Shellcode Analysis

The shellcode loaded by the macro contains an encrypted DLL which is decrypted at runtime and then manually mapped into memory by the shellcode. After mapping the DLL, the shellcode jumps to the entry point of that DLL. The shellcode uses some kind of custom hashing method to resolve the APIs. We used hollows_hunter to dump the DLL and reconstruct the IAT once it is fully mapped into memory.

The hashing function accepts two parameters: the hash of the DLL and the hash of the function we are looking for in that DLL. A very simple algorithm is used for hashing APIs. The following code block shows this algorithm:

def string_hashing(name):
    hash = 0
    for i in range(0, len(name)):
        hash = 2 * (hash + (ord(name[i]) | 0x60))
    return hash

The shellcode and all the subsequent inter-process Code/DLL injections in the attack chain use the same injection method as described below.

Code Injection

The injection function is responsible for resolving all the required API calls. It then opens a handle to the target process by using the OpenProcess API. It uses the SizeOfImage field in the NT header of the DLL to be injected into allocated space into the target process along with a separate space for the init_dll function. The purpose of the init_dll function is to initialize the injected DLL and then pass the control flow to the entry point of the DLL. One thing to note here is a simple CreateRemoteThread method is used to start a thread inside the target process unlike the KernelCallbackTable technique used in our macro.

Malware Components

• stage1_winword.dll – This is the DLL which is mapped inside the Word process. This DLL is responsible for restoring the original state of KernelCallbackTable and then injecting stage2_explorer.dll into the explorer.exe process.

• stage2_explorer.dll – The winword.exe process injects this DLL into the explorer.exe process. With brief analysis we find out that the .data section contains two additional DLLs. We refer to them as drops_lnk.dll and stage3_runtimebroker.dll. By analyzing stage2_explorer.dll a bit further we can easily understand the purpose of this DLL.

The above code snippet shows the main routine of stage2_explorer.dll. As you can see it checks for the existence of “C:Wíndowssystem32wuaueng.dll” and then if it doesn’t exist it takes its path to drop additional files. It executes the drops_lnk.dll in the current process and then tries to create the RuntimeBroker process and if successful in creating RuntimeBroker, it injects stage3_runtimebroker.dll into the newly created process. If for some reason process creation fails, it just executes stage3_runtimebroker.dll in the current explorer.exe process.

• drops_lnk.dll – This DLL is loaded and executed inside the explorer.exe process, it mainly drops the lnk file (WindowsUpdateConf.lnk) into the startup folder and then it checks for the existence of wuaueng.dll in the malicious directory and manually loads and executes it from the disk if it exists. The lnk file (WindowsUpdateConf.lnk) executes “C:Windowssystem32wuauclt.exe” /UpdateDeploymentProvider C:Wíndowssystem32wuaueng.dll /RunHandlerComServer. This is an interesting technique used by Lazarus to run its malicious DLL using the Windows Update Client to bypass security detection mechanisms. With this method, the threat actor can execute its malicious code through the Microsoft Windows Update client by passing the following arguments: /UpdateDeploymentProvider, Path to malicious dll and /RunHandlerComServer argument after the dll.

• stage3_runtimebroker.dll – This DLL is responsible for creating the malicious directory (“C:Wíndowssystem32”) and then drops the wuaueng.dll in that directory, furthermore it sets the attributes of the directory to make it hidden.

• wuaueng.dll – This is one of the most important DLLs in the attack chain. This malicious DLL is signed with a certificate which seems to belong to “SAMOYAJ LIMITED”, Till 20 January 2022, the DLL had (0/65) AV detections and presently only 5/65 detect it as malicious. This DLL has embedded inside another DLL which contains the core module (core_module.dll) of this malware responsible for communicating with the Command and Control (C2) server. This DLL can be loaded into memory in two ways:
  – If drops_lnk.dll loads this DLL into explorer.exe then it loads the core_module.dll and then executes it
  – If it is being executed from wuauclt.exe, then it retrieves the PID of explorer.exe and injects the core_module.dll into that process.

The Core module and GitHub as a C2

Rarely do we see malware using GitHub as C2 and this is the first time we’ve observed Lazarus leveraging it. Using Github as a C2 has its own drawbacks but it is a clever choice for targeted and short term attacks as it makes it harder for security products to differentiate between legitimate and malicious connections. While analyzing the core module we were able to get the required details to access the C2 but unfortunately it was already cleaned and we were not able to get much except one of the additional modules loaded by the core_module.dll remotely (thanks to @jaydinbas who shared the module with us).

There seems to be no type of string encoding used so we can clearly see the strings which makes the analysis easy. get_module_from_repo uses the hardcoded username, repo_name, directory, token to make a http request to GitHub and retrieves the files present in the “images” directory of the repository.

The HTTP request retrieves contents of the files present in the repository with an interesting validation which checks that the retrieved file is a PNG. The file that was earlier retrieved was named “readme.png”; this PNG file has one of the malicious modules embedded in it. The strings in the module reveal that the module’s original name is “GetBaseInfo.dll”. Once the malware retrieves the module it uses the map_module function to map the DLL and then looks for an exported function named “GetNumberOfMethods” in the malicious module. It then executes GetNumberOfMethods and saves the result obtained by the module. This result is committed to the remote repo under the metafiles directory with a filename denoting the time at which the module was executed. This file committed to the repo contains the result of the commands executed by the module on the target system. To commit the file the malware makes a PUT HTTP request to Github.

Additional Modules (GetBaseInfo.dll)

This was the only module which we were able to get our hands on. Only a single module does limit us in finding all the capabilities this malware has. Also its a bit difficult to hunt for these modules as they never really touch the disk which makes them harder to detect by AVs. The only way to get the modules would be to access the C2 and download the modules while they are live. Coming back to this module, it has very limited capabilities. It retrieves the Username, ComputerName and a list of all the running processes on the system and then returns the result so it can be committed to the C2.

GitHub Account

The account with the username “DanielManwarningRep” is used to operate the malware. The account was created on January 17th, 2022 and other than this we were not able to find any information related to the account.

Second Malicious Document used in the campaign

Malicious Document – Salary_Lockheed_Martin_job_opportunities_confidential.doc (0160375e19e606d06f672be6e43f70fa70093d2a30031affd2929a5c446d07c1)

The initial attack vector used in this document is similar to the first document but the malware dropped by the macro is totally different. Sadly, the C2 for this malware was down by the time we started analyzing it.

This document uses KernelCallbackTable as well to hijack the control flow just like our first module, the injection technique used by the shellcode also resembles the first document. The major difference in this document is that it tries to retrieve a remote HTML page and then executes it using mshta.exe. The remote HTML page is located at https[:]//markettrendingcenter[.]com/member.htm and throws a 404 Not Found which makes it difficult for us to analyze this document any further.

Attribution

There are multiple indicators that suggest that this campaign has been operated by the Lazarus threat actor. In this section we provide some of the indicators that confirm the actor behind this attack is Lazarus:

• Using job opportunities as template is the known method used by Lazarus to target its victims. The documents created by this actor are well designed and contain a large icon for a known company such as LockHeed Martin, BAE Systems, Boeing and Northrop Grumman in the template.
• In this campaign the actor has targeted people that are looking for job opportunities at Lockheed Martin. Targeting the defense industry and specifically Lockheed Martin is a known target for this actor.
• The document’s metadata used in this campaign links them to several other documents used by this actor in the past.

• Using Frame1_Layout for macro execution and using lesser known API calls for shellcode execution is known to be used by Lazarus.
• We also were able to find infrastructure overlap between this campaign and past campaigns of Lazarus (Figure 19).

Conclusion

Lazarus APT is one of the advanced APT groups that is known to target the defense industry. The group keeps updating its toolset to evade security mechanisms. In this blog post we provided a detailed analysis about the new campaign operated by this actor. Even though they have used their old job theme method, they employed several new techniques to bypass detections:

• Use of KernelCallbackTable to hijack the control flow and shellcode execution
• Use of the Windows Update client for malicious code execution
• Use of GitHub for C2 communication

IOCs:

Maldocs:
0d01b24f7666f9bccf0f16ea97e41e0bc26f4c49cdfb7a4dabcc0a494b44ec9b Lockheed_Martin_JobOpportunities.docx

0160375e19e606d06f672be6e43f70fa70093d2a30031affd2929a5c446d07c1
Salary_Lockheed_Martin_job_opportunities_confidential.doc

Domains:
markettrendingcenter.com
lm-career.com

Payloads:

The post North Korea’s Lazarus APT leverages Windows Update client, GitHub in latest campaign appeared first on Malwarebytes Labs.

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.