Agentic AI with Social Engineering, JavaScript Stealer and the Silent Lynx
The cybersecurity landscape is evolving rapidly, with organizations facing increasingly sophisticated threats and vulnerabilities across various attack surfaces. Critical security flaws, like the recently patched Cisco ISE vulnerabilities, highlight the risks posed by privilege escalation and remote code execution exploits. Meanwhile, advanced threat actors such as Silent Lynx are employing multi-stage cyberattacks using PowerShell, Golang, and C++ loaders to infiltrate government entities and financial institutions, demonstrating a growing emphasis on espionage. At the same time, cybercriminals are leveraging AI to automate phishing, malware development, and large-scale fraud, putting additional pressure on Security Operations Center (SOC) analysts who are already overwhelmed by alert fatigue and manual processes. To counter these challenges, organizations are increasingly adopting AI-driven security solutions to enhance efficiency, automate threat detection, and strengthen their overall cyber resilience. The arms race between attackers and defenders continues, making proactive security strategies more critical than ever.A Closer Look at mTLS and the Default Server in F5 NGINX
When you connect to an HTTPS site, your browser (or other client) typically sends a Server Name Indication (SNI)—the hostname it wants to reach—during the TLS handshake. This lets F5 NGINX figure out which cryptographic settings to use for that specific hostname. In other words, SNI influences: Which x509 certificate is sent to the client Which cryptographic algorithms are offered Which session ticket key is used for encrypting and decrypting session tickets Which session cache is active, if you’re using caching Which Certificate Authority (CA) is checked when you require mutual TLS (mTLS) If the client doesn’t provide SNI or if the hostname doesn’t match any of your configured server_name directives, F5 NGINX defaults to a “fallback” setup—usually called the default server. That means: The default server’s certificate, ciphers, ticket key, and session cache get used automatically. If you haven’t explicitly marked any server block as default_server, F5 NGINX chooses the first block for that listen socket in your configuration as the fallback. Here’s the crucial detail: once the TLS handshake finishes and a certificate has been selected (for example, from the default server), F5 NGINX will still examine the HTTP Host header for request routing. If it specifies a different domain matching another server block, the request is forwarded there at the HTTP layer. From the client’s perspective, however, the originally cryptographic settings remain in effect, because the TLS negotiation is already complete. Single Server Block In the simplest configuration, only one server block listens for TLS connections on a given IP address and port: server { listen 443 ssl; server_name example.com; ssl_certificate /etc/ssl/certs/example.com.crt; ssl_certificate_key /etc/ssl/private/example.com.key; ssl_client_certificate /etc/ssl/certs/ca.crt; ssl_verify_client on; # Additional configuration, such as locations and logging } In this example: If the client provides SNI matching example.com, F5 NGINX presents /etc/ssl/certs/example.com.crt and verifies the client certificate against /etc/ssl/certs/ca.crt. If the client does not provide SNI, this same server block still handles the request because there are no other blocks to consider; the same certificate and CA (ca.crt) apply. Once authenticated, the client proceeds under the cryptographic settings of this single server block. With only one server block present, there is no additional routing or fallback scenario to manage. Multiple Server Blocks on the Same IP/Port When multiple server blocks listen on the same IP address and port, F5 NGINX uses SNI to determine which server block should handle the request. If no matching SNI is found, requests fall back to the server marked with default_server. As previously stated, if the default_server is not explicitly defined, F5 NGINX will use the first server block in the configuration as the fallback. # example.com and the default server (first in config) server { listen 443 ssl; server_name example.com; ssl_certificate /etc/ssl/certs/example.com.crt; ssl_certificate_key /etc/ssl/private/example.com.key; ssl_client_certificate /etc/ssl/certs/ca_A.crt; ssl_verify_client on; # Additional configuration, such as locations and logging } # www.example.com server { listen 443 ssl; server_name www.example.com; ssl_certificate /etc/ssl/certs/www.example.com.crt; ssl_certificate_key /etc/ssl/private/www.example.com.key; ssl_client_certificate /etc/ssl/certs/ca_B.crt; ssl_verify_client on; # Additional configuration, such as locations and logging } In this example: If the client provides SNI matching example.com, the first server block’s certificate (example.com.crt) and CA settings (ca_A.crt) are used. If the client provides SNI matching www.example.com, the second server block’s certificate (www.example.com.crt) and CA settings (ca_B.crt) are used. If the client does not provide SNI (or provides an unmatched server name), the first server block (example.com) acts as the default. Its certificate (example.com.crt) and CA (ca_A.crt) apply for the TLS handshake. After TLS is established under the default server, if the HTTP Host header is www.example.com, F5 NGINX routes the request to the second server block for application-level processing. However, the TLS session—including which certificate and CA were used—remains with the default server’s settings. This means the second server’s client certificate configuration (ca_B.crt) is not involved in re-validating the client, since no new TLS handshake occurs. Recommendations The fallback behavior mentioned above might not fit all use cases. If it poses a risk or doesn’t align with your security needs, consider reconfiguring F5 NGINX (e.g., setting up a stub default server or applying tighter mTLS rules) to restrict or eliminate this fallback path. Defining a Default Server (or Stub Default Server) It is highly recommended to define a default server in F5 NGINX. If you do not want to allow fallback for clients without valid SNI, you can set up a stub default server (configuration example below). A stub default server, as shown below, ensures that unmatched SNI (or no SNI) connections are rejected at the handshake level, preventing unintended fallback to a less restrictive configuration. Perhaps most importantly, it does not contain any client authentication configuration directives, forcing client authentication to occur in the most specific server blocks. In the example below I have added `ssl_verify_client off;` for illustrative purposes, however the setting of `off` is the default. Note: ssl_reject_handshake appeared in nginx version 1.19.4. For versions prior to that, one can define a server that simply returns the special 444 HTTP response code. Authorization Checks in All Server Blocks Even with a stub default server, all server blocks should implement authorization checks if they serve sensitive content. Because requests may be forwarded from the default server to a non-default server after decryption, every server block must enforce its own mTLS policies and check variables such as $ssl_client_s_dn or $ssl_client_i_dn (if you rely on client certificates) to ensure consistent and robust security across your deployment. # explicit default server server { listen 443 ssl default_server; ssl_reject_handshake on; ssl_verify_client off; ssl_protocols TLSv1.2 TLSv1.3; } # example.com server { listen 443 ssl; server_name example.com; ssl_certificate /etc/ssl/certs/example.com.crt; ssl_certificate_key /etc/ssl/private/example.com.key; ssl_client_certificate /etc/ssl/certs/ca_A.crt; ssl_verify_client on; # Check subject DN if ($ssl_client_s_dn !~ "CN=TrustedClient_A,O=MyOrg") { return 403; } # Check issuer DN (this may not be necessary for all deployments) if ($ssl_client_i_dn !~ "CN=TrustedCA_A,O=MyOrg") { return 403; } # Additional configuration, such as locations and logging } # This server block handles requests for www.example.com server { listen 443 ssl; server_name www.example.com; ssl_certificate /etc/ssl/certs/www.example.com.crt; ssl_certificate_key /etc/ssl/private/www.example.com.key; ssl_client_certificate /etc/ssl/certs/ca_B.crt; ssl_verify_client on; # Check subject DN if ($ssl_client_s_dn !~ "CN=TrustedClient_B,O=MyOrg") { return 403; } # Check issuer DN (this may not be necessary for all deployments) if ($ssl_client_i_dn !~ "CN=TrustedCA_B,O=MyOrg") { return 403; } # Additional configuration, such as locations and logging } Conclusion In summary, working with multiple server blocks, SNI, and mTLS can make F5 NGINX setups more complex. Knowing precisely which server block handles the TLS handshake—particularly when there is no SNI or an unmatched name—helps maintain the desired security posture. Careful attention to these details keeps certificates and policies consistent for all client connections.Copilot’s Weakness, DeepSeek Data exposed, Backdoor in Contec CMS8000 & Apple's Zero-Day
Notable security news for the week of Jan 26th-1st Feb 2025, brought to you by the F5 Security Incident Response Team. This week your editor is Dharminder. In this edition, I have security news about weakness in GitHub’s Copilot - where a simple word “sure” can drastically change its response and much more, Wiz Research discovered DeepSeek’s database, accessible without authentication, contained over a million log entries, including chat history, API keys, backend details, and operational metadata, FDA’s warning on backdoor and some other vulnerabilities discovered in Contact CMS8000 patient monitor and Fix of Zero-Day vulnerability in Apple OS exploited in wild is released.A Very Chinese New Year
Happy New Year everyone! It's a new year, with new news, and the same old(er) MegaZone. This time we're looking at the news that I found worthy from the week of January 5-11, 2025. (Have you gotten used to typing 2025 yet?) I found it to be a fairly slow news week, and not much really grabbed my attention enough that I felt it was worth commenting on. That's not too unusual for the start of a new year, as there is often a bit of a post-holiday lull. Not that there was no news at all, it is never truly quiet in cybersecurity, just that most of it was run-of-the-mill stuff, IMHO. Oh, and as for the title of this 'issue', I know the Lunar New Year (aka Chinese New Year) isn't until January 29th, but I couldn't pass up the play on words given the topic below. And with that, let's dive in.Cyber security 2024 summary and 2025 forecasts from the news
Notable security news for the week of Dec 22 nd – Dec 28 th 2024. This week editor is Lior from F5 SIRT. As always, when a year ends, security websites and vendors summarize the most significant security issues that happened over the past year. And with every end, there is a beginning. Enter 2025 cybersecurity predictions: what will happen this year in the world of cybersecurity? Here is what I summarized regarding the end of year 2024 and 2025 prediction in the cybersecurity landscape. 2024 cyber summary In 2024, the cybersecurity landscape was marked by significant incidents and evolving threats, with "more" being the keyword — more of everything. CVE details show a record number of 40,152 CVEs, around 10k more than last year. The CISA site - Known Exploited Vulnerabilities Catalog - shows significant growth in the actual exploitation of vulnerabilities. Large-scale incidents such as the Snowflake Data Breach, Salt Typhoon, and Fileless Malware, along with many other names that no one can really remember, have occurred. Then the true nature of software unexpectedly reveals itself, as seen in the CrowdStrike incident. One of the major breakthroughs in technology is the emergence of generative AI chatbot platforms, and as with any new technology, there is a need to secure it. Generative AI chatbots are becoming popular in web applications and are used to assist with specific, tailored actions relevant to users. These AI-driven chatbots use a wrapper on a commercial chat using APIs to operate, creating a whole new playground for attacks that now try to “convince” the chat to provide details it shouldn’t. Sounds familiar? totally familiar, but this time it is not XSS or SQLi; it is the LLM itself. Which is a great opportunity to mention the F5 AI Gateway. I guess we can consider 2024 as a year with unprecedented levels of security events (see my 2024 prediction more of everything). Enter 2025 So now you can ask yourself, will this continue in 2025 at the same growing rates? For sure! And will cybersecurity in 2025 be the year of AI security expansion? Beyond securing LLMs themselves, threat actors are expected to leverage artificial intelligence (AI) to enhance the sophistication of their attacks. This includes the use of AI for crafting more convincing phishing schemes, automating social engineering tactics, and deploying deepfakes for identity theft and fraud. But AI can also be used for protection and cyber defense: Integration of AI in Security Operations Centers (SOCs): AI is anticipated to play a central role in SOCs, automating tasks such as threat detection, vulnerability assessments, and incident response. Human analysts will focus on strategic decision-making and handling complex threats, enhancing overall operational efficiency. Security "co-pilots": AI-driven security operations centers (SOCs) will improve threat detection and automate incident response. Security controls assessment powered by AI: Using "AI Cyber Governance Platforms," AI will assist security personnel in understanding the real value of their security products and services, optimizing their arsenal to maximize protection. Agentic AI: Agentic AI is a software program designed to independently make decisions and take actions to achieve specific goals. Agentic AI is trending due to its ability to autonomously help CIOs realize their vision for generative AI to increase productivity. This all means that we are facing an even more intense year and as they say, "It is going to be interesting." Recommended reading: The Top 25 Security Predictions for 2025 New vulnerabilities While summarizing and doing prediction is nice exercise, the reality is that we have new vulnerability every week, here are two of them from last week: New critical Apache Struts flaw exploited to find vulnerable servers A recently patched critical Apache Struts 2 vulnerability tracked as CVE-2024-53677 is actively exploited using public proof-of-concept exploits to find vulnerable devices. Apache publicly disclosed the Struts CVE-2024-53677 flaw (CVSS 4.0 score: 9.5, "critical")” at Dec 11”, stating it is a bug in the software's file upload logic, allowing path traversals and the uploading of malicious files that could lead to remote code execution. "We are seeing active exploit attempts for this vulnerability that match the PoC exploit code. At this point, the exploit attempts are attempting to enumerate vulnerable systems," reports Ullrich. https://www.bleepingcomputer.com/news/security/new-critical-apache-struts-flaw-exploited-to-find-vulnerable-servers/ Palo Alto Releases Patch for PAN-OS DoS Flaw — Update Immediately Palo Alto Networks has disclosed a high-severity vulnerability impacting PAN-OS software that could cause a denial-of-service (DoS) condition on susceptible devices. The flaw, tracked as CVE-2024-3393 (CVSS score: 8.7), "A denial-of-service vulnerability in the DNS Security feature of Palo Alto Networks PAN-OS software allows an unauthenticated attacker to send a malicious packet through the data plane of the firewall that reboots the firewall," the company said in a Friday advisory. Palo Alto Networks said it discovered the flaw in production use, and that it's aware of customers "experiencing this denial-of-service (DoS) when their firewall blocks malicious DNS packets that trigger this issue." https://thehackernews.com/2024/12/palo-alto-releases-patch-for-pan-os-dos.html https://security.paloaltonetworks.com/CVE-2024-3393 Podcasts recommendation Finally, I have listen to those podcasts in the past week and they are worth the time spending on. Podcast - Three Buddy Problem Palo Alto network edge device backdoor, Cyberhaven browser extension hack, 2024 research highlights. https://securityconversations.com/episode/palo-alto-network-edge-device-backdoor-cyberhaven-browser-extension-hack-2024-research-highlights/ F5 DC : Announcing the new 'AI Friday' Podcast - Episode 1 Our own F5 folks talk about AI in a new podcast. Great job, looking forward for the next chapter. https://community.f5.com/kb/technicalarticles/announcing-the-new-ai-friday-podcast---episode-1/338527 See you all next year.Attacks against Domain Specific Languages, EU Cybersecurity Laws, & Supply Chain Attacks
Jordan_Zebor is your editor once again for this issue of This Week In Security. This week I will cover some interesting research which highlights Attacks against Domain Specific Languages, some new EU Cybersecurity Laws, & a few more instances of Supply Chain Attacks. Attacks against Domain Specific Languages The article highlights new attack techniques discovered in Open Policy Agent (OPA) and Terraform by security researcher Shelly Raban, who uncovered vulnerabilities in the supply chain and configuration management of these infrastructure-as-code and policy-as-code tools. The research explores how attackers can exploit these DSLs to compromise cloud identities, enable lateral movement, and exfiltrate data through various malicious techniques, such as credential theft and DNS tunneling. Open Policy Agent (OPA) Attacks OPA, a policy engine, uses Rego, a domain-specific language (DSL), to make policy decisions. Attackers can exploit vulnerabilities in OPA's supply chain by gaining access to the policy storage and uploading malicious policies. Once the malicious policy is fetched during a regular update, it can execute harmful actions like credential exfiltration. This can be done by abusing OPA's built-in functions, such as opa.runtime().env for accessing environment variables or http.send for exfiltrating sensitive data to an external server. Additionally, attackers can use DNS tunneling via the net.lookup_ip_addr function to stealthily transmit sensitive information, such as credentials, to a malicious server. Terraform Attacks Terraform, a popular Infrastructure-as-Code (IaC) tool, uses the HashiCorp Configuration Language (HCL) for declarative configurations. Terraform's CI/CD pipelines often run the terraform plan phase on pull requests, which can inadvertently trigger malicious code execution if a pull request includes a compromised module or data source. One risk arises from the use of external and HTTP data sources, which can be manipulated to exfiltrate sensitive information, such as AWS credentials, to an attacker-controlled server. Terraform also uses provisioners like local-exec and remote-exec, which can run arbitrary code on the local or remote infrastructure, making them a target for attackers who could deploy malicious scripts or even cryptocurrency miners. These attack techniques highlight the importance of securing IaC and PaC tools to prevent malicious code from being executed during the infrastructure provisioning or policy evaluation phases. New EU Cybersecurity Laws The new cybersecurity laws in the EU establish a European Cybersecurity Alert System and amend the Cybersecurity Act of 2019 to enhance security standards for managed security services. The first law creates a pan-European network of cyberhubs to improve coordinated threat detection and response across borders, leveraging AI and advanced data analytics. It also introduces a Cybersecurity Emergency Mechanism and a European Cybersecurity Incident Review Mechanism to support member states in preparing for and recovering from major cyberattacks. The second law focuses on certifying managed security services, ensuring higher quality and reducing market fragmentation by creating a unified certification scheme. These laws are beneficial because they foster stronger international collaboration, improve threat detection and response, and enhance the quality of cybersecurity services across Europe. By using data analytics, the alert system can enable faster and more effective responses to cyberattacks. However, the laws may also have potential drawbacks, such as the complexity of managing cross-border cooperation and ensuring privacy while sharing sensitive threat information. Software Supply Chain Attacks Software supply chain attacks involve the compromise of trusted software packages or their distribution channels to introduce malicious code that can harm users. The Ultralytics AI library, a widely used Python package for artificial intelligence applications, and the Solana Web3.js JavaScript SDK, utilized by decentralized applications to interact with the Solana blockchain, were both targeted in separate incidents that exploited vulnerabilities in their build processes to inject malicious payloads. Ultralytics AI The Ultralytics AI module, a popular Python package for AI, was compromised in a supply chain attack that introduced a cryptocurrency miner in versions 8.3.41 and 8.3.42. The malicious code, which caused high CPU usage, was injected through a vulnerability in the library's build environment via GitHub Actions Script Injection. After being flagged by a researcher, the compromised versions were removed, and a new release fixed the security flaw. While the payload was a miner, more severe malware risks, like backdoors, remain a concern. Solana Web3.js In a separate attack, the Solana Web3.js JavaScript SDK was modified to steal private keys from developers and users in versions 1.95.6 and 1.95.7. The malicious "addToQueue" function exfiltrated keys, sending them to an attacker-controlled server. The breach occurred via a compromised publish-access account. Developers were advised to upgrade to the latest release and rotate keys. The stolen funds amounted to an estimated $184,000. That's it for this week. Hope you enjoyed the content.
