Turn XDR volume into revenue. Morpheus investigates 100% of alerts and triages 95% in under 2 minutes, letting MSSPs scale without adding headcount.
The post The Autonomous MSSP: How to Turn XDR Volume into a Competitive Advantage appeared first on D3 Security.
The post The Autonomous MSSP: How to Turn XDR Volume into a Competitive Advantage appeared first on Security Boulevard.
I have no context for this video—it’s from Reddit—but one of the commenters adds some context:
Hey everyone, squid biologist here! Wanted to add some stuff you might find interesting.
With so many people carrying around cameras, we’re getting more videos of giant squid at the surface than in previous decades. We’re also starting to notice a pattern, that around this time of year (peaking in January) we see a bunch of giant squid around Japan. We don’t know why this is happening. Maybe they gather around there to mate or something? who knows! but since so many people have cameras, those one-off monster-story encounters are now caught on video, like this one (which, btw, rips. This squid looks so healthy, it’s awesome)...
The post Friday Squid Blogging: Giant Squid Eating a Diamondback Squid appeared first on Security Boulevard.
Regulators made their move in 2025.
Disclosure deadlines arrived. AI rules took shape. Liability rose up the chain of command. But for security teams on the ground, the distance between policy and practice only grew wider.
Part two of a … (more…)
The post LW ROUNDTABLE Part 2: Mandates surge, guardrails lag — intel from the messy middle first appeared on The Last Watchdog.
The post LW ROUNDTABLE Part 2: Mandates surge, guardrails lag — intel from the messy middle appeared first on Security Boulevard.
Session 5D: Side Channels 1
Authors, Creators & Presenters: Lukas Maar (Graz University of Technology), Jonas Juffinger (Graz University of Technology), Thomas Steinbauer (Graz University of Technology), Daniel Gruss (Graz University of Technology), Stefan Mangard (Graz University of Technology)
PAPER
KernelSnitch: Side Channel-Attacks On Kernel Data Structures
The sharing of hardware elements, such as caches, is known to introduce microarchitectural side-channel leakage. One approach to eliminate this leakage is to not share hardware elements across security domains. However, even under the assumption of leakage-free hardware, it is unclear whether other critical system components, like the operating system, introduce software-caused side-channel leakage. In this paper, we present a novel generic software side-channel attack, KernelSnitch, targeting kernel data structures such as hash tables and trees. These structures are commonly used to store both kernel and user information, e.g., metadata for userspace locks. KernelSnitch exploits that these data structures are variable in size, ranging from an empty state to a theoretically arbitrary amount of elements. Accessing these structures requires a variable amount of time depending on the number of elements, i.e., the occupancy level. This variance constitutes a timing side channel, observable from user space by an unprivileged, isolated attacker. While the timing differences are very low compared to the syscall runtime, we demonstrate and evaluate methods to amplify these timing differences reliably. In three case studies, we show that KernelSnitch allows unprivileged and isolated attackers to leak sensitive information from the kernel and activities in other processes. First, we demonstrate covert channels with transmission rates up to 580 kbit/s. Second, we perform a kernel heap pointer leak in less than 65 s by exploiting the specific indexing that Linux is using in hash tables. Third, we demonstrate a website fingerprinting attack, achieving an F1 score of more than 89 %, showing that activity in other user programs can be observed using KernelSnitch. Finally, we discuss mitigations for our hardware-agnostic attacks.
ABOUT NDSS
The Network and Distributed System Security Symposium (NDSS) fosters information exchange among researchers and practitioners of network and distributed system security. The target audience includes those interested in practical aspects of network and distributed system security, with a focus on actual system design and implementation. A major goal is to encourage and enable the Internet community to apply, deploy, and advance the state of available security technologies.
Our thanks to the Network and Distributed System Security (NDSS) Symposium for publishing their Creators, Authors and Presenter’s superb NDSS Symposium 2025 Conference content on the Organizations' YouTube Channel.
The post NDSS 2025 – KernelSnitch: Side Channel-Attacks On Kernel Data Structures appeared first on Security Boulevard.
via the comic artistry and dry wit of Randall Munroe, creator of XKCD
The post Randall Munroe’s XKCD ‘EPIRBS’ appeared first on Security Boulevard.
This episode of the Defenders Log features host David Redekop and guest Andreas Taudte discussing the often-overlooked world of DDI (DNS, DHCP, and IP Address Management) and its critical role in network security.
Taudte defines DDI and explains his accidental entry into this specialized, yet foundational, field. He stresses that DNS and DHCP are core network services, and misconfigurations are common, often inherited from retiring long-term employees. He shares “horror stories,” including a system where a majority of DNS responses were “not existing” (NXDOMAIN) due to misconfigured devices and a global organization where administrative access was never revoked from former trainees.
The discussion highlights DDI as a forgotten attack surface, noting that attackers focus on areas like DNS tunneling (TXt, HINFO, SINK records) and data exfiltration because these areas are often ignored by traditional security tools. Taudte notes improvements in awareness, especially regarding the need to integrate DDI tools with the broader ecosystem.
Taudte emphasizes the importance of applying security in layers, especially for DHCP, which he calls the “Sandwich Kid” of DDI, as it links devices to IP addresses. He supports the “default deny all” approach (or Zero Trust) but notes that legacy infrastructure, such as 20-year-old factory robots, prevents a one-size-fits-all solution.
His final piece of advice is that DNS resolution should be predictable. Network teams must always be able to trace the path of a DNS query and predict the source of the response, filters applied, and what policies are enforced.
Would you like to explore any of the discussed topics, such as DNS tunneling or the concept of predictable DNS resolution, in more detail?
Full episode of The Defender’s Log here:
The Hidden Layer of Cybersecurity: Andreas Taudte on DNS & DDI Defense
Cybersecurity experts David Redekop and Andreas Taudte discuss the crucial role of DDI (DNS, DHCP, and IP Address Management) as a foundational layer for security.
View it on YouTube: https://www.youtube.com/watch?v=pOjLMKL0qEc
Listen to the episode on your favourite podcast platform:
Spotify
https://open.spotify.com/episode/4TG0PXtD0ColIrxFXr7n0N
ADAMnetworks
https://adamnet.works
David Redekop: You know what drew you into this world of DNS and DDI?
Andreas Taudte: DNS resolution should be predictable.
David Redekop: I didn’t tell you this. This is something that many people are not aware of because it’s quite old. I always like to ask, is there one piece of advice or wisdom that you would like the world to know?
Andreas Taudte: But if you have some suspicious, uh, DNS communication within your network, everything that is not leaving your DNS infrastructure can still be a threat.
David Redekop: You are clearly a good teacher, instructor, empowering others.
Andreas Taudte: If you look at some network management tools or some network monitoring tools, they have some tab or some submenu where you have some item to…
Voiceover: Deep in the digital shadows where threats hide behind any random byte. A fearless crew of cybersecurity warriors guards the line between chaos and order. Their epic battles rarely spoken of until today. Welcome to the Defenders Log, where we crack open the secrets of top security chiefs, CISOs, and architects who faced the abyss and won. Here’s your host, David Redekop.
(01:20 - 05:20)
David Redekop: Welcome to another episode of the Defenders Log. This is episode number 11, and, uh, I had the chance to meet Andreas Taudte. I hope I pronounced your name, uh, correctly. Andreas Taudte, welcome.
Andreas Taudte: Many thanks for having me, and it’s good to have a chat with you again.
David Redekop: Yes, absolutely. I didn’t tell you this.
Andreas Taudte: Oh, that makes my life easier. I’m kidding. No, no, no, no, no. Most of my German friends speak English better than I speak German anymore because it’s been so many years since I’ve had to actively use it. So, we’ll…
David Redekop: No, we’re going to make it the harder way. We’re going to stay with English.
Andreas Taudte: Okay. Okay. So, just have to be careful what I’m… what I’m talking about. Uh, when… when I… when I switched to German, when I mean thinking about something like, oh my god, what is he thinking about? Stuff like that.
David Redekop: Well, you know what they say. The mother tongue is, uh… years ago I was, uh, told that the way you determine your mother tongue is how you do your times table. And everybody learns the mathematical timetable. In this part of the world, it is usually done 1 through 9, right? 6 * 7, 7 * 8, 9 * 9, right? So you have this entire matrix of your times table, and I learned it in German. So to this day, if you ask me what’s 6 * 7, in my mind, it’s… [German thought process] and then I have to translate it back to English. So technically, German is still my mother tongue based on that determination, but…
Andreas Taudte: I never… never heard about it. Never heard about it. But what… what I realized is when I, um, in… in the past before the pandemic, I was traveling, uh, a lot, but only in the northern hemisphere. For whatever reason, I never had a chance to go to the… to the… to the southern hemisphere. And when you are in… in a location where you are talking in… in English the entire day and maybe for a week or so, it happened to me that even my thoughts started to be in English, which was just awkward.
David Redekop: Wow. What about your tongue? Do you get a tired tongue from being in English all day?
Andreas Taudte: No. I guess it’s a little bit difficult in the beginning when you haven’t done it for a couple of days or even weeks, uh, to… Yeah. Come up to speed and make it fluent and stuff like that. It always just takes a little while, like an… like an old machine that needs to warm up a little bit. But, um, once… once I’m in, um, it’s… yeah, I know it’s… it’s definitely not perfect. And if you look at grammar and stuff like that, totally not correct, but yeah, I get used to it quite very… very quickly. Very quickly.
David Redekop: Yeah. Well, this is going to be interesting from an AI LLM closed captioning perspective because our first run-through is always AI run, and then we go through an edit. So, I suspect we’ll have to do a first… a few German fixes in this one. Okay. I hope I’m not offending you, but I have a German joke ready.
Andreas Taudte: Okay.
David Redekop: You heard about the, uh, British that were calling the, uh, German Coast Guard because they were in trouble?
Andreas Taudte: Ah, yeah. Oh, I… I knew when this is heading to.
David Redekop: “Help, help. We are sinking.” And the German Coast Guard comes to the microphone.
Andreas Taudte: “Yeah, what are you thinking about?” I guess this was actually… I’m not sure, but I guess this was an ad many years ago in television about some… I have no idea, some academy where you can have some… some lessons or something like that. If you… if you look it up on… on YouTube or something like that, uh, you… you will actually find a real recording of that. It’s a very, very old ad from the… from the time when we had televisions and not when we’re not watching Netflix on… on iPads, right?
David Redekop: One of the casualties of having had cultural migrations in my life is that a lot of things I discover for the first time today, and people like you are graceful in responding, “Yeah, we’ve known about that for decades already.” But it’s… it’s a really good one. It’s an old one that is really good one. Yeah.
(05:21 - 09:52)
David Redekop: All right. Well, Andreas Taudte, it was a pleasure meeting you at, uh, I think the first time was in Stockholm at, uh, DNS-OARC, and, uh, you, uh, highlighted some things that made me realize that you really are an extremely deep learner. And, uh, based on what I saw you, uh, deliver in terms of content, you are clearly a good teacher, instructor, empowering others. And partly what we want to do with the Defender’s Log is not only raise awareness around the aspect of zero trust networking, zero trust connectivity, and… and how just the core of, you know, doing security differently than we’ve done it in the past. Instead of layering so many things, doing everything at the top layer, let’s start with doing things properly at the foundational layers. Let’s think about first building blocks and first principles, and, uh, you seem to just fit squarely in that space. So, I’m glad you, uh, were available to, uh, hang around with me here online for a bit. And maybe you can just start by telling us, you know, what drew you into this world of DNS and DDI? Maybe start with DDI 'cause that term is very common in… in your world, but it’s not necessarily well known. So, let’s start with what DDI means and then how you got pulled into this world.
Andreas Taudte: Oh, let’s… let’s see if we, uh, we can make an entire podcast about that. Um, let me… let me try to make this very short. So, first of all, DDI stands for DNS, DHCP, and IP address management. When I started in this industry, it had… it already had a… a different name. It was just called IPAM. And IPAM back then already included the management of the core network services DNS and DHCP. And then around, I guess, 2012, Gartner came up with a report and they actually created this acronym of DDI. Before that, it was just IPAM. And back then, uh, the old IPAM guys were a little bit confused like, “Yeah, wait a second. DNS and DHCP was always included. So why double it?” Meanwhile, I like it that we have the phrase or… or the… or the acronym DDI and IPAM because in many tools you will find an IPAM section. So if you look at some network management tools or some network monitoring tools, they have some tab or some submenu where you have some IPAM to manage some networks or document some networks. But DDI really means that you have some interaction with the core network service, that you are pushing configs and that you are getting results into the database, for example.
Andreas Taudte: And I ended here by accident. I was, uh, a trainee at a company that was doing banking software, and when a customer not only wanted to buy the software but wanted to get it hosted in a data center, they had a subsidiary that was, uh, a data center provider, and I was a trainee in that organization. And during that time, they got acquired by a huge, massive organization that wanted to get foot in the door into this industry. Um, and during that period where my time with this company came to an end, they weren’t allowed to hire people because they were still talking about contracts because it was a… a Swiss organization. I was working for a German organization, and some, um, managers in the different organizations had to negotiate stuff and things like that. And in my class back then, there was a guy, uh, that was doing… ex… that was a trainee for a system integrator that was, uh, doing DDI purely. Nothing else. Or IPAM, sorry, back then it was IPAM, right? Um, and he was like, “Yeah, if they… if they can’t hire you, uh, maybe just send us your CV.” And, um, two weeks later, um, I was hired, and I moved from the guy that was coming to the office, uh, whenever he wanted to, uh, do some stuff on data center machines and getting stuff done with monitoring and, uh, backups and you name it. I moved right into the industry of being a consultant for DNS and DHCP. So at the first couple of weeks, I had to read a lot of books, and some of them are still behind me. If you look at the recording on… later on on YouTube, for example, you can see these books, and some of them are back from these days. And yeah, and it’s a… it’s a small niche, and uh, I’m in that niche since 16 years now, and it looks like that I… it’s the only thing I can do. I can’t do anything else.
(09:53 - 14:23)
David Redekop: Well, it is a fun space because it is not one where you could implement something and offered a solution and have everybody adopt it. It’s not like it’s got the lifecycle of a computer that may be anywhere between three to eight or nine years at the… the outside that eventually gets caught up with a modern operating system. Like, I don’t think Windows 95, for example, or even Windows 2000 can do anything online anymore because it’s so deprecated. However, I, for example, know personally of a Fortune 50 company in Canada that still operates on publicly used… on public space as private space because somebody years ago read Hitchhiker’s Guide to the Galaxy and thought that, “Oh, since 42 isn’t in use, we’re just going to use 42 dot for our entire enterprise.” And so when you start doing that and then you start statically assigning everything from gateways to switches, there is no refresh cycle of IP addressing because you might replace hardware in the regular lifecycle, but you’re going to adopt the old address schema. And so this is now going on, I want to say, about 15 years that… that they’ve been on a re-addressing project. So in effect, they’re using a proper RFC1918 today in parallel to the old one, but anytime we try to completely remove the old one as an alias on gateways, we still find stuff that breaks, right? And so IP address management, you might think of it as you… or DDI as something that as niche as it is, the more niche it is, the more you know fixed it should be. And yet it goes back so far. And so unless you have someone like yourself that really understands the IP addressing history of any organization, a lot of things don’t make sense. So in a… a new person that’s responsible for infrastructure that has experience can basically, uh, determine what might have happened in the past in order for us to arrive at this stage. I’m not sure if you have similar stories.
Andreas Taudte: Oh yeah. Yeah, definitely. In many cases, the network team that is responsible for these core network services, DNS, DHCP, and the IP address management on top of it, they haven’t built it themselves. They inherited it from somebody. It happens very rarely that an infrastructure like this is managed by somebody who built it back then. And just during an… an event that I attended this… this week, I met again with a person that is responsible for the, uh, DNS and DHCP infrastructure of a huge car manufacturer since nearly 30 years, and now he’s retiring. So he knows every single server and zone, and I guess he even knows every record personally, something like that. So that… that’s… that’s very rare that you have somebody that is… that knows an infrastructure like this in and out. And… and hopefully they make a proper offboarding so that the… the new team has a chance to, yeah, get as much information out of his brain as possible. And this is… this is happening in my industry at the moment more often, that you see people that are responsible in organizations for these services since 20 years, 25 years, or in that case, nearly 30 years, and they are retiring. And yeah, maybe they will… they will come to the office once a week for half a day to get some extra… extra income. So they are not… not completely gone. But, uh, for everything that is related to daily tasks and troubleshooting and stuff like that, and especially with DNS, you can’t wait till Friday afternoon when the old guy comes into the office to troubleshoot an issue in DNS. That’s not possible. So this is happening, uh, very, very frequently, uh, right now. So since… since one or two years, I see stuff like this happening more often. And yeah, if you are the new guy, maybe somebody that just finished university, somebody that grew up with, uh, with an iPad and internet in every coffee store… Yeah, that can be challenging.
(14:24 - 23:38)
David Redekop: Absolutely. You must have some stories that you can tell even if you don’t identify the guilty. But what’s like the worst horror story where you’ve walked into where there is some kind of a conflict whether or misconfiguration in the area of DDI?
Andreas Taudte: The short answer would be, um, every time. Um… No, but… but, um, to… yeah, um, I always just try to be the, uh, the advocate for these teams, uh, because then the… the real issue is that it has been there since ever. So DNS and DHCP was running in an organization since ever, as already… as I already mentioned, it was, uh, created, uh, designed and built many, many years ago. And in a lot of implementations, it’s just a checkbox. If you take a look at the Windows box for example, yeah, it’s a checkbox in the server manager and ta-da, you got a DNS server. Yeah, it’s, uh, it’s running and it’s doing its job, so it… it don’t has the attention that it should have. And in most cases, it’s not that you have a dedicated team or person that is, uh, responsible for, uh, taking care of DNS and DHCP other than this guy that is… that that is doing this since… since 30 years. In many cases, it is just a, yeah, like a side hustle of the network team in addition to, yeah, the WAN and the LAN and the Wi-Fi and Voice over IP and security and you name it. So every time when I have a chance to meet with a… with a new organization, I try to do some kind of workshop to have a chance to really deep dive into their infrastructure. Because if you ask a client, “Hey, what does your DNS and DHCP look like?” And they go to the whiteboard and they make some nice drawings, and this is just, uh, 80% of the truth. Sometimes not even half of it. But the remaining, uh, 20%, this is where… yeah, the… you name it, hit the fan. So what I tried to do is I tried to get as deep as possible into an infrastructure. Um, and I even created over the last 15 or 16 years, I created a kind of workshop documents which is more or less something like a questionnaire. It’s actually, it’s available on GitHub. I’m not sure if we can add it to the podcast notes, um, afterwards. Maybe that’s possible.
David Redekop: Absolutely. Yeah.
Andreas Taudte: Yeah. Happy to share that. So because if you ask more specific questions, you make the client think. They are just like, “Oh yeah, wait a second. Yeah, you are right. We have something like this in this specific location because it’s something like that.” So stuff like that always happens when people like me in this niche walk into a huge organization with thousands or hundreds of… of servers. Maybe some stories that are quite kind of funny. Um, so for example, many years ago I… I installed a POC with a… with a customer, and we made a POC very close to the, uh, production environment. So that it’s… it’s not just a small lab where they… where they were able to play around it. It was a proper POC. And back then, um, the DDI tools started to add dashboards to their web interface where you have some statistics like memory usage, CPU usage, or some statistics from DNS and DHCP. And there is a very basic statistic, uh, available in ISC BIND which is in most cases the underlying DNS server in the DDI tools. And it has something like, okay, how many NXDOMAIN, uh, responses do you have? How many SERVFAIL responses do you have? And in this specific case, we were running this POC for a week or two, and then we had something like 75, 76 percentage was NXDOMAIN, uh, responses. So which means that the majority of responses in their DNS were responses answered with “not existing.” And that helped us to identify some, u, misconfigured systems that they distributed all over their locations. So it was nothing like a DNS tunnel or some control plane of a command and control center or something like that. Back then it was just a misconfiguration, and we were able to identify that, which dropped the load on the DNS servers heavily because these boxes were causing a lot of… of CPU, uh, usage and memory usage. So this is something that was an easy fix.
Andreas Taudte: Another one was also was more related to let’s say the… the organization behind an… in DDI tool because many organizations think that they can just buy a fancy appliance or XYZ as a service and ta-da, they have a security deal in DHCP, and that’s not the case. And in this specific scenario, it was an official reference customer of a huge DDI vendor, and they were even when they had some regional meetings with other customers. They were even on stage presenting their solution and stuff like that. And I know them since more than 10 years. Actually, I designed the DDI infrastructure back then. And years later, we made a security assessment of the infrastructure. And we identified that they have user accounts that no longer belong to the network team. And we try to identify what these user accounts are. And the story behind that is when they have a trainee in the organization, they are moving from department to department. So they are in the network team for a couple of weeks and then they go to the security team, then they go to the development, then they go to the support. So they during their… their time over approximately 3 years being a trainee in this organization, they have some weeks or months in every single department. And when they join the department in the network team, they have an… they get an account in the DDI tool, and because they had… they should somehow support the rest of the team, they have an admin account. So they have full control over the system. And maybe they finish their time being a trainee and then they become an employee… employee, and then they move into the support department or they stay with the developers. They have the same account in Active Directory like they had when they were a trainee, and nobody ever refuted the access rights. So somebody belonging to the dev team has full access to the core network services or the management platform of the core network services for DNS and DHCP of a global organization. And this is not really related to DNS and DHCP security per se. It’s related to, yeah, ownership responsibilities, rules, policies that come on top of that. So these are… these are two funny stories that I… I recall from the past couple of years, and there are much more. So if we… I’m happy to… to have some beers with you in the future. Uh, we can… we can deep dive into many, many more stories like that.
David Redekop: I’m sure there’s no shortage of situations where the principle of least privilege was just never registered because you don’t need the principle of least privilege in any new business to drive up topline. You don’t need it in order to drive down costs. In fact, it’ll do the opposite sometimes. You don’t need it to create a, you know, leading edge status even as a software company. But so many proactively secure methodologies actually require a commitment and a conscientious effort because of the risk of not doing so can have such a large impact. Right? And so if there was ever an incident in an organization like that and someone looked at doing proper root cause analysis, it’d be like, “Well, why did that compromised account have those admin privileges that were not necessary?”
Andreas Taudte: Yeah, that’s… that’s a story that we see over and over again. And we keep on bringing up the theme that an attacker just needs to find very often for each stage of the attack just one weakness. What’s the next one weakness that I can exploit? And that happens to be one of them.
(23:39 - 25:07)
Andreas Taudte: Yeah, that’s the issue with… that’s… that’s… that’s related to DNS specifically, but also to the entire DDI infrastructure at an organization because it’s something like an… an… an intersection between different areas. So it covers network, you have cloud, you have security, you have operations. And in many organizations, when the organization is big enough, these different flavors are different departments and they are even sometimes separated into subdivisions and things like that. So when maybe when a potential attacker would like to slip through the detection mechanisms that they have in place, if I have four different departments that are more or less responsible for things that are related to DNS, DHCP, and computers management and maybe they have their own tools or they don’t talk to each other or they… they just meet twice a year to have some kind of recap of the year meeting, stuff like that. So if each organization only sees a small portion of the entire DDI world of that specific organization, it’s much easier for an attacker to slip through the potential detection mechanisms that each of these individual departments have in place.
David Redekop: Right. Wow. I am really wondering how many organizations, if there’s even such information available of what the attack surface is like in this boring network plumbing area of DDI. That’s how it’s often seen. Like it doesn’t get the very cool marketing fluff on any product. Like no one goes out and brags about their DDI security posture. In fact, I’ve never seen those three words strung together, right? Because it would be super uninteresting for anybody that’s a potential investor or someone that’s looking at, you know, what is your overall revenue versus cost model? What’s your gross margin? They’re not interested in those boring behind the scenes unless they are in the world of proper risk assessment and making infrastructure long-term sustainable. We could definitely spend some time analyzing that, and I’m wondering if an organizations of analysts have any insight into how big the problem might be because what I notice is that the way attackers are growing their capabilities is they are looking for areas that are not yet addressed. So if we don’t have a broad approach to securing a particular area, then the organized adversaries can basically hone in on that, and you can see that they’re definitely thinking about what’s our next area of attack and there’s… this might be an area that they can still focus on.
(25:08 - 29:45)
Andreas Taudte: Yeah, that’s… that’s… that’s right. That’s right. Based on my experience in this field, it’s getting better. Um, I would say so especially in the last couple of years the… the awareness that DNS, uh, is… is a critical service, that it can be attacked easily, and also that it can be… can be used as a transport for some malicious things and behaviors and stuff like that. Um, so it’s getting better. With regards to IP address management, the ‘I’ in DDI, I have seen improvements in the past as well. So in… especially with regards to integrations into third-party systems. So the… the DDI vendors realize that nobody is buying a DDI tool to live on its own. It’s part of an… of an ecosystem. It has systems on the left hand side, on the right hand side that could benefit from the information that is within the database. And on the other side, the IPAM system itself can benefit from information that the other tools store and collect. For example, one thing, um, that is, uh, overseen more often is the… the second ‘D’. Um, it’s DHCP. Um, and somebody… somebody called it the “Sandwich Kid.” I’m not sure if you… if you are familiar with that phrase or the sandwich kit. So if you have three kids, you have the oldest one and you have the youngest one and then you have the one in the middle. That is…
David Redekop: Yeah, it’s always the one in the middle. Yeah, there’s… there’s this… that’s good.
Andreas Taudte: There’s this show, um, Malcolm in the Middle. It’s an older one. Not sure if you… if you… if you know that, um, and he’s… he’s some kind of sandwich kid. And DHCP is exactly the same. So it’s when… when… when a company is not taking much care about DNS, then you can be sure that DHCP is completely under the radar. And it gives you so much useful information because it’s linking a device to an IP address. You have some timestamps, and in within a DHCP package, you can identify specific things like you can easily, uh, differentiate between a Windows box and a printer. And this is very, very value information. And if you just look at your IP address management database and you have the information that, “Oh, there’s a suspicious client because in that network there shouldn’t be a printer. Why is there a printer?” It could just be something like a misconfigured or misplaced, uh, machine or maybe an attacker that is faking a MAC address that somehow or belongs to an area where printers are typically located. Uh, so stuff like that. So it’s getting better, and if you look at various let’s say, yeah, rules and compliance policies and stuff like that, just… just recently, um, a new version of this, uh, guidance from… from… from NIST came out. Um, the first one that is, I guess it’s always 10 years ago when they wrote the first document about DNS security, it was more related to DNSSEC. So, uh, signing and validating DNS answers or responses. And the… the new version really addresses more specific things related to DNS security. So it’s getting better, and it actually, it can happen when you are an insurance organization or a bank or something like that, that some external audit happens once in a while and they will ask you stuff like, “Okay, who has access to DNS and do you have an audit trail of things that change in DNS? Do you have something like a two-man rule that… that is, uh, in place for critical records like, yeah, maybe you can just change the record of a printer but you can’t change the record of an SAP system, for example, stuff like that.” So it’s… the awareness S is a raise in awareness. But of course, in many cases, I come to organizations that have thousands or hundreds of domain controllers running some Active Directory integrated DNS, and the IP documentation is a spreadsheet that is stored on a share drive. This is still the case, and from my perspective, it’s really impressive to see that a massive organization with limited resources to people and money is able to manage such a complex infrastructure with some core services running as just some built-in, uh, implementation and some spreadsheets or… or Wikipedia or intranet sites. It’s very impressive that they are able to manage it. It’s… from my point of view, it’s… it would make their life much easier. But I’m always impressed how stable these networks work with banks, car manufacturers, retailers, universities all over the place.
(29:46 - 33:32)
David Redekop: It is so true. I am constantly marveling at the exact same thing. Why is it that it works? But it works because there’s human attention to it, and it’s because we’ve always done it this way. That is the reason we’re hesitant to change. And someone started at some point to track it in an Excel spreadsheet and it stayed there. Some of them are proud that they’ve moved it to Google Sheet so that they can now share it better, and that’s… that’s already a step forward. But no, I… I like the idea of Infrastructure as Code being applied to network configuration because it really only makes sense to do those fundamental things properly from first principles. And then from then on, you have the best possible long-term value by doing things right from the base layer up. It’s just… it’s like that with every other industry. It’s like that with construction. If you don’t have a proper… in our part of the world, we have basements, right? So before you build a house, you always have to dig a hole and then you’re putting proper concrete as your foundation, both as the floor and as the walls. And now anything you build on top of that is going to have a… a lifespan of maybe not thousands of years like some buildings used to be constructed, but at least, you know, 50, 70, maybe 100 years with a proper foundation. And it’s amazing that we don’t translate that back to networks because if you set up a business, if you set up a network, chances are that it’s going to be around a long time. It is worth it to just build that foundation properly.
Andreas Taudte: Yeah. And then nothing… nothing consists longer than a temporary solution. So something like, “Oh yeah, yeah, we had just created this as… as a draft,” and then, uh, 12 years later the draft is still used by the majority of the infrastructure. But yeah, this picture of a, um, of a building is actually something that I… that I used in a, um, in a presentation many years ago where I tried to… to highlight to, uh, let’s say the IT management, uh, layer that when they are talking about zero trust and digitalization and artificial intelligence and you name it. They are already talking about the decoration of the balcony on the second floor, but they haven’t started with the foundation yet. Uh, maybe it’s there, but maybe it’s somehow rotten. Maybe you have some… some water, some groundwater that is… that… that is coming through the walls and stuff like that. So getting a proper foundation is… is necessary. All the other topics on the balconies, they are very, very relevant for sure. Definitely, we are living in… in very, very modern worlds where your fridge is able to… to communicate with the internet to order milk and stuff like that. So we have completely different challenges. So things like… like zero trust and others in… in that area absolutely relevant and they have to be on the agenda. But, um, what I see more often is that there’s a new buzzword every year and then the… the… the… the management layer, the IT organization is following this specific password and they still are running with a spreadsheet and some Microsoft based DNS in… in… in the… in the backyard.
David Redekop: Yeah. I mean, and there is value in some buzzwords because if the buzzword gains, uh, awareness and popularity, then at least the C-suite or whoever upper management happens to be in an organization can ask, “How are we doing in this buzzword?” Right? And get some accountability. But yeah, generally when that is the only area of… of response, it’s… it’s not sufficient.
(33:33 - 39:27)
David Redekop: Let’s, uh, switch for a moment to the marketing term “zero trust” that I don’t really like, but only because it is a buzzword that’s overused 'cause everyone’s zero trust and AI everything. It really… it really burns those of us that have been working in that space long before those terms even existed and… and applied those technologies. But in our process of doing the default deny all, to me that’s a… a more technically accurate, uh, description. When we do default deny all, we basically treat every destination IP address as a stranger until it is not. And the way it is not a stranger is that the DNS query was made, matched to a policy, and then a protective resolver said “That’s safe and here it is,” and the policy engine says, “Yes, you’re allowed to go there.” Right. So that… that process… And you pointed out when I chatted with you about, I found it really quite intriguing because I had not seen that one particular threat before where attackers can actually utilize the serial number of the Start of Authority record and map it such that it maps back to an IPv4 address. Tell us more about that.
Andreas Taudte: This is actually something that I just saw at a, um, at another webinar and I guess it was some guy from Infoblox from, I guess, Poland or Czech Republic. He… he made the… the… the original presentation where I saw that first, and I immediately tested it and it just worked. And I used it, uh, during, um, an event that I attended recently to demonstrate how easy you can put stuff into DNS. And if it’s not observed properly then, yeah, you can just… And the fun… the funny thing is you don’t even have to recalculate the serial number into an IP address. When you use ping on your command line for example, you can ping a serial number because it’s just 32 bits. So that means you don’t have to recalculate it and add some dots between the octets. You can just ping it. It just works. And it’s something that is… it’s always funny and scary at the same time what you can do with DNS. Um, there’s… there’s a… a collection that, um, a guy called Peter Lowe is… is collecting since many years. So it’s some funny stuff that people do with DNS. So they… they use it to… to, uh, stream MP3s for example. This is possible. So they… they actually… they… they store MP3s in public resolvers and they have a, on the other part of the world, they have the capability to read that and play music. So stuff like that is possible. It’s something that is there since ever. It’s a 40 plus year old protocol. And because of that, it’s… it’s like like in… like in… in our environment as well. So when you… when you… I guess you grew up when, um, a fridge was already available. I’m pretty sure that when you came home there was a fridge in the apartment or in the house. Uh, so this is something that you are used to. So you’re not taking much attention to, yeah, how the fridge is behaving, what, um, energy it is consuming. Is it clean for example? Is it… is it cleaned more often? Uh, so to avoid some bacterials and stuff like that because it had always been there. There was food in it all the time. So you’re not taking much attention to bringing much attention to it. And it’s the same with, uh, with… with DNS and especially when the team that is maintaining, um, the DNS infrastructure just inherited from somebody else that is no longer with the company.
David Redekop: Yeah, it… it works and there’s… there’s this very, very valuable phrase that “never touch a running system,” which it has some… some relevance of course. So if it’s working don’t touch it, but, um, just because it’s a broken doesn’t mean it’s working. Right. Right. Yeah. You mentioned Peter Lowe, and he was actually, uh, the one who introduced me to DNS.toys. I’m not even sure if .toys is a valid TLD domain, but whoever runs that, I’d like to give them credit because there’s a really cool stuff. I actually created a conditional forwarding rule on my network because there’s like really cool things that you can do like get a command line quick report of the weather in your area. So that’s… that’s not an example.
Andreas Taudte: Yeah, of course.
David Redekop: Yeah. Yeah. Really, really very cool. But anyway, when you pointed that thread out to me, I thought I need to really figure out, you know, how this works. And I was very excited to have the same emotion repeat when we see a new threat that we haven’t seen before. How does this whole approach of default deny all or what we call “don’t talk to strangers”… Microsoft, by the way, at Ignite now announced general availability of the Microsoft zero trust DNS which does that same approach on Windows 11 Enterprise or Windows 11 Pro Education. Um, it’s available as long as the device is enrolled in mobile device management. You can basically push a DoH profile to the Windows endpoint and then have that Windows endpoint use that DoH service only and then it integrates with the Windows filtering, uh, platform to basically apply the same thing to Windows endpoint. And so we’re excited because finally we’re not the only ones in the world that are saying this is the way to do egress control and proper default deny all.
(39:28 - 44:21)
David Redekop: But back to the threat that you pointed out to me that Infoblox had shared with the serial number trick, it was good to know that that was not a way for an attacker to get out. But at the around the same time is when we saw more and more, uh, report around, uh, TXT record abuse by attackers. What have you come across in that space in the TXT record abuse area?
Andreas Taudte: It’s not only the… the TXT is… is used very often because you can store a lot of information in… in a TXT record, but there are other record types that are not really recognized by some let’s say DNS analytics tools. So for example, in… in many other devices or infrastructure devices in… in a network like firewalls and you name it. Meanwhile, they also joined this track of a DNS security. So they have something available. But just… just recently I learned that in many cases they are able to validate A records, AAAA records, PTR records, but if it comes to other record types like TXT for example but also HINFO or there’s a record type called SINK, uh, which was originally planned to be the record type for everything else that is not an address or a name. So when it comes to… to stuff like that that is handled by every DNS server on the planet correctly but a firewall for example that has some inspection related to DNS ignores it because it has nothing. It can’t comprehend what this TXT record or HINFO, uh, record actually means and what it should look like or what it shouldn’t look like and stuff like that. So it just passes through as a standard DNS for example. So this is… this is stuff that you see quite often in… in let’s say everything that is related to tunneling.
David Redekop: Yes.
Andreas Taudte: Through a DNS protocol. So tunneling, um, is used for different flavors. So you can use it for data exfiltration which means that you try to stay hidden in the network as long as possible because you’re using DNS. So we are not talking about a something like a fiber connection. So, but if you are in the network long enough, um, and if you can extract, uh, data slowly via a DNS tunnel, of course, if you have a… an export of a… of a table from a customer database that contains credit cards, you don’t need many gigabytes. Um, if you have 100… 100 credit cards, um, that’s more than enough, I would say. It’s also used for, um, command and control which means that if you have an affected, uh, device that needs some more information or some more data from the command and control center that is outside of the organization that, uh, was compromised, then a DNS tunnel is used as well, but in that case it’s used bidirectional so it’s not just to get data out it’s also to get information in.
David Redekop: Yes.
Andreas Taudte: So and it’s it’s not only TXT records. Um, they use A records, AAAA records and other record types as well. And very, very modern, uh, DNS tunnel techniques, they even use combinations so to make it harder to get, uh, detected. So they… they identify, for example, the different DNS servers in an infrastructure and coming back to the… to the scenario where you have domain controllers. Um, how easy it is to find out the domain controllers in an infrastructure is you can just query the DNS name of the… of the domain and then you get a list, um, of all the domain controllers that’s built in and then you have let’s say 20 different, uh, domain controllers that talk DNS and in many cases they can resolve internet names as well and then meanwhile these tunnels are so, uh, intelligent that they first they use different types record types. So some data is… is transferred via TXT, some is transferred via, um… um, A records, and some is even transferred via SOA record and stuff like that. And then they switch the timings. So it’s not like that they just hammer the DNS server with… with queries. They have some delays in between and they change the delay. So maybe they wait a second before the next package and then they wait two milliseconds for the next package and then they wait 5 minutes and then they even switch the resolver. So they maybe they start, uh, the tunnel on the domain controller number one, use some different, uh, delay, some different records, and after a while they switch to another domain controller. So that makes it harder to, um, identify such a tunnel because you can’t identify a tunnel by the first package. You need some package… packages to identify okay this looks suspicious. This seems to be a tunnel. But if you are spreading this over different DNS servers in the infrastructure and you just look at one specific DNS lo… lock of one specific server, it’s very hard to identify okay this is a part of a tunnel. So you really have to collect query and response logs from all these servers, bring them into one place and there you can identify “Okay, it looks like that this specific client has established a tunnel that is using various flavors of records, different delays between queries, and is using 10, 15 different DNS servers to get the data out or in.”
David Redekop: Wow. There is clearly a tremendous amount of effort in looking for evasion techniques by the threat actors for them to make all of the complex DNS evasion possible that you’ve just described. I just marvel at it and that just confirms with me over and over again when I hear how complex threats can be, um, that the only approach that a defender has in the long term is to take a default deny all approach, hijack all non-authorized DNS servers, and basically have a deterministic policy approach that ensures that you know even down to record types. We’ve only recently introduced the idea of record type blocking on a per policy basis because for example the NULL and PRIVATE record types and TXT record types are not used by our everyday devices. So… so the devices that user devices are laptops, computers and smartphones, they don’t need to use those record types. They only need A and AAAA typically. And so that approach hopefully will… will keep us in a stronger defensive space, you know, before, you know, uh, someone’s at risk. 'Cuz I always thrive with the idea that a managed SOC gets an alert that says, “Here was a threat. It was mitigated before any damage could get done.” But we should investigate how that, you know, malware or how that fileless threat got into the network to begin with. But it’s such a thrill as a defender when you see that the work that you did in advance actually stopped the attackers at the, you know, second, third, fourth, fifth step of the attack chain. And, uh, that thrill is what drives us to look for the next defensive technique.
(44:22 - 51:33)
David Redekop: But balancing it at the same time with not creating user frustration. Right? So how do you have principle of least privilege not become principle of least aggravation? Uh, you know from user’s point of view…
Andreas Taudte: That’s… that’s… that’s a difficult one. So from my point of view, um, organizations they should just combine everything. Of course, uh, it’s… it’s… it’s great that vendors of operating systems in… in… included capabilities like zero trust DNS for example, this is great. In many organizations, of course, the majority of, uh, of employees are sitting in front of a Windows box. Yes, it’s it… that’s what… what what I see when I… when I visit, um, organizations. But of course, you still have, um, this… this fridge in the coffee kitchen. And, um, in the last couple of years, I had a chance to work with these massive organizations that are producing stuff like cars and others. And here, uh, you have different challenges like you have an… a robot that is running in a factory that was bought 20 years ago and it has some DNS server hardcoded into the mainboard and this thing still has to run for the next 10 years before it produced enough cars to buy a new robot, something like that. This is the typical calculation that companies like that like this flavor, uh, do. So even that you have something like zero trust DNS that is available for the operating system for the people in the office. Yeah, you will see a lot of machines, uh, talking IP and using DNS that are far away from having something like zero trust DNS installed per default. So even just something like a simple response policy zone that is just filtering all the already known bad guys is still useful. And don’t only enable stuff like this on your DNS server. Of course, every communication in the network starts with a DNS query and a response. So A can’t talk to B other you have some hard-coded IP addresses in some config files. And even that is the case in some of these factories for example. But in addition to this, yeah, if your firewall has a DNS security feature and it’s part of your subscription, which is always important to validate, yeah, just enable it. And if you have some some other, uh, infrastructural devices that can do stuff with or that can review stuff that is in your DNS in your DHCP just… just use it. And something that is… that is… that is… that is quite old but still relevant is stuff like like NetFlow for example. This is something that, uh, many people, uh, are not aware of because it’s… it’s quite old. Um, and I’m not sure if this is even taught on, uh, in… in universities or schools that something like NetFlow exists and this gives you, uh, very good, uh, visibility.
Andreas Taudte: So just enable it all. Security is an onion and you have to add, uh, one layer. Um, and if you have multiple layers that cover DNS, the chance that you are in a… in a good, uh, shape is much better, uh, compared to just use one thing. Just for example have a cloud security solution that filters all your DNS traffic before it hits the the internet which is good but if you have some suspicious, uh, DNS communication within your network, everything that is is not leaving your DNS infrastructure is… can still be a threat. So if you have different network areas, so some high security network areas and some other network areas that are less secure and somebody would like to access something in another security area and the policy is doesn’t allow that but there are DNS servers in between you have your East-West communication in your DNS infrastructure that is also able to create some kind of DNS tunnel for example. And if you filter your suspicious DNS queries only at the edge before it… it leaves your… your infrastructure… Maybe you are missing a huge portion of DNS that can have some suspicious behavior as well.
David Redekop: You just reminded me how important it is for teams in their area of knowledge to be open to what they need to be aware of from other teams. Sometimes if we talk to a network team about a… a necessary change that the security team requires, there’s resistance there and usually the resistance comes from lack of awareness of what the security impact is. And so there’s lots of value for security teams to become more network aware, for the network teams to become more security aware, for the application teams, the apps to understand more about network and security because the space is quite deep and all we need to think about is reflect upon what you just shared around the various, uh, attack techniques.
Andreas Taudte: Yeah, definitely.
(51:34 - 55:54)
David Redekop: I have not even gotten to a single one of my questions on my, uh, document here, Andrea. So, I think that’s a good thing and that’s okay. But there is one question that I always have to ask 'cuz I know for you it’s Friday afternoon. It’s all… it’s already getting dark or has already gotten dark during this call. You probably want to get together with family. Uh so, I’m not going to keep you much longer, but I always like to ask, is there one piece of advice or wisdom that you would like the world to know?
Andreas Taudte: One advice that I try to give all my, uh, clients, um, customers, prospects is DNS resolution should be predictable. So as a… as a network team that is responsible for the DNS infrastructure, when a specific client in a specific location sends a query for a specific name, the team has to be able to predict what path the query takes and where the response is coming from and what filters or policies are applied, um, during this process. If you aren’t able to do that, I’m not for 100% of course we have infrastructures that are quite complicated but if you are not aware if, uh, a client in location A wants to resolve www.example.com and a client in another location is doing the same and you don’t know where the answer at the end, uh, is coming from, then you really have to start an assessment for your DNS infrastructure. This is the from my point of view the… the minimum criteria. You need to understand your DNS infrastructure enough to make predictions like that. There are some cases where you can’t predict stuff like that, especially when it comes to… to policies and some compliance capabilities are… are involved of course. But if something is resolving host123.company.corp, the team should be able to identify what resolver is used. Is this resolver equipped with some RPI zones or some other threat intelligence? Where is this query forwarded to? And where is the authoritative DNS server located that provides the answer? Is it a secondary? Is it a primary? Is it talking to a hidden primary, for example? Or is it within the same location? Is it in the same region? Are there some GeoIP things involved so that a client on location A gets a different IP address than a client in location B for exactly the same query? So this is an advice that I try to share with… with all my clients and then we try to identify how good they are in that specific case.
David Redekop: That really hits very close to home. But you just said RPZ and I just want to say thank you. I know the world of internet is US-centric where it’s RPZ, right? But, uh, the Canadians and the Brits, we like the “Zed.” But no. Okay. So now you just gave me another reason for us to reconnect because we built a sort of informal way of gauging a scorecard on DNS resilience on the inside of infrastructure. So we’re not talking about the authoritative or public resolver side, but on the inside of a network. And then I… and I think if we get this right, we might just have to come up with a new slogan. “It was never DNS.” Because if you get 100% resilience, it was never DNS. That would be kind of cool.
Andreas Taudte: That’s right. And when you… when you just… just recap the recent issues, DNS was… was doing great. It was just the management on top of DNS. That was some kind of…
David Redekop: Yes.
Andreas Taudte: So it’s… it’s exactly…
David Redekop: Like there was no DNS protocol patch. There was no ISC BIND patch that needed to come out, right? It was the data source. Yeah. But that nuance probably never left, you know, the people that really were truly interested at the actual root cause. But yeah.
Andreas Taudte: Yeah, that’s right.
(55:55 - End)
David Redekop: Andreas Taudte, it’s been a real pleasure chatting with you. Thank you for your time today. We’ll, uh, connect again and look forward to seeing you again as well.
Andreas Taudte: Yeah, many thanks for taking your time and I’m looking forward to another episode even without me. Just… just… just, uh, uh, listening to all the stuff that you, uh, collected was great and I will continue to follow these episodes and yeah.
David Redekop: Well you definitely not only, um, met the bar but you allowed the quality and a sense of comfort. There’s a guy on, on, uh, social media that was evaluating a ton of, uh, cyber security podcasts. He’s in a position of a CISO and he gave this podcast a C-minus and, uh, I thought, “Okay.” Well, I mean it was subjective because he basically said it’s just not for me and… and I understand that but I look at information like that and say what can I do better? And I realized at that moment that I personally need to be more relaxed and more connected and so I am now a little bit more relaxed than I was at that time. Anyway, we’ll leave it at that for today and, uh, we’re looking forward to connecting with you again real soon. Take care.
Andreas Taudte: Okay. Looking forward to that. Hey, thanks. Take care. Bye-bye.
Voiceover: The defender’s log requires more than a conversation. It takes action, research, and collective wisdom. If today’s episode resonated with you, we’d love to hear your insights. Join the conversation and help us shape the future together. We’ll be back with more stories, strategies, and real-world solutions that are making a difference for everyone. In the meantime, be sure to subscribe, rate, write a review, and share it with someone you think would benefit from it, too. Thanks for listening, and we’ll see you on the next episode.
1 post - 1 participant
The post TDL 011 | The Hidden Layer of Cybersecurity: Andreas Taudte on DNS & DDI Defense appeared first on Security Boulevard.
Pets, poisoned AI search results, and a phone call that sounds like it’s coming straight from the federal government, this week’s scams don’t have much in common except one thing: they’re getting harder to spot.
In today’s edition of This Week in Scams, we’re breaking down the biggest security lapses and the tactics scammers used to exploit them, and what you can do to stay ahead of the latest threats.
If you’re a Petco customer, you’ll want to know about not one but two data security lapses in the past week.
First, as reported by TechCrunch on Monday, Petco followed Texas data privacy laws by filing a data breach with the attorney general’s office. In that filing, Petco reported that the affected data included names, Social Security numbers, and driver’s license numbers. Further info including account numbers, credit and debit card numbers, and dates of birth were also mentioned in the filing.
Also according to Techcrunch, the company filed similar notices in California and Massachusetts.
To date, Petco has not made a comment about the size of the breach and the number of people affected.
Different states have different policies for reporting data breaches. In some cases, that helps us put a figure to the size of the breach, as some states require companies to disclose the total number of people caught up in the breach. That’s not the case here, so the full scope of the attack remains in question, at least for right now.
As of Thursday, we know Petco reported that 329 Texans were affected along with seven Massachusetts residents, per the respective reports filed. California’s report does not contain the number of Californians affected, yet laws in that state require businesses to report breaches that affect 500 or more people, so at least 500 people were affected there.
Below you can see the form letter Petco sent to affected Californians in accordance with California’s data privacy laws:
In it, you can see that Petco discovered that “a setting within one of our software applications … inadvertently allowed certain files to become accessible online.” Further, Petco said that it “immediately took steps to correct the issue and to remove the files from further online access,” and that it “corrected” the setting and implemented unspecified “additional security measures.”
So while no foul play appears to have been behind the breach, it’s still no less risky and concerning for Petco’s customers. We’ll cover what you can do about that in a moment after we cover yet another data issue at Petco through its Vetco clinics.
Also within the same timeframe, yet more research and reporting from Techcrunch uncovered a second security lapse that exposed personal info online. From their article:
“TechCrunch identified a vulnerability in how Vetco’s website generates copies of PDF documents for its customers.
“Vetco’s customer portal, located at petpass.com, allows customers to log in and obtain veterinary records and other documents relating to their pet’s care. But TechCrunch found that the PDF generating page on Vetco’s website was public and not protected with a password.
“As such, it was possible for anyone on the internet to access sensitive customer files directly from Vetco’s servers by modifying the web address to input a customer’s unique identification number. Vetco customer numbers are sequential, which means one could access other customers’ data simply by changing a customer number by one or two digits.”
With the size and reach of the Petco breach still unknown, and the impact of the Vetco security lapse also unknown, we advise caution for all Petco customers. At minimum, monitor transactions and keep an eye on your credit report for any suspicious activity. And it’s always a good time to update a weak password.
For those who received a notification, we advise the following:
Check your credit, consider a security freeze, and get ID theft protection. You can get all three working for you with McAfee+ Advanced or McAfee+ Ultimate.
Monitor transactions across your accounts, also available in McAfee+ Advanced and Ultimate.
Keep an eye out for phishing attacks. Use our Scam Detector to spot any follow-on attacks.
Update your passwords. Strong and unique passwords are best. Our password manager can help you create and store them securely.
And use two-factor authentication on all your accounts. Enabling two-factor authentication provides an added layer of security.
What to do if your Social Security number was breached.
If you think your Social Security number was caught up in the breach, act quickly.
You might want to be careful when searching for customer service numbers while in AI mode. Or with an AI search engine. It could connect you to a scammer.
From The Times comes reports of scammers manipulating the AI in platforms like Google and Perplexity so that their search results return scam numbers instead of a proper customer service numbers for, say, British Airways.
How do they manipulate those results? By spamming the internet with false info that gets picked up and then amplified by AI.
“[S]cammers have started seeding fake call center numbers on the web so the AI is tricked into thinking it is genuine …
“Criminals have set up YouTube channels with videos claiming to help with customer support, which are packed with airline brand names and scam numbers designed to be scraped and reused by the AI.
“Bot-generated reviews on Yelp or video descriptions on YouTube are filled with fraudulent numbers as are airline and travel web forums.”
And with these tactics, scammers could poison the results for just about any organization, business, or brand. Not just airlines. Per The Times, “The scammers have also hijacked government sites, university domains, and even fitness sites to place scam numbers, which fools the AI into thinking they are genuine.”
This reveals a current limitation with many AI platforms. Largely they can’t distinguish when people deliberately feed them bad info, as seen in the case here.
Yet even as this attack is new, our advice remains the same: any time you want to ring up a customer service line, get the number directly from the company’s official website. Not from AI search and not by clicking a paid search result that shows up first (scammers can poison them too).
Are you under investigation for money laundering? Of course not. But this scam wants you to think so—and to pay up.
On Tuesday, the Federal Trade Commission (FTC) issued a consumer alert warning that people are reporting getting unexpected calls from someone saying they’re “FTC agent” John Krebs. Apparently “Agent Krebs” is telling people that they’re under investigation for money laundering—and that a deposit to a Bitcoin ATM can resolve the matter.
Of course, it’s a scam.
For starters, the FTC doesn’t have “agents.” And the idea of clearing one’s name in an investigation with a Bitcoin payment is a sure-fire sign of a scam. Lastly, any time someone asks for payment with Bitcoin or other payment methods that are near-impossible to recover (think wire transfers and gift cards), those are big red flags.
Apart from hanging up and holding on to your money, the FTC offers the following guidance, which holds true for any scam call:
As always, here’s a quick list of a few stories that caught our eye this week:
AI tools transform Christmas shopping as people turn to chatbots
National cybercrime network operating for 14 years dismantled in Indonesia
Why is AI becoming the go-to support for our children’s mental health?
We’ll see you next Friday with a special edition to close out 2025 … This Year in Scams.
The post This Week in Scams: Petco Breach Warning, and Watch Out for Fake Federal Calls appeared first on McAfee Blog.
Login