The CyberWire Daily Podcast 6.23.23
Ep 1850 | 6.23.23

Two sets of China-linked cyberespionage activities. Mirai’s new vectors. A Cozy Bear sighting. Anonymous Sudan gets less anonymous.

Transcript

Dave Bittner: An update on Barracuda ESG exploitation. Camaro Dragon's current cyberespionage tools spread through infected USB drives. The Mirai botnet is spreading through new vectors. Midnight Blizzard is out and about. Ukraine is experiencing a "wave" of cyberattacks during its counteroffensive. Karen Worstell from VMware shares her experience with technical debt. Rick Howard speaks with CJ Moses, CISO of Amazon Web Services. And Anonymous Sudan turns out to be no more anonymous or Sudanese than your dear Uncle Louie.

Dave Bittner: I'm Dave Bittner with your CyberWire intel briefing for Friday, June 23, 2023.

Update on Barracuda ESG exploitation.

Dave Bittner: Proofpoint has tweeted updates on what the firm's researchers are seeing in the wild concerning exploitation of CVE-2023-2868, the vulnerability recently found in Barracuda's Email Security Gateway. As you might expect, it's an espionage caper. The threat group seen working against this particular vulnerability is UNC4841. Proofpoint calls them an "aggressive and highly skilled actor conducting targeted activity." The group is generally and credibly believed to be acting on behalf of the Chinese government. Its targets, geographically, have been the United States, Norway, Taiwan, and Poland. By sector, UNC4841 has been most interested in academic institutions, defense establishments, and the US Federal Government. Michael Raggi, staff threat research engineer at Proofpoint, emailed a high-level summary of the activity the researchers found, stating, "Proofpoint has observed intermittent exploitation attempts by Chinese state-aligned threat actor UNC4841 targeting CVE-2023-2868 from October 2022 through May 29, 2023. This vulnerability was being actively used in the wild by an APT actor as recently as three weeks ago. While the phishing campaigns involved conventional espionage operations, the threat actor also exhibited a sustained focus on scientific research, energy entities, and public health data, which demonstrates a more complex tasking than initially disclosed publicly. This zero-day vulnerability continues an increasing trend of vulnerable email gateway appliances being exploited via advanced exploits contained within phishing emails." Barracuda has issued both mitigations and patches.

Camaro Dragon’s current cyberespionage tools spread through infected USB drives. 

Dave Bittner: Another cluster of espionage activity attributable to China is the subject of research by Check Point. The firm's researchers have released a report focusing on a USB-propagated malware campaign that it attributes to the Chinese-based espionage group Camaro Dragon. The Check Point Research Incident Response Team discovered the malware while investigating an incident in a European hospital earlier this year. They wrote, "The investigation showed that the malicious activity observed was likely not targeted but was simply collateral damage from Camaro Dragon's self-propagating malware infections spreading via USB drives." Patient Zero, as Check Point calls the first victim, initially received the infection while attending a conference in China and connecting a USB drive to a colleague's already infected computer. The malware hides all of the victim's files on the drive and shows a program that appears to merely display the files, but which launches a backdoor in the background. The tools involved in the infection, WispRider and HopperTick, seem to align with other tools used by Camaro Dragon, including TinyNote (a Go-based backdoor) and HorseShell (a malicious router firmware). Check Point explains, "The ability to propagate autonomously and uncontrollably across multiple devices enhances this threat's reach and potential impact. This approach not only enables the infiltration of potentially isolated systems but also grants and maintains access to a vast array of entities, even those that are not primarily targeted." The researchers have since noticed several newer variations of these backdoors, all seeming to originate in Southeast Asia. Check Point reports that Camaro Dragon uses its own FTP servers and third-party services like Google Drive to exfiltrate data. Propagation by touch, in this case touch by a USB drive, makes the virus metaphor an unusually apt one. Cover your cough, and watch where you stick those dongles.

Mirai update: new infection vectors.

Dave Bittner: A version of the Mirai botnet is exploiting vulnerabilities affecting D-Link, Arris, Zyxel, TP-Link, Tenda, Netgear, and MediaTek devices, BleepingComputer reports. According to Palo Alto Networks' Unit 42, "The threat actors have the ability to gain complete control over the compromised devices, integrating those devices into the botnet. These devices are then used to execute additional attacks, including DDoS attacks." Akamai has observed Mirai botnet samples exploiting CVE-2023-26801, a command injection vulnerability affecting certain versions of LB-LINK wireless routers. The researchers state, "This can lead to various security risks, including unauthorized access, device compromise, and further exploitation within the network."

Microsoft Threat Intel report: Midnight Blizzard, a Russian SVR threat actor.

Dave Bittner: Microsoft has released a new intelligence profile on a Russian Foreign Intelligence Service threat actor it now calls Midnight Blizzard (formerly NOBELIUM). This threat actor targets government agencies, non-governmental organizations, and diplomatic personnel in an intelligence gathering operation. Microsoft writes, "They utilize diverse initial access methods ranging form stolen credentials to supply chain attacks, exploitation of on-premise environments to laterally move to the cloud, exploitation of service providers' trust chain to gain downstream customers, as well as ADFS malware known as FOGGYWEB and MAGICWEB. Midnight Blizzard is tracked by partner security companies as APT29, UNC2452, and Cozy Bear." Midnight Blizzard uses a "cyber fire-and-maneuver" technique, moving between low-reputation IP addresses that are used for only a short period of time. This helps them obfuscate their operations. In response to this threat actor, Microsoft announced that it has added protections to Defender Antivirus, Defender for Endpoint, Defender for Cloud Apps, and Azure Active Directory. In full disclosure, we note that Microsoft is a CyberWire partner.

Ukraine is experiencing a "wave" of cyberattacks during its counteroffensive.

Dave Bittner: The Russian intelligence agents and their privateers, auxiliaries, and front groups have of course been active in the war against Ukraine. US Deputy National Security Advisor Anne Neuberger told the FT Cyber Resilience Summit yesterday, "We know Ukraine is currently experiencing a significant surge in cyberattacks in parallel to the kinetic aspects." The Record reports that she specified neither the scope of the attacks nor the sectors that were receiving hostile attention.

"Anonymous Sudan" is neither.

Dave Bittner: And finally, some of the Russian hacktivist auxiliaries are more deniable than others. There's a growing consensus that Anonymous Sudan, which represents itself as a hacktivist organization with Islamist sympathies operating in Sudan, is neither an Anonymous affiliate nor Sudanese. Cybernews summarizes the evidence that points to the group's status as a KillNet affiliate, which means in turn that it's working for the Russian intelligence services. Much of the evidence leading to the conclusion that Anonymous Sudan is a Russian front group comes from research by Australian security firm CyberCX, and Anonymous Sudan wasn't happy about being outed. The group yesterday said it had conducted a DDoS attack against CyberCX's website, explaining, "The reason for the attack: stop spreading rumors about us, and you must tell the truth and stop the investigations that we call the investigations of a dog." The "dog" insult is a nice but too obvious gesture toward the culture of the Sahel region of Africa, where dogs are proverbial dirty, low, snappish, and thieving, but, really, few will be deceived. There were not signs of disruption on CyberCX's website this morning, by the way. Straight up, Anonymous Sudan is Russian. And CyberCX, you can tell Anonymous Sudan that you're happy to be top dog.

Dave Bittner: Coming up after the break, Karen Worstell from VMware shares her experience with technical debt. Rick Howard speaks with CJ Moses, CISO of Amazon Web Services. Stick around.

Dave Bittner: Karen Worstell is senior cybersecurity strategist at VMware. And she previously held CISO positions at both Microsoft and AT&T, where she led her teams through the challenging and sometimes daunting task of digital transformation. I spoke with Karen Worstell about the notion of technical debt. She shares her insights.

Karen Worstell: So McKinsey and Company has come out recently with some articles around this topic, which I highly recommend. And they basically say that it's the tax on any development project or digital transformation that a company wants to undertake but must first address on previously unaddressed issues in the infrastructure or whatever the development platform, whatever those might be. So things that were left undone before, that now will be a barrier to getting something new completed. And that's how they kind of define it in a broad way. So it could be anything relating to process and procedure, to be honest, to application debt, for things that are like ship it now and we'll fix it later, infrastructure, inventory. So there's a ton of different places where this, you know, can show up. But that's kind of how, in a very general, high-level term, that's how McKinsey defines it. And they say that it accounts for 40% of the balance sheet in IT.

Dave Bittner: Can we dig into that a little bit? How does it have such a large hit there on the balance sheet?

Karen Worstell: Well, it depends on each organization. Obviously, that's not going to be true for every company. But in my experience, when I've led major transformation projects, there was a saying that we had, which is, "is it done or is it done done?" So there's a lot of things that get put in place. One of my favorite examples that people don't think about a lot but we all feel every month is patches. So whether it's a patch Tuesday patch, a security upgrade patch, or some other sort of upgrade, or whether it is our system is down and we are working with the vendor on tier three support and they sent us a patch and we have to put that in the system in order to bring it back up again. And the question we would ask, my boss would ask, is: What does the patch do? Well, we don't know; the vendor gave it to us. And so, like what's it going to affect? Well, we're not really sure. We just need to get the system back up again. That's an example of the kind of thinking and the kind of very pervasive practices that lead to an accumulation of technical debt. Another thing that is a great example is -- I was at the Sedona Conference recently, and they were reviewing a draft of some guidelines on incident response. And so as I was reading the draft, one of the things that came out was, the very first thing that every organization must do in order to have a solid incidence response plan is to have a data inventory. And I almost snorted my coffee, my morning coffee, out my nose. Because I'm like, yeah, that's a really good idea. Who does that? Nobody. Nobody has a data inventory. We're lucky if people know where all of their IT technical assets are. And that is a form of technical debt. And we've watched it grow over the years, as we've chased the next new thing. So I think of it in terms of security. As we've chased the next new thing, right, in terms of capability, functionality, business, things that keep our business competitive. We leave behind those things that are sort of the done done. And in many cases, that has to do with security. And we figure that we'll come back to it later and we never do. And that gap has grown over time.

Dave Bittner: Just this week, I saw someone say that ransomware operators are technical debt collectors.

Karen Worstell: Oh, excellent, yeah. I might use that. It's true. I mean, the reason that we -- you know, 80% of ransomware -- I saw a thing, you know, in the industry regs recently. 80% of ransomware is due to misconfigurations. Misconfigurations are technical debt. So then your question was, what should we do about it? And my answer has evolved into, you have to tie it to a business imperative that people care about. So in McKinsey's article, their example is, every new digital transformation project has to have a technical debt tax. That tax shows up as 20% has to be allocated to the retirement of the technical debt associated with this project. It's an outcome that is a required outcome that's managed through the governance process with some teeth behind it. So that we recognize the fact that it's not like IT's problem to go out there and try to scrape together money to go out and fix technical debt. It's the business's appetite for new capability that has to be recognized, that we got here in an honest way, but now we have to do something about it. It's sort of like finally going and cleaning your room. Like, you know? It's like you finally -- you can't just kind of like keep ignoring it or keep ignoring parts of it forever. You have to eventually go in there and fix it.

Dave Bittner: Right.

Karen Worstell: So putting that tax on the project is one way of doing it. But it also has to have that top-level oversight and governance that says, yes, we're going to track this; yes, we're going to make you do it. And there's no sliding past it and trying to like get a get-out-of-jail card. You know, everybody has to understand that this is the reason why we have to do it. Now, with the companies that do -- and we saw this in our own effort -- not at VMware, at another company. The upside of it is that the payback is in the millions and millions and millions of dollars. And so you can go put that tax and clean up the technical debt, and thinking that it's like a non-value-added activity. But the truth of it is is that it pays itself back in it's faster time to market with new capability, less time spent doing break-fix, deploying the defect-free code. I've been saying this for years, but, you know, McKinsey's article finally validates this.

Dave Bittner: What about the pressure to ship? You know, our competitors, they're not worrying about that silly technical debt. They're going to beat us to market, then it won't matter that our technical debt is taken care of because we'll be out of business.

Karen Worstell: Yeah. That's the AI conversation right now.

Dave Bittner: Right.

Karen Worstell: We can't dare slow down. If we slow down, somebody else will do it. Some of that's probably fear. Some of it's probably reality. Where I think this is going to start to shift is in the whole concept of duty of care. First of all, the obligation to be clear about, this is the state of being of us, right. We need to know where we are. Like Ray Dalio is really clear about, you know, you can't -- there's all kinds of great sayings out there. Ray Dalio has one. Jesse Itzler, he just basically says, "be where your feet are," right. That's about being present, but it's also about like I say, you know, make a stand, but you better know where your feet are. We need to be brutally honest with ourselves so that we can be transparent and have integrity. Integrity is everything, with others. If I am making representations to my executive management that everything is fine when it's not, that's on me. And the problem with that is that chain continues all the way to the board of directors. So nobody really knows where we are. And that means that we're not operating with our fiduciary obligations and accountability to the company or to our stakeholders. There's always going to be that drive that comes from that place that says, I have to win this; and the only way to win this is to cut corners. But I think more and more, we're seeing that that's not really the path to winning. And I believe with all my heart that it's not the path to winning, ultimately. You might win in the short run, but you won't win in the long run.

Dave Bittner: That's Karen Worstell from VMware.

Dave Bittner: There's a lot more to this conversation. If you want to hear more, head on over to the CyberWire Pro and sign up for Interview Selects, where you'll get access to this and many more extended interviews.

Dave Bittner: Continuing with our series of interviews, my CyberWire colleague Rick Howard gathered at the recent AWS re:Inforce conference today, Rick speaks with CJ Moses, chief information security officer of Amazon Web Services, sharing his take on resilience.

Rick Howard: The CyberWire is an Amazon Web Services media partner. And in June 2023, Jen Eiben, the CyberWire's senior producer, and I traveled to the magic world of Disneyland in Anaheim, California to attend their AWS re:Inforce conference and talk with senior leaders about the latest developments in securing the Amazon cloud. I got to sit down with CJ Moses, the chief information security officer at AWS, and we were discussing resilience as a cybersecurity first principle strategy. But he added a nuance to the definition of resilience that I hadn't considered before. He makes a distinction between availability and durability.

CJ Moses: You can look at resilience from different dimensions. You know, obviously, your traditional availability type of thing, but then you also have a durability. And, quite honestly, if you're prioritizing, you want to prioritize durability. Because if I'm down for two minutes, but yet I still have your data available when it comes back on, you're accepting that sometimes things happen. And there's a whole process we go through to make sure it doesn't happen again. But the inverse is not the case. If we lose your data or somehow there is an issue from a durability perspective, then that's not a good day for either of us and you're really not happy with us. So a lot of -- you know, there's prioritization placed on durability over resilience or over availability. But at the same time, both are exceptionally high bars. And we have planning for each of the different -- and you have to do from a resiliency and, you know, from that perspective, we have planning that we have to do with each of the teams, the different services, because the models for each are different. At S3, being a highly durable model and a highly available model, needs to be available and it needs to be durable.

Rick Howard: I'm not sure I get the difference between durability and availability. Tell me again.

CJ Moses: Very specifically, availability is if you have a piece of data stored in S3 -- our sample storage service -- and you request access to it, and it's available, you then get it. If there's an availability issue, you don't get it. Durability is if you ask for that piece of data and I come back with a vault saying, I don't have it, it's no longer durable. I no longer have the data, and therefore, we have a problem.

Rick Howard: They can't get it.

CJ Moses: Yes. And the durability model -- you know, S3 was created on a durability model of, you know, of nine nines. It's like lots of nines So it's essentially, we'll lose one piece of the date every gazillion years or something of that nature. Not good at math, so don't quote me on that.

Rick Howard: Wait, let me write that down.

CJ Moses: Yeah, right. It's all in the documentation, feel free to read the website. I used to actually know all that stuff, but my brain's been filled with other things these days. So there is a huge difference between availability and durability. At the same time, customers really demand and should be given both. And that's when you tie those things together, resilience is a big part of that. Another big part of resilience, we look at, you know, the benefit of the cloud is that we are highly resilient, that we can stay up and face all kinds of threats. Can we always do so? No. At large-scale, things will fail. And we have to plan. And we've seen those things happen, you know, recent days included.

Rick Howard: Yep.

CJ Moses: And although things happen, one of the things you have to do is make sure -- I know we're far away from strategy. So we'll get back to that.

Rick Howard: No, no, resilience is a strategy, so I'm fine with that, okay.

CJ Moses: So one of the things that you have to make sure is that that you learn a lot more in failure than you ever will in success. And every time we have any kind of issue, we are very diligent in reviewing that to ensure that we've done the right things and are continuing to do the right things. You've likely heard of this before, "correction of error" (COE). And, you know, essentially root-cause analysis. With on top of that root-cause analysis, what are the action items that you are definitively taking with named actors and due dates for doing those things? And we track them to make sure that they are done. Such that -- again, don't want to, you know, hammer your toe or your thumb, whatever, a second time.

Rick Howard: So putting my customer hat on, right, watching how Amazon handles a major outage, I would like to have the same capability on my little startup, right.

CJ Moses: Yeah.

Rick Howard: When I do something stupid and it breaks, I would like to have a pushbutton. It just starts over there now, right, and I continue delivering my service, right?

CJ Moses: Well, the capability exist for you to be able to do so.

Rick Howard: Yeah, it's just a little bit hard right now. > >CJ Moses: So I totally get where you're going. And that's the thing is that we're not there yet for all the things.

Rick Howard: Yeah, I get it.

CJ Moses: But 15 1/2 years ago, when I started, you have to take into account -- you know, I'll give you some history, some back-in-the-day-type of stuff.

Rick Howard: Oh yeah.

CJ Moses: We're getting older by the second. When I started, AWS was five services, one region. The security model was a user ID and password that you used to buy books with, same one.

Rick Howard: Is that right?

CJ Moses: No multi-accounts, no nothing. Your whole account, you're running your business -- although it might have been out of Starbucks off your laptop, that's what it was. So we've come a long way. We still have a ways to go. And some of the things that essentially in the military we used to call the "football." Press the button, we had a whole new disaster recovery environment. This is something that has been created, we do have. Lots of companies use very similar things. You know, infrastructure as a code is a wonderful thing. But the days of -- you know, back in the day when I was at the FBI or actually when I was at OSI, we didn't call them advanced persistent threats, because that didn't even exist yet, but that's what we were dealing with. And if you had one of those get into a network that you're somehow responsible for, you had a hard time getting them out. In some cases, you had to shut everything down and start from scratch elsewhere. In the physical world, that's a nightmare. That's expensive. You're down for a long time. In the cloud, just like you just said, you're a startup.

Rick Howard: Just flip a switch.

CJ Moses: Press a button, boom, you've got another one, and it's maybe in another region elsewhere, or maybe that's the reason you're doing it is because of survivability or, as we were talking about earlier, you know, resilience. But that model is very doable. And understanding that we don't have the service that says, okay, you've established your whole environment -- well, we do have the tools to do it. But a service to do it on your behalf, to cookie-cutter copy.

Rick Howard: Yeah. We looked at the tools. Yeah, just make it a little bit easier, that's all I'm asking. So we're at the end of this, CJ. What's the Twitter line for the conference, right? What's the takeaway that we should have here?

CJ Moses: Any chance we get, we need to make security the path -- the most secure methods, the path of least resistance. Humans by nature are lazy. I'm lazy.

Rick Howard: I'm lazy.

CJ Moses: It's just the nature of humans. And if you make the more secure path, the path of least resistance, we'll all be better off for it.

Rick Howard: That's a fantastic way to end this conversation. I appreciate it, CJ. That's some really good stuff, thank you very much.

CJ Moses: Absolutely. I appreciate it. I look forward to trying to come back and we can talk some more.

Rick Howard: Excellent, man. Thank you, sir.

CJ Moses: Thank you.

Dave Bittner: That's the CyberWire's own Rick Howard speaking with CJ Moses, CISO of Amazon Web Services.

Dave Bittner: And that's the CyberWire. For links to all of today's stories, check out our Daily Briefing at the cyberwire.com. Be sure to check out this weekend's Research Saturday and my conversation with Ian Ahl, from Permiso's P0 Labs, discussing "unmasking GUI-Vil: A financially-motivated cloud threat actor." That's Research Saturday, check it out. We'd love to know what you think of this podcast. You can email us at cyberwire@n2k.com. Your feedback helps us ensure we're delivering the information and insights that help keep you a step ahead in the rapidly changing world of cybersecurity. We're privileged that N2K and podcasts like the CyberWire are part of the daily intelligence routine of many of the most influential leaders and operators in the public and private sector, as well as the critical security teams supporting the Fortune 500 and many of the world's preeminent intelligence and law enforcement agencies. N2K strategic workforce intelligence optimizes the value of your biggest investment. We make you smarter about your team, while making your team smarter. Learn more at n2k.com. This episode was produced by Liz Irvin and senior producer, Jennifer Eiben. Our mixer is Tre Hester, with original music by Elliott Peltzman. The show was written by John Petrik. Our executive editor is Peter Kilpe, and I'm Dave Bittner. Thanks for listening. We'll see you back here next week.