After 30 years and a brief pandemic hiatus, DEF CON returns with "Hacker Homecoming," an event that put the humans behind cybersecurity first.

DEF CON — Las Vegas — Halls stuffed with hackers lined up for hours for their chance to hone their skills on the latest tech, helped along by a volunteer army of so-called "goons" — it was a hopeful place to be last weekend during DEF CON 30.

Everyone wore masks so even the immunocompromised could participate. There was a trend toward focusing on using hacker powers to protect the population from utility breaches, smart car accidents, misinformation, and more. Giving the entire conference its reputational edge were rooms buzzing with information and the kind of immediacy and potency that made it feel almost subversive — punk rock, even.

Here are just a few of the highlights Dark Reading happened to find among the organized chaos that was DEF CON 30.

**1\. Merch Madness**

The longest lines, by many hours, were those to get the latest DEF CON-branded merchandise. While some used the time to refuel with snacks, others put a little more thought into the break in the action. Take Brad Lindsley, who made his own "Linecon Bag" with a mounted gaming screen and controllers for four players.

"I was waiting in line for hours at another DEF CON and I was thinking about what I would want to do in line," he told Dark Reading.

    

Brad Lindsley shows off his Linecon bag. (Photo by Becky Bracken for Dark Reading)

**2\. IoT Village**

DEF CON 30 hackers also had the option to ply their skills on dozens of Internet of Things (IoT) devices, including the Emergency Broadcast System and a Globecomm satellite system, thanks to the work of TIVO Trevor and the rest of the team, who spent the last 90 days building the IoT common control framework (CCF).

Trevor said that this year the IoT Village made the decision to shift its emphasis because of the shifting threat landscape that now focuses on infrastructure and other IoT devices.

"We've moved away from SOHO (small offices/home offices) to IoT this year," he told Dark Reading.

    

TIVO Trevor at the DEF CON 30 IoT Village. (Photo by Becky Bracken for Dark Reading)

**3\. Sink This Battleship**

There were too many contests going on during DEF CON 30 to count. One big one was a version of Capture the Flag called "Can You Sink the Ship?" put on by Fathom5, which challenged teams of hackers to bring down their ship training module. The kickoff was preceded by more than a few rules laid out by Fathom5 CTO David Burke, who included an instruction not to tinker with the hoses underneath: "Please don't spray hydraulic fluid everywhere around the room."

    

Burke explains the ground rules of the contest. (Photo by Becky Bracken for Dark Reading)

**4\. Other Challenges Accepted**

Other, less elaborate contests included a collection of Capture the Flag versions, Red Team challenges, and even a DEF CON Scavenger Hunt.

    

One of the many contest leaderboards projected around the DEF CON Contest Village. (Photo by Becky Bracken for Dark Reading)

**5\. The Voting Village**

Noted voting-machine researcher Harri Hursti, representing the Election Integrity Foundation, brought in a collection of voting machines currently in use across the US for hackers and conspiracy theorists alike to try out and challenge their security.

Dark Reading ran into a group of hackers giving one of the US voting machines a careful look. Asked if they thought they might be able to crack into it, one of the group responded, "I don't know if we can, but it's fun thing to play with."

    

Voting machine hackers, from L to R: Wkampbel, Segzf4ult, Cole Knight, James, Semifour. (Photo by Becky Bracken for Dark Reading)

**6\. The Signage**

Even the signage spread out around DEF CON 30 was flair-forward, with an array of clever quips, dazzling digital renderings, and just straight-up art. Here is just the tiniest taste of what was on display.

    

The Chill Out Room at DEF CON had an elaborate stage for DJs and performances. (Photo by Becky Bracken for Dark Reading)

    

Signage at the lock-picking area at DEF CON. (Photo by Becky Bracken for Dark Reading)

    

Wall projection over main DEF CON 30 entrance. (Photo by Becky Bracken for Dark Reading)

**7\. Brain Hacking & Misinformation**

An entire village at this year's DEF CON was dedicated to misinformation. With phishing and social engineering still driving so many successful cyberattacks, Dr. Matthew Canham of Beyond Layer 7 gave a presentation on cognitive security, which essentially means blocking attackers from compromising the brain itself. From optical illusions to instances like Cambridge Analytica's practice of building psychographic profiles to target victims, brain hacks are here and getting more sophisticated, according to Dr. Canham.

    

Misinformation Village information screen prior to Dr. Canham's presentation. (Photo by Becky Bracken for Dark Reading)

**8\. The Traditions**

This year was Michael Bargury's debut on the DEF CON stage. That meant that before he kicked off his presentation about codeless malware, the CTO and cofounder of Zenity (and Dark Reading columnist) engaged in a DEF CON tradition... he did a shot, along with his "goon" who gave the introduction. After a few seconds and just one wince while the liquor went down, Bargury was officially inaugurated into the DEF CON speaker's club and ready to go.

    

Bargury takes the podium following his inaugural shot of courage. (Photo by Becky Bracken for Dark Reading)

DEF CON 30: Hackers Come Home to Vibrant Community

The most heavily targeted flaw last quarter was a remote code execution vulnerability in Microsoft Office that was disclosed and patched four years ago.

Attacks targeting a remote code execution vulnerability in Microsoft's MSHTML browser engine — which was patched last September — soared during the second quarter of this year, according to a Kaspersky analysis.

Researchers from Kaspersky counted at least 4,886 attacks targeting the flaw (CVE-2021-40444) last quarter, an eightfold increase over the first quarter of 2022. The security vendor attributed the continued adversary interest in the vulnerability to the ease with which it can be exploited.

Kaspersky said it has observed threat actors exploiting the flaw in attacks on organizations across multiple sectors including the energy and industrial sectors, research and development, IT companies, and financial and medical technology firms. In many of these attacks, the adversaries have used social engineering tricks to try and get victims to open specially crafted Office documents that would then download and execute a malicious script. The flaw was under active attack at the time Microsoft first disclosed it in September 2021.

The attacks targeting the MSHTML flaw were part of a broader set of exploit activity last quarter that overwhelmingly targeted Microsoft vulnerabilities. According to Kaspersky, exploits for Windows vulnerabilities accounted for 82% of all exploits across all platforms during the second quarter of 2022. While attacks on the MSHTML vulnerability increased the most dramatically, it was by no means the most exploited flaw.

**Old Is Gold for Threat Actors**

Kaspersky's telemetry showed far more attacks on a handful of other vulnerabilities from 2018 and 2017. One of them was CVE-2018-0802, a remote code execution (RCE) vulnerability in Microsoft Office that was attacked some 345,827 times last quarter. Another similar memory corruption flaw from 2017 (CVE-2017-11882) was targeted in 140,623 attacks while a Microsoft Office/WordPad remote code execution flaw also from 2017 (CVE-2017-0199) was involved in 60,132 attacks.

The so-called Follina vulnerability in Microsoft Support Diagnostic Tool (MSDT) (CVE-2022-30190) was among the most targeted of recent vulnerabilities. The RCE flaw was one of at least five zero-day flaws that Microsoft has disclosed this year.

In total, Kaspersky found vulnerabilities in older versions of Microsoft Office being used in attacks against more than half a million users in second quarter. The attacks are another reminder of how unpatched vulnerabilities in older technologies remain a popular and highly attractive target for threat actors, the security vendor noted. "Old versions of applications remain the main targets for attackers, with almost 547,000 users in total being affected through corresponding vulnerabilities in the last quarter," Kaspersky said.

Kaspersky's report is another reminder of why security experts advocate quick patching of Microsoft vulnerabilities. Recent data has shown attackers have gotten much faster at exploiting flaws than before. A study that Rapid7 conducted last year showed that the mean time to known exploitation for vulnerabilities in 2021 was just 12 days — a 71% decrease from 42 days in 2020. The company explained the numbers as being driven by a sharp rise in zero-day exploit activity. "A drastic reduction in time to exploitation year over year means that not only are well-worn emergency patching procedures necessary, incident response protocols are likely to require repeated use as well," Rapid7 noted at the time.

Most Q2 Attacks Targeted Old Microsoft Vulnerabilities

ZTNA brings only marginal benefits unless you ensure that the third parties you authorize are not already compromised.

The transition to a zero-trust architecture is rife with challenges that can put a 10,000-piece, monochromatic jigsaw puzzle to shame. Not only must the IT team recognize and validate every corporate employee, their computing devices, and their applications, but they also must do so for key nonemployees, third-party vendors, and partners who access corporate assets.

It is a difficult enough task when one knows who their primary third-party supply chain partners are; it becomes almost impossible to manage secondary, tertiary, and other partners as well. And therein lies the challenge of defining who is an authorized and authenticated user and who is not.

While many of today's zero-trust network access (ZTNA) products claim to offer ongoing authentication and authorization of every known and registered user, device, and application trying to access a network all the time, often what companies actually experience is slightly different, says Jason Georgi, field CTO at Palo Alto Networks. Instead of constant authentication, they get initial authentication for each access.

Today, he says, ZTNA products excel at the microsegmentation of networks and providing very limited access to corporate assets on the network, but he expects next-generation ZTNA products to provide greater security for the data being processed.

A white paper by John Grady, a senior analyst at Enterprise Strategy Group, and commissioned by Palo Alto Networks asserts that there are several areas where current ZTNA products are falling short. Among the improvements Grady called for are prevention of violations of least privilege, the ability to cancel an application's access if it starts behaving in an unanticipated or unacceptable manner after granted access, and the ability to do security inspections of data not currently being inspected.

**Reducing Third-Party Risk**

Companies working to improve their risk profile by employing ZTNA are gaining only marginal benefits if they do not ensure that the third parties they authorize are not already compromised. To accomplish this, companies moving to zero trust also need to improve their third-party risk management (TPRM).

Organizations that employ ZTNA require that remote users be entered into a Microsoft Active Directory or other authentication system. While that works well for remote employees, it falls short when the remote access user is a business partner or vendor. Because of this, these partners often need to access the corporate environment over a virtual private network (VPN). But VPNs have inherent security limitations and do not scale well. As a result, someone who uses a VPN to access corporate assets behind the corporate firewall already has more access than they require; malicious users could leverage this to attack the network from the inside.

"If you think about all the bad things that have occurred, it's always through that backdoor of a vendor connection because you have a wide-open pipe on a VPN," says Dave Cronin, vice president of cybersecurity strategy for Capgemini Americas.

But VPNs, despite having less comprehensive security than zero-trust offerings, are not going away, he cautions. A zero-trust architecture requires that every user be preauthorized within a trusted environment, such as by being listed in Microsoft Active Directory or some similar application. That will not happen when organizations have hundreds or thousands of supply chain partners who are not individually identified, authenticated, and registered.

"In a lot of cases, organizations are layering additional sets of controls around specifically the third-party access component because, in some cases, the third parties are using unmanaged devices, meaning they're using their own corporate devices or even personal devices to access a company's enterprise applications," says Andrew Rafla, a partner and principal, as well as the cyber-risk and zero trust leader, at Deloitte. "There's a greater need to shift toward more modern ZTNA or \[Secure Access Service Edge\] SASE-type solutions, specifically for third-party access."

Rafla adds that the zero-trust edge (ZTE), sometimes referred to as SASE, can be seen as a compensating control to help mitigate the potential threats brought on by third parties and other managed constituents. Such compensating controls — including edge security, TPRM, multifactor authentication, and perhaps a dozen more controls together — can help companies demonstrate that they should qualify for cyber insurance, which has become more difficult to obtain recently.

"The more agile you are able to be as an organization to enable remote workforces, the easier, generally speaking, it is for you to do the right thing for derisking third-party access to your application systems environments," says Josh Yavor, CISO at Tessian. "The reason for that is because by pushing security down to the devices and then to the application layer, it means that while the networks are absolutely still relevant and critical, we're logically building our defensive risk bubbles around the applications themselves, and then the devices and identities that are in use when accessing them.

"By separating what used to be entirely network-dependent thinking to those layers, it means that we have more granular options for enabling access securely from our third parties."

That said, while hybrid VPN and ZTNA networks are likely here to stay for the foreseeable future, VPN security needs to be enhanced by adding more authentication controls and the ability to shut down the connection should the user access inappropriate data or applications. This could include improving port and protocol controls to contain the risk.

Transitioning From VPNs to Zero-Trust Access Requires Shoring Up Third-Party Risk Management

Here's how to flip the tide and tap open source intelligence to protect your users.

Are you a fan of fitness-focused social networking apps such as Strava? You're not alone. Even military personnel enjoy tracking and sharing their runs. It sounds great, except that all activity and GPS data the Strava app collects and publishes invariably exposes the precise location of military bases.

You might be surprised to see the kind of information that's publicly available on the Internet today. But it shouldn't be a surprise, given how we live in the days of oversharing. We announce on Twitter and email auto-responses about our vacation plans, essentially inviting robbers. Security professionals call it OSINT (open source intelligence), and attackers use it all the time to identify and exploit vulnerabilities in processes, technologies, and people. OSINT data is usually easy to collect, and the process is invisible to the target. (Hence why military intelligence uses it along with other OSINT tools like HUMIT, ELINT, and SATINT.)

The good news? You can tap OSINT to protect your users. But first you'll have to understand how attackers exploit OSINT to sufficiently evaluate the scope of your attack surface and bolster your defenses accordingly.

OSINT is an age-old concept. Traditionally, open source intelligence was gathered through TV, radio, and newspapers. Today, such information exists all across the Internet, including:

· Social and professional networks like Facebook, Instagram, and LinkedIn  
· Public profiles on dating apps  
· Interactive maps  
· Health and fitness trackers  
· OSINT tools like Censys and Shodan

All this publicly available information helps people share adventures with friends, find obscure locations, keep track of medications, and find dream jobs and even soulmates. But there's another side to it as well. Unbeknownst to potential targets, this information is just as conveniently available to scammers and cybercriminals.

For instance, the same ADS-B Exchange app that you use to keep track of your loved one's flights in real-time can be exploited by malicious actors to locate their targets and craft nefarious plans.

**Understanding the Different Applications of OSINT**

Open source information isn't just available to those it is intended for. Anyone can access and utilize it, including government and law enforcement agencies. Despite being cheap and easily accessible, nation-states and their intelligence agencies use OSINT because it provides good intelligence when done right. And since it's all freely available information, it's very hard to attribute access and utilization to a single entity.

Extremist organizations and terrorists can weaponize the same open source information to collect as much data about their targets as possible. Cybercriminals also use OSINT to craft highly targeted social engineering and spear phishing attacks.

Businesses use open source information to analyze competition, predict market trends, and identify new opportunities. But even individuals perform OSINT at some point and for a variety of reasons. Whether it's Googling an old friend or a favorite celebrity, it's all OSINT.

**How to Use Multiple OSINT Techniques**

The shift to work-from-home was inevitable, but the entire process had to be expedited when COVID-19 hit. Finding vulnerabilities and data against people working from home, outside the traditional security perimeter of organizations, is sometimes just a quick online search away.

**Social networking sites****:** Cybercriminals can gather data like personal interests, past achievements, family details, and current and even future locations of employees, VPs, and executives of their target organizations. They can later use this to craft spear-phishing messages, calls, and emails.

**Google:** Malicious users can Google information such as the default passwords for specific brands and models of IT equipment and IoT devices like routers, security cameras, and home thermostats.

**GitHub:** A few naive searches on GitHub can reveal credentials, master keys, encryption keys, and authentication tokens for apps, services, and cloud resources in shared, open source code. The infamous Capital One breach is a prime example of such an attack.

**Google hacking:** Also known as Google dorking, this OSINT technique lets cybercriminals use advanced Google search techniques to find security vulnerabilities in apps, specific information about individuals, files containing user credentials, and more.

**Shodan and Censys:** Shodan and Censys are search platforms for Internet-connected devices and industrial control systems and platforms. Search queries can be refined to find specific devices with known vulnerabilities, accessible elastic search databases, and more.

**Applications of OSINT for Defense Practices**

Businesses that are already using OSINT to identify opportunities and study competitors need to widen their application of OSINT to cybersecurity.

OSINT Framework, a collection of OSINT tools, is a good starting point for enterprises to harness the power of OSINT. It helps penetration testers and security researchers discover and collect freely available and potentially exploitable data.

Tools like Censys and Shodan are primarily designed for pen-testing, too. They allow enterprises to identify and secure their Internet-connected assets.

Oversharing personal data is problematic for individuals and the organizations they work for. Enterprises should educate employees about safe and responsible social media use.

Employee cybersecurity awareness training should be, at the very least, a semi-annual undertaking. Unannounced cyberattacks and phishing simulations must be part of these training workshops.

How and Why to Apply OSINT to Protect the Enterprise

Attacked once, victimized multiple times: Data marketplaces are making it easier for threat actors to find and use data exfiltrated during ransomware attacks in follow-up attacks.

Cybercriminals and other threat actors are increasingly using data dumped from ransomware attacks in secondary business email compromise (BEC) attacks, according to new analysis by Accenture Cyber Threat Intelligence.   

The ACTI team analyzed data from the 20 most active ransomware leak sites, measured by number of featured victims, between July 2021 and July 2022. Of the 4,026 victims (corporate, non-governmental organizations, and governmental entities) uncovered on various ransomware groups’ dedicated leak sites, an estimated 91% incurred subsequent data disclosures, ACTI found.

Dedicated leak sites most commonly provide financial data, followed by employee and client personally identifiable information and communication documentation. The rise of double extortion attempts – where attack groups use ransomware to exfiltrate data and then publicize the data on dedicated leak sites – has made large amounts of sensitive corporate data available to any threat actor. The most valuable types of data most useful for conducting BEC attacks are financial, employee, and communication data, as well as operational documents. There is a significant overlap between the types of data most useful for conducting BEC attacks and the types of data most commonly posted on these ransomware leak sites, ACTI said.

The data is a “rich source for information for criminals who can easily weaponize it for secondary BEC attacks,” ACTI said. “The primary factor driving an increased threat of BEC and VEC attacks stemming from double-extortion leaks is the availability of \[corporate and communication data\].”

    

There is overlap between available disclosed data and such data’s usefulness for BEC attacks.

Data thieves are making it easier for their customers to find and access the stolen information. The dedicated leak sites are increasingly available on publicly accessible sites, not hidden away on Tor domains, and some offer searchable indexed data to make it easier for threat actors to find what they need for their attacks.

For example, the operators of the data-selling marketplace Industrial Spy organize and name folders with labels that reflect their content to make finding specific files easy, ACTI said. Customers can use the marketplace’s search functionality to find specific files, such as employee data, invoices, scans, contracts, legal documents, and email messages. The search can also hunt for data from specific industries and countries.

“Indexed and searchable databases like these help actors more efficiently acquire specific data versus downloading bulk data and hoping to find desired information,” ACTI said.

Cybercriminals Weaponizing Ransomware Data for BEC Attacks

Duston Childs and Brian Gorenc of ZDI take the opportunity at Black Hat USA to break down the many vulnerability disclosure issues making patch prioritization a nightmare scenario for many orgs.

BLACK HAT USA – Las Vegas – Keeping up with security-vulnerability patching is challenging at best, but prioritizing which bugs to focus on has become more difficult than ever before, thanks to context-lacking CVSS scores, muddy vendor advisories, and incomplete fixes that leave admins with a false sense of security.

That's the argument that Brian Gorenc and Dustin Childs, both with Trend Micro's Zero Day Initiative (ZDI), made from the stage of Black Hat USA during their session, "Calculating Risk in the Era of Obscurity: Reading Between the Lines of Security Advisories."

ZDI has disclosed more than 10,000 vulnerabilities to vendors across the industry since 2005. Over the course of that time, ZDI communications manager Childs said that he's noticed a disturbing trend, which is a decrease in patch quality and reduction of communications surrounding security updates.

"The real problem arises when vendors release faulty patches, or inaccurate and incomplete information about those patches that can cause enterprises to miscalculate their risk," he noted. "Faulty patches can also be a boon to exploit writers, as 'n-days' are much easier to use than zero-days."

**The Trouble With CVSS Scores & Patching Priority**

Most cybersecurity teams are understaffed and under pressure, and the mantra "always keep all software versions up-to-date" doesn't always make sense for departments who simply don’t have the resources to cover the waterfront. That's why prioritizing which patches to apply according to their severity rating in the Common Vulnerability Severity Scale (CVSS) has become a fallback for many admins.

Childs noted, however, that this approach is deeply flawed, and can lead to resources being spent on bugs that are unlikely to ever be exploited. That's because there's a host of critical information that the CVSS score doesn't provide.

"All too often, enterprises look no further than the CVSS base core to determine patching priority," he said. "But the CVSS doesn't really look at exploitability, or whether a vulnerability is likely to be used in the wild. The CVSS doesn't tell you if the if the bug exists in 15 systems or in 15 million systems. And it doesn't say whether or not it's in publicly accessible servers."

He added, "And most importantly, it doesn't say whether or not the bug is present in a system that's critical to your specific enterprise."

Thus, even though a bug might carry a critical rating of 10 out of 10 on the CVSS scale, it's true impact may be much less concerning than that critical label would indicate.

"An unauthenticated remote code execution (RCE) bug in an email server like Microsoft Exchange is going to generate a lot of interest from exploit writers," he said. "An unauthenticated RCE bug in an email server like Squirrel Mail is probably not going to generate as much attention."

To fill in the contextual gaps, security teams often turn to vendor advisories – which, Childs noted, have their own glaring problem: They often practice security through obscurity.

**Microsoft Patch Tuesday Advisories Lack Details**

In 2021, Microsoft made the decision to remove executive summaries from security update guides, instead informing users that CVSS scores would be sufficient for prioritization – a change that Childs blasted.

"The change removes the context that's needed to determine risk," he said. "For example, does an information-disclosure bug dump random memory or PII? Or for a security-feature bypass, what is being bypassed? The information in these writeups is inconsistent and of varying quality, despite near universal criticism of the change."

In addition to Microsoft either "removing or obscuring information in updates that used to produce clear guidance," it's also now more difficult to determine basic Patch Tuesday information, such as how many bugs are patched each month.

"Now you have to count yourself, and it's actually one of the hardest things I do," Childs noted.

Also, the information about how many vulnerabilities are under active attack or publicly known is still available, but buried in the bulletins now.

"As an example, with 121 CVEs being patched this month, it's kind of hard to dig through all of them to look for which ones are under active attack," Childs said. "Instead, people now rely on other sources of information like blogs and press articles, rather than what should be authoritative information from the vendor to help determine risk."

It should be noted that Microsoft has doubled down on the change. In a conversation with Dark Reading at Black Hat USA, the corporate vice president of Microsoft's Security Response Center, Aanchal Gupta, said the company has consciously decided to limit the information it provides initially with its CVEs to protect users. While Microsoft CVEs provide information on the severity of the bug, and the likelihood of it being exploited (and whether it is being actively exploited), the company will be judicious about how it releases vulnerability exploit information, she said.

The goal is to give security administrations enough time to apply the patch without jeopardizing them, Gupta said. "If, in our CVE, we provided all the details of how vulnerabilities can be exploited, we will be zero-daying our customers," she said.

**Other Vendors Practice Obscurity**

Microsoft is hardly alone in providing scant details in bug disclosures. Childs said that many vendors don't provide CVEs at all when they release an update.

"They just say the update fixes several security issues," he explained. "How many? What's the severity? What's the exploitability? We even had a vendor recently say to us specifically, we do not publish public advisories on security issues. That's a bold move."

In addition, some vendors put advisories behind paywalls or support contracts, further obscuring their risk. Or, they combine multiple bug reports into a single CVE, despite the common perception that a CVE represents a single unique vulnerability.

"This leads to possibly skewing your risk calculation," he said. "For instance, if you look at buying a product, and you see 10 CVEs that have been patched in a certain amount of time, you may come up with one conclusion of the risk from this new product. However, if you knew those 10 CVEs were based on 100+ bug reports, you might come to a different conclusion."

**Placebo Patches Plague Prioritization**

Beyond the disclosure problem, security teams also face troubles with the patches themselves. "Placebo patches," which are "fixes" that actually make no effective code changes, are not uncommon, according to Childs.

"So that bug is still there and exploitable to threat actors, except now they've been informed of it," he said. "There are many reasons why this could happen, but it does happen – bugs so nice we patch them twice."  

There are also often patches that are incomplete; in fact, in the ZDI program, a full 10% to 20% of the bugs researchers analyze are the direct result of a faulty or incomplete patch.

Childs used the example of an integer overflow issue in Adobe Reader leading to undersized heap allocation, which results in a buffer overflow when too much data is written to it.

"We expected Adobe to make the fix by setting any value over a certain point to be bad," Childs said. "But that's not what we saw, and within 60 minutes of the rollout, there was a patch bypass and they had to patch again. Reruns aren't just for TV shows."

**How to Combat Patch Prioritization Woes**

Ultimately when it comes to patch prioritization, effective patch management and risk calculation boils down to identifying high-value software targets within the organization as well as using third-party sources to narrow down which patches would be the most important for any given environment, the researchers noted.

However, the issue of post-disclosure nimbleness is another key area for organizations to focus on.

According to Gorenc, senior director at ZDI, cybercriminals waste no time integrating vulns with large attack surfaces into their ransomware tool sets or their exploit kits, looking to weaponize newly disclosed flaws before companies have time to patch. These so-called n-day bugs are catnip to attackers, who on average can reverse-engineer a bug in as little as 48 hours.

"For the most part, the offensive community is using n-day vulnerabilities that have public patches available," Gorenc said. "It's important for us to understand at disclosure if a bug is actually going to be weaponized, but most vendors do not provide information regarding exploitability."

Thus, enterprise risk assessments need to be dynamic enough to change post-disclosure, and security teams should monitor threat intelligence sources to understand when a bug is integrated into an exploit kit or ransomware, or when an exploit is released online.

Ancillary to that, an important timeline for enterprises to consider is how long it takes to actually roll out a patch across the organization, and whether there are emergency resources that can be brought to bear if necessary.

"When changes occur to the threat landscape (patch revisions, public proof-of-concepts, and exploit releases), enterprises should be shifting their resources to meet the need the need and combat the latest risks," Gorenc explained. "Not just the latest publicized and named vulnerability. Observe what's going on in the threat landscape, orient your resources, and decide when to act."

Patch Madness: Vendor Bug Advisories Are Broken, So Broken

GitHub, the owner of the Node Package Manager (npm), proposes cryptographically linking source code and JavaScript packages in an effort to shore up supply chain security.

Organizations hosting significant parts of the open source software supply chain continue to adopt security measures that give developers and maintainers more tools to harden their projects against attacks and malicious code commits.

On Monday, GitHub announced that the company — which owns and maintains the Node Package Manager (npm) service — had called for developers to comment on a plan to adopt sigstore, which simplifies the signing of code components produced by projects as well as linking them back to the source code. The sigstore project has made digitally signing source code easier because individual maintainers no longer have to manage their own cryptographic infrastructure.

The technology service allows software developers to confirm what code has been used to generate a particular software application or component, says Brian Behlendorf, general manager of Open Source Security Foundation (OpenSSF), which maintains sigstore with the Linux Foundation.

"The assembly of components into software platforms and applications — all of that has been done with the same kind of security we had on the Internet before TLS \[Transport Layer Security\], frankly," he says. "We depended on a not necessarily misplaced but  high degree of trust that the infrastructure just did things for us or that there were not bad actors out there."

The proposal is the latest effort to make tools available to developers to secure the software supply chain. GitHub's npm, the Python Package Index (PyPI), and others have already urged developers to adopt two-factor authentication (2FA) to secure their accounts to prevent a compromise through a simple credential-based attack. GitHub, for example, has already moved the top 500 most-popular npm projects to 2FA and plans to require the security technology for any project with more than a million downloads per week.

Adopting digital signing of software packages is another critical step. In March, software security firm Sonatype announced it had "every intent to adopt sigstore as part of the Maven Central platform." Maven is the most popular source of Java software components and is maintained by Sonatype. PyPI has a specification called The Update Framework (TUF) that calls for digital signing of software packages, and the repository has a sigstore module under development.

The ability to attest that a program or executable came from a certain source code repository is an important step in securing the software supply chain, Justin Hutchings, director of project management for GitHub's security features, wrote in the blog post.

"When package maintainers opt-in to this system, consumers of their packages can have more confidence that the contents of the package match the contents of the linked repository," Hutchings said. "Historically, linking packages back to the source code has been difficult because it required individual projects to register and manage their own cryptographic keys."

GitHub acquired the Node Package Manager (npm) in 2020.

**SBOMs and "Salsa"**

The ability to sign code is fundamental to supply chain security. For example, a software bill of materials (SBOM) is a way to communicate to developers and security tools the components that make up a software project. Determining what software components and libraries are used in modern software projects is not always straightforward. Already, the US government has created requirements that any software sold to a federal agency needs to have an SBOM, but only a third of companies currently use SBOMs.

Another initiative, the Supply Chain Levels for Software Artifacts (SLSA), pronounced "salsa," provides developers and application security managers with a road map for securing software projects and communicating the software provenance.

"You need to have integrity, and you need to understand the quality — SLSA is really around that integrity part," says Kim Lewandowski, one of the original creators of SLSA and a co-founder at Chainguard, a software security firm. "A developer knows they're getting this piece of software that is built around these dependencies and these are the \[software\] artifacts that went into it."

Sigstore works because the technology makes signing code much easier for developers. OpenSSF's Behlendorf likens the platform to the Let's Encrypt service, which makes the keys for securing websites freely available and easy to deploy. Making any security technology easy to use is critical, he says.

"Greater security in open source software is going to come, not just by helping people write better code," he says. "It is not just going to come from a lot of people finding zero-days, and getting those fixed and fixes pushed out. It is going to come from having tooling that will make having better security throughout the supply chain a 'zero lift' for developers. If they even have to have a feature flag turned on, that is too much."

Software Supply Chain Chalks Up a Security Win With New Crypto Effort

Unusually, SOVA, which targets US users, now allows lateral movement for deeper data access. Version 5 adds an encryption capability.

The Android banking Trojan SOVA is back and sporting updated capabilities — with an additional version in development that contains a ransomware module.  

Researchers at Cleafy, which documented the resurgence of SOVA, say that version 4 appears to be targeting more than 200 mobile applications, including banking apps and crypto exchanges/wallets. Spain appears to be the country most targeted by the malware, followed by the Philippines and the US.

The SOVA v4 malware is hidden within fake Android applications disguised by the logos of popular apps including Chrome and Amazon. The latest version includes a refactored and improved cookie-stealer mechanism, which can now specify a list of targeted Google services and other applications. In addition, the update allows the malware to protect itself by intercepting and deflecting attempts made by victims to uninstall the app.

Also in the latest versions of SOVA, attackers can control the specific targets via the command-and- control (C2) interface. This increases the adaptability of the malware to a large variety of attack scenarios.

In addition, it has capabilities that allow attackers to grab screenshots, and to record and execute commands. This enables an attacker to look for ways to laterally move around to other systems or applications that might be more lucrative.

"The most interesting part is related to the \[virtual network computing\] capability," the report notes. "This feature has been in the SOVA roadmap since September 2021 and that is strong evidence that \[threat actors\] are constantly updating the malware with new features and capabilities."

**Ransomware on the Horizon**

The Cleafy team also found evidence that suggested that an additional version of the malware, version 5, is in development and will include a ransomware module that had previously been announced in a September 2021 development roadmap.

"The ransomware feature is quite interesting as it’s still not a common one in the Android banking-trojan landscape," Cleafy researchers note. "It strongly leverages on the opportunity that has arisen in recent years, as mobile devices became for most people the central storage for personal and business data."

Cory Cline, senior cyber security consultant at nVisium, says that adding ransomware capabilities to a banking Trojan offers plenty of upside to cybercriminals.

"No longer do they need to steal your personal data to get access to your financial information," he explains. "With ransomware capabilities, attackers can now encrypt affected devices."

He adds that with more and more people storing nearly every aspect of their lives on their mobile devices, attackers will be able to more easily find targets willing to pay to get access to their data returned.

"The team behind SOVA has demonstrated a new level of sophistication," he says. "The feature set is fairly unique to the Android banking Trojan scene, and SOVA is one of the most feature-rich Android banking Trojans available."

However, he points out that the team behind SOVA has opted to implement RetroFit for C2 as opposed to writing its own solution.

"This could speak to some limitations in the development team," Cline says.

**Banking Trojans Get Boost From Added Capabilities**

Other banking Trojans have also resurfaced with updated features to help skate past security, including Emotet, which re-emerged earlier this summer in a more advanced form after having been taken down by joint international task force in January 2021.

Joseph Carson, chief security scientist and Advisory CISO at Delinea, says that improving and evolving existing Android banking Trojans has many advantages.

"The significant improvements to SOVA v4 and SOVA v5 show that attackers can simply expand existing features such as the cookies stealer, which now includes more payment services and applications to exploit," he points out. "New modules such as those targeting cryptowallets demonstrate that attackers see cryptocurrencies as a lucrative target."

He explains that adding ransomware capabilities can have multiple advantages for attackers, such as destroying evidence. That makes it difficult for digital forensics to discover any traces or attribution of the attacker, and gives the attacker an additional option to get paid when stealing credentials or cookies is not successful.

"As new Internet services specifically in the financial industry get adopted," Carson says, "attackers will need to keep updating banking Trojans with new modules just like any other software company to stay compatible with newer technologies."

Novel Ransomware Comes to the Sophisticated SOVA Android Banking Trojan

Back-end complexity of cloud computing means there's plenty of potential for security problems. Here's how to get a better handle on SaaS application security.

Many security practitioners take their eye off cloud and software-as-a-service (SaaS) security based on the faulty assumption that the providers are inherently secure. While most providers are, the cloud is so flexible and customizable that every organization might open different doors – ones that they're responsible for closing. Ones that traditional security tools often overlook.

Some 89% of organizations have a multicloud strategy, with 48% using multiple public and private clouds. By the end of 2021, it was estimated that 99% of organizations would be using one or more SaaS solutions. With so many resources now in the cloud, it's a complex responsibility to secure each one.

Security risks continue to plague organizations. According to Varonis' "2021 SaaS Risk Report," 44% of cloud user privileges are misconfigured and 43% of all cloud identities are unused and exposed to threats. By rightsizing your cloud footprint, adopting new security controls, and emphasizing SaaS security management, you can be confident enough in your security to achieve cloud nirvana – security that's so automated, intuitive, and frictionless that you never have to think about it. There are three phases to getting there.

**Understand Your Cloud Footprint**

You must take a strategic view of cloud security. The first step is to undertake an inventory to find what SaaS services are in use. Which business areas are dependent on what SaaS services? Which SaaS services are common across the enterprise?

Then create an inventory focused on where your most sensitive data is. What information is leaving your applications or being exchanged with other applications? The next question is: Which users, resources, and applications have access to your data? Only once you understand your cloud footprint, data in the cloud, and resources accessing it, can you work to secure it.

Make no mistake: cloud and SaaS sprawl are difficult to audit. According to Productiv's recent report, the average SaaS portfolio size is 254 applications but only 45% of those apps are used on a regular basis. Taking that deep dive and reflecting on the business purposes of those apps may identify some ways to reduce your organization's overall risk (and your SaaS spend). Auditing your cloud footprint is important so that you have a clear picture of your risk, and so you can ensure you're meeting compliance, regulatory, and customer obligations.

Before you can start chipping away at the inhibitors of SaaS security, you need to make sure you're covering all your bases. Does your security scope include management of third-party applications and data? What about any necessary compliance or regulatory policies for checking misconfigurations and anomalies? While most companies stop there, it's important to have deep security coverage for your most business-critical SaaS applications, including threat detection and continuous monitoring.

**Protect Your Cloud Footprint**

Once you understand your cloud footprint, and where most sensitive data is, you need to assess whether your data is protected. Are appropriate security controls in place to ensure all applicable layers of encryption and masking? Are only appropriate people able to access sensitive data? Are configurations being scanned on a regular basis to detect misconfigurations and, more importantly, are those misconfigurations being remediated in a timely manner?

You need to define security controls to protect the data and configurations. Once you've defined security controls, you need to replicate the process for the multitude of SaaS vendors you're working with across your ecosystem.

In addition to, say, Microsoft 365, you probably also have some combination of Workday, Salesforce, ServiceNow, Atlassian, and potentially dozens of other applications that keep your business running. Interestingly, the Productiv report shows an inverse relationship between the size of an organization and its application engagement. Smaller organizations, according to the report, engage with 49% of apps while enterprises only use 39%.

The fragmentation of the SaaS market means that not only do you have multiple vendors to consider, but they all operate based on different standards and with different levels of security. Unfortunately, there's no common framework for SaaS security.

The Center for Internet Security (CIS) has developed critical controls for the cloud, but they haven't yet become so widely adopted that they provide consistency across the entire industry. For now, you need visibility into the security of each SaaS application.

**Cloud Nirvana: Eliminate the Need to Think About Security**

Getting closer to cloud nirvana means finding efficiency as the cloud continues to scale. SaaS leads the way in the expansion of cloud adoption, with end-user spending expected to hit more than $176 billion this year, according to Gartner, and increase nearly 18% next year.

Adhering to the industry standard framework like CIS controls will make for a clearer picture of your SaaS security, but there's even more you can do. By adopting a DevSecOps structure, you involve security teams at the beginning of the development lifecycle so there are no surprises or delays down the road.

Reaching true cloud nirvana, though, typically comes through SaaS security management that can monitor, detect, and protect against threats. This includes automating security for instant visibility, 24/7 monitoring, and alerts for common SaaS security risks like misconfigured data access, overly broad permissions for user accounts, and exposed data.

How to Clear Security Obstacles and Achieve Cloud Nirvana

The head of Microsoft's Security Response Center defends keeping its initial vulnerability disclosures sparse — it is, she says, to protect customers.

BLACK HAT USA — Las Vegas — A top Microsoft security executive today defended the company's vulnerability disclosure policies as providing enough information for security teams to make informed patching decisions without putting them at risk of attack from threat actors looking to quickly reverse-engineer patches for exploitation.

In a conversation with Dark Reading at Black Hat USA, the corporate vice president of Microsoft's Security Response Center, Aanchal Gupta, said the company has consciously decided to limit the information it provides initially with its CVEs to protect users. While Microsoft CVEs provide information on the severity of the bug, and the likelihood of it being exploited (and whether it is being actively exploited), the company will be judicious about how it releases vulnerability exploit information.

For most vulnerabilities, Microsoft's current approach is to give a 30-day window from patch disclosure before it fills in the CVE with more details about the vulnerability and its exploitability, Gupta says. The goal is to give security administrations enough time to apply the patch without jeopardizing them, she says. "If, in our CVE, we provided all the details of how vulnerabilities can be exploited, we will be zero-daying our customers," Gupta says.

**Sparse Vulnerability Information?**

Microsoft — as other major software vendors — has faced criticism from security researchers for the relatively sparse information the company releases with its vulnerability disclosures. Since Nov. 2020, Microsoft has been using the Common Vulnerability Scoring System (CVSS) framework to describe vulnerabilities in its security update guide. The descriptions cover attributes such as attack vector, attack complexity, and the kind of privileges an attacker might have. The updates also provide a score to convey severity ranking.

However, some have described the updates as cryptic and lacking critical information on the components being exploited or how they might be exploited. They have noted that Microsoft's current practice of putting vulnerabilities into an "Exploitation More Likely" or an "Exploitation Less Likely" bucket does not provide enough information to make risk-based prioritization decisions.

More recently, Microsoft has also faced some criticism for its alleged lack of transparency regarding cloud security vulnerabilities. In June, Tenable's CEO Amit Yoran accused the company of "silently" patching a couple of Azure vulnerabilities that Tenable's researchers had discovered and reported.

"Both of these vulnerabilities were exploitable by anyone using the Azure Synapse service," Yoran wrote. "After evaluating the situation, Microsoft decided to silently patch one of the problems, downplaying the risk," and without notifying customers.

Yoran pointed to other vendors — such as Orca Security and Wiz — that had encountered similar issues after they disclosed vulnerabilities in Azure to Microsoft.

**Consistent with MITRE's CVE Policies**

Gupta says Microsoft's decision about whether to issue a CVE for a vulnerability is consistent with the policies of MITRE's CVE program.

"As per their policy, if there is no customer action needed, we are not required to issue a CVE," she says. "The goal is to keep the noise level down for organizations and not burden them with information they can do little with."

"You need not know the 50 things Microsoft is doing to keep things secure on a day-to-day basis," she notes.

Gupta points to last year's disclosure by Wiz of four critical vulnerabilities in the Open Management Infrastructure (OMI) component in Azure as an example of how Microsoft handles situations where a cloud vulnerability might affect customers. In that situation, Microsoft's strategy was to directly contact organizations that are impacted.

"What we do is send one-to-one notifications to customers because we don't want this info to get lost," she says "We issue a CVE, but we also send a notice to customers because if it is in an environment that you are responsible for patching, we recommend you patch it quickly."

Sometimes an organization might wonder why they were not notified of an issue — that's likely because they are not impacted, Gupta says.

Source

DARKReading