The era of digital trust is broken, and constant vigilance is needed to get things back on track.

Most of the attention paid to cybersecurity by practitioners and the general public alike is to threats that are external, such as attackers and scammers acting individually or as part of a larger organization. But a pair of stories this month alleging insider abuse at Meta and Twitter have served as harsh reminders that sometimes the call is coming from inside the house.

Reportedly, employees at both companies have recently used internal workarounds or private channels to sell access to platforms and verification, in some instances for bribes, creating a precarious and unmoderated black market for people who have already been denied re-entry to the platforms by official mechanisms. Twitter employees, Elon Musk appeared to imply in a tweet shortly after taking over as CEO of the company, may have sold verification status to users off the books for as much as $15,000. The Wall Street Journal, meanwhile, reported that more than two dozen employees and third-party contractors at Meta abused an internal account recovery tool to restore accounts for people who otherwise had no recourse to recover an account.

Though some of the employees allegedly might have capitalized on their internal access to help a family member or a friend who lost their account, it's not outside the realm of possibility that a well-informed threat actor (nation-state or otherwise) could take advantage of the workaround to gain access to Facebook or Twitter, or even leverage their connection to an employee to gain access to company secrets.

Once active on the platform through their connection to a Meta employee, an attacker has free rein to continue their scams unabated. And if an employee is already abusing an internal mechanism to enable account recovery, they probably also have a dollar figure that they would accept in return for access to deeper company information or credentials, and not necessarily through their own free will.

**Employees as Unintentional Threats**

Employees who may think they're doing the right thing — with a little monetary incentive — by helping people bypass Meta's dead-end customer service ecosystem might unknowingly elevate attackers posing as normal users. Rising inflation over the past several months in the United States has also likely pushed employees everywhere — not just at Meta or Twitter — to be more susceptible to offers of extra cash or cryptocurrency in exchange for simply doing their job. Not all insider threats are created equal, but two of the world's largest social media firms seem to have enabled employees to become both active insider and unintentional insider threats.

Of course, the fact that employees at Meta and Twitter had the motivation to become insider threats isn't surprising. Insider threats, double agents, and moles existed in security modeling long before the cybersecurity industry was born. But that the black market behavior at Meta and Twitter was allegedly widespread and unchecked is another sign that the ability to trust anyone or anything online is diminishing rapidly, especially on Twitter, where Musk has disassembled and reassembled the company's previously longstanding verification system several times in just a few weeks.

At both companies, employees were allegedly abusing their privilege and access, but using the mechanisms to offer verification and account recovery as they were designed. When you leave the onus of security and proper data protection to the end user, bad things happen. Because while companies may have the best intentions and believe staff to be trustworthy and dependable, in a mature threat model, virtually every employee is an insider threat — especially when they can act through unmonitored channels.

**Digital Trust Is Broken**

And reversing this trend isn't a simple fix. Managing and mitigating the risks involved with providing staff the tools they need to do their job — in this case, account administrators and recovery mechanisms — necessarily means granting access to confidential data and credentials, which can be abused by anybody with the right savviness and determination.

One way companies try to avoid this is through data loss prevention programs that send out an alert when data is exfiltrated through email or a USB, or when privileged programs or locations are accessed too frequently or at unusual times. Some companies will go so far as to monitor internal communications to find disruptive behavior, as Musk has reportedly done at Twitter since taking over.

The reality is that both organizations and consumers should begin to act as if the era of digital trust is broken. If years-old systems meant to verify the authenticity of users and keep attackers at bay are being misused within an organization, then customers cannot log in with absolute certainty that their personal information won't be abused as well.

That doesn't mean users should quit these platforms immediately and go back to snail mail. But it should serve as a wake-up call to organizations that constant vigilance is the only way to ensure threats don't go unchecked, whether they're internal or external.

Are Meta and Twitter Ushering in a New Age of Insider Threats?

Dark Reading's Kelly Jackson Higgins explains the enormous legacy left behind by Dan Kaminsky and his seminal "Great DNS Vulnerability" talk at Black Hat 2008.

He was one of the good guys.

The late, great Dan Kaminsky offered many big moments in Black Hat history, none more enormous than his reveal at Black Hat 2008 with his "Great DNS Vulnerability" presentation, where he showed up on roller skates and explained why the entire Internet was at risk and open to cyberattack.

Besides deciding to share this monumental find with the cybersecurity community and helping steer some of the best minds of the time to produce a fix, Kaminsky represented a kinder, gentler side of infosec that put people and their security first. 

To wit: He developed the DanKam augmented reality for a colorblind friend, and hearing aids for this grandmother, who made regular appearances at Black Hat as well, with plates of homemade cookies to share with everyone.

Dark Reading's editor-in-chief, Kelly Jackson Higgins, tells the story of that seismic DNS day in 2008, and all that Dan Kaminsky meant to the cybersecurity community, in this first installment of our new series, "Black Hat Flashback." 

On a regular basis, editors from Dark Reading will reminisce about some of the major Black Hat moments in history that changed the game forever.

Take a look, then watch Dan Kaminsky in action giving a keynote speech at Black Hat 2016.

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

Subscribe

Black Hat Flashback: The Day That Dan Kaminsky Saved the Internet

There are a few reasons that the topic of API security has been popping up more and more as 2022 comes to a close.

Back in July 2021, Gartner predicted that by 2022, application programming interface (API) attacks will become the most frequent attack vector, causing data breaches for enterprise web applications.

Was the analyst firm right? It's too early to know for sure since OWASP is still tallying the results.

API attacks are back in the news. It turns out the likely ingress point for the Optus breach was a lowly REST API. And someone has leaked all of the data stolen from the Twitter breach — which also involved an API.

When we talk about API security, we're referring to the measures and practices that we use to secure APIs and the data they transmit. We might be worried about unauthorized access, adverse reaction to a DDoS (more than one API has fallen over and left the underlying system wide open and completely insecure), or other malicious attacks.

There's an art to securing APIs; a light touch and a delicate combination of technical and organizational skills are required to do it right.

On the technical side we’re looking at measures such as authentication and authorization, encryption, automated testing, and monitoring. On the organizational side, you need to know exactly who in the org chart the API was designed to serve, and tailor access accordingly. For external APIs, you need to know how much data should be available to the outside world, and how that data needs to be curated and presented.

**How Are APIs Protected?**

There's a sane order of operations when you're trying to secure your company's APIs.

First, find and catalog every API. The number of companies that actually do this and keep their API inventory up to date is small indeed. Developer convenience, rapid website development, and the increasing push towards federated services all contribute to mystery APIs popping up out of the blue without any kind of compulsory registration structure in place.

To avoid this kind of API creep, every single one of them should be registered centrally with the following information:

*   Name
*   Tools and packages used to build the API
*   Servers that it runs on
*   Services that rely on that API
*   Documentation of all valid uses and error codes
*   Typical performance metrics
*   Expected uptime or downtime windows

All of this information goes into a repository run by the cybersecurity team.

Second, set up security and performance automation for every API. This is why you asked for all of that information, and this is how you keep everything secure. Using the data provided by the developers (and DevOps team, the Web team, etc.), the cybersecurity and/or testing team can put together automation that tests the API regularly.

Functional tests are important because they make sure that everything is working as expected. Non-functional tests are important because they probe the reliability and security of the API. Remember that APIs must fail securely. It isn't enough to know that one has fallen over — you need to know the consequences of that failure.

Finally, add the API to the normal threat prevention suite. If any of the tools or packages used to build the API are found to be buggy, you need to know. If any of the protocols that it uses are deemed insecure when you do detect trouble, you need to have the team shut the APIs down until they can be examined and rebuilt.

Doing these things once is great; creating a programming and security culture that allows you to maintain fully cataloged and documented APIs is the long-term goal.

**Specific API Behaviors to Note**

When pen testing and securing an API, some techniques are more useful than others.

1.  **Start with behavioral analysis.** This tests whether or not the reality matches the documentation in terms of the level of access granted, the protocols and ports used, the results of successful and unsuccessful queries, and what happens to the system as a whole when the API itself stops functioning.
2.  **Next is service levels.** This involves the priority of the process itself on the server, rate limiting for transactional APIs, minimum and maximum request latency settings, and availability windows. Some of these details are important for DDoS prevention (or blunting). Others are useful to monitor whether there are any slow memory leaks or garbage collection issues that might be a long-term threat to the integrity of the server itself.
3.  **Authentication and sanitation issues** speak directly to the level of trust you have for the API's users. As you would with any service, queries need to be sanitized before they're accepted. This prevents code injection, buffer overflows, and the like.

There needs to be some level of authentication with APIs that are designed for a specific user base. However, this can get complex. Federation is one issue that you need to deal with, determining which central identification and authentication servers you'll accept. You might want to have two-factor authentication for particularly sensitive or powerful APIs. And of course authentication itself isn't necessarily a password these days; biometrics is a valid way to wall off an API. To make a long story short: Apply the standards that you find reasonable, and test the limitations that you've set on a regular basis.

Finally, encryption and digital signatures need to be part of the conversation. If it's on the Web, then we're talking about TLS at minimum (repeat the mantra: We don't REST without TLS!). Other interfaces also need encryption, so pick your protocols wisely. Remember that the static information, be it a database or a pool of files somewhere, also needs to be encrypted. No flat text files anywhere, no matter how "innocent"; salt and hash should be the standard. And checksums are a must when providing or receiving files that are known entities (size, contents, etc.).

Finally, key management can be difficult to get right. Don't expect every DevOps person to have perfect digital key implementation when a decent portion of the cybersecurity folks are half-assing it themselves. When in doubt, go back to the OWASP Cheat Sheet! That's what it's there for.

**Responding to an API Attack**

The cardinal rule is: If your API is going to fail, pinch off access. Under no circumstance should services fail in an open or accessible state. Remember to rate-limit and keep error messages short and generic. Don't worry about honey pots or API jails — worry about survival.

Custom-crafted API attacks on an individual basis need to be treated like any other breach attempt. Whether you caught the attempt yourself or via AI/ML analysis, follow your SOP. Don't cut corners because it's "just" an API.

API security separates the mediocre CISO who focuses solely on infrastructure from the masterful CISO who addresses actual business threats and ensures survivability. Create a system for API security, create reusable interface testing automation, and keep your API inventory up to date.

API Security Is the New Black

The effectiveness of attacks largely depends on organizations' distributed denial-of-service defenses.

As Russian ground troops prepared to enter Ukraine in February 2021, Ukrainian governmental departments, online media organizations, financial firms, and hosting providers were slammed with a surge of distributed denial-of-service (DDoS) attacks. These attacks only increased in frequency and impact as Russian tanks rolled across the border, adding to the frenzy and chaos of that time.

Quick to hit back, Ukraine's IT Army sprang to life during the early days of the conflict. Much like Ukraine's volunteer army on the ground, recruits flooded in from all over the world to take part in the brewing war being waged online between Russia and Ukraine, with observed DDoS attacks focused on Russian targets increasing by 236% between February and March.

What seems clear is that whether issued by hacktivists or nation-states, DDoS attacks are often the opening salvo between opposing forces in today’s geopolitical conflicts. Compared with other types of cyberthreats, DDoS attacks can be launched relatively quickly. In addition, while DDoS attacks can cause significant disruption on their own, they can also mask or distract attention from more significant threats.

And, as seen in Ukraine and elsewhere, the use of DDoS attacks on the digital battlefield seems to be increasing. This article will examine the history of DDoS attacks for geopolitical conflict compared with recent attacks, providing insights that organizations can use to protect themselves from collateral damage.In summary, events during the last year have proven that DDoS attacks — whether launched by nation-states, ideological groups, or rogue individuals — will not diminish any time soon. DDoS remains an effective tool for disrupting networks and degrading the morale of countries embroiled in sociopolitical upheaval, with new attacks happening every day. To stay protected in this time of war and geopolitical conflict, organizations must remain vigilant in their defense.

**2022: A Record-Setting Year for DDoS**

The use of DDoS attacks to gain geopolitical advantage is nothing new, but the frequency at which these types of attacks are growing is noteworthy. In the latest "DDoS Threat Intelligence Report," Netscout reported more than 6 million attacks in the first half of 2022. Of these attacks, a majority corresponded with national or regional conflicts.

To continue with the Ukraine example, the frequency of DDoS attacks directed at Ukraine leveled off by April 2022, while cyberattacks ratcheted up against perceived allies of Ukraine. This likely is attributable to Ukrainian Internet properties migrating to countries like Ireland, as instability in the intra-Ukraine Internet forced many network segments to rely upon connectivity in other countries.

Echoes of this conflict continue to resonate across the global Internet. In March 2022, India experienced a measurable increase of DDoS attacks following its abstentions from United Nations Security Council and General Assembly votes condemning Russian actions in Ukraine. Similarly, during the first half of the year, Belize endured its single highest number of DDoS attacks on the same day that it made public statements in support of Ukraine.

Elsewhere, the nation of Finland — a close neighbor of Russia — experienced a 258% percent year-over-year increase in DDoS attacks coinciding with its announcement to apply for membership in NATO. Poland, Romania, Lithuania, and Norway, meanwhile, all were targeted with DDoS attacks by adversaries linked to Killnet, a group of online attackers aligned with Russia.

But these examples rooted in the conflict between Russia and Ukraine are not the only online battlegrounds where fights over geopolitics are being waged. As tensions between Taiwan and China and Hong Kong and China escalated during the first half of the year, DDoS attack campaigns often coincided with public events. For example, in the run-up to Nancy Pelosi's historic visit to Taiwan this summer, the website of Taiwan's presidential office and other government websites went dark due to DDoS attacks. And in Latin America, during a contentious election in Colombia this past year, waves of successive DDoS attacks were launched during the initial vote and the contested runoff.

One common thread is that many of these attacks use known attack vectors and readily available DDoS-for-hire services, also known as booter/stressor services, found on the Dark Web. These illicit services typically offer a restricted tier of free demonstration DDoS attacks to prospective customers, lowering the bar for would-be attackers to rapidly spin up attacks at very little to no cost. However, because these attack vectors are well-known, they can be easily mitigated in most circumstances.

**Don't Become Collateral Damage**

DDoS attacks have the potential to seriously disrupt Internet operations for their intended targets, but they can also cause a significant collateral impact footprint for bystander organizations and Internet traffic. This risk is particularly high as data hosting and services flow from war-torn regions like Ukraine to locations abroad.

In many of the examples listed above, the effectiveness of attacks largely depended upon whether targeted organizations had organized DDoS defenses. In Ukraine and other countries, disruption was quickly remedied for unprotected organizations as global DDoS defense companies stepped in to help Ukrainian organizations that needed it. However, ongoing defenses are still needed for most organizations.

Amid this environment, the most prudent course of action to prevent collateral damage is to regularly assess DDoS risk factors, especially related to direct service delivery elements, supply chain partners, and other dependencies. Organizations should ensure that critical public-facing servers, services, applications, content, and supporting infrastructure are adequately protected. They also should check to make sure DDoS defense plans reflect ideal current configurations and operational conditions, and that the plans are periodically tested to verify that they can be successfully implemented as required.

In summary, events during the last year have proven that DDoS attacks — whether launched by nation-states, ideological groups, or rogue individuals — will not diminish any time soon. DDoS remains an effective tool for disrupting networks and degrading the morale of countries embroiled in sociopolitical upheaval, with new attacks happening every day. To stay protected in this time of war and geopolitical conflict, organizations must remain vigilant in their defense.

War and Geopolitical Conflict: The New Battleground for DDoS Attacks

CISA’s Known Exploited Vulnerabilities Catalog has become a valuable repository of vulnerabilities to be patched. A pair of reports analyze the vulnerabilities under attack to understand the kind of threats organizations should be prioritizing.

Back in November 2021, the US Cybersecurity and Infrastructure Security Agency (CISA) published the Known Exploited Vulnerabilities (KEV) Catalog to help federal agencies and critical infrastructure organizations identify and remediate vulnerabilities that are actively being exploited. CISA added 548 new vulnerabilities to the catalog across 58 updates from January to end of November 2022, according to Grey Noise in its first-ever "GreyNoise Mass Exploits Report."

Including the approximately 300 vulnerabilities added in November and December 2021, CISA listed approximately 850 vulnerabilities in the first year of the catalog's existence.

Actively exploited vulnerabilities in Microsoft, Adobe, Cisco, and Apple products accounted for over half of the updates to the KEV catalog in 2022, Grey Noise found. Seventy-seven percent of the updates to the KEV catalog were older vulnerabilities dating back to before 2022.

"Many were published in the previous two decades," noted Grey Noise's vice president of data science, Bob Rudis, in the report.

Several of the vulnerabilities in the KEV catalog are from products that have already entered end-of-life (EOL) and end-of-service-life (EOSL), according to an analysis by a team from Cyber Security Works. Even though Windows Server 2008 and Windows 7 are EOSL products, the KEV catalog lists 127 Server 2008 vulnerabilities and 117 Windows 7 vulnerabilities.

"The fact that they are a part of CISA KEV is quite telling as it indicates that many organizations are still using these legacy systems and therefore become easy targets for attackers," CSW wrote in its "Decoding the CISA KEV" report.

Even though the catalog was originally intended for critical infrastructure and public-sector organizations, it has become the authoritative source on which vulnerabilities are – or have been – exploited by attackers. This is key because the National Vulnerability Database (NVD) assigned Common Vulnerabilities and Exposures (CVE) identifiers for over 12,000 vulnerabilities in 2022, and it would be unwieldy for enterprise defenders to assess every single one to identify the ones relevant to their environments. Enterprise teams can use the catalog's curated list of CVEs under active attack to create their priority lists.

In fact, CSW found a bit of a delay between when a CVE Numbering Authority (CNA), such as Mozilla or MITRE, assigned a CVE to a vulnerability and when the vulnerability was added to the NVD. For example, a vulnerability in Apple WebKitGTK (CVE-2019-8720) received a CVE from Red Hat in October 2019 was added to the KEV catalog in March because it was being exploited by BitPaymer ransomware. It had not been added to the NVD as of early November (the cutoff date for CSW's report).

An organization relying on the NVD to prioritize patching would miss issues that are under active attack.

Thirty-six percent of the vulnerabilities in the catalog are remote code execution flaws and 22% are privilege execution flaws, CSW found. There were 208 vulnerabilities in CISA’s KEV Catalog associated with ransomware groups and 199 being used by APT groups, CSW found. There was an overlap, as well, where 104 vulnerabilities were being used by both ransomware and APT groups.

For instance, a medium-severity information disclosure vulnerability in Microsoft Silverlight (CVE-2013-3896) is associated with 39 ransomware groups, CSW said. The same analysis from CSW found that a critical buffer overflow vulnerability in the ListView/TreeView ActiveX controls used by Office documents (CVE-2012-0158) and a high-severity memory corruption issue in Microsoft Office (CVE-2017-11882) are being exploited by 23 APT groups, including most recently by the Thrip APT group (Lotus Blossom/BitterBug), in November 2022.

The spike in March 2022 is the result of Russia invading Ukraine in February – and the updates included many legacy vulnerabilities that nation-state actors had been known to exploit in businesses, governments, and critical infrastructure organizations, Grey Noise said. The vast majority – 94% – of the vulnerabilities added to the catalog in March were assigned a CVE before 2022.

CISA updates the KEV catalog only if the vulnerability is under active exploitation, has an assigned CVE, and there is clear guidance on how to remediate the issue. In 2022, enterprise defenders had to deal with an update to the KEV catalog on an almost weekly basis, with a new alert typically issued every four to seven days, Rudis wrote. The defenders were just as likely to have just a single day between updates, and the longest break defenders had in 2022 between updates was 17 days.

Adobe, Apple, Cisco, Microsoft Flaws Make Up Half of KEV Catalog

Dark Reading's panel of security experts deliver a magnum of bubbly hot takes on what 2023 will look like, featuring evil AIs, WWIII, wild workplace soon-to-be-norms, and more.

The end of the year is upon us, and that means predictions — lots and lots of predictions. And no wonder: With 2022 in the books, cybersecurity professionals worth their salt are starting to think about what's around the next bend; one needs to be prepared, after all.

This year, we wanted to break out of the mold of covering predictable predictions ("more automation is on the horizon," anyone?) to focus on some of the more out-there views on what the cybersecurity landscape might hold for the next revolution around the sun. In this, our stable of experts didn't disappoint.

Security experts from near and far gave Dark Reading their most outrageous/boldest security predictions for 2023. Whether that's something that will happen on the threat side of things (hackers will start WWIII), an impending crazy cyberattack (looking at you, evil Santa elves), a prediction for insane futuristic tech on the defensive side (bot vs. bot), nutty enterprise trends (spyware for employees), what have you — these crystal ball-isms will hopefully make you think about what is in store.

For instance, David Maynor, director of the Cybrary Threat Intelligence Team (CTIG), offered up a slew of hot takes for 2023 that run to the dystopian. And we're here for it:

"Information security practitioners will continue to be divided into topics, such as active defense, to the point that pseudo-religious cults may form," he opines. "DEF CON will be canceled. A reboot or sequel of one of the following movies will be greenlit: Hackers, Sneakers, WarGames, The Net, Swordfish."

Nicely done, David. And that's just the beginning.

**Cookies to the Rescue: A Seasonally Appropriate Hacking Collective**

To kick things off, Dean Agron, CEO and co-founder of Oxeye Security, flagged an impending cyberattack that's sure to hit everyone on Santa's list, not just the naughty ones.

>   
> "The 'Santa's Gift' attack, from a Greenland-based hacking group called '\[email protected\]'s 3lves' will allow attackers to bypass input sanitation mechanisms by using a specific combination of 🎅🏼 🦌 🧝 🎄 🎁 🛷 emojis (Santa, reindeer, elf, Christmas tree, gift, and sleigh). Every input that allows inputting emojis is vulnerable, and the right permutation of emojis will immediately enable root access to your cloud infrastructure. Privacy and security advocates who have been fighting to eliminate cookies are rethinking their posture, as an overflowing stack of cookies (and a glass of milk) is the only known measure to combat this attack." — Dean Agron, CEO and co-founder of Oxeye Security

Yes, he was just kidding. But it made you wonder for a minute, didn't it? Onto the real predictions!

**Automation Is Finally Ready for Prime Time**

Sure, predicting the use of more security automation is like saying there might be more political division in Congress in the new year. But at least one of the experts we tapped took it an extra step further.

>   
> "The drive to use automation to replace human workers will evolve into automating away the need for useless middle management where both workers and executives rejoice." — John Bambenek, principal threat hunter at Netenrich

Ouch.

**Scary AI & Machine Learning Gets ... Scarier**

The idea of weaponized deep fakes becoming a go-to method for attackers was a theme for many of the bold predictions that Dark Reading received.

>   
> "We haven't really seen it at scale yet, but with the trouble we already have getting our users to follow policy and not fall for social engineering attacks, how much worse will it be if (when) we have to deal with videos of their boss telling them that it's totally cool to give that random caller your password?" — Mike Parkin, senior technical engineer at Vulcan Cyber

Others also warmed to this theme.

>   
> "In 2023, fraudsters will devise new ways to hack into accounts, including new ways to spoof biometrics, new ways to create fraudulent identity documents, and new ways to create synthetic identities." — Ricardo Amper, founder and CEO at Incode

Roger Grimes, data-driven defense evangelist at cybersecurity company KnowBe4, points out that scary-level AI can juice the D, too.

>   
> "2023 will be the first year of bot vs. bot. The good guy's threat hunting and vulnerability-closing bots will be fighting against the bad guy's vulnerability-finding and attacking bots, and the bots with the best AI algorithms will win. 2023 is the year where AI becomes good enough that the humans turn over defense and attacks to self-traveling and replicating code for the entire attack chain from initial root exploit to extraction of value." — Roger Grimes, data-driven defense evangelist at KnowBe4

**Chatbot AIs: A Particularly Nasty Strain**

Sometimes the dark view of AI use has to do with unintended consequences, with Maynor linking back to his WarGames reboot note.

>   
> "A person with no programming or security knowledge may accidentally create a destructive, self-propagating worm using an AI chatbot and then accidentally release it on the Internet, causing almost a trillion dollars in damage worldwide." — Cybrary's Maynor

Hmmmm, what AI chatbot could he possibly be referring to? At least one person we talked to has no qualms naming names, with a dark prediction about AI-assisted phishing.

>   
> "Hackers will use ChatGPT to develop multilingual communications with unsuspecting users in business supply chains. Many of the most notorious cybercriminal gangs and state-sponsored cybercriminals operate in countries like Russia, North Korea, and other foreign countries \[which makes them\] somewhat easier for end users to detect. This technology can develop written communications in any language, with perfect fluency. It will be very difficult for users to recognize that they are potentially communicating via email with an individual who barely speaks or writes in their language. The damage this technology will cause is almost a certainty." — Adrien Gendre, chief tech & product officer and co-founder at Vade

Of course, these are early days for ChatGPT and its ilk. Imagine the risk once development really gets going.

>   
> "It's only now that the AI algorithms have evolved where good bot vs. bad bot becomes a realistic threat. ChatGPT showed us what was possible ... and it's not even the latest AI version. I'm not scared of ChatGPT. I'm scared of its children and grandchildren." — KnowBe4's Grimes

**Apocalypse Now? Critical Infrastructure Is Set to Burn...**

Evil AIs are forever tied in most of our minds with taking over the world and bringing about apocalypse (save John Connor!). But some experts tell Dark Reading that the apocalypse doesn't need to wait for the sentient robots.

>   
> "In 2023 we'll see a disruption to network supply chain unlike anything we've ever seen before: A new tactic that will be added to the warfare arsenal is the sabotage of fiber cable. It has long been a war tactic to target communication lines, but the attacks will be farther reaching and wipe out Internet access for entire continents." — Daniel Spicer, chief security officer at Ivanti

Sure, the Internet disappearing overnight could cause major dysfunction, but what about a long-term lack of power?

>   
> "The skills gap, recession and tensions abroad are forming a perfect storm for a major attack on the power grid in 2023. At the beginning of 2022, Homeland Security warned that domestic extremists had been developing plans to attack the US electric power infrastructure for years. The combination of aforementioned factors makes the US's power grid more vulnerable to cyberattacks than it has been in a long time." — Edward Liebig, global director of cyber-ecosystem at Hexagon Asset Lifecycle Intelligence

Ian Pratt, global head of security for personal systems at HP Inc., even offers Dark Reading a potential attack vector for such a scenario.

>   
> "Session hijacking — where an attacker will commandeer a remote access session to access sensitive data and systems — will grow in popularity in 2023. If such an attack connects to operational technology (OT) and industrial control systems (ICS) running factories and industrial plants, there could also be a physical impact on operational availability and safety — potentially cutting off access to energy or water for entire areas." — HP's Pratt

**... Or Maybe Not**

There's a contrarian in every bunch. Ron Fabela, CTO and co-founder at SynSaber, laid one such prediction on Dark Reading: that 2023 will be remembered for the ICS cyberwar that wasn't.

>   
> "While everyone in industrial cybersecurity will continue to fear all-out cyberwar, with predictions of turning off the power grid and poisoning our water shouted from rooftops and Capitol Hill, one thing is for certain: It's a paper dragon, all hot air and no teeth. The security operator in the SOC and the industrial operator in the control center deserve our attention rather than Russian APTs." — SynSaber's Fabela

**WWIII Started by Hackers?**

So if fears that the Bad Guys will take out our critical infrastructure are overblown, does anything have the power to light off a firestorm of kinetic war?

Why, messing with our finances, of course.

>   
> "An attack against the Securities & Exchange Commission (or IRS, or some similar fundamental agency to the US government) would likely be as clear a flash point for war as the assassination of Archduke Franz Ferdinand. So, if it were to happen, it would be a very carefully calculated and planned, state-sponsored attack." — Simon Eyre, CISO and managing director at Drawbridge

**Cybersecurity Consolidation? Less Vendor Choice? Nope & Nope**

Speaking of finances, anyone who has been following the volatile vagaries of the cybersecurity market from an M&A, valuation, and funding perspective will be aware that most analysts believe that enterprises will rapidly consolidate their cyber-defense tools under just a handful of vendor names — meaning that security Big Kahunas will just keep snapping up small fry and rivals until the choices end up very limited indeed.

Enterprises seem to want that too, according to survey after survey, given the upside in terms of interoperability and management.

Richard Stiennon, chief research analyst at IT-Harvest, says bah humbug to all that.

>   
> "I have been hearing this since there were less than 100 vendors. Now, I count more than 3,200 cybersecurity vendors covering 17 major categories and 660 subcategories. There are always going to be new threats, and new threat actors creating demand for new products that will come from startups. Yes, there will be lots of M&A action in 2023, probably close to 400 transactions. Every acquisition whets the appetite of investors to get in on the action. It also creates founders who are now wealthy who start their next company as soon as they earn out." — IT-Harvest's Stiennon

**Big Brother IS Watching You**

We would be remiss if we wrapped up without mentioning the myriad predictions that Dark Reading received regarding the future of remote and hybrid working. It isn't going anywhere — that genie is well and truly out of the bottle, we all agree. But there's a rather horrific side effect of that reality: The use of creepy productivity monitoring tools by employers, which for all intents and purposes, is spyware by another name, says one expert.

>   
> "Many leaders are resistant to remote work because they are used to leading based on observations, i.e. who is sitting at their desk the longest? In today’s ‘anywhere work’ environment, ‘observation leadership’ is causing managers to implement spy-like tools that measure activity and working hours which invade privacy and create a feeling of distrust among employees." — Dean Hager, CEO of Jamf

Silver lining alert: Hager adds that this kind of completely whacked-out employee tracking will backfire, leading to an outcome-based leadership that will have a positive effect on employee morale and company culture.

Beyond the Obvious: The Boldest Cybersecurity Predictions for 2023

Businesses need to educate employees the type of social engineering attacks used by hacking group DEV-0537 (LAPSUS$) and strengthen their security posture.

The hacking group DEV-0537, also known as LAPSUS$, operates on a global scale using a pure extortion and destruction model without deploying ransomware payloads. Unlike other social engineering attackers, DEV-0537 publicly announces its attacks on social media and pays employees for login credentials and multifactor authentication (MFA) approval. In the past, they have also used SIM-swapping to facilitate account takeovers, targeted personal employee email accounts, and intruded on crisis-communication calls once their targets have been hacked.

With some education on DEV-0537’s known tactics and strong cyber hygiene, businesses can guard themselves against future social engineering attacks.

**Strengthen MFA Implementation**

MFA is one of the primary lines of defense against DEV-0537. Require MFA for all users across all locations — regardless of whether they’re working remotely, from a trusted environment, or even from an on-premises system.

DEV-0537 often attempts to access networks via compromised credentials, so user and sign-in risk-based policies can protect against threats like new device enrollment and MFA registration. "Break glass" accounts and enterprise or workplace credentials should be stored offline rather than in a password vault or an online browser. Businesses can also leverage password protection to guard against easily guessed passwords.

Passwordless authentication methods can further reduce risks. Finally, you can use automated reports and workbooks to gain insight into risk distribution, risk detection trends, and opportunities for risk remediation.

Avoid telephone-based MFA methods to mitigate the risk of SIM-jacking, where the attackers trick the mobile carrier into transferring the phone number to a different SIM card. Other MFA factors such as voice approvals, simple push (instead, use number matching), and secondary email addresses are also weak and can be bypassed. Prevent users from sharing their credentials, and block location-based MFA exclusions — which allow bad actors to bypass the MFA requirements if they can fully compromise a single identity.

**Require Healthy and Trusted Endpoints**

Another way to guard against data theft is by requiring trusted, compliant, and healthy devices for access to resources. Cloud-delivered protection can further protect against rapidly evolving attacker tools and techniques, block new and unknown malware variants, and enhance attack surface reduction rules and tamper protection.

**Leverage Modern Authentication Options for VPNs**

Implementing modern authentication and tight conditional VPN access policies like OAuth or SAML has previously been effective against DEV-0537. These strategies block authentication attempts based on sign-in risk — requiring compliant devices in order for users to sign in and tighter integration with your authentication stack to improve risk detection accuracy.

**Strengthen and Monitor Your Cloud Security Posture**

Because DEV-0537 uses legitimate credentials to attack networks and leak sensitive enterprise data, at first glance, the group’s activity might appear consistent with typical user behavior. However, you can strengthen your cloud security posture by reviewing Conditional Access user and session risk configurations, configuring alerts to prompt a review on high-risk modification, and reviewing risk detections.

**Improve Awareness of Social Engineering Attacks**

Strong employee education is another way to protect your organization against social engineering attacks like DEV-0537. Your technical team should know what to watch out for and how to report unusual employee activity. Likewise, IT help desks should quickly track and report any suspicious users. Review your help desk policies for password resets for highly privileged users and executives to take social engineering into consideration.

**Establish Operational Security Processes in Response**

One hallmark tactic of DEV-0537 is to monitor and eavesdrop on incident response communications in the event of a cybersecurity breach. Companies should monitor these communication channels closely, and attendees should be routinely verified.

In the event that your organization is hacked by DEV-0537, follow tight operational security practices. Develop an out-of-band communication plan for incident responders that can be used for multiple days while an investigation occurs, and ensure response plan documentation is closely guarded and not easily accessible.

_Microsoft will_ _continue monitoring_ _DEV-0537’s activities, and we will share_ _additional insights and recommendations_ _as the situation evolves._

Read more _Partner Perspectives_ from Microsoft.

6 Ways to Protect Your Organization Against LAPSUS$

Security leaders from a media corporation, a commercial real estate company, and an automotive technology company share how they address cyber-risk.

Every organization is at risk of a cyberattack, but each organizations addresses risk differently. No one expects SMBs to take the same approach to cybersecurity as a large enterprise, or a legacy organization to have the same appetite for risk as a startup. Similarly, how an organization defends itself from attack depend on various factors, including its size, type of industry, supply chain resources, approach to outsourcing and remote work, and global presence.

Security leaders from three very different industries sat down with Dark Reading to discuss their respective cybersecurity programs.

John McClure is the CISO at Sinclair Broadcast, a major new and sports broadcasting provider in the United States, with nearly 200 televisions stations, streaming and digital platforms, and almost two dozen sportscasts. McClure says that while Sinclair faces many of the same cybersecurity threats that any organization faces, it is also considered part of the critical infrastructure because it carries emergency broadcast signals. One of the challenges that McClure has seen over the past five years is the disappearing network borders and finding ways to protect the network as the way people work continues to change.

Doug Shepherd is the senior director of the offensive security services team at Jones Lang LaSalle (JLL), a worldwide commercial real estate company with 90,000 employees in more than 60 countries. For a long time, JLL was more of a brand than a company, Shepherd explains, but in recent years, it has become more cohesive and working together under the JLL model. The company's cybersecurity concerns revolve around integrating all the different office networks into a unified model and consolidating individual security practices into one companywide policy, Shepherd says.

Luis Cunha is the director of security engineering at Aptiv, an automotive technology company with 170,000 employees in 165 manufacturing plants around the world. Operational technology security is as important to Aptiv as information technology, with endpoint security across all technologies a major concern, Cunha says.

**Size of Security Team**

There is no "right" size when it comes to the security team. Some organizations have large teams, and others partner with third-party providers to offset small teams. That difference is very clear with Sinclair, JLL, and Aptiv.

When Shepherd first came to JLL, most security was outsourced, but now there are 100 people on the security team, he says. However, Shepherd believes the team is a little undersized considering the size of the company.

Outsourcing in such a distributed company meant that each office was setting its own policies. JLL's focus on unifying security is driving its decision to move away from outsourcing. The goal is to reduce its reliance on outsourcing and eventually bring in contractors who work directly with the security staff, Shepherd says.

Sinclair's McClure didn't provide exact numbers — he just says his security team meets the industry average. At Sinclair, security is handled both in-house and outsourced. Sinclair relies on outsourcing for skills that are difficult to recruit and retain in-house, such as threat hunting, McClure says.

And then there is Aptiv, with 35 people on its security team — up from five on the engineering team a year ago, according to Cunha. Cunha thinks Aptiv has outsourced too much, which has an impact on the organization's agility and flexibility. When you outsource, you lose the ability to change and react to security problems quickly, Cunha says.

**Investing in Security Tech**

What kind of security technologies an organization invests in depends on factors such as regulatory and compliance requirements, the type of threats the organization sees, and its technology stack. As organizations move more of their operations to the cloud, they are investing in cloud security. With the shift to distributed computing, identity becomes an even more critical area of focus.

McClure says Sinclair is investing in a number of technologies, including endpoint detection and response (EDR), extended detection and response (XDR), and endpoint security, with an emphasis on identity and cloud security.

The broadcasting provider is also relying on automation to support the volume and velocity of data that is driven across its networks, says McClure. While some of the automation capabilities are native to the technology in use, the company also utilizes security orchestration, automation, and response (SOAR) technologies across multiple platforms.

In contrast, automation is in "very early days" for JLL, Shepherd says, as the organization moves away from outsourcing to in-house security. The company is focusing on endpoint and cloud security, and that is also where the focus is for automation. Shepherd is designing automation that pulls data from every endpoint every 15 minutes to look for indicators of risk in real time.

In the past, security was siloed at Jones Lang LaSalle, so the current focus is to set up technology that will allow the security team to have better visibility into the whole environment, Shepherd says.

Aptiv's focus is a little different, as the company is looking to adopt technology that brings more security efficiency and quality, with a greater focus on secure access service edge (SASE), Cunha says. Aptiv also invests in operational technology security for its manufacturing plants. There are a lot of different vendors for both types of security, and a goal for Cunha is better consolidation of technology and vendor solutions. Orchestration and automation tools play a very important role integrating security tools.

**Road to Data-Driven Security**

As far as Aptiv's Cunha is concerned, you can't have orchestration and automation without solid data analytics. Engineering teams use data analytics to improve security tools, Cunha says, bringing search capabilities to the SOC. Cunha's team performs its own data analytics rather than relying on a platform.

Like automation, data analytics is still in the early stages at JLL, but that doesn't mean data is not still useful, Shepherd says. JLL uses analytics to help determine what’s happening on the perimeter, he says.

Data analytics are used to control coverage and control efficiency, as it helps Sinclair understand the business and the assets that need to be protected, McClure says.

**Biggest Security Concerns**

Ransomware is the threat that keeps Shepherd up at night. It is the biggest concern for JLL because of how it disrupts business operations, he says.

Aptiv's Cunha's worries center around threats that impact data liability and organizational reputation, he says. While phishing is a common attack vector, Cunha also has to contend with lesser-known threats against operational technologies.

For McClure, ransomware and cybercrime are the biggest concerns, but he points out that cyber threats have not become more sophisticated. Instead, he thinks the barrier to entry for attackers has gotten lower, and as a result, there are more attacks. The attack vectors themselves, he says, haven't changed much over the years, and cybercriminals are using the same methods to get into the system.

It is the volume of attacks that is the greater challenge for organizations, McClure says, not increased sophistication in attacks.

3 Industries, 3 Security Programs

Attackers are harvesting credentials from compromised systems. Here's how some commonly used tools can enable this.

The majority of cyberattacks rely on stolen credentials — obtained by either tricking employees and end-users into sharing them, or by harvesting domain credentials cached on workstations and other systems on the network. These stolen credentials give attackers the ability to move laterally within the environment as they pivot from machine to machine — both on-premises and cloud — until they reach business-critical assets.

In the Uber breach back in September, attackers found the credentials in a specific PowerShell script. But there are plenty of less flashy, yet just as damaging, ways attackers can find credentials that would allow them access to the environment. These include common local credentials, local users with similar passwords, and credentials stored within files on network shares.

In our research, we faced the question of what kind of information can be extracted from a compromised machine — without exploiting any vulnerabilities — in order to move laterally or extract sensitive information. All the tools we used here are available on our GitHub repository.

Organizations rely on several tools to authenticate to servers and databases using SSH, FTP, Telnet, or RDP protocols — and many of these tools save credentials in order to speed up authentication. We look at three such tools — WinSCP, Robomongo, and MobaXterm — to show how an attacker could extract non-cleartext credentials.

**WinSCP: Obfuscated Credentials**

When a domain controller is not available, a user can access system resources using cached credentials that were saved locally after a successful domain logon. Because the user previously was authorized, the user can log into the machine using the domain account via cached credentials even if the domain controller that authenticated the user in the past is not available.

WinSCP offers the option to save the credential details used to connect to remote machines via SSH. While the credentials are obfuscated when saved in the Windows registry (Computer\\HKEY\_CURRENT\_USER\\SOFTWARE\\Martin Prikryl\\WinSCP 2\\Sessions), they are not encrypted at all. Anyone who knows the algorithm used to obfuscate can gain access to the credentials.

Since WinSCP's source code is available on GitHub, we were able to find the obfuscation algorithm. We used a tool that implemented the same algorithm to de-obfuscate the credentials, and we gained access to the credentials in cleartext.

Implementing an obfuscation algorithm to secure credentials stored is not best practice, as it can be easily reversed and lead to credentials theft.

**Robomongo: Not a Secret Key**

Robomongo (now Robo 3T) is a MongoDB client used to connect to Mongo database servers. When you save your credentials, they are encrypted and saved in a _robo3t.json_ JSON file. The secret key used to encrypt the credentials is also saved locally, in cleartext, in a _robo3t.key_ file.

That means that an attacker who gains access to a machine can use the key saved in cleartext to decrypt the credentials.

We looked at Robomongo's source code on GitHub to understand how the key is used to encrypt the password and learned that it uses the SimpleCrypt lib from Qt. While Robomongo uses encryption to securely store credentials, the fact that the secret key is saved in cleartext is not best practice. Attackers could potentially read it, because any user with access to the workstation can decrypt the credentials. Even if the information is encoded in a way that humans cannot read, certain techniques could determine which encoding is being used, then decode the information.

**MobaXterm: Decrypting the Password**

MobaXterm is a powerful tool to connect to remote machines using various protocols such as SSH, Telnet, RDP, FTP, and so on. A user who wants to save credentials within MobaXterm will be asked to create a master password to protect their sensitive data. By default, MobaXterm requests the master password only on a new computer.

That means that the master password is saved somewhere, and MobaXterm will retrieve it to access the encrypted credentials. We used Procmon from the Sysinternals Suite to map all the registry keys and files accessed by MobaXterm, and we found the master password saved in the Windows registry (Computer\\HKEY\_CURRENT\_USER\\SOFTWARE\\Mobatek\\MobaXterm\\M). Credentials and passwords are saved in the C and P registry keys, respectively.

Initially, we were unable to decrypt the master password, which was encrypted using DPAPI. We eventually figured out that the first 20 DPAPI bytes, which are always the same when using DPAPI, had been removed. When we added the first 20 bytes, we were able to decrypt the DPAPI cipher to obtain the SHA512 hash of the master password. This hash is used to encrypt and decrypt credentials.

Here, the encryption key used to securely store the credentials is saved using DPAPI. That means that only the user who saved the credentials can access them. However, a user with administrator access, or an attacker who gains access to the victim's session, can also decrypt the credentials stored on the machine.

**Know the Risks**

Developers, DevOps, and IT use various tools to connect to remote machines and manage these access details. Vendors have to store this sensitive information in the most secure way. However, encryption is always on the client side, and an attacker can replicate the tool behavior in order to decrypt the credentials.

As always, there isn't a magic solution that can solve every problem we've discussed here. Organizations might, however, begin by examining the services they are now using. They can construct an accurate risk matrix and be better prepared for data breaches by having a stronger understanding of the types of sensitive data and credentials they are storing.

Extracting Encrypted Credentials From Common Tools

How CISOs handle the ethical issues around data breaches can make or break their careers. Don't wait until a breach happens to plot the course forward.

The recent conviction of Joe Sullivan, Uber's chief information security officer (CISO), for failing to report the company's 2016 data breach came as an unwelcome surprise to some and as a justified consequence of Mr. Sullivan's actions to others.

As a fellow CISO and information security leader for over 30 years, I respect Sullivan's distinguished career and, at the same time, fully support the verdict. Sullivan found himself in an ethical dilemma that most CISOs find themselves in sooner or later. How a CISO decides to handle that dilemma can make or break their career.

**What Are a CISO's Responsibilities?**

The role and responsibilities of the CISO are constantly evolving and are scrutinized even more so thanks to the growing publicity around large breaches, such as that seen at Uber.

For CISOs considering what these recent events mean for them, it's a suitable time to ask three important questions.

**1)** **As CISO, what is my responsibility when there's a data breach?** 

While the Uber trial may have brought the CISO's role into sharper focus, I don't think it changes the responsibility or liability associated with the role. When a breach occurs, the CISO's responsibility is clear: be transparent and provide all the necessary disclosures. Sometimes these disclosures are mandated by regulatory bodies, and sometimes they are just considered a responsible disclosure by the company to its constituents.

I don't know if Sullivan's first reaction was to take the correct action and report the breach as required by law. Considering his long career, I certainly hope that was the case. That said, depending on the reporting structure within the company, many CISOs may not have the final say about whether the company will disclose the breach. As is often the case, the CISO may be overruled and pressured to find a way to reframe the breach as something other than a breach. This reframing can help the company avoid potential negative consequences, including regulatory fines, remediation costs (for example, providing credit monitoring services to affected customers), and impact on customer trust and company reputation.

A breach is, quite correctly, viewed as a failure of the company to protect the data that was breached. It can also ultimately be viewed as a failure of the CISO. This raises the age-old questions: Where does the buck stop? And who bears the ultimate responsibility for the breach? Regardless, it's not a simple thing for a company to admit or disclose.

The CISO's ethical dilemma is: Do I maintain the integrity of my role and follow my responsibility? Or do I try to reframe the incident so that my company doesn't bear the consequences?

I would like to think that if I were in Sullivan's shoes, I would be willing to resign my position rather than betray the integrity of my role and, frankly, the trust of my constituents. To paraphrase US President Harry S. Truman, "The cybersecurity buck stops with the CISO."

**2) What is my company's plan for when (not if) we get breached?**

As the CISO for a security vendor, I know all too well the motivation and determination of bad actors and nation states. I also understand the odds organizations face in falling victim to an attack — organizations must assume they'll be breached. What will you do when that happens?

Addressing worst-case scenarios and having a contingency plan in place before you get breached can minimize the financial and operational fallout when you do. What's the cost of downtime if an attacker takes your customer support or supply chain operation offline? Where are your systems most vulnerable? How do you contain the damage, and how quickly can you recover? How do you communicate what happened to your employees, customers, and the board?

The CEO and other company officers must proactively work with the CISO to address these questions and develop a comprehensive plan that is ready when a breach occurs. Immediate action — and honesty — count above all else. But such a plan will only be successful if it has been created, vetted, and rehearsed well in advance.

**3) What is my role with the board of directors?**

The most resilient companies commit to security at the top and drive it down through every level of the organization. This means establishing a strong cybersecurity culture with the board, as well as with employees. Many CISOs may have to contend with the biases of boards that say, "that'll never happen to us" or "it's going to happen anyway, so why invest in cybersecurity."

**Manage the CISO Relationship Like a Business Relationship**

One way for CISOs to enhance their relationship with the board is to serve as the bridge between technology and business. We need to show the board that we manage cybersecurity as a business risk, and align with performance, growth, and other business goals of the organization. Be sure to use business terms and outcomes, not just technical acronyms and concepts. Help answer the question "Why should I care about this?" And if you succeed in being granted resources by the board, it's important to follow up with a report that connects the resources you requested to the business results and outcomes that followed.

In my own experience, to be most effective, it's important for the CISO to nurture a relationship with their board members outside of regularly scheduled meetings. This gives us the opportunity to better understand what our board members are expecting from the CISO, and likewise, to start educating the board. In the end, the practice of cybersecurity is about managing risk, but the truth is that we can never eliminate risk completely. Daily breach headlines have put every CISO in the hot seat. The CISO has a daunting job: they must manage their organization's day-to-day defense, while simultaneously creating an action plan for that inevitable future attack. It takes integrity and honesty for a CISO to successfully lead and thrive today in this challenging and critical role.

Source

DARKReading