The campaign heavily uses Dropbox folders and PowerShell scripts to evade detection and quickly scrapped infrastructure components after researchers began poking around.

North Korea-linked threat groups are increasingly using living-off-the-land (LotL) techniques and trusted services to evade detection, with a recent Kimsuky campaign showcasing the use of PowerShell scripts and storing data in Dropbox folders, along with improved operational security.

In the campaign, dubbed "DEEP#DRIVE" by security firm Securonix, the threat group used fake work logs, insurance documents, and crypto-related files to convince users to download and run a zipped shortcut file that gathers system configuration information and then executes PowerShell and .NET scripts. The attack tools upload the system data to Dropbox folders and then download additional commands and capabilities for further compromise.

While the attackers showed some interest in quick financial wins — such as targeting cryptocurrency users — for the most part, the threat group focused on stealing sensitive data from South Korean government agencies and businesses, says Tim Peck, a senior threat researcher at Securonix.

"We observed evidence of both espionage and financial motivation, though leaning more toward espionage," he says. "This aligns with Kimsuky's historical targeting of South Korean government agencies, enterprises, and strategic industries."

North Korean cyber-operations groups have consistently targeted South Korea and the US, with South Korean government agencies and companies among the most popular targets. In September 2024, the FBI warned that North Korean groups planned to launch a surge of attacks against organizations with significant cryptocurrency reserves, and Kimsuky launched a similar multistage attack against South Korean targets last year.

**A Prolific Group**

Kimsuky isn't monolithic, but has five threat groups that have overlap with what other companies consider to be the same group, says threat intelligence firm Recorded Future. One group tends to focus on the healthcare and hospitality sectors, for example, while another focuses on cryptocurrency markets.

By mid-2023, Kimsuky became the most prolific North Korean group. (More recent data not available.) Source: Recorded Future's "North Korea's Cyber Strategy" report

The Kimsuky groups accounted for the most attacks identified as North Korean in origin between 2021 and 2023, according to Recorded Future's "North Korea Cyber Strategy" report. In 2024, the groups continued to account for a high volume of attacks, says Mitch Haszard, senior threat intelligence analyst with Recorded Future.

"These groups conduct high volume phishing campaigns, primarily targeting individuals and organizations in South Korea, while occasionally targeting entities in other countries," he says. "In the activity we see, these groups appear to be going for volume, rather than more time-consuming, tailored spear-phishing operations."

Other well known North Korean groups, such as Lazarus and Andariel, are not as prolific as the Kimsuky threat actors. While some of those groups are more focused on gathering sensitive information, nearly all also have a financial motivation.

**Thousands of Victims?**

In the DEEP#DRIVE campaign, following the compromise of a system, the Kimsuky group's attack scripts upload data on the system configuration to one of several Dropbox folders. While the Securonix researchers were not able to gather intelligence from all the suspected Dropbox locations, they uncovered signs of more than 8,000 configuration files, although some appear to be duplicates, Peck says.

While that means they likely came from the same victim organizations, the campaign appears to be quite successful, he says.

"There were two factors which contributed to the 'uniqueness' of the configuration file, the username, and IP address," Peck says. "Some usernames were associated with dozens of similar IP addresses, which could indicate lateral movement by the attacker — \[that is\], infecting dozens of machines from the same entity."

The data from a compromised system includes the host IP address, the system uptime, details about the OS type and version, any installed security software, and a list of running processes.

**Kimsuky Improves Its OpSec**

The campaign also highlighted North Korean cyber-operations groups' improvements to operational security. The group used OAuth-based authentication on its Dropbox folders, preventing traditional URL-blocking or network-based defenses from following the links. The threat actors also quickly took down components of their infrastructure soon after the Securonix researchers began investigating, Securonix's Peck says.

"This level of operational awareness is not always present in phishing-driven malware campaigns," he says.

For companies, the threat group's tactics underscore that the hidden file extensions should be disabled, shortcut files should be blocked from executing in user folders, and only signed PowerShell scripts be allowed to execute. Those three countermeasures make the attackers' activity much easier to detect, Peck says.

In addition, companies in targeted industries — such as cryptocurrency exchanges and government agencies — should bolster their email security and regularly train employees on how to spot phishing threats, says Recorded Future's Haszard.

"Most North Korean cyberattacks still start with social engineering and a phish," he says. "Companies should ensure that they have an email security solution in place and regularly train employees on phishing threats, as well as conduct simulated phishing tests."

**About the Author**

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

North Korea's Kimsuky Taps Trusted Platforms to Attack South Korea

Now we know exactly how DeepSeek was designed to work, and we may even have a clue toward its highly publicized scandal with OpenAI.

Source: mundissima via Alamy Stock Photo

Researchers have tricked DeepSeek, the Chinese generative AI (GenAI) that debuted earlier this month to a whirlwind of publicity and user adoption, into revealing the instructions that define how it operates.

DeepSeek, the new "it girl" in GenAI, was trained at a fractional cost of existing offerings, and as such has sparked competitive alarm across Silicon Valley. This has led to claims of intellectual property theft from OpenAI, and the loss of billions in market cap for AI chipmaker Nvidia. Naturally, security researchers have begun scrutinizing DeepSeek as well, analyzing if what's under the hood is beneficent or evil, or a mix of both. And analysts at Wallarm just made significant progress on this front by jailbreaking it.

In the process, they revealed its entire system prompt, i.e., a hidden set of instructions, written in plain language, that dictates the behavior and limitations of an AI system. They also may have induced DeepSeek to admit to rumors that it was trained using technology developed by OpenAI.

**DeepSeek's System Prompt**

Wallarm informed DeepSeek about its jailbreak, and DeepSeek has since fixed the issue. For fear that the same tricks might work against other popular large language models (LLMs), however, the researchers have chosen to keep the technical details under wraps.

Related:Code-Scanning Tool's License at Heart of Security Breakup

"It definitely required some coding, but it's not like an exploit where you send a bunch of binary data \[in the form of a\] virus, and then it's hacked," explains Ivan Novikov, CEO of Wallarm. "Essentially, we kind of convinced the model to respond \[to prompts with certain biases\], and because of that, the model breaks some kinds of internal controls."

By breaking its controls, the researchers were able to extract DeepSeek's entire system prompt, word for word. And for a sense of how its character compares to other popular models, it fed that text into OpenAI's GPT-4o and asked it to do a comparison. Overall, GPT-4o claimed to be less restrictive and more creative when it comes to potentially sensitive content.

"OpenAI's prompt allows more critical thinking, open discussion, and nuanced debate while still ensuring user safety," the chatbot claimed, where "DeepSeek’s prompt is likely more rigid, avoids controversial discussions, and emphasizes neutrality to the point of censorship."

While the researchers were poking around in its kishkes, they also came across one other interesting discovery. In its jailbroken state, the model seemed to indicate that it may have received transferred knowledge from OpenAI models. The researchers made note of this finding, but stopped short of labeling it any kind of proof of IP theft.

Related:OAuth Flaw Exposed Millions of Airline Users to Account Takeovers

"\[We were\] not retraining or poisoning its answers — this is what we got from a very plain response after the jailbreak. However, the fact of the jailbreak itself doesn't definitely give us enough of an indication that it's ground truth," Novikov cautions. This subject has been particularly sensitive ever since Jan. 29, when OpenAI — which trained its models on unlicensed, copyrighted data from around the Web — made the aforementioned claim that DeepSeek used OpenAI technology to train its own models without permission.

Source: Wallarm

**DeepSeek's Week to Remember**

DeepSeek has had a whirlwind ride since its worldwide release on Jan. 15. In two weeks on the market, it reached 2 million downloads. Its popularity, capabilities, and low cost of development triggered a conniption in Silicon Valley, and panic on Wall Street. It contributed to a 3.4% drop in the Nasdaq Composite on Jan. 27, led by a $600 billion wipeout in Nvidia stock — the largest single-day decline for any company in market history.

Then, right on cue, given its suddenly high profile, DeepSeek suffered a wave of distributed denial of service (DDoS) traffic. Chinese cybersecurity firm XLab found that the attacks began back on Jan. 3, and originated from thousands of IP addresses spread across the US, Singapore, the Netherlands, Germany, and China itself. 

Related:Spectral Capital Files Quantum Cybersecurity Patent

An anonymous expert told the Global Times when they began that "at first, the attacks were SSDP and NTP reflection amplification attacks. On Tuesday, a large number of HTTP proxy attacks were added. Then early this morning, botnets were observed to have joined the fray. This means that the attacks on DeepSeek have been escalating, with an increasing variety of methods, making defense increasingly difficult and the security challenges faced by DeepSeek more severe."

To stem the tide, the company put a temporary hold on new accounts registered without a Chinese phone number.

On Jan. 28, while fending off cyberattacks, the company released an upgraded Pro version of its AI model. The following day, Wiz researchers discovered a DeepSeek database exposing chat histories, secret keys, application programming interface (API) secrets, and more on the open Web.

Elsewhere on Jan. 31, Enkyrpt AI published findings that reveal deeper, meaningful issues with DeepSeek's outputs. Following its testing, it deemed the Chinese chatbot three times more biased than Claud-3 Opus, four times more toxic than GPT-4o, and 11 times as likely to generate harmful outputs as OpenAI's O1. It's also more inclined than most to generate insecure code, and produce dangerous information pertaining to chemical, biological, radiological, and nuclear agents.

Yet despite its shortcomings, "It's an engineering marvel to me, personally," says Sahil Agarwal, CEO of Enkrypt AI. "I think the fact that it's open source also speaks highly. They want the community to contribute, and be able to utilize these innovations. I think that's why a lot of closed-source model providers are sort of scared."

He adds, too, that "there are other models that are worse than DeepSeek. It's just that DeepSeek is so much in the news, so it has a lot of eyes on it."

**About the Author**

Nate Nelson is a writer based in New York City. He formerly worked as a reporter at Threatpost, and wrote "Malicious Life," an award-winning Top 20 tech podcast on Apple and Spotify. Outside of Dark Reading, he also co-hosts "The Industrial Security Podcast."

DeepSeek Jailbreak Reveals Its Entire System Prompt

DeepSeek, a Chinese AI startup, exposed sensitive data by leaving a database open. Wiz Research found chat logs, keys, and backend details accessible.

DeepSeek, a Chinese AI company, has made a name for itself with its AI models that rival OpenAI’s systems. But along with its rise came a serious security issue as researchers at Wiz found that a database tied to the company was left publicly accessible, exposing over a million log entries, backend details, software keys, and more.

****How It Happened****

During a routine security assessment, researchers at Wiz discovered that DeepSeek had an unprotected ClickHouse database, open to anyone with internet access. This database wasn’t just visible; it allowed full control over stored data, meaning an attacker could manipulate or extract critical information without restriction.

The exposed database was linked to multiple subdomains, including:

dev.deepseek.com:9000

oauth2callback.deepseek.com:9000

ClickHouse is an open-source, columnar database management system designed to process analytical queries on large datasets quickly. Originally developed by Yandex, it’s widely used for real-time data analytics, log processing, and business intelligence.

According to Wiz’s blog post, its researchers were able to query the system without authentication, revealing a massive volume of logs containing:

*   **API keys**
*   **Chat histories**
*   **Backend service details**
*   **System operational metadata**

This wasn’t just a minor misconfiguration. The database contained detailed logs of internal system activity, exposing how DeepSeek’s AI tools operate and communicate. Worse yet, the exposure meant attackers could execute commands and extract even more sensitive data directly from the server.

****What Was at Risk?****

DeepSeek’s AI services process large amounts of user-generated data, meaning chat logs could have included personal or proprietary information. The database also stored API keys, which, in the wrong hands, could allow attackers to impersonate DeepSeek’s services or access further internal systems.

Given the expansion of AI startups, security often takes a backseat to development speed. In this case, a simple security lapse exposed valuable internal data, which could have been exploited by cybercriminals.

****DeepSeek’s Response****

Once notified by Wiz, DeepSeek moved quickly to lock down the database and remove public access. However, it remains unclear whether any unauthorized parties accessed the information before it was secured.

****DeepSeek: Privacy and Cybersecurity Concerns****

DeepSeek’s Chinese ownership has already raised concerns among Western governments, with some critics arguing that the chatbot collects excessive personal data, posing privacy risks. Adding to these worries, DeepSeek recently reported a “large malicious attack” that forced the company to suspend new user registrations. Now, with a publicly exposed database compromising sensitive information, the company faces yet another cybersecurity setback.

****Expert Opinion****

Gunter Ollmann, CTO at Cobalt, notes that situations like the DeepSeek issue happen often because the process of getting the product up and running takes priority over security. Also, since DeepSeek has taken a prominent place in the world of AI, the impact could have been huge for companies and individual users.

“The DeepSeek exposure highlights a critical and recurring issue—organizations, especially those innovating rapidly in AI, often prioritize speed over security.” Explained Gunter. “Wiz’s discovery reinforces the importance of proactive security testing, particularly as attack surfaces expand with cloud-based infrastructure and publicly accessible APIs.”

DeepSeek AI Leaks Over a Million Chat Logs and Sensitive Data Online

Palo Alto, USA, 30th January 2025, CyberNewsWire

**Palo Alto, USA, January 30th, 2025, CyberNewsWire**

SquareX discloses a new attack technique that shows how malicious extensions can be used to completely hijack the browser, and eventually, the whole device.

**PALO ALTO, Calif., Jan. 30, 2025** — Browser extensions have been under the spotlight in enterprise security news recently due to the wave of OAuth attacks on Chrome extension developers and data exfiltration attacks. However, until now, due to the limitations browser vendors place on the extension subsystem and extensions, it was thought to be impossible for extensions to gain full control of the browser, much less the device.

SquareX researchers Dakshitaa Babu, Arpit Gupta, Sunkugari Tejeswara Reddy and Pankaj Sharma debunked this belief by demonstrating how attackers can use malicious extensions to escalate privileges to conduct a full browser and device takeover, all with minimal user interaction. Critically, the malicious extension only requires read/write capabilities present in the majority of browser extensions on the Chrome Store, including common productivity tools like Grammarly, Calendly and Loom, desensitizing users from granting these permissions. This revelation suggests that virtually any browser extension could potentially serve as an attack vector if created or taken over by an attacker. To the best of our understanding, extensions submitted to the Chrome Store requesting these capabilities are not put through additional security scrutiny at the time of this writing.

The browser syncjacking attack can be broken up into three parts: how the extension silently adds a profile managed by the attacker, hijacks the browser and eventually gains full control of the device.

**Profile Hijacking**

The attack begins with an employee installing any browser extension – this could involve publishing one that masquerades as an AI tool or taking over existing popular extensions that may have up to millions of installations in aggregate. The extension then “silently” authenticates the victim into a Chrome profile managed by the attacker’s Google Workspace. This is all done in an automated manner in a background window, making the whole process almost imperceptible to the victim. Once this authentication occurs, the attacker has full control over the newly managed profile in the victim’s browser, allowing them to push automated policies such as disabling safe browsing and other security features.

Using a very clever social engineering attack that exploits trusted domains, the adversary can then further escalate the profile hijacking attack to steal passwords from the victim’s browser. For example, the malicious extension can open and modify Google’s official support page on how to sync user accounts to prompt the victim to perform the sync with just a few clicks. Once the profile is synced, attackers have full access to all credentials and browsing history stored locally. As this attack only leverages legitimate sites and has no visible sign that it has been modified by the extension, it will not trigger any alarm bells in any security solutions monitoring the network traffic.

**Browser Takeover**

To achieve a full browser takeover, the attacker essentially needs to convert the victim’s Chrome browser into a managed browser. The same extension monitors and intercepts a legitimate download, such as a Zoom update, and replaces it with the attacker’s executable, which contains an enrollment token and registry entry to turn the victim’s Chrome browser into a managed browser. Thinking that they downloaded a Zoom updater, the victim executes the file, which ends up installing a registry entry that instructs the browser to become managed by the attacker’s Google Workspace. This allows the attacker to gain full control over the victim’s browser to disable security features, install additional malicious extensions, exfiltrate data and even silently redirect users to phishing sites. This attack is extremely potent as there is no visual difference between a managed and unmanaged browser. For a regular user, there is no telltale sign that a privilege escalation has occurred unless the victim is highly security aware and goes out of their way to regularly inspect their browser settings and look for associations with an unfamiliar Google Workspace account.

**Device Hijacking**

With the same downloaded file above, the attacker can additionally insert registry entries required for the malicious extension to message native apps. This allows the extension to directly interact with local apps without further authentication. Once the connection is established, attackers can use the extension in conjunction with the local shell and other available native applications to secretly turn on the device camera, capture audio, record screens and install malicious software – essentially providing full access to all applications and confidential data on the device.

The browser syncjacking attack exposes a fundamental flaw in the way remote-managed profiles and browsers are managed. Today, anyone can create a managed workspace account tied to a new domain and a browser extension without any form of identity verification, making it impossible to attribute these attacks. Unfortunately, most enterprises currently have zero visibility into the browser – most do not have managed browsers or profiles, nor any visibility to the extensions employees are installing often based on trending tools and social media recommendations.

What makes this attack particularly dangerous is that it operates with minimal permissions and nearly no user interaction, requiring only a subtle social engineering step using trusted websites – making it almost impossible for employees to detect. While recent incidents like the Cyberhaven breach have already compromised hundreds, if not thousands of organizations, those attacks required relatively complex social engineering to operate. The devastatingly subtle nature of this attack – with an extremely low threshold of user interaction – not only makes this attack extremely potent, but also sheds light on the terrifying possibility that adversaries are already using this technique to compromise enterprises today.

Unless an organization chooses to completely block browser extensions via managed browsers, the browser syncjacking attack will completely bypass existing blacklists and permissions-based policies. SquareX’s founder Vivek Ramachandran says “This research exposes a critical blind spot in enterprise security. Traditional security tools simply can’t see or stop these sophisticated browser-based attacks. What makes this discovery particularly alarming is how it weaponizes seemingly innocent browser extensions into complete device takeover tools, all while flying under the radar of conventional security measures like EDRs and SASE/SSE Secure Web Gateways. A Browser Detection-Response solution isn’t just an option anymore – it’s a necessity. Without visibility and control at the browser level, organizations are essentially leaving their front door wide open to attackers. This attack technique demonstrates why security needs to ‘shift up’ to where the threats are actually happening: in the browser itself.”

SquareX has been conducting pioneering security research on browser extensions, including the DEF CON 32 talk Sneaky Extensions: The MV3 Escape Artists that revealed multiple MV3 compliant malicious extensions. This research team was also the first to discover and disclose the OAuth attack on Chrome extension developers one week before the Cyberhaven breach. SquareX was also responsible for the discovery of Last Mile Reassembly attacks, a new class of client-side attacks that exploits architectural flaws and completely bypasses all Secure Web Gateway solutions. Based on this research, SquareX’s industry-first Browser Detection and Response solution protects enterprises against advanced extension-based attacks including device hijacking attempts by conducting dynamic analysis on all browser extension activity at runtime, providing a risk score to all active extensions across the enterprise and further identifying any attacks that they may be vulnerable to.

For more information about the browser syncjacking attack, additional findings from this research are available at **sqrx.com/research**.

**About SquareX**

SquareX helps organizations detect, mitigate and threat-hunt client-side web attacks happening against their users in real time.

SquareX’s industry-first Browser Detection and Response (BDR) solution, takes an attack-focused approach to browser security, ensuring enterprise users are protected against advanced threats like malicious QR Codes, Browser-in-the-Browser phishing, macro-based malware and other web attacks encompassing malicious files, websites, scripts, and compromised networks.

Additionally, with SquareX, enterprises can provide contractors and remote workers with secure access to internal applications, enterprise SaaS, and convert the browsers on BYOD / unmanaged devices into trusted browsing sessions.

**Contact**

**Head of PR**  
**Junice Liew**  
**SquareX**  
**\[email protected\]**

SquareX Discloses “Browser Syncjacking” , a New Attack Technique that Provides Full Browser and Device Control, Putting Millions at Risk

**SquareX discloses a new attack technique that shows how malicious extensions can be used to completely hijack the browser, and eventually, the whole device.**

**PALO ALTO, Calif., Jan. 30, 2025** — Browser extensions have been under the spotlight in enterprise security news recently due to the wave of OAuth attacks on Chrome extension developers and data exfiltration attacks. However, until now, due to the limitations browser vendors place on the extension subsystem and extensions, it was thought to be impossible for extensions to gain full control of the browser, much less the device.

SquareX researchers Dakshitaa Babu, Arpit Gupta, Sunkugari Tejeswara Reddy and Pankaj Sharma debunked this belief by demonstrating how attackers can use malicious extensions to escalate privileges to conduct a full browser and device takeover, all with minimal user interaction. Critically, the malicious extension only requires read/write capabilities present in the majority of browser extensions on the Chrome Store, including common productivity tools like Grammarly, Calendly and Loom, desensitizing users from granting these permissions. This revelation suggests that virtually any browser extension could potentially serve as an attack vector if created or taken over by an attacker. To the best of our understanding, extensions submitted to the Chrome Store requesting these capabilities are not put through additional security scrutiny at the time of this writing.

The browser syncjacking attack can be broken up into three parts: how the extension silently adds a profile managed by the attacker, hijacks the browser and eventually gains full control of the device.

**Profile Hijacking**

The attack begins with an employee installing any browser extension – this could involve publishing one that masquerades as an AI tool or taking over existing popular extensions that may have up to millions of installations in aggregate. The extension then “silently” authenticates the victim into a Chrome profile managed by the attacker’s Google Workspace. This is all done in an automated manner in a background window, making the whole process almost imperceptible to the victim. Once this authentication occurs, the attacker has full control over the newly managed profile in the victim’s browser, allowing them to push automated policies such as disabling safe browsing and other security features.

Using a very clever social engineering attack that exploits trusted domains, the adversary can then further escalate the profile hijacking attack to steal passwords from the victim’s browser. For example, the malicious extension can open and modify Google’s official support page on how to sync user accounts to prompt the victim to perform the sync with just a few clicks. Once the profile is synced, attackers have full access to all credentials and browsing history stored locally. As this attack only leverages legitimate sites and has no visible sign that it has been modified by the extension, it will not trigger any alarm bells in any security solutions monitoring the network traffic.

**Browser Takeover**

To achieve a full browser takeover, the attacker essentially needs to convert the victim’s Chrome browser into a managed browser. The same extension monitors and intercepts a legitimate download, such as a Zoom update, and replaces it with the attacker’s executable, which contains an enrollment token and registry entry to turn the victim’s Chrome browser into a managed browser. Thinking that they downloaded a Zoom updater, the victim executes the file, which ends up installing a registry entry that instructs the browser to become managed by the attacker’s Google Workspace. This allows the attacker to gain full control over the victim’s browser to disable security features, install additional malicious extensions, exfiltrate data and even silently redirect users to phishing sites. This attack is extremely potent as there is no visual difference between a managed and unmanaged browser. For a regular user, there is no telltale sign that a privilege escalation has occurred unless the victim is highly security aware and goes out of their way to regularly inspect their browser settings and look for associations with an unfamiliar Google Workspace account.

**Device Hijacking**

With the same downloaded file above, the attacker can additionally insert registry entries required for the malicious extension to message native apps. This allows the extension to directly interact with local apps without further authentication. Once the connection is established, attackers can use the extension in conjunction with the local shell and other available native applications to secretly turn on the device camera, capture audio, record screens and install malicious software – essentially providing full access to all applications and confidential data on the device.

The browser syncjacking attack exposes a fundamental flaw in the way remote-managed profiles and browsers are managed. Today, anyone can create a managed workspace account tied to a new domain and a browser extension without any form of identity verification, making it impossible to attribute these attacks. Unfortunately, most enterprises currently have zero visibility into the browser – most do not have managed browsers or profiles, nor any visibility to the extensions employees are installing often based on trending tools and social media recommendations.

What makes this attack particularly dangerous is that it operates with minimal permissions and nearly no user interaction, requiring only a subtle social engineering step using trusted websites – making it almost impossible for employees to detect. While recent incidents like the Cyberhaven breach have already compromised hundreds, if not thousands of organizations, those attacks required relatively complex social engineering to operate. The devastatingly subtle nature of this attack – with an extremely low threshold of user interaction – not only makes this attack extremely potent, but also sheds light on the terrifying possibility that adversaries are already using this technique to compromise enterprises today.

Unless an organization chooses to completely block browser extensions via managed browsers, the browser syncjacking attack will completely bypass existing blacklists and permissions-based policies. SquareX’s founder Vivek Ramachandran says “This research exposes a critical blind spot in enterprise security. Traditional security tools simply can’t see or stop these sophisticated browser-based attacks. What makes this discovery particularly alarming is how it weaponizes seemingly innocent browser extensions into complete device takeover tools, all while flying under the radar of conventional security measures like EDRs and SASE/SSE Secure Web Gateways. A Browser Detection-Response solution isn’t just an option anymore – it’s a necessity. Without visibility and control at the browser level, organizations are essentially leaving their front door wide open to attackers. This attack technique demonstrates why security needs to ‘shift up’ to where the threats are actually happening: in the browser itself.”

SquareX has been conducting pioneering security research on browser extensions, including the DEF CON 32 talk Sneaky Extensions: The MV3 Escape Artists that revealed multiple MV3 compliant malicious extensions. This research team was also the first to discover and disclose the OAuth attack on Chrome extension developers one week before the Cyberhaven breach. SquareX was also responsible for the discovery of Last Mile Reassembly attacks, a new class of client-side attacks that exploits architectural flaws and completely bypasses all Secure Web Gateway solutions. Based on this research, SquareX’s industry-first Browser Detection and Response solution protects enterprises against advanced extension-based attacks including device hijacking attempts by conducting dynamic analysis on all browser extension activity at runtime, providing a risk score to all active extensions across the enterprise and further identifying any attacks that they may be vulnerable to.

For more information about the browser syncjacking attack, additional findings from this research are available at **sqrx.com/research**.

**About SquareX**

SquareX helps organizations detect, mitigate and threat-hunt client-side web attacks happening against their users in real time.

SquareX’s industry-first Browser Detection and Response (BDR) solution, takes an attack-focused approach to browser security, ensuring enterprise users are protected against advanced threats like malicious QR Codes, Browser-in-the-Browser phishing, macro-based malware and other web attacks encompassing malicious files, websites, scripts, and compromised networks.

Additionally, with SquareX, enterprises can provide contractors and remote workers with secure access to internal applications, enterprise SaaS, and convert the browsers on BYOD / unmanaged devices into trusted browsing sessions.

**Contact**

**Head of PR**  
**Junice Liew**  
**SquareX**  
**\[email protected\]**

SquareX Unveils “Browser Syncjacking” Attack Granting Full Browser and Device Control

The now-fixed vulnerability involved a major travel services company that's integrated with dozens of airline websites worldwide.

Source: Ribkhan via Shutterstock

A vulnerability that exposed millions of airline customers to potential account takeovers has highlighted the significant risks organizations face from misconfigured OAuth authentication processes.

The vulnerability in this case involved a major provider of online travel services for hotels and car rentals. Many airlines have integrated this service into their websites, allowing customers to use their airline points to book not just flights, but also hotels and rental cars in one seamless process.

**OAuth Implementation Flaw**

Researchers at Salt Security, hunting for real-world examples of API supply chain attacks, stumbled upon a vulnerability in the travel company's process for authenticating users looking to access its services after making an initial airline booking. The flaw, which the travel services company has since fixed, basically gave attackers a way to redirect a user's OAuth credentials to a server of their choice.

The credentials would have allowed the attackers to obtain a valid session token from an airline's website and use it to log into the travel company's systems as the victim and book hotels and car rentals using airline loyalty points.

The discovered vulnerability enabled attackers to hijack victim accounts with a single click, Salt Security researcher Amit Elbirt wrote in a blog post this week, without revealing the identity of the travel services company.

While the takeover would have happened within the travel provider's service, it would have given an attacker full access to a victim's stored information on the airline company's site, including personally identifying information, mileage, and rewards data. "This critical risk highlights the vulnerabilities in third-party integrations and the importance of stringent security protocols to protect users from unauthorized account access and manipulation," Elbirt wrote.

OAuth (Open Authentication) is a security protocol that allows users to grant websites or applications access to their information on other sites without sharing their passwords. A familiar example is logging into a website using Google or Facebook (by clicking "Sign in with Google" or "Login with Facebook" links). In the case of the travel services company, OAuth enabled users to login to the company's site using their airline credentials.

As Salt Security explains it, when a user clicks on the login button to access the travel company's site, they are automatically redirected to the requisite airline company's login page for authentication. Once complete, the airline site sends an authorization code back to the travel company site, which initiates a process whereby the travel site receives an access token. The travel site then uses the token to request user data from the airline site.

**A Failure to Verify**

What Salt Security discovered was a weakness in the travel company's authentication flow that gave them a way to redirect the equivalent of a user's login credentials to their own server. "The specific issue here is that the travel company did not correctly verify that the sensitive authentication credentials were sent to a valid domain," says Yaniv Balmas, vice president of research at Salt Security. "By manipulating this flaw, we could force the travel company to send these credentials to us instead of the airline company, thus allowing us — or or a malicious actor abusing this — to take over the airline user account and perform any actions on their behalf."

To exploit the flaw, an attacker would have sent a malicious link, which would appear to be a valid airline link, via email or text message to users of airline sites integrated with the travel service provider. According to Salt Security, once a user clicks the link and successfully authenticates to an official airline service, the attacker gains full access to the user’s account within the travel system. "From the victim's perspective, it would be almost impossible to understand the link is malicious since it genuinely belongs to the airline, and there is no easy way to understand its malicious nature without an expert-level understanding of OAuth and authentication flows," he says.

**Common Issue**

The vulnerability with the unnamed travel company is more common that one might assume, Balmas says. In 2023, for instance, Salt Security discovered a similar vulnerability in Booking.com's OAuth implementation process that gave attackers a way to take over user accounts when using their Facebook accounts to log into the hotel reservation site. Another time, researchers from the company found OAuth implementation flaws involving Grammarly, Vidio, and Indonesian e-commerce site Bukalapak that gave attackers potential access to hundreds of millions of user accounts across multiple websites.

"The biggest issue here is that from the airline's perspective, there is absolutely no visibility in case an attack occurs, and in fact, an attack request will look completely identical to a legitimate one," Balmas notes. "This basically means that the third party — the travel company in this case—is the one responsible for the security and safety of its customer users." Often, he adds, there's no certainty that a third party will hold to the same security standards as its customer.

**About the Author**

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

OAuth Flaw Exposed Millions of Airline Users to Account Takeovers

Cybersecurity researchers have disclosed details of a now-patched account takeover vulnerability affecting a popular online travel service for hotel and car rentals.
"By exploiting this flaw, attackers can gain unauthorized access to any user’s account within the system, effectively allowing them to impersonate the victim and perform an array of actions on their behalf – including

OAuth Redirect Flaw in Airline Travel Integration Exposes Millions to Account Hijacking

Third-party API security requires a tailored approach for different scenarios. Learn how to adapt your security strategy to outbound data flows, inbound traffic, and SaaS-to-SaaS interconnections.

Source: Elena Uve via Alamy Stock Photo

COMMENTARY

API security often involves third-party, rather than first-party, APIs, and each use case can have different requirements. Rather than trying to make one technological approach work for all instances, security and risk management leaders must adapt their approach to the specific use case.

According to a recent Gartner survey, 71% of IT leaders report using third-party application programming interfaces (APIs) in their organizations. Many security and risk management leaders must focus on API security when dealing with consumption and integration with third-party APIs, rather than exposure of first-party APIs. 

In addition, when it comes to third-party APIs, many remediation measures, such as patching for exposures, are not under the organization's direct control. Therefore, the approach will have to be fundamentally different as compared to first-party APIs. 

Three use cases should be top of mind for these security leaders.

**Use Case 1: Discover and Manage Outbound Data Flows to Third-Party APIs**

In this first use case, the enterprise sends data to third parties via APIs, typically by invoking them from homegrown applications. In an e-commerce scenario, for instance, the service providing the API could be a payment gateway. In this example, the outgoing traffic would contain payment data used to process a payment. There are different ways to invoke the API from within the application, such as direct integration, using a software development kit or a webhook.

A main risk is that sensitive data may be sent toward the API. This activity may conflict with enterprise policies or industry regulations. Third-party APIs may also put the data, or the data of customers, in danger. For example, an attacker may be able to steal payment data from customers by using a vulnerable payment API. Depending on the scenario, injecting a malicious payload could also corrupt the database of a business partner.

In this scenario, security leaders should discover third-party APIs by performing traffic inspection, code repository inspection, and software composition analysis, as certain third-party APIs may be invoked via third-party libraries, not homegrown code.

Security leaders should also liaise with the team that manages sourcing, procurement, and vendor management (SPVM) and third-party cyber-risk to ensure software-as-a-service (SaaS) applications are vetted and comply with organizational policies.

Security leaders must also identify sensitive data exfiltration by monitoring the outgoing traffic in these API exchanges. This is typically achieved by implementing data loss prevention (DLP) capabilities. Disparate tools could apply—for example, security service edge (SSE), DLP, and API protection tools all have certain DLP capabilities.

*   Differentiators could include whether the tool can categorize data while in transit (“on the fly”) or whether it can perform remediation actions, such as blocking the exchange, anonymizing, or encrypting the data.
    
*   The monitoring point may also matter, as some tools may already be installed or have access to unencrypted traffic.
    
*   Most importantly, the way security leaders have configured a tool matters. If it is set up to act as a choke point, it could be a better option than a tool configured to process only specific types of traffic or incoming traffic, for example.
    
*   Internal considerations, such as which team owns and operates each tool, will also play a role in determining which tool to choose.
    

Finally, security leaders can implement proper authentication and authorization of the API client (in this scenario, the application) using the mechanisms offered by the API provider. At a minimum, favor tokens over API keys for authorization. Assess how opaque and proof-of-possession tokens (or at least frequently rotated access credentials) and certificate pinning may efficiently mitigate token leakage and interception risks in specific use cases. Be mindful of the technical burdens they may require to set them up and issues with traffic inspection.

**Use Case 2: Protect From Inbound Traffic From Third-Party APIs**

In this use case, the organization consumes the third-party API, and the data is incoming. A typical example could be an enterprise application that makes an API call to obtain data from a commercial SaaS provider or a business partner.

One risk in this use case is receiving potentially harmful input from the API. Malicious input from third-party APIs may endanger applications, its users, or the infrastructure hosting applications. For example, if an API response with a malicious payload is sent to a database, it could result in an injection attack.

Data exfiltration is still a risk for this use case, and many of the recommendations from the first use case still apply here. If the outgoing API request contains sensitive data, that data could be intercepted. For example, if an API call requests a list of restaurants based on GPS coordinates, said GPS coordinates could be intercepted if the connection is not secure. Most importantly, the third-party API could be fetching the specific data of the enterprise. (Think, for example, of an API fetching data about customers from specific instances of a CRM SaaS application.)

Security leaders should perform input validation. Ask developers to add input validation controls when ingesting any input, including input from third-party APIs. This will prevent a large spectrum of attacks from malicious input, such as SQL injection attacks. Application security testing (AST) tools can help automate these checks.

Use Web application firewall functionality from a Web application and API protection tool in-line to add contingencies against injection attacks and other types of malicious input.

Finally, vet the input with an antivirus, sandboxing, or content disarm and reconstruction solution by integrating applications typically via Internet content adaptation protocol or APIs with one or more of these tools.

**Use Case 3: Discover, Vet and Manage the Data for Third-Party Apps That Communicate via APIs**

Many security leaders are focused on API security but describe a scenario where one or more SaaS applications typically communicate via APIs, exchanging enterprise data. This issue can be exacerbated because users may be able to interconnect SaaS applications without having administrative privileges. While the underlying communication may be API-based, this problem's solution is closer to the best practices for SaaS security.

This situation is particularly challenging when an authorized SaaS application user connects it via API to an unauthorized SaaS app. Many organizations will have little to no visibility of the connection's existence, let alone of any data transfers across it. Second, visibility is limited to what SaaS providers reveal through their own management APIs, as there's no clear place to insert an in-line control. The main risk with this scenario is that the SaaS application may expose sensitive enterprise data via the API, and that data may be transferred to an unapproved and even unknown location that security has not vetted.

Security leaders should discover the SaaS applications used by performing a census, releasing a policy, and inspecting traffic. Use SSE, firewalls, SaaS management platforms, or other tools to identify the SaaS applications users are accessing, especially those housing sensitive data. Until they know what applications users are accessing, they cannot check for SaaS-to-SaaS connectivity

Discover rogue SaaS access tokens by querying the SaaS applications used, where supported. Create and promote policy to users about connecting SaaS apps via OAuth.

For the previous use cases, liaise with the team that manages SPVM and third-party cyber-risk to ensure SaaS applications are vetted and comply with organizational policies, such as data security and third-party sharing ones. In addition, inventory SaaS-to-SaaS interconnections; automated tooling, such as SSPM offerings, can help ensure this is a continuous process.

By adapting their approaches to these three specific use cases and their possible variations, security leaders can address the risks that third-party APIs present for their organizations.

**About the Author**

VP Analyst, Gartner

Dionisio Zumerle is a VP Analyst at Gartner, where he is currently focused on application and mobile security topics. Zumerle's coverage includes API security, mobile application security, DevSecOps, and mobile threat defense.

3 Use Cases for Third-Party API Security

An extension point in Jenkins allows selectively disabling cross-site request forgery (CSRF) protection for specific URLs. Bitbucket Server Integration Plugin implements this extension point to support OAuth 1.0 authentication.

In Bitbucket Server Integration Plugin 2.1.0 through 4.1.3 (both inclusive) this implementation is too permissive, allowing attackers to craft URLs that would bypass the CSRF protection of any target URL.

Bitbucket Server Integration Plugin 4.1.4 restricts which URLs it disables cross-site request forgery (CSRF) protection for to the URLs that needs it.

1.  GitHub Advisory Database
2.  GitHub Reviewed
3.  CVE-2025-24398

**Bitbucket Server Integration Plugin allows bypassing CSRF protection for any URL**

High severity GitHub Reviewed Published Jan 22, 2025 to the GitHub Advisory Database • Updated Jan 22, 2025

**Package**

maven io.jenkins.plugins:atlassian-bitbucket-server-integration (Maven)

**Affected versions**

\>= 2.1.0, < 4.1.4

An extension point in Jenkins allows selectively disabling cross-site request forgery (CSRF) protection for specific URLs. Bitbucket Server Integration Plugin implements this extension point to support OAuth 1.0 authentication.

In Bitbucket Server Integration Plugin 2.1.0 through 4.1.3 (both inclusive) this implementation is too permissive, allowing attackers to craft URLs that would bypass the CSRF protection of any target URL.

Bitbucket Server Integration Plugin 4.1.4 restricts which URLs it disables cross-site request forgery (CSRF) protection for to the URLs that needs it.

**References**

*   https://nvd.nist.gov/vuln/detail/CVE-2025-24398
*   https://www.jenkins.io/security/advisory/2025-01-22/#SECURITY-3434

Published to the GitHub Advisory Database

Jan 22, 2025

Last updated

Jan 22, 2025

GHSA-qjw6-xvrm-5f2h: Bitbucket Server Integration Plugin allows bypassing CSRF protection for any URL

The flurry of non-human identity attacks at the end of 2024 demonstrates extremely strong momentum heading into the new year. That does not bode well.

Itzik Alvas, Co-Founder & CEO, Entro Security

January 22, 2025

3 Min Read

Source: Brain light via Alamy Stock Photo

COMMENTARY

A look back at 2024's top non-human identity (NHI) attacks and their year-end explosion sends a worrying signal that 2025 is going to be a tough year for machine-to-machine identity theft.

One year ago, NHI burst onto the scene with a big warning flare, when Cloudflare disclosed that NHI mismanagement caused a massive breach, stemming from the failure to rotate an access token and account credentials exposed in the 2023 Okta compromise. 

While the attack was contained, the impact on Cloudflare was nonetheless significant. The company disclosed it had to rotate every production credential (more than 5,000 individual credentials), physically segment test and staging systems, perform forensic triages on 4,893 systems, and then reimage and reboot every machine in its global network.

As the year progressed, NHI breaches gained momentum.

In June, the New York Times made its own news when 270GB of its internal data and applications in 5,000 repositories were stolen from GitHub and published on the Web. 

How? The breach was executed using NHI when an exposed GitHub Personal Access Token, a machine-to-machine secret, allowed unauthorized access to the company's code repositories. The "All the News That's Fit to Print" outlet downplayed the story. Cybersecurity experts did not agree, however, arguing that source-code leaks can have wide-ranging implications.

**High-Profile Breach Disclosures**

The year ended with a spate of high-profile breach disclosures attributed to NHI during the fourth quarter. 

Thousands of online stores running Adobe Commerce (formerly Magento) software were hacked and infected with digital payment skimmers. The NHI attack used stolen cryptographic keys to generate an application programming interface (API) authorization token, enabling the attacker to access private customer data and insert payment skimmers into the checkout process.

AWS and Microsoft Azure machine-to-machine authentication keys found in Android and iOS apps used by millions were compromised, exposing user data and source code to security breaches. Exposing this type of credential can easily lead to unauthorized access to storage buckets and databases with sensitive user data. Apart from this, attackers could use them to manipulate or steal data.

Schneider Electric confirmed its development platform was breached after a hacker used exposed Jira credentials to steal data. The hacker gloated that the breach compromised critical data, including projects, issues and plug-ins, along with over 400,000 rows of user data, totaling more than 40GB of compressed data,

The Cybersecurity and Infrastructure Security Agency (CISA) warned that attackers were exploiting a critical missing authentication vulnerability in Palo Alto Networks Expedition, a migration tool that can help convert firewall configuration from Checkpoint, Cisco, and other vendors to PAN-OS. This security flaw enabled threat actors to remotely exploit it to reset application admin credentials on Internet-exposed Expedition servers.

A new sophisticated phishing tool targeting GitHub users was also revealed in the fourth quarter. It posed a significant threat to developers and organizations worldwide. Here's how this relates to NHIs: Bots used a compromised secret and set of permissions associated with that credential as the ingredients to make the API calls and create comments using a script.

The comments themselves convinced developers to use insecure scripts as validated solutions.

These scripts, in turn, could lead victims to phishing pages designed to steal login credentials, malware downloads, or rogue OAuth app authorization prompts granting attackers access to private repositories and data.

Finally, and bringing the year to a dramatic close, NHI was responsible for the US Treasury hack by Chinese threat actors, who gained access to "unclassified documents" after compromising the agency's networks. The attackers were able to exploit vulnerabilities in remote tech support software by misusing a leaked API key to gain unauthorized access.

The flurry of NHI attacks at the end of the year demonstrates extremely strong momentum heading into 2025. That does not bode well. 

Chief information security officers (CISOs) and security teams need to prioritize the emerging NHI threats roaring into the new year.

**About the Author**

Co-Founder & CEO, Entro Security

Itzik Alvas is co-founder and CEO at Entro Security and former healthcare organization CISO and information technology manager at Microsoft.

A cloud and security expert with more than 17 years of experience managing and building teams of hundreds of employees for both leading global enterprise companies and early-stage startups, always at the forefront of state-of-art security solutions used by governments, top intelligence agencies, data centers, cloud providers and industrial markets. Itzik served with the IDF's elite intelligence unit.

Tag

#oauth