WEBVTT 1 00:00:00.120 --> 00:00:03.439 Welcome to your deep dive. Today. We're cracking open no 2 00:00:03.640 --> 00:00:08.519 Starch pen testing Azure to explore the wild world of 3 00:00:08.560 --> 00:00:12.679 Azure cloud security from a penetration testers perspective. It's like 4 00:00:12.720 --> 00:00:15.240 getting a sneak peek into the attacker's playbook. 5 00:00:15.359 --> 00:00:20.559 This book really dives into the unique challenges of securing 6 00:00:20.559 --> 00:00:25.199 cloud environments, which are vastly different from traditional on premises setups. 7 00:00:25.280 --> 00:00:27.679 Right, and one thing that stood out to me is 8 00:00:27.719 --> 00:00:30.719 how critical planning and scoping are in this whole process. 9 00:00:30.760 --> 00:00:32.679 I mean, nobody wants to end up on the wrong 10 00:00:32.719 --> 00:00:35.280 side of the law while trying to improve security right. 11 00:00:35.399 --> 00:00:40.600 Absolutely, Penetration testing without proper authorization and a clearly defined 12 00:00:40.640 --> 00:00:46.039 scope can have serious legal ramifications. Imagine accidentally disrupting a 13 00:00:46.039 --> 00:00:49.520 critical service or accessing data you weren't supposed to. That's 14 00:00:49.520 --> 00:00:51.880 why it's crucial to have a solid plan in place, 15 00:00:52.200 --> 00:00:55.240 outlining the systems you'll be targeting, the methods you'll use, 16 00:00:55.560 --> 00:00:57.240 and the timeframe for the assessment. 17 00:00:57.320 --> 00:00:59.799 And here's where it gets really tricky. The book mentions 18 00:00:59.840 --> 00:01:03.280 that cloud resources can be physically located in different countries, 19 00:01:03.520 --> 00:01:05.920 each with its own set of laws and regulations. That 20 00:01:05.959 --> 00:01:07.799 adds a whole other layer of complexity. 21 00:01:08.040 --> 00:01:11.000 Definitely, a server could be migrated to a different region 22 00:01:11.079 --> 00:01:15.200 during testing, potentially landing it into jurisdiction with very different 23 00:01:15.239 --> 00:01:18.400 cybersecurity laws. It's essential to have a clear understanding of 24 00:01:18.400 --> 00:01:21.200 where your client's data resides and to comply with all 25 00:01:21.239 --> 00:01:23.159 relevant regulations. 26 00:01:23.280 --> 00:01:25.599 Before you even start poking around. There's a lot of 27 00:01:25.680 --> 00:01:29.760 legal groundwork to cover. Now, let's dive into Azure's deployment models. 28 00:01:30.200 --> 00:01:32.799 I was surprised to learn that Azure uses both a 29 00:01:32.920 --> 00:01:36.959 legacy model ASM and a newer role based system AIRM, 30 00:01:37.079 --> 00:01:39.640 and both are still actively used. What are the security 31 00:01:39.680 --> 00:01:43.640 implications of having these two models running side by side. 32 00:01:43.680 --> 00:01:45.760 It's like having two sets of locks on your front door. 33 00:01:46.280 --> 00:01:49.239 Compromising one user's account might only grant access to a 34 00:01:49.280 --> 00:01:52.680 portion of the resources under a subscription. A thorough penetration 35 00:01:52.799 --> 00:01:55.560 test needs to target both models to assess the overall 36 00:01:55.560 --> 00:01:56.400 security posture. 37 00:01:56.840 --> 00:01:59.640 That makes sense. So with ASM, you've got your three 38 00:01:59.680 --> 00:02:04.640 manual service administrator, account administrator, and code administrator. The book 39 00:02:04.640 --> 00:02:06.439 makes it sound like gaining access to any of these 40 00:02:06.519 --> 00:02:09.599 roles is basically game over for ASM resources. Is that 41 00:02:09.639 --> 00:02:10.560 a fair assessment? 42 00:02:10.800 --> 00:02:15.360 Pretty much co administrator role despite its name, has essentially 43 00:02:15.439 --> 00:02:18.680 the same privileges as the service administrator. Both roles have 44 00:02:18.759 --> 00:02:21.719 full control over any ASM created resource. 45 00:02:22.240 --> 00:02:24.479 Got it, So it's like finding the master key that 46 00:02:24.560 --> 00:02:29.199 unlocks everything. Now let's talk about ARM. It sounds like 47 00:02:29.319 --> 00:02:32.120 this newer model is a bit more granular with its 48 00:02:32.159 --> 00:02:33.280 permissions exactly. 49 00:02:33.479 --> 00:02:38.000 AIRM utilizes roll test access control, which allows administrators to 50 00:02:38.039 --> 00:02:42.479 define very specific permissions for users and groups. This means 51 00:02:42.479 --> 00:02:45.960 that even if an attacker compromises one user's account, they'll 52 00:02:45.960 --> 00:02:49.319 only have access to the resources they're explicitly authorized to use. 53 00:02:49.479 --> 00:02:52.639 That's reassuring, But even with these different access models, at 54 00:02:52.639 --> 00:02:54.840 the end of the day, attackers still need credentials to 55 00:02:54.840 --> 00:02:56.159 get their foot in the door right. 56 00:02:56.400 --> 00:02:59.800 The book mentions mimic ants as a particularly sneaky tool 57 00:02:59.800 --> 00:03:00.599 in the arsenal. 58 00:03:00.680 --> 00:03:04.240 Mimicats is a powerful post exploitation tool that can extract 59 00:03:04.280 --> 00:03:07.639 passwords directly from a user's operating system, even when the 60 00:03:07.680 --> 00:03:10.360 system is offline. It takes advantage of how Windows stores 61 00:03:10.400 --> 00:03:11.400 credentials in memory. 62 00:03:11.479 --> 00:03:14.319 That's pretty unsettling. Does that mean any attacker with memicats 63 00:03:14.400 --> 00:03:17.439 could just grab passwords from any Windows system? Not quite. 64 00:03:17.599 --> 00:03:22.080 The effectiveness of mimicats depends on various factors, including the 65 00:03:22.080 --> 00:03:27.120 Windows version and configuration. Newer versions, especially Windows ten Enterprise 66 00:03:27.240 --> 00:03:31.039 with Credential Guard enabled, store credentials in a more secure, 67 00:03:31.080 --> 00:03:35.000 isolated environment, making it much harder for tools like mimicats 68 00:03:35.039 --> 00:03:35.479 to succeed. 69 00:03:35.639 --> 00:03:38.280 It's like a constant arms race between the attackers and 70 00:03:38.319 --> 00:03:40.919 the defenders, with each side trying to outsmart the other. 71 00:03:41.159 --> 00:03:44.439 That begs the question, if an organization is migrating to 72 00:03:44.479 --> 00:03:47.319 Azure and still has older Windows systems, is that something 73 00:03:47.360 --> 00:03:49.039 they should be particularly concerned about? 74 00:03:49.360 --> 00:03:52.599 Absolutely, those older systems could be a prime target for 75 00:03:52.680 --> 00:03:57.039 attackers using tools like mimicats. It's crucial to prioritize upgrading 76 00:03:57.080 --> 00:04:01.240 to newer, more secure versions of Windows and implementing robust 77 00:04:01.280 --> 00:04:03.400 security controls like multi factor authentication. 78 00:04:03.520 --> 00:04:06.840 Okay, so upgrading your systems and layering on those extra 79 00:04:06.840 --> 00:04:10.159 security measures is key. But aside from brute force attacks 80 00:04:10.159 --> 00:04:12.879 with tools like mimicats, what are some other ways attackers 81 00:04:12.919 --> 00:04:14.319 go after credentials in the cloud. 82 00:04:14.520 --> 00:04:18.920 Phishing is a perennial favorite. Attackers create convincing fake login 83 00:04:19.000 --> 00:04:23.519 pages or set up elaborate credential capturing systems to trick users. 84 00:04:23.560 --> 00:04:25.399 Into revealing their sensitive information. 85 00:04:25.519 --> 00:04:27.639 That's right. Phishing never seems to go out of style, 86 00:04:27.800 --> 00:04:31.360 does it. But I imagine phishing attacks targeting cloud environments are 87 00:04:31.399 --> 00:04:34.160 a bit more sophisticated than your average email scam. 88 00:04:34.360 --> 00:04:38.319 Right, you bet think spear phishing campaigns specifically designed to 89 00:04:38.319 --> 00:04:43.120 target Azure administrators or developers with access to sensitive cloud resources. 90 00:04:43.600 --> 00:04:47.319 These attacks are highly targeted and often leverage social engineering 91 00:04:47.319 --> 00:04:49.920 techniques to bypass traditional security measures. 92 00:04:50.040 --> 00:04:53.160 That's scary stuff. It really highlights the need for continuous 93 00:04:53.199 --> 00:04:58.240 security awareness training for all employees, especially those with privileged access. Now, 94 00:04:58.839 --> 00:05:02.439 speaking of sensitive information, the book dives deep into Azure 95 00:05:02.519 --> 00:05:05.839 storage security. It makes it sound like securing storage accounts 96 00:05:05.920 --> 00:05:07.160 is absolutely paramount. 97 00:05:07.240 --> 00:05:11.399 You're absolutely right. Azure storage accounts are where organizations keep 98 00:05:11.399 --> 00:05:15.399 a treasure trove of sensitive data. If an attacker gains access, 99 00:05:15.920 --> 00:05:22.079 they can recavoc stealing data, manipulating configurations, even injecting malicious code. 100 00:05:22.240 --> 00:05:24.839 Okay, so it's like the Fort Knox of your Azure environment. 101 00:05:25.680 --> 00:05:28.759 But we're talking about real world attack scenarios. How are 102 00:05:28.759 --> 00:05:32.959 attackers actually getting their hands on those storagecout keys in 103 00:05:33.000 --> 00:05:33.560 the first place. 104 00:05:33.800 --> 00:05:37.800 Be surprised how often developers accidentally leave those keys exposed 105 00:05:38.399 --> 00:05:41.759 in source code, repositories or configuration files. It's like leaving 106 00:05:41.800 --> 00:05:43.879 the keys to your vault hanging on a Pullton board. 107 00:05:43.920 --> 00:05:48.240 That's incredible. So, aside from accidentally leaving those keys lying around, 108 00:05:48.439 --> 00:05:51.639 what are some other ways attackers are exploiting Azure storage? 109 00:05:52.040 --> 00:05:56.480 They might exploit weak access controls like overly permissive permissions 110 00:05:57.160 --> 00:06:00.160 that allow anyone to read or write data, or or 111 00:06:00.160 --> 00:06:03.480 they might target specific storage services like queues, which are 112 00:06:03.480 --> 00:06:05.680 often used for communication between applications. 113 00:06:05.800 --> 00:06:09.439 Hold on manipulating cues. How does that work and what 114 00:06:09.480 --> 00:06:10.920 are the potential consequences? 115 00:06:11.319 --> 00:06:14.399 Imagine a queue used to process orders in an e 116 00:06:14.399 --> 00:06:19.000 commerce application. An attacker could inject malicious messages into the queue, 117 00:06:19.360 --> 00:06:23.920 altering prices, redirecting payments, or even causing the application to crash. 118 00:06:23.959 --> 00:06:27.839 Wow, so a seemingly harmless queue could be a major 119 00:06:27.920 --> 00:06:31.800 security vulnerability. What are some practical steps developers can take 120 00:06:32.199 --> 00:06:33.600 to prevent this type of attack? 121 00:06:33.720 --> 00:06:37.759 Strong authentication and authorization are essential, along with proper input 122 00:06:37.879 --> 00:06:41.720 validation and sanitization. Think of it like implementing texts and 123 00:06:41.759 --> 00:06:45.560 balances to ensure only legitimate messages are processed. 124 00:06:45.920 --> 00:06:48.680 So it's all about building those security checks into the 125 00:06:48.720 --> 00:06:52.000 application itself, not just relying on perimeter security. That makes 126 00:06:52.000 --> 00:06:54.920 a lot of sense. Now let's shift gears and talk 127 00:06:54.959 --> 00:06:59.360 about virtual machine security, or VM security. The book really 128 00:06:59.399 --> 00:07:02.519 emphasizes how critical it is to lock down those vms, 129 00:07:02.879 --> 00:07:06.279 and it even details some scary scenarios like attackers obtaining 130 00:07:06.360 --> 00:07:09.120 VHD images and extracting data from them. 131 00:07:09.160 --> 00:07:11.639 It's a serious threat, and it's not as difficult as 132 00:07:11.639 --> 00:07:15.319 you might think. Attackers can download snapshots of vhds using 133 00:07:15.360 --> 00:07:19.040 freely available tools like Microsoft Azure Storage Exploitate. 134 00:07:18.680 --> 00:07:21.160 A free tools, So anyone with Internet access can just 135 00:07:21.199 --> 00:07:22.800 download these VHD images. 136 00:07:23.040 --> 00:07:25.959 Not exactly, they would still need the storage account key, 137 00:07:26.279 --> 00:07:28.920 which brings us back to the importance of securing those keys. 138 00:07:29.040 --> 00:07:32.120 But once they have the key, downloading the VHD is 139 00:07:32.160 --> 00:07:33.079 just a few clicks away. 140 00:07:33.160 --> 00:07:36.079 Okay, so that's step one. But once an attacker has 141 00:07:36.120 --> 00:07:39.120 that VHD image, what can they actually do with it? 142 00:07:39.240 --> 00:07:42.240 Think of it like stealing a blueprint. They can analyze 143 00:07:42.240 --> 00:07:46.519 the VHD using forensic tools to extract all sorts of 144 00:07:46.560 --> 00:07:52.240 sensitive information, including user accounts, passwords, and configuration files. 145 00:07:52.279 --> 00:07:55.040 That's pretty alarming. So it's like having your entire server 146 00:07:55.199 --> 00:07:58.959 environment compromised just because a single storage account key was leaked. 147 00:07:59.160 --> 00:08:02.319 What are some concrete steps organizations can take to protect 148 00:08:02.319 --> 00:08:03.959 their vhds from this kind of attack. 149 00:08:04.319 --> 00:08:08.279 Encryption is key here. Azure offers disc encryption, a free 150 00:08:08.279 --> 00:08:11.920 service that uses BitLocker for Windows vms and dmcrypt for 151 00:08:12.160 --> 00:08:15.959 Linux vms to fully encrypt the virtual disc. This makes 152 00:08:16.000 --> 00:08:19.040 it impossible for attackers to analyze the VHD, even if 153 00:08:19.079 --> 00:08:20.040 they manage to attain it. 154 00:08:20.240 --> 00:08:24.079 So it's like putting that VHD image in a lock box, 155 00:08:24.319 --> 00:08:27.319 making it useless to anyone without the key. But what 156 00:08:27.439 --> 00:08:31.279 about securing the vms themselves? Are there any default security 157 00:08:31.279 --> 00:08:33.679 features in Azure or is it all up to the 158 00:08:33.720 --> 00:08:35.919 administrators to configure everything manually. 159 00:08:36.279 --> 00:08:39.879 Azure vms come with some basic security features enabled by default, 160 00:08:40.200 --> 00:08:43.919 like firewalls and antivirus software. However, they are not fort 161 00:08:43.960 --> 00:08:46.559 Knox out of the box. Administrators still need to be 162 00:08:46.600 --> 00:08:52.159 proactive about configuring security settings, applying updates, and implementing best 163 00:08:52.200 --> 00:08:54.840 practices like least privilege access right. 164 00:08:54.919 --> 00:08:57.080 So it's not a set it and forget it scenario. 165 00:08:57.279 --> 00:09:01.039 You need to be constantly vigilant about securing yours. Now, 166 00:09:01.120 --> 00:09:02.600 one thing that really stood out to me in the 167 00:09:02.600 --> 00:09:05.879 book was the potential for attackers to exploit the VM 168 00:09:06.000 --> 00:09:08.960 password reset option in the Azure portal. How does that 169 00:09:09.039 --> 00:09:10.519 work and why is it such a concern. 170 00:09:10.679 --> 00:09:14.000 It's a classic privilege escalation attack. If an attacker gains 171 00:09:14.039 --> 00:09:16.919 access to the Azure Portal and can target a specific VM, 172 00:09:17.080 --> 00:09:19.559 they can simply use the password reset feature to gain 173 00:09:19.600 --> 00:09:22.600 administrative access even without knowing the current password. 174 00:09:22.919 --> 00:09:26.240 Wow, that sounds like a pretty significant loophole. Are there 175 00:09:26.279 --> 00:09:29.159 any limitations to this attack or is it a guaranteed 176 00:09:29.200 --> 00:09:30.039 win for the attacker? 177 00:09:30.159 --> 00:09:33.159 Oh, they would need access to the Azure Portal in 178 00:09:33.200 --> 00:09:36.519 the first place, which requires valid credentials. This is where 179 00:09:36.559 --> 00:09:41.240 strong authentication practices like multi factor authentication in MFA come 180 00:09:41.320 --> 00:09:44.480 to play. MFA adds an extra layer of security, making 181 00:09:44.519 --> 00:09:47.559 it significantly harder for attackers to gain unauthorized access. 182 00:09:47.600 --> 00:09:51.480 So MFA is crucial for protecting those administrative accounts. But 183 00:09:51.600 --> 00:09:54.799 even with MFA, it's still possible for determined attackers to 184 00:09:54.840 --> 00:09:58.200 find ways to bypass security measures. What are some other 185 00:09:58.240 --> 00:10:02.919 defenses organizations can implement to protect against VM password reset attacks. 186 00:10:03.080 --> 00:10:06.240 Robust logging and monitoring can be incredibly helpful by tracking 187 00:10:06.320 --> 00:10:09.720 activities like password resets. Security teams can quickly identify and 188 00:10:09.759 --> 00:10:14.559 investigate any suspicious behavior. Alerting mechanisms can notify administrators of 189 00:10:14.639 --> 00:10:18.320 any unexpected password changes, allowing for swift action to contain 190 00:10:18.399 --> 00:10:19.200 potential threats. 191 00:10:19.279 --> 00:10:22.000 Right, So, it's about having that visibility into what's happening 192 00:10:22.000 --> 00:10:25.679 in your environment and being able to respond quickly to 193 00:10:25.799 --> 00:10:29.120 potential threats. But let's assume for a moment that an 194 00:10:29.159 --> 00:10:33.679 attacker manages to bypass those initial defenses and gains access 195 00:10:33.720 --> 00:10:36.919 to a VM. What are their next steps? What are 196 00:10:36.919 --> 00:10:38.720 they likely to do once they're inside. 197 00:10:39.120 --> 00:10:42.320 Their next move is often to map out the network 198 00:10:43.399 --> 00:10:48.480 and identify potential targets for further exploitation. They'll investigate firewall rules, 199 00:10:49.080 --> 00:10:53.559 network configurations, and connected systems to fight weaknesses they can exploit. 200 00:10:53.679 --> 00:10:56.080 It's like they're scouting the terrain looking for the path 201 00:10:56.080 --> 00:10:59.799 of least resistance. What are some common misconfigurations that make 202 00:10:59.840 --> 00:11:02.440 the this reconnaissance process easier for attackers. 203 00:11:02.519 --> 00:11:05.240 One of the most dangerous misconfigurations is the allow all 204 00:11:05.320 --> 00:11:08.679 firewall rule. Some administrators, yeah either out of convenience or 205 00:11:08.720 --> 00:11:12.200 lack of understanding, might allow connections from any IP address, 206 00:11:12.399 --> 00:11:14.639 essentially leaving the door wide open. For attackers. 207 00:11:14.679 --> 00:11:17.120 That's a rookie mistake, right, I mean, it seems like 208 00:11:17.159 --> 00:11:20.919 common sense to restrict access to only authorized IP addresses. 209 00:11:21.120 --> 00:11:24.519 What about firewalls for specific services like Azure Sql. Are 210 00:11:24.559 --> 00:11:25.360 those any different? 211 00:11:25.639 --> 00:11:29.080 Azure Sql firewalls are designed to be more restrictive by default, 212 00:11:29.480 --> 00:11:33.840 only allowing access from other Azure services. However, developers often 213 00:11:33.879 --> 00:11:37.000 need to connect from their workstations, which can lead to 214 00:11:37.000 --> 00:11:41.240 relaxed firewall rules common defined rules that allow connections from 215 00:11:41.320 --> 00:11:44.519 wide IP ranges, potentially opening up vulnerabilities. 216 00:11:45.519 --> 00:11:48.600 So it's that balance between security and usability that can 217 00:11:48.639 --> 00:11:51.759 sometimes create vulnerabilities. What's the best way to strike that balance? 218 00:11:51.799 --> 00:11:52.360 In this case? 219 00:11:52.679 --> 00:11:56.720 Administrators need to carefully evaluate each firewall rule, ensuring they 220 00:11:56.759 --> 00:12:01.559 only grant access to necessary IP addresses. Important regular audits 221 00:12:01.600 --> 00:12:04.960 and reviews can help identify and eliminate overly permissive rules, 222 00:12:05.399 --> 00:12:06.639 reducing the attack surface. 223 00:12:06.759 --> 00:12:10.360 Okay, got it. So it's about being meticulous with those 224 00:12:10.399 --> 00:12:13.159 firewall configurations and not just taking the easy way out. 225 00:12:13.240 --> 00:12:16.440 Now we've talked about traditional firewalls, but the book also 226 00:12:16.519 --> 00:12:20.080 mentions as your web application firewalls or wfs, How are 227 00:12:20.120 --> 00:12:22.399 those different and what role do they play in securing 228 00:12:22.480 --> 00:12:23.360 azure environments. 229 00:12:23.639 --> 00:12:27.720 Unlike traditional firewalls that operate at the network layer, wafs 230 00:12:27.879 --> 00:12:31.080 sit in front of web applications and analyze incoming traffic 231 00:12:31.159 --> 00:12:35.799 for malicious patterns. They can block suspicious requests or report incidents, 232 00:12:36.120 --> 00:12:40.120 acting more like an intrusion detection system than a traditional firewall. 233 00:12:39.879 --> 00:12:43.720 So they're looking for specific attack signatures and behaviors rather 234 00:12:43.759 --> 00:12:47.480 than just blocking IP addresses imports. That's pretty cool. What 235 00:12:47.519 --> 00:12:50.559 are some examples of attacks that a wave might detect 236 00:12:50.600 --> 00:12:51.120 and block? 237 00:12:51.440 --> 00:12:55.360 Laways could detect and block common web attacks like sequel injection, 238 00:12:55.759 --> 00:12:59.399 cross sight scripting, and session hijacking. They can also protect 239 00:12:59.399 --> 00:13:02.960 against application layer GIDAS attacks and filter traffic based on 240 00:13:03.000 --> 00:13:05.879 factors like geographic location or device type. 241 00:13:06.000 --> 00:13:08.519 Wow, so they're quite versatile. But are they a fool 242 00:13:08.559 --> 00:13:12.039 proof solution or are there ways for attackers to bypass them. 243 00:13:12.200 --> 00:13:15.639 While waves are incredibly powerful, no security measure is full proof. 244 00:13:15.759 --> 00:13:19.759 Attackers are constantly evolving their techniques and some sophisticated attacks 245 00:13:19.799 --> 00:13:22.159 might slip through the cracks. That's why it's essential to 246 00:13:22.240 --> 00:13:25.840 use waves in conjunction with other security measures and regularly 247 00:13:25.919 --> 00:13:29.039 update through rule sets to stay ahead of emerging threats. 248 00:13:29.360 --> 00:13:33.159 So it's back to that layered approach to security. Now, 249 00:13:34.080 --> 00:13:37.399 let's talk about something that sounds a bit scary, cloud 250 00:13:37.480 --> 00:13:40.559 to corporate network bridging. I'm guessing this is where things 251 00:13:40.600 --> 00:13:43.879 can get really risky, especially when you're connecting your cloud 252 00:13:43.960 --> 00:13:46.720 environment to your internal corporate network. 253 00:13:46.759 --> 00:13:49.519 It definitely adds another layer of complexity. While features like 254 00:13:49.600 --> 00:13:53.159 VPNs and express rout are fantastic for enabling hybrid it, 255 00:13:54.039 --> 00:13:56.440 they can also create a bridge between the cloud and 256 00:13:56.480 --> 00:13:58.919 the corporate network. If an attacker breaches a public facing 257 00:13:58.919 --> 00:14:02.799 service in Azure that has VPN connectivity to the corporate network, 258 00:14:03.240 --> 00:14:07.000 they potentially have a direct path to infiltrate the internal systems. 259 00:14:07.240 --> 00:14:09.960 That's a frightening thought. It's like leaving a secret backdoor 260 00:14:10.000 --> 00:14:13.320 into your fortress wide open. What are some stepped organizations 261 00:14:13.320 --> 00:14:16.639 can take to mitigate this risk and secure those hybrid connections. 262 00:14:17.000 --> 00:14:20.840 Separation is key. Isolate services that need corporate network access 263 00:14:21.080 --> 00:14:25.000 from those exposed publicly, ideally keeping them in separate subscriptions. 264 00:14:25.279 --> 00:14:28.320 And if a service needs both types of access, careful 265 00:14:28.320 --> 00:14:31.639 design and thorough threat modeling are crucial, followed by rigorous 266 00:14:31.639 --> 00:14:34.320 tenetration testing to validate the security. 267 00:14:34.399 --> 00:14:38.240 Okay, so it's all about compartmentalizing and minimizing the attack 268 00:14:38.320 --> 00:14:40.960 surface as much as possible. But let's dive a little 269 00:14:40.960 --> 00:14:44.639 deeper into VPN specifically. What are some common attack vectors 270 00:14:44.759 --> 00:14:48.320 that target azure VPN connections and how can organizations defend 271 00:14:48.320 --> 00:14:48.879 against them. 272 00:14:49.080 --> 00:14:54.200 Attackers might try to exploit misconfigured VPN gateways, brute force credentials, 273 00:14:54.600 --> 00:14:57.679 or even intercept traffic if it's not properly encrypted. They 274 00:14:57.720 --> 00:15:02.759 might also attempt to create rogue VPN can to gain unauthorized. 275 00:15:02.080 --> 00:15:04.720 Access, so it's like they're either trying to break into 276 00:15:04.759 --> 00:15:08.240 the existing tunnel or build their own secret passage. What 277 00:15:08.279 --> 00:15:11.360 are some telltale signs of a rogue VPN connection that 278 00:15:11.399 --> 00:15:13.039 security team should be on the lookout for. 279 00:15:13.240 --> 00:15:18.240 Unusual traffic patterns, unauthorized IP addresses, accessing sensitive resources, or 280 00:15:18.279 --> 00:15:21.399 an increase in VPN connection attempts, especially outside of normal 281 00:15:21.399 --> 00:15:23.360 business hours can all be red flags. 282 00:15:23.399 --> 00:15:27.000 Got it? So monitoring and anomaly detection are critical for 283 00:15:27.039 --> 00:15:31.240 spotting those suspicious activities. Now, what about express route? It 284 00:15:31.240 --> 00:15:34.279 sounds like a more robust and secure option than VPNs, 285 00:15:34.480 --> 00:15:38.279 but are there any specific security considerations organizations should be 286 00:15:38.320 --> 00:15:38.720 aware of. 287 00:15:39.120 --> 00:15:43.759 Express route establishes dedicated circuits between a company and Microsoft's 288 00:15:43.759 --> 00:15:48.279 cloud services, offering a more stable and secure connection than 289 00:15:48.360 --> 00:15:52.639 the public Internet. However, if an attacker compromises a system 290 00:15:53.159 --> 00:15:56.240 connected to the Express Route network, they could potentially access 291 00:15:56.279 --> 00:16:00.039 a wider range of resources, including both Azure and corporate. 292 00:15:59.679 --> 00:16:03.080 System So the stakes are even higher with Express Route 293 00:16:03.159 --> 00:16:06.240 given its complexity and cost. What kind of attackers are 294 00:16:06.240 --> 00:16:09.440 typically interested in targeting these connections. 295 00:16:09.080 --> 00:16:12.200 Due to the higher barrier to entry attax targeting Express 296 00:16:12.279 --> 00:16:15.759 Route are usually carried out by sophisticated actors like nation 297 00:16:15.879 --> 00:16:19.639 states or highly skilled cyber criminals seeking access to high 298 00:16:19.679 --> 00:16:21.519 value data or critical infrastructure. 299 00:16:21.559 --> 00:16:23.720 Okay, so these are not your average script kitties. What 300 00:16:23.759 --> 00:16:27.759 are some defenses against these advanced persistent threats targeting Express 301 00:16:27.799 --> 00:16:28.600 Route connections? 302 00:16:29.039 --> 00:16:34.960 Strong authentication and authorization are paramount. Implementing robust network segmentation 303 00:16:35.480 --> 00:16:38.840 can help limit the impact of a potential breach. Continuous 304 00:16:38.960 --> 00:16:43.639 monitoring and intrusion detection systems can help identify suspicious activity, 305 00:16:44.080 --> 00:16:47.600 and having well rehearsed incident response plans can help contain 306 00:16:47.639 --> 00:16:49.080 and remediate attacks quickly. 307 00:16:49.600 --> 00:16:53.120 It's all about proactive security measures and being prepared for 308 00:16:53.159 --> 00:16:56.679 the worst case scenario. Now I'd like to shift gears 309 00:16:57.000 --> 00:16:59.480 and talk about a service that I'm particularly interested in, 310 00:16:59.720 --> 00:17:03.440 a service bus. What is this service and what makes 311 00:17:03.480 --> 00:17:04.839 it a potential target for attackers? 312 00:17:04.880 --> 00:17:09.359 Dinature service bus is a messaging service that facilitates communication 313 00:17:09.440 --> 00:17:12.799 between applications. It's attractive to attackers because it can hold 314 00:17:12.839 --> 00:17:16.240 sensitive information like connection strings and access keys, and it 315 00:17:16.240 --> 00:17:19.640 can be exploited to disrupt communication or even gain control 316 00:17:19.720 --> 00:17:21.079 over other Azure services. 317 00:17:21.119 --> 00:17:23.920 Okay, so it's like a central communication hub, right that 318 00:17:23.960 --> 00:17:26.559 attackers might try to compromise to gain a foothold in 319 00:17:26.599 --> 00:17:29.400 the environment. What are some specific attack vectors they might 320 00:17:29.519 --> 00:17:30.839 use against service bus? 321 00:17:31.039 --> 00:17:34.839 One common attack is obtaining administrative details such as the 322 00:17:34.920 --> 00:17:39.440 instance name, resource group, dot URL, and access keys. They 323 00:17:39.519 --> 00:17:44.400 might employ social engineering, phishing, or exploit vulnerabilities in the 324 00:17:44.400 --> 00:17:47.319 management interface to steal these credentials. 325 00:17:47.480 --> 00:17:51.279 So securing those administrative details is absolutely crucial. What are 326 00:17:51.279 --> 00:17:55.400 some best practices for protecting this information and mitigating those risks? 327 00:17:55.640 --> 00:18:01.079 Think about implementing strong password policies, multi factor authentication, and 328 00:18:01.119 --> 00:18:05.240 the principle of least privilege access. Robust logging and monitoring 329 00:18:05.640 --> 00:18:09.599 can help detect unauthorized access attempts and regular security audits, 330 00:18:09.640 --> 00:18:11.440 can ensure configurations are up to date. 331 00:18:11.759 --> 00:18:15.400 Got it. So it's back to those fundamental security principles again. 332 00:18:15.440 --> 00:18:15.640 Now. 333 00:18:15.880 --> 00:18:18.200 The book also mentions Azure logic apps, and I have 334 00:18:18.240 --> 00:18:20.119 to admit I'm not entirely sure what those are. Can 335 00:18:20.160 --> 00:18:22.359 you explain them and why they might be of interest 336 00:18:22.440 --> 00:18:23.039 to attackers? 337 00:18:23.160 --> 00:18:26.319 Logic apps are a cloud tiss service that allows users 338 00:18:26.359 --> 00:18:30.079 to automate workflows and integrate different applications and services. They're 339 00:18:30.119 --> 00:18:33.000 essentially building blocks for creating automated processes in the cloud. 340 00:18:33.240 --> 00:18:35.640 Okay, that makes sense, But how do they fit into 341 00:18:35.640 --> 00:18:39.480 the security landscape? Are logic apps themselves vulnerable to attacks 342 00:18:39.599 --> 00:18:41.880 or is it more about how they're used and configured. 343 00:18:42.480 --> 00:18:45.359 While logic apps themselves might not have a huge attack surface, 344 00:18:45.599 --> 00:18:49.799 they often cash credentials and access tokens for various services, 345 00:18:50.079 --> 00:18:53.559 including both Microsoft and third party services. That's what makes 346 00:18:53.559 --> 00:18:54.839 them attractive to attackers. 347 00:18:54.960 --> 00:18:58.160 Ah, so it's those cached credentials that are their real price. 348 00:18:58.720 --> 00:19:02.039 Are there any specific attacks that target logic apps or 349 00:19:02.079 --> 00:19:05.799 is it more about exploiting misconfigurations and poor security practices. 350 00:19:06.279 --> 00:19:10.000 It's mainly about exploiting those misconfigurations and weaknesses in how 351 00:19:10.079 --> 00:19:13.000 logic apps are implemented, attackers might try to gain access 352 00:19:13.000 --> 00:19:16.720 to the underlying infrastructure, exploit vulnerabilities in the platform itself, 353 00:19:17.160 --> 00:19:20.960 or use social engineering techniques to trick users into revealing 354 00:19:21.039 --> 00:19:22.000 sensitive information. 355 00:19:22.200 --> 00:19:26.200 It's another reminder that even seemingly harmless services can pose 356 00:19:26.200 --> 00:19:30.240 a security risk if not properly secured. Now, let's move 357 00:19:30.240 --> 00:19:32.759 on to a service that I'm really intrigued by, as 358 00:19:32.799 --> 00:19:36.000 your key vault. It sounds like this service is designed 359 00:19:36.799 --> 00:19:39.519 to be a digital fortress for storing secrets. Is that 360 00:19:39.599 --> 00:19:40.319 a fair assessment? 361 00:19:40.559 --> 00:19:45.359 Absolutely? Keyvol provides a secure and centralized platform for storing 362 00:19:45.400 --> 00:19:52.039 sensitive information like passwords, connection strings, API keys, and certificates. 363 00:19:52.240 --> 00:19:55.880 It's built with robust security controls to protect these secrets 364 00:19:55.920 --> 00:19:57.240 from unauthorized access. 365 00:19:57.480 --> 00:19:59.599 Okay, so it's like the ultimate lock box for your 366 00:19:59.599 --> 00:20:02.519 most valuable digital assets. But as we've seen with other 367 00:20:02.559 --> 00:20:06.680 Azure services, every fortress has its potential weaknesses. What are 368 00:20:06.720 --> 00:20:10.279 some of the vulnerabilities that attackers might target in keyvault? 369 00:20:10.599 --> 00:20:15.200 Misconfigured access policies are a common vulnerability. If permissions aren't 370 00:20:15.200 --> 00:20:18.759 properly restricted, users or applications could gain access to secrets 371 00:20:18.759 --> 00:20:22.240 they shouldn't have. Attackers also look for vulnerabilities in the 372 00:20:22.319 --> 00:20:25.880 key voult service itself, though Microsoft regularly patches and updates 373 00:20:25.880 --> 00:20:28.240 the platform to address any known issues. 374 00:20:28.480 --> 00:20:31.119 So even with a service that's designed for security, it 375 00:20:31.160 --> 00:20:33.319 all comes down to how it's configured and managed. What 376 00:20:33.359 --> 00:20:36.039 are some best practices for hardening key vault and ensuring 377 00:20:36.039 --> 00:20:37.680 the security of the secrets stored. 378 00:20:37.440 --> 00:20:41.880 Within Tightly controlling access is paramount Role based access control 379 00:20:42.079 --> 00:20:47.160 RBAC allows administrators to grank granular permissions to users and applications, 380 00:20:47.720 --> 00:20:50.519 ensuring they only have access to the specific secrets they need. 381 00:20:51.119 --> 00:20:54.039 Pre Encrypting secrets before storing them in key vault adds 382 00:20:54.039 --> 00:20:55.200 an extra layer of protection. 383 00:20:55.319 --> 00:20:58.799 Pre encrypting secrets. That's interesting. Why is that recommended and 384 00:20:58.920 --> 00:21:00.839 what additional benefits does it provide? 385 00:21:01.039 --> 00:21:04.079 It ensures that even if an attacker gains access to 386 00:21:04.119 --> 00:21:07.039 the key vault, they won't be able to easily decrypt 387 00:21:07.039 --> 00:21:10.880 the secrets without the additional encryption key. Think of like 388 00:21:10.920 --> 00:21:12.880 having a lock box inside a vault. 389 00:21:12.960 --> 00:21:15.519 That's a great analogy. So it's like defense in depth 390 00:21:15.559 --> 00:21:18.319 applied to secrets management. Now, what about logging? Is that 391 00:21:18.400 --> 00:21:20.119 important for key vault security as well? 392 00:21:20.200 --> 00:21:24.480 Absolutely? Enabling logging provides an audit trail of all activities 393 00:21:24.480 --> 00:21:29.519 related to keyfold including key enumeration, creation, reads, rights, and deletions. 394 00:21:29.680 --> 00:21:33.079 This allows security teams to monitor for any suspicious activity 395 00:21:33.440 --> 00:21:35.079 and identify potential breaches. 396 00:21:35.319 --> 00:21:38.839 So it's like having a security camera inside the vault 397 00:21:39.400 --> 00:21:44.119 recording everything that happens. Now, let's talk about how attackers 398 00:21:44.160 --> 00:21:47.319 typically try to access keyvoult. Are there any common techniques 399 00:21:47.359 --> 00:21:50.279 they use to get their hands on those valuable secrets. 400 00:21:50.519 --> 00:21:54.839 They might try to exploit stolen credentials, brute force access keys, 401 00:21:55.440 --> 00:21:59.319