Security Boulevard

via the comic humor & dry wit of Randall Munroe, creator of XKCD

Permalink

The post Randall Munroe’s XKCD ‘Origami Black Hole’ appeared first on Security Boulevard.

Navigating the job market can feel like a final boss battle in a video game—thrilling, challenging, and filled with traps. Unfortunately, work-from-home scams are some of the trickiest villains you’ll encounter on this quest. They disguise themselves as legitimate opportunities, preying on jobseekers eager to land their dream roles.

The post Time for a new job—9 work-from-home scams and how to spot them appeared first on Security Boulevard.

Authors/Presenters: Panel

Our sincere appreciation to DEF CON, and the Authors/Presenters for publishing their erudite DEF CON 32 content. Originating from the conference’s events located at the Las Vegas Convention Center; and via the organizations YouTube channel.

Permalink

The post DEF CON 32 – Preparing for the Future: A Discussion of Our Rapidly Evolving Threat Landscape appeared first on Security Boulevard.

I recently caught up with Karissa Breen, the founder of KBI.Media, and we got straight into our topic: What is breach readiness and business continuity planning in complex environments? Everyone talks about having a plan, but actually putting it into action, especially when you’re under attack, is a completely different story. Realities of Breach Readiness […]

The post Breach Readiness and Business Continuity Planning appeared first on ColorTokens.

The post Breach Readiness and Business Continuity Planning appeared first on Security Boulevard.

Introduction

Web applications and APIs are critical parts of your attack surface, but managing WAFs has never been easy.  False positives, rule tuning, risks of production outages, and log analysis - all of this work has made WAF historically difficult to operationalize.

Well, that time is over.  Meet Impart’s WAF Squad - a five-member squad of AI assistants superheroes dedicated to making web application security not just manageable, but downright fun!

In this blog post, you’ll see why these Assistants aren’t just toys —they’re here to revolutionize how you protect your apps and data - IN PRODUCTION.

WAF his a hard space to play

WAF has always been a historically challenging space to work in because of the intersection of multiple personas within a organization.  Unlike other appsec tools like DAST, which are primarily controlled and managed by the application security team with very few other stakeholders, WAF has many stakeholders with different focus areas and priorities.  WAF historically has impacted SRE teams, software engineers, architects, SOC teams, as well as application security teams.   One tiny mistake by any of these teams can have a huge impact on all of them, which carries significant risk.  That’s why so many organizations get so little value out of their WAF, with most of their rules turned off or in non-blocking mode.

‍

At Impart, we have decades of operational experience working with all of these types of teams across hundreds of customers, along a wide range of production environments.  Over the years we’ve been able to identify most of the common operational and implementation pitfalls associated with each persona and have developed playbooks and tactics to still be successful.

Team of Assistants approach

Many companies in the information security space have different types of assistants and chatbots bolted onto their SaaS offerings.  These assistants have largely been gimmicks, not trusted enough to do anything in production.  The most egregious I’ve encountered are AI chatbots which summarize developer documentation for security teams, which is a solution in search of a problem and doesn’t consider the different personas involved in a typical security team.

Our core insight from working in the WAF space for so long is that security is a team sport.  It’s not enough to have a general purpose security assistants working on a security problem - there needs to be multiple security assistants, each with a different focus area and different expertise, which work together seamlessly in the same manner that an effective security team works together with other stakeholders in their organization.

How We Built Our WAF Assistants

Building out a suite of AI-driven WAF Assistants wasn’t just about slapping some algorithms onto a firewall—it was about solving real-world security problems experienced by the people in the trenches. We started by mapping out the key personas in a typical WAF deployment: the SRE responsible for rolling out and monitoring performance, the AppSec engineer tasked with analyzing behavior and spotting threats, the Detection and Response engineer creating effective security policies, the Product Security specialist ensuring alignment with business goals, and the SOC analyst managing day-to-day operations and investigations.

Once we had these roles pinned down, we identified their most critical “jobs to be done,” such as monitoring resource usage, discovering risky endpoints, crafting targeted detection rules, refining policies to meet product objectives, and triaging potential incidents. By translating each job into a set of repeatable tasks, we saw a clear path for AI agents that could automate or assist these responsibilities.

From there, we built out five specialized WAF Assistants, each tailored to a core persona. Finally, we integrated them into the Impart data fabric natively so they could seamlessly share findings and data with each other:  threat findings from one Assistant inform detection rules in another, and policy changes are instantly visible to the entire stack. The end result is a coordinated security “dream team” that unburdens human experts and ensures your WAF remains agile and effective—no matter how quickly your environment changes.

Meet the Dream Team

1. Inspector – The detective who uncovers shadow endpoints, outdated libraries, and all those forgotten subdomains. If there’s a dark corner, Inspector’s flashlight finds it.
2. Rule Writer – The coding wizard turning Inspector’s insights into targeted, accurate WAF rules. No more bloated rule sets that miss the mark.
3. Architect – The master planner ensuring your security policies scale effortlessly across cloud, hybrid, or on-prem. Whether you’re building a small fortress or a mega-fortified city, Architect has you covered.
4. SOC Analyst – The 24/7 sentinel, correlating alerts in real time and triaging incidents before they blow up. Think of it as your trusty night watch.
5. Installer – The DevOps whiz who rolls out WAF deployments without the drama. Quick, painless, and no downtime migraines.

Alone, each Assistant shines. Together, they’re an all-star team capable of thwarting zero-day threats, locking down new APIs, and ensuring your security strategy doesn’t crumble under the next wave of attacks.

How They Work Together on Impart

Imagine a platform where all five heroes hang out, share intel, and tackle threats the moment they appear. That’s Impart. Instead of bouncing between separate dashboards, you get a single command center. Inspector flags a suspicious endpoint? Great—Rule Writer can generate the necessary protection. Architect tests, approves, and deploys the policy, and SOC Analyst keeps watch for any follow-up threats. It’s the definition of teamwork, only you’re not wrangling five different tools or stakeholders manually to make it happen.

Conclusion & Call to Action

The WAF Assistants represent a new era of web security—smarter, faster, and infinitely more collaborative. By offloading repetitive tasks and maintaining real-time communication across the Impart platform, they free your human experts to focus on strategy, innovation, and high-level risk management.

Ready to see them in action? Click here to sign up for an upcoming deep-dive or book a live demo. Your security posture is about to get a serious upgrade—let the WAF Assistants show you what true teamwork can achieve.

‍

The post Meet the WAF Squad | Impart Security appeared first on Security Boulevard.

Six Tech Trends Shaping the Future of Brand Experiences
madhav
Wed, 01/08/2025 - 12:38

Business success relies on balancing positive brand experiences and maintaining consumer trust. Consumers want efficiency—2024 research from Thales found that 22% of consumers will give up after less than a minute if they're having a frustrating customer experience—but they are suspicious of the technologies that provide that efficiency. 57% are nervous that brands' use of generative AI will put their personal data at risk.

Businesses must take advantage of emerging technologies to gain and maintain customers. But it's equally important to take a considered, responsible approach to those technologies to maintain customer trust. Here are a few technologies that can help improve your organization's brand experience and some advice on how to get your customers to trust them.

• Generative AI

  Generative AI has dominated news, corporate, and social media headlines for nearly two years. Speculation about its potential ranges from mundane to hysterical. But if used correctly, it could genuinely transform brand experiences.

  Consumers are split on AI. While 51% said they would be happy for companies to use the technology to improve their brand experiences, 43% said they would not trust any interactions powered by it.

  Generative AI can improve the brand experience in many ways. For example, technology enables businesses to tailor product recommendations, FAQs, and marketing materials to specific customers. Similarly, using generative AI, organizations can quickly and efficiently analyze customer feedback to gauge public sentiment towards their brand and adjust their services and marketing accordingly.

  Convincing consumers to trust your use of AI relies on transparency. It's essential to demonstrate your commitment to data privacy by publishing an AI policy that clarifies how you intend to use customer data. Often, it's the fear of the unknown that scares people, meaning that simply explaining your AI policy can significantly improve customer trust.

• Augmented Reality and Virtual Reality

  Augmented Reality (AR) and Virtual Reality (VR) are revolutionizing how brands interact with consumers. While they differ slightly – AR overlays digital information onto the real world, while VR creates entirely simulated environments – both technologies create immersive consumer experiences. For example, brands may use AR and VR technologies for virtual try-ons, interactive product demonstrations, and immersive storytelling.

  While these technologies undoubtedly enhance customer engagement and drive sales, they also bring about significant, novel privacy considerations. For example, unlike the other technologies covered in this article, AR can see exactly what users see. If a threat actor were to gain access to an AR device, they could record the user in potentially embarrassing or compromising situations and demand a ransom from them. Similarly, VR devices often record and track a user’s fingers – if they type a password or code in their VR device, cybercriminals could steal this data and, hence, their data. It’s crucial to be open with users about the data you collect and take special measures to protect that data.

• IoT Devices

  Love them or hate them, IoT devices are the future. If used correctly, they can significantly improve consumers' experiences and interactions with your brand. Moreover, consumers are remarkably bullish on smart home devices, with 30% saying the technology will improve their interactions with brands over the next 12 months.

  Consider smart energy meters, for example. These devices not only provide users greater insight into their energy uses and associated costs but also communicate with them directly, alerting them to planned or impromptu outages and restorations.

  Similarly, by integrating with voice assistants like Amazon Alexa or Google Assistant, users can interact directly with your brand by speaking. Although your customers know they're not talking to a human, your brand's voice will shine through and improve the overall brand experience. What’s more, voice assistants such as these collect vast amounts of data on consumer behavior, preferences, and usage patterns that you can use to personalize product offerings, improve customer experiences, and develop new products and services that meet evolving consumer needs.

  However, IoT devices have substantial privacy implications. Remember, these devices are always listening, which can be a disconcerting reality for consumers. To set your customers' minds at ease, you should emphasize the security features of these devices and clearly outline your privacy policies.

• Personalization Through Progressive Profiling

  Progressive profiling is a great way to collect consumer data without demanding too much at once. This caveat is especially important considering that 29% of users reported leaving a brand in the past 12 months because it demanded too much information. It allows brands to build detailed customer profiles organically, enhancing personalization, improving customer experience, increasing engagement, boosting data quality, and strengthening customer relationships.

  However, brands must remember that although they’re not collecting an overwhelming amount of data all at once, they are still collecting data. Just because consumers are more willing to accept this kind of data collection, that doesn’t give brands the right to disregard data privacy considerations like minimization and security.

• Chatbots

  Good customer service is essential. Research suggests that 73% of customers will switch to a competitor after multiple bad experiences. But good customer service is extremely difficult—and expensive—to provide. Unless you're a tiny business with only a handful of high-value customers, hiring enough staff to effectively deal with customer queries and complaints simply is not feasible. This is where chatbots come in. Chatbots have played a role in customer service for some time, but generative AI has supercharged their abilities. Consumers know this fact, with 25% believing they will contribute to positive brand interactions in the next 12 months.

  With generative AI, chatbots provide responses tailored to consumers' history, preferences, and behavior. They can even predict customer needs based on past interactions and offer proactive assistance, making for a bespoke and positive brand experience. Similarly, as generative AI has improved, chatbots respond to customer queries rather than just redirecting them to FAQ pages or a customer service email address.

  But, again, this technology can seriously damage customer trust. Chatbots are especially risky as they not only present data privacy concerns—you can remediate these with a transparent data privacy policy, as above—but they can also be unreliable. In 2024, Air Canada's customer service chatbot wrongly offered a customer a bereavement discount. The airline refused to honor the discount, and the customer sued, winning over $800 in damages. To avoid a similar situation, it's essential to audit AI-powered chatbots regularly.

• 5G

  The rollout of 5G networks in recent years has sped up data speeds and lowered latency, granting new possibilities for enhancing brand experiences. For example, brands could create high-quality, interactive content, live-stream events, and deliver personalized experiences in real-time, further blurring the lines between the physical and digital worlds.

  But again, brands need to consider the data they collect when delivering these experiences. 5G networks inherently collect more data than less powerful networks, so brands need to take extra measures to protect it.

In conclusion, it's crucial to recognize that customers want to both trust a brand and have a positive, streamlined experience with it. While these wants are often difficult to reconcile, they are not mutually exclusive or unreasonable. To succeed as a modern business, take advantage of technology trends that can improve brand experiences, but be sure to take a considered, responsible, and transparent approach to these technologies with customer privacy at its core.

Identity & Access Management Cloud Computing

Ammar Faheem | Product Marketing Manager
More About This Author > Schema {
"@context": "https://schema.org",
"@type": "BlogPosting",
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://cpl.thalesgroup.com/blog/access-management/six-tech-trends-shaping-brand-experiences"
},
"headline": "Six Tech Trends Shaping the Future of Brand Experiences",
"description": "Explore six technology trends including AI, AR/VR, IoT, and 5G that are shaping brand experiences while addressing consumer trust concerns.",
"image": "https://cpl.thalesgroup.com//sites/default/files/content/blog/social/six-tech-trends-shaping-the-future-of-brand-experiences-sc.jpg",
"author": {
"@type": "Person",
"name": "Ammar Faheem",
"url": "https://cpl.thalesgroup.com/blog/author/afaheem"
},
"publisher": {
"@type": "Organization",
"name": "Thales Group",
"description": "The world relies on Thales to protect and secure access to your most sensitive data and software wherever it is created, shared, or stored. Whether building an encryption strategy, licensing software, providing trusted access to the cloud, or meeting compliance mandates, you can rely on Thales to secure your digital transformation.",
"url": "https://cpl.thalesgroup.com",
"logo": "https://cpl.thalesgroup.com/sites/default/files/content/footer/thaleslogo-white.png",
"sameAs": [
"https://www.facebook.com/ThalesCloudSec",
"https://www.twitter.com/ThalesCloudSec",
"https://www.linkedin.com/company/thalescloudsec",
"https://www.youtube.com/ThalesCloudSec"
]
},
"datePublished": "2025-01-08",
"dateModified": "2025-01-08"
}

basic

The post Six Tech Trends Shaping the Future of Brand Experiences appeared first on Security Boulevard.

Victim organizations need more effective tools and strategies to streamline incident response and mitigate financial fallout. 

The post Rethinking Incident Response: How Organizations Can Avoid Budget Overruns and Delays  appeared first on Security Boulevard.

The numbers are staggering—2024 has seen over 200,000 layoffs across 1,200 companies, with 82% coming from the tech industry. Welcome to the Top Tech Talent Reemployment Project! I’m Peter, and this initiative is all about supporting those affected by layoffs and helping them find fulfilling roles. In our first episode, I’m joined by my friend […]

The post Reemployment Project: Meet Alex Ryan appeared first on Security Boulevard.

After being let go from F5 in May 2023, I started thinking about how to support job seekers during tough times. That’s when I came up with the Top Tech Talent Reemployment Project—a video series featuring professionals who have been impacted by layoffs. The idea is simple: I host 5-7 minute interviews where we discuss […]

The post Top Tech Talent Reemployment Project: Helping Job Seekers Shine! appeared first on Security Boulevard.

Explore the invisible war being fought in cyberspace, where nations battle without traditional weapons. This comprehensive guide explains modern cyberattacks, their impact on global security, and how countries defend their digital borders in an increasingly connected world.

The post The Digital Battlefield: Understanding Modern Cyberattacks and Global Security appeared first on Security Boulevard.

Are Organizations Fully Grasping the Importance of API Security? It is surprising how often businesses underestimate the importance of Application Programming Interface (API) security while navigating the digital landscape. This concern arises due to the significant rise in API-centric applications. While APIs offer countless benefits, they also pose substantial cybersecurity challenges. So, how well are […]

The post Challenges and Solutions in API Security appeared first on Entro.

The post Challenges and Solutions in API Security appeared first on Security Boulevard.

Why Is Identity Access Management (IAM) Crucial in Cloud Security? Have you ever thought about how crucial Identity Access Management (IAM) is when it comes to cloud security? IAM is not just about managing human identities but also about dealing with non-human identities (NHIs) and their secret security management. As a data management specialist and […]

The post The Role of IAM in Securing Cloud Transactions appeared first on Entro.

The post The Role of IAM in Securing Cloud Transactions appeared first on Security Boulevard.

Author/Presenter: Joshua Herman

Our sincere appreciation to DEF CON, and the Authors/Presenters for publishing their erudite DEF CON 32 content. Originating from the conference’s events located at the Las Vegas Convention Center; and via the organizations YouTube channel.

Permalink

The post DEF CON 32 – Psychic Paper: Making E-Ink Access Badges Accessible For Anyone appeared first on Security Boulevard.

Philadelphia, Pa., Jan. 7, 2025, CyberNewswire — Security Risk Advisors today announced it has become a member of the Microsoft Intelligent Security Association (MISA), an ecosystem of independent software vendors (ISVs) and managed security service providers (MSSPs) that have integrated … (more…)

The post News Alert: Security Risk Advisors joins Microsoft Intelligent Security Association (MISA) first appeared on The Last Watchdog.

The post News Alert: Security Risk Advisors joins Microsoft Intelligent Security Association (MISA) appeared first on Security Boulevard.

Ramat Gan, Israel, January 7th, 2025, CyberNewswire — CyTwist, a leader in advanced next-generation threat detection solutions, has launched its patented detection engine to combat the insidious rise of AI-generated malware.

The cybersecurity landscape is evolving as attackers harness … (more…)

The post News alert: CyTwist launches threat detection engine tuned to identify AI-driven malware in minutes first appeared on The Last Watchdog.

The post News alert: CyTwist launches threat detection engine tuned to identify AI-driven malware in minutes appeared first on Security Boulevard.

In the world of cybersecurity, compliance is a no-brainer. Adhering to corporate and regulatory compliance standards is critical for enterprises. And while compliance does not ensure active and constant protection against cybersecurity threats, it's a standard to aim for that can ensure stealthier cybersecurity for enterprises. 

Chris Hughes, CEO of Aquia, said in a recent LinkedIn post that it's a good baseline for enterprises — and the most effective way to get organizations to invest in cybersecurity

The post Compliance as cybersecurity: A reality check on checkbox risk management appeared first on Security Boulevard.

via the respected Software Engineering expertise of Mikkel Noe-Nygaard and the lauded Software Engineering / Enterprise Agile Coaching work of Luxshan Ratnaravi at Comic Agilé!

Permalink

The post Comic Agilé – Mikkel Noe-Nygaard, Luxshan Ratnaravi – #319 – Specialities appeared first on Security Boulevard.

Exabeam today added a bevy of capabilities to its New-Scale Security Operations Platform, including support for open application programming interface (API) and an ability to search data stored in the LogRhythm security information event management (SIEM) platform it acquired last year.

The post Exabeam Extends Scope and Reach of SIEM Platform appeared first on Security Boulevard.

On Detection: Tactical to Functional Seven Ways to View API Functions Introduction

Welcome back to Part 15 of the On Detection: Tactical to Functional blog series. I wrote this article to serve as a resource for those attempting to create tool graphs to describe the capabilities of the attacker tools or malware samples they encounter. Throughout this series, I’ve analyzed many API functions and summarized my analysis through function call stacks. As I expanded the range of functions I’ve analyzed, I noticed that there is not a one-size-fits-all solution when creating function call stacks.

Overall, I’ve found that there are, at least, seven different types of functions:

1. Standard Functions (Syscalls)
2. Sub-operations (NtQueryInformation* or NtSetInformation*)
3. Remote Procedure Calls (NdrClientCall*)
4. Local Security Authority Functions (LsaCallAuthenticationPackage)
5. Driver IOCTLs (DeviceIoControl or NtFsControlFile)
6. Compound Functions (Multiple operations)
7. Local Functions

In this article, I work to categorize functions based on their function type. To do so, I will introduce the category and what makes its functions unique, share a sample whose critical function exemplifies the category, provide the sample’s tool graph and explain how it works, and finally break down the specific function call stack that demonstrates the category in question. Ultimately, you should have the toolset to identify the category to which a given function belongs based on a few heuristics I will share along the journey. This knowledge will empower you to better understand and categorize the attacker tools or malware samples you encounter.

This article is broken down into sections that describe and demonstrate the categories. I subdivide each section further into a “category introduction,” where I will explain the category at a high level; the “sample,” where I will introduce the tool or malware sample that we will analyze to learn about the category; the “tool graph,” where I will explain how the sample implements its functionality; and the “function call stack,” where I will focus on the sample’s critical function which exemplifies the category of focus.

While this article follows several relevant articles that examine individual function types in depth, I consider it more of a preamble to such deep dives. Here, I will introduce two or three new function-type categories I have not previously discussed, but I plan to write a subsequent deep dive on each eventually.

1. Standard Function (syscall)

The first and most common category is the so-called standard functions. These functions are standard because they represent the most common construction and serve as excellent starting points for anyone interested in gaining experience building function call stacks. Standard functions typically involve multiple layers of redirection between DLLs but will inevitably pass the caller-supplied arguments to a system call (syscall) for execution in the kernel. If you’ve followed this series, you will be highly familiar with standard functions and know that we use the syscall as an abstraction layer, which I call an operation. As we progress into other categories, we will see that the operation will remain, but we will derive it differently.

Sample

Our standard function sample comes from DGRonpa’s excellent Process_Injection repository. I enjoy this repo because they have created simple proof-of-concept implementations for the Process Injection technique’s diverse set of procedures. If you are just getting started with implementing the analytical process I present in this series, I recommend you check out this project. It demonstrates how slight implementation changes can have a massive impact on the mutual detectability of malware samples. This article will focus on the Shellcode_Injection.cpp sample, which implements the canonical process injection procedure. For those unfamiliar with process injection, it is primarily a defense evacuation technique used by attackers to inject or migrate their malicious code into an otherwise legitimate process, thus making them less susceptible to detection.

Process_Injection/Classical_Injeciton/Shellcode_Injection.cpp at main · DGRonpa/Process_Injection

Tool Graph Tool Graph: Shellcode_Injection.cpp

We can construct the tool graph by analyzing the source code at the link in the previous section. In doing so, we see that the sample begins by opening a handle to the target process, the process that the attacker intends to inject their code into, by calling the kernel32!OpenProcess function. Next, the code passes the process handle to kernel32!VirtualAllocEx. VirtualAllocEx is a function that allows an application to allocate a buffer in the memory of a different or remote process. The memory buffer will hold the attacker’s shellcode. Next, the sample writes shellcode to the newly allocated buffer via the kernel32!WriteProcessMemory function. Finally, the sample calls kernel32!CreateRemoteThread to execute the shellcode in the target process, thus finalizing the injection routine.

Function Call Stack Function Call Stack: kernel32!CreateRemoteThread

Based on my analysis of this sample, it appears that kernel32!CreateRemoteThread is the sample’s critical function. I attribute this choice to the fact that CreateRemoteThread is the function that causes the injection. When the sample calls CreateRemoteThread, we can say that process injection has occurred. Let’s take a look at the function call stack for kernel32!CreateRemoteThread. It is worth understanding the general flow we expect in standard functions.

By analyzing the function call stack, we find that the final function, before the Operation, is a system call (syscall) named NtCreateThreadEx. Syscalls, like NtCreateThreadEx, are responsible for transitioning execution from user-mode to kernel-mode. This transition serves as a boundary whereby analysts can treat the kernel-side functionality as opaque, as it is not standard for a user-mode application to interact with kernel code except through very specific windows like syscalls.

2. Sub-Operations

Now that we have built the foundation, we can look at functions that offer a slight variation. Like Standard functions, this next function-type category is also based around a syscall but provides a bit more variation that must be accounted for by analysts. I call this group of functions Sub-Operations. These functions are often difficult to discern at the Win32 API layer but become evident at the Native API or Syscall layers due to a unique naming convention where the Native API and Syscall are referred to by Nt(Query/Set)Information* where the * represents a specific object type such as Process, File, etc.

For more detailed information on functions in the sub-operation category, I recommend reading Part 14 of this series.

Sample

To demonstrate the Sub-Operation category, we will investigate a sample that Jonathan Johnson wrote for our Malware Morphology workshop. This sample, called Sample 1, implements a simple version of Token Impersonation, and we will find that its critical function is a Sub-Operation.

MalwareMorphology/Sample 1/src/Source.cpp at main · jaredcatkinson/MalwareMorphology

I encourage you to check out the full workshop to see how attackers can change their approach when facing different constraints or circumstances. The slides and labs are available in the linked GitHub repository, and a video recording of the workshop lecture is available on NorthSec’s YouTube channel.

Tool Graph Tool Graph: Malware Morphology Sample 1

Let’s analyze Sample 1’s source code to build the tool graph. This sample starts by calling kernel32!OpenProcess to open a handle to the target process. In this case, the target process is the process from whom the attacker wants to impersonate. Next, it passes the process handle to advapi32!OpenProcessToken and opens a handle to the target process’s primary token. The primary token represents the user context the attacker is after. While the attacker now has access to their target token, Windows does not allow a process to impersonate the primary token of a different process, so Jonny calls advapi32!DuplicateToken to make a fresh copy of the token. Finally, he passes the duplicated token to advapi32!SetThreadToken to execute the impersonation. Finally, Jonny follows good programming practice by cleaning up the handles he opened by calling kernel32!CloseHandle three times. It is important to note that these calls to CloseHandle are purely optional, so it is plausible that a malicious implementation may exclude them.

Function Call Stack Function Call Stack: advapi32!SetThreadToken

When it comes to Token Impersonation, the moment of impersonation represents the critical point in the function chain. As a result, we can identify advapi32!SetThreadToken as the crucial function in the function chain.

The function call stack, shown below, appears to follow a similar pattern to the Standard Function. However, the implementation diverges when the code reaches kernelbase.dll. In this case, the high-level function, advapi32!SetThreadToken is a wrapper around a more generic low-level function called ntdll!NtSetInformationThread. In Part 14 of this series, I discussed a class of functions called Nt(Set/Query)Information* that facilitate the setting (writing) or querying (reading) of metadata properties for the target object specified by the *, which in this case happens to be a Thread. The caller specifies which specific metadata property to query or set via an information class.” Each object type has a unique set of information classes. You can see in the screenshot below that SetThreadToken specifies information class 5 via the second parameter, which corresponds to ThreadImpersonationToken.

For this category of functions, the information class is critical for properly assigning the operation. If we treated advapi32!SetThreadToken as if it were a Standard Function, we would derive the operation from the syscall, NtSetInformationThread, meaning the operation would be Thread Set. The problem is that the Thread Set operation covers ALL of the Thread’s metadata properties, including properties irrelevant to token impersonation, such as ThreadIoPriority. While it may be interesting to know whether someone changed a thread’s IO priority, that change does not indicate Token Impersonation. All said, there are 41 Thread information classes (metadata properties), and only one is relevant to this particular procedure. Therefore, we require a way to differentiate between Thread Set operations, and the most natural option for doing so is using the information class as an additional indicator. Thus, the resulting operation is Thread Set: ThreadImpersonationToken.

3. Remote Procedure Calls (NdrClientCall4)

Now, we’ve reached the categories I have not yet covered in this series. The first is related to remote procedure call (RPC) procedures. Functions built on RPC Procedures do not result in syscalls, at least not directly. Instead, they implement the client component of the RPC client/server relationship. In the RPC model, the client and server can exist within different processes or even on different systems. Previously, I mentioned that syscalls are responsible for transferring execution from user mode to kernel mode. Similarly, an RPC procedure transfers execution from the client application, the Win32 API function, to the server application. This process is commonly referred to as Interprocess Communication (IPC). Especially in cases where the client and server exist on separate systems, this boundary is at least as robust as the user mode/kernel mode boundary. A key feature of RPC is that the server component generally constrains the set of sub-routines a client can execute on the server. This constraint creates an opportunity to establish our operation abstraction layer.

Sample

For this third class of functions I decided to use a BOF called sc_create that is included in the TrustedSec CS-Remote-OPs-BOF project. Based on the commit history, it appears that it was originally written by Christopher Paschen. The BOF’s name indicates that Christopher reimplemented the functionality of the sc.exe create command. I’ve found that BOFs provide a great starting point for analysts that are trying to get their feet wet in this typeof analysis. Their simplicity can primarily be attributed to the fact that BOF often implement very discrete capabilities which limits the amount of digging that one must do.

CS-Remote-OPs-BOF/src/Remote/sc_create/entry.c at main · trustedsec/CS-Remote-OPs-BOF

Tool Graph Tool Graph: sc_create BOF

Our analysis of the sc_create BOF found that it first opened a handle to the Service Control Manager (SCM) via the advapi32!OpenSCManagerW function. Next, the BOF creates the target service via the advapi32!CreateServiceW function. While the operator can specify specific service details such as its name, binary path, and start type during creation, some other features must be added after the fact. To make these additional changes, the tool calls the advapi32!ChangeServiceConfig2W function. Finally, we see the tool close the handles to the newly created service and the SCM by calling the advapi32!CloseServiceHandle function twice.

Function Call Stack Function Call Stack: advapi32!CreateServiceW

Since the technique in this example is Service Creation, it makes sense to choose advapi32!CreateServiceW as the sample’s critical function for investigation.

CreateServiceW is the first function category that does not make a syscall. Technically, it does EVENTUALLY, but there is an important caveat. You see, advapi32!CreateServiceW is an API function wrapper around an RPC Procedure. In the image below, we see the kernelbase!CreateServiceW function call the rpcrt4!NdrClientCall2 function. NdrClientCall2 is one of a set of functions, represented by NdrClientCall*, that RPC clients can use to make requests. Analysis of the NdrClientCall2’s first and second parameters, which is outside the scope of this article, allows us to identify that kernelbase!CreateServiceW invokes the RCreateServiceW procedure from the Microsoft Service Control Manager Remote Protocol (MS-SCMR).

The Service Control Manager (services.exe) implements its API via RPC, allowing other applications to interact with it. Applications can query, create (as we see here), delete, or modify services through the MS-SCMR RPC interface. Now, we need to understand that the relationship between the calling application and the Service Control Manager is a client/server relationship where clients can make local AND remote requests. The remote aspect is why service creation is a powerful lateral movement technique. Given sufficient permissions, attackers can create malicious services on remote systems. The client/server relationship is essential in our analysis because it acts like a boundary where interaction is constrained to a finite set of RPC procedures like RCreateServiceW. This constraint allows for the application of the operation abstraction layer, which is labeled Service Create in this specific case.

Note: This is not to say that it is not valuable to understand what happens on the server side of the interaction because, in some cases, like this one, an understanding of the server-side component can reveal an alternative procedure to achieve the same outcome (lateral movement via service creation). That said, the ability to implement the server-side implementation, especially remotely, has shown in my analysis to be the exception, not the rule. I will write more about this in a future post.

4. LSA Functions (LsaCallAuthenticationPackage)

Next, we encounter a function type category that took me a while to understand, the LSA Function. Eventually, I discovered that LSA Functions are to RPC Procedures as Sub-Operations are to Standard Functions. That is, LSA Functions rely on a specific RPC Procedure called SspirCallRpc, which the Microsoft Security Support Provider Interface (MS-SSPI) implements. MS-SSPI offers an extensible framework for authentication whereby Microsoft and third-party vendors can extend how users authenticate to the system. As a result, all interactions with “Authentication Packages” flow through the same RPC Procedure. However, the Local Security Authority (LSA) determines how to handle each request based on the specified Authentication Package and AP function. These additional variables indicate that it will not be enough to observe the invocation of SspirCallRpc. Instead, more precise monitoring is necessary, but unfortunately, I am not aware of any vendor that supports this level of monitoring as of this writing.

I highly recommend checking out Evan McBroom’s excellent LSA Whisper project to learn more about the Authentication Packages and LSA.

Sample

This category of functions is the one that inspired me to write this post. I struggled to integrate functions that interact with the Local Security Authority (LSA) into my model for an extended period. When I finally understood how they fit, I realized I had incorrectly conceptualized other categories, like RPC functions. This category is essential when considering modern tradecraft, as shown by my colleagues Will Schroeder in his work on Rubeus and Evan McBroom in his work on LSA Whisperer. Many modern workflows manipulate an agent’s identity context through interactions with LSA, so modern detection approaches must understand these underlying mechanisms. With that in mind, we will look at the inner workings of the pass-the-ticket (ptt) argument in many of Rubeus’ commands.

Rubeus/Rubeus/lib/LSA.cs at master · GhostPack/Rubeus

Tool Graph Tool Graph: Rubeus ptt

At this point, each sample we have investigated supported one use case. Rubeus is a full-featured tool suite that supports many Kerberos-related attacks. The pass-the-ticket feature assumes the operator has a Kerberos ticket and facilitates adding that ticket to the ticket cache of the specified logon session.

The tool graph below shows that Rubeus begins by connecting to the Local Security Authority (LSA) server using the secur32!LsaConnectUntrusted function. This results in an LSA handle that the tool uses in subsequent calls. Next, the application finds the Kerberos authentication package (AP) by calling the secur32!LsaLookupAuthenticationPackage function. Rubeus then calls secur32!LsaCallAuthenticationPackage specifying the Kerberos authentication package’s KerbSubmitTicket function. The KerbSubmitTicket AP function adds the supplied ticket to the specified logon session’s ticket cache. Finally, Rubeus releases the LSA handle by calling secur32!LsaDeregisterLogonProcess.

Function Call Stack Function Call Stack: secur32!LsaCallAuthenticationPackage (Kerberos KerbSubmitTicket)

The secur32!LsaCallAuthenticationPackage function is responsible for “passing-the-ticket” in the sense that it is the function that adds the ticket to the ticket cache. For that reason, let’s dig a bit deeper into it to understand how it works.

When we open secur32!LsaCallAuthenticationPackage in our disassembler, we see that it eventually makes an RPC Procedure call to the SspirCallRpc procedure implemented by the Microsoft Security Support Provider Interface (MS-SSPI). You might immediately think that I’m crazy because we just covered RPC Procedures in the previous section, but it turns out that this particular case is more complicated than that. That’s because there is an additional layer or two of abstraction. The SspirCallRpc procedure acts as a gateway for applications to interact with LSA regardless of the authentication package and function that the caller specifies. Behind the scenes, MS-SSPI (loaded in lsass.exe) handles these calls and passes execution to the appropriate authentication package, such as kerberos.dll. As a result, observing a call to the SspirCallRpc procedure only indicates that some authentication-related operation has occurred. However, it does not provide the necessary level of detail to determine whether the operation is the one you are interested in, such as adding a Kerberos ticket to the ticket cache, in this case via KerbSubmitTicket. Like Sub-Operations, this category requires that we operate at a more granular level if we can hope to use this signal in any meaningful detection strategy.

It is also worth noting that these LSA-related operations function based on the same client/server relationship as RPC but are often constrained to the local machine only. The lsass.exe application runs as a protected process on modern operating systems, so LsaCallAuthenticationPackage or SspirCallRpc, more specifically, acts as an interface for applications to interact with LSA. This constraint allows us, again, to treat the LSA side of this interaction opaquely. I’ve found it helpful to label the resulting operation using the AP function, which in this example is KerbSubmitTicket.

5. Driver IOCTLs

Another important category I have not extensively written about is Driver IOCTLs. These functions rely on making specific Input/Output Control calls to kernel drivers via API functions like kernel32!DeviceIOControl and ntdll!NtfsControlFile. IOCTLs facilitate direct interaction with a kernel driver and represent something between a Syscall and an RPC Procedure. In this case, we treat the transfer of execution from the client application to the kernel driver as the boundary for abstraction.

Sample

To demonstrate Driver IOCTLs in practice, I will use Matt Graeber’s Get-System implementation from the PowerSploit project. Get-System provides two approaches to Token Theft. The first follows the traditional Token Impersonation approach, while the second relies on a trick with named pipes. For this analysis, I will focus on the named pipe approach.

PowerSploit/Privesc/Get-System.ps1 at d943001a7defb5e0d1657085a77a0e78609be58f · PowerShellMafia/PowerSploit

Thanks to Jonathan Johnson for helping to identify a function that embodies this category. He pointed me to one of his blog posts focused on advapi32!ImpersonateNamedPipeClient, which inspired me to find a sample that leverages that function. If you want to understand how I constructed the function call stack, I recommend you read his post.

Exploring Impersonation through the Named Pipe Filesystem Driver

Tool Graph Tool Graph: PowerSploit Get-System

After consulting the source code for our sample, I found that the named pipe impersonation trick is a bit complicated. It starts with a call to advapi32!CreatePipe, which generates a new pipe with a fairly permissive DACL. Next, we interact with the Service Control Manager (SCM) via advapi32!OpenSCManagerW. This call results in a handle to the local SCM. Matt passes the SCM handle to advapi32!CreateServiceW to create a new service that the attack will eventually use to connect to the named pipe. Services can run as the NT AUTHORITY\SYSTEM user, resulting in the “named pipe client” being SYSTEM. We then see a call to advapi32!CloseServiceHandle to close the service handle. Next, Get-System calls advapi32!OpenServiceW to open a new handle to the service. The service handle is passed to advapi32!StartServiceW to execute the service, thus connecting to the named pipe. After the service is executed, the sample is cleaned up via advapi32!DeleteService and two calls to advapi32!CloseServiceHandle. Finally, advapi32!ImpersonateNamedPipeClient is called to steal the SYSTEM account token.

Function Call Stack Function Call Stack: advapi32!ImpersonateNamedPipeClient

As mentioned earlier, I selected this sample to highlight the advapi32!ImpersonateNamedPipeClient function.

Like many other functions, ImpersonateNamedPipeClient flows to kernelbase.dll, where it makes a call to a Native API function called ntdll!NtFsControlFile. The Microsoft documentation for the NtFsControlFile function states that “[it] sends a control code directly to a specified file system or file system filter driver, causing the corresponding driver to perform the specified action.” We can see from the arguments passed to NtFsControlFile that the handle is to the specified named pipe, which, in the case of Matt’s Get-System implementation, is the dummy named pipe created via the CreatePipe function call. We also see that kernelbase!ImpersonateNamePipeClient hardcodes the sixth parameter, representing the FsControlCode, to 0x11001C.

Implementation of kernelbase!ImpersonateNamedPipeClient

The FsControlCode tells the driver which sub-routine to execute. In his blog post analyzing the function, Jonny explains that this control code is known as FSCTL_PIPE_IMPERSONATE and that the components of the control code indicate that this is function number 7 for named pipes (FILE_DEVICE_NAMED_PIPE). We can, therefore, use the control code as the abstraction layer for our operation, which we will call Pipe Impersonate.

6. Compound Functions

A special category is the Compound Function. A Compound Function is a function that, at the Win32 API level, appears as a single function but, lower in the function call stack, breaks down into many more specific functions and, thus, operations. We typically find that Compound Functions implement logic to execute an everyday routine that would normally require multiple individual function calls. A great example of a compound function is dbghelp!MiniDumpWriteDump, which creates process crash dumps. It is built on top of kernel32!ReadProcessMemory. However, a crash dump requires numerous specific memory reads to occur. MiniDumpWriteDump implements this logic, so the application developer is not required to understand the details of the crash dump or process memory structures.

Sample

We will look at Justin Bui’s Primary Token Theft sample for this category. Justin wrote this program to evaluate which processes would be the best targets for System Token Theft. It is a relatively simple program, but it allows us to see a third implementation of Token Impersonation. I challenge you to analyze this sample’s operation chain and compare it to the sample we used to dig into Sub-Operations.

PrimaryTokenTheft/main.cpp at master · slyd0g/PrimaryTokenTheft

Tool Graph Tool Graph: PrimaryTokenTheft

The tool graph for the PrimaryTokenTheft sample is relatively straightforward compared to some of our other examples. In all, we see that there were three function calls kernel32!OpenProcess, advapi32!OpenProcessToken, and advapi32!ImpersonateLoggedOnUser. The first function, kernel32!OpenProcess is used to open a handle to the target process. This process typically runs in the context of a user with desirable access, such as the NT AUTHORITY/SYSTEM account or a Domain Administrator account. The resulting handle is then passed to advapi32!OpenProcessToken, which opens a handle to the desired access token. Finally, Justin passes the token handle to advapi32!ImpersonateLoggedOnUser, where all the magic happens.

Function Call Stack Function Call Stack: advapi32!ImpersonateLoggedOnUser

Digging into the advapi32!ImpersonateLoggedOnUser function’s call stack, everything progresses normally, like a standard function, until we reach kernelbase.dll. As shown in the image below, we see calls to ntdll!NtQueryInformationToken, ntdll!NtDuplicateToken, ntdll!NtSetInformationThread, and ntdll!NtClose.

Implementation of kernelbase!ImpersonateLoggedOnUser

As a result, the function call stack splits at kernelbase!ImpersonateLoggedOnUser. The end effect is that rather than a one-to-one relationship between the function and the operation, we find that advapi32!ImpersonateLoggedOnUser has a one-to-four relationship, which has massive implications for our detection engineering efforts. Each underlying function will fit within one of the categories covered in this article. For example, NtQueryInformationThread and NtSetInformationThread belong to the Sub-Operation category, while NtDuplicateToken and NtClose belong to the Standard Function category.

You will notice that the resulting operation chain for this particular sample is not much different from that of the sample used in the Sub-Operation section. This similarity means that these two samples are likely to be mutually detectable, or, put another way, they can both be detected using the same analytic.

7. Local Functions (memcpy or GetCurrentProcess)

The final category is probably the least important from the detection engineering perspective. However, understanding how to spot functions from this set will empower you to separate the wheat from the chaff. Local Functions is the name I’ve given to the functions that never cross a relevant boundary. They often, if not always, are resolved within the initial implementation DLL and perform local tasks. You will find that as you begin to analyze complicated functions, you will encounter many local functions, so you must understand how to spot these functions so you can be sure that you can safely ignore them.

Sample

In this example, we will rely on the Get-ProcessTokenPrivilege PowerShell function from Will Schroeder’s PowerUp module. This function is a helper function that implements something similar to whoami /priv.

PowerSploit/Privesc/PowerUp.ps1 at master · PowerShellMafia/PowerSploit

Tool Graph Tool Graph: Get-ProcessTokenPrivilege

The tool graph shows that this PowerShell function is meant to check which privileges are enabled for the current user context. We see kernel32!GetCurrentProcess emits a handle to the calling process. That handle is then passed to advapi32!OpenProcessToken, which returns a handle to the calling process’s primary token. Finally, the advapi32!GetTokenInformation function is called to return a list of the token’s enabled privileges.

Note: Can you identify which categories advapi32!OpenProcessToken and advapi32!GetTokenInformation fit into?

Function Call Stack Function Call Stack: kernel32!GetCurrentProcess

In this sample, the kernel32!GetCurrentProcess function represents the Local Function category. After opening kernel32.dll in IDA, we can browse to the implementation of the GetCurrentProcess function. We see that this function does not do much. It returns -1, which functions as a pseudo-handle for the calling process.

Implementation of kernel32!GetCurrentProcess

As a result, the function call stack is essentially non-existent, as shown below. Since kernel32!GetCurrentProcess does not cross a client/server boundary like that of user-mode/kernel-mode, RPC client/server, or LSA client/auth package it does not have a corresponding operation.

Conclusion

For as long as I can remember, we have used API functions to describe a particular malware sample’s functionality. These function chains have proven helpful to Detection Engineers as they provide a blueprint for observation. However, not all functions are created equally. In our analysis, we’ve identified seven function categories, each requiring a different analytical approach. I hope the descriptions in this article help you determine which type of function you have encountered so you can ensure you are collecting data with an adequate level of granularity.

Part 15: Function Type Categories was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.

The post Part 15: Function Type Categories appeared first on Security Boulevard.

Agents, Robotics, and Auth - Oh My! Introduction

2025 will be the year of the futurist. I never thought that I'd be writing a blog post about AI and robotics at this point in my career, but technology has advanced so much in the lat 12 months setting up 2025 to be a landmark year in terms of the tech industry. Self driving cars, robots, AGI - these are all things that have a realistic chance of shipping this year which is super exciting for me as a futurist. That said, Advances in artificial intelligence (AI) agent technology, robotics, and APIs are transforming the way we live and work, but they also present new challenges for web application and API security. Traditional Web Application Firewalls (WAFs) are going to struggle to keep pace with these changes, leading to the rise of API Native WAFs and WAF Agents as superior solutions. This article will explore the new threats to WAFs in 2025.

New Threats to WAFs in 2025

The increasing sophistication of AI agent technology, robotics, and APIs has given rise to a new generation of cyber threats. These threats are more complex, adaptive, and difficult to detect than ever before. The following table summarizes some of the key threats facing WAFs in 2025:

‍

‍

AI-Powered Attacks

There is a distinction between AI-powered and AI-assisted threats. AI-powered attacks, like deepfake video scams, have been limited to date. AI-assisted threats are more common, where AI helps threat actors create variants of existing malware or better phishing email lures7. However, by 2025, malicious use of multimodal AI will be used to craft an entire attack chain. As multi-modal AI systems gain the ability to integrate text, images, voice, and sophisticated coding, threat actors will leverage them to streamline and automate the entire pipeline of a cyberattack7.

‍

One example of an AI-powered attack is the use of deepfakes to scam individuals. In one instance, scammers impersonated a company's chief financial officer during a video conference call and convinced a finance worker to pay them $25 million2. AI can also be used to automate social engineering attacks by engaging with targets on social media, building trust, and gathering information to personalize attacks8.

‍

While large language models (LLMs) like GPT-3/-4 have enabled astonishing breakthroughs in generative AI, they also present security challenges. One challenge is adapting LLMs to specific needs. Developers often use extensive manual adjustments to prompts to adapt an LLM to their requirements, which can lead to deep model dependence for AI applications. Other methods used include fine-tuning results using human feedback loops and improving relevance and accuracy through run-time queries to authoritative external datasets (i.e., Retrieval-Augmented Generation, or RAG)9.

Growing API Vulnerabilities

APIs are a primary target for attackers in the age of agentic AI10. Agentic AI systems are capable of perceiving, reasoning, acting, and learning, and APIs are the backbone of these systems10. Attackers are escalating their use of AI-driven bots, supply chain breaches, and multi-vector campaigns to exploit API vulnerabilities10. Smarter, stealthier bots will exploit APIs for credential stuffing, data scraping, and automated account takeovers10.

The increasing volume of APIs and threats has made API discovery a critical focus for organizations in 202511. According to a recent industry report, 57% of organizations suffered an API-related data breach in the past two years, with 73% of those experiencing three or more incidents12. API-related security issues now cost organizations up to $87 billion annually11. Furthermore, 65% of organizations believe that generative AI applications pose a serious risk to APIs13.

Some specific examples of API breaches that occurred in 2024 include:

• A buggy API at a messaging company led to unauthorized access to 650,000 sensitive messages, exposing passwords and allowing penetration testers to retrieve confidential data14.
• An exposed Trello API compromised the data of over 15 million users by linking private email addresses to Trello accounts14.
• An API vulnerability in the social media platform Spoutible exposed user data, including bcrypt hashes of passwords14.

Emergence of Robotic Systems

As robots become more interconnected, they are increasingly vulnerable to various cyber threats, including Denial of Service (DoS) attacks, spoofing, and man-in-the-middle attacks5. These attacks can disrupt operations, steal sensitive data, and cause significant financial losses to businesses5.

Humanoid robots, which rely heavily on AI algorithms, are particularly vulnerable to adversarial attacks. In these attacks, malicious actors feed manipulated or misleading data into the AI system to exploit its decision-making process15. For example, in a factory setting, adversarial input could cause a robot to malfunction, leading to poor or dangerous decision-making15.

Another significant risk is supply chain attacks. Robots often rely on components and software sourced from third-party vendors, and if any of these components are compromised, they could serve as a backdoor for cybercriminals15.  Integrating cybersecurity measures into existing robotic systems can be complex and challenging5. 

Robotic systems begin to bridge the gap between the digital world and the physical world, raising the stakes for security professionals.  While publicly disclosed incidents specifically targeting robotic systems are relatively rare (likely due to underreporting) , there have been some notable security incidents and research findings highlighting the vulnerabilities of these systems:   

• Remote takeover of a Jeep Cherokee: Researchers demonstrated how they could remotely take control of a Jeep Cherokee by exploiting vulnerabilities in the vehicle's Uconnect infotainment system . This incident highlighted the potential for attackers to manipulate critical vehicle functions, posing significant safety risks.   
• Vulnerabilities in industrial and home robots: In 2017, IOActive discovered over 50 security vulnerabilities in six different robots, including popular models like NAO and Pepper, as well as industrial robots from Universal Robots and Rethink Robotics . These vulnerabilities could allow attackers to manipulate robot movements, disable safety features, and even gain access to sensitive data.   
• Healthcare robot vulnerabilities: In 2022, Cynerio researchers found five vulnerabilities in Aethon TUG autonomous robots used in hospitals across the United States . These vulnerabilities could allow attackers to disrupt hospital operations, steal sensitive patient data, or even manipulate robot behavior, potentially endangering patients.  

These incidents demonstrate the growing need for robust cybersecurity measures in robotic systems. As robots become more prevalent and interconnected, organizations must prioritize security to prevent potential harm, data breaches, and operational disruptions.   

Why Traditional WAFs Struggle

Traditional WAFs, while still valuable for basic protection, face several challenges in addressing the evolving threat landscape:

• Reliance on Static Rules: Traditional WAFs rely on predefined rules and signatures to detect and block attacks. This approach is ineffective against new or sophisticated attacks that do not match known patterns17. They often need help with real-time detection and response to complex, adaptive bots18.
• Limited Visibility: Traditional WAFs often have limited visibility into application logic, user workflows, and data structures. This makes it difficult to detect attacks that exploit vulnerabilities in these areas19.
• Inability to Adapt: Traditional WAFs are not designed to adapt to the dynamic nature of cyber threats. They often require manual updates to address new vulnerabilities and attack techniques20.
• Challenges with API Security: Traditional WAFs often struggle to secure APIs due to the complex authorization mechanisms, protocol variations, and payload structures used by APIs21. They are not effective at protecting against API attacks like those in the OWASP API Top 1022. 
• Cloud Environment Challenges: Applying WAFs in cloud environments presents specific challenges, such as complex deployment scenarios in Kubernetes and poor management efficiency with multiple clouds24.

Today, only 19% of organizations rate their traditional security solutions as highly effective in protecting APIs12. Despite 85% of IT leaders expressing confidence in their organization's security capabilities, 55% have experienced an API security incident in the past year27. This highlights the need for more advanced solutions to address the evolving threat landscape.

The Rise of WAF Agents

Agent-based WAFs represent a new approach to web application and API security28. These WAFs use AI agents to monitor and analyze traffic, detect anomalies, and mitigate threats in real-time. Here's why agent-based WAFs are superior solutions:

• Adaptive Learning: Agent-based WAFs use machine learning to continuously learn and adapt to new threats. This allows them to detect and block attacks that traditional WAFs would miss29.
• Behavioral Analysis: Agent-based WAFs can analyze user behavior and identify anomalies that may indicate malicious activity. This helps to detect attacks that are not based on known signatures or patterns30.
• Contextual Awareness: Agent-based WAFs have a deeper understanding of application logic, user workflows, and data structures. This allows them to detect attacks that exploit vulnerabilities in these areas29.
• Real-time Threat Intelligence: Agent-based WAFs can integrate with threat intelligence feeds to stay updated on the latest threats and vulnerabilities. This helps to proactively block attacks before they can cause damage17.
• Automated Response: Agent-based WAFs can automate incident response processes, reducing the time it takes to respond to threats. This helps to minimize the impact of attacks17.
• Human-in-the-Loop Oversight: Implementing "human-in-the-loop" oversight enables agents to work autonomously while human experts review decisions after they've been made32. This provides a layer of human control and accountability, mitigating the risks of unintended consequences.

Web Application and API Protection (WAAP) is an important concept in this context. WAAP refers to cloud-based services created to safeguard vulnerable APIs and web applications33. Cloud WAAP services provide various security modules, including bot mitigation, WAF, API protection, and protection against DDoS attacks33.

Proactive security measures, such as those employed by agent-based WAFs, can significantly reduce the number of alerts and allow security teams to focus on real threats23.

Conclusion

As AI agent technology, robotics, and APIs continue to advance, the threat landscape will become increasingly complex. Traditional WAFs will struggle to keep pace with these changes, making agent-based WAFs a necessity for organizations looking to protect their web applications and APIs. By leveraging the power of AI, agent-based WAFs offer a more adaptive, intelligent, and effective approach to security, ensuring that organizations can stay ahead of the curve in the ever-evolving cyber battlefield.

References

1. Emerging Threats to Critical Infrastructure: AI Driven Cybersecurity Trends for 2025, accessed January 6, 2025, https://www.captechu.edu/blog/ai-driven-cybersecurity-trends-2025

2. AI could empower and proliferate social engineering cyberattacks | World Economic Forum, accessed January 6, 2025, https://www.weforum.org/stories/2024/10/ai-agents-in-cybersecurity-the-augmented-risks-we-all-need-to-know-about/

3. Breaking Down the OWASP Top 10 API Security Risks 2023 (& What Changed From 2019), accessed January 6, 2025, https://www.veracode.com/blog/research/breaking-down-owasp-top-10-api-security-risks-2023-what-changed-2019

4. OWASP API Security Top 10 Vulnerabilities: 2023 - APIsecurity.io, accessed January 6, 2025, https://apisecurity.io/owasp-api-security-top-10/

5. Consolidating market leadership in robotic cybersecurity - Alias Robotics, accessed January 6, 2025, https://news.aliasrobotics.com/consolidating-market-leadership-in-robotic-cybersecurity-alias-robotics/

6. The Achilles' Heel of Automation: Why Robot Security Can't Be an Afterthought in Manufacturing - Founder Shield, accessed January 6, 2025, https://foundershield.com/blog/robot-security-in-manufacturing-automation/

7. 2025 Forecast: AI to supercharge attacks, quantum threats grow, SaaS security woes, accessed January 6, 2025, https://www.scworld.com/feature/cybersecurity-threats-continue-to-evolve-in-2025-driven-by-ai

8. Generative AI Security: Emerging Attack Vectors and Mitigation Strategies - Medium, accessed January 6, 2025, https://medium.com/@petertou12/generative-ai-security-emerging-attack-vectors-and-mitigation-strategies-c0de90edb446

9. Five Back-to-the-Future Predictions for AI in 2025 - The Fast Mode, accessed January 6, 2025, https://www.thefastmode.com/expert-opinion/38803-five-back-to-the-future-predictions-for-ai-in-2025

10. 2025 Predictions: What Lies Ahead for API Security and Bot Management, accessed January 6, 2025, https://securityboulevard.com/2024/12/2025-predictions-what-lies-ahead-for-api-security-and-bot-management/

11. Application and API Security in 2025: What Will the New Year Bring? - Thales CPL, accessed January 6, 2025, https://cpl.thalesgroup.com/blog/application-security/application-api-security-2025

12. Traceable Releases 2025 State of API Security Report - AI-Tech Park, accessed January 6, 2025, https://ai-techpark.com/traceable-releases-2025-state-of-api-security-report/

13. Traceable Releases 2025 State of API Security Report: API Breaches Persist as Fraud, Bot Attacks, and Generative AI Increase Risks | Cybersecurity Dive, accessed January 6, 2025, https://www.cybersecuritydive.com/press-release/20241030-traceable-releases-2025-state-of-api-security-report-api-breaches-persist/

14. It's 2024 and the API Breaches Keep Coming - Salt Security, accessed January 6, 2025, https://salt.security/blog/its-2024-and-the-api-breaches-keep-coming

15. Robotics and AI: Emerging Cyber Threats in Autonomous Systems, accessed January 6, 2025, https://cyberlabsservices.com/robotics-and-ai-emerging-cyber-threats-in-autonomous-systems/

16. Robotics cyber security: vulnerabilities, attacks, countermeasures, and recommendations - PMC - PubMed Central, accessed January 6, 2025, https://pmc.ncbi.nlm.nih.gov/articles/PMC7978470/

17. Why AI is Essential for Solving Problems Beyond WAFs: A Deep Dive - Camenta Systems, accessed January 6, 2025, https://www.camentasystems.com/resources/blog-article/why-ai-is-essential-for-solving-problems-beyond-wafs-a-deep-dive

18. How Bots and Bad Actors Bypass Web Application Firewalls (WAFs) | CHEQ, accessed January 6, 2025, https://cheq.ai/blog/how-bots-and-bad-actors-bypass-web-application-firewalls-wafs/

19. AI-Powered WAFs vs. Traditional Firewalls: Protecting Your Web Applications - Medium, accessed January 6, 2025, https://medium.com/@seekmeai/ai-powered-wafs-vs-traditional-firewalls-protecting-your-web-applications-51f5bf46de8e

20. The Need for Next-Generation Web Application Firewalls (WAFs) in Modern Threat Landscape | A10 Networks, accessed January 6, 2025, https://www.a10networks.com/blog/the-need-for-next-generation-web-application-firewalls-wafs-in-modern-threat-landscape/

21. Modern API Security Risks and Challenges Solved with Web App and API Protection (WAAP) Solutions - F5, accessed January 6, 2025, https://www.f5.com/company/blog/modern-security-risks-challenges-solved-web-app-api-protection

22. Blog: 11 Reasons Your WAF Can't Secure Your APIs - Traceable AI, accessed January 6, 2025, https://www.traceable.ai/blog-post/11-reasons-your-waf-cant-secure-your-apis

23. Why WAFs Help, But Aren't Enough for API Security - Levo.ai, accessed January 6, 2025, https://www.levo.ai/resources/blog/why-wafs-help-but-arent-enough-for-api-security

24. Six Challenges of Applying WAF in the Cloud and How to Solve Them | by Carrie - Medium, accessed January 6, 2025, https://medium.com/@carriesafelinewaf/six-challenges-of-applying-waf-in-the-cloud-and-how-to-solve-them-02e4c95db7a0

25. Protecting Your APIs in the Wild: A Deep Dive into WAF and API Gateway Integration, accessed January 6, 2025, https://dev.to/apisix/protecting-your-apis-in-the-wild-a-deep-dive-into-waf-and-api-gateway-integration-56an

26. Why does WAF matter in API security? - Traefik Labs, accessed January 6, 2025, https://traefik.io/blog/why-does-waf-matter-in-api-security/

27. API Security Perspectives 2025 report from Kong Inc | App Developer Magazine, accessed January 6, 2025, https://appdevelopermagazine.com/api-security-perspectives-2025-report-from-kong-inc/

28. Beyond ChatGPT: How AI Agents are Shaping the Future of Cyber Defense and Offense, accessed January 6, 2025, https://www.radware.com/blog/security/beyond-chatgpt-how-ai-agents-are-shaping-the-future-of-cyber-defense-and-offense/

29. How secure are your web applications with WAF and AI-based WAFs? - Globalbiz Outlook, accessed January 6, 2025, https://globalbizoutlook.com/how-secure-are-your-web-applications-with-waf-and-ai-based-wafs/

30. AI-powered WAFs vs traditional firewalls: Protecting your web applications - AI News, accessed January 6, 2025, https://www.artificialintelligence-news.com/news/ai-powered-wafs-vs-traditional-firewalls-protecting-your-web-applications/

31. Mitigate Emerging Risks and Security Threats from AI Agents, accessed January 6, 2025, https://securitymea.com/2024/09/10/mitigate-emerging-risks-and-security-threats-from-ai-agents/

32. What are the risks and benefits of 'AI agents'? - The World Economic Forum, accessed January 6, 2025, https://www.weforum.org/stories/2024/12/ai-agents-risks-artificial-intelligence/

33. What is Web Application and API Protection (WAAP) - Imperva, accessed January 6, 2025, https://www.imperva.com/learn/application-security/web-application-and-api-protection-waap/

34. How Does a WAF Work? - Security Boulevard, accessed January 6, 2025, https://securityboulevard.com/2023/05/how-does-a-waf-work/

35. How does a WAF mitigate vulnerabilities? - F5, accessed January 6, 2025, https://www.f5.com/company/blog/how-does-a-waf-mitigate-vulnerabilities

36. Why Do I Need API Security if I Have a WAF and API Gateway? - Cequence Security, accessed January 6, 2025, https://www.cequence.ai/blog/api-security/why-do-i-need-api-security-if-i-have-a-waf-and-api-gateway/

37.  accessed December 31, 1969, https://pulse.latio.tech/p/wtf-is-cloud-application-detection

38. State of 'State of Cloud Security' Reports: Insights or Self-Owns ..., accessed January 6, 2025, https://ramimac.me/state-of-cloud-security

39. What Is Behavioral Cloud Application Detection & Response (CADR ..., accessed January 6, 2025, https://www.armosec.io/blog/cloud-application-detection-response-cadr/

40. How to build an offensive AI security agent - Anshuman Bhartiya, accessed January 6, 2025, https://www.anshumanbhartiya.com/posts/hackagent

41. How to build a defensive AI security agent with RAG, accessed January 6, 2025, https://www.anshumanbhartiya.com/posts/defenseagent

‍

The post Agents, Robotics, and Auth – Oh My! | Impart Security appeared first on Security Boulevard.