Nov 20, 2017
John
Comments Off on OSX.Proton spreading through fake Symantec blog

OSX.Proton spreading through fake Symantec blog

Sunday night, a series of tweets from security researcher @noarfromspace revealed a new variant of the OSX.Proton malware, spreading in a concerning new method—spoofing security company Symantec’s blog.

Method of infection

The malware is being promoted via a fake Symantec blog site at symantecblog[dot]com. The site is a good imitation of the real Symantec blog, even mirroring the same content. The registration information for the domain appears, on first glance, to be legitimate, using the same name and address as the legitimate Symantec site. The email address used to register the domain is a dead giveaway, however:

Even more suspicious is the certificate used by the site. It is legitimate SSL certificate, but was issued by Comodo rather than Symantec’s own certificate authority.

The fake site contains a blog post about a supposed new version of CoinThief, a piece of malware from 2014. The fake post claims that a new variant of CoinThief has been spotted. In fact, as far as I’ve been able to determine, this is a made-up story, and no such new variant of CoinThief actually exists.

The fake post promotes a program called “Symantec Malware Detector,” supposedly to detect and remove the malware. No such program actually exists.

Unfortunately, links to the fake post have been spreading on Twitter. Some of the accounts tweeting the link appear to be fake accounts, but others seem to be legitimate. Given the fact that the primary goal of the Proton malware is to steal passwords, these could be hacked accounts whose passwords were compromised in a previous Proton outbreak. However, they could also simply be the result of people being tricked into thinking the fake blog post is real.

Users who download and run the “Symantec Malware Detector” will instead be infected with malware.

Malware behavior

When run, the malicious Symantec Malware Detector application displays a very simple window, using the Symantec logo:

If the user quits the application at this point, the malware does not actually get installed. However, let’s be honest—if you’ve been tricked into downloading and opening this application, you probably won’t bail out at this point.

Clicking the “Check” button results in a request for an admin password:

The average Mac user has seen these kinds of password request many times before, so again, this is unlikely to raise suspicions among users who have gotten this far. In reality, this is a very well-done fake and will give the malware your password. (Unlike the legitimate password request this is designed to imitate, which does not give the requesting software the user’s password.)

If an admin password is provided, the application displays a progress bar claiming to be scanning the computer.

In reality, however, the application has installed the Proton malware.

The malware will begin capturing information, including logging the user’s admin password in clear text, among a lot of other personally-identifying information (PII) to a hidden file:

[...]

 2017-11-19T20:29:19.801Z
 *********
 test
 test
 test%E2%80%99s Mac
 testpw
 10.12.6
 en_US

[...]

The malware also captures and exfiltrates things like keychain files, browser auto-fill data, 1Password vaults, and GPG passwords. Since the malware has phished the user’s password, the hackers will be able to decrypt the keychain files at a minimum.

Indicators of compromise

The Symantec Malware Detector application is, as far as I’m able to determine, a completely made-up name. If you see such an application—perhaps in the Downloads folder, or perhaps in the Applications folder, depending on where the user puts it—it should be deleted.

If you are unsure of whether the application is actually malicious, you can check the code signature. Enter the following command in the Terminal, substituting the actual path:

codesign -dvvv "path/to/Symantec Malware Detector.app"

The malicious application has been signed by someone named Sverre Huseby, using a certificate with a team identifier of E224M7K47W. Anything signed with this certificate should be considered malicious.

Once this malicious “dropper” application has been run, the following paths will be found on the system:

/Library/LaunchAgents/com.apple.xpcd.plist
/Library/.cachedir/
/Library/.random/

The .random directory holds the malicious Proton executable, which is kept running by the com.apple.xpcd.plist launch agent. The .cachedir folder contains data that has been or will be exfiltrated.

In addition to these files, the /private/etc/sudoers file will have been modified. The following line will have been added to the end:

Defaults !tty_tickets

That line should be removed from the sudoers file.

Fortunately, Apple is aware of this malware and has revoked the certificate used to sign the malware. This will prevent future infections by the Symantec Malware Detector. Revoking the certificate will not, by itself, do anything to protect a machine that is already infected.

Implications

Malwarebytes for Mac will detect and remove Proton infections for free. If you find your Mac to be infected, it’s quite easy to remove the malware. However, removing the malware is only a part of the solution.

Since Proton is designed to steal login credentials, you will need to take some emergency actions post-infection. You should treat all online passwords as compromised and change them all. Be sure, while you’re at it, to use different passwords on every site, and use a password manager (such as 1Password or LastPass) to keep track of them. Since 1Password vaults are a target of Proton, be sure that you don’t store your password manager’s master password in your keychain or anywhere else on the computer. That should be the one and only password that you memorize, and it should be strong.

You should also enable two-factor authentication on every account that will allow you to do so. That will minimize the impact of such breaches in the future by ensuring that a hacker will need more than just your password to access your accounts.

In addition to passwords, you should consider any other information that may have been part of the compromise. For example, if you store credit card numbers or other sensitive data in the keychain, it should be treated as compromised and you should respond accordingly.

As always, if the machine that was compromised was issued to you by your employer, or has company data on it, you should notify IT immediately. Failure to do so could lead to a very serious breach of your company’s systems.

Conclusion

Proton has been circulating for quite some time after its initial appearance in March. It has previously been distributed via a compromise of the Handbrake application and a similar compromise of a couple Eltima Software applications. It is highly likely that Proton will continue to circulate, and similar incidents will continue to occur.

Proton illustrates an increasing problem in the Mac community. The prevailing attitude that you can avoid Mac malware if you’re careful enough is failing in the face of supply chain attacks, such as the hacks of the Handbrake and Eltima Software systems.

Further, so-called “fake news” being used to distribute malware is a highly dangerous threat. Many people these days are looking to download malware removal software for the Mac, due to the increasing prevalence of annoying Mac adware. Unfortunately, it is often the case that such software will be downloaded after a search that gives questionable results, or after seeing a recommendation from a hacked or fake account on social media or forums.

Macs are the targets of an increasing amount of malware. They can no longer be assumed to be safe. The old advice that “Macs don’t get viruses,” which can still be found echoing in many Mac-centric forums, has never been true, and this is becoming increasingly obvious to those following such events. Do not fall victim due to a false sense of security caused by the fact that you have a Mac!

The post OSX.Proton spreading through fake Symantec blog appeared first on Malwarebytes Labs.

Powered by WPeMatico

Nov 20, 2017
John
Comments Off on A week in security (November 13 – November 19)

A week in security (November 13 – November 19)

Last week, we gave you some tips for the inevitable online chaos that is Cyber Monday, explained how “trusted” root certificates can sometimes be anything but, and explored the strange world of catphishing. We also pulled apart some malware found on Google Play and laid out the specifics of the cloud in simple terms.

Other news

  • London Metropolitan Police aren’t massively keen on facial recognition technology. (source: The Register)
  • Fake News is a bigger problem than just in the realm of the political. (source: Digital Shadows)
  • Banking Trojans won’t be going away anytime soon—here’s another one! (source: Security Intelligence)
  • Why do bug bounty hunters, er, hunt bug bounties? Study available here. (source: Help Net Security)
  • That camera in your home may have a vulnerability lurking. (source: Talos Security)
  • A legitimate email appears to be phishy fun with the Punisher. (source: io9)
  • Hide your Facebook and Twitter from this piece of malware. (source: CNet)

Stay safe everyone!

The post A week in security (November 13 – November 19) appeared first on Malwarebytes Labs.

Powered by WPeMatico

Nov 17, 2017
John
Comments Off on 10 tips for safe online shopping on Cyber Monday

10 tips for safe online shopping on Cyber Monday

Shoppers familiar with the Cyber Monday circus know they’re stepping into the lion’s den. The Internet has always been a lawless place, but it becomes particularly rough during the holiday shopping season.

In preparation for the frenzy, cyber villains have crafted a virtual onslaught of social engineering scams, malspam, and malicious, spoofed websites in order to dupe the droves of people expected to spend nearly $4 billion online this year.

So, bargain hunters, it’s important to know the warning signs. Here’s your guide to safe online shopping on Cyber Monday and beyond.

  1. Go directly to a store’s website instead of using search engines to look for deals. If you happen to find a deal using a search engine, try to verify it by searching for the exact name of the deal in quotes. If it’s a scam, then it’s likely someone will have already put out a warning.
  2. Give pop-ups and other digital ads the stank eye. Many pop-ups could contain fake coupons, redirect you to malicious sites, or expose you to cross-site scripting attacks. If a coupon seems to come out of nowhere with a too-good-to-be-true offer, don’t think twice. Just click that “x” and shut it down.
  3. Watch out for social media scams, especially on Facebook. Cybercriminals are using fake or compromised Facebook accounts in order to post links to amaaaaaazing deals that don’t actually exist. They’re especially prone to dropping links on the walls of open groups dedicated to shopping. “One of the top shopping scams to avoid in the run-up to Cyber Monday is the social media fakeout,” says Chris Boyd, Lead Malware Analyst at Malwarebytes. “During any given holiday period there will be an excess of fake offers, deals, and supposed freebies which tend to have a sting in the tail. If you’re being asked to share something on Facebook in order to get your hands on something too good to be true, you can bet there’s a scam involved.”
  4. Dump Cyber Monday emails with attachments in the virtual garbage. Cyber Monday emails with attachments, especially zip files, are super suspect—it’s possible, in fact likely, that they contain malware. Delete them immediately. Not only that, but you should review any other Cyber Monday-related emails with a hawk eye. If you get an email from a store claiming to have a deal, type the store’s URL directly into your browser instead of clicking on the link. If the site doesn’t verify the deal, you know it’s a fake.
  5. Make sure you’re on a secure connection. Look for the padlock icon to the left of the URL when you go to check out. If it’s there, then that means the information passed between a store’s server and your browser remains private. In addition, the URL should read “https” and not just “http.”
  6. Do not use debit cards to shop online. Want to give cybercriminals direct access to your bank account? Then by all means, use your debit card! Otherwise, play it safe by using credit cards or a PayPal account that’s linked to a credit card. While many banks are cracking down on fraudulent withdrawals, you’ll still have to wait for your money while they investigate the charges.
  7. Avoid using public wifi to shop. All a cybercriminal needs to do to get a public wifi password and wreak havoc is order a coffee. If you’re shopping and entering personal data, best to do it on your secure wifi connection at home.
  8. Watch out for malicious QR codes. Q what now? QR codes are small, pixelated codes meant to be scanned by a smartphone’s camera. They often contain coupons, links to websites, or other product marketing materials. Some hackers have started creating codes that link to a phishing or malware site, printing them on stickers, and placing them on top of the legit QR codes. Best to avoid them.
  9. Don’t fork over extra info. If a site starts asking for out-of-the-ordinary personal data, like Social Security numbers or password security questions, slam on the brakes and get the heck out of Dodge.
  10. Tighten up security before you shop on Cyber Monday. Make sure all software on your computer is up-to-date, including your OS, browser, and other apps. And if you don’t already have it, install a cybersecurity program on your desktop (whether it’s a Mac or PC) that prevents malware infection to insure maximum coverage. In addition, since mobile shopping is set to outpace desktop shopping for the first time this year, it’s a smart idea to download a cybersecurity program for your phone. If you’ve already covered your cybersecurity bases, make sure you run updates on all those programs as well.

Happy, and safe, holiday shopping everyone!

The post 10 tips for safe online shopping on Cyber Monday appeared first on Malwarebytes Labs.

Powered by WPeMatico

Nov 16, 2017
John
Comments Off on When you shouldn’t trust a trusted root certificate

When you shouldn’t trust a trusted root certificate

Root certificates are the cornerstone of authentication and security in software and on the Internet. They’re issued by a certified authority (CA) and, essentially, verify that the software/website owner is who they say they are. We have talked about certificates in general before, but a recent event triggered our desire for further explanation about the ties between malware and certificates.

In a recent article by RSA FirstWatch, we learned that a popular USB audio driver had silently installed a root certificate. This self-signed root certificate was installed in the Trusted Root Certification Authorities store. Under normal circumstances, you would have to agree to “Always trust software from {this publisher}” before a certificate would be installed there.

However, the audio driver skipped this step of prompting for approval (hence “silently” installing).  The silent install was designed to accommodate XP users, but it had the same effect in every Windows operating system from XP up to Windows 10. The installer was exactly the same for every Windows version. Ironically enough, the certificate wasn’t even needed to use the software. It was just introduced to complete the installation on Windows XP seamlessly.

Why is this a bad thing?

Root certificates can be installed for purposes such as timestamping, server authentication, code-signing, and so on. But this particular driver installed a certificate valid for “All” purposes. So any system with these drivers installed from any of the vendors will trust any certificate issued by the same CA—for “All” purposes. Under normal circumstances, only a certificate issued by Microsoft would have “All” in the root certificates “Intended Purposes” field.

Having a certificate in the Trusted Root Certification Store for “All” intended purposes on a Windows system gives anyone that has the private key associated with the certificate the ability to completely own the system on which it is installed. The impact is the same as for any Certificate Authority (CA) behind certificates installed on Windows systems.

certmgr

An exception is that in some instances large companies may choose to do the same with the intent to perform SSL decryption at the perimeter for outbound traffic. So, not only does silently adding a root certificate break the hierarchical trust model of Windows. It also gives any owner of the private key that goes with that certificate a lot of options to perform actions on a computer with that certificate installed.

How can they be abused?

An attacker who gets ahold of the private key that belongs to a root certificate can generate certificates for his own purposes and sign them with the private key. Any certificate with the root certificate already in their Trusted Root Certification Store on a Windows system will trust any certificate signed with the same private key for “All” purposes. This applies to software applications, websites, or even email. Anything from a Man-in-the-Middle (MitM) attack to installing malware is possible. And as if this wasn’t bad enough, security researchers at the University of Maryland found that simply copying an authenticode signature from a legitimate file to a known malware sample can cause antivirus products to stop detecting it, even though it results in an invalid signature.

Methods of abuse

There are several ways of abusing certificates by criminals. They can:

Of all these methods, it stands to reason that stolen certificates, especially those intended for “All” purposes, are the most dangerous. So introducing one of these just because you want to install a driver or to enable easier customer support, and not letting the user know, is inadvisable at best.

If you think that the number of certificates in use by malware authors can’t be that large, have a look at the suspects that have been reported at the CCSS forum.

How can I remove certificates I don’t need or trust?

A list of known signing certificates that are being abused by threat actors has been made available at signedmalware.org. As explained earlier, using signing certificates gives criminals a lot of options to bypass system protection mechanisms, which is why you might want to remove those from your machine. There is also a test site where you can check if any of the software programs that are open to an MitM attack are active on your system.

To delete a trusted root certificate:

  • Open the certificates snap-in for a user, computer, or service. You can do this by running certmgr.msc from your Run/Searchprograms box or from a command prompt.
  • Select Trusted Root Certification Authorities.
  • Under this selection, open the Certificates store.
  • In the details pane on the right-hand side, select the line of the certificate that you want to delete. (To select multiple certificates, hold down control and click each certificate.)
  • Right click the selection you made and in the action menu, click delete.
  • Confirm your choice by clicking yes if you are completely sure that you want to permanently delete the certificate.

Please note that user certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

You might want to back up the certificate by exporting it before you delete it. For the procedure to export a certificate, see export a certificate.

If you want to look at the Thumbprint, aka serial number, of the certificates, you can use this Powershell command to list the non-Microsoft certificates in the Trusted Root Certification Authorities:

Get-ChildItem -Path cert:currentuserAuthRoot -Recurse | select Thumbprint, FriendlyName, Subject | ConvertTo-Html | Set-Content c:userspublicdesktopcertificates.html

This will create a html file on the public desktop that shows the list by Thumbprint (in reverse order) and where you can look up the Friendly Name and Subject that belongs to a Thumbprint.

exported certificates list

For those that do like to keep an eye on things, there is a guide by Xavier Mertens for a piece of code that alerts you about changes in the certificate store.

Conclusion

Since root certificates are intended to heighten security, it should be clear to those issuing them that they should be treated as such, and not as something that they can install willy-nilly whenever it suits their needs. The whole point of prompting users is to establish a chain of trust that they should be able to rely on. And in this case, the prompt was bypassed only to enable installation on a no-longer-supported operating system. That both ruins user trust and introduces unnecessary security risk for a rather shallow reason.

The post When you shouldn’t trust a trusted root certificate appeared first on Malwarebytes Labs.

Powered by WPeMatico

Nov 15, 2017
John
Comments Off on Bad romance: catphishing explained

Bad romance: catphishing explained

You’ve heard or read about some variant of this story before: Girl meets Boy on a dating website. Girl falls in love. Boy claims he does, too. Girl is excited to meet Boy soon. But at the last minute, Girl finds out that Boy (1) had an accident and broke a hip; (2) has a very sick relative he needs to look after; (3) is going away to a secluded place to “find himself”—you’re not the problem, he is, right?; or (4) (through a helpful and mournful friend) is dead.

Suddenly suspect, Girl digs a little deeper. Girl finds out that Boy isn’t the dreamboat he portrays himself to be. Boy is, in fact, her female colleague’s timid 13-year old son whom she met once at a work function.

Bummer, right? Here’s another one:

Two months ago, Deloitte revealed that it was breached by hackers, who most likely already had access to compromised servers since November 2016. Around the same time, a cybersecurity staffer at Deloitte was convinced to open a booby-trapped Excel file from a female friend he met on Facebook months before. Her name was “Mia Ash,” a London-based photographer. She was described as lovely and disarming.

She was also 100 percent fake.

Mia Ash is the latest in a lengthening line of online femme fatales who successfully infiltrated corporate systems by targeting and successfully duping smart men working in IT and cybersecurity—people who everyone expects to practice what they preach. Her equally fake predecessors went by the names of Robin Sage and Emily Williams. Although all three were created as social engineering lures, one significant difference stood out: Sage and Williams were the brainchildren of cybersecurity experts who wanted to expose the human weakness in the national defense and intelligence communities. Ash, on the other hand, was the product of a known Iranian APT group who deliberately took advantage of that weakness to achieve their nation-state goals.

Two very different stories, one common theme: romantic deception.

What is catphishing?

Catfishing (spelled with an “f”) is a kind of online deception wherein a person creates a presence in social networks as a sock puppet or a fictional online persona for the purpose of luring someone into a relationship—usually a romantic one—in order to get money, gifts, or attention. Catphishing (spelled with a “ph”) is similar, but with the intent of gaining rapport and (consequently) access to information and/or resources that the unknowing target has rights to.

Simply put, the former is out to break hearts (and bank accounts), while the latter is out to compromise individuals, organizations, and quite possibly even countries.

Can we say that catphishing has gone beyond bad romancing for money? Absolutely.

What motivates catphishers to do what they do?

The motivations behind the act are likely similar to why spies steal secrets: to make use of the stolen information to gain the upper hand against the target or organization they belong to. As we all know, stolen information in the hands of criminals can be used in many ways—for extortion, for sale on the black market. However, in the end, the organization that was compromised loses integrity, clients, business opportunities, and gets fined if they were found to be non-compliant with security and privacy regulations.

Catphishing is dangerous enough that most companies consider it a business threat.

On the other hand, those catphishing individuals might also use the information they gather from individuals to create even more social media profiles. Sometimes, catphishers mislead simply to bully people online.


Read: Tackling the myths surrounding cyberbullying


Blimey. Those catphishers ought to pay for what they’ve done!

Unfortunately, in many countries, catphishing (and catfishing) isn’t illegal. In the UK, “catfishing” is not even a legally-defined term. Although at present, the practice is pretty much legal, active campaigns are aiming to change this.

In the US, Oklahoma is the only state that made catfishing illegal.

Although one cannot lawfully pin catfishing/catphishing against someone, there are other legal areas that those affected by the practice can look into and decide whether they want to pursue these instead. They are (but are not limited to) the following:

  • Copyright violation (for photos stolen and used in the deception)
  • Criminal impersonation
  • Defamation
  • Identity fraud
  • Espionage

How can we protect ourselves from this?

Start by familiarizing yourselves with the following red flags, which indicate that you may be dealing with a catphisher online:

  • Everything that they claim to be seems too good to be true.
  • If you meet them on a dating website, and they suggest getting in touch with you via other means, such as email and other chat services.
  • They show no interest in a face-to-face meeting or even in using voice chat services.
  • Most (if not all) photos they use don’t include other people.
  • Quite a number of their social media followers appear to be sockpuppet accounts.
  • They ask a lot of information about you early on in the relationship like how much you earn, what kind of home you live in, and where your parents are (to name a few).

Stay safe out there!

Recommended reading for parents:

The post Bad romance: catphishing explained appeared first on Malwarebytes Labs.

Powered by WPeMatico

Nov 14, 2017
John
Comments Off on New Android Trojan malware discovered in Google Play

New Android Trojan malware discovered in Google Play

A new piece of mobile malware has been discovered in Google Play masquerading as multiple apps: an alarm clock app, a QR scanner app, a compass app, a photo editor app, an Internet speed test app, and a file explorer app. According to Google Play data, all were last updated between October and November 2017.  These dates are likely when they were added to Google Play, based on their low version numbers (e.g. 1.0, 1.0.1).

We named this new malware variant Android/Trojan.AsiaHitGroup based on a URL found within the code of these malicious APKs.

Click to view slideshow.

For the sake of discussion as we analyze this malware, let’s concentrate on just one of its associated apps, since they all share the same behavior. We will focus on a malicious QR scanner app named Qr code generator – Qr scanner.

Surface analysis of Trojan AsiaHitGroup

AsiaHitGroup has several layers of maliciousness. It starts innocently enough with an icon created on the mobile device after install. Click on the icon, and it opens a functioning QR scanner, as promised.

Click to view slideshow.

However, this QR scanner is short lived. You only get one chance to use the app, because after clicking out of it, the icon disappears! Out of frustration, you may immediately go to your apps list to uninstall this bizarre-behaving QR scanner, but good luck finding it. If you are looking under the Q’s for Qr coder generator or Qr scanner, it’s not there. It’s not even under the icon’s name, Barcode reader, which is shown briefly before vanishing. Instead, this deceiving app is called Download Manager in the app list. Unless you know all the apps on your mobile device exceptionally well, it’s near impossible to discover this app name.

Diving deeper into Trojan AsiaHitGroup

If the behaviors listed above weren’t enough to conclude this QR app is malicious, it gets worse. The first step performed by the malicious app in the background is checking the location of the mobile device. This is done by using the website ip-api.com which provides Geolocation using IP. If the location is in an area that satisfies rules within the code, then it proceeds to the next step. This next step is to download an APK by visiting a website that contains download instructions.

Code from http://[hidden_domain]/api/custom/dynamic-fragment with instructions to download an APK

{"id": "duy.van.dao.dynamicduy.20171005.16", "files": [{"id": "duy.van.dao.dynamicduy.20171005.16", "md5": "4662e8537751c49beb06309a989796fc", "url": "https://[hidden_domain]/hoanghai27/dynamic-fragment/raw/master/dynamic-plugin-v22.apk"}], "version": "20171005.16", "fragments": [{"code": "duy.van.dao.dynamicduy.20171005.16", "name": "duy.van.dao.dynamicduy.MainFragment", "host": "dynamicfragment"}]}

Unfortunately during testing, the APK could not be downloaded via the malicious QR app—most likely due to my location. However, I was able to manually download the APK using the URL provided within the download instructions. The behavior of this downloaded APK was that of a Trojan SMS (which is why I subsequently named it Android/Trojan.SMS.AsiaHitGroup). Based on all the references to Asia within the code, my assumption is you must be in Asia for this malware to fully function.

Add some adware into the mix

Even if the malicious Trojan SMS fails to download, there is yet another layer to the malevolence.  Hidden within the malicious QR app is another APK waiting to do its biding. However, this hidden APK is a less threatening, adware-pushing app.

The hidden adware app comes with an unusual service name: vn.solarjsc.fakeads.ShowAdsService.  Within this service, there is reference to the same domain that was used to gain download instructions of the Trojan SMS. Although I was unable to verify, this domain may also contain the “fakeads” referenced in the service name. Regardless, rest assured we are detecting this hidden adware app as well as Android/Adware.AsiaHitGroup.

Google Play: not quite flawless

Even with the introduction of Google Play Protect, there appears to be no fail-proof way to stop malware from entering the Play store. This is where a second layer of protection is strongly recommended. By using a quality mobile anti-malware scanner, you can stay safe even when Google Play Protect fails. We (obviously) recommend Malwarebytes for Android. Stay safe out there!

 

Malicious APK samples: use at own risk

Android/Trojan.AsiaHitGroup

MD5: 178E6737A779A845B8F2BAF143FDEA15, Package Name: duy.van.dao.qrcode
MD5: 7EEC1C26E60FEDE7644187B0082B6AC4, Package Name: com.varvet.barcodereader
MD5: 7CEDA121F9D452E9A32B8088F50012B8, Package Name: com.maziao.alarm
MD5: B481CE9D0B7295CDA33B15F9C7809B95, Package Name: com.magiaomatday.editimage
MD5: 60A71632004EE431ABB28BF91C3A4982, Package Name: com.maziao.speedtest
MD5: N/A, Package Name: com.ruzian.explorer

Android/Trojan.SMS.AsiaHitGroup

MD5: 3CC02E4FECEB488B084665E763968108, Package Name: duy.van.dao.dynamicduy

Android/Adware.AsiaHitGroup

MD5: 995D5DC873104B5E42B3C0AF805359DB, Package Name: com.offer.flashcall

The post New Android Trojan malware discovered in Google Play appeared first on Malwarebytes Labs.

Powered by WPeMatico

Nov 14, 2017
John
Comments Off on Explained: the cloud

Explained: the cloud

Even if you are reading this post because you have no idea what the cloud is, you might be using it more often than you realize. Twitter, LinkedIn, Dropbox, Google Drive, and Microsoft Office 365 are some of the most well-known cloud apps.

Let’s start with a definition of the cloud to get a grip on things:

Cloud computing, often referred to as simply “the cloud,” is the delivery of on-demand computing resources—everything from applications to data centers—over the Internet.

Cloud resources are often split up in three different ways:

  • Public: cloud services are delivered over the Internet and sold on demand, which provides customers with a great amount of flexibility. You only pay for what you need.
  • Private: cloud services are delivered over the business network from the owner’s data center. You have control over the hardware, as well as the management and related costs.
  • Hybrid: a mix of the above. Businesses can choose to have control over the most sensitive data or their average user and use public services to cover the rest of their needs.

Multi-cloud is another expression you may have come across. This means that companies use more than one public cloud provider, maybe for specific applications or as a method to cover outages. When using hybrid and multi-cloud solutions, it is important to spread the workload in a cost-effective manner.

Perceptions of the cloud

There are a few expressions about saving your data in the cloud that are not completely true, but will give you an idea of people’s perception of the cloud and what risks might be involved.

  • Your data is on someone else’s computer.
  • Your data is in a huge server farm.
  • You can’t be sure where your data is right now.

As you can probably tell from these statements, the main concern about the cloud is a lack of control over the data. This is not surprising, given the number of breaches that have occurred in recent times. According to an article on CSO, more data records were lost or stolen in the first half of 2017 than in all of 2016.

So what we really want to know is: Who actually has access to our data? This is not only relevant with regards to cybercriminals that can gain access through breaches. The Patriot Act gives the US government a lot of freedom to access and investigate data that is stored in cloud infrastructures. And of course, the cloud provider who stores that data can see it. Depending on the provider, they can even advertise to you based on your data, as is the case with most social media platforms.

And in case of a breach? Is your data stored and sent encrypted? What if someone manages to intercept the traffic? These questions may not all be relevant in your case, but they are worth thinking about.

Pros and cons

As with all technology, there are pros and cons to using the cloud. Here are a few:

Pros

  • scalable and flexible, so you can quickly react to ups and downs
  • cost effective—you pay for what you use
  • off-site backup, so no need to worry about losing it all in a fire or other catastrophe
  • access to data in any location

Cons

  • less direct control
  • potential for privacy and security violations (breaches)
  • different security measures from what you may be used to
  • access dependent on access to the Internet, which means services outages could lock you out of your data

secured cloud

Choosing the right cloud service

First and foremost, when looking for a cloud service provider, you should consider one that not only suits your data storage needs, but also is a reliable partner. Look at their track record and ask for references. With public cloud solutions, you need to consider the possibilities of traffic being intercepted, maybe even being altered, and data being stolen. And always look for providers that offer encryption and multi-factor authentication.

Because running cloud applications requires more attention then straightforward data storage, it’s helpful to distinguish Infrastructure-as-a-Service (IaaS) from Platform-as-a-Service (PaaS) when you are talking about cloud security.

  • IaaS is when your systems are running on virtual servers in the cloud.
  • PaaS is when your applications are running on cloud environments.

For IaaS situations, the security problems that are left up to you to take care of are not that different from the ones in your regular environment. You should be able to treat the servers as if  they were in your own network. They require the same security solutions as your own, which could be anything from anti-malware software to a firewall.

For a PaaS environment, application hardening will be different as it may require a web-application firewall. As the applications are not running from the systems within your intranet, they will very likely be using different Internet connections to send and receive traffic. This is something to determine with the cloud service provider. Who takes care of what?

One other thing to consider when choosing your cloud service provider is the physical location of your data. It is your responsibility to make sure you remain compliant with laws and industry regulations. This can also be an important consideration when you are about to decide which data you will move to the cloud and which should be kept in-house.

Summary

The cloud is in essence a method to use other resources than your own to run applications or store any kind of data. It offers users flexibility, scalability and puts the care of systems in other hands than yours. The price, besides the fees, is a loss of control over the resources and data. For businesses, compliance is another factor to weigh. When talking to potential cloud service providers, security should always be a point on the agenda. It has to be clear who takes care of which aspects of cloud security, otherwise it could slip through the cracks.

The post Explained: the cloud appeared first on Malwarebytes Labs.

Powered by WPeMatico

Nov 13, 2017
John
Comments Off on A week in security (November 6 – November 12)

A week in security (November 6 – November 12)

After coming out victorious in a case against PUPs, Malwarebytes CEO Marcin Kleczynski has this to say:

We fought for our users and we won.

— Marcin Kleczynski (@mkleczynski) November 9, 2017

And my, do we feel like champions!

You can read more about this here.


Last week, we looked into the cryptocurrency mining phenomenon, rising digital crimes that target businesses—the final supplement of a two-part series—a bogus WhatsApp app that got through the Google Play store because the actor behind it used Unicode, and puppy scams. We also revealed a Bitcoin multiplier scam that actors behind the Magnitude EK were banking on and the coming back of the Disdain EK, this time delivering a Neutrino bot.

Lastly, we put out word about potential fakeries from cybercriminals targeting those shopping on Singles’ Day and a little exercise for the talented guys and gals who like to tinker with code, which we followed with a step-by-step tut on how to solve it.

Other news

  • Paradise lost? Breach of law firm, Appleby, exposes information of the rich. And so are their tax schemes. (Source: Quartz)
  • There’s a flaw in Tor that allows user IP address to leak. This affects macOS and Linux users. (Source: Computing)
  • Proofpoint reveals a multi-prong attack against Android users, wherein users are first faced with a phishing campaign, and then convinces users to install malware, then finally attempted to steal card details. (Source: InfoSecurity Magazine)
  • To hack back or not to hack back: this has been a longstanding debate from within and without the security industry. Keith Alexander, ex-NSA Director, weighed in on the debate, advising companies to never hack back as this might start wars. (Source: Motherboard)
  • According to a DHS testing, the Boeing 757 aircraft is found to be vulnerable to hackers. (Source: Aviation Today)
  • Companies granting a lot of admin rights to employees can actually leave them vulnerable to cyber attacks. (Source: TEISS)
  • Mozilla’s “Privacy Not Included” guide reveals gadgets and devices one might not acquire for loved ones as they can spy on them. (Source: CSO)
  • No, your Netflix account has been suspended. If you see an email saying otherwise, watch out! It’s a phishing campaign. (Source: Wired)

Safe surfing, everyone!

The post A week in security (November 6 – November 12) appeared first on Malwarebytes Labs.

Powered by WPeMatico

Nov 13, 2017
John
Comments Off on Augmented Reality games and real-world trolling

Augmented Reality games and real-world trolling

Augmented Reality games—where you wave a device around and the digital collides with reality— have been booming in popularity ever since Pokemon GO! rolled into mobile storefronts. However, many AR games haven’t really been designed with the possible consequences of real-world safety in mind. Take this hurricane howler, for example.

Even games that aren’t AR often include some sort of real-world activity. Black Watchmen is an Alternate Reality Game that involves solving puzzles both online and off, and depending on how much personal information you volunteer, you’ll gain access to more involved gameplay aspects.

At the absolute other end of the scale are games which (by accident or design) don’t include enough information ingame to explain how to achieve certain goals or tasks. In those cases, you’ll find a whole boatload of third-party tools, services, and community-driven sites that help keep the game fully functional from a “How do I do this?” perspective. Elite: Dangerous, for example [1], [2], [3]. This could also bring risks in the shape of fake/malicious downloadable programs.

In all of this, the potential for people to abuse tools outside of the game itself is high. And that’s exactly what happened to players of Ingress, the AR sci-fi game about aliens and capturing portals. The game relies on lots of player data, including location, which is a big part of how it works. And despite the data being anonymous (and stacked alongside piles of other player information), there are limits.

Geolocation is a huge driver for the game, and when a third-party tool designed to prevent players spoofing location was put to use by cheaters, it resulted in players finding themselves blocked into their property by vehicles, notes left on their doorstep, and even players on the other team knowing the “victim” was going out of town on holiday.

Many AR games are dead in the water without geolocation, as without it you may as well be sitting at home. The challenge for developers is to ensure games where players are in competition aren’t abused and turned into weird cases of real-world harassment. For now, these (hopefully isolated) stalker cases will likely put some folks off taking the plunge into competitive AR titles, and that’s a shame.

At a time when games are becoming more sociable, it’s ironic that a tool designed to stop cheaters has ended up becoming another sneaky way to grief people both online and off. “Be mindful of the information you post online and reveal in games” doesn’t really help much when the culprit is data being scraped outside of your control. So unless the games you play can prevent this kind of activity, you may wish to simply leave some mobile titles on the shelf for the time being.

The post Augmented Reality games and real-world trolling appeared first on Malwarebytes Labs.

Powered by WPeMatico

Nov 10, 2017
John
Comments Off on How to solve the Malwarebytes CrackMe: a step-by-step tutorial

How to solve the Malwarebytes CrackMe: a step-by-step tutorial

The topic of this post is a Malwarebytes CrackMe—an exercise in malware analysis that I recently created. First, the challenge was created to serve internal purposes, but then it was released to the community on Twitter and triggered a lot of positive response. Thanks to all of you who sent in your write ups! Some of the links are included in the appendix.

I got several questions from people who were stuck and needed some more explanation/guidance. So I promised to present my own solution in a step-by-step tutorial to the CrackMe. I am going go into detail so that even someone with little experience in reverse engineering will not feel lost. But if you still find something unclear, please don’t hesitate to ask in the comments.

The CrackMe was intended to be simple, yet to demonstrate various techniques commonly used by malware—that’s why we hoped it would be a good learning experience for the beginner malware analyst. Like always, the demonstrated solution is just one of many possible approaches.

Techniques demonstrated

The techniques/skills that we wanted to exercise in the CrackMe are:

  • Noticing common evasion tricks (antidebug, anti-vm, etc.) and bypassing the checks
  • Detecting XOR-obfuscated payload and decoding it
  • Basic understanding of the RunPE technique
  • Finding a way to debug/load shellcode

Environment and tools used

For the analysis environment, I used Windows 7 32bit on Virtual Box, with an Internet connection.

During the analysis, I used the following tools:

Stage 1

When we run the CrackMe, the first thing we see is the following banner:

So far, we know that the CrackMe is finished when we get a flag in the following format:

flag{...}

There is no password prompt whatsoever—we just see the failure message on the screen. The only way to understand it more is by looking inside. For this purpose, I am going to use IDA.

Finding the decisive variable

The code is not obfuscated, and we can easily see that this message comes after the check:

The success of the check will depend on the value of AL registry (AL=0 leads to failure). This value is set in the function above: sub_4014F0. Let’s go inside the function and see where exactly is it set:

So there is some variable (IDA automatically named it szUrl, suggesting that it will be used somewhere as a URL) that is passed to a function sub_403380. The output of this function (at this point we can guess that it is some checksum) is going to be compared with the hardcoded one. If it matches, AL is being set. So, our goal is to have szUrl filled in such a way that it will give us the valid checksum: 0x3B47B2E6.

Finding references

First, let’s have a look at the external references (xrefs) of the variable szUrl to find out how is it used and where is it set. We can view them by pressing CTRL+X in IDA:

As you can see, it is referenced from three places in the code. The second (highlighted) one is the place where we came from (szUrl being passed to the checksum calculation).

How is the variable used?

The third xref will probably refer to the usage of this variable. So, let’s see it:

Entering in the function sub_4033D0, we can see some API calls related to reading the content from the given URL, such as:

And:

At this point, we can be sure that the content of the szUrl, if filled correctly, will be used to download some content from the Internet.

How is the variable filled?

Now let’s have a look at the first reference and find out where the value of szUrl comes from:

We can see it is one of the parameters passed to the function sub_4031C0. This function takes also an array of DWORDs. Let’s look inside the function. We can see that Windows Crypto API is being used:

The passed content is decrypted with the help of Windows API, using AES algorithm.

Following the order of the passed parameters, it is easy to guess that this function is going to decrypt the passed buffer (the array of DWORDs) and the szUrl will be used to store the output. So the only thing that we need to take care of is a valid key for the decryption. Then we will get the proper URL that has the defined checksum 0x3B47B2E6.

Finding the decryption key

The key is derived from the hash another buffer, passed as one of the function’s parameters. We can see that Windows Crypto API is used to derive the hash. The used hashing function is SHA256 (algorithm ID: 0x800C = CALG_SHA_256):

This hash is used to derive the AES128 key (algorithm ID: 0x660E = CALG_AES_128):

We find that the buffer used as the base of the key is passed as a 4-th parameter to the function:

Let’s name it key_buf and find out where is is passed to the function:

Again, xfers can tell us more about where is it set:

We find out that the full buffer consists of pieces that are set DWORD by DWORD in various functions. Let’s have a look at each of those functions.

At this point, things are getting easy: We have various environment checks that malware often uses for recognizing if it is run in a controlled environment or not. For example, checking if it runs under the debugger:

While malware detecting the debugger often terminates the execution, in this case the conditions are reversed. Having each check passed/item detected gives us one more piece of data to the buffer. We need to catch them all!

We may achieve it by following each check and patching it out (removing the conditional jump) so that the chunk will be added to the buffer unconditionally. You can use IDA for patching, but IMHO it is not convenient, so I usually do it with the help of some other tools (debuggers like OllyDbg, or PE-bear), and use IDA just to find the branches.

Example: removing conditional checks in PE-bear:

Follow the offset of the check (CTRL+R):

Select the bytes on the hex view and modify them:

Result:

After following and removing all the checks, we can save the patched file:

If we deploy the patched version, we see some progress! The message “You are on the right track!” is printed on the screen. We can also see a hint that something is being uncompressed.

Examining the traffic

We already know that something was downloaded from the Internet (using the decrypted URL), so it may be helpful to have a closer look at the network traffic. There are many ways of checking the URL that was queried. We can do it with the help of Wireshark or Fiddler:

Request and response:

We see that the content was downloaded from the pastebin from the URL: http://pastebin.com/raw/9FugFa91

The content is in Base64, but decoding it by a Base64 decoder does not give us any sensible result. (We guess that the reason is the content is compresses and/or further encrypted). So, let’s go inside the applications again!

Understanding the payload

First, let’s do some static analysis to understand what exactly this payload is supposed to be and how is it going to be used. Let’s search first where the “Nope :(” message box is being shown. We see that before there is a check if the buffer starts from “MZ,” it is a well-known magic number starting DOS applications and also Windows Executables (PE files).

Taking a closer look at this function, we find out that the downloaded file is processed by few functions.

First, it is base64 decoded. Then, the output is uncompressed:

We understand that this function is responsible for decompression by looking inside and finding the relevant API calls, such as RtlDecompressBuffer:

Then, we notice a function that reads like something from the clipboard:

Going inside it, we can also easily find relevant API calls, such as:

We find that the format that is being read from the clipboard is one that measures text (CF_TEXT).

Then, we find that the content that was read from the clipboard is being used by another function. It becomes an XOR key to decrypt the downloaded content:

After all this, the result starts from the “MZ” magic number. It is being injected into rundll32.

Following inside the function sub_4011F0, we see exactly how the injection was made. It is a classic RunPE technique. The new process is created as suspended. The payload is being written into its memory space, linked to its PEB and resumed:

More detailed explanation of this well-known technique is out of scope of this article (you can find it here). However, unpacking it is very easy—we just need to dump the payload after it is decrypted but before it is converted into the virtual format and written to the remote process. I will show some of the possible unpacking methods next.

Decrypting the payload

During the static analysis, we found out the following information:

  • The payload is downloaded from the decrypted URL
  • It is Base64-decoded
  • It is decompressed with RtlDecompressBuffer
  • It is XOR-decrypted with the help of some key that is read from the clipboard

To pass this level, we must find the XOR key. It will not be difficult, knowing that the XOR operation is self-reversible. But first, let’s dump the payload after it is decompressed so that we can get the material for further analysis.

I will run the patched version of the CrackMe under the debugger (e.g. ImmunityDbg) and go to the API call RtlDecompressBuffer:

I am setting the breakpoint at the end of the decompression function and then running the CrackMe.

We can see on the stack the variable that was passed to the function. Let’s follow the buffer that was uncompressed:

We can see some repetitive patterns and the string “malwarebytes.” It is easy to guess that it will be the XOR key passed via clipboard. At this point, we can choose various approaches of unpacking it. I will demonstrate just one of them.

Decoding the XOR-obfuscated payload

After the buffer is decompressed, we dump it to file and decode by our external tool dexor.py.

First, we dump the buffer:

Then, we have to trim it so that it will start from the proper offset. We can do so by opening the dumped memory page in XVI32 hexeditor, navigating to the beginning of out buffer, and choosing:

Edit->Dump to cursor

Then, we can easily decode it by the script, supplying the XOR key. In this case, we could easily guess that the key is “malwarebytes” because this string repeats multiple times in the decoded buffer (XOR key is visible in those fragments of file when it was applied on NULL bytes).

dexyor.py --file dump.bin --key "malwarebytes"

You can see the steps taken on the video below:

As we expected, based on the earlier findings, the decoded output is a new PE file.

Stage 2

Stage 2 is inside the new executable. After we dumped it, we can run it as a fully independent module. We see that it pops up the following message:

Let’s open it in IDA and have a look. It is not obfuscated and the structure is pretty simple.

Understanding the checked conditions

First of all, we can see why the “Fail” message was displayed. The first thing that is checked is the module path, compared with the path to rundll32.exe. The check is not done by direct comparison of the strings, but instead, the checksums of the paths are calculated and compared:

In short, if the current PE is not injected into the rundll32.exe, the check should fail and lead to the mentioned message box. At the moment, we want to run this PE file as an independent unit, not via rundll32. So we need to get rid of this check. We can do it by simply patching out the conditional jump (the same way as we patched out the conditional jumps in Stage 1).

Alternatively, we can load the executable under a debugger, set the breakpoint on the check, and change the flag to bypass it.

In order for the final flag to pop-up, two more conditions have to be met:

1. A process with a window of given class has to be running in the system.

First, the EnumWindows function is called. The searched checksum is given in the parameter to the callback:

Inside the callback function, each window’s class name is compared to the checksum. If it matches, the particular process is being opened for further injection:

Someone may notice that this check is implemented similar to this one. The searched window class belongs to ProcessExplorer.

2. The application must be loaded under the debugger.

The presence of the debugger is being checked, and sets the flag that further on influences the value of the XOR key.

If we run the executable under the debugger and if we have a ProcessExplorer (32-bit) running, the MessageBox with the flag will be injected there and we will get the solution instantly. Example:

Dumping and running the shellcode

If we have luck, we may get it very quickly. But in real life, finding the proper process that has to be injected could be problematic. Also, people who were running the CrackMe on the 64bit version of Windows will encounter problems because the shellcode is 32bit and can be injected only to the 32bit version of Process Explorer. However, in order to solve it, knowing the process name is not at all required. We can just dump the shellcode before it is injected and load it by our own loader.

First, we have a look in IDA and see the part of the code where the injection is made. Before, the checksum of the shellcode is calculated:

So at this point we already have the valid shellcode stored in the buffer. We don’t really care where it is injected—we can just dump it and run it on our own. To reach this place, we only need to bypass the search of the window with the given checksum. We can do it by simply patching the condition (or changing the flag under debugger). This is the condition that must be patched out:

On the attached video we can see the full solution: dumping the shellcode and running it independently. In the given example, the shellcode was added as a new section to the original CrackMe with the help of PE-bear:

That’s how we got the final flag:

Conclusion

In this tutorial, I tried to explain step-by-step one of the possible solutions to the CrackMe. I recommend you to have a look at the write ups below to see different perspectives and learn more. And of course, I encourage you to try on your own and describe your own solution, because this is the best way to learn.

Appendix

Received write ups:

https://mauronz.github.io/mb-crackme/ – by @FraMauronz

https://drive.google.com/file/d/0Bzb5kQFOXkiSSURnMUZmaVpWRlk – by @JR0driguezB

https://drive.google.com/file/d/0Bzb5kQFOXkiSUmgwN2dWT21jdXM – by @ShAd0wHuNt3r_0

https://29wspy.ru/reversing/SolutionHasherezadeCrackme2017.pdf – by @ValthekOn

The post How to solve the Malwarebytes CrackMe: a step-by-step tutorial appeared first on Malwarebytes Labs.

Powered by WPeMatico

Location and hours

1-401-366-2249
Txt/Email or CALL NOW to discuss your recovery plan.
Computer repair association logo