VMRay announces the closing of a Series B led by global alternative asset manager Tikehau Capital, which will fuel further expansion of the product portfolio to target a broader set of market segments.

**BOCHUM, GERMANY (PRWEB)** **DECEMBER 20, 2022 --** VMRay, a global player in advanced threat detection and analysis that offers solutions for enterprises, governmental organizations, and MDRs to detect and analyze the most challenging malware and phishing threats, announces the closing of a Series B led by global alternative asset manager Tikehau Capital, through its subsidiary Tikehau Ace Capital and its European Cybersecurity Growth fund alongside new investors NRW.BANK and Gründerfonds Ruhr. Previous investors eCAPITAL and High-Tech Gründerfonds also participated in the round. The new investment will fuel further expansion of the product portfolio to target a broader set of market segments.

VMRay was founded to overcome a big vulnerability in cybersecurity: new, unknown, and sophisticated threats and targeted attacks. The company started its journey by developing a unique, hypervisor-based approach to sandboxing, and kept adding cutting-edge technologies, including its own Machine Learning models, to address emerging and evolving challenges. The solutions aim at improving the efficiency of SOC teams with accurate verdicts, noise-free output, and seamless integrations with major EDR, XDR, SOAR, and Threat Intelligence Platform vendors. The company is now working with 4 of the world’s top 5 technology companies, 37 leading financial institutions and 56 governmental organizations around the world.

“The cyber threat landscape is going through a profound change, and with the increasing volume and complexity of new threats, our customers face new challenges,” said Dr. Carsten Willems, co-founder and CEO of VMRay. “The latest investment has been a collaboration with a strategic scope, enabling VMRay to make its product suitable for a wider range of market segments and use cases including threat intelligence, security automation and MSSPs.” 

“In our role as cybersecurity-focused experts, we were impressed with VMRay's unique value proposition: building more effective detection tools integrated or interfaced with larger cybersecurity solutions. VMRay's ability to automate detection is a clear differentiator, positioning it as the tip of the spear in the global effort to elevate cybersecurity standards globally," said Augustin Blanchard, Executive Director at Tikehau Capital. "We firmly believe the company will sustain scalable, explosive growth in the coming years, driven by skilled leadership and powerful market tailwinds.”

“VMRay has managed to uniquely position themselves in the market, complementing existing solutions as the extra layer of security that is needed to combat advanced and unknown threats,” said Dr. Ulrich Schmitt from High-Tech Gründerfonds. “Having built a strong foundation for further international growth, the company is set to become the global leader in advanced threat detection, and we are excited to support the VMRay team in the years to come.”

Willi Mannheims, Managing Partner at eCAPITAL added, “We’re delighted to be partnering with a syndicate of top investors to continue fueling VMRay’s success and support the company’s experienced management team in driving growth.”

About VMRay  
At VMRay, our purpose is to liberate the world from undetectable digital threats.Led by reputable cyber security pioneers, we develop best-of-breed technologies to detect and analyze unknown threats that others miss. Thus, we empower organizations to augment and automate security operations by providing the world’s best threat detection and analysis platform. We help organizations build and grow their products, services, operations, and relationships on secure ground that allows them to focus on what matters with ultimate peace of mind. This, for us, is the foundation stone of digital transformation.

Cybersecurity Company VMRay Extends Series B Investment to a Total of $34M USD to Drive Growth into New Markets

The technique loads a nonmonitored and unhooked DLL, and leverages debug techniques that could allow for running arbitrary code.

A newly pioneered technique could render endpoint detection and response (EDR) platforms "blind" by unhooking the user-facing mode of the Windows kernel (NTDLL) from hardware breakpoints. This potentially gives malicious actors the ability to execute any function from within NTDLL and deliver it, without the EDR knowing it, researchers warned.

The Cymulate Offensive Research Group, which discovered what it calls the "Blindside" technique, noted in a report released Dec. 19 that the injected commands could be used to perform any number of unexpected, unwanted, or malicious operations on a target system.

Blindside creates an unhooked process. This means the hooks (which allow one application to monitor another) used by EDR platforms to identify if behaviors are malicious will not be present in the unhooked process.

Because many EDR solutions rely entirely or heavily on hooks to track behaviors and malicious activities, they would be unable to track the behaviors of the process launched with Blindside, the researchers explained.

Mike DeNapoli, director of technical messaging at Cymulate, notes that there are other methods to block hooks, but they depend heavily on cooperation from the operating system. Not so with Blindside.

"Blindside leverages hardware operations and can work in circumstances where other methods fail," he explains.

DeNapoli also points out that the use of hardware breakpoints for malicious outcomes is not entirely new, explaining that researchers knew various forms of breakpoints can be used to obfuscate against detection within x86 architectures. However, Blindside has a slightly different approach.

"Previous threat methodologies and techniques have focused on the virtualization of a process, or the use of syscalls to accomplish their goal," he says. "Blindside adds the use of specific debugging breakpoints to force a process to launch without hooks, which is what makes it a new technique."

**Discovering New Techniques Improves Protection**

DeNapoli says discovering new attack vectors allows EDR vendors and their customers to stay ahead of the game on defense.

"When investigating techniques, the Cymulate Offensive Research Team will sometimes discover ideas that could be used to create new techniques," he explains, adding that the justification for going public with the results is bringing greater awareness of these potential attack techniques and methods to EDR vendors and the public — before they are discovered by threat actors and used for malicious purposes.

"EDR solutions use multiple methodologies to monitor applications and processes for circumstances where they perform malicious actions," DeNapoli says. "This idea of behavior-based detection has become the primary and most popular method of anti-malware operations. This makes bypass and compromise of this form of anti-malware operation a major concern of organizations and service providers alike."

John Bambenek, principal threat hunter at Netenrich, agrees that the good news is that this tactic was discovered in advance of an attack and shared with the broader community.

"That way, they can develop mitigations, some of which were in the research itself," he says. "This research identifies the problem and a path forward."

He adds that attackers are constantly developing techniques and looking for holes to bypass our security tools. Earlier this month, vulnerabilities were found in EDR tools from different vendors — among them Microsoft, Trend Micro, and Avast — that give attackers a way to manipulate the products into erasing virtually any data on installed systems.

And another threat group was recently observed using the Microsoft-signed drivers as part of a toolkit designed to terminate antivirus and EDR processes.

"Either we find them first and develop mitigations or we want for the attackers to find them and deal with breaches," Bambenek says.

**Updating Defense Postures**

DeNapoli explains that next-gen EDR platforms will likely evolve away from relying so much on the hooking process.

"Several EDR vendors that Cymulate tested the technique against had already begun to use more than just hooking methods to track behaviors, and more are sure to do so as additional techniques to avoid hooking are brought to the public light," he says.

Working with an organization’s EDR vendor and/or service provider and keeping the system and the configuration of the tools within their infrastructure updated and validated as per vendor/provider recommendations, is a critical step in staying ahead of threat actors, DeNapoli adds.

"Because EDR solutions are only one layer of defenses, and because modern cybersecurity solutions can be complex, it is vital that organizations also regularly validate their security controls," he says.

Bambenek cautions that many organizations believe their job is done when they get EDR deployed everywhere and, while important, it is only one piece of the puzzle.

"Security, unfortunately, will require constant investment, because the attackers are certainly investing in their own R&D," he explains. "Primarily, the work here is on EDR vendors to look at other means to detect the use of these techniques."

'Blindside' Attack Subverts EDR Platforms From Windows Kernel

Asset inventory, behavioral baselining, and automated response are all key to keeping patients healthy and safe.

According to a 2020 memo from the Commonwealth of Massachusetts Department of Public Health, a code black event is "defined as when a hospital's Emergency Department is closed, as declared by an authorized hospital administrator, to all patients (ambulance and walk-in patients) due to an internal emergency."

The memo goes on to list a number of situations constituting internal emergencies, including:

*   Fires
*   Explosions
*   Hazardous material spills or releases
*   Other environmental contamination
*   Flooding
*   Power or other utility failures
*   Bomb threats
*   Violent or hostile actions impacting the Emergency Department

**Code Black/Code Dark**

On April 20, 2022, the Bay State added another item to that list, when code black events were declared at hospitals in Worcester and Framingham, following cyberattacks on Tenet Healthcare Corporation facilities there and in Florida. According to HealthcareITNews, "Tenet immediately suspended user access to impacted IT applications, executed extensive cybersecurity protection protocols and took steps to restrict further unauthorized activity." HealthITSecurity later reported that the attack campaign included a ransomware infection that ultimately cost Tenet $100 million in lost revenue during the second quarter. 

Now, cyberattacks have their own emergency response designation, called "code dark." A recent Wall Street Journal article described code dark procedures at Washington, DC's Children's National Hospital, during which, while IT staff respond to the event, hospital employees are trained to turn off Internet-connected medical equipment to keep an attack from spreading. Under such conditions, the hospital's CISO said, "If we call a code dark, the entire hospital knows to disconnect devices anywhere they can." 

**Patient Safety at Risk**

That's not especially comforting, given healthcare providers' reliance on medical devices. Hospitals are prime targets for threat actors, and especially for ransomware gangs. They know healthcare providers are under great pressure to maintain continuity of operations and to protect patient safety, and so are most likely to pay the cost to unlock medical systems, devices, and data, rather than risk an unfortunate outcome. A new study by the Ponemon Institute underscores this risk, finding that hospitals falling victim to a ransomware attack experience a decline in care quality and outcomes, including longer patient stays, test and procedure delays, and even more complications following care. 

Healthcare organizations invest aggressively in connected devices to improve facilities management and administration, and to provide a higher quality of patient care. Those devices include the Internet of Things (IoT), the Internet of Medical Things (IoMT), and operational technologies (OT). A recent study by Juniper Research forecasts that the average hospital will have as many as 3,850 IoMT devices connected to their networks by 2026. Every device that connects increases the complexity of a hospital's IT estate and its attack surface.

**Zero Trust for Connected Devices Starts With Asset Inventory and Baselining**

The proliferation of these devices in a hospital's IT infrastructure requires meticulous attention be paid to the risk each connected device adds to the network. Without the means to discover, monitor, and manage every connected device, the security of an organization's devices, data, and even patients themselves could be compromised. That makes it imperative to translate the elements of zero trust (never trust, always verify, and least privilege access) and apply them to a connected device security strategy.  

The first step in doing that requires knowing your attack surface. The adage "You can't protect what you can't see" holds true here, making complete device discovery and classification essential and foundational to protecting healthcare environments. This can range from traditional IT devices and medical devices that cannot be discovered via traditional means to elevator and HVAC control systems that are core to hospital operations. The approach needs to be "passive" so it doesn't impact device function.  

The next step is mapping transactions. With connected devices, this starts by using machine learning to establish and understand a baseline of how each device should behave. Since most IoT, IoMT, and OT devices operate within deterministic parameters, having an accurate understanding of normal, safe behavior makes it easier to recognize anomalous behaviors that represent early indicators of compromise. And when you can accurately detect an attack or risky behavior, you can automate policy enforcement that isolates compromised or at-risk devices. 

**Automate Response and Policies With Machine Efficiency**

That granular device profile — what a device is, how it's communicating, where it's connected, and its normal patterns of behavior — contains the elements you need to architect your zero\-trust policies and response — both reactive and proactive. The device context allows you to quickly respond to an attack and minimize and contain the blast radius. It also allows you to maintain operational continuity by keeping gear in service rather than shutting things down that might not need to be taken offline, or that could put patient care at risk if disconnected.  

For example, rather than taking a connected medical device offline if it is being used by a patient, dynamically generate zero\-trust segmentation policies that can quickly isolate the device on the network and allow its "sanctioned" behavior to continue. In contrast, a compromised surveillance camera communicating to a malicious domain can be blocked and taken off the network immediately, without risking an adverse medical outcome. 

**Enlightened, Not Dark**

A code dark protocol that asks doctors, nurses, and medical support staff to disconnect devices is one way to deal with a cyberattack, but it's not the best way. Instead, use an enlightened approach that applies a zero\-trust strategy to protecting connected devices. By starting with an asset inventory of devices in the network, baselining of device behavior, and leveraging automation to respond to threats and quickly stop lateral movement, you can maintain a higher security profile without compromising healthcare quality. When that is the model, network and patient safety can be maintained at a high level, even in the middle of a cyberattack, without pulling the plug.

Protecting Hospital Networks From 'Code Dark' Scenarios

Threat actors can take over victims' cloud accounts to steal data, or use them for command-and-control for phishing attacks, denial of service, or other cyberattacks.

Attackers can compromise a new feature in Amazon Web Services (AWS) to hijack cloud accounts' static public IP addresses and abuse them for various malicious purposes, researchers have found.

Threat actors can use the Amazon Virtual Private Cloud (VPC) Elastic IP (EIP) transfer feature to steal someone else's EIP and use it as their own command-and-control (C2), or to launch phishing campaigns that impersonate the victim, researchers from cloud incident response firm Mitiga revealed in a blog post on Dec. 20.

Attackers also can use the stolen EIP to attack a victim's own firewall-protected endpoints, or to serve as the original victim’s network endpoint to extend opportunities for data theft, the researchers said.

"The potential damage to the victim by hijacking an EIP and using it for malicious purposes can mean using the victim’s name, jeopardizing the victim’s other resources in other cloud providers/on-premises, and \[stealing the\] victim’s customers' information," Or Aspir, software engineer at Mitiga, wrote in the post.

Threat actors must already have permissions on an organization's AWS account to leverage the new attack vector, which the researchers call "a post-initial-compromise attack."

However, because the attack was not possible before the feature was added and is not yet listed in the MITRE ATT&CK Framework, organizations may be unaware that they are vulnerable to it, as it's not likely to be picked up by existing security protections, the researchers said.

"With the right permissions on the victim’s AWS account, a malicious actor using a single API call can transfer the victim’s used EIP to their own AWS account, thus practically gaining control over it," Aspir wrote. "In many cases it allows greatly increasing the impact of the attack and gaining access to even more assets."

**How Elastic IP Transfer Works**

AWS introduced EIP in October as a legitimate feature to allow transfer of Elastic IP addresses from one AWS account to another. An Elastic IP (EIP) address is a public and static IPv4 address that can be reached from the Internet and can be allocated to an Elastic Compute Cloud (EC2) instance for Web-facing activities, such as website hosting or communicating with network endpoints under a firewall.

AWS introduced the feature to make it easier to move Elastic IP addresses during AWS account restructuring by transferring the EIP to any AWS account — even AWS accounts that are not owned by someone or his or her organization, the researchers said.

With the feature, the transfer is a mere "two-step handshake between AWS accounts — the source account (either a standard AWS account or an AWS Organizations account) and the transfer account," Aspir explained.

**Abuse of Elastic IP Transfer**

The ease with which EIPs can now be transferred creates an unintentional issue, however — while it certainly facilitates the process of transferring IP for legitimate account owners, it also makes it easier for malicious actors as well, the researchers said.

Researchers described a basic scenario to illustrate how attackers can take advantage of EIP transfer, assuming that attackers already have permissions that allow them to "see" existing EIPs and their status, or whether or not they are associated with other computer resources.

Typically, EIPs are associated, but sometimes an organization keeps dissociated EIP for later use, or as a result of an unmanaged environment that keeps unused resources, the researchers said. "Either way, the attacker only needs to enable the EIP transfer, and the IP address is theirs," Aspir wrote.

Attackers can do this in two ways with the correct permissions: either transfer a dissociated EIP or remove the association of an associated EIP and then transfer it, the researchers said.

For the former, an adversary must have the following action in its attached Identity and Access Management (IAM) policy on AWS: "ec2:DisassociateAddress" action on the elastic IP addresses and the network interfaces that the IP addresses are attached to.

To transfer an EIP, a threat actor must have the following actions in its attached IAM policy: "ec2:DescribeAddresses" on all the IP addresses and "ec2:EnableAddressTransfer" on the EIP address that the attacker wants to transfer, the researchers said.

**Leveraging a Stolen EIP**

There are a wide range of attack scenarios that a threat actor can engage in after successfully transferring someone else's EIP to their own control.

In external firewalls used by the victim, for example, an attacker can communicate with the network endpoints behind the firewalls if there is an allow rule on the specific IP address, the researchers said.

Moreover, in cases in which a victim uses DNS providers such as a Route53 service, there could be DNS records of an "A" type in which the target is the transferred IP address. In this case, an attacker can abuse the address for hosting a malicious Web server under a legitimate victim’s domain, then launch other malicious actions, such as phishing attacks, the researchers said.

Attackers also can use the stolen IP address as C2, using it for malware campaigns that appear legitimate and thus fly under the radar of security defensives. A threat actor can even cause denial of service (DoS) to a victim's public services if they dissociate an EIP from a running endpoint and transfer it, the researchers said.

**Who's at Risk and How to Mitigate It**

Anyone using EIP resources in an AWS account is at risk, and thus must treat the EIP resources like other resources in AWS that are in danger of exfiltration, the researchers advised.

To protect themselves from an EIP transfer attack, Mitiga recommends that enterprises use the principle of least privilege on AWS accounts and even disable the ability to transfer EIP entirely if it's not a necessary feature on their environment.

To do this, an organization can use native AWS IAM features such as service control policies (SCPs), which offer central control over the maximum available permissions for all accounts in an organization, the researchers said, providing an example in their post of how this works.

AWS Elastic IP Transfer Feature Gives Cyberattackers Free Range

Large vendors are commoditizing capabilities that claim to provide absolute security guarantees backed up by formal verification. How significant are these promises?

There is no software without bugs, right? While this is a common sentiment, we make assumptions that rely on the premise that software has no bugs in our day-to-day digital life. We trust identity providers (IDPs) to get authentication right, operating systems to perfectly comply with their specs, and financial transactions to always perform as intended. Even more vividly, we trust software with our physical safety by going on planes, driving a car that actively corrects our adherence to traffic lanes or our distance from the car in front of us, or undergoing certain surgeries. What makes this possible? Or to put it another way, why aren't planes falling out of the sky due to bad software?

Software quality assurance borrows from scientific and engineering tools. One way to ensure and improve software quality is to publicize it and give as many people as possible an incentive to try to break it.

Another is using design patterns or well-architecture frameworks rooted in engineering. For example, while not every software project can be put under the same level of scrutiny as the Linux kernel, which has been under scrutiny for decades, software projects can open source code to invite scrutiny or submit code for audits in hopes to gain some of the security guarantees.

And of course, there's testing. Whether static, dynamic, or real-time, done by the developer or by a dedicated team, testing is a major part of software development. With critical software, testing is usually an entirely separate project handled by a separate team with specific expertise.

Testing is good, but it doesn't claim to be comprehensive. There are no guarantees we found all the bugs because we don't know which bugs we don't know about. Did we already find 99% of Linux kernel bugs out there? 50%? 10%?

**The 'Absolute' Claim**

The research field of formal methods is looking at ways to assure you that there are no bugs in a certain piece of software, such as your stockbroker or certificate authority. The basic idea is to translate software into math, where everything is well-defined, and then create an actual proof that the software works with no bugs. That way, you can be sure that your software is bug-free in the same way you can be sure that every number can be decomposed to a multiplication of prime numbers. (Note that I don't define what a bug is. This will prove to be a problem, as we will later see.)

Formal method techniques have long been used for critical software, but they were extremely compute- and effort-intensive and so applied only to small pieces of software, such as a limited part of chip firmware or an authentication protocol. In recent years, advanced theorem provers like Z3 and Coq have made it possible to apply this technology in a larger context. There are now formally verified programming languages, operating systems, and compilers that are 100% guaranteed to work according to their specifications. Applying these technologies still requires both advanced expertise and a ton of computing power, which make them prohibitively expensive to most organizations.

Major cloud providers are performing formal verification of their fundamental stacks to reach high levels of security assurance. Amazon and Microsoft have dedicated research groups that work with engineering teams to incorporate formal verification methods into critical infrastructure, such as storage or networking. Examples include AWS S3 and EBS and Azure Blockchain. But the really interesting fact is that in the past few years, cloud providers have been trying to commoditize formal verification to sell to their customers.

**Decisively Solving Misconfiguration?**

Last year, AWS released two features that leverage formal verification to address issues that have long plagued their customers, namely network and identity and access management (IAM) misconfigurations. Network access and IAM configurations are complex, even for a single account, and that complexity grows drastically in a large organization with distributed decision-making and governance. AWS addresses it by giving its customers simple controls — such as "S3 buckets should not be exposed to the Internet" or "Internet traffic to EC2 instances must go through a firewall" — and guaranteeing to apply them in every possible configuration scenario.

AWS is not the first to address the misconfiguration problem, even for AWS-specific issues such as open S3 buckets. Cloud security posture management (CSPM) vendors have been addressing this issue for a while now, analyzing virtual port channel (VPC) configuration and IAM roles and identifying cases where privileges are too lax, security features are not properly used, and data can be exposed to the Internet. So what's new?

Well, this is where the absolute guarantee comes in. A CSPM solution works by creating a known-bad or known-good list of misconfigurations, sometimes adding context from your environment, and producing results accordingly. Network and IAM analyzers work by examining every potential IAM or network request and guaranteeing that they will not result in unwanted access according to your specification (such as "no Internet access"). The difference is in the guarantees about false negatives.

While AWS claims that there is no way it has missed anything, CSPM vendors say they are always on the lookout for new misconfigurations to catalog and detect, which is an admission that they did not detect these misconfigurations previously.

**Some Flaws of Formal Verification**

Formal verification is great for finding well-defined issues, such as memory security issues. However, things become difficult when trying to find logical bugs because those require specifying what the code is actually supposed to do, which is exactly what the code itself does.

For one thing, formal verification requires specifying well-defined goals. While some goals, like preventing access to the Internet, seem simple enough, in reality they are not. The AWS IAM analyzer documentation has an entire section defining what "public" means, and it's full of caveats. The guarantees it provides are only as good as the mathematical claims that it has coded.

There's also the question of coverage. AWS analyzers cover only a few major AWS services. If you route traffic into your network through an outbound connection channel, the analyzer wouldn't know. If some service has access to two IAM roles and can combine them to read from a confidential public bucket and write to a public one, the analyzer wouldn't know. Nevertheless, on some well-defined subset of the misconfiguration problem, formal verification provides stronger guarantees than ever before.

Getting back to the relative advantage question posed above, the difference is that the IAM and network analyzer claims that its list of issues detected is comprehensive, while CSPM claims that its list covers every misconfiguration known today. Here's the key question: Should you care?

**Should We Care About Absolute Guarantees?**

Consider the following scenario. You own a CSPM and look at the AWS network and IAM analyzer. Comparing the results of the two, you realize that they've identified the exact same problems. After some effort, you fix every single problem on that list. Relying only on your CSPM, you would feel you are in a good place now and could dedicate security resources elsewhere. By adding AWS analyzers to the mix, you now know — with an AWS guarantee — that you are in a good place. Are these the same results?

Even if we neglect the caveat of formal verification and assume that it catches 100% of issues, measuring the benefits over detection-based services like CSPM would be an exercise for every individual organization with its own security risk appetite. Some would find these absolute guarantees groundbreaking, while others would probably stick to existing controls.

These questions are not unique to CSPM. The same comparisons could be made for SAST/DAST/IAST web application security testing tools and formally verified software, to name one example.

Regardless of individual organization choices, one exciting side effect of this new technology would be an independent way to start measuring security solutions' false negative rates, pushing vendors to be better and providing them with clear evidence where they need to improve. This in and of itself is a tremendous contribution to the cybersecurity industry.

Are 100% Security Guarantees Possible?

Sites spoofing Grammarly and a Cisco webpage are spreading the DarkTortilla threat, which is filled with follow-on malware attacks.

Researchers have spotted two phishing sites — one spoofing a Cisco webpage and the other masquerading as a Grammarly site — that threat actors are using to distribute a particularly pernicious piece of malware known as "DarkTortilla."

The .NET-based malware can be configured to deliver various payloads and is known for functions that make it extremely stealthy and persistent on the systems it compromises.

Multiple threat groups have been using DarkTortilla since at least 2015 to drop information stealers and remote access Trojans, such as AgentTesla, AsyncRAT and NanoCore. Some ransomware groups too — such as the operators of Babuk — have used DarkTortilla as part of their payload delivery chain. In many of these campaigns, attackers have primarily used malicious file attachments (.zip, .img, .iso) in spam emails to wrap up unsuspecting users in the malware.

**DarkTortilla Delivery Via Phishing Sites**

Recently, researchers at Cyble Research and Intelligence Labs identified a malicious campaign where threat actors are using two phishing sites, masquerading as legitimate sites, to distribute the malware. Cyble surmised that the operators of the campaign are likely using spam email or online ads to distribute links to the two sites.

Users who follow the link to the spoofed Grammarly website end up downloading a malicious file named "GnammanlyInstaller.zip" when they click on the "Get Grammarly" button. The .zip file contains a malicious installer disguised as a Grammarly executable that drops a second, encrypted 32-bit .NET executable. That in turn downloads an encrypted DLL file from an attacker-controlled remote server. The .NET executable decrypts the encrypted DLL file and loads it into the compromised system's memory, where it executes a variety of malicious activities, Cyble said.

The Cisco phishing site meanwhile looks like a download page for Cisco's Secure Client VPN technology. But when a user clicks on the button to "order" the product, they end up downloading a malicious VC++ file from a remote attacker-controlled server instead. The malware triggers a series of actions that end with DarkTortilla installed on the compromised system.

Cyble's analysis of the payload showed the malware packing functions for persistence, process injection, doing antivirus and virtual machine/sandbox checks, displaying fake messages, and communicating with its command-and-control (C2) server and downloading additional payloads from it.

Cyble's researchers found that to ensure persistence on an infected system for instance, DarkTortilla drops a copy of itself into the system's Startup folder and creates Run/Winlogin registry entries. As an additional persistence mechanism, DarkTortilla also creates a new folder named "system\_update.exe" on the infected system and copies itself into the folder.

**Sophisticated & Dangerous Malware**

DarkTortilla's fake message functionality meanwhile basically serves up messages to trick victims into believing the Grammarly or Cisco application they wanted failed to execute because certain dependent application components were not available on their system.

"The DarkTortilla malware is highly sophisticated .NET-based malware that targets users in the wild," Cyble researchers said in a Monday advisory. "The files downloaded from the phishing sites exhibit different infection techniques, indicating that the \[threat actors\] have a sophisticated platform capable of customizing and compiling the binary using various options."

DarkTortilla, as mentioned, often acts as a first-stage loader for additional malware. Researchers from Secureworks' Counter Threat Unit earlier this year identified threat actors using DarkTortilla to mass distribute a wide range of malware including, Remcos, BitRat, WarzoneRat, Snake Keylogger, LokiBot, QuasarRat, NetWire, and DCRat.

They also identified some adversaries using the malware in targeted attacks to deliver Cobalt Strike and Metasploit post-compromise attack kits. At the time, Secureworks said it had counted at least 10,000 unique DarkTortilla samples since it first spotted a threat actor using the malware in an attack targeting a critical Microsoft Exchange remote code execution vulnerability (CVE-2021-34473) last year.

Secureworks assessed DarkTortilla as being very dangerous because of its high degree of configurability and its use of open source tools like CofuserEX and DeepSea to obfuscate its code. The fact that DarkTortilla's main payload is executed entirely in memory is another feature that makes the malware dangerous and difficult to spot, Secureworks noted at the time.

Sophisticated DarkTortilla Malware Serves Imposter Cisco, Grammarly Pages

A mobile phone store owner stole T-Mobile employee credentials to "unlock" phones for resale, earning him millions in illicit profits.

Phishing emails and social engineering scams were all it took for mobile phone store owner Argishti Khudaverdyan to breach the mobile provisioning systems of T-Mobile, AT&T, and Sprint to "unlock" phones from their network constraints — earning him more than $25 million in the process.

Now Khudaverdyan has been convicted and sentenced to 10 years in federal prison for wire fraud, money laundering, and identity theft, among other counts.

In all, Khudaverdyan stole the credentials of more than 50 T-Mobile employees across the US, allowing him to unblock hundreds of thousands of phones, according to the Department of Justice.

"From August 2014 to June 2019, Khudaverdyan fraudulently unlocked and unblocked cellphones on T-Mobile's network, as well as the networks of Sprint, AT&T, and other carriers," the DOJ explained. "Removing the unlock allowed the phones to be sold on the black market and enabled T-Mobile customers to stop using T-Mobile’s services and thereby deprive T-Mobile of revenue generated from customers’ service contracts and equipment installment plans."

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

T-Mobile Carrier Scammer Gets Decade in the Slammer

Bright Data CEO Or Lenchner discusses how security teams are utilizing public Web data networks to safeguard their organizations from digital risks.

Threat intelligence plays a key role in the safety and security of any organization’s online activity, and it plays a determining factor in upholding the integrity of their internal infrastructure.

But to be able to assess possible threats across the cybersecurity landscape at scale, they need data — and more importantly, public Web data.

This is because Web data helps security operators better understand the vulnerabilities that may be present within their systems, threats that could originate within the networks of outside organizations as well as potential risks that could target their organization across the World Wide Web.

**Public Web Data in Security Research, Intelligence, and Testing**

In practice, this collection of public Web data is used to automate checks that can discover the presence of possible malware, phishing links, different forms of fraud, information leaks, and counterfeiting schemes.

Essentially, it provides security operators with the visibility they need to proficiently detect, address, and prevent real live threats or intrusions from affecting their organizational security, by mapping out the potential security gaps that could target various Web-based systems.

**Web Data Collection Networks**

To obtain this increased visibility, security firms and operators use public Web data collection networks to gather large amounts of information, or Web data, which they then use to identify, monitor, and assess threats in real-time.

The Web data collection networks (IP proxy networks included) provide a risk-free environment to discover how to prevent digital risks from reaching their organization, without sacrificing the integrity of their internal infrastructure.

In order to accomplish this, security operators route requests through Web data collection networks to assess the risk of potentially malicious websites or URLs.

The requests then return information, or Web data. That Web data provides details on how the domain reacted to the request, which then allows the security teams to assess the threat (or lack thereof) and take proper action to mitigate it before it ever reaches their Web-based systems.

Within applications, this method essentially provides a firewall, opening a one-way access to information, considering the manner in which the requests are routed: away from their internal systems — safeguarding their organization’s internal network.

**Security Use Cases:****Scraping for Possible Malware and Phishing Schemes Targeting US Banks**

The security departments of some of the leading US banks use public Web data collection networks to gather information about possible online threat actors and examine malware.

Additionally, they use Web scraping techniques to continually and automatically scan the public domain for potentially malicious websites or links. For example, security teams can automatically identify different phishing sites that attempt to steal sensitive client or company information such as usernames, passwords, or credit card information.

From here, when an email comes into the organization’s network or a website is approached, the security team already knows the risk parameters attached to it.

**Web Scraping for Cybersecurity Firms**

A number of cybersecurity firms use Web data collection in order to assess the risk of different domains for malware and fraud.

They generate or purchase lists of potentially malicious domains, and then route DNS requests to each of these links, servers, or websites to see how they react to the request.

This provides the cybersecurity firms with the ability to approach possibly malicious websites as a “victim” or a real user, and see how the website would target an unsuspecting visitor to properly assess the risk.

**Threat Research and Mitigation**

Threat intelligence firms deploy the use of public Web data collection networks to tap into various sources of information, such as hacker or app forums, public social media channels, blogs, and so on, to identify new leads on various potential threats.

This collection of Web data is foundational to their intelligence insights, which they then share with a wide range of customers looking to bolster their own security operations.

**Key Takeaways**

Overall, integrating with Web data collection networks enhances an organization’s visibility and ability to deal with digital threats across the vast online landscape in real-time.

This is particularly important considering the recent shifts made in remote working, as well as the broadening of online operations, strategies, and services all around, following the onset of the coronavirus, which only further add to the lists of risks or pathways that can disrupt organizational security.

So, while the task set before security teams has become increasingly more difficult, Web data collection networks have essentially transformed this once complicated ordeal into a much more manageable endeavor by providing options for automation — helping them to target more sources of information, in turn identifying more risks, while protecting the integrity of their own internal systems in the grand scheme of things.

**About the Author**

    

Or Lenchner is CEO of Bright Data, a position he has held since July 2018. For the past few years, under his leadership, the company has advanced its product offerings to include first-of-its-kind automated solutions, enabling its over 15,000 customers to collect and receive public data in a matter of minutes. Prior to his career at Bright Data, Lenchner founded and managed several Web-based businesses, developing digital assets and online marketing programs.

Threat Intelligence Through Web Scraping

Epic Games has been fined for violating children's online privacy, banned from using collected data.

The Federal Trade Commission announced it has reached a settlement with Epic Games, the developer behind the wildly popular online game Fortnite, for its violation of the Children's Online Privacy Protection Act (COPPA). The settlement still requires approval from a US federal court.

In addition to paying a $275 million fine, Epic Games received an injunction barring it from utilizing any of the Fortnite data collected outside COPPA rules, according to a statement from the FTC.

"As our complaint notes, Epic used privacy-invasive default settings that harmed young Fortnite players," FTC Chair Lina M. Khan said in the announcement. "Protecting the public, and especially children and teens, from online privacy invasions is a top priority for the Commission, and this enforcement action makes clear to businesses that the FTC is cracking down on these unlawful practices."

This isn't Epic Games' first security snafu. In 2019, a vulnerability in its online platform could have threatened data belonging to players of Fortnite.

Fortnite, created by Epic Games, has more than 80 million players and is responsible for nearly half of the video game developer's estimated value of $5 billion to $8 billion.

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Fortnite Developer Epic Games Slapped With $275M Penalty

A fully functional SentinelOne client is actually a Trojan horse that hides malicious code within; it was found lurking in the Python Package Index repository ecosystem.

In the latest supply chain attack, an unknown threat actor has created a malicious Python package that appears to be a software development kit (SDK) for a well-known security client from SentinelOne. 

According to an advisory from cybersecurity firm ReversingLabs issued on Monday, the package, dubbed SentinelSneak, appears to be a "fully functional SentinelOne client" and is currently under development with frequent updates appearing on the Python Package Index (PyPI), the main repository for Python code. 

SentinelSneak does not attempt malicious actions when it is installed, but it waits for its function to be called by another program, researchers noted. As such, the attack highlights attackers' focus on the software supply chain as a way to inject compromised code into targeted systems as a beachhead for further attacks. So far, those further attacks have likely not happened, researchers said. 

"A cursory glance at the source of this package would have easily missed the malicious functionality injected in the otherwise legitimate SDK code," says Tomislav Pericin, chief software architect at ReversingLabs.

The attack also demonstrates a common way to attack the supply chain: Use a variant of typosquatting to create malicious packages that bear names similar to well-known open source components. Often called dependency confusion, the technique is an example of one used against the Node Package Manager (npm) ecosystem for JavaScript programs in an attack dubbed "IconBurst," according to research published in July. 

In another typosquatting attack, a threat group uploaded at least 29 clones of popular software packages to PyPI.

"The SentinelOne imposter package is just the latest threat to leverage the PyPI repository and underscores the growing threat to software supply chains, as malicious actors use strategies like 'typosquatting' to exploit developer confusion and push malicious code into development pipelines and legitimate applications," ReversingLabs stated in its advisory.

While code repositories of all kinds are under attack, overall, the npm ecosystem has suffered more malicious attention than the Python Package Index. In 2022, 1,493 malicious packages have been uploaded to PyPI, a drop of nearly 60% from the 3,685 malicious uploads detected by ReversingLabs in 2021, the company stated.

**Fooling the Unwary**

In the latest effort, the fake SentinelOne 1.2.1 package raises many red flags, the advisory stated. The suspicious behaviors include the execution of files, the creation of new processes, and communicating with external servers using their IP address rather than a domain name.

ReversingLabs stressed that the client has no connection to SentinelOne, besides using the security firm's name. The PyPI package appears to be an SDK that helps simplify programmatic access to the client.

"It could be that malicious actors are attempting to draft on SentinelOne’s strong brand recognition and reputation, leading PyPI users to believe that they have deployed SentinelOne's security solution, without taking the — necessary — step of becoming a SentinelOne customer," ReversingLabs stated in its advisory. "This PyPI package is intended to serve as an SDK to abstract the access to SentinelOne’s APIs and make programmatic consumption of the APIs simpler."

In a statement to Dark Reading, SentinelOne reiterated that the package is fake: "SentinelOne is not involved with the recent malicious Python package leveraging our name. Attackers will put any name on their campaigns that they think may help them deceive their intended targets, however this package is not affiliated with SentinelOne in any way. Our customers are secure, we have not seen any evidence of compromise due to this campaign, and PyPI has removed the package."

**Attackers See Developers as Another Vector**

The attack also shows that developers are becoming an increasing target of attackers, who see them as a weak point in targeted companies' defenses, as well as a potential way to infect those companies' customers. 

In September, for example, attackers used stolen credentials and a development Slack channel to compromise game developer Rockstar Games and gain access to sensitive data, including assets for the developer's flagship Grand Theft Auto franchise.

For that reason, companies should help their developers understand which software components could pose a risk, Pericin says.

"Developers should put new project dependencies under a higher degree of scrutiny before opting to install them," he says. "Given that the malware only activates when used, not when installed, a developer might have even built a new app on top of this malicious SDK without noticing anything odd."

In the case of SentinelSneak, the threat actor behind the Trojan horse published five additional packages, using variations on the SentinelOne name. The variations appear to be tests and did not have a key file that encapsulated much of the malicious functionality.

ReversingLabs reported the incident to the PyPI security team on Dec. 15, the company said. SentinelOne was notified the next day.

"We've caught this malicious package very early," the company said. "There's no indication that anybody has yet been affected by this malware."

  
_Story was updated to include a statement from SentinelOne._

Source

DARKReading