IT News

Last week on Malwarebytes Labs, we looked at the strengths and weaknesses of the Zero Trust model, gave you the low-down on spear phishing, and took a delve into the world of securing the managed service provider (MSP).

Other cybersecurity news

• UN compromised via Sharepoint hack: An extraordinary tale highlighting that absolutely nobody is safe when bad things happen and are then covered up. (Source: The Register)
• TA505 returns: A well-known financial phishing attack is back from hiatus to cause chaos once again. (Source: Bleeping Computer)
• SMS phishing, aka smishing: Residents of Pitt County are warned to be wary of bogus FedEx notifications sent by text. (Source: News Channel 12)
• Social media booster runs into password mayhem: Another organisation discovers too late that plaintext passwords aren’t a great idea. (Source: TechCrunch)
• Ashley Madison breach returns to haunt us: Five years on, it’s causing problems in all new ways, fueling a new extortion scam. (Source: VadeSecure)
• Hacking in Hong Kong: ESET looks at how the Winnti group are targeting two Hong Kong Universities. (Source: ESET)
• Microsoft launches new bug bounty program: If you’re into gaming, this may be just what you’re looking for. (Source: Help Net Security)
• Big breach, big numbers: A compromise could potentially include a large tally of (more than 30 million) credit card information. (Source: Krebs on Security)
• The real world virus scammers have arrived: Booby-trapped Word documents pushing the Emotet Trojan are being fired out to people’s mailboxes, disguised as warnings about the coronavirus. (Source: TechRepublic)
• Tricky phishing: It may be the case that we’re not as good at detecting scams as we think we are. (Source: ZDNet)

Stay safe, everyone!

The post A week in security (January 27 – February 2) appeared first on Malwarebytes Labs.

We’ve previously discussed threats to managed service providers (MSPs), covering their status as a valuable secondary target to both an assortment of APT groups as well as financially motivated threat groups. The problem with covering new and novel attack vectors, however, is that behind each new vector is typically a system left unpatched, asset management undone, a security officer not hired (typically justified with factually dubious claims of a “skills shortage”) or a board who sees investment in infrastructure—and yes, security is infrastructure—as a cost center rather than a long-term investment in sustainable profits.

In short, malware can be significantly less dangerous to a business than that business’ own operational workflow.

Points of entry

Data on breach root causes is hard to come by, typically because security vendors tend to benefit by not providing industry vertical specific risk analysis. But the data that is available occasionally hints at corporate data breaches starting with some common unforced errors.

The 2019 Verizon DBIR claims that only 28 percent of observed data breaches involve the use of malware for the initial intrusion. While malware plays a significant role in the subsequent exploitation, the numbers suggest the majority of public breaches are not driven by zero-day exploits or outlandishly complex intrusion paths. So if you’re trying to secure an MSP, what are the most common entry points for attackers?

Under the broad heading of “hacking,” the most prominent observed tactics for point-of-entry include phishing, use of stolen credentials, and other social engineering techniques. Subsequent actions to further access include common use of backdoors or compromised web applications. Let’s break these down a little further.

Phishing is a reliable way of gaining a foothold to compromise a system. How would an employee clicking on a phish constitute an unforced error? Frequently, enterprises of all sorts incentivize their workers to click on absolutely everything, while simultaneously limiting their actual reading of messages. The consequences for poorly-designed corporate communications can be huge, as was seen when an MSP lost control of admin credentials via phishing attack that was subsequently used to launch ransomware.

Stolen credentials are a tremendously common attack vector that has been seen in several high profile MSP data breaches. “Stolen” is a bit of a misnomer though, and they would be better considered as “mishandled.”

Setting aside credentials gained via social engineering or phishing, companies can frequently lose track of credentials by keeping old or unnecessary accounts active, failing to monitor public exposure of accounts, failing to force resets after secondary breaches that may impact employees, failing to enforce modern password policies—basically failing to pay attention.

Should any single account with exposed credentials be over-privileged, a significant breach is almost guaranteed. And the consequences for MSPs with sloppy credential handling can be quite severe (1, 2).

Last in the lineup for unnecessary security failures is patch management. Like any other company trying to manage fixed infrastructure costs, MSPs rely heavily on third-party software and services. So when a business-critical support app is discovered to have multiple severe vulnerabilities, it introduces a wide-open channel for further exploitation. On occasion, the vulnerabilities used are brand new. Typically, they are not, and companies that fail to patch or mitigate vulnerable software get predictably exploited.

Mishandled mitigation

These attack entry points have a couple factors in common. First, they are not tremendously technically sophisticated. Even with regards to limited APT examples, the actors relied on compromised credentials and phishing first before deploying the big guns for lateral propagation. Second, mitigating these common entry points are actions that impacted MSPs should have been doing anyway.

Credential management that includes limited external monitoring, timely access control, and periodic privilege review doesn’t simply protect against catastrophic breaches—it protects against a host of attacks at all points of the technical sophistication spectrum.

Anti-phishing system design cues not only defend against employees leaking critical data, they also make for more efficient corporate communications, keep employees safe, and ideally reduce their overall email load.

Appropriate logging with timely human review cuts down time to breach discovery, but also assists in detailed risk analysis that can make for lean and effective security budgets into the future. The relationship between all of these security behaviors and observed MSP data breaches suggests that more attention to industry best practices could have gone a long way toward eliminating or sharply diminishing breach risk.

Finally, a patch management schedule that tracks third party software and services, fixing vulnerabilities in a timely manner is a great way to close some of the largest entry points into an MSP. Subordinating patches to non critical business needs, not having a test network to deploy patches, or simply not patching at all is a large signpost to attackers signifying an easy target.

MSP security: not a luxury

An MSP might be tempted to consider security as an expensive indulgence—something to be considered as a nice-to-have after uptime and availability of resources. Done well, it is neither expensive, nor a luxury.

Adherence to security norms that have been well defined for years can go a long way toward preventing big breaches, and can do so without expensive vendor contracts, pricy consultants, or best-in-class equipment. A managed service provider who chooses to ignore or delay those norms does so at its peril.

The post Securing the MSP: their own worst enemy appeared first on Malwarebytes Labs.

Phishing, a cyberattack method as old as viruses and Nigerian Princes, continues to be one of the most popular means of initiating a breach against individuals and organizations, even in 2020. The tactic is so effective, it has spawned a multitude of sub-methods, including smishing (phishing via SMS), pharming, and the technique du jour for this blog: spear phishing.

But first, a quick parable.

A friend of mine received a blitz of emails over the course of a few days, all geared toward their Netflix account.

Click to enlarge

The clues indicating something wasn’t quite right were numerous:

• There were half a dozen emails instead of just one.
• All of them required payment information, but each mail gave a different reason as to why.
• There were spelling mistakes galore.
• The emails were not personalised in any way.

Even without spotting the utterly bogus, non HTTPS URL linked from the email body, this friend would never have fallen for it. Granted, they have a decent knowledge of security basics. However, consider if the attacker had done this:

• Grabbed some personal details from a data dump
• Hunted online for accounts belonging to this person, perhaps on social media
• Checked to see if they had an account with Netflix
• Crafted an imitation Netflix email address
• Addressed the potential victim directly by name
• Included some or all of their home address
• Made use of spell check
• Set up a free HTTPS website
• Used the most current version of Netflix’s logo

See the difference? While the first set of emails wouldn’t pass muster with a marginally knowledgeable user, the second would be much more difficult to screen as fake.

And that is what’s known in the business as spear phishing.

What is spear phishing?

Spear phishing’s sole purpose is to get inside the recipient’s head and make them think the messages they’re responding to are 100 percent legitimate—achieved due to personal touches designed to make them think what they’re dealing with is the real deal.

While you could argue alarm bells should ring when being asked for credit card details, in all honesty, once the scammer has thrown a few personal details into the mix like name and address, it may well be too late.

Imagine if the scammer monitored social media feeds to see which shows their target liked, then said something like, “Please ensure your details are correct to continue enjoying The Witcher.” Now add a picture of Henry Cavill looking cool.

Game. Over.

As you might expect, this kind of attack is rather difficult to combat. It doesn’t help when utterly random nonsense such as the poorly-made Netflix phishing attempt regularly inflict huge losses on organisations across the globe, despite being pretty terrible.

How many times have we seen healthcare facilities and even local municipal governments fall foul to ransomware via pretend spreadsheet attachments in fake HR tax emails? Make no mistake, this is a very real and immediate problem for those caught out.

With generic phishing already causing huge headaches for businesses and consumers alike, cybercriminals using data dumps expertly combined with professional social engineering techniques have an ever higher likelihood of success. And that’s before you consider other forms of spear phishing, such as conversation hijacking (more on this later), or attacks that use the spear phish as a launching pad for infecting networks with malware and other digital nasties.

Shall we take a look at some numbers?

Watch those verticals

A few years ago, the average cost of spear phish prevention over 12 months was $319,327 versus the significantly higher cost of any successful attack, which weighed in at $1.6 million. In 2019, the stats leaning heavily towards spear phishing speak for themselves, and huge payouts for scammers are the order of the day.

Payouts of $40 million, $50 million, and even $70 million and beyond are common, and that’s before you get to the cost of the cleanup and class action lawsuits. Throw in a little reputation damage and a PR firestorm, and you have all the ingredients for a successful breach. For the victims, not so much.

With spear phishing, the slightest piece of information can bring about an organisation’s downfall as it slices through all its otherwise fully functional security defences.

Evolution of the spear phish

Spear phishing isn’t only left to the realm of emails. Highly-targeted attacks also branch out into other areas, especially ones full of self volunteered information. Hijacking customer support conversations on Twitter is a great example of this: scammers set up imitation support accounts then barge into the conversation, leading the victim to phishing central. It’s a slick move.

It’s debatable how much of these scams are targeted, considering they’re making their attack up on the fly, instead of wading in with pre-gained knowledge. The difference here is the recon is aimed at the person the potential victim is being helped by, as opposed the victim themselves. Making note of when the customer support account is active, looking at initial Tweets so they can pretend to be the same person who helped before, and adopting some of their speech mannerisms/corporate speak all help to create a convincing illusion.

At that point, all we’re really dealing with is a perfectly-crafted imitation email but in human form, and with the ability to interact with the victim. Has spear phishing ever seen such a potent way to go on the offensive? When people are happy to weaponise customer support to use them against you, it’s really something to sit down and consider.

Fighting the rising tide of spear phishing

Anybody can be a target, but executives, especially at the CEO level, is where it’s at in terms of big scores for criminals (a form of targeting sometimes called whaling). By necessity, most organisations’ executives are set up to be publicly visible, and scammers take advantage of this. As has been mentioned, this is one of the toughest forms of attack to defend against.

If the social engineering component is designed to open the network to malware abuse, then we also need to consider the overall security infrastructure. Security software, updates, firewalls, and more all become important tools in the war against spear phishing—especially given what can come after the initial foot in the door attack.

Tools such as spam filtering and detection are great for random, casual attacks, but given the direct nature of spear phishing, it may well be a bridge too far for automation to flag as suspicious. Dedicated, ongoing training is important at all levels of the business, alongside not getting into the habit of blaming employees and third parties when things go wrong (and they will, eventually). You don’t want people less likely to report incidents out of fear of getting into trouble—it’s not productive and won’t help anybody.

Tools to aid in reporting spear phishing attacks, either dedicated apps or something web-based inside the network, are always useful. It’s also good to ensure departments have at least some idea how important business processes work in other departments. Securing the organization is a little easier when unrelated department A is an additional layer of defence for unrelated department B. Pay attention to HR, accounting, and top line exec interaction.

If your organisation hasn’t considered what to lock down yet, there’s never been a better time. Europol’s EC3 report on spear phishing was released late last year and contains a wealth of information on the subject for those wanting to dive deeper.

Ponder all forms of phishing, see which one(s) may be the biggest danger to your organisation and your employees, and start figuring out how best to approach the issue. You won’t regret it—but the scammers certainly will.

The post Spear phishing 101: what you need to know appeared first on Malwarebytes Labs.

In a US court of law, the accused are deemed to be innocent until proven guilty. In a Zero Trust security model, the opposite is true. Everything and everyone must be considered suspect—questioned, investigated, and cross-checked—until we can be absolutely sure it is safe to be allowed.

Zero Trust is a concept created by John Kindervag in 2010 during his time as Vice President and Principal Analyst for Forrester Research. When looking at failures inside organizations to stop cyberattacks, especially lateral movements of threats inside their networks, Kindervag realized that the traditional security model operated on the outdated assumption that everything inside an organization’s network could be trusted. Instead, Zero Trust inverts that model, directing IT teams according to the guiding principle of “never trust, always verify” and redefining the perimeter to include users and data inside the network.

Over the last 10 years, more and more businesses have moved toward the Zero Trust model, demolishing the old castle-and-moat mentality and accepting the reality of insider threats. We take an inside look at Zero Trust, including its strengths and weaknesses, to help organizations evaluate whether they should embrace the philosophy within their own walls or consider different methods.

Definition of Zero Trust

Zero Trust is an information security framework that states organizations should not trust any entity inside or outside of their network perimeter at any time. It provides the visibility and IT controls needed to secure, manage, and monitor every device, user, app, and network belonging to or being used by the organization and its employees and contractors to access business data.

The goal of a Zero Trust configuration should be clear: restrict access to sensitive data, applications, and devices on a need-to-know basis. Employees in finance need accounting software—all others should be barred. Remote workers should use VPNs—access from the open Internet should be prohibited. Data sharing should be limited and controlled. The free flow of information that was once one of the cornerstones of the Internet needs to be confined in order to protect networks from penetration, customers from privacy violations, and organizations from attacks on infrastructure and operations.

The strategy around Zero Trust boils down to scrutinizing any incoming or outgoing traffic. But the difference between this and other security models is that even internal traffic, meaning traffic that doesn’t cross the perimeter of the organization, must be treated as a potential danger as well.

While this might seem severe, consider the changes in the threat landscape over the last 10 years: the hundreds of public data leaks and breaches; ransomware attacks that halted operations on thousands of endpoints in cities, schools, and healthcare organizations; or millions of users’ personally identifiable information stolen from business databases. As cybercriminals continue to turn their focus to business targets in 2020, Zero Trust seems like a smart approach to thwart increasing numbers of attacks.

Implementing Zero Trust

Implementing a Zero Trust security model in an organization is not simply a change in mindset. It will require a clear view of functions within the company’s departments, currently-deployed software, access levels, and devices, and what each of those requirements will look like in the future.

Often, building a Zero Trust network from the ground up is easier than reorganizing an existing network into Zero Trust because the existing network will need to remain functional throughout the transition period. In both scenarios, IT and security teams should come up with an agreed-upon strategy that includes the ideal final infrastructure and a step-by-step strategy on how to get there.

For example, when setting up resource and data centers, organizations may have to start almost from scratch, especially if legacy systems are incompatible with the Zero Trust framework—and they often are. But even if companies don’t have to start from scratch, they may still need to reorganize specific functions within their security policy, such as how they deploy software or onboard employees, or which storage methods they use.

Strengths of Zero Trust

Building Zero Trust into the foundation of an organization’s infrastructure can strengthen many of the pillars upon which IT and security are built. Whether it’s in bolstering identification and access policies or segmenting data, by adding some simple barriers to entry and allowing access on an as-needed basis, Zero Trust can help organizations strengthen their security posture and limit their attack surface.

Here are four pillars of Zero Trust that we believe organizations should embrace:

• Strong user identification and access policies
• Segmentation of data and resources
• Strong data security in storage and transfer
• Security orchestration

User identification and access

Using a secure combination of factors in multi-factor authentication (MFA) should provide teams with sufficient insight into who is making a request, and a well thought-out policy structure should confirm which resources they can access based on that identification.

Many organizations gate access to data and applications by opting for identity-as-a-service (IDaaS) cloud platforms using single sign-on services. In a Zero Trust model, that access is further protected by verifying who is requesting access, the context of the request, and the risk of the access environment before granting entry. In some cases, that means limiting functionality of resources. In others, it might be adding another layer of authentication or session timeouts.

Segmentation

Robust access policies will not make sense without proper segmentation of data and resources, though. Creating one big pool of data where everyone that passes the entrance test can jump in and grab whatever they want does not protect sensitive data from being shared, nor does it stop insiders from misusing security tools or other resources.

By splitting segments of an organization’s network into compartments, Zero Trust protects critical intellectual property from unauthorized users, reduces the attack surface by keeping vulnerable systems well guarded, and prevents lateral movement of threats through the network. Segmentation can also help limit the consequences of insider threats, including those that might result in physical danger to employees.

Data security

Even with restricting access to data and reducing the attack surface through segmentation, organizations are open to breaches, data leaks, and interception of data if they do not secure their data in storage and in transit. End-to-end encryption, hashed data, automated backups, and securing leaky buckets are ways organizations can adopt Zero Trust into their data security plan.

Security orchestration

Finally, drawing a thread through all of these pillars is the importance of security orchestration. Even without a security management system, organizations using Zero Trust would need to ensure that security solutions work well together and cover all the possible attack vectors. Overlap is not a problem by itself, but it can be tricky to find the right settings to maximize efficiency and minimize conflicts.

Challenges of the Zero Trust strategy

Zero Trust is billed as a comprehensive approach to securing access across networks, applications, and environments from users, end-user devices, APIs, IoT, micro-services, containers, and more. While aiming to protect the workforce, workloads, and workplace, Zero Trust does encounter some challenges. These include:

• More and different kinds of users (in office and remote)
• More and different kinds of devices (mobile, IoT, biotech)
• More and different kinds of applications (CMSes, intranet, design platforms)
• More ways to access and store data (drive, cloud, edge)

Users

In the not-too-distant past, it was commonplace for the vast majority of the workforce to spend the entirety of their working hours at their place of employment. Not true today, where, according to Forbes, at least 50 percent of the US population engage in some form of remote work. That means accessing data from home IPs, routers, or public Wi-Fi, unless using a VPN service.

But users are not necessarily limited to a workforce. Customers sometimes need to access an organization’s resources, depending on the industry. Consider customers that want to select orders for their next delivery, check on inventory, participate in demos or trials, and of course access a company’s website. Suppliers and third-party service companies may need access to other parts of an organization’s infrastructure to check on operations, safety, and progress.

All of these instances point to a wide variation in user base and a larger number of access points to cover. Coming up with specific policies for each of these groups and individuals can be time-consuming, and maintaining the constant influx of new employees and customers will add considerable workload for whomever manages this task moving forward.

Devices

In this era of BYOD policies and IoT equipment, plus the “always on” mentality that sometimes strikes for remote employees, organizations must allow for a great variation in devices used for work, as well as the operating systems that come with them. Each of these devices have their own properties, requirements, and communication protocols, which will need to be tracked and secured under the Zero Trust model. Once again, this requires a bit more work upfront but likely yields positive results.

Applications

Another challenging factor to take into account when adopting a Zero Trust strategy is the number of applications in use across the organization for people and teams to collaborate and communicate. The most versatile of these apps are cloud-based and can be used across multiple platforms. This versatility can, however, be a complicating factor when deciding what you want to allow and what not.

Are the apps shared with third-party services, agencies, or vendors? Are the communication platforms outward-facing, and not just for employees? Is this application necessary only for a particular department, such as finance, design, or programming? All of these questions must be asked and answered before blindly adopting a stack of 60 applications for the entire workforce.

Data

One reason why the old security policies are growing out of favor is that there’s no one, fixed location that needs to be protected any longer. Organizations can’t just protect endpoints or corporate networks. More and more resources, data, and even applications are stored in cloud-based environments, meaning they can be accessed from anywhere and may rely on server farms in various global locations.

This is further complicated by the potential shift to edge computing, which will require IT teams to switch from a centralized, top-down infrastructure to a decentralized trust model. As we have seen in our series about leaky cloud resources (AWS buckets and elastic servers), the configuration of data infrastructure in cloud services and beyond will need to be flawless if businesses don’t want it to end up as the weakest link in their Zero Trust strategy.

To trust or not to trust

Overhauling to a Zero Trust security framework isn’t easily accomplished, but it’s one we feel strengthen’s an organization’s overall security posture and awareness. IT teams looking to convince executives of the old guard might look for prime opportunities, then, to make their argument. For example, if there’s already a planned move to cloud-based resources, that’s a good time to suggest also adopting Zero Trust.

Changes in the threat landscape, including recent vulnerabilities in VPNs and Citrix, plus ransomware being delivered through Remote Desktop Protocol (RDP), might encourage more organizations to investigate a Zero Trust solution, if only for identity and access management. These organizations will have to allow for a transition period and be prepared for some major changes.

A proper Zero Trust framework that doesn’t automatically allow traffic inside the perimeter will certainly hinder the lateral threat movement that hackers use to tighten their grip on a breached network. Top business-focused threats such as Emotet and TrickBot would be hindered from spreading, as they’d be unable to work their way from server to server in a segmented network. Since the point of infiltration is usually not the target location of an attacker, setting up internal perimeters can also limit the severity of a successful attack.

Add to these layers strong data security hygiene and intelligent orchestration that provides wide coverage across threat types, operating systems, and platforms, and businesses have a security framework that’d be pretty tough to beat today. In our eyes, that makes Zero Trust a hero.

The post Explained: the strengths and weaknesses of the Zero Trust model appeared first on Malwarebytes Labs.

Last week on Malwarebytes Labs, we reported on a Ryuk ransomware attack on The Tampa Bay Times, a newspaper in Florida; unmasked an elaborate browser locking scheme behind the more advanced tech support operations that are currently active; and looked at the latest laws on regulating deepfakes.

Other cybersecurity news

• Cisco’s Talos Intelligence Group discovered a new data stealer and called it JhoneRAT. This latest remote access Trojan (RAT) was designed and created to target Arabic-speaking nations. (Source: TechDator)
• Fake videos purportedly taken by Nest cameras are used to perform sextortion campaigns against their users. (Source: Bleeping Computer)
• The Philippine Airlines (PAL) warned locals of a phishing site using a bogus Facebook ad and claiming that participants could win free tickets in exchange for answering questions. (Source: ABS-CBN News)
• The Better Business Bureau (BBB) alerted readers of a tech support scam using the “Expiring License” lure to get the attention and trick Windows users into giving out their banking details. (Source: Better Business Bureau News)
• 70,000 photos of users of the dating app, Tinder, were found on the public web for free. Along the photos were data of 16,000 Tinder user IDs. (Source: Sophos’s Naked Security Blog)
• Point-of-sale (PoS) software company, THSuite, was found to be breached after sensitive data of cannabis users were leaked because of an insecure Amazon S3 bucket. (Source: Newsweek)
• Google security engineers found that Apple’s privacy protections on Safari actually put user data at risk. (Source: CNET)
• Hiring scams or fake job listings target job seekers’ personally identifiable information, warns the FBI. (Source: FBI PSA)
• In contrast to what is generally advised, new survey found that victims continue to pay ransomware threat actors to prevent business disruption. (Source: DarkReading)
• PupyRAT, a Trojan believed to be linked to state-backed threat actors working out of Iran, was found targeting the European energy sector since late 2019. (Source: ZDNet)

Stay safe, everyone!

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

Florida newspaper The
Tampa Bay Times suffered a Ryuk ransomware attack Thursday, making it the
latest major victim of the notorious ransomware family that continues to rise
in popularity.

Curiously, the paper is at least the third Florida-based Ryuk
victim in the past year.

The attack, which The Tampa Bay Times reported on itself, did not result in any breached data. Sensitive customer information, such as subscriber addresses and credit card details, was not disclosed in the breach, the newspaper said.

The Tampa Bay Times
chief digital officer Conan Gallaty said the paper had “a lot of plans for
systems that go down,” and that its priority was in restoring and securing
operations.

“The focus for us is to fully recover and then work on
further preventative measures,” Gallaty said.

The newspaper did not respond to the threat actors, and
Gallaty said the paper would have refused any ransom payment demanded. This
stalwart opposition is becoming less common today, as increasingly companies
are forced to choose between the loss of several hundred thousand dollars in
ransom payments, or several hundred thousand dollars in database and operations
recovery.

Further, when some companies hire the help of outside malware recovery firms, they may be signing up, quietly, for ransomware negotiations. A ProPublica investigation last year found that at least two cybersecurity firms that touted allegedly advanced technology solutions would, in fact, pay off the ransoms demanded by the threat actors who breached their clients.

The investigation of two firms found that:

“The [cybersecurity] firms are alike in other ways. Both
charge victims substantial fees on top of the ransom amounts. They also offer
other services, such as sealing breaches to protect against future attacks.
Both firms have used aliases for their workers, rather than real names, in
communicating with victims.”

Though The Tampa Bay Times did not disclose the Ryuk ransomware attack vector, Gallaty said he believed the paper was unlikely to be a specific target for the threat actors. That’s hard to reconcile with Ryuk’s history—already it has been responsible for crippling the delivery operations for at least four major US newspapers, including The Chicago Tribune and The Los Angeles Times.

In speaking with The
Tampa Bay Times, Malwarebytes senior security researcher JP Taggart
explained the calculus behind potential Ryuk ransomware targets:

“They’re looking at the people that have the most to lose.”

That bears true when looking at recent Ryuk victims.

In June 2019, the government of Lake City, Florida, crawled to a halt, with phones and computer systems stalled after threat actors successfully implanted a Ryuk variant into the city’s network. Unable to work themselves out of the problem, even with the help of the FBI, the city had to make a choice. It chose to pay $460,000. A similar situation happened months later, in October, when the Alabama-based DCH Health System was forced to partially shut down three of its hospitals after a Ryuk attack. Again, unable to solve the problem, and unable to continue to turn away all but the most critical patients, the hospital operator decided to prioritize patient care, paying an undisclosed amount to the threat actors.

Those payments add up. According to CrowdStrike, Ryuk’s deployment teams have amassed more than $3.7 million in paid ransoms.

When Ryuk’s threat actors haven’t successfully scored a big pay day, though, they’ve still managed to do enormous damage. In April 2019, Imperial County, California, refused to pay an enormous $1.3 million ransom from a Ryuk attack, but, according to The Wall Street Journal, the city has spent $1.6 million in recovery efforts. In late December, the US Coast Guard publicly announced that it suffered a Ryuk attack that shut down a maritime facility for 30 hours.

The ransomware campaigns became so common that the FBI warned the public that threat actors had used Ryuk to target more than 100 US and international businesses since its emergence in August 2018.

According to new Malwarebytes data, those attacks have
continued. From January 1–23, 2020, Malwarebytes recorded a cumulative 724 Ryuk
detections. The daily detections fluctuated, with the lowest detection count at
18 on January 6, and the highest detection count at 47 on January 14.

The ransomware frequently works in conjunction with Emotet
and TrickBot in multi-stage attacks. Those separate malware families have also
been active in the new year, with small spikes into the thousands of
detections. Emotet, particularly, kicked
itself into high gear again starting on January 13.

As we explained before in our threat spotlight on Ryuk:

“The first stage of the attack starts with a weaponized
Microsoft Office document file—meaning, it contains malicious macro
code—attached to a phishing email.
Once the user opens it, the malicious macro will run cmd and execute a PowerShell command. This command
attempts to download Emotet.

Once Emotet executes, it retrieves and executes another
malicious payload—usually TrickBot—and collects information on affected systems. It
initiates the download and execution of TrickBot by reaching out to and
downloading from a pre-configured remote malicious host.

Once infected with TrickBot, the threat actors then check if the
system is part of a sector they are targeting. If so, they download an additional
payload and use the admin credentials stolen using TrickBot to perform lateral
movement to reach the assets they wish to infect.

The threat actors then check for and establish a connection with
the target’s live servers via a remote desktop protocol (RDP).
From there, they drop Ryuk.”

The Tampa Bay Times
did not specify which systems, or how many computers, were disrupted in
Thursday’s attack. Instead, the only hint of inconvenience in the newspaper’s routine
was the acknowledgement that Friday’s newspaper would be published with an
earlier deadline.

The show must go on.

The post Tampa Bay Times hit with Ryuk ransomware attack appeared first on Malwarebytes Labs.

In a rare example of legislative haste, roughly one dozen state and federal bills were introduced in the past 12 months to regulate deepfakes, the relatively modern technology that some fear could upend democracy.

Though the federal proposals have yet to move forward, the state bills have found quick success at home. Already three states—California, Virginia, and Texas—have enacted deepfake laws, and legislation is pending in Massachusetts, New York, and Maryland, which introduced its own bill on January 16 this year.

The laws and pending legislation vary in scope, penalties,
and focus.

The Virginia law amends current criminal law on revenge porn, making it a crime to, for instance, insert a woman’s digital likeness into a pornographic video without her consent. The Texas law, on the other hand, prohibits the use of deepfakes for election interference, like making a video that fraudulently shows a political candidate at a Neo-Nazi rally one month prior to an election.

A New York bill tackles an entirely different subject—how to treat a deceased person’s digital likeness, a reality that is coming to a screen near you (starring James Dean). And two state laws potentially address the rising threat of “cheapfakes,” low-tech digital frauds that require no artificial intelligence tools to make.

This legislative experimentation is expected for an emerging
technology, said Matthew F. Ferraro, a senior associate at the law firm
WilmerHale who advises clients on national security, cyber security, and crisis
management.

“In some ways, this is [an example] of the laboratories of
democracy,” Ferraro said, citing an idea popularized decades ago by Supreme
Court Justice Louis Brandeis. “This is what people cheer about.”

But one category of deepfakes legislation has earned more upset than others—the kind that solely regulates potential election interference. Groups including the American Civil Liberties Union, Electronic Frontier Foundation, and First Draft, which researches and combats disinformation, warn of threats to free speech.

Further, prioritizing political deepfakes legislation could, in effect, deprioritize the larger problem of deepfake pornography, which accounts for a whopping 96 percent of deepfake material online today, said Adam Dodge, founder of the nonprofit End Technology-Enabled Abuse, or EndTAB.

“I think it’s
important that we address future harm, I just don’t want that to come at the
expense of the people being harmed right now,” Dodge said. “We have four
deepfakes laws on the books in the United States, and 50 percent of them don’t
address 96 percent of the problem.”

Today, Malwarebytes provides a more detailed look at deepfakes legislation and laws in the United States, following our analysis last week of the country’s first-ever, federal deepfake rules. Far beyond what that language requires, the following bills and laws call for civil and criminal penalties, and directly address concerns of both political disinformation and nonconsensual pornography.

Federal deepfakes legislation before Congress

Before lawmakers in Washington, DC, are at least four federal deepfakes bills in both the US House of Representatives and the Senate. They are:

• The Identifying Outputs of Generative
  Adversarial Networks (IOGAN) Act
• The Deepfake Report Act of 2019
• A Bill to Require the Secretary of Defense to
  Conduct a Study on Cyberexploitation of Members of the Armed Forces and Their
  Families and for Other Purposes
• The Defending Each and Every Person from False
  Appearances by Keeping Exploitation Subject (DEEP FAKES) to Accountability Act

The bills largely hew to one another. The IOGAN Act, for example, would require the directors of both the National Science Foundation and the National Institute of Standards and Technology to submit reports to Congress about potential research opportunities with the country’s private sector in detecting deepfakes.

The Deepfake Report Act would require the Department of Homeland Security to submit a report to Congress about the technologies used to create and detect deepfakes. Senator Ben Sasse’s “cyberexploitation” bill would require the Secretary of Defense to study the potential vulnerabilities of US armed forces members to cyberexploitation, including “misappropriated images and videos as well as deep fakes.”

The DEEP
FAKES Accountability Act, however, extends beyond reporting and research requirements.
If passed, the bill would require anyone making a deepfake—be it image, audio,
or video—to label the deepfake with a “watermark” that shows the deepfake’s
fraudulence.

But Dodge said
watermarks and labels would fail to help anyone whose likeness is used in a
nonconsensual deepfake porn video.

“The reality is, when it comes to the battle against deepfakes,
everybody is focused on detection, on debunking and unmasking a video as a
deepfake,” Dodge said. “That doesn’t help women, because the people watching those
videos don’t care that they’re fake.”

The DEEP
FAKES Accountability Act would make it a crime to knowingly fail to provide that
watermark, punishable by up to five years in prison. Further, the bill would
impose a civil penalty of up to $150,000 for each purposeful failure to provide
a watermark on a deepfake.

According to
Electronic Frontier Foundation, those are severe penalties for activities that
the bill itself fails to fully define. For example, making a deepfake with the
intent to “humiliate” someone would become a crime, but there is no clear
definition of what that term means, or whether that humiliation would require
harm. In the bill’s attempt to stop deceitful and malicious activity, the organization
said, it may have reached too far.

“The [DEEP
FAKES Accountability Act] underscores a key question that must be answered:
from a legal and legislative perspective, what is the difference between a
malicious ‘deepfakes’ video and satire, parody, or entertainment?” the
organization wrote. “What lawmakers have discussed so far shows they do not
know how to make these distinctions.”

Statewide,
the concerns shift to whether deepfakes legislation will have its intended
effect.

State deepfakes laws and legislation

Last summer, the warnings about the democratization of deepfakes technology became reality—a new app offered for free on Windows gave users the ability to remove clothes from uploaded photos of women. The app, called DeepNude, was first discovered by Motherboard. It shut down just hours after the outlet published its first piece.

Less than one week later, a new deepfake law in Virginia came
into effect. The state’s lawmakers had passed it months earlier, in March.

Unique when compared to later state deepfake laws, Virginia’s
law did not craft a new crime for deepfake creation and distribution, but
instead expanded its current law on revenge porn to include deepfakes material.
Now, in Virginia, anyone who shares or sells nude or sexual images and videos—including
deepfakes—with the intent to “coerce, harass, or intimidate,” is guilty of a
Class 1 misdemeanor.

Dodge said he appreciated Virginia’s approach.

“The Virginia law is interesting because it’s the only law
that has taken the existing nonconsensual pornography criminal code section and
amended it to include deepfakes pornography,” Dodge said, “and I like that.”

Shortly after Virginia enacted its deepfake law, Texas
followed, passing a law that instead focused on election interference.
According to the law, the act of creating and sharing a deepfake video within 30
days of an election with the intent to “injure a candidate or influence the
result of an election” is now a Class A misdemeanor. The law’s definition of a
deepfake is broad: a video “created with the intent to deceive, that appears to
depict a real person performing an action that did not occur in reality.”

The law has already received a high-profile use-case: Houston Mayor Sylvester Turner asked the district attorney to investigate his opponent’s campaign for making a television ad that showed edited photos of the mayor, along with an allegedly fake text he sent.

In October, California followed both Virginia and Texas, passing two laws—one to prohibit nonconsensual deepfake pornography, and the other to prohibit deepfakes used to impact the outcome of an upcoming election.

The bills’ author—Assembly Member Marc Berman—said he wrote the latter bill after someone created and shared an altered video of Nancy Pelosi, appearing to show her as impaired or drunk. But the video was far from a deepfake. Instead, its creator simply took footage of the Speaker of the House of Representatives and slowed it down, making what is now referred to as a “cheapfake.”

Ferraro said that trying to pass legislation to prevent
cheapfakes will be difficult, though.

“It’s going to be very hard to write a bill that captures
all of those so-called cheapfakes, because the regular editing of videos could
fall under a definition that is too broad,” Ferraro said, explaining that standard,
everyday broadcast interviews incorporate countless edits that might change the
overall impression of the interview to audiences, even when the edits are done
for non-malicious reasons, like cutting away from a political candidate giving
a speech to show their audience.

“That’s the sort of problem of the cheapfake: Simple editing
can give vastly different impressions, based on the content,” Ferraro said.

As California, Texas, and Virginia work out the enforcement
of their laws, Maryland, New York, and Massachusetts are considering their own approaches
to legislating deepfakes.

On January 16, Maryland introduced a bill targeting political influence deepfakes. The bill, which has a scheduled hearing in early February, prohibits individuals from “willfully or knowingly influencing or attempting to influence a voter’s decision to go to the polls or to cause a vote for a particular candidate by publishing, distributing, or disseminating a deepfake online within 90 days of an election.”

The Massachusetts deepfake legislation would criminalize the
use of deepfakes for already “criminal or tortious conduct,” in effect making
it illegal to use a deepfake in conjunction with completing other crimes. So,
committing fraud? That’s a crime. But deploying a deepfake to aid in committing
that fraud? Well, that would also be a crime.

Finally, in New York, state lawmakers are trying to
legislate a different aspect of deepfakes and digital recreations—the rights to
an individual’s digital likeness. The bill was introduced last year, expired,
and was then re-introduced. It would protect a person’s digital likeness 40
years after their death. The bill would also create a registry for surviving
family members to record their control of a deceased relative’s likeness.

The Screen Actors Guild‐American Federation of Television
and Radio Artists supported the bill.

“The state’s robust performance community should not have to endure years of costly litigation to protect their basic livelihood and artistic legacy,” the group said.

Major motion picture studios, including Disney, Warner Bros., and NBCUniversal opposed the bill. Though Disney’s filmmakers said they received approval from the estate of the late actor Peter Cushing to use his likeness in the 2017 movie Star Wars: Rogue One, it’s not hard to see why required approval for future projects would prove an obstacle for Hollywood.

What next?

The opposition to deepfakes laws is clear: Such laws could
be overbroad, uninformed, and, in their attempt to regulate one problem,
actually trample on the protected rights of Americans.

The bigger question is, has the opposition been successful? In
a word, no.

Texas passed its election interference deepfake law with no recorded opposition votes in either the House or the Senate (though two House members were a “no vote” and four abstained). California similarly passed its election interference deepfake law in a 67–4 vote in the Assembly and a 29–7 vote in the Senate. After the vote, the ACLU of California wrote to the California governor, asking for a veto. It didn’t work.  

In Washington, DC, though, the situation could be different, since new Federal rules on deepfakes research were approved last month. Those rules require the Director of National Intelligence to submit a report to Congress in 180 days about deepfakes capabilities across the world and possible countermeasures in the US. Until that report is submitted, Senators and Representatives might have little appetite to move forward.

Much like the statewide sweep of data privacy laws last year, the future of deepfake laws depends on political will, popularity, and whether lawmakers even have time to draft and pass such legislation. It is, after all, an election year.

The post Deepfakes laws and proposals flood US appeared first on Malwarebytes Labs.

In the early days, practically all tech support scammers would get their own leads by doing some amateur SEO poisoning and keyword stuffing on YouTube and other social media sites. They’d then leverage their boiler room to answer incoming calls from victims.

Today, these practices continue, but we are seeing more advanced operations with a clear separation between lead generation and actual call fulfillment. Malvertising campaigns and redirections from compromised sites to browser locker pages are owned and operated by experienced purveyors of web traffic.

There is one particular browser locker (browlock) campaign that had been eluding us for some time. It stands apart from the others, striking repeatedly on high-profile sites, such as the Microsoft Edge Start page, and yet, eluding capture. In addition, and a first to our knowledge, the browser locker pages were built to be ephemeral with unique, time-sensitive session tokens.

In November 2019, we started dedicating more time to investigating this campaign, but it wasn’t until December that we were finally able to understand its propagation mechanism. In this blog, we share our findings by documenting how threat actors used targeted traffic-filtering coupled with steganography to create the most elaborate browser locker traffic scheme to date.

A well-documented history

There are many public reports about this tech support scam affecting users with the same red screen template. Contrary to what some people have posted online, this is not malware, and computers aren’t infected. It is simply what we call a browser locker, or browlock for short, a social engineering technique that gives the illusion of a computer virus and scares people into calling a toll-free number for assistance. Here are some examples:

• When Searching Ebay only I get Google Chrome Critical Error (eBay forums)
• Microsoft Edge Critical Process Died Stop Code – Red Screen (Microsoft forums)
• First full day using new Surface and get this “critical process died error report”. Why? (Reddit)
• Google Chrome Critical Error after update (Malwarebytes forums)

One lengthy and epic forum thread on Microsoft’s forums describes how this browlock campaign has been afflicting the Microsoft Edge start page and even left Microsoft engineers puzzled as to where, exactly, it came from:

We do quite a bit of work to scan the ads we get from our exchanges, but some behave differently for certain users than they do when we do our scanning. In the future, please continue to submit feedback so we can narrow the scans on our end and potentially reproduce and remove this once and for all.

This is noteworthy for a couple of reasons: First, it is quite daring to push your browlock right on Microsoft’s own start page. Second, a large part of the targeted audience for tech support scams are going to be people that use Windows’ default browser and start page. To this day, this campaign is still active on the MSN portal.

This browlock was also found on many other large sites, including several online newspaper portals. For a campaign to run with such a wide distribution and for this length of time is unheard of, at least when it comes to browser lockers.

Cat-and-mouse game

Each victim report we received was more or less the same. A user would open up the MSN homepage or perhaps be browsing a popular tech portal, when all of the sudden their screen would turn red and display a warning message similar to the one shown below:

As we’d go to manually check the page, we would be greeted with a “404 Not Found” error message, as if it were gone. For this reason, we began calling this campaign the “404Browlock.” Attempts to replay the browser locker redirection by visiting the same portals as the victims were also unsuccessful.

Most, if not all, browlock URLs can be revisited without any special user-agent or geo-location tricks. In fact, browlocks themselves aren’t typically sophisticated; their only advantage is they can iterate through hundreds or thousands of different domain names more rapidly than one can blacklist them.

Mapping the browser locker campaign infrastructure

Despite coming up empty each time, we started to build a list of indicators of compromise (IOCs) and did some retro hunting to get a better idea of the scale of this campaign.

Most domain names are registered on the .XYZ TLD (although several other TLDs have and continue to be used) and named using dictionary words grabbed somewhat alphabetically.

2019-12-06,transfiltration[.]xyz,158.69.0[.]190,AS 16276 (OVH SAS)
2019-12-06,transmutational[.]xyz,158.69.0[.]190,AS 16276 (OVH SAS)
2019-12-06,tricotyledonous[.]xyz,158.69.0[.]190,AS 16276 (OVH SAS)
2019-12-06,triethanolamine[.]xyz,158.69.0[.]190,AS 16276 (OVH SAS)
2019-12-06,trigonometrical[.]xyz,158.69.0[.]190,AS 16276 (OVH SAS)
2019-12-06,trithiocarbonic[.]xyz,158.69.0[.]190,AS 16276 (OVH SAS)

The threat actor hosts, on average, six domains on each VPS server, and then rotates to new ones when they are burned. After retro hunting back to June 2019, we collected over 400 unique IP addresses.

Looking at additional data sources, we can see that this browser locker campaign started at least in December 2017. At the time, the infrastructure was located on a different hosting provider and domains used the .WIN TLD.

Even back then, visiting the browlock URL directly (without proper redirection) would also result in a 404 page.

One lone artifact, an audio file (help.mp3), was indexed by VirusTotal and can be played below:

Again based on open source data, we created a rough timeline of the infrastructure the threat actors abused—from where they were first spotted on Petersburg Internet to moving briefly to DigitalOcean before settling on OVH from January 30, 2019 onward.

Steganography to hide redirection mechanism

Given that we couldn’t identify how this browlock was propagating, we figured it must be using an unconventional trick.

Many of the sites that victims reported being on when the browlock happened contained videos, so we thought one likely vector could be video ads. This form of malvertising is more advanced than traditional malicious banners because it enables the crooks to hide their payload within media content.

Once again, we spent a fair amount of time looking at video ads but still couldn’t identify the entry point. We switched our search to another type of medium but evidence was shared with us later on confirming the video ad infection vector.

Coincidentally, we had just been studying some interesting new developments with online credit card skimmers where malicious code was embedded into image files. This technique, known as steganography, is a clever way to hide artifacts from humans and scanners.

While developing tools to identify such rogue images, we came across what we thought might be the smoking gun. We discovered a PNG file that contained obfuscated data.

This time though, if the fraudsters were indeed using steganography, they certainly weren’t making it obvious. We identified a malformed PNG file that contained extra data after its end of file marker and looked suspicious.

Unlike the aforementioned credit card skimmer, which was clearly visible and recognizable with obvious character strings, this one looked like it was encoded. And clearly, the image on its own could not be weaponized without additional code to load with the per-victim unique key to decrypt it.

Anti-bot and traffic filtering

The JavaScript code that interacted with the PNG image used some light hex obfuscation and random variable naming to hide its intentions.

The hex string x57x45x42x47x4c decodes to WEBGL, and by decoding the rest of the obfuscated variable, we can see that this script is using the WEBGL_debug_renderer_info API to gather the victim’s video card properties. This allows the threat actors to sort real browsers (therefore real people) from crawlers or even virtual machines, which would not show the expected hardware information. The Zirconium group’s vast malvertising operation, disclosed in January 2018 by Jerome Dangu over at Confiant, also used that same API to filter traffic.

But perhaps the most interesting function within this JavaScript snippet is the one that processes the actual PNG image behind the steganography. The _Nux function parses the image data by using the @#@ delimeter (as seen in Figure 8 above) and stores it within the _OIEq variable.

If the user is detected as a bot or not interesting traffic, the PNG does not contain the extra data after the IEND end of file marker, and therefore the _OIEq variable will be empty.

The function still attempts to parse the PNG, but it will fail on the eval, and will not generate the browlock URL. The user, not being considered a proper candidate, will not be redirected and won’t even be aware of the fingerprinting that just happened.

This kind of filtering is not usually seen (except for advanced malvertising operations), which is one of the reasons why so many victims have experienced this browlock, yet little is known about it.

Anti-replay mechanism

The next evasion technique is intended for security folks, and those trying to troubleshoot these malicious redirections. A network traffic capture (SAZ, HAR) must include the malicious JavaScript, as well as the steganographic PNG and the browlock itself.

Similar to a technique we’ve previously only observed with exploit kits, the threat actor is using one-time tokens to prevent “artificial” replays of the redirection mechanism. If the proper session key is not provided, the decryption of the PNG data will fail to produce the browlock URL.

Once again, we must pause for a moment and note that this kind of complexity is unheard of for something like a browser locker. While cloaking techniques are common, this is by far the most covert way we’ve seen to redirect to any browlock.

Other traffic chains

After we had discovered the PNG redirection mechanism, we shared our findings with security firm Confiant. They were aware of the domain api.imagecloudsedo[.]com but had seen it in a different campaign. Confiant nicknamed it WOOF due to a string of the same name found in the code.

Additionally, Google, via Confiant’s intermediary, shared yet another instance that explains the number of redirections from newspaper sites we had been seeing. This second instance of the WOOf script was loaded via video widgets.

Digital Media Communications, a company that specializes in ads converted into widgets for the web, was apparently compromised several months ago. According to data collected by the Internet Archive, one of their scripts hosted at widgets.digitalmediacommunications[.]com/chosen/chosen.jquery.min.js was injected on August 13, 2019.

A number of websites, many of them news portals, load this widget and are therefore unwittingly exposing their visitors, as the compromised library subsequently retrieves the malicious PNG from api.imagecloudsedo[.]com before redirecting to the browlock page.

It’s highly likely that there are other compromises of third parties that haven’t been found yet, although we suspect that the methods used would be similar to the ones we know about.

Examining the browser locker page

The following diagram depicts what needs to take place in order for victims to get redirected to the browser locker page after several layers of validation.

Ultimately, the previously analyzed function will arrive at the eval part of the code and return code to launch the browlock.

top.location = '[browlock URL]';

This little bit of code redirects the current browser page to the new URL. It is, in fact, one of the most common techniques for malicious ads to redirect users to scam pages. We believe the threat actor is likely using the same trick for its other malvertising campaigns.

This browser locker is clean and contained as it obfuscates its source code and has few external dependencies, such as libraries. We can see that it uses the evil cursor, which is a flaw that allows criminals to create a fake cursor that tricks users into clicking on the wrong area when they are trying to close a browlock.

While Chrome and Edge users can somewhat get rid of the offending page, on Firefox, this is a true browlock, causing the browser to eventually crash.

The code used to freeze the browser has been duplicated enough times to render the browser useless. In the image below, we see the same function with slightly different parameters.

If we deobfuscate any of the functions, we recognize the history.pushState() method, which we reported back in 2016, and which is still not handled well by most browsers. This bug actually came to Mozilla’s attention three years ago, and more recently when someone reported the same 404Browlock:

Browser lockers can be difficult to fix because they often use code that is otherwise perfectly legitimate. Browser vendors often have to juggle with performance and compatibility issues at the same time.

Handing victims over to tech support scammers

The ultimate goal for browser lockers is to get people to call for assistance to resolve (non-existent) computer problems. This is handled by third parties via fraudulent call centers. The threat actor behind the traffic redirection and browlock will get paid for each successful lead.

To confuse victims, the fake Microsoft agent will tell you to run some commands simply intended to open up a browser window.

From there, they will ask you to download and run a remote assistance program that will enable them to take control of your computer. A few minutes later, they will use their favorite tool, notepad, to start drafting an invoice:

While the machine is still supposedly infected, they will simply browse to a site to take the payment for 1 year, 3 year, or 5 year plans costing $195, $245, and $345, respectively.

Where do we go from here?

Given the level of sophistication involved in this campaign, we can expect that the threat actor has diversified their traffic to have some kind of redundancy.

We hope that our efforts to expose this scheme will help others to identify the browlock redirections within their networks. Despite our repeated attempts to report these abuses, they have not been fixed. We remain available to OVH for closer collaboration to shut down this campaign.

For best protection against this and other browlocks, we recommend using our free browser extension, Browser Guard. Not only does it benefit from our domain and IP blacklist, but it can also detect and block browlocks and other tech support scams via signatureless techniques.

Acknowledgements

We would like to thank Confiant for sharing additional data regarding the other cases of the malicious script (_WOOf variant).

Thanks to @prsecurity_ for pointing out a quicker way to retrieve the browlock URL by RC4 decrypting the PNG data using the unique key found within the script.

Indicators of Compromise (IOCs)

There are simply too many IOCs to put here, so we’ve uploaded the browlock domains and IP addresses as a STIX2 file onto our GitHub page. It includes data going back to June 2019 based on indicators we collected by conducting retro hunting. Please note that this is only a partial account of this campaign based on the data we could collect.

Compromised library

widgets.digitalmediacommunications[.]com/chosen/chosen.jquery.min.js

Steganographic redirector

api.imagecloudsedo[.]com
141.98.81[.]198

Regex to identify the browlock URLs

/en/?search=w?(%[w_-~.]{1,4}){10,20}&list=([0-9]00000|null)$

The post WOOF locker: Unmasking the browser locker behind a stealthy tech support scam operation appeared first on Malwarebytes Labs.

Last week on Malwarebytes Labs, we taught you how to prevent a rootkit attack, explained what data enrichment means, informed you about new rules on deepfakes in the US, and demonstrated how backdoors in elastic servers expose private data.

Other cybersecurity news

• An online group of cybersecurity analysts calling themselves Intrusion Truth have revealed information about their fourth Chinese state-sponsored hacking operation. (Source: ZDNet)
• Travelex warned customers of a phone scam threat in wake of their ransomware attack. (Source: Graham Cluley)
• The federal government is preparing for another fight with Apple in an ongoing battle for access to encrypted iPhones. (Source: Vox recode)
• Proof-of-concept exploit code has been published for critical flaws impacting the Cisco Data Center Network Manager (DCNM) tool for managing network platforms and switches. (Source: ThreatPost)
• The Dutch National Cybersecurity Centre (NCSC) says that companies should consider turning off Citrix ADC and Gateway servers if the impact is acceptable. (Source: BleepingComputer)
• Hackers stole personal information from 100,000 West Australians in a cyberattack on P&N Bank. (The West Australian)
• In an important Patch Tuesday release, Microsoft fixed critical bugs in CryptoAPI, RD Gateway, and .NET. (Source: Naked Security)
• The latest update to Google’s Smart Lock app on iOS means you can now use your iPhone as a physical 2FA security key for logging into Google’s first-party services in Chrome. (Source: The Verge)
• The domain name weleakinfo.com has been seized by the FBI. The website sold information claiming to have more than 12 billion records gathered from over 10,000 breaches. (Source: DarkReading)
• Pretending to be the Permanent Mission of Norway, Emotet operators performed a targeted phishing attack against users associated with the United Nations. (Source: BleepingComputer)

Stay safe, everyone!

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

It seems like every day we read another article about a data breach or leak of cloud storage exposing millions of users’ data.

The unfortunate truth is that the majority of these leaks require no actual “hacking” on the part of the attacker. Most of the time, this highly confidential data is just sitting in open databases, ripe for the picking.
It’s all too easy to discover data leaks online, especially in cloud services, which says a lot about the state of security and preparedness for cyberattacks—we have a long way to go.

Continuing my series on insecure cloud infrastructure, where I previously covered AWS and PACS, I will be going into some detail on elastic servers. Specifically, I will cover a number of cases in which I discovered a common misconfiguration, leading to open backdoors, which expose many records of personal data.

---

Exposed databases using search

Before I go into detail on the accidental backdoors found in elastic servers, let’s take a look at just how easy it is to find one of these exposed databases online.

While there are dozens of tools and methods for this discovery phase, for the purposes of this demonstration, I used shodan, a search engine that crawls the web for Internet-connected devices.

Let’s do a quick experiment and see if it yields results. With a quick Google search on elastic databases, we learn that elastic databases by default listen on port 9200.

From there, we open up shodan and search:
elastic port:9200

This will basically bring up IPs who have a service responding on port 9200 and whose content contains the word “elastic.” Ninety-nine percent of the time, this will bring up an elastic search server.

For the sake of full comprehension, I will give a 10-second primer on how to use the elastic search API.

Elastic can be compared to MYSQL in the following way:

MYSQL	ELASTIC
Databases	Indices
Tables	Types
Records – column and row	Document with properties

Here are a few key commands to help you navigate any elastic instance. The first is the /_cat command and the second is the /_search?pretty=true.
The cat command simply lists information, and it is a good starting point to understand what indices or fields you have to work with.

Elastic servers

Jumping into shodan, we start our search for elastic databases.

Let’s choose the a random IP that comes up from the shodan query. In this case, it is a server residing in China: https://www.shodan.io/host/47.104.101.159#9200

We can check if it is open to the world by typing in: http://47.104.101.159:9200/_cat/

This brings up the following results:

Seems like no authentication so far. Let’s look at what indices exist here by typing in /_cat/indices, which gives us the following results:

So far so good. It is clear that at the moment we will not likely be facing any authentication stopping us from accessing the data. Now we can list the contents of one of these indices, similar to a Select * from TABLE_NAME in sql. Lets choose one at random, kms_news, which looks to have 37 records inside.

We type http://47.104.101.159:9200/dzkj_news/_search?pretty=true
and voila! All the data spits out for us with hardly any effort at all.

As you can see, it was quite easy to find exposed data in a random elastic server online. In less than a minute, we found an exposed server and could continue to dump all the data. I am certain that if we spent a bit more time, we would find a database with a more critical leak.

There is a reason, after all, that these databases have received so much press for their infamous leaks.

---

The backdoor

Now lets get to the topic at hand… the misconfigurations leading to the backdoor.

Along with elastic, you often hear the word Kibana. This is basically the GUI front end to an elastic database, allowing you to browse/search data and configure the structure and details of the elastic instance.

As such, it is common for companies to have an internal elastic DB on premise and expose the Kibana front end so that employees may access the data from their web browser, fully authenticated. In this case, the Kibana server could listen on port 5601, open to the Internet, and will access the data from an internal elastic DB behind the company’s local intranet.

So where does the backdoor lie? Well, after having done an exhaustive search of various Kibana servers online, I noticed something funny happening on a large number of results.

I would browse to the Kibana instance and receive the login screen as expected, but after doing a port scan using nmap on the same IP, I noticed a familiar port being opened:

The infamous 9200!

To be specific, I found more than 20 servers within a span of five minutes with this same misconfiguration. What’s going on here is that an admin set up elastic search and decided to allow access through the Kibana front end, restricted by proper authentication. The problem, however, is that the actual data store on port 9200 isn’t just communicating internally. It, too, is exposed to the Internet, allowing backdoor access to the data directly from elastic queries carried out by anyone who wants to look, just as we did in the example above.

Here is an illustration showing the misconfiguration, which should make it all the more clear.

Finding a port 9200 exposed to the public does not mean there will be something of value inside. However, the combination of these two ports being exposed and restricting access only on Kibana almost guarantees that there is data here the company wanted to keep private.

Elastic ready to snap

Elastic is likely the number one source of leaked data online, and after conducting this research, I would attribute that to how easy it is to misconfigure. The focus, of course, being on the relationship between the internal server on 9200 and the public-facing component on 5601.

The purpose of this article was not to talk about a specific company or to put anyone on blast for exposing public data. Rather, I am hoping to explain just how many servers are sitting on the Internet with this backdoor. There are thousands of elastic servers open to the public and exposing data—this is nothing new. What makes these specific cases unique is that there were clearly attempts to incorporate some type of security, however, the platform is clearly being misunderstood.

Because elastic search is such a commonly used cloud database, it’s important to highlight this specific misconfiguration because it can easily be fixed.

Finding the exposed data was neither the result of a 1337 hack, nor a difficult side channel to discover. Hopefully this may help admins using elastic to better understand the danger of defaults, and for security analysts, this hopefully provided some useful information on researching new cloud infrastructures.

Stay tuned for the next article in this series where I will be covering the details of various leaks found on elastic.

The post Business in the front, party in the back: backdoors in elastic servers expose private data appeared first on Malwarebytes Labs.