Black Hat presentation reveals adversaries don't need to complete all seven stages of a traditional kill chain to achieve their objectives.

Source: Funtap via Shutterstock

BLACK HAT USA – Las Vegas – Thursday, Aug. 8 – Organizations that are expanding their use of SaaS applications may want to revise their notions of — and approaches to — the cyber kill chain.

SaaS applications have transformed the modern organization's attack surface and eliminated — or made easier — several of the steps that adversaries have traditionally needed to execute a successful attack, researchers at AppOmni said in a talk at Black Hat USA 2024.  Security teams need to revise and readjust their defenses to keep ahead of the new reality.

**The SaaS Kill Chain**

"The SaaS-enabled kill chain, when considered from the lens of MITRE ATT&CK tactics, is abbreviated," the researchers said. "Several steps are often skipped or entirely unnecessary for an attack to accomplish their goals and the majority of defenses are focused on the initial access stage."

The software-as-a-service model has become nearly ubiquitous. Research Productiv conducted last year revealed organizations, on average, used a staggering 342 SaaS applications at the end of 2023, with operations teams being the biggest users, followed by IT, sales, and product teams. Among the most popular SaaS products were Confluence, Salesforce, Tableau, Atlassian Cloud, and Jira.

AppOmni found the growing use of such applications give adversaries new — and often quicker — ways to target enterprise application and data than before. Researchers at the company analyzed some 230 billion normalized SaaS audit log events from across 24 different SaaS services and 1.9 million alerts over a six-month period to get an idea of attacker tactics, techniques, and procedures (TTPs) in SaaS environments.

The analysis showed that attackers often don't need to execute all seven steps of the traditional chain to launch a successful SaaS attack. Lockheed Martin's cyber kill chain — which has long been used as a basis for defending against attacks — identifies reconnaissance, weaponization, delivery, exploitation, installation, command and control, and actions on objectives as actions an adversary must complete to pull off a successful attack.

With attacks on SaaS environments, "the kill chain from an attacker's perspective is really centralized down to a couple of points: initial access and credential access, and collection and exfiltration," Brandon Levene, principal product manager, threat detection, at AppOmni tells Dark Reading.

**Walking in Through the Front Door**

In many of the attacks that AppOmni analyzed, adversaries gained access to an organization's SaaS applications through an externally facing identity provider. "Usually, they just walk in through the front door with valid accounts," Levene says. Attackers often use infostealers to grab user credentials to cloud accounts or tactics like credential stuffing, brute force, and password spraying to acquire credentials to cloud accounts — or they simply purchase them in Dark Web markets, according to Levene.

"Once you are past the IdP \[identity provider\] like an Okta, or a Ping or an Entra, all applications behind that are freely available to you as the attacker," he says. That means attackers don't have to necessarily conduct reconnaissance to gather information on a target environment because they already have access to it.

Similarly, an attacker needs little time and resources to establish persistence on a compromised environment or enable lateral movement because a valid credential gives them persistent and wide access to whatever they need. "Once you compromise an externally facing identity provider like Okta, you don't need persistence or lateral movement," Levene says.

He points to two large attacks that AppOmni analyzed as examples of how adversaries target SaaS environments. In one of them, the threat actor logged into the IdP using a valid token and then modified the IP ranges that were allowed to authenticate to various applications. In just 10 minutes, the threat actor downloaded more than 100 files from cloud storage and information repositories. They also modified authentication policies for some applications and changed direct deposit payment choices in a likely attempt to redirect funds. "They didn't have to go through a VPN. They didn’t even bother to obfuscate their real location. What they did was basically smash and grab," Levene says.

He adds that many of the brute force, password spraying, and credential stuffing attacks that AppOmni observed targeted Microsoft O365 and came from two large Chinese networks: ChinaNet and China Unicon.

Enabling better visibility across SaaS environments is a key first step to protecting against such attacks, he notes. Organizations need to understand their attack surface, look at how their SaaS apps are configured and monitor them. They must also fully leverage their IdP's capabilities and features like MFA and hardware tokens. Levene adds that the goal should be to enforce a zero-trust access model to SaaS applications.

**About the Author**

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year career at Computerworld, Jai also covered a variety of other technology topics, including big data, Hadoop, Internet of Things, e-voting, and data analytics. Prior to Computerworld, Jai covered technology issues for The Economic Times in Bangalore, India. Jai has a Master's degree in Statistics and lives in Naperville, Ill.

SaaS Apps Present an Abbreviated Kill Chain for Attackers

Researchers at Aqua Security discovered the "Shadow Resource" attack vector and the "Bucket Monopoly" problem, where threat actors can guess the name of S3 buckets based on their public account IDs.

Source: Holger Burmeister via Alamy Stock Photo

BLACK HAT USA – Las Vegas – Thursday, Aug. 8 – Six critical vulnerabilities in Amazon Web Services (AWS) could have allowed threat actors to target organizations with remote code execution (RCE), exfiltration, denial-of-service attacks, or even account takeovers.

"Most of the vulnerabilities were considered critical because they gave access to other accounts with minimal effort from the attacker perspective," Aqua's lead security researcher Yakir Kadkoda tells Dark Reading.

During a briefing on Wednesday at Black Hat USA in Las Vegas, researchers at Aqua Security revealed that they discovered new attack vectors using bugs "Bucket Monopoly" and "Shadow Resources." The impacted AWS services include Cloud Formation, CodeStar, EMR, Glue, SageMaker, and Service Catalog.

Upon discovering the vulnerabilities in February, the Aqua researchers reported them to AWS, which confirmed the issues and rolled out mitigations to the respective services piecemeal between March and June. However, open source iterations could still be vulnerable.

**'Bucket Monopoly': Attacking Public AWS Account IDs**

The researchers first uncovered Bucket Monopoly, an attack method that can significantly boost the success rate of attacks that exploit AWS S3 buckets — i.e., online storage containers for managing objects, such as files or images, and resources required for storing operational data.

The issue is that S3 storage buckets were designed to use predictable, easy-to-guess AWS account IDs instead of a unique identifier for each bucket name using a hash or qualifier.

"Sometimes the only thing that an attacker needs to know about an organization is their public account ID for AWS, which is not considered sensitive data right now, but we recommend it is something that an organization should keep as a secret," Kadkoda says.

To mitigate the issue, AWS changed the default configurations.

"All of the services have been fixed by AWS in that they no longer create the bucket name automatically," he explains. "AWS now adds a random identifier or sequence number if the desired bucket name already exists."

Security researchers and AWS customers have long debated whether AWS account IDs should be public or private. AWS cautions customers against sharing credentials and advises them to use and share account IDs carefully. However, according to AWS documentation on account identities, account IDs "are not considered secret, sensitive, or confidential information."

Aqua's researchers disagree.

"Based on our research, we strongly believe that account IDs should be considered secrets since there may be other kinds of similar exploits that could be carried out based on knowing an account ID," Kadkoda notes in a detailed technical report on the vulnerabilities set to be published on Friday. "Although the common assumption is that knowing an account ID alone is not sufficient to hack an account, attackers might still use it to gather information about your AWS account and more."

An AWS spokesperson declined to comment on that specifically, but did say that AWS was aware of this research.

"We can confirm that we have fixed this issue, all services are operating as expected, and no customer action is required,” the spokesperson says.

**Shadow Resources: Hidden Assets Offer Cover for Attackers**

Kadkoda says his team also discovered the Shadow Resources attack vector, which can create AWS S3 service components unknown to the account owner.

The researchers initially discovered the problem in the AWS CloudFormation service, where an attacker could engage in resource squatting by creating accounts in unused AWS geographic regions with the same name as legitimate, existing stacks. Once the victim stored their workloads in a new region, they could connect to it and then unknowingly use attacker-controlled S3 buckets.

That's because when using the service with the AWS Management Console to create a new stack, AWS automatically creates an S3 bucket to store CloudFormation templates. The name of the S3 bucket is the same across all AWS regions, which is how an attacker can guess the account name and gain access to it.

"I can take over your S3 bucket and just poison the configuration and replace it," Aqua security researcher Assaf Morag says. "It's a huge thing because in between the lines, with a remote code execution, you can grab the accounts of any company in the world."

All services require configuration files, and AWS uses S3 buckets as its file system to store configurations.

"In most cases, these configurations are really significant because these are the instructions to the services," Morag says. "It could be a YAML file or other things that the service needs to use behind the scenes."

Given that customers can have hundreds or thousands of distinct AWS accounts spread across regions worldwide, exploits of shadow services could have been significant, Morag emphasizes. Where there were any victims of the vulnerability is not known.

"The potential of being attacked or being a victim could have been massive," he says.

**Open Source Projects in S3 Buckets Could Still Be Vulnerable**

While AWS has mitigated the vulnerabilities impacting its services, Kadkoda warns that the attack vectors could still impact open source projects deployed in their AWS environments. Many open source projects automatically create S3 buckets or direct users to deploy them, he notes.

"We found a lot of open source projects vulnerable to this vector because they're using them behind the scenes with predictable bucket names," Kadkoda says.

Users should check to see whether each existing bucket's name has been claimed elsewhere, and, if so, they should rename it.

In all cases, Kadkoda and Morag say users should avoid creating S3 buckets with predictable or static identifiers in the first place. Instead, they should create an S3 bucket name with a unique hash or a random identifier for each region and account to prevent attackers from claiming them first.

**About the Author**

Jeffrey Schwartz is a journalist who has covered information security and all forms of business and enterprise IT, including client computing, data center and cloud infrastructure, and application development for more than 30 years. Jeff is a regular contributor to Channel Futures. Previously, he was editor-in-chief of Redmond magazine and contributed to its sister titles Redmond Channel Partner, Application Development Trends, and Virtualization Review. Earlier, he held editorial roles with CommunicationsWeek, InternetWeek, and VARBusiness. Jeff is based in the New York City suburb of Long Island.

Critical AWS Vulnerabilities Allow S3 Attack Bonanza

Invisible authentication mechanisms in Microsoft allow any attacker to escalate from privileged to super-duper privileged in cloud environments, paving the way for complete takeover.

Source: Sergey Nivens via Alamy Stock Photo

BLACK HAT USA – Las Vegas – Wednesday, Aug. 7 – An obscure issue with Microsoft's Entra ID identity and access management service could allow a hacker to access every corner of an organization's cloud environment.

Crucially, the attack requires that a hacker already have access to an admin-level account. With that in hand, though, the possibilities are limitless. At 4:20 p.m. local time today at Black Hat, Eric Woodruff, senior cloud security architect at Semperis, will describe how an attacker in such a position could take advantage of layered authentication mechanisms in Entra ID to gain all-powerful global administrator privileges.

An attacker with global administrator privileges can do anything in an organization's cloud environment to any of its connected services, including but not limited to accessing sensitive data and planting malware. As Woodruff explains, "It's like being a domain administrator in the cloud. As a global administrator, you can literally do anything: You could get into people's emails in Microsoft 365, you could move into any application that's tied to Azure, etc."

Entra ID is central to any organization using Microsoft 365 and Azure, managing and securing access and permissions across cloud applications and services.

Within each tenant (organization), Entra ID represents users, groups, and applications as "service principals," which can be assigned roles and permissions of one kind or another.

The problem identified by Woodruff begins with the fact that users with privileged Application Administrator or Cloud Application Administrator roles can assign credentials directly to a service principal. An attacker with such privileges can use this system quirk to effectively act as their targeted application when interfacing with Entra ID.

Next, the attacker can follow the OAuth 2.0 client credential grant flow, exchanging credentials for tokens that grant access to resources. This is where the second major issue comes into play. During his research, Woodruff identified three application service principals capable of performing actions they didn't appear to have permission to enact:

*   In the enterprise social networking service Viva Engage (formerly Yammer), the ability to permanently delete users, including Global Administrators.
    
*   In the Microsoft Rights Management Service, the ability to add users.
    
*   For the Device Registration Service, the ability to elevate privileges to the Global Administrator level
    

The Microsoft Security Response Center (MSRC) assigned these vulnerabilities medium, low, and high severity ratings, respectively.

Woodruff emphasizes that the issue with the Device Registration Service is far more significant than the others. "Generally, you would delegate Admin roles to people doing more day-to-day, mundane things \[in your organization\]. They don't have the power to do whatever. But if they happen to know of this path we found, they could go give themselves that role," he explains.

**Dealing With Cloud Permissions**

When Woodruff went to Microsoft with his findings, the company explained that, in fact, he was allowed to do what he did thanks to hidden authentication mechanisms "behind the scenes."

Dark Reading reached out to Microsoft for more information about how these layered, unseen authentication mechanisms work, and why they exist in the first place. A Microsoft spokesperson replied with no further details.

For now, Microsoft has been patching over the issue with new controls that limit the use of credentials on service principals. Now, when one attempts privilege escalation using the Device Registration Service, Microsoft Graph returns an error.

It's unclear whether this issue has ever been exploited in the wild. To determine that, Woodruff says, organizations can review Entra ID audit logs, or look out for leftover attacker credentials. Neither method is foolproof, however, as logs tend to expire after a certain period of time, and attackers can always retroactively hide their paper trails.

"Having worked in the whole Microsoft ecosystem awhile, I've run a lot of security assessments and would find that a lot of organizations have relatively lax security around application administrators. You see it in the news these days: Someone targets the help desk, and the next thing you know, they're a domain admin, because of some privilege chain," he says.

This latest discovery, though part of the same pattern, was nonetheless a bit of a shock. "It was sort of like: Oh, these app admins at a lot of orgs aren't really guarded the way they should be," he says.

**About the Author**

Nate Nelson is a freelance writer based in New York City. Formerly a reporter at Threatpost, he contributes to a number of cybersecurity blogs and podcasts. He writes "Malicious Life" -- an award-winning Top 20 tech podcast on Apple and Spotify -- and hosts every other episode, featuring interviews with leading voices in security. He also co-hosts "The Industrial Security Podcast," the most popular show in its field.

Hazy Issue in Entra ID Allows Privileged Users to Become Global Admins

The number of additions to the Known Exploited Vulnerabilities catalog is growing quickly, but even silent changes to already-documented flaws can help security teams prioritize.

CVE age distribution of KEV by groupSource: GreyNoise Intelligence

B-SIDES LAS VEGAS – Las Vegas – Wednesday, Aug. 7 – Organizations that use the Known Exploited Vulnerabilities (KEV) catalog to prioritize patching are likely missing silent changes to the list that could indicate that an issue's severity has changed, according to an analysis presented at the BSides Las Vegas conference on Aug. 7.

The KEV catalog — which currently consists of more than 1,140 vulnerabilities that are known to have been exploited in the wild — tracks software flaws by their Common Vulnerabilities and Exposures (CVE) identifier, records the date when the vulnerability was confirmed in the wild and has a flag that indicates whether ransomware groups are using the security issues.

Yet, specific changes to the data — such as uncommonly short times to remediate vulnerabilities and changes to the ransomware status — can give security teams valuable information, the analysis stated.

Unfortunately, the Cybersecurity and Infrastructure Security Agency (CISA), which manages the list, does not often call out these changes and outliers, says Glenn Thorpe, senior director of security research and detection engineering at GreyNoise Intelligence.

"We who are not bound by its directives forget that this is actually a to-do list," he says, adding: "So, if folks are actually using this to prioritize remediation or some kind of process, they need to know \[when\] it is updated silently."

The KEV catalog, introduced in November 2021 with 290 exploited vulnerabilities, is maintained by CISA and gives organizations the information necessary to prioritize patching flaws that are currently under attack. The list, however, does not rank the severity of issues, and vulnerabilities are often not added until well after the initial evidence of exploitation comes to light.

**Surge From a Cyber Conflict**

While less than 3 years old, the KEV catalog has already passed through three periods, Thorpe says. The original catalog had 287 vulnerabilities, which had an average age — the time between the release of the CVE and the vulnerability's addition to the KEV list — of 591 days. Then, during a 109-day period in early 2022 and the initial months of Russia's invasion of Ukraine, a massive stockpile of vulnerabilities was exploited, encompassing 396 issues with an average age of 1,898 days.

Starting in mid- to late 2023, CISA started changing its policies on the KEV catalog, providing additional signals as to the severity of a vulnerability. Source: GreyNoise Intelligence

Since mid-2022, 453 newly exploited vulnerabilities have been discovered, with an average age of 567 days.

"There is this thought that maybe the numbers have gone down, because the Russia-Ukraine conflict has dragged on so long," he says. "But I \[feel that\] when it ends, each side will looking for vulnerabilities and stockpiling once again."

Five organizations — Microsoft, Apple, Cisco, Adobe, and Google — account for about half of all vulnerabilities on the list, demonstrating cyberattackers' penchant for major software platforms.

**Pay Attention to Friday Updates**

While any vulnerability in the KEV catalog should likely be patched as soon as possible, companies may want to prioritize those being used in ransomware campaigns. The list has a flag designating whether CISA has confirmed use of a particular flaw by ransomware gangs. However, at least 41 times, that flag has been changed to "known" — indicating ransomware use — after the vulnerability's addition to the list without explicit notification.

Perhaps more critical for prioritization is the "due date" for fixing a vulnerability, which informs federal agencies of the date by which the issue must be remediated. While the vast majority of vulnerabilities have a 21-day requirement, since late 2023, CISA has set shorter remediation deadlines for specific vulnerabilities. The shorter patching deadlines are typically for more critical appliances that are connected to a networks, such as the severe Ivanti vulnerabilities, as well as issues in Juniper routers and Cisco devices and Atlassian's Confluence server, GreyNoise's Thorpe says.

In fact, another data point suggests that CISA made other changes to how it handles KEV-catalog announcements in late 2023. Around the same time that CISA had assigned shorter deadlines, the agency also began foregoing the release of any list updates on Fridays, except in two specific cases, the analysis found.

"Either there was a decision made to prioritize these a little differently, or they ... were kind of figuring out how to prioritize these differently, because the list is getting big," Thorpe says.

Organizations can use the policy changes inferred from the way CISA updates the KEV catalog to understand which issues the agency considers most critical. A KEV update released on a Friday should be considered significant, as should a vulnerability with a due date less than 21 days away. Finally, Thorpe says, updates to the known ransomware usage field are another signal that security teams should pay attention to.

**About the Author**

Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT's Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline Journalism (Online) in 2003 for coverage of the Blaster worm. Crunches numbers on various trends using Python and R. Recent reports include analyses of the shortage in cybersecurity workers and annual vulnerability trends.

Monitoring Changes in KEV List Can Guide Security Teams

The security vendor has also implemented several changes to protect against the kind of snafu that crashed 8.5 million Windows computers worldwide last month.

Source: Ascannio via Shutterstock

CrowdStrike will give customers more control over how they deploy content updates to the company's Falcon sensor endpoint security technology following the recent incident that saw a faulty update crash more than 8.5 million Windows systems worldwide.

The beleaguered security vendor — which is the target of two lawsuits over the incident already — has implemented new features to its platform to support the capability with additional functionality planned for the future.

**Multiple Changes**

The update is one of several changes CrowdStrike has implemented following the completion of a root cause analysis (RCA) of the July 19 incident. In an Aug. 7 update, CrowdStrike announced other changes it has made to ensure something similar does not happen in the future. The changes include new content configuration system test procedures, additional deployment layers and acceptance checks for its content configuration system, and new validation checks for its updates.

CrowdStrike has also asked two independent third-party security vendors to review the code for its Falcon sensor technology and of the company's quality control and release processes for the product. "We are using the lessons learned from this incident to better serve our customers," CrowdStrike CEO George Kurtz said in a statement that accompanied its RCA. "To this end, we have already taken decisive steps to help prevent this situation from repeating and to help ensure that we — and you — become even more resilient."

CrowdStrike's problems started with a July 19 content update for a new Falcon sensor capability that the security vendor first rolled out in February 2024. The automatically deployed update caused Windows systems worldwide to crash and created enormous disruptions for organizations across multiple sectors, including airlines, financial services, healthcare, manufacturing, and government. In many cases, systems admins had to manually restart computers, which meant that it took days for numerous organizations to restore services fully.

CrowdStrike has already become the target of at least two class-action lawsuits over the incident — one on behalf of the company's shareholders and the other on behalf of affected businesses. Many others, including Delta Air Lines, are expected to sue CrowdStrike over related outage costs in coming days and months.

**Parameter Count Mismatch**

The security vendor has identified a parameter count mismatch between what its Falcon sensor product expected and what the July 19 content configuration update actually contained as the root cause for the problems. The update was for a Falcon sensor feature that CrowdStrike rolled out in February to detect and provide insights into new attack techniques that exploit specific Windows mechanisms. Falcon sensor uses a specific template with a predefined set of 20 separate input fields to deliver this specific capability.

CrowdStrike's content configuration update on July 19 provided 21 input fields rather than the 20 fields the sensor expected. "In this instance, the mismatch resulted in an out-of-bounds memory read, causing a system crash," CrowdStrike said.

While the security vendor introduced the template with the mismatched parameter count in February, its analysis showed it slipped past multiple layers of build validation and testing.  No one caught the discrepancy during the sensor release test process, during stress tests of the template, or even during initial real-world deployments. In part, this was because the test processes and initial deployments used a "wildcard matching criteria" — meaning they accepted any value or no value at all — for the extra input field's parameter.

The July 19 update used a non-wildcard matching criterion for the July 21 parameter, which meant the sensor had to contend with data for a field it did not expect. "The Content Interpreter expected only 20 values," CrowdStrike said. "Therefore, the attempt to access the 21st value produced an out-of-bounds memory read beyond the end of the input data array and resulted in a system crash."

**About the Author**

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year career at Computerworld, Jai also covered a variety of other technology topics, including big data, Hadoop, Internet of Things, e-voting, and data analytics. Prior to Computerworld, Jai covered technology issues for The Economic Times in Bangalore, India. Jai has a Master's degree in Statistics and lives in Naperville, Ill.

CrowdStrike Will Give Customers Control Over Falcon Sensor Updates

During a "Shark Tank"-like final, each startup's representative spent five minutes detailing their company and product, with an additional five minutes to take questions from eight judges from Omdia, investment firms, and top companies in cyber.

Founder and CTO of Knostic, Sounil Yu, runs to the stage to collect his award after being announced the winner of the 2024 Startup Spotlight competition.Source: Kristina Beek

BLACK HAT USA – Las Vegas – Wednesday, Aug. 7 – Eitan Worcel, CEO of Mobb Security, last year's Startup Spotlight winner, last night announced that the torch would be passed to the 2024 winner: Knostic, an LLM access-control company. Sounil Yu, Knostic founder and CTO, was present to accept.

In the first phases of the competition, each group submitted a five-minute video pitch on behalf of their cybersecurity startup to present their company and the products and solutions it provides, whether it be in the development, launch, or newly launched stage.

After that, the selection dwindled to a select, top four finalists: LeakSignal, RAD Security, DryRun Security, and Knostic. Each made a final pitch on behalf of their companies in last night's event at Black Hat USA, in a Shark Tank\-style competition.

The panel of judges included Omdia analysts Ketaki Borade, Hollie Hennessy, and Rik Turner; Coleen Coolidge of Twilio; Trey Ford of Deepwatch; Maria Markstedter of Azeria Labs; Lucas Nelson of VC firm Lytical Ventures; and Robert J. Stratton III of startup accelerator MACH37.

**4 Unique Cyber Startups, Pitching to the Judges**

LeakSignal is an openly distributed data governance solution that aims to classify and protect sensitive data, allowing customers to set limits on internal API data access and focus on data classification. The platform blocks sensitive data before it’s logged, and redacts that data during calls to outbound third-party APIs.

The platform is built with Rust, and is designed to integrate with an organization's existing architecture. Its team's next-stage focus is to expand the support LeakSignal provides to more complex AI models, and to refine its data classification algorithms to provide a more accurate and comprehensive protection. 

RAD Security meanwhile focuses on tackling security issues surrounding cloud native development. According to the company, "For teams to achieve true resilience against emerging threats, detection and response solutions must evolve their approach beyond signature-based, one-size-fits-all solutions."

To that end, the company aims to provide customers with a custom view of what should and shouldn’t be happening in their cloud infrastructure, providing a unique and more accurate detection-and-response plan for malicious behavior. By creating fingerprints of the good behavior an enterprise is experiencing across its software supply chain, cloud native infrastructure, and workloads, RAD Security is better able to detect anomalies to that — and thus any cyberattacks the company faces. 

The third finalist, DryRun Security, is an application security company that provides automated, behavioral code reviews by interrogating code changes based on static patterns and behaviors. Ken Johnson, CTO and co-founder of DryRun, explained that after he and CEO James Wickett realized that the security industry had been anaylzing software in the same manner for years on end, they decided to build their company to create not only a developer-first tool, but also a new way of analyzing and detecting risk. The company currently conducts more than 10,000 secure code reviews for its customers, using an approach that it explains is grounded in the principles of contextual security analysis (CSA).

Rounding out the group is winning startup Knostic, comprised of 12 employees, with a pre-seed funding of $4.4 million, and which aims to ensure that internal generative AI (GenAI) tools aren't leaking sensitive data to users that shouldn't have access to it.

As GenAI tools like ChatGPT continue to gain popularity, organizations are learning that connecting a large language model (LLM) to its internal systems comes with a serious risk of exposing sensitive data. Knostic creates a knowledge control layer based on employees' permissions for accessing content.

In a demonstration during the presentation, Yu showed the audience a mock interface of an HR department user sending a message to an internal chatbot inquiring about quarterly sales revenue. Knostic's platform ensured that the actual numerical value — sensitive financial information — was not revealed, but provided additional useful information instead outlining which departments contributed the most toward the company's profitability. The same query made by a CEO however returned the actual dollar figure, as the CEO has higher clearance.

"What differentiates the two is need to know," said Yu during the presentation.

The company's product works with Copilot for Microsoft 365 for now, but the next phase is to expand support to all software-as-a-service (SaaS) tools that incorporate LLMs.

**Winner's High**

When asked how it felt to present to the crowd amongst fellow finalists, Yu tells Dark Reading that he "was preparing for disappointment" after he completed his presentation.

"It's a high stress environment," Yu says. "Your perception of time completely changes, right? I was like 'Oh, I got this in four minutes and thirty seconds. No problem.'" During his presentation, however, Yu was cut short by the five-minute timer. In hindsight, he says, the experience was great.

"I think the opportunity \[to present\] to this sort of audience is a very legitimate validation," Yu says. "All finalists deserve attention, because it means there's real value that we're producing. I'm fortunate that we were able to win, but I think we should recognize all the other contestants for the value that they brought."

Knostic Wins 2024 Black Hat Startup Spotlight Competition

The evolving malware is targeting hospitality and other B2C workers in Canada and Europe with capabilities that can evade Android 13 security restrictions.

ImageBroker.com GmbH & Co. KG via Alamy Stock Photo

The Chameleon Android banking Trojan is back on the threat scene, armed with new Android security-bypass features. The malware poses as a customer relationship management (CRM) application and targets employees in the hospitality sector and other business employees on two continents.

Researchers from Threat Fabric revealed that the device-takeover Trojan is targeting "hospitality workers and potentially B2C business employees in general" across Canada and Europe. Researchers say the new variant uses a dropper that can bypass Android 13+ AccessibilityService restrictions.

The Trojan is targeting a popular restaurant chain in Canada, which operates globally, to get access to corporate banking accounts, which would pose a "significant risk" to the organizations breached, according to Threat Fabric.

"The increased likelihood of such access for employees whose roles involve CRM is the likely reason behind the choice of the masquerading during this latest campaign," according to a blog post from Threat Fabric.

Researchers also see evidence of attacks that target "customers of specific financial organizations" in which Chameleon masquerades as a security application to install a security certificate released by the victims' banks as part of the malware's resurgence.

**Shape-Shifting Malware**

Security researchers first detected Chameleon — which got its name for its ability to adapt to its environment through multiple new commands — around December 2022/January 2023, when it appeared in its earliest form as a work in progress. Except for an appearance late last year with a significantly more fully featured variant that could bypass biometric security, the malware has been flying under the radar.

Now it has evolved yet again, with new features that show how its operators are changing the malware to keep up with the Android OS as it also becomes fortified with advanced security features.

According to the Threat Fabric post, "Most significant is the Trojan's ability to bypass Android 13+ restrictions, which once again proves the prediction we made in the past — this capability has become essential for modern banking Trojans."

Chameleon's use of the BrokewellDropper for delivery is significant to this bypass; indeed, since the leak of the source code for the dropper — which has an extensive set of device-takeover capabilities — more threat actors now have access to security bypass on the Android OS, according to Threat Fabric.

**Trojan's Latest Disguise**

Chameleon's most recent disguise should be no surprise to security researchers tracking the Trojan, as the malware, like other Trojans, has historically impersonated trusted apps. Previously, Chameleon came cloaked as an app from institutions such as the Australian Taxation Office (ATO) or one of several popular banking apps in Poland to steal data from user devices.

Once loaded, the dropper displays a fake page masquerading as a CRM login page, requesting the employee ID. It then displays a message asking to reinstall the application, which is actually Chameleon, which installs and bypasses Android AccessibilityService restrictions. After installation, the Trojan loads a fake website again asking for the employee's credentials. If submitted, the app displays an error page, according to Threat Fabric.

Chameleon remains running in the background on a device, which means it can also collect other credentials and sensitive info from a user by using keylogging. "Such information can be used in further attacks or the actors can monetise it by selling  it on underground forums," according to the post.

**More Sophisticated Attacks**

The latest Chameleon campaign demonstrates how Trojan-wielding cybercriminals are finding new and innovative ways to target bigger assets beyond the banking credentials of individual mobile users, according to Threat Fabric. This should put all organizations on high alert to the evolving mobile threat landscape.

"With the rising number of banking products for businesses (especially small and medium) and the convenience of having them available through mobile, we can expect cybercriminals to further explore the approach of targeting such mobile devices and its users," according to the post.

To combat these threats, financial organizations can take preventive measures to educate business customers about the potential impact of mobile banking malware like Chameleon and the consequences these malicious apps can bring, according to Threat Fabric. Moreover, given their visibility into customers' financial accounts, banks should also become more proactive in spotting anomalies in activity and behavior to stop threats before they compromise accounts.

**About the Author**

Elizabeth Montalbano is a freelance writer, journalist, and therapeutic writing mentor with more than 25 years of professional experience. Her areas of expertise include technology, business, and culture. Elizabeth previously lived and worked as a full-time journalist in Phoenix, San Francisco, and New York City; she currently resides in a village on the southwest coast of Portugal. In her free time, she enjoys surfing, hiking with her dogs, traveling, playing music, yoga, and cooking.

Chameleon Banking Trojan Makes a Comeback Cloaked as CRM App

Microsoft claims 50,000 organizations are using its new Copilot Creation tool, but researcher Michael Bargury demonstrated at Black Hat USA ways it could unleash insecure chatbots.

Source: Brain Light via Alamy Stock Photo

BLACK HAT USA – Las Vegas – Wednesday, Aug. 7 – Enterprise usage of Copilot Studio, Microsoft's automated chatbot creation tool, has grown considerably since its release less than nine months ago. But despite opening the floodgates for anyone to create so-called "copilots," all bots created or modified with the service aren't secure by default.

So says security researcher Michael Bargury, a former senior security architect in Microsoft's Azure Security CTO office, now a project leader for the OWASP Low-Code/No-Code Top 10 Security Risks project and CTO at Zenity.

On Wednesday at Black Hat USA in Las Vegas, Bargury demonstrated how developers could unwittingly build copilots that inadvertently exfiltrate data or bypass policies and data loss prevention controls.

"It's very, very easy to make a mistake with this no-code tool and introduce a serious security vulnerability into a copilot," Bargury tells Dark Reading. "Actually, it's very difficult to get everything right because there are so many ways to get it wrong."

**Rapid Adoption of Copilot Studio**

The drag-and-drop, wizard-based Copilot Creation tool is available to all users of the Microsoft 365 productivity suite and has quickly introduced an easy way for power users in lines of business to create copilots, or AI assistants, that are designed to automate workflows and enable more efficient meetings, among other capabilities.

The addition of Copilot Studio to the mix further allows customers to extend the capability of these bots and build custom copilots.

During Microsoft's fourth quarter, 2024 fiscal year earnings call on July 30, chairman and CEO Satya Nadella touted that the usage of Copilots grew 60% in the last quarter. And the number of organizations that have used Copilot Studio grew by 70% last quarter, reaching 50,000 shops, including Carnival, Cognizant, Eaton, KPMG, Majesco, and McKinsey.

**Initial Release Was "Way Overpermissioned"**

Among some of the initial problems Bargury spotted were in the default settings in the copilot bots created by Copilot Creator. Specifically, many of the bots were publicly accessible without requiring authentication. Also, they could impersonate a user with ease.

"You could create a copilot that bakes your identity into it," he explains. "Now, I talk to that copilot over the Internet without logging in, and I'm using your identity. It was way overpermissioned."

Bargury says he discovered a variety of other security faults following the release of Copilot Studio. For example, someone trying to create a copilot designed to call on public SharePoint sites could also tap a private SharePoint site on the same network. Because the copilots could easily be discovered outside of an organization, they could become conduits for remote attacks.

"I could search the Web for open Copilot Studio bots, and we found tens of thousands of them," Bargury says. "And then I could fuzz those copilots with AI and find out which copilots I could talk to, and find out whether it's willing to talk to me and what kinds of information and operations it could perform. And then I could grab information from them."

He says that Microsoft has fixed the issues and has introduced new admin controls designed to strip away the ability to inadvertently create insecure actions, such as allowing an administrator to disallow users from creating bots that can be shared publicly. Admins should update their implementations to protect their organizations.

**Low Code & Chatbots: Balancing Productivity & Security**

The appeal of Microsoft Copilot and similar bots is that they enable users to be more productive, and they automate many routine tasks. But as this research shows, they can also be a weak link inside an organization. Bargury says he believes Microsoft is committed to ensuring Copilot Studio has better security from here on out.

"I think they are going to continue investing in giving admins more control," he says. "But they are in a tough spot because they need to balance productivity with security. And we know where the balance ends."

In his Black Hat session, Bargury also demonstrated CopilotHunter, a new module for the Power Pwn security tool set for Microsoft's low-code/no-code Power Platform that scans for open Copilot Studio bots and fuzzes them to access the data behind them. It is available on GitHub.

**15 Ways to Break Copilot Studio**

In his conclusion, Bargury broke down the 15 security issues he discovered with Copilot Security.

1.  Unreliable and untrusted input
    
2.  Multiple data leakage scenarios
    
3.  Oversharing sensitive data
    
4.  Unexpected execution path
    
5.  Unexpected execution path and operations
    
6.  Data flowing outside org's compliance and geo boundaries
    
7.  Sensitive data oversharing and leakage
    
8.  Destructive, unpredictable copilot actions
    

10.  Gain unintended data access
    
11.  Hardcoded credentials might be supplied as part of a copilot answer
    
12.  Oversharing copilot access through channels
    

14.  Oversharing copilot ownership with members
    
15.  Oversharing copilot ownership (and more) with guests
    

**About the Author**

Jeffrey Schwartz is a journalist who has covered information security and all forms of business and enterprise IT, including client computing, data center and cloud infrastructure, and application development for more than 30 years. Jeff is a regular contributor to Channel Futures. Previously, he was editor-in-chief of Redmond magazine and contributed to its sister titles Redmond Channel Partner, Application Development Trends, and Virtualization Review. Earlier, he held editorial roles with CommunicationsWeek, InternetWeek, and VARBusiness. Jeff is based in the New York City suburb of Long Island.

Creating Insecure AI Assistants With Microsoft Copilot Studio Is Easy

You're only as strong as your weakest security link.

Source: Elena Uve via Alamy Stock Photo

COMMENTARY

Most companies are sitting ducks regarding API security. During my two decades in infosec, I've never seen a threat landscape evolve as rapidly and dangerously as the one surrounding APIs. And here's the kicker: Most organizations are blissfully unaware of the ticking time bomb in their digital infrastructure.

Remember the Optus breach that exposed 9.8 million customer records last year? That was just the tip of the iceberg. APIs are the new favorite target for hackers, and for good reason. They're everywhere, often poorly secured, and packed with juicy data.

Don't believe me? Let's look at some numbers. A recent security audit for a midsize fintech client uncovered a staggering 5,743 distinct APIs in active use. Five years ago, that number was 486. This isn't an anomaly — it's the new normal.

But here's where it gets scary: Most companies have yet to learn how many APIs they run. It's like leaving your house with every window and door wide open and then wondering why you got robbed.

Take the recent Twilio debacle. A single unsecured API endpoint exposed 33 million phone numbers associated with Authy accounts, according to Trend Micro. The attackers didn't need sophisticated tools or insider knowledge. They fed a list of phone numbers into an API and watched the data pour out. It was that easy.

Or consider the 2021 Peloton fiasco. A faulty API allowed anyone to access users' private account data without authentication. Age, gender, and location were all up for grabs.

These aren't isolated incidents. They're symptoms of a systemic problem in our approach to API security. We're building digital skyscrapers on foundations of sand and then acting surprised when they come crashing down.

So, what can you do about it? Here are some practical steps:

1.  Get your house in order. Start cataloging every API in your ecosystem. You can't secure what you don't know exists. You can use automated discovery tools if you have to, but you can get a complete inventory.
    
2.  Adopt a zero-trust approach. Treat every API call as potentially malicious, regardless of origin. Implement strong authentication and authorization for every endpoint. No exceptions.
    
3.  Rate limit everything. Don't let attackers flood your APIs with requests. Set sensible limits and enforce them rigorously.
    
4.  Versioning is your friend. Implement a robust versioning system for your APIs. When vulnerabilities are discovered (and they will be), you need to be able to deprecate and disable old versions quickly.
    
5.  Educate your developers. Most API vulnerabilities stem from developers' lack of security awareness. Invest in regular training sessions focused explicitly on API security best practices.
    
6.  Monitor aggressively. Implement advanced monitoring and behavioral analysis tools. Be sure to look for anomalies in API traffic patterns. The sooner you can detect unusual activity, the better your chance of preventing a breach.
    
7.  Regular penetration testing. Don't wait for hackers to find your vulnerabilities. Conduct regular, API-focused penetration tests and fix the issues they uncover.
    

Here's the hard truth: If you're doing only some of these things, you're probably next on the hit list. The attackers are getting more innovative, more resourceful, and more persistent. They're probing your defenses right now, looking for that one weak API that will give them the keys to your kingdom.

The subsequent major breach isn't a matter of if, but when. And when it happens, the question won't be, "How did this happen?" We know how it will happen. The question will be, "Why didn't we do more to prevent it?"

It's time to wake up to the API security crisis and stop treating API security as an afterthought or a nice-to-have. With board-level visibility and dedicated resources, it must be at the forefront of your security strategy.

Because if you don't take API security seriously now, you'll be forced to take it seriously after a breach. And by then, it'll be too late.

The choice is yours. Act now — or explain to your customers later why you didn't.

**Additional Considerations**

As we delve deeper into the API security crisis, it's crucial to understand that this is not just a technical problem, it's a business problem. The repercussions of a major API breach can be devastating, affecting everything from your company's bottom line to its reputation in the market.

Consider the following:

1.  Regulatory compliance. With regulations like GDPR, CCPA, and others becoming increasingly stringent, API security is no longer just about protecting data — it's about avoiding hefty fines and legal troubles. A breach could cost your company millions in penalties and long-term damage to your brand.
    
2.  Third-party risk. Your API ecosystem likely extends beyond your organization. Third-party integrations and partnerships can be a significant vulnerability if not properly managed.
    
3.  Evolving attack vectors. Attackers are constantly innovating. From API poisoning to GraphQL abuse, new attack vectors are emerging faster than many organizations can keep up. 
    
4.  Continuous monitoring and improvement. The API security landscape is not static. What's secure today might be vulnerable tomorrow. Please make sure your API security posture evolves with the threat landscape.
    

Remember, you're only as strong as your weakest link in API security. It's time to fortify every aspect of your API ecosystem before it's too late. Your business's future may very well depend on it.

**About the Author**

Partner Solutions Architect

Vaibhav Malik has more than 14 years of experience in networking and security. He collaborates with global partners to create and deploy robust security solutions for enterprise clients. Malik is a recognized thought leader and expert in zero-trust security architecture. His previous roles at large service providers and security companies involved assisting Fortune 500 clients with network, security, and cloud transformation projects. He champions an identity and data-centric approach to security and is a popular speaker at industry events. With a master's in telecommunication from the University of Colorado Boulder and an MBA from the University of Illinois Urbana-Champaign, Malik's extensive expertise and hands-on experience make him an invaluable asset for organizations aiming to strengthen their cybersecurity posture in today's complex threat landscape.

The API Security Crisis: Why Your Company Could Be Next

PRESS RELEASE

NEW YORK – Today, Verizon Business released its 2024 Mobile Security Index (MSI) report outlining the top threats to mobile and IoT device security. This year’s report, in its seventh iteration, goes beyond employee-level mobile usage and extends into the usage of IoT devices and sensors and the security concerns the growth of these devices can present especially as remote work continues to be a trend. This expanded view of mobile security concerns for organizations showcases the evolving threat landscape that CIOs and other IT decision makers must contend with.

As dependency on mobile devices grows, so too do the risks, especially in critical infrastructure sectors where the consequences of security breaches can be catastrophic. The 2024 MSI, which surveyed 600 people responsible for security strategy, policy and management, underscores this point.

**Employees are using more mobile and IoT devices, leading to increased cyber risks**

The survey finds that 80% of respondents consider mobile devices critical to their operations, while 95% are actively using IoT devices. However, this heavy reliance comes with significant security concerns. In critical infrastructure sectors, where 96% of respondents report using IoT devices, more than half state that they have experienced severe security incidents that led to data loss or system downtime.

“These findings highlight the continued friction that employers face as more and more work is done on personal mobile devices,” said Phil Hochmuth Research VP, enterprise mobility at IDC. “This is why we are seeing more and more employers move from a pure bring-your-own-device model to employer provided devices where CIO’s can have greater governance to protect critical infrastructure from cyber attacks."

Additionally, Hochmuth says, organizations should adopt robust frameworks such as Zero Trust and the National Institute of Standards and Technology’s Cybersecurity Framework (NIST CSF) 2.0, and comply with mandates like the European Union’s NIS2 Directive.

**Emerging AI cyberthreats meet new AI defenses**

Emerging artificial intelligence (AI) technologies are expected to exacerbate the mobile threat landscape, but it also presents opportunities for defense. A striking 77% of respondents anticipate that AI-assisted attacks, such as deepfakes and SMS phishing, are likely to succeed. At the same time, 88% of critical infrastructure respondents acknowledge the growing importance of AI-assisted cybersecurity solutions.

**Accounting for IoT growth in cybersecurity planning**

With companies increasingly deploying IoT devices, their digital landscapes are evolving, creating a need for cybersecurity strategies to evolve in kind.

“The Industrial Internet of Things (IIoT) is giving rise to a massive expansion in mobile device technology that goes well beyond phones, tablets and laptops. Enterprise networks now include all sorts of sensors and purpose-built devices that monitor, measure, manage and control commercial tasks and data flow,” said TJ Fox, SVP of Industrial IoT and Automotive, Verizon Business. “That IIoT growth brings with it a proportionate need for more knowledge, awareness and IT solutioning to ensure the security of those increasingly sophisticated networks. The growing importance that IoT plays in our customer’s technology ecosystem underscores why it should be a component in any sound cybersecurity program.”

**What business leaders should know**

The 2024 MSI helps inform cybersecurity decisions for leaders of businesses of all sizes and in key sectors. As mobile and IoT threats rise, the need for robust security measures has never been greater. In response to these growing threats, 84% of respondents have increased their mobile device security spending over the past year, with 89% of critical infrastructure respondents planning further increases.

This year’s MSI includes contributions from Verizon’s partners including Ivanti, Lookout, Jamf among others.  Help your organization lower cyber risks by deploying comprehensive security protections, continuous employee education and advanced threat detection capabilities. Read the Verizon Business 2024 Mobile Security Index to learn more about suggested best practices your organization can implement.

Source

DARKReading