Webinar - Fantastic Attack Types and How to Find Them - Exabeam

Webinar: Fantastic Attack Types and How to Find Them

Webinar Transcript | Air Date April 12, 2022

Watch the Webinar | Read the Blog Post

Jeannie Warner:

Thank you all for joining. We will get the webinar started momentarily. Feel free to get yourself a tasty beverage and a comfy chair. Hello, everyone. We are so glad you could join us today. We will get started shortly, but I want to cover some basic housekeeping information. Today’s webinar is being recorded. We will email you a link to the recording after the live event. Secondly, we hope to have time for QA at the end, so please submit any questions on the sidebar.

 You’re welcome to ask as we go in chat but in case we miss them, we’ll review at the end. Thank you. We will start momentarily. Welcome to our webinar, Fantastic Attack Types and How to Find Them. I’m Jeannie Warner, director of product marketing here at Exabeam. I’m joined by Randeep Gill. Next slide, please. Randeep and I both have a background in beast hunting. I started off my life as a NOC operator and then a SOC operator and built up IBM’s MSS for … Oh gosh, I was nine years there. I’ve also been a global SOC operator. Meanwhile, I’ve also worked for fire walls. I’ve worked in application security. I’ve worked in CASBs. I’ve worked in endpoints and identity, kind of all across the beastly range. And this is Randeep.

Randeep Gill:

Thanks, Jeannie. I’ve also been a beast hunter. I started life as a IT helpdesk person. Once I started there, moved into working in a busy SOC, protecting the global organization, monitoring their firewalls and endpoint products as well as network devices. I’ve been a dedicated network engineer and I’ve moved into the vendor world, went in detail on EDR products and back in Exabeam.

Jeannie Warner:

Next slide, please. What we’re going to do is we’re going to talk about some beastly timelines here. We’re going to say roughly everything that attacks you happens in a very similar order. And we’re going to review that for a number of different attacks that have happened so that you can see and hopefully be comforted by the consistency of them that will take away your fear of the unknown unknowns and zero days to say this is the tool set you need and this is the methodology you need in order to find them. Let’s talk about footprints next.

Randeep Gill:

I think before we get started, I think it’s important to know that there’s four real things that happen just about every time when we see these beastly attacks. I’m going to pick on some of the key ones here and we can almost reflect upon a lot of these together. Malware dropper, as we know, these are sneaky beasts. We often see them hiding with free utility programs or part of Adaware or more sophisticated Trojans to avoid detection.

Some of them even take advantage of known vulnerabilities, and we’ll see that little bit later on, and bury themselves deep in the file and folder systems all across your network. Sadly, for us, droppers, as we’ve seen, can be spread through many mechanisms such as emails, malicious links, drive by downloads, or even simply the flash drive. But the most important here and one of the four is all the biggest data breaches have involved potential credential theft.

When the attackers leverage some of the credentials to gain access, they take the credentials that are phished from a company and they actually impersonate the employee and escalate privileges often laterally moving across the environment in some cases and creating phantom accounts which really leads to the next two points. Once they’ve established persistence, we’ve seen that they can open up command and control, drop payloads, execute programs, do whatever they like to ex-filtrate data. As a result, what we see is IT over time. We find ourselves spending huge amounts of times performing the same task to remediate. We’re looking for footprint and various solutions in our stack to build a picture. We may even patch or remediate or scan for vulnerabilities. Jeannie.

Jeannie Warner:

Well, I wanted to add one little piece in there and say there’s always going to be somebody sitting in the audience that says, “What about application security attacks too?” The Panama Papers was literally somebody went in, did a path reversal attack, went on down at a sequel tech, get it. But in the end I can attack through a website as easily as anything else if it’s a badly built website or sorry, insecure set and DevSecOps, but in the end of it’s all about the credentials. You’re absolutely right on that. Let’s go to the next slide.

The timeline is what matters to us most as I mentioned earlier. I love talking about the order which things to happen is discovered through disclosure, either responsible or irresponsible disclosure is roughly the same. Some clever researcher, white hat or black discovers some commonplace part of an operating system, firmware, website, operation, process, et cetera, it can be used for a purpose other than which it was designed. Responsible disclosure could have that person contact the organization that manufactures that software or hardware who would then presumably respond with an update to patch. It’s a beautiful system, what goes wrong? What if that company or the email or vulnerability gets ignored or gets no reply or something else, let’s just call it unhelpful. Or the vulnerability is not fixed within a reasonable timeframe. Right now they say 90 to 180 days is the super generous. Ideally 60 to 90 would be more ideal or the person who discovered it feels that telling the public will force the organization to fix things.

Ideally, every software or hardware company will have a standard methodology by which people can report bugs or vulnerabilities. But we all know that when somebody publishes an exploit POC, everyone suffers. Scanners get updated with bad things like lightning, and everybody’s checking to see, oh, do we use that vulnerable thing there’s an attack for? Most companies are also pretty fast to push workarounds and mitigations and then patches but again, as we said in the last slide, somebody you just created a lot of work for the IT team, especially security operations. I want to pause and point out that many people who work in security operations did not start their life out as programmers they started working in desktop support, network ops, or just proved to be curious methodical and good at communication, which is honestly more important for security and the job that they’re doing than knowing how to program. Next slide.

Randeep Gill:

What I really want to do is look at a recent beast. Isn’t this crazy Jeannie this exploit is a bypass of the old fix from 2010. What do we know about the SpringShell? What we know is this the spring beast affected functions that user request mappings Java objects within this spring framework. The pop code creates a controller once loaded into Tomcat that can handle HTTP requests. What’s really clever with this piece is the attacker can then change a default access logs to their choosing. The attacker can then send commands and actually insert code into this field. But vulnerability in spring results in a client’s ability in some cases modify sensitive variables inside the web server by carefully crafted HTTP requests. Now, as we saw at the end of this, what were the real remediation steps. There was checks made with the Java toolkit version nine, firewall IDS platforms where enabling TLS inspection for the various vulnerabilities even same for [inaudible 00:08:04]. At endpoint eventually was checking for signature behavior.

Next. We just talked about some of the remediation steps at the end there by the individual toolkits. This is not unusual. Often we find ourselves looking at various footprints within the security stack independently pivoting from one toolkit to other to retrospectively build a story. However, if we use the IoC approach to determine how to get to root cause, we find ourselves spanning our search across various stacks automatically. Now let’s take these four IoCs, for example. We can start to ask those questions across those IoCs automatically. For example, do I know what users normally use RDP? What is a normal time of access for that RDP? What is normal for the accounts creations in a department or an organization? Is it an unusual time to form a specific type of cloud or application activity? Understanding normal is essential along with visibility in the type of logs that we see. Next.

Jeannie Warner:

This one is all about me because log4J was a total weekend killer for me. Dropping a POC for an exploit on a Friday gets you to that special hot place even if you apologize later and they did to be fair. Log4J is a simple Java based logging utility proving there is literally nothing out there that cannot be used for ill if it is not kept up to a date and occasionally examined. Apache put out a patch, and exploit hit. Apache put out a new patch and then another, but in the way of things, there was a process to discover important questions that every SOC gets asked in rapid fire from all directions, even by savvy executives and security pros. First one, do we use this thing, Apache Java? Yeah. As of last year, Apache was somewhere between 25 and 35% of the market.

That’s 25 to 30% of every website you’re going to visit today probably has something of Apache in it. That’s a quarter to a third of all UIs and portals too. They’re going to ask what version you’re on. This is where SOC and IT start to have a long, long talk. Is that the vulnerable one is their next question. Can we do the mitigations today? Is there evidence that somebody else has already compromised us? And then the last question they said is what do we look for to keep from being compromised today and tomorrow? Next slide. Naturally, your beast hunter advice is if you find it put in on a watch list immediately and patch the bots and system, but you also need to check for past infestations. It should be reassuring to anyone how quickly security people post everything they know about how to scan for boxes or vulnerabilities online.

 It’s just as good for the good guys here as it is for the bad guys. Now, this slide shows a quick cut and paste query for how to look for log4J processes in your environment. This image below that is a snapshot of what it can look like if you find it and this was from a live search we did. This answer you can say, we do use log4J it’s right here. Now Randeep’s going to walk you through the next slide which is how do you do detections of have we been attacked or have there been infiltrations.

Randeep Gill:

Thanks Jeannie. As you can see on the slide here there’s certainly a lot of footprints there. Rather than looking at singular instance as we mentioned before, or alert space of detections, we can actually adapt our thinking to ask key questions based upon the source. Let’s look at the network traffic or a network device. We can ask, well, are there any new abnormal connections to a new geolocation? Is there traffic now persistent on a new port, maybe of a EDR tool or endpoint tool? Was power used by a cmdlet? Was ping used abnormally. And from a traditional side, if you’re getting an abundance of security alerts, is it the first security alert for this asset or actually for this organization? Next.

Jeannie Warner:

I was going to say it is not necessarily over at that point. Let’s look back one year to Solorigate. That was a big scramble of overtime fund as well. SolarWinds for anyone living under a rock is this awesome network, asset management monitoring software. Even in a SOC couple different times we used it. We’ve used it at more than one company I’ve worked for. What happened here was that in a clever attacker said, hey, why should I bother trying to attack 2,000 companies when I can infect the file at the source? Microsoft Threat Intelligence Center named the actor behind the SolarWinds, the SUNBURST back door teardrop malware called them NOBELIUM which I think is far too noble a name for the jerks who did it. They dropped malware at the source so that when people downloaded SolarWinds, Orion platform, DLL, they got a Trojan horse inside their proverbial gates. SUNBURST launched a golden ticket, which is credentials, attack against the active directory.

They got super user credentials which then spread across the network and unexplained Azure active directory activity, which had never been seen before. The Trojan laid low at first and then it for a while a month later reached out to contact a command and control server using a sub domain generated from information that it had been quietly gathering inside. It actually was cool in a bad way, because it added a unique sub domain for each affected domain. It was sheer elegance in the evil simplicity for evading antivirus and endpoint software. You had to see the traffic to the domains and identity stores and recognize what was happening was new unique and undesirable. But as you can see, once the CNC server has the legitimate super use group credential, the network is pretty much honed and it was honed a long time before discovery. Next.

Randeep Gill:

Hold on, Jeannie, this definitely isn’t over. Once you’re already compromised Look actually what else can happen in here. Once [inaudible 00:14:02] and a back grow is open I can connect to command to controls, send remote command shells, download further payloads, exfiltrate data low and slow. Definitely something that we should notice. Before we go on, I want to go back in time for a moment. Next.

Does everyone remember APT28 and 29. Let’s take a look at order of things before we move forward, which also seem consistent with what we have talked about so far. In the recon stage, beast used various reconnaissance constant methods to determine the best attack vector for compromising their target here. Some of these in this case for network vulnerability scanning credential harvesting, as we’ve seen before and using doppelganger domains. The weaponization phase was key. They used malware called OnionDuke to wrap around legitimate files like RTF files and also flash code to circumvent security controls and delivery actually was through traditional methods, spear phishing, in this case, where they were able to send links to the end user to open up and gain access to the environment. The exploitation took advantage of common vulnerabilities, which were eventually patched. However, once the attackers gained persistence, they were able to send command control instructions and start data exfiltration. But we aren’t finished. Are we yet?

Jeannie Warner:

I want to add in here, there’s also a social angle of the attack. I don’t want people to hate on the victims. Nearly anybody can be manipulated into giving up data they should not from names to type of equipments they use to the security stack. I could, putting on my black hat probably pose as a sales agent and bluff my way up through the CTO and chief architects through a series of phone calls and questions. I can do spear phishing from there and convince people to open my emails with a phone call. A lot of times you’ll see people blaming, oh my gosh, somebody clicked on something. I want to be fair and say, people are really clever and vicious with the social angle and please don’t hate on the people who accidentally clicked on a bad link. There’s literally almost nothing they can do to stop somebody who’s determined to do it. Next, please.

 The truth is you probably have most of what you need for a stack. I want to pause here for a second and say we just kind of dumped a lot of information on you. Does somebody have any questions out there in listener land? Okay. You probably have most of the stack you need from servers to endpoints to applications, domain controllers, all of these things have the ability to log what is going on. Every organization is invested somewhere in security technology of one kind or another to monitor what’s going on. Maybe they use a network taps to host an endpoint based detections. Web SAS vendors have APIs you can investigate to look at the traffic. All of these things are important. Let’s move on.

Randeep Gill:

That’s a great point, Jeannie. Actually, all these items in security stack investments, their key indicators or footprints as part of the Beast Hunter’s investigation, they offer various insights as part of the hunt. As however, as we will learn, they need to play together to see the true footprints of a beast. Next.

Jeannie Warner:

I am loving these days that almost every security vendor out there is starting to map to MITRE. MITRE is my favorite. The MITRE attack chain TTPs cover just about every clever technique that can be used with sub domains and sub attacks within the lists. Most of the vendors are starting to offer up maps of the coverage that their products offer. Allow me to take one moment and say, no one vendor covers everything. That’s the point of having your security stack to increase your coverage end to end of the MITRE stack. The point of all these detections and capabilities is to arm your security operations with what they need to help you out for all of the zero de-beast we’re talking about. Standards, methods and processes are your best friends. Next slide.

Randeep Gill:

We’ve all been here. A recent study shows that the 70% of analysts time is spent in detection, triage investigation. What are the real problems that we all face. With the detection side, we’re constantly editing and refining false positives and keeping up with new attacks which are often missed. When we look at triage, where analysts are forced to pick alerts of key interest and ignore others and investigation we’re taking a lot of time to pivot to different console, different toolkits to find root cause and build a picture of what has occurred often taking hours or days. And as a result, we have inconsistent responses from analysts leading to missed and incomplete investigation remediation.

Now using analytics, we can start to automate and use the behavior analytics piece to remove the overhead and tuning rules and detecting unknowns. We can also use the key alerts and actually use behavior analytics to look at risk within environment. We can create timelines automatically showing that we can use all those footprints and all the investments that you’ve made to work together for every single assets or user within the environment. And thus, as a result, we can refine those playbooks with minimal time and effort. Next.

Jeannie Warner:

I was going to say, if you wouldn’t mind clicking through, I think there’s more of the image here. There we go. Ransomware persistent.

Randeep Gill:

My God, it’s an old beast this one. I need some time with this one so I’m going to take a deep breath. Did you know that ransomware beast have been ran since 1989? I also remember crypto locker variant was first used in 2013. And nowadays, as we see there’s ransomware as a service, it’s still prevalent offering opportunistics, even first time techies prebuilt kits that they can buy with minimal technical knowledge and actually get a subscription and a support and form advice. I’m going to do a brief breakdown of some of the items there that we should be aware of and some of you probably are. The distribution side looking at a way of distributing the payload as we’ve seen through phishing campaigns, water hole attacks, exploit kits, drive-bys and infection is really once the dropper is on the system running executables to stage the first part of the malicious intent. Once they’ve established persistence they’re scanning and enumerating across the environment and thus the encryption starts and boom payday.

Jeannie Warner:

I remember reading in the news paper the JLA Piper that people were walking into their office with a big sign that said, please do not plug your computers and turn them on as they were getting hacked. 1.5 million was the estimate of how much money was spent by that IT department in overtime.

Randeep Gill:

Wow. Next. How should we and can we review this problem? We can start to use analytics to help hunters like ourselves identify key behavioral patterns throughout environment and create holistic pictures of an emerging threat and possible attack scenarios. Let’s look an example. Let’s be really open about this. How to quickly identify compromise user, for example. Never seen before file execution or abnormal network activity while mapping these seamlessly into one single timeline. We can also use the behavior modeling piece to automatically understand what is normal versus abnormal with the environment. As a result, we can start to identify these changes and subsequently defeat the attack hopefully. Assume you’ve been breached, post-infection, what other things can we do? Planning is key for this. We could implement seamless playbooks to triage and attack or prevent. For example, orchestrate actions or isolate a host, killing a process, blocking an IP address or prompting the use for additional authentication to help limit the scope of the attack. Next.

Jeannie Warner:

Okay. Let’s pause again for a moment. Does anybody have any questions on that? All right. I like talking about the four beast how they do because in the end many comes and asks me remember those four questions of, do we use this in our environment? Is it vulnerable? Have we had any evidence that it’s been misused? What’s going on? These handbooks that you have, as we talk about are basically the same. You’re going to search your data lake or log file stores. You’re going to look for anomalous behavior. You’re going to hopefully have a remediation playbook, which this is what we’re going to do every time if we find it. And last time I’m going to talk a little bit about threat intelligence and how that can help everybody. Moving on, maybe you’re looking backwards. As we’ve said, maybe all you have are known footprints.

This is the stuff that you looked up on the web that I said earlier. Everybody goes out there. What do you scan for? You can find that through some friendly Google searches or any of your security vendors should always say, this is what you should find and look for. This is where you look it up. You’re scanning to see is the beast present? Is it vulnerable? I might scan for hashes or indications of compromise, which is sources, destinations, port used for the first time, et cetera.

I’m going to scan for new credential activity. New user IDs. Because there been a privilege elevation, stale credentials and by stale credentials, did somebody create a user three months ago that has never done anything until suddenly that does something today? That is absolutely an indication of possible compromise. I also like scanning a big files going out and unexplained places or any weird email activity or any weird port, 25 activity, things of unusual size, rodents of unusual size going out through your firewall. All of these can be indications of attack. All of that is most important in knowing what normal looks like. Let’s move on.

Randeep Gill:

Absolutely 100% true. The importance of understanding normal is so key here as mentioned in the prior slides, knowing what our normal network operating system devices look like and users look like on a day to day basis is critical to understand our security posture, thus risk. Without this baseline knowledge, we are blind to the possible abnormalities and the beast we have understood thus far. Next, in addition to that and in compliment to that, the importance of different log sources working together is imperative to provide you with a chronological timeline of events. As a result describing anomalous activities events mapped together against even MITRE TTPs if you so like. So this example, we see lateral movement for this particular user and we also see privilege escalation and persistence across various accounts as the accounts switch to access a particular server. Next.

Jeannie Warner:

Oh, I like this one because this is very much a, when I was running a SOC globally, I got people of all levels of experience. Maybe they had been somebody’s babysitter. Maybe they’d been a desktop support person, whatever it is, sometimes they all get a job and how do we train them all to do the same thing every single time. This matters a lot. This is huge about saying everybody has a different skill, a different ability, a different talent. What I care about is can they communicate, do they read and understand? Do they have the ability to do other things like for years, SOC used to see only things in the network and perimeter. IT architecture tended to handle anything that had to do with the domain that had to do with the passwords or identity in any way. What we’re starting to see now is building the right checklists, calling an incident type of category and saying, hey, new person, Jeannie just finished training you last week. You got something exciting on your bowl this week. This is step by step what you need to do.

Prescriptive step by step guidance can help even new baby, say baby SOC person, baby beast hunter coming out and learn how they need to do it. And have you done this? Have you scanned for this? Have you looked for this? Is there any of this? All of that guidance is important for the new person of understanding how to do their jobs, especially if, and without a molecule of malice, this has been outsourced to a team maybe in another country that has never done this particular skillset before, but they’ve done helped desk for other things. They know how to troubleshoot. This is how we teach them how to be beast hunters. Next. In our instance, Randeep, we had the ability for you to customize it. Talk to them a little bit about that.

Randeep Gill:

I think this is really, really key. I think the important thing here is allowing the beast hunters, us, the flexibility to adapt to the environment. And every environment is different and provide a platform through which customizations and automations can be achieved. In this case, using our action editors to modify and adapt different actions from different API requests, different log sources that we see here. Next.

Jeannie Warner:

I was going to pause on that for one moment and it’s okay we can go to the new slide, but say, let’s say something that next step in line is scan that box and maybe Jeannie doesn’t know how to scan or doesn’t have any of the scanning tools. There ought to be a way that I can immediate click the box, maybe open a ticket up so Randeep on his team can then go take and do it because Randeep is my scanning god, it’s just a step that needs to happen and he’s the one who’s going to do it. But that’s what we mean about checklist and making it easy. Now, I love threat intelligence because threat intelligence, you can gather it yourself, you can pay somebody to gather it for you. You can use different teams. OSINT is an open source feed. Zerofox is an excellent new source that we use at Exabeam one of sources we have of pulling it in saying, what are the known bad domains? What are the known bad IPS? What is the list of commanding control centers?

Gathering from all of the different locations of every threat team, every CCERT to every different organization that puts these all together. It’s got to come in here and aggregate and look at it and bring in those indicators that compromise such that if it’s in your tools, for instance, if it’s in your SIM, your XDR tools, you can say, ah, this is a known command and control IP that is suddenly Randeep’s computer is connecting to it. I think Randeep might be compromised and suddenly I’m going to change his risk thereby automatically. And that’s the beautiful thing about automating, but at the very least, maybe you don’t have this automation maybe you’re still putting it all together.

I highly recommend going out, finding your favorite at sources of these and bringing them in. Even for those of you that are just saying, look, Jeannie, I’m on the IT architecture team. I have control of nothing. I only manage IDs. Have you ever run across the, haveibeenpwned.com database to say these are the list of the 10,000 most common passwords that people used. Can you run the files of your password list and sure that people are not using adminadmin, as somebody may be down in Equifax and Argentine was doing on their website.

Let’s make sure that these are not commonly being used, that nobody has the default admins, the default passwords, the default pieces on all of this is stuff that you can look up yourself, but threat intelligence services, if you can automate it, it’ll save you tons of time. If you can’t automate it, please be aware that they exist and you can look for them as you’re doing your beast hunting activities. I think that’s kind of a lot of pieces altogether. We’ve gotten to the end here. Pausing a moment here. We’ve just thrown a fire hose of information about this. Do we have any questions out there?

Somebody actually did say on open source threat intelligence, anybody can get to osintframework.com O-S-I-N-T-F-R-A-M-E-W-O-R-K.com. People who do development should be also intimately familiar with OWASP, which is the project. I’m going to say it wrong. It’s the open source web security, but basically what are the 10 most common ways people hack your website? I will also say, please, don’t forget to do your pin test regularly. If you’re not checking your code before pushing your live, you probably should. Ask your dev team for the last couple that went by the log4J if they have any kind of do they do library checks, do they have anything, software composition analysis, SCA tools. There’s a lot of really good ones out there. Just ask if they’re using this and this also kind of opens the first part of the communication you may have between your SOC and between your development team and between your identity and IT architecture team. And that triumvirate of love, I think could be its whole webinar of how do you make it work better together because that’s huge.

Randeep Gill:

I see a follow up question there Jeannie, are there any other sources besides MITRE that we recommend for threat modeling? I think Google is your friend in this case, but I’ve personally used, there are quite a few, STRIDE, PASTA, CVSS, CWE are pretty useful attack trees and vast. There’s also security card and probably a lot more. But for me I like MITRE best because more security vendors are mapping to MITRE now and being consistent so that’s pretty much my personal favorite. What about you Jeannie?

Jeannie Warner:

Well, I wrote a first thing for when Microsoft was first saying, are we going to map our stuff to CVSS? This is the common vulnerabilities go in system. I like it because it’s useful for vendors to say, how dangerous is this? How much attention do you need to pay? And sometimes this is a small piece and what it gets access to is not very big and in your environment, it might be a all right, I’ve done all of my math and they have really neat math sheets so you can go in and say, I use it here I use it here and they will give you a score and it’s between one to 10.

If it’s a three, maybe you put it in somebody’s backlog of events you need to work on. If it’s a 10, holy cow, maybe that’s a drop everything and get your team to look at it today, please. Part of that is between maybe you have a, if you’re a hospital with a patient portal and something comes up and it’s a 10 and is going to affect whether your customers can actually see their doctors do it today. If it’s something on can your marketing team send out their emails your marketing team can probably wait a little bit longer. They’re that kind? Sorry, marketing. I don’t see any other questions. Do you see any?

Randeep Gill:

I don’t. No.

Jeannie Warner:

Oh, clearly we were gods. Thank you everybody. We really appreciate the time you had and that you shared with us today. We look forward to having you on future webinars. And as we said, you will get out of this, both a blog that we wrote on a 10 fantastic attack types. We are also producing a root force solution brief, which we will follow up and also send you as soon it is done with somebody making it really, really beautiful. Thank you so much for your time today.

Watch the Webinar | Read the Blog Post