WEBCAST: Attack Tactics Part 1

Summary

---

Episode Summary: Talkin' Bout [Infosec] News – Attack Tactics Part 1

Podcast: Talkin' Bout [Infosec] News
Host: Black Hills Information Security
Episode: WEBCAST: Attack Tactics Part 1
Air Date: June 4, 2018
Main Hosts/Speakers: John Strand (B), Derek Banks (C), Sierra (A)

---

Episode Overview

This episode kicks off a new series on "Attack Tactics," focusing on the offensive side of web application assessments and red teaming. John Strand, with guests Derek Banks and Sierra, break down a recent BHIS penetration test to illustrate modern attack methodologies used against organizations, emphasizing tactics, tools, and real-world lessons learned. This part of the series is purely offensive—defensive strategies and detection methods will follow in Part 2.

---

Key Discussion Points & Insights

1. Structure of the Webcast Series

• The series alternates between offensive (attacks/techniques) and defensive (detectors/countermeasures) topics.
• Real test cases are drawn from BHIS engagements, with redacted details to protect client specifics.
• This episode’s test case: External assessment against an org with cloud-based email (Office 365), SharePoint, some VPNs—most critically, single-factor authentication (SFA).
• Slides are referenced but not included in the podcast; listeners are directed to YouTube for visuals.

---

2. Common Security Weaknesses Uncovered

• Single-factor authentication (SFA) is a persistent vulnerability.

  • “If we're ever doing an assessment for an organization and they do not have two-factor enabled, it's pretty much a bad sign for them.” — John [02:29]
  • SFA tied into Active Directory is especially problematic.

• Cloud services (Office 365 & Google Apps) increase attack surface.

  • Pen testing against these services is often discouraged.
  • Detection by providers (like Microsoft) is hit-or-miss or significantly delayed.
  • Credential reuse and cloud/on-prem authentication create dangerous links.

• Default credentials and exposed admin interfaces are rampant.

  • Many orgs leave interfaces unprotected or still using defaults, especially when third-party vendors are involved.

• Legacy technology and overlapping stacks increase risk.

  • Multiple VPN solutions (Cisco, Juniper, Softlayer) and exposed database servers multiply attack surfaces.
  • Old service accounts and outdated group policy artifacts (like GPP password files) still common in even large/modern orgs.

---

3. Attack Methodology Walk-through

Reconnaissance (Recon NG and OSINT) [03:01+]

• Using tools like Recon NG, Shodan, HaveIBeenPwned, Punk Spider to gather user info, breached creds, and exposed services without tipping off the target.

Password and Credential Gathering [04:48+]

• Finding immense numbers of leaked credentials online is still highly effective (“It's ridiculous to me how effective it still is for us to find credentials associated with a target organization online.” — John [08:44])
• Tools and resources: HaveIBeenPwned, Pastebin, custom APIs, password dumps.

Cloud & Hybrid Attacks [05:09, 07:21+]

• Credential reuse from third-party breaches leads to Office 365/Google Apps accounts compromise.
• Password spraying (using Burp Suite and related tools) is frequent.
• Detection by cloud providers is either slow or absent.

Password Policy and Hash Cracking [12:48+]

• Weak org password policies (8-character minimum still prevalent).
• Even with longer (15+) passwords, dictionary/rule-based hashcracking (Hashcat techniques) can still yield wins.
• Most clients haven't moved beyond short, easy-to-crack passwords.

Notable quote:
“The longer the password the better. But still to this day, the majority of our customers … still have an 8 character password policy because they couldn’t win the fight. Security did not win the fight against operations.” — Derek [13:30]

Default Credentials and Poor Decommissioning [18:21+]

• Many exposed management interfaces still use default credentials.
• Third-party, VOIP, and legacy admin panels are common culprits.
• Pen testers often gain access this way more than by exploiting software vulnerabilities.

Password Spraying Tactics [22:45+]

• Season-and-year type passwords (“Spring20”, etc.) remain very common.
• “Password spraying gets us into more organizations than just about anything.” — John [22:45]
• Spray attacks are now federated/distributed via tools like Proxy Cannon, Amazon Lambda, to evade simple IP-based blocking ([24:15+]).
• Blue teams often engage in IP-blocking battles, but attackers can throttle attempts and constantly shift IPs.

Credential Reuse and Lateral Movement [27:04+]

• Credentials from one compromised service (e.g., SharePoint) allow access to other linked services (e.g., Office 365, OWA, VPNs).
• Global Address Lists are harvested to expand the attack surface within the org.

Post-Exploitation Recon and Data Gathering [33:32+]

• Searching mailboxes (MailSniper) and SharePoint for internal docs, VPN setup instructions, and more credentials.
• Attackers seek to avoid dropping malware; living-off-the-land (abusing built-in tools/RDP/VPN) is preferred if possible to avoid detection.

Domain Recon, Privilege Escalation, and Hash Extraction [36:31+]

• Techniques: NetUser, NetView, PowerView, Bloodhound, DeathStar for mapping AD relationships.
• Kerberoasting: Cracking service account hashes retrieved via Kerberos ticket requests ([38:40+]).
• Group Policy Preference files (GPP): Still, years after patch, many orgs’ GPP XMLs contain crackable admin passwords ([41:09+]).
• Attackers dump hashes from DCs using safer methods (volume shadow copy vs. in-memory dump) to avoid crashes.

Password Policy Realities [47:39+]

• Easiest point of compromise: orgs stuck with 8-character password policies (often due to legacy apps/mainframes).
• Cultural and operational inertia (“If it’s not broken, don’t fix it”) keeps insecure defaults alive.

Attack Objectives and Adversarial Goals [48:50+]

• Real adversaries (or targeted pentests) have a specific data or privilege objective (not merely “domain admin” but often sensitive docs, IP, or financial data).
• Ownership of a large portion of creds generally equals organizational compromise.

---

4. Pen Testing Team Definitions [20:05+]

• Red team: Adversary simulation (planned duration, possibly all attack types).
• Black team: Surprise, open-ended testing—attack could happen anytime over many months.
• Purple team: Red (attackers) and blue (defenders) collaborate, sharing TTPs and detection/response learnings.

Quote:
“It’s basically a difference in timescale.” — John, on distinction between red and black teams [21:09]

---

Notable Quotes & Memorable Moments

| Timestamp | Speaker | Quote | |-----------|-------------|--------------------------------------------------------------------------------------------------------| | 02:29 | John (B) | “If we're ever doing an assessment for an organization and they do not have two-factor enabled, it's pretty much a bad sign for them.” | | 08:44 | John (B) | “It's ridiculous to me how effective it still is for us to find credentials associated with a target organization online.” | | 13:30 | Derek (C) | “The longer the password the better. But ... still have an 8 character password policy because they couldn't win the fight.” | | 18:21 | John (B) | “We have better success with default creds than actual remote exploits gaining access to systems.” | | 22:45 | John (B) | “Password spraying gets us into more organizations than just about anything.” | | 23:03 | John (B) | “A password like right now it'd be spring 20. That would be a password that would be used...” | | 24:15 | Sierra (A) | “When you attack, are you coming from one IP?...” | | 31:06 | Sierra (A) | “Do you find yourself making recommendations for stricter passwords for privileged accounts when you can't win the overall policy?” | | 48:50 | John (B) | “Anytime an adversary is coming at your organization and they’re a targeted adversary, they have a goal and objective.” |

---

Important Segment Timestamps

• Key Problem: Single-Factor Authentication in the Cloud — [02:03–03:01]
• Recon NG and OSINT Methods — [03:01–05:09]
• Cloud Service Exploitation & Detection Gaps — [05:52–08:44]
• Password Spraying & Credential Harvesting — [08:44–12:47]
• Hash Cracking & Password Policy Weaknesses — [12:48–15:38]
• Exposed Services & Default Credentials — [15:38–20:05]
• Pentest Team Definitions — [20:05–22:45]
• Password Spray Details & Defeating IP-Based Blocking — [22:45–26:24]
• Credential Reuse & Expanding Access — [27:04–29:41]
• Sensitive Data Search via MailSniper — [33:32–36:16]
• Active Directory Recon & Advanced Techniques — [36:31–41:09]
• Group Policy Password Extraction — [41:09–42:51]
• Hash Dumping via Volume Shadow Copy — [44:25–47:39]
• Password Policy History/Persistence — [47:39–49:30]
• Closing Themes & Next Episode Preview — [52:06–54:37]

---

Key Takeaways

• Credential management and authentication weaknesses remain the lowest-hanging fruit for attackers, despite years of warnings and tools available.
• Detection by cloud email/SaaS providers is inadequate or too delayed to be meaningful for many real attacks.
• Password spray, credential stuffing, and default creds trump exotic remote exploits for real-world red teams.
• The attack chain often combines OSINT, recycled creds, exposed interfaces, poor cleanup, and lateral movement, usually without any malware needed.
• Defense is multi-layered and can’t rely on a single technology or team. Upcoming episodes will address defense and detection strategies for each attack method discussed here.

---

Final Thoughts & Series Direction

The episode sets up a comprehensive, realistic view of how modern attacks against organizations unfold, focusing on actionable steps, real mistakes, and penetration tester perspectives. The next episode will shift focus to defensive measures, detection techniques, and practical advice for organizations to harden themselves against these attack tactics.

---

Useful Links:

• Black Hills Information Security YouTube
• Black Hills Information Security Website

[Note: All timestamps refer to the podcast episode audio.]

Transcript

[A]

Hello from Spearfish, South Dakota. It's the Black Hills Information Security Podcast. This is the podcast version of our webcast, so slides that we reference may be missing, but you can find the whole episode on our YouTube channel.

This is Attack Tactics Part 1 with John Strand and special guest Derek Banks and me, Sierra.

[B]

So this webcast is the beginning of a series I thought would be a lot of fun Attack Tactics. So the first one will be offensive. That's we're going to talk about a component of a Red Team or a web application assessment. And then the second one, which is purely offensive, we're going to go through the entire attack methodology that we discussed in the previous session and we're going to discuss the step by step defenses that your organization could have in place to stop each one of those. As much as I hate saying this, it's kind of like a cyber kill chain for each one of our webcasts. God help me, I know that every time I say that, Lockheed Martin gets a nickel. So we're going to be talking about the attacks and we're going to be talking about the defenses. Now, as much as possible, I try to pull these different red teams web application assessments and the different attacks that we do from actual penetration tests that BHIS does. And whenever possible, I try to have the actual tester or one of the testers that were on that engagement on the call in the webcast with us. And in this webcast we're going through an assessment that Derek did. And I've also changed some things from parts of this parts of the Red team. So it doesn't exactly map off perfectly off of one of our reports and one of our customers that we did. By the way. The slides will be available, but we'll release the slides after the second webcast where I fill in all the defenses for each one of the components. So the overview. Derek, do you want to talk a little bit about this test from an external perspective? I didn't change much on this slide. They had their standard setup on the DMZ, some VPNs, some SharePoint servers and Office 365. Anything else from an overview perspective that you think was important?

[C]

No, I think that about covers it. They had moved their email into the cloud as well as the SharePoint install they had was also in the cloud. You have to pause before you say that. And I think the key thing that we'll see here as we walk through it is the single factor was the biggest issue. They had single factor authentication and it's.

[B]

Quickly getting to the point for a lot of our assessments, if we're ever doing an assessment for an organization and they do not have two factor enabled, it's pretty much a bad sign for them. Would you say it's almost, I don't want to say a guarantee, but a very high likelihood that we're going to be able to get into an organization if they just have single factor authentication to some degree?

[C]

Yes, I think pretty much if there is anything that's single factored and then also if it's tied internally to Active Directory, that typically there'll be something there.

[B]

Yeah. And both of those things are in play in this assessment. But like every single good red team or penetration test that's being done, you're always going to start with Recon ng. Now what Recon NG does for those of you that are relatively new, you can look it up, just Google Recon NG and it'll take you to a repository that is currently maintained by Tim Tomes. Tim Tomes is a former employee of Black Hills Information Security and currently he does a lot of subcontracting. He still does work with us quite regularly and we're still maintaining or supporters of Recon NG and supporting code and also financially supporting the open source project as well. Recon NG is designed to tie together all of the different components of open source recon that you can pull without actually touching the organization. Now there are some modules that do touch the target organization, but the vast majority of them are pulling from third party resources like you would pull information from. Have I been pwned about possibly compromised email accounts and password hashes? You could use things like Punk Spider which has been released in updated to possibly identify services, ports or vulnerabilities for different web services Shodan to identify services that are exposed as well. The idea is to find out as much as you can about a target organization without touching it. The more you learn about an organization generally the better the actual assessment. Pen test Red team goes because you're not going to be stumbling into things quite so blindly whenever you do your assessment. We're going to be looking for users services, netblocks, vulnerabilities, possibly even identifying various passwords and credentials that are exposed on third party sites. In fact, Derek, have you talked with Mike Fouch this morning yet at all?

[C]

Not directly, but I didn't hear from this morning's POD meeting about the cool thing he was doing.

[B]

Yeah, he's working on a new API for pulling down I think it was 1.7 billion passwords that were exposed Online and then the ability to search that stuff. That's what he did this weekend. This weekend I cleaned my house and Mike instead did something awesome that he wrote. So hopefully we'll have some blog posts coming up.

[A]

Cleaning the house is awesome.

[B]

No, it's not. It really, really was not awesome at all. So one of the things that was discovered was an Office365 redirect. And I used my own Office365 account here. Now, Derek, can you talk a little bit about what we mean by a redirect whenever we go to a mail server and it shoots us over to an Office365 account?

[C]

Yeah. So basically, depending on what the MX record is, it'll redirect to the, you know, what your organization's email domain is to office 365. I think technically in this case they might have been federated, but it doesn't really matter. So essentially you're checking mail out in the cloud.

[B]

Yeah. And we see the same thing not just with Office365, but also whenever we're attacking organizations that use Google Apps domain as well. And this is becoming, I don't know, I want to get your take on this, but I think that this is becoming a bigger and bigger problem in the security testing community because by and large, these cloud providers for email, they generally don't like you doing pen testing against Office365 or doing pen testing against Google Apps. And they frown upon that activity. Yeah, they do.

So when we're talking about detection and some of the attacks that we did against this organization, kind of setting it up for what's coming, did Microsoft actually detect any of the attacks that we did against this customer or was it relatively under the wire?

[C]

Yeah, for this particular customer, no. However, early on, and we had a customer. When I say early on, I mean when we started running into customers that were using Office365 email.

There was some level of detection. I don't know enough about the back end to know if that customer had purchased something different or had something different set up. I think for this particular customer, we ended up actually performing password spraying against their on premise adfs server. So I don't think it was that like we were actually going after something that was in their.

Asset.

[B]

And that kind of shows a little bit how if you have a service that's exposed, like a SharePoint service or ADFS or something, and it ties directly into Active Directory and you find user IDs and passwords, we can then reuse those accounts in cloud Services that may be tied with the authentication back into the same active directory back end. And it basically shows you shouldn't have anything that's doing direct authentication back to active directory exposed directly without it being behind some type of protection like I would say two factor. I'll come back to that. But really behind a vpn. Now with two factor, what are some of the techniques I know we aren't talking about in this particular assessment? What are some of the techniques that you've been using lately? We've been using lately to kind of get around two factor authentication.

[C]

You mentioned Mike Felsh a minute ago. He wrote Cred Sniper, which I think is a really interesting tool that does exactly that. When you phish somebody for what you fish someone, they click on the link, they get to a page that looks like their email and then they put their credentials in on the back end. It auto authenticates you. I think that's a project that I haven't heard a lot of people talking about that will probably be sort of like Mail Sniper was when it was released that hey, look at this nifty thing that it does. Okay, that's great. Microsoft says that's not really a problem. And the next thing you know we're getting phone calls from government organizations going what the hell?

[B]

Yeah, like the FBI was probably my favorite phone call. And the final thing about this, some of the other assessments that we've been doing lately for doing password spraying directly against like Office 365 and Google, we've look, the providers do not like pen testers doing password spraying against their services. And it gets into this really weird murky gray area as to whether or or not it's legal that the customer allows you to attack their specific domain. Does Microsoft allow you to do that? And those are interesting conversations that we need to have. However, for a number of these scenarios we have discovered that if we do password spring against something like Office 365 in particular Office 365 actually Microsoft does actually notify some of our customers that a password spray or an attack was attempted. But by and large I think almost every single one of them it was two weeks after the attack. So it's not really good up to date telemetry on the attacks as they're coming through. This becomes more and more of a problem that we as a testing community and organizations are going to have to deal with to be ready for testing these various cloud services. And you'll see why here in just a little bit. Next one, creds. It's Ridiculous to me how effective it still is for us to find credentials associated with a target organization online. Now for those of you that are relatively new to these webcasts, what we mean by creds online is if your organization users, let's say@hacked company.com on hacked company.com goes to a third party website like Adobe or LinkedIn or some other website and that website is compromised in a public way where the attacker takes the credentials from that public compromise and then they post them out someplace like Pastebin. They'll a lot of times post the email addresses and the user accounts and the password hashes on these third party sites and then you can pull those credentials down. That's why stuff like Troy Hunt's have I been pwned has been so important is it's showing people just how often credentials are in fact compromised. With a little bit of digging, very easy to go back to the root of where that compromise was posted online and actually pull those hashes and then even crack some of them as well. We talked a lot about Mike. I was talking about him this morning. I said I think not. I said, he said this morning last week I think that they were on a red team and he found three credentials that were compromised in third party breaches and they worked for an engagement that he was working on. So that happens. Do we have any questions so far?

[A]

Brian asked.

Does Microsoft, are they able to tell when they've been breached using Burp Suite in Power?

[B]

That's exactly the technique that we do use whenever we're doing password spraying attacks. Correct me if I'm wrong, Derek. We generally use Burp instead of tools like Hydra because Hydra doesn't follow redirects very well. Whereas if you're doing a password spray with Burp, you can enable Burp to follow the redirects actually get to the size of the destination page and it tends to work better for password spraying. Is that a correct assessment, Derek, in your opinion?

[C]

Yes. If I can't get the easy route and Mail Sniper doesn't work, I'll move to Burp Suite. Or if it's something that's not supported in Mail Sniper at the moment, like say it was a VPN page or something like that. Yeah, Bursley, it's my tool of choice.

[B]

Now the reasoning behind, from what I've heard this has not been confirmed. But from what I've heard, especially with Microsoft, whenever you're doing password Spraying attacks against 365, they have a proxy in the front of their server which is a Good thing. They should be using application level proxies. But the way the logging works, you have logging in two separate locations on the proxy server and on the Office 365 servers. And correlating those logs together and actually identifying attacks is kind of what the problem that Microsoft has had traditionally detecting these attacks more or less in real time. Now there are CASBs. You can actually get a cloud access security broker that you can put on top of your cloud infrastructure that will help detect some of these attacks and mitigate these attacks. We'll talk more about that against Webcast next week. We'll discuss that in more detail.

[A]

Okay.

[B]

Yes.

[A]

Gordon had a question. Do you guys find that password hashes are often crackable? You'd figure with good password policies that even if you had the hashes, you wouldn't be able to crack them effectively or efficiently.

[B]

That's a great point, Derek. I'll throw that over to you. Just to recap it, he asked, if an organization has strong password policies, doesn't it mitigate the likelihood of us cracking passwords on the edge of a network, not on the edge of a network from third party breaches? And I think that there's a lot to that. We have how the passwords actually stored. Is it MD5 or is it bcrypt? How are they actually stored? But then the complexity does actually factor. So what are your thoughts, Darren?

[C]

Yeah, I think that by and large that if you have a policy that said.

15 is what we currently recommend, it does make cracking an NTLM hash certainly more difficult. But I think the longer the password the better. But still to this day, the majority of our customers, we've had repeat customers come back and still have an 8 character password policy because they couldn't win the fight. Security did not win the fight against operations. And so yeah, it's just we don't see a lot of places still having long password policies.

[B]

We do have a couple of customers that do and it does actually make it a lot more difficult. However, here's where this gets interesting and we really should have Kent, Jordan and Derek on to talk about password cracking. Whenever you're cracking passwords with something like Hashcat, let's say an organization has implemented a 15 character password policy. Whenever you're running with Hashcat, you can actually run it with a rule set that does combinations of the password. So if you have a password list, let's say that's Apple, Dog and Cat. It'll try Apple, Dog and Cat, but then it'll do Apple, Dog, Apple Cat, Cat, Dog, Cat, Apple. It'll concatenate those different words together. And what you come up with is somebody could have a password of company name password 1234. And if you have those two separate passwords in the password dictionary, it'll take them and put them together. So yes, longer passwords, passwords do make a difference, but we still come up with ways to actually crack those passwords using various dictionary shenanigans, style attacks, using tools like Hashcat. So it reduces the amount of passwords that are correct, but it doesn't completely mitigate them. But as Derek said, the vast majority of organizations today still run eight character passwords. And I'll talk more about that a little bit later. So some additional recon findings. Credentials, Office 365 support portals, proxies, Citrix servers, database servers exposed directly to the Internet. They had multiple VPNs. This is something that I've seen in a number of organizations and I added it into this first example where an organization will have like a Cisco vpn, a Juniper VPN and then some other SSL softlayer vpn.

I have all the testers send me the reports and I review these reports and I try to find some trends. One of the trends that I do see is multiple different types of technologies at play. Database servers should never be exposed open Internet. But we do see it. When we do see it a lot of times we'll see organizations that are running Microsoft SQL, MySQL Oracle databases, and they're running multiple different technology stacks with VPNs. I asked some of the former customers why they were running some of these like multiple VPN providers. And almost consistently the reasoning came back that they do that because they started with VPN X and then they implemented a new provider, let's say like Cisco. And Cisco had its own VPN capabilities, so they enabled those VPN capabilities. But whenever they tried to remove the legacy VPN technology, there was always an executive or an application or an API or some customer or a service provider that needed to access through the legacy vpn. So they end up managing two separate technology stacks. And this is a consistent theme that I'm noticing with many organizations that have a very poor security posture is they have a diverse technology portfolio. That means they're running like Apache, that means they're running Windows, that means they're running bsd, they're not consistently locking down on one specific technology stack and they have multiple different technologies doing the exact same thing. So that's a consistent problem that we see. Service Desk, SharePoint, you mentioned as well also a JBoss server that was exposed and that gives US management to JBoss so we can actually go through and talk to it directly. So immediately these particular attacks, attackers, they tried to attack the JBoss server using Metasploit modules. So they tried using JBoss phone scanner, and they were ultimately denied. And the thing I'd like to ask about this, Derek. Whenever we do these types of assessments, it's kind of, at this point, a little bit of due diligence to try these various exploits against these services to see if there is an exploitable surface. And that really kind of gets into a weird place between a vulnerability assessment and a red team and a black team. But it is common for us to try to use these types of exploits against the services and also get denied with remote exploits. How often do you actually still see remote exploits successful in most organizations, organizations.

[C]

Today, from an external standpoint, it's not very often at all. I think actually my entire time at Black Hills, the times that I've actually used a legitimate exploit, internal or external, is less than 10. And I've been here almost four years now. And it's, you know, it happens, but externally it's very rare.

[B]

Yeah. So the next attack, default credentials. This is something that we do all the time. So for this one, I think that this particular customer had like an expense reimbursement reimbursement server and it was exposed directly to the Internet and you could actually access the management interfaces for that expense reimbursement server. And it's very common for us to find services, be it JBoss, be an expense reimbursement server, be it a JIRA server, whatever. We try a variety of different default creds. And just out of curiosity, I have seen in the reports that are reviewed, we have better success with default creds than actual remote exploits gaining access to systems. Your thoughts?

[C]

Oh, yeah. Especially when a third party implements something like a voiceover IP solution or something along that lines, and there's an external component to it and third party stuff, it seems like. I've seen a few of those.

[B]

Yeah. So yes, default creds definitely go after those. And I think this is one of those areas that a lot of pen testing, red teaming, black teaming, security assessment teams ignore. And there's a number of reasons for that. One, vulnerability assessment scanners, by and large, if you enable them to do password attacks against these services that are exposed, it's very, very, very common for that to lead to a lockout scenario reactively start Locking out domain account. Especially if these services are exposed directly to the inside of the network to active directory. The other reason why they tend to be ignored, because those plugins are usually disabled. They're not actively scanned for, so people tend to ignore them. So we see these default creds for many services that haven't been updated in years and they're still there. And that's generally because a lot of testers just don't even bother to test for them at all.

[A]

You referenced blackteam and some people are asking what blackteam is. What they're saying is John overloading definitions?

[B]

I am overloading definitions, of course. So let's go through the different teamings that we have. And it's funny because I have a slide at the end of this that I talk about all the different teams, but let's talk about it now. So a red team is where you're doing adversary simulation. And if we're going down the full technical definition of what a red team is, a red team will be technical, like external, trying to do attacks like we're talking about in this webcast. But it may also include physical penetration testing, electronic, trying to attack Zigbee, Bluetooth, wireless protocols as well, may have a physical component and possibly social engineering. Basically any means possible, try to get in. One of the issues with a red team, though is it's very much bound with a specific time frame. So a red team will happen within a two week period or a month period. And it's difficult with many customers because it's hard for a human being to know something like a red team is coming down the pipe on this specific date and time frame and continue your security posture as business as usual. Some customers do that, like the CIO will hire us to do a red team and they won't tell anybody else. However, it's also very common for CIO CTOs managers, when they know that it's happening, to basically get all of their security team and their network operations center together and say, all right everybody, we got Black Hills Information security coming in and we know that they're coming in these weeks. We need everyone to be ready. We absolutely, positively need to be set up. And no vacation. We got double shifts. And that that's kind of harsh because it doesn't adequately represent the security posture for the organization at all. So a black team takes care of that. What a black team does, it says, within the next six months we're going to attack your organization. However, we're not going to notify you, you're not going to know when we're going to come and you may not even know where we're actually coming from. So it changes that entire methodology. So it's no longer trying to work everything in, in a two week period. It's now spread out. And to be honest, black teaming tends to incorporate a lot more failure, a lot more low and slow kind of password attempts, spear phishing attempts where you maybe try to attack 10 or 15 users and then wait a few weeks and then try 10 or 15 more users a little bit later. So it's basically a difference in timescale in a purple team once again having way too many turns. Terms is a collaborative penetration test where the blue team, the defenders, are seeing exactly what's being done and then working collaboratively with the red team to develop better detects to identify the attacks that are happening more collaboratively. So does that answer the question?

[A]

Right. They didn't reply, but yes.

[B]

Next, attempt password spraying. And this is ridiculous. This is, is something that password spraying gets us into more organizations than just about anything in particular season and year. If you look at bhis shirts I'm not wearing.

I'm wearing a competitor shirt today that I got from a booth. But it's very, very common support for us. Yeah, we support all of our brothers and sisters in the pen testing community. It's very, very consistent that we have a password. Like right now It'd be spring 20. That would be a password that would be used. Now some people may have password complexity in play where they will not allow dictionary words, but they'll just simply change out like the winter the I and they'll change it to a 1 or something like that. And in this particular example, gained access to a Mr. Smith account. I actually think that was the account, Derek. I think it was literally a Smith account and gained access to finding that with a SharePoint server in this situation that had authentication tied directly into the domain controller where they could find that single password with that account. And the tool used in this situation was burp and then of course the season and year. So Derek, anything else to add on this one?

[C]

I have something.

[B]

Oh, we got some questions.

[A]

Frank says it should be. Yes, yes. Okay, we do have some questions. If you want to take a breath.

[C]

Of air, go ahead.

[A]

Oh, see, he's gonna change it. Frank.

Can we go back to some of the other questions?

[B]

Sure, let's go through some questions.

[A]

Okay. When you attack, when you attack, are you coming from one ip? Would it be easy to block that IP that is spraying for Passwords, such bars and no.

[B]

Yes, it would be. It would be easy to just block that single IP address if that's what we actually do. What we're doing now is we're actually working once again. You stay ready. Or Mike has released a tool that allows us to do password spurring via Amazon Lambda. Basically, it's not just coming from our IP address, but it's literally coming from Amazon. We've had additional tools that we've used in the past. Remember, Remux was one tool, reverse multiplexing tool that we used a long time ago. Or you could also use it. Completely lost it. What's the tool that spans up Amazon EC2 instances and then once they get blocked, it puts up another one. Proxy Cannon. That's it. Proxy Cannon. Thank you. You almost got it right there. So there's a number of different ways as an adversary or a pen tester that's doing adversary simulation that you can actually federate your password attacks from multiple different IP addresses. So, Derek, you want to add anything to that that I may have missed?

He's on mute.

[A]

Yeah, sorry, there was a lot of background noise. Derek, you're unmuted now.

[B]

Oh, there we go.

[C]

Yeah. So I guess that I have actually been in battles with the blue team on a red team where they were blocking IPs and it's just too easy to go through various means and get other IP addresses they're throw away through VPN services or something like Proxy Cannon. And then if we see that we're getting into that kind of battle, we just throttle it back. I mean, are you going to detect.

Attempts where the password spray is coming in every like 3, 4 minutes or at some random time?

[B]

And that's just. That kind of gets back to the red team versus black team. What are the time scales that you're going to be dealing with as well?

[A]

Lars is asking. He says he sees attacks from Amazon all the time. How do you defend those? Oh, looks like you'll have to come to part two.

[B]

Yes, you're going to have to come to part two. Part two, we're going to be talking about defenses. So we're going to go through this exact webcast. I know that this always seems like a cop out. Well, if you want the answer to that question, you're going to have to come to our next webcast. We'll see you then.

[A]

But it's going to be fun.

[B]

Then buy my book. No, but, no, we didn't have enough to actually put in the defenses in addition to the offensive components. So we're literally going to go through each one of these slides and we're going to talk about the defensive capabilities, the event logs that should be triggered different like I talked about casb, we'll talk about that and the ability to detect attacks against cloud services. So, yes, that is all coming. Okay, any other questions?

[A]

There are.

[B]

Yes, there are so many we're going.

[A]

To get rid of, but keep going because it's already 28.

[B]

All right, so the next one. There we go. There we go. Got Outlook web access with Mr. Smith. Now what's interesting about this is look at that jump. We may have grabbed the password from one service like SharePoint, but then we reused that same password in Office 365. Having that separation I think really helps for a couple of different things. One, it becomes really important whenever we start talking about two factor authentication bypass. You may have one particular service where you can enumerate user IDs and passwords, but you may not be able to use them on that service because of two factor. You would have to back up, find another service like Exchange Web Services or Office365 where that is not enabled. The two factor authentication is not enabled, where you harvest the credentials someplace and then use them someplace else. And this is very, very, very consistent with a number of the different attacks and the reports that I'm reading. And what we're doing on a regular basis is credential harvesting here, using those credentials someplace else. And this is pretty easy. I love this because when I was going through the report, Derek, it was basically the tool used. Yeah, just used a browser. Just log in. Don't try to get crafty, don't try to get tricky. Just log in to this, to this person's cloud based email and you now have access to their email. So anything to add, Derek?

[C]

No, other than, you know, once we get access to those other services, specifically email, well then we're going reading, Right, that's the next step.

[B]

There you go, setting it up for you. One of the things that we love is pulling down global address lists. And I found this really nice. I found this really, really nice. Like Elvis Presley address book.

I thought that was nice. We pulled on the address book the global address list and we're constantly trying to expand that attackable surface. We may have access to one account, but you use that one account, you download the global address list, you now have hundreds, if not thousands of additional accounts that you can go back and you can do that password spray against all of those accounts. That leads me to this There were five more people in this organization that were using the exact same password in this attack. Once you guys got access to the initial service, you went back, you redid the password spray and you got access to a whole bunch more accounts. And I'm going to fix this slide real quick.

[C]

I think all said and done, it was a large organization. I think we ended up having through various different passwords that were all really crappy passwords.

200 and some odd accounts, which is a lot of reading email.

[B]

Yeah, that's a ton of reading of emails. It's really weird. You feel kind of snoopy, like you're stalking someone because like whenever you're pen testing you gain access, it's just a shell. Whenever you're reading someone's emails, I don't know if it was you, but there was an assessment. I think it was one David was on where he shot me some screenshots. And some of the screenshots are talking about wire transfers because that's what the customer wanted us to look into as wire transfers. And a whole bunch of the wire transfers were actually wire transfers from this guy's personal account to buy a hot. And you're just like, oh, that is. So why are you doing that on your work?

[A]

I did get somebody's email on my phone once that felt real dirty.

[B]

Real dirty. Just. Oh yeah.

[A]

How we had to call the help.

[B]

Desk and like not the bhis help desk. Making that clear.

[A]

The client's help desk tricked them into like having me, who was not me, downloaded onto their iPhone and we didn't have the right information. And I totally did.

[C]

It was so terrifying.

[B]

Oh, that was social engineering. I get it.

[A]

Yeah.

[B]

Yeah. You always it found the kind of.

[A]

Dirty reading other people's other.

[B]

Yeah, you read through other people's emails, you find out who they hate.

[A]

If this actually was. They didn't. They didn't have that many things. Uriah had a question going back to what this passwords rank thing. Okay. Do you find yourself making recommendations for stricter passwords for privileged accounts when you can't win the overall policy? Would that help?

[B]

Oh man. Derek, what are your thoughts on that? Does it actually make things better if you're like, oh, we're only going to use long and strong passwords for administrative and everyone else can use crappy8 character passwords.

Well, that was fast.

[C]

So it seems like a good idea. The problem is if you have, let's say a tenth of your organization is it and they're all using great passwords but then you're in a situation where these non IT folks for some reason or another administrator on different machines.

Then I can still gain some level of administrative access. And if you haven't moved to Windows 10, I can then dump out that long complex password where an administrator is logged in and doesn't really make that big of a difference.

[B]

I think that gets back to a key theme. If you know the entirety of your environment, you're like, oh, these are the only accounts we need to be worried about, then it would make sense. But the fact is that these organizations are so incredibly complicated, it's almost impossible to identify all the different paths to domain administrator. Further, I think you were on a test live two weeks ago, maybe it was longer ago where you didn't get domain administrator, but you were still able to find highly sensitive documentation from the accounts that you actually gained access to. I think that that goes to show it's not an issue of always trying to get domain admin. It's many times an issue of what are the sensitive data and what kind of sensitive things can you do to that organization as well.

[C]

Yeah, we were just on a couple of weeks ago, had a client where we didn't get domain admin and they thought it was great. But we, we had two accounts, one that was an administrator across all workstations and another was an administrator across all servers. What did it matter? I could still go pretty much be admin anywhere besides the domain controllers.

[B]

Yeah, and that was a weird edge case. I think you had to explain it to me with crayons, how it wasn't that we were getting domain administrator, but it was a weird, weird edge case. Let's move on Looking for VPN instructions. This is something that I thought was great and this one's pulled right out of that report with tools like Mail sniper. Just simply SharePoint access or going through emails and trying to identify how do normal users access the environment. And I loved how there was like literally a part where you're searching for how to gain access to the VPN and it's like literally here's a document, step by step, instructions, download this executable. By the way, here's the certs for accessing the vpn. It was basically like it was completely laid out for you.

[C]

Yeah, it sounded easy, but it took like two days to get to that point.

[B]

It read really easy, but that is something I don't know. It's easy to find user IDs and passwords, but I think that getting those certs that is a lot more difficult to actually get those certificates whenever we're running things like Mail Sniper, it seems like once again, Mail Sniper is so useful for this. To be able to search for things like creds, to be able to search for things like password, to be able to to search for things like VPN certs. Yeah, I don't know. My battery was full. See if there's a battery charger on the floor for this. It's got a yellow tip right there. There it is right there.

There we go. Yes, the tip is yellow. All right.

Let'S see if that makes my computer happy. Yes. Whoa. I got bright really, really fast. All right, so it's not just an issue of just trying to once again gain access to a system. So but it's how can you actually gain access to that organization and use the built in different protocols and services that are available so far. I'd like to point out at this point no malware has been implanted on the organization. And that's going to be a theme that I'll start talking about from here on out. It's not always about exploit spearfish, gain access, drop malware on the system, get C2 and then pillage. If you can do that, great. That's awesome. But if you can get access to the environment through the vpn, if you can get access to the environment using RDP or Remote Desktop Protocol or Citrix or any of those other services, that's even better because the amount of detects that that organization is going to have for you coming into that organization are going to be a lot lower. I just basically pulled down Mail Sniper. One of the things I didn't do, and I'm trying not to do in any of these presentations is trying not to use any screenshots from the actual reports. So I'll go and pull down screenshots from our blog and put those in. And this is an example of Mail Sniper. You can see where it's invoked here. We import the module Mail Sniper and then you can basically do a search, invoke, self search, mailbox and we vladiannanobotninjas.com and you're doing a search for specific terms, password, creds, credentials. And you could add in more terms, right? Like you could do a search for vpn, you could do a search for certificates, you could do those types of searches and it'll pull back all of the emails that have those specific phrases or words in them. And then that allows you to kind of reduce or boil the ocean down to specifically the emails that are interesting to you as the. As the tester or an attacker can use to basically further leverage their access deeper into the organization. So Derek, anything to add here?

[C]

No, I was reading the audience questions. That'll suck your life away.

[B]

That'll suck your life away.

[A]

It's hard to pay attention to all the things because they are crazy.

[B]

So hard to keep up. So hard to keep up.

[A]

That's why I'm here. I can't keep up either.

[B]

So VPN access. Now you just basically log directly into the VPN server, make sure that you get an IP address on the internal network with the credentials that have provided to you. And now you're on the network. Now post VPN VPN access. You've got to start doing some recon to try to identify where you're going to go next for this. You can use built in command line utilities. You can use. Net user space forward slash domain. You can use NetView. You can use Power View to pull additional information. We should tweet out if someone can get us the link. HarmJoy has amazing cheat sheets out on GitHub. HarmJoy from SpectreOps has some amazing cheat sheets for using tools like Power View. If you just do a search on Power View cheat sheet harmdroy, I'm sure someone will post it up.

[A]

There we go.

[B]

There's like five or six cheat sheets that they have in their git repository. You should make sure that that's the right one. That's the, that's. That's not the actual cheat sheets, but that's okay. I gotta get. We gotta get a little bit worried whenever people start sending us links like here, use this tiny.

[A]

I'll just send it to you guys.

[B]

Just send it out. So it's awesome because there's a lot that you can enumerate. Like domain administrators, you can enumerate additional workstations, you can enumerate password policies. It amazing what you can pull down. This is where this starts to get a little bit hazy when we're talking about detection. Most organizations are trying to use just straight PowerShell logging and logging anytime someone's using PowerShell. That's going to be difficult in some organizations, especially if you don't do proper filtering on what's being done with systems administrators. We'll talk more about this detection a little bit later. But suffice to say, there's amazing utilities and tools to actually find additional access. One that I didn't talk about much here because I want to have a total webcast dedicated to. It would be Bloodhound and Also Death Star for enumerating the path to domain administrator. Now, kerberosting, this is by a very, very good friend of Black Hills Information Security, Tim Medine from Red Siege Security. They do a lot of consulting and subcontracting with us. We absolutely love them. Now Derek, with kerberosting, let me get this straight. You can actually pull down password hashes with kerberosting without having privileged accounts?

[C]

Correct, correct. All you need is valid domain credentials. You don't even necessarily have to be on a machine that's joined to the domain, use tools like mPacket M proxy your traffic through or if you're on the vpn, you're already there.

And just need valid credentials.

[B]

Yep. And you talked about mPacket specifically. MPacket's a collection of a variety of different tools. And the specific tool that you're talking about in mpacket is getuser spns Python, correct?

[C]

Yes, that's correct.

[B]

So now with that, this was weird. This organization had I think 800 different service accounts. How does that happen? How does an organization end up with hundreds and hundreds of different service accounts?

[C]

Oh wait, did you want me to answer that?

[B]

I was hoping you could because I honestly couldn't figure out a good reason. I've got an idea.

[A]

Brian says hard work, hard work.

[C]

So not good. Internal policies in terms of how to teams work together, how applications are integrated into the environment, you know, I guess you could take an approach. Well, one service account, if it got popped, then, okay, now you have, you know, less chance of administrators on different servers. But it turns out when you have 800, somebody's definitely going to have a crappy password. With Kerber roasting in particular, I've been, I've gotten domain administrator out of the gate just from cracking one of the, the tickets.

[B]

And also one of the reasons why, once again, looking at reports over the past few years, one of the reasons why I think you see organizations with these hundreds of accounts is just it's an old organization. You have a domain that basically goes all the way back to Windows 2000 Active Directory and then you upgrade it to 2003 and you keep migrating to newer versions and people don't ever really seem to clean up after themselves. So you see these accounts, these service accounts, and not all of these service accounts are used. Many of them are still active. They just set it up so it never expires, ever. And they still have the privileges that they had within the domain. But people just don't seem to clean up service accounts. They don't seem to clean up applications at all. So this becomes a great technique to try to gain access to the environment. Now the next one. I was really, really shocked when I saw this on a report that we put out recently. Group Policy Preferences and the passwords. And for this you use the PowerShell script, get GPP password PS1. And.

I think if we were like four or five years ago, group policy preference files, we would expect to see that. So let me explain what that is and then I'll have Derek talk about why we continue to see it even today. So whenever you automatically build workstations, you can use.

Group Policy Preferences. So it'll push down a policy to systems and it'll automatically configure that system to be in compliance with all the other systems in the domain work. And as part of that, you can push down a local administrator password to that system. Now, to be fair, the GPP file is actually, it actually has the password encrypted, which is fine, except for Microsoft actually released the key to decrypt it publicly. I think it was in a technet article. So you could basically gain access to any of these GPP files and then you could quickly reverse that password. Now, Microsoft patched this. I think it was. Was it 2013 or 2015, Derek, that Microsoft patched this issue?

[C]

I'm pretty sure it was 2013.

[B]

It wasn't that. It was, it wasn't like, like last week. But if they patched this, Derek, how come organizations still have these GPP passwords in use?

[C]

Because the patch didn't go pull out all the passwords from the XML files that they left that up to the reader, you know, because everybody reads all the knowledge base articles for all the patches, right?

[B]

I know, I do.

Go ahead.

[C]

I was just saying that. And then, you know, they don't change the local administrator password ever. And then, you know, speaking as a former systems administrator from a lifetime ago, I get, you know, if it's not broken, don't go fix it.

[B]

But this is pretty broken.

[C]

It's pretty broken, yeah.

[B]

Recap. Basically, the patch stopped new passwords from being basically used in that really easy to crack format. But all the old stuff it was incumbent upon the administrators to go fix on their own at this point. You got two admin accounts from gpp, you've got three or four accounts from kerberosting. We already have six accounts from Password Spring on the outside of the environment. So there's just a multitude of different accounts that you can use now to basically try to start using those creds you know, you start logging in with remote desktop and authenticating and seeing what you can actually gain access to, and then you use that also. At this point, one of the things we do in almost every single assessment, not every single assessment, but almost every assessment that involves red team or C2 pivot is establish a secondary command and control. Now, to be completely honest, a number of attackers wouldn't have established a secondary command and control server with malware outside of the environment. They just wouldn't. If you have the level of that we have at this point, you would generally stay with the protocols that you have so you can fly underneath the radar. But that actually gets into a fundamental shift of how you can look at assessments and how they should work. One of the key mantras that I always like to say at BHIS is our goal is to get caught. At some point, we desperately want our customers to be able to detect us. And the reason why is we want to be able to identify those clipping levels where the organization's security technology and their architecture is successful and it is in fact way working. We don't always want to approach every single assessment with, can we hack you now, to be honest, we do have customers that we do that, but they're rare. They're customers that have been doing this for a long time. They have a good security posture. We've tested them multiple years in a row. Then we switch into a full red team or a full black team to try to gain access to that environment. With a lot of just standard pen tests or red teams, you do want to identify the clipping level where someone could detect you. And unfortunately, in this situation, a number of determinations, different command and control channels were established, DNS, VS Agent, standard HTTP, HTTPs. And none of them were actually detected, which is a bit concerning. And we'll talk about ways to detect those in the next webcast. Now, you pulled the password hashes at this point. Honestly, Derek, I thought you were just being mean. Using volume shadow copies to pull basically all of the password hashes from the domain controller, the ntds DIT file where the password hashes are stored, and you pulled it from volume shadow copy. Now, why, why would, as a tester or an adversary, a quote unquote bad guy, why would you pull the password hashes from a domain controller using volume shadow copy?

[C]

Why would you go after the passwords altogether? Right? I mean, so to take a step back to what you were saying before about a secondary C2, it was twofold. One, we were a little worried that they were gonna figure out out we were VPN again. We never did. But we only had like two certificates for tied to whatever users we had and so we're a little worried about that. But we're also like on week three of the engagement at this point and.

We wanted to at least give the blue team a chance. Right.

But then why would you go after passwords? Well, this is a red team. We had an object like we weren't just going to go in and say oh look, we hacked you.

[B]

Haha.

[C]

No, I think they wanted us to go after some specific financial type information that was in their environment and we figured they were in databases so we were going to go after database administrators and for that we needed credentials and so we went to go get all the hashes.

[B]

And now specifically on volume shadow copy, as somebody that's doing abstract emulation, why, why wouldn't you just use hash dump for metasploit, Meterpreter or any of the PW dump tools out there? Why would you use volume shadow copy against a domain controller?

[C]

Yeah, so you know, using something that's, well, historically.

Using something that was in, you know, metasploit, you had to put like a get a session on the domain controller or use something that injected into LSAs. And I really, I didn't want to crash a domain controller, which I've done in the past. So use volume shadow copy to go get a copy of the file from the server because the NTDS DIT file is in use and you can't just go copy it.

[B]

And the likelihood of crashing the domain by doing volume shadow copies using Secret Stump is very, very, very low.

[C]

Yeah, and now I don't even do that. I just use replication services and Secret Stump and just go and stream it off the server. I don't log into domain controllers anymore.

[B]

Just pull it off then crack passwords. Now you were talking about eight character passwords earlier. What are some of the reasons that you think that organizations still are using eight character passwords? Because this isn't the exception. We're starting to see organizations eke up to 10 character passwords, but it's rare for us to see an organization make the jump to 15 characters.

[C]

So I think.

Unfortunately if you have a mainframe in your environment, chances are there's some overarching. Password policy in the mainframe only supports eight characters. Everybody thinks eight characters. We can't have two separate policies, one for your mainframe password and one for your domain password. Because that would be crazy, right? We could never make an exception for any Kind of policy because we're in 100% compliance across the board anyway.

[B]

Yep.

[C]

Yeah. No, and you know, I think this particular customer did have a mainframe and it was just a cultural type thing. Other organizations we see it's just a fight, they can't because the operations folks just, they just think, oh my gosh, now I have to have an 18 character password policy and it has to have, you know, an exclamation point and some numbers and letters. It's got to be complicated character set. And you know, it doesn't.

[B]

And one of the things I talk about in the notes and by the way, for this webcast, every one of these slides has full notes, sans like literature style. One of the things I talk about is the NIST Green book series. You know, I keep talking about that. That's something. Back in 1984, they developed a policy that was released in 85 that said eight characters. Oh, it said eight or nine, but at any rate, everyone read that to be eight characters. And they got picked up from policy to policy to policy to different audit standards. And we still see it today. And I think also people get attached to their passwords, like they love the fact that they used a password that was their initials and then their last four, their Social Security number in college. So they just keep using things. Yeah, right. They just, you know, they keep on reusing those again and again. And it's funny how many organizations have fought this fight for years to try to increase the password complexity. And people are always like, management is always like, well, prove to me that an attacker can do this. And then when a firm comes in and does prove it, then it's like, okay, well now we've got to change it. And they maybe go to 10. So it's funny to see how password complexity is eking up and then search and plunder. And I didn't get into a lot of details. You were talking about database servers or old legacy systems. And honestly, this is the goal, right? Anytime an adversary is coming at your organization and they're a targeted adversary, they have a goal and objective. When you're doing pen testing, red teaming, black teaming, there should be a goal and of what you're going to use all this access for, to gain access to something sensitive and different tools. You have Sharefinder, Mail Sniper. At this point, with 70% of the passwords of the organization, the entire organization is effectively owned by the adversaries. And if it gets to this point, that's what we call a really bad day at that point. So A special note on Chris Nickerson. I noticed that Sierra brought up Chris Nickerson's Twitter earlier.

[A]

Just a little while ago, somebody, somebody.

[B]

Somebody pointed out and Chris was like, I'm going to call you out if you don't, if you're going to use red teaming and you don't have physical social engineering electronic on this one. So we didn't cover those. And one of the reasons is we're at 1152 Mountain. This is going to be a series, right? So the next webcast is going to be all about the defensive components that would have made our lives completely difficult. That's going to be increased password complexity standards. That's going to be two factor authentication on absolutely everything. It's going to uncover identifying services that are no longer being used or service accounts that are no longer being used and disabling those. Also JP Cert, we're going to talk about what event IDs are going to be triggered in which situations. So we want to break that up. Some components will be broken out into dedicated sessions. So there will be a dedicated session for just the physical pen testing and social engineering. Sierra talked a little bit about social engineering, feeling creepy about getting people's email and getting access to it. So those things are absolutely on the menu. And it's hard to cover a whole engagement in just a one hour webcast. But we absolutely love Nickerson. We love Layers Consulting. They're one of our sister pen testing firms up there with trusted SAC and in guardians and secure ideas. People that we work with very regularly and we chat with all the time. In fact, I think Nickerson is coming out for Wilder's Hacking Fest. Is he confirmed he was here last year. I died.

[C]

I don't remember.

[B]

You don't remember all of this stuff off the top of your head?

[A]

No, I don't, John. So much stuff.

[B]

So much, so much is to be going, going on. But do check out Chris next time he's presenting someplace. All right. Now one of the final things I want to call everyone's attention for, and this is something that's going to be tying into the next webcast is I'm not going to be talking about one specific technique to detect and stop each individual adversary point. And that has a lot to do with whenever we discuss defense in depth over the years, over the decades, a lot of people took that to mean just spending a lot of money on defense. Like you have AV everywhere. Well, we got 100,000 endpoints with AV. That's a hundred thousand AV engines. That's defense in depth, right? No, it's not. So we're going to be talking about for each component, how can we overlap multiple views? So if we dropped an agent like VS Agent, an implant on this organization, we should be able to detect those. By we, I mean blue teamers should be able to detect those with Endpoint antivirus user behavioral analytics, we'll talk about JP and logon tracer, netflow analysis, SIEM specific event IDs that you can focus in on and of course, endpoint firewalls. So having multiple different components for each one of our different attack steps or attack tactics, how you can actually detect, respond and stop these different components of what was being used. So that's what's coming up next weekish, maybe the next webcast. So be on the lookout for a invite coming out for the next webcast is going to dissect this. We're not going to spend as much time talking about the attack. We're going to spend a lot more time talking about the defenses and detections associated with it.

[A]

It'll be fun.

[B]

Pen testing what we do. Black Hills Information Security. Go through this quick. Pen testing, web assessment, mobile apps, Red Black, purple hunt teams, mergers and acquisitions assessments, webcasts. And of course I think we do security memes better than just about anybody out there. I think that we're. I think that's one of our core competencies. Absolutely. I think we rock with that gift. Tweets also want to say thanks. For those of you that are new to this webcast, my name is John Strand. We've got Derek on as well. We've got Sierra. Behind the camera is Brianna and I'm associated with Secur Weekly Ions Active Countermeasures Sans Institute, Black Hills Information Security. And I literally look like a NASCAR driver with all the patches and all the things that are going on. So here we are. Do we have any final questions before we wrap this up?

[A]

We had so many questions. I'm sorry I didn't get all of them. I tried to hit the ones that kind of fit in as I could like keep up. Send me an email sierrahis co if we didn't get to your question. Thank you for everyone that was on first time. Thank you for everyone that was on multiple times. If you have a BHIS webcast punch card, punch it again.

[B]

We'll see you on the next one. Thank you everybody. Take care.

[A]

Bye. See you.

[B]

Derek.

[A]

Thanks for joining us on the podcast version of the Black Hills Information Security webcast. See you again next time.