In the wake of the U.S. defense leak, the Pentagon CIO has given a one-week deadline for all defense agencies to ensure compliance with DOD information security protocols. But what does that actually mean? Join Matt, David, and Varonis Team Lead Engineer for U.S. Public Sector Trevor Brenn for a State of Cybercrime episode that breaks down what the DOD is demanding from its agencies and how this influences the future of information security within government.
[00:00:00]
Matt Radolec: Hello everyone and welcome to another episode of State of Cybercrime. I'm joined today by our usual co-host David Gibson, who's back from vacation. I know many of you missed him in our last episode. We've also got a special guest today which is Trevor Brennan, if you want to say hello, Trevor.
Trevor joins us from Varonis's Federal Data Security Engineering team to talk specifically about the DOD's response to the data leaks.
[00:01:00] Really excited to have you back, David. And have you here today, Trevor.
Trevor Brenn: Yeah, Matt. Thanks for having me on.
David Gibson: Good to be back.
Matt Radolec: We are gonna crack right into it today.
We want to actually start today really by talking about the call from DOD to take action in response to the Pentagon Discord leaks, and we'll remind you guys a little bit about that, and then we'll go through our usual segments.
As always we want to talk about some Good News in cyber. We'll jump on into the Danger Zone and talk about some of the threat actors that you guys should be worried about. We'll round it out with some Vulnerable Vulnerabilities including one in a UDP protocol that Mr. Gibson is extremely passionate about.
And we always save time at the end for Q&A. Feel free to submit questions in the chat or in the Q&A and we'll try to cover them as quickly as we can.
In our last episode, we talked a lot about this National Guardsman that appeared to have, leaked some classified intelligence data, subsequently has been arrested for it.
Actually, that happened live on the show. We had our viewers chime in and tell us that the arrest had occurred, even after we had started the show so that was pretty cool.
And it really seems to [00:02:00] be highlighting this need for safeguarding and the handling of classified information.
And Trevor, that's why we wanted to bring you on. As we know there's been quite an overwhelming response both from the community and specifically from the DOD office of the CIO. Do you want to talk to us a little bit about that?
Trevor Brenn: Yeah, absolutely. So I think we were talking about this before as a lot's been going back and forth around this.
We really don't know what happened here as the government tends to be very hush when these situations happen until they're completely remediated. But what we can use is the actual guidance that they've released for other agencies to figure out or piece together partially what happened just by looking at what they're telling people to fix.
Matt Radolec: And what is that? We've all read this memo from the DOD. I think there were two deadlines in it. One was around, was it re-certifying access by yesterday?
Trevor Brenn: Yeah. May 2nd.
Matt Radolec: And then, I'll have you tell our audience what that means in a second, and then CIOs have until about the end of the month to do that same thing.
So what does that mean when a DOD CIO says, [00:03:00] re-certify access by yesterday?
For someone that was trying to comply with that, what would that have meant?
Trevor Brenn: Yeah, so a lot of times when we see government timelines like this, they're multi-step due to just the reality of working in a large agency like that, most of the time we see policy first and then action second.
So in this case, it's the Get your ducks in the row. We're expecting you to validate that everyone is on need to know, which is the government term that basically means least privilege, and then over the next month you're gonna be expected to not just enforce it, but make it provable, right?
A lot of these come with an audit or they come with a report, or they come with some way to actually prove out that you're hitting these requirements and what these requirements really are, are spelled out really straightforward in NIST 800-53, which is the bedrock government cybersecurity compliance document.
And it's been around for almost a decade at this point. So really what this is doing is enforcing the basic stuff that agencies should have been doing and most likely have been missed in this situation.
Matt Radolec: Now, the specific controls, Trevor, that got outlined, they had a [00:04:00] lot to do with least privilege, with audit logging and then some things around monitoring.
When we talk about, and like AC-6, I know you wanted us to talk about today, you felt that was really important, let's think about what might have happened here, right? We've got this person who's got some level, maybe too much, maybe just right, amount of access to a system and they clearly have been able to use that access to leak information.
I think these are things that we've all generally accepted at this point. But why would enforcing need to know or doing an entitlement review help with that?
Trevor Brenn: Yeah, so a lot of the data that was leaked was active wartime information, right? When we think about the Department of Defense's mission and what their most critical data is, like active strategy, locations of weapon caches, these are the things that you don't want the adversary to know.
So these are the things that we think that they're gonna have under the most lock and key and if you're not actively involved in that wartime situation, you should be protected from seeing it and that data should be protected from you regardless of whether [00:05:00] there's malicious intention or not, there was in this situation.
So when they talk about need to know, when they talk about least privileges, should an Army, National Guardsman or Air National Guardsman in the United States have visibility into this type of communication, and weapons and wartime information? And in this case, we've seen no. And we see the reason why, because it only takes one, even though there may have been 10, 15,000 people with access to this data, which would be too many in that case, the one person who slips up or the one person who has malicious intent ends up causing significant damage to the effort.
Matt Radolec: I think another debated thing, I'm actually curious to see, David, both what you think about this and our audience is, we've figured out the MOS of Jack Teixeira, I hope I'm pronouncing the name right, this National Guardsman that got arrested seems to be like a Cyber Transport Systems Engineer for the Air Force, and it's debated whether or not that meant that this came with privileged access or like administrative rights.
Either way, right? An admin needing to have these rights to carry out tasks and needing [00:06:00] to potentially go unmonitored or have unrestricted access, I think that's why we're seeing the controls getting suggested around who's got privileged accounts, do they have the right level of privilege, and are we actually monitoring when they use that access?
This just undermines the importance of trust but verify, which I think is another really common government phrase we all hear.
David Gibson: Yeah I think first of all, least privileged monitoring user access: who knew? Kind of a basic thing.
I think one of the interesting things here is it shows how an organization can do just about everything right from like the getting into the building, and blocking at the end point, and segmenting networks, even having discontinuous or disconnected islands of information, but if data still gets out then it's kind of catastrophe, right?
These kinds of attacks, like the insiders, if you don't do a good job with walling off what people can access in the first place and monitoring what they're doing, these kinds of things are really hard to combat and start and and stop.[00:07:00]
Matt Radolec: I think that's the sentiment I would echo as well. This is supposed to be like the most lockdown data, short of maybe let's say like the Coca-Cola recipe, right? Maybe there's less people because not so many people need to have access to that at one time. What I could imagine, there are lots of soldiers and leaders on the battlefield that do need access to this intelligence as you talk about, Trevor. Maybe more than they need access to the secret formula or the seven herbs and spices combination. But with the data being so locked down already and this still being at risk especially, I think this undermines the insider risk that we all face, that every organization faces, especially when you think of the motivations behind it.
It's unclear that it's clout as the only motivation or internet points is the only motivation for this particular incident, but I think time will tell on that.
And Trevor, I know you live in this space. You're always advising our clients on what to do here, people that are trying to do the right thing before the end of May, do you have any tips or recommendations for them on, how to obviously take the DOD's advice and the memo's advice, but anything you want to go above and beyond that?
Trevor Brenn: Realistically, one of the biggest problems with breaches [00:08:00] like this is the length of staying power, right?
So he was gone or compromised, or however you wanna say it, for over a month before anybody realized what was happening. The data that persisted on those discard logs, we only know half of it, right? How many private communications did he have? How many WhatsApp communications did he have? And we can see it called out in access investigations, right?
After you have a breach or when you catch a breach, you have to have a strong understanding of what happened. You have to have all of your data or all your ducks in a row so you can at least understand what the fallout was, right?
We're only seeing the publicly available breach at this point. Who knows if the adversary got access to that information and who knows how much of it we don't even know, how much of it wasn't breached.
So having a strong auditing understanding of who's touching what is gonna be really important if this ever happens because knowing what's been breached is sometimes more important than anything else, right? Knowing the fallout.
Matt Radolec: And I just wanna echo a sentiment from Richard, one of our viewers, around using some monitoring tools to potentially [00:09:00] identify behaviors outside the norm would also be helpful here.
Now not that we want to put this topic to rest, because we know a lot of you are really passionate about it, but we do have a couple other segments that we want to jump into.
But let's make sure that we talk about Good News. Every episode we always want to cover that the good guys are doing good stuff because there's always a lot of doom and gloom and cybersecurity, yet there is some good stuff happening.
And so the first thing that we obviously want to talk about here is we've got this Cryptbot malware operation.
David, so first off, welcome back so happy to have you here. Rob was a good stand in, but no substitute for the dad jokes and the puns that you bring to the show.
David Gibson: Thank you very much. Thank you very much. Good to be back.
Yeah, this is good news. I think we'll start out: what is Cryptbot?
This is an info stealer. It was first seen or popular in 2019. It was previously distributed via a phishing email. In 2022, it came back via this crack software.[00:10:00] And I guess the group that Google is now able to disrupt was tricking users into downloading malicious versions of Google Earth Pro and probably more dangerously Google Chrome. And so once these were installed, it's malware, steals everybody's information.
Google can now disrupt and take down the domains that this group is operating from. And I guess you know, since it's Chrome and it's Google Earth, it's definitely relevant for Google to disrupt that network as well.
One thing that I thought was interesting is this cracked malware was distributed by the site 360installer. That's kind of the hub, and I think that other malware sites would point people to this and it was like a pay per install thing. So each of the affiliates or whatever would get paid every time somebody installed this cracked malware.
And I just, go back through your history, your browser history, if you've ever downloaded Chrome or been redirected there. I searched through mine just to make sure I hadn't, I usually am pretty good about not going anywhere but I checked that.
Matt Radolec: This is the first time [00:11:00] that we've seen Google disrupt a malware ring using, it's almost like trademark or copyright as the grounds, right?
Like these are Google products that are being rebranded or recoded for malicious intent, or not even recoded, but just things that appear like Google products.
It was something that was called Glupteba, I think it was back in 2021. It was like a big botnet that they used that was a similar authority to do.
Shout out if we got any Googlers or Mandiant folks on the line. Shout out for being a part of the good news for our show today.
David Gibson: Yeah, it's nice to see, nice to see the good guys get a win.
Matt Radolec: Now there are a few Vulnerable Vulnerabilities that we want to talk about as well. David, I think, the first one that comes to mind for me is one that we actually authored for the first time in, what was it, August of 2021.
It's getting the rounds again cuz Krebs released an article just a couple of days ago talking about abusing guest access to Salesforce.
Now you're our resident expert on Salesforce permissions. Would you mind giving our audience just like a little bit of background on like, [00:12:00] how this is possible? And then talk about like the impact of taking advantage of abusing these misconfigured communities.
David Gibson: Yeah, sure. And this blog we updated it in light of the recent events here but we did write about it a couple years ago.
Salesforce isn't just an internal CRM solution. It's far more than that. And there's a lot of external facing use cases for Salesforce like communities, sales communities, support, help desk. People log in to a Salesforce over the internet and actually log in probably isn't the right word because you have public facing pages that are accessible via the internet and when you do that, you're using what's called a guest account in Salesforce.
Now, the guest account can have a lot of different rights, and of course people wanna lock it down. But because Salesforce is a big app with a lot of sophistication and a lot of complexity, it's easy to get a profile or a permission [00:13:00] set configured incorrectly for that guest user. And so what happens is that guest user gets more access than people think to more objects and more records than people think. And then this can be used, especially if you connect to it via API, to scrape a lot of information out of these Salesforce instances.
So this is true for
Matt Radolec: Yeah, go ahead, David, yeah.
David Gibson: I was just gonna say, it's not the only SaaS app that has configuration issues like that.
Matt Radolec: And for some of our, let's say offensive-minded security folks on the line, using something like a Burp Suite, you could send specially crafted packets, requests, particular web requests, to these community sites to do a little bit of enumeration, find out the different objects that are out there that might have access to the guest profile with a little bit of creative Google searching, like the in URL Google searching, you might be able to find one of these pages where these objects are hosted and then request them via the API because this guest user profile has [00:14:00] access to these objects, and the sensitive or private or even potentially restricted information might be finding its way into these communities and into these Salesforce objects that have the guest profile that have access to them.
So the, there's a much bigger thing to think about here, which is not just yes, this is one way that having some sort of public access gets exploited, but it also undermines, and I wanna shout out like Amazon on this, right? Amazon was dealing with this with public facing S3 buckets. I'm sure everyone on our show today has heard a story about someone who, for some reason or another, flipped a bucket to public and this begs the question for me, is it up to the manufacturers to try to stop this?
To give the example for Amazon, buckets used to have a potential to be set default public and had to be flipped to private. Then the default was private. Now, not only is the default private, but to set it to public, you actually have to click yes twice. You have to click yes to the config, and then when you hit save, it's like, are you sure you want to do this? And then you have to hit save again.
Obviously if you create the bucket via like API or a [00:15:00] Terraform script, it's not gonna happen that way.
But if you're doing it via the Amazon console, there are a lot of barriers to you setting and configuring a bucket this way. How much of the onus is on us the users, the community that leverages Salesforce versus Salesforce themselves to help eliminate these loopholes?
David Gibson: This is one of the things about the shared responsibility model. I think people are responsible for configuring the applications and sometimes there's a little bit more responsibility than people realize. And there's some complexity there too.
I think that the S3 example that you gave is great, right? And making it easier for people to configure things in the right way. But still, it's not exactly for the faint of heart, right? There are several options, right?
If you go into the S3 configuration, it's like do you want only new stuff to be public? Or like old stuff? It's all stuff. It's like there are a couple different configuration options and I think the sophistication and the amount of knowledge that people really need to have, let's just say, it may be harder in the cloud, but I don't think it's really getting easier.
We've [00:16:00] invested a lot of time in the on-prem infrastructure, configuring hosts, configuring network security, learning about this, and there's just as much in the shared responsibility model, just because you may not have to patch an OS, you may not have to worry so much about the network segmentation on a SaaS.
You still gotta worry about making sure that things are configured correctly and really that the data's locked down and there are a lot of knobs and options that you have to know these days.
Matt Radolec: And I wanna ask our audience question as well.
Two part question, everybody. One, do you have Salesforce? Two, have you actually verified, not just trust that your admins are doing the right thing, but verified that you don't have exposure via this guest profiling in your communities?
The reason I bring that up is we see customers maybe aren't monitoring their Salesforce with a Varonis yet. They'll call on us cuz they have an incident. Someone tells 'em, Hey, I got some data. I don't know how it got on the web. They think it might have originated from Salesforce. And what we're often finding is that security teams aren't quite as involved in the configuration of a Salesforce because it's usually someone else [00:17:00] that bought Salesforce and had hired the people to administer Salesforce.
And so it's a little bit of a black box to security teams. Or maybe they only do manual review or they're just asking their admins. I'm really curious to see if any of our audience members have actually themselves checked to see if their Salesforce has had exposures or if you're relying on either a third party or your administrators to do that.
David Gibson: Yeah, and there's some big bucket items that are hard to see. One of the other things that we see is the UAT environments, the sandbox environments that happen to have complete copies. Maybe it's like a month old, but then the access controls aren't minded in the same way there, in the configurations in the same way.
Matt Radolec: I think there was another zero day, David, that you were really eager to share with everybody. This one has to deal with some, what was it called? The Cisco Prime Collaboration Deployment Server, if I remember.
David Gibson: Yeah , or a PCD if you're cool.
But yeah, there's a zero day. This is a component that's part of their unified communications management suite. And essentially it's a [00:18:00] component that runs on these PCD servers. And these are typically internal servers, but there's a web UI to administrate them. And guess what? It doesn't validate input.
So look for a patch next month, but in the meantime you've gotta contain these servers. And I would probably segment off that web interface to just trust the codes to jump box or some sort of thing. I don't know what you'd recommend there, Matt.
Matt Radolec: Yeah, and I was gonna say, or if you've got the ability to monitor the request that web server is receiving, even if you're just streaming a log somewhere.
Cause what you wanna look for are someone that might be attempting to execute arbitrary code for the lack of this input validation, or even do some reconnaissance. So just gather information back in the replies that might reveal sensitive information. And you gotta think this Cisco device is on the internal network already so this is a great place to potentially even mask your reconnaissance or lateral movement or privilege escalation activities or even actions on objectives.
David Gibson: Yeah, it's a component that I think is probably likely to be not messed with a lot or [00:19:00] not thought of a lot by admins because it runs the comms and it's set it and forget it, but this is a great place to hide. Speaking of which-
Matt Radolec: Yeah, talking about hiding, right? 3CX is getting another round. I actually want call this a supply-chain-attack-ception for those of you that have ever seen the movie Inception. And you know, it's got many layers, right?
The interesting nuance here is there was this trading technologies was first targeted by th is North Korean attacker group. I want to say that Mandiant and is deeming them, let me make sure I'm reading the name of it, it's a UNC4736. And they targeted a company called Trading Technologies, where they were able to identify supply chain vulnerability.
They used that supply chain vulnerability to attack 3CX to subsequently establish another supply chain of vulnerability to attack their clients. So you've got this supply-chain-attack-ception where one attacker group has a very clear motive that they want to have these very difficult to detect, most likely zero day vulnerabilities, that then they leverage to go find more [00:20:00] zero day vulnerabilities.
And so I think the first thing you have to take into account here is you've got a very dedicated attacker that's not just going to spend the time to like get in your network and unleash ransomware. Thereafter, you know what might be your crown jewels, your code, or you know your manufacturing process, to find a way to insert themselves in it, to infect your clients. And then if you've got clients that also make things, their clients.
And that's really the nuance or the special thing that happened here.
Now, in terms of who they targeted, we're seeing both financial services, we're also seeing these information technology providers.
Because these FinTech companies, they make a product, right? Trading technologies, they make a trading technology. 3CX, they make a phone and telephony collaboration system.
And we're also seeing some of the command and control framework that was used by the Lazarus group, which might indicate a connection between UNC4736 and the Lazarus group or maybe they're the same people.
I think Mandiant's probably out far ahead in terms of attribution here, and so we'll look to them to see some updates, but what's the practical advice here? I actually [00:21:00] wanna go back to something that Trevor talked about and some of our audience members did as well.
We hear all these initiatives around zero trust, around assume that there's compromise everywhere and how would you lock things down. I also think this undermines the importance of something, David, that you and I talk about a lot, which is protect the thing that you care about the most.
So that no matter what the vectors change, right? These are two vectors to your data. This 3CX supply chain attack, this trading technology supply chain attack. If the thing that you're trying to protect is well hardened and well monitored, it doesn't really matter what vector the attacker used to get in.
You'll know when they go after that thing. And I think if there's one takeaway every show we have vulnerabilities to talk about .Every show we have zero days to discuss that give attackers another vector but the target remains the same.
David Gibson: And making sure that the right people have the right access as well as the right applications, right? Getting to that least privileged model and then monitoring what people are doing there.
It goes back to that same guidance.
Matt Radolec: And for those of you that don't know, I [00:22:00] imagine it was a number of years ago, David, you actually had a really popular article in USA Today or something about another UDP protocol vulnerability. You know, certainly pretty passionate about that.
This SLP amplification attack, what's that? What's the implication? What's like the risk factor for our viewers?
David Gibson: Yeah, this is really interesting and I enjoy learning about these denial-of-service attacks. I've kind of seen them over the years evolve.
This one is in a protocol called the Service Location Protocol. It's a protocol I think came out in 1997. It was designed for the use on the land, so you could advertise printers and other services. And it's UDP and TCP port 427 but the UDP part is the operative part because that's easy to spoof.
And that's because it doesn't have the three-way handshake in TCP so the TCP is much harder to spoof. So that basically means you can masquerade as sending a packet from somewhere and you'll get a response back, even if that is to somebody [00:23:00] else, right?
And so that's the crux of it. But this SLP module, in addition to being able to respond to the victim, right? So the attacker hits the SLP server, and if they used a spoofed address, then that would go back to the victim. But the S LP service itself has a vulnerability where the attacker can register multiple services on the host, and therefore take with one packet, get a whole bunch of responses, and that amplifies this.
Matt Radolec: And those responses can be bigger so now you're starting to get to the point of this denial-of-service from just clogging up a bunch of pipes or connections between different hosts, right?
David Gibson: Exactly. And then you multiply that by multiple hosts, and now you could essentially have a wall of UDP traffic of these SLP responses that can overwhelm your pipe.
So this reminds me of the Fraggle attacks that happened with UDP ,before that the Smurf attacks. I love these characters, but I remember that one. It [00:24:00] resulted in t-shirts that I think I had that said "No IP Directed Broadcast". That initial Smurf attack was a ping right to a broadcast address that then amplified everybody on that network would send the ICMP ping response to the victim.
And anyway, it goes way back. So these protocols can be dangerous.
Matt Radolec: In terms of proliferation, I think the scans that we saw, there were somewhere around 60,000 hosts on the internet that were advertising SLP outbound. Did we get that number right from, is that from BitSight?
David Gibson: I think 54,000 is what they said from BitSight.
And then so 54,000 hosts and each of them doing a 2200 times multiple of the initial packet. That's scary. It's a big, it's a big amount of traffic.
Matt Radolec: Certainly a decent amount of exposure and primarily used in network devices like printers and also ESXi.
David Gibson: That's right. So there's some stuff VMware talked about this and warned about this as well.
Matt Radolec: And that's not even the most dangerous thing we wanna talk about. Let's [00:25:00] jump into the Danger Zone and talk a little bit about some nation state activity.
The first thing that I want to mention around this Alloy Taurus, also associated with something that's called PingPull, this is a Chinese nation state actor. They've got a new variant. They've got a Linux malware variant that they're using for targeted cyber attacks. But the most interesting nuance about this for me, I wanted to share with people is I don't think I asked the question like, Around attribution, like how do we actually know who this attacker is?
And I'm always answering with we'll start with sophistication and who uses these techniques in other places? The first layer of sophistication to PingPull is they've got TCP, ICMP, as well as HTTPS backdoor, and C2 communication channels.
So they have this resilient infrastructure that no matter what their initial, maybe it's PingPull, maybe it's Sword which is just another malware variant they're using to get that initial foothold, they've got options if you're blocking, let's say HTTPS traffic or ICMP traffic from getting out of your environment or TCP traffic over the port that they're trying to [00:26:00] use.
Or maybe you've even got some DNS layer. So Unit 42 from Palo Alto was the first to break the story about this. Obviously all the the Palo stack started to get some of those blocking mechanisms. Maybe you don't have the one that blocks the ICMP traffic or the HTTPS traffic, or the threat intelligence that you have doesn't get all those signals.
That's the level of resilience that a sophisticated threat actor brings to the table when they release a new variant of malware.
A lot of things in government, financial services, mostly in the other side of the world from where we're sitting today, countries like Australia, Malaysia, Vietnam, the Philippines, Cambodia, Russia, and I think in addition to all the things that we would wanna mention to you guys about this RAT, this remote access intrusion, is this PingPull variant, that is the new thing to the table or the updated attacker techniques.
And this group has also been associated with the name Gallium. Many organizations worried about espionage from Chinese state actors going after intellectual property and defense [00:27:00] information. And if you're in that part of the world, definitely, probably wanna make sure that your defenses are well aware of Alloy Taurus or Gallium as it has been before and some of the things that you can do to identify whether it's PingPull or Sword getting dropped on your network.
David Gibson: Yeah, definitely upping the sophistication there.
Matt Radolec: Upping the cuteness and the sophistication at the same time, what is this Charming Kitten, BellaCiao? What's the story here on that, David?
David Gibson: Apparently this APT group did some market research and RAT was not as popular as cat so they're Charming Kitten. Just had to get the dad joke in there.
So anyway, this is an Iranian sponsored APT group also known as something less cute, Phosphorus and APT35. But this is an ATP group and they have malware called BellaCiao. Can you translate that for us, Matt?
Matt Radolec: Yeah, that's beautiful hello in Italian.
David Gibson: Yeah.
Matt Radolec: And specifically this would be of a beautiful woman because we had bella. I have parlo Italiano [00:28:00] for any Italian audience members that we have.
David Gibson: That's some good game right there with that translation. Thank you.
But anyway, this is new malware, BitDefender per Dark Reading ,it was discovered by Bit Defender.
It's pretty sophisticated. They custom build the malware for each victim, but what I thought was pretty interesting was the command and control mechanism. The way that it would do the command and control would be through DNS. And that's not new in itself, but the way they did it through DNS is every 24 hours they would resolve a name and the instructions were, encoded may not be the right word, but signaled through the resulting IP address in that DNS query.
So each octet would have, based on what whatever the number was, would signal different instructions for the malware to do.
And so it's hiding in plain sight. I think we're seeing the sophistication of this just continue to elevate. It's not really clear so far what the malware's gonna be used for in each of these cases, [00:29:00] but it seems like Charming Kitten is trying to charm its way into a lot of different organizations and, to be determined later what they're gonna use it for.
Matt Radolec: What a fluffy way to articulate that. I think that when we talk about this, we've talked about DNS tunneling and DNS commanding control before, where attackers will use the host name to do the command and control part. So it'll be malicious domain dot command dot command dot com but what you're saying the change here is that they're actually translating it to the actual IP address itself in the reply that is then subsequently issuing command. So a flip flop of the DNS command and control that we've seen in the past.
And initial asset specs for Charming Kitten seem to be all over the place. We saw things like the Microsoft Exchange zero days, the Manage Engine zero days. So really any means that they need in order to get in.
David Gibson: Yeah this seems to be like whatever the vulnerability is, however we can get in, get the dropper in, and then we'll go from there.
Matt Radolec: Anything interesting coming in the chat that we want to cover?
David Gibson: I did want to echo one comment though [00:30:00] from Diane, if that's okay with you, David.
Matt Radolec: It's talking about this kind of gap in security knowledge where not everyone is a Salesforce architect and understands if they click one thing here, what the downstream impact is gonna be over here. And just talking about the need for documentation and steps and controls and who can set those configurations so you've got the right people with the right level of knowledge setting the config, and then the right people with the right training and knowledge confirming the config.
I want to say something about that though. When you start to think about that problem at scale in the cloud, you start to get overwhelmed really quickly. Not everyone has the cyber force the size of DOD or our largest banks with hundreds or even potentially thousands of people in cyber.
A lot of people are just skating by with a couple of people. And so when you think about that, you start to see the need for automation or start to see the need to partner with third parties to be able to do all of that cloud or security posture monitoring that you might want to.
David Gibson: I think this reminds me of a conversation that I've [00:31:00]had with a few folks is just choosing what you want to invest time learning, a lot of the configurations change quite a bit and you know, it's gosh, do I really wanna invest the time and memorizing or really learning a whole suite of configurations that's gonna be different next month.
I remember back in the mid nineties it was like, do I learn net buoys or IPX/SPX or IP, and thankfully I chose wisely on that one.
But you wanna make sure you target your effort that's gonna pay off.
Matt Radolec: Yeah. And potentially use like a risk-based approach, right? Spend your time on the things where the most risk exists.
And the last question came in from Diane. Thank you, by the way, Diane. Listening to how DNS is being utilized in a similar way to how covert channels and hardware were utilized and multi-level security systems, are those old methodologies relevant or becoming more relevant today?
David Gibson: It's really interesting. I feel like the fundamentals you can't escape 'em, and these things that we talked about today with some of the you know SLP and the DNS, without a fundamental understanding [00:32:00] on how some of these bedrock things work it's hard to follow along. With some of the newer attacks, certainly. I'm not sure if I'm answering the questions, but I feel like they're more relevant. I mean, We haven't fully transitioned to IPv6 yet. And we've been talking about that for over 20 years.
Matt Radolec: I would say that if anything same methods, more creative ways to implement and people are finding more ways to use this age old protocol that I don't think is going anywhere, which is DNS.
Trevor, I got one for you that came in from Andrew. I read that the DOD leaker was able to browse a database. Can you talk to how you can make least privilege and audit people for sponsoring that database? Like it seems like a big miss that someone was able to have access to a database.
Now let's leave whether or not that happened or not for the OIG report. Let's just speak to it generally, right? What could be done to make least privilege and make something like that auditable.
Trevor Brenn: Yeah, so a lot of it is just gonna be around collecting the right data and collecting it from all the data sources. But on the other hand, when it comes to privileged [00:33:00]accounts, they have to have extra scrutiny applied to them, right?
We've seen a lot of tools that password vault administrative accounts have a checkout system. So that if you do have accounts that have this elevated privilege, and they are designed for an explicit purpose, right? And this goes for service accounts as well. When they're in use, we know when they're in use and when they're not in use, they're not just floating in the ether for somebody to grab or to use.
Whether or not this person's activity was, or their access was legitimate or illegitimate, the fact that they could come and go as they pleased with no oversight or no behavioral analytics to say this user's ticking up or in risk or ticking down in risk really prevents presents a huge oversight.
Matt Radolec: We'll take this one last question here from Ryan. I'm gonna point this one to you David.
We've got Salesforce but security wasn't as involved in planning or rollout. We feel pretty blind to the Salesforce environment. What are our first steps? What should we do to learn more and investigate, and what guard rails should we should provide?
Now, before you answer, I'm gonna do a shameless plug here. If you really don't know where to start other than David's advice, because he's a [00:34:00] Salesforce guru, we do offer free risk assessments. It's gonna be a start, right? You're gonna get an idea of what some of the misconfigurations that might exist or some of the exposure that you might have in Salesforce, and there is no obligation to move forward from that.
So if you want us to take a look at your Salesforce, you can either follow up or you can have one of our moderators follow up with you. But David, any other practical advice there?
David Gibson: Yeah, there are a couple of native tools in Salesforce, but the first place I check is what's called your orgwide sharing defaults.
What we're seeing there is a lot of the record types are overly accessible by default and end users don't realize who's got access to which resources or which records in Salesforce and they'll upload sensitive attachments or they'll put sensitive data in the notes, not realizing they're exposing it to everybody in the company.
And the other thing is what I mentioned at the outset is check, okay, how many Salesforce environments do we actually have? And how many of them have external developer access? Because we need somebody's help to do what we're doing. And how many have complete copies of Salesforce?[00:35:00] And as Matt said, there's tons of configuration settings, there's tons to check with the permissions, and, if you wanna get a little help with that, it's an easy process for us to do that.
Matt Radolec: Yeah. I think with that first of all, Trevor, thanks so much for joining us today. It was great to have an expert on the public sector, especially on the Department of Defense and especially, and again how hot and relevant that topic is. Welcome back David, and thank you to our audience, this show is made possible because of you.
We really appreciate your viewership and your feedback and your engagement, and we look forward to seeing you in our next episode.
David Gibson: Thanks so much everybody.
Trevor Brenn: Thanks for having me, Matt.
David Gibson: Thanks, Matt. Thanks Trevor.