ThreatsDay Bulletin: FortiGate RaaS, Citrix Exploits, MCP Abuse, LiveChat Phish & More

Cybersecurity threats rarely come with a bang and fanfare. The most dangerous ones operate quietly, imperceptibly, woven into the everyday operations of IT infrastructure. Last week's ThreatsDay Bulletin report is an excellent example of how seemingly minor security gaps can become attack vectors exploited on a corporate scale. Instead of one spectacular exploit, we're dealing with a set of smaller, but extremely practical penetration methods — from FortiGate RaaS to MCP protocol abuse and phishing campaigns on LiveChat. This is not a story about how thieves break through the front door. This is a story about how they pass through all the other entrances.

In a world where enterprises invest billions in advanced perimeter protection, they paradoxically expose themselves to attacks exploiting old, known vulnerabilities. The report shows a certain trend that should concern every CISO: the simplest methods work best, and employee education cannot replace solid security architecture. The Polish IT industry, rapidly growing and increasingly interested in digital transformation, faces this same challenge. Companies migrate to the cloud, implement remote solutions, but the foundations of their security remain weak.

FortiGate RaaS: When a Security Device Becomes a Gateway for Attackers

Fortinet is one of the world's largest providers of security devices, and its FortiGate is practically a standard in corporate networks. That's why the discovery that FortiGate can be exploited as Ransomware-as-a-Service (RaaS) is particularly alarming. Attackers are not looking for a way to break into the network through the device — they're doing something far more effective. They use it as infrastructure for their ransomware operations.

The mechanism is simple, but brilliant. Instead of building their own infrastructure, cybercriminals exploit already existing, well-secured devices that companies bought precisely to defend themselves against them. FortiGate, being a gateway between the internal network and the outside world, has access to sensitive data and systems. If attackers gain access to the device — through an undiscovered vulnerability, weak administrative password, or social engineering — they can reconfigure it to act as a control point for ransomware campaigns.

In Poland, where many medium-sized companies rely on FortiGate as their only advanced security device, the risk is particularly high. Companies rarely update firmware regularly, and even more rarely monitor administrative access logs. This means attackers can operate in the shadows for weeks before anyone notices an anomaly.

• Exploiting weak administrative passwords to FortiGate
• Exploiting known CVE vulnerabilities in older firmware versions
• Configuring the device as a proxy for ransomware traffic
• Masking malicious traffic as normal network traffic
• Storing infected files in the device's cache

The problem is that most companies treat security devices as a black box — install, configure once, and forget. Administration amounts to adding new firewall rules, not regularly auditing the security of the device itself. This is exactly what attackers are counting on.

Citrix Exploits: When a Remote Access Application Becomes a Door for Intruders

Citrix is another giant in the world of IT infrastructure — its remote access solutions are ubiquitous in large organizations. However, Citrix's story is a story of repeated security mistakes that companies discover, patch, and then discover again a few years later.

The latest series of Citrix exploits concerns Citrix NetScaler, a device that manages remote access for thousands of employees. The vulnerability allows unauthorized access to the system without the need to possess valid credentials. Attackers can simply bypass the authentication mechanism and enter the network as if they were authorized users.

In Poland, where remote work has become the norm and many companies have made their operations dependent on Citrix, this vulnerability has direct consequences. An employee of company X may be attacked with phishing, but even if they don't click the link, attackers can simply bypass Citrix and access the network directly. This means that traditional phishing campaigns can be strengthened with direct access to infrastructure.

Citrix is not the only player in remote access, but it is one of the most popular. This means that every vulnerability in Citrix has the potential to affect tens of thousands of organizations simultaneously.

The response to these exploits is of course software updates, but many companies wait months before deploying a patch. The reasons are mundane: lack of testing in a production environment, concerns about remote access downtime, lack of IT resources. Meanwhile, the vulnerability window remains open.

MCP Abuse: When a Protocol for Developers Becomes an Attack Tool

Model Context Protocol (MCP) is a relatively new standard that allows AI applications to better communicate with external systems. It sounds innocent, but in the hands of attackers it becomes a powerful tool. MCP enables an application to access system resources, databases, and APIs — all under the guise of normal operation.

MCP abuse involves attackers injecting malicious instructions into an AI system that are executed with the application's permissions. If the AI application has access to a customer database, attackers can command it to "export all data to an external server". If it has access to the file system, it can command "delete all access logs".

The problem is that most companies implementing AI don't think of MCP as an attack vector. They focus on making AI more useful, not on restricting its permissions. This is the classic "security by obscurity" approach — we assume no one will think of the attack, so we don't secure it.

• Injecting instructions into AI systems through prompt injection
• Data exfiltration through APIs connected with MCP
• Modifying business logic of applications through context manipulation
• Privilege escalation through a chain of MCP commands
• Bypassing audit through operations performed in AI context

In the Polish AI startup ecosystem, where companies quickly implement new technologies without deep security audits, this threat is particularly real. A startup might integrate MCP with a CRM system to help AI better serve customers, but doesn't realize they've just opened a backdoor for attackers to the entire customer database.

Phishing Campaigns on LiveChat: When a Communication Channel Becomes an Attack Vector

LiveChat is a popular customer communication platform used by thousands of companies worldwide. It is also an excellent vector for phishing campaigns because users are accustomed to clicking links and downloading files from this channel.

The latest phishing campaign uses LiveChat to distribute malicious links that lead to pages imitating popular services — banks, email, payment platforms. A user clicking on a link thinks they're talking to a company representative, but actually lands on a page controlled by attackers.

The genius of this approach is that attackers don't need to compromise a LiveChat account. They simply create a new account, give it a credible name (e.g., "Support Team"), and then wait for someone to accept it. Many companies have weak verification of new contacts, especially when they appear to be from vendors or business partners.

In Poland, where LiveChat is popular among e-commerce and service companies, this method is particularly effective. A customer service employee, accustomed to receiving inquiries from customers, can easily miss that the "customer" is actually an attacker trying to manipulate them into clicking a link or revealing confidential information.

Defense against this type of attack requires education, but also technology. Companies should implement links with phishing protection that scan the target page before redirecting the user. They should also regularly test their employees with simulated phishing campaigns.

Zero Trust Network Access: From VPN to Real Security

All these threats — FortiGate RaaS, Citrix exploits, MCP abuse, and LiveChat phishing — point to one fundamental problem: the traditional network security model is dead. For decades, companies relied on VPN networks and perimeter firewalls to protect their infrastructure. The assumption was simple: if you're inside the network, you're safe.

The problem is that this model doesn't work in a world of remote work, cloud computing, and API access. An employee working from home doesn't need access to the entire corporate network — they need access to a few specific applications. VPN gives them access to everything, which opens the door for attackers who once get into the network.

Zero Trust Network Access (ZTNA) is a new paradigm that rejects the assumption "safe inside, dangerous outside". Instead, ZTNA assumes that every access must be verified, regardless of whether it comes from inside or outside the network. An employee wants access to a CRM application? The system checks their identity, device, location, behavior — and only then grants access to the specific application, nothing more.

• Identity verification using multi-factor authentication
• Device health check (whether antivirus is installed, whether the system is updated)
• Behavior analysis (whether the user is logging in from an unknown location, whether they're downloading an unusual amount of data)
• Access to specific applications, not the entire network
• Continuous monitoring and ability to immediately revoke access

ZTNA is not just security — it's also convenience. An employee doesn't have to configure VPN, doesn't have to wait for a connection, they simply log into a portal and have access to the applications they need. For companies, this means lower infrastructure costs (no need to maintain expensive VPN servers) and better visibility of who does what.

Practical Implementation of ZTNA in Polish Companies

The theory of ZTNA is beautiful, but practice is more complicated. Implementing ZTNA requires not only new tools, but also a change in thinking about security. Companies must map all the applications employees need, determine who has access to what, and implement a system that will enforce it.

In Poland, where many companies still use older systems and applications that weren't designed with ZTNA in mind, this can be a challenge. An old application written 15 years ago may not support modern authentication protocols. Integration with existing Active Directory infrastructure may be complicated.

However, companies that decide to go with ZTNA can expect a significant reduction in risk. Instead of worrying about whether their FortiGate is secure or whether Citrix is patched, they can focus on ensuring that every access is justified and monitored.

Implementing ZTNA is a gradual process. Companies can start with a pilot — select one application, implement ZTNA for that access, gather experience, and then expand. The most important thing is to start now, before the next wave of attacks forces them to act under time pressure.

Eliminating Lateral Movement: The Last Line of Defense

Even if attackers get into the network — and statistically, most companies will experience a breach within a year — ZTNA can reduce damage by eliminating lateral movement. Lateral movement is when attackers, after gaining access to one system, try to move to other systems on the network.

In the traditional network model, when attackers get into one computer, they can move around the network almost unimpeded. All systems trust each other because they're on the same network. ZTNA changes this — every access, even between internal systems, requires verification.

This means attackers cannot simply move from an infected employee's computer to a database server. They would have to re-authenticate, and the system could detect an anomaly — for example, that the access is coming from an unknown device or at an unusual time.

This is a fundamental change in network security architecture. Instead of relying on the perimeter being secure, we rely on every access point being secure. It's more labor-intensive, but also significantly more effective in practice.

The Future of Access Security: Not VPN, but ZTNA

The ThreatsDay report shows a clear trend: traditional security devices — VPN, firewalls, even advanced solutions like FortiGate — are not sufficient. For decades, companies relied on them to protect their infrastructure. Attackers have found ways to bypass them, and companies remain on the defensive, constantly patching holes instead of building a fundamentally more secure architecture.

ZTNA is not a panacea — no security system is. But it's a significantly better approach than relying on VPN and firewalls. It allows companies more precise access control, better visibility of what's happening on the network, and faster anomaly detection.

For Polish companies rapidly digitizing and transitioning to remote work, the choice is clear: either invest in traditional security solutions and hope they're sufficient (which is doubtful), or move to ZTNA and be confident that you're doing everything in your power to protect your infrastructure. Given the number of threats described in the ThreatsDay report, the second option seems far more sensible.