Investigation Scenario 🔎

You received an alert referencing an exploitation attempt against Apache (see image).

What do you look for to investigate whether an incident occurred and what was affected?

Assume you have access to whatever digital evidence source you need.

#InvestigationPath #DFIR #SOCAnalyst

What do you think are the qualities of a good logging source (in terms of the data itself)? For example, good logging sources...

...have timestamps that indicate timezone

...are structured for easy parsing of individual fields

What else?

#DFIR #SOCAnalyst

Investigation Scenario 🔎

While hunting through O365 logs, you discovered the depicted entry related to one of your user’s mailboxes.

The user is on vacation for a week and unreachable. What do you look for to investigate whether an incident occurred?

Assume you have access to whatever digital evidence source you need.

#InvestigationPath #DFIR #SOCAnalyst

This week's scenario presents a good opportunity for forecasting... thinking through what other events might have happened if the scenario event was malicious OR benign.

The User Agent string is trivial to set or change for anything sending data over HTTP and related protocols. There are many reasons why you might encounter a blank one. For example...

- A malicious script

- A misconfigured script

- A misconfigured proxy or logging error (more common than you think)

- Malware downloaders

- Malware C2

- Default behaviors (this is the case for PowerShell's Net.WebClient.DownloadString).

- and more...

From an investigative perspective, you might want to start by understanding what was transmitted (but not easy since I said no PCAP) or locating and assessing the disposition of the process responsible for the network traffic. There are lots of good ideas for doing that here: https://twitter.com/chrissanders88/status/1630953588582129664

Once you've identified the responsible process, you can begin understanding its function. We've talked about that here a lot... searching threat intel for the hash, sandbox output, org prevalence, user role context, file source, and so on.

Lots of folks mentioned profiling the remote host based on reputational threat intel. Plenty useful! But, often not something that'll help you establish disposition on its own for a case like this.

I chose this response from @JoeSchottman (on Twitter) as my response of the week: https://twitter.com/JoeSchottman/status/1630779645518831616. While it's only one thing to look for, it's a valuable insight into the types of hosts where you might see this behavior and a quick path to potentially proving a benign disposition by making a phone call.

By the way, I mentioned logging errors... what are some ways that logging errors might obscure actual event information in a manner detrimental to an investigation? Something to think about...

New Investigation Scenario next Tuesday! 🚀

#InvestigationPath #DFIR #SOCAnalyst

Investigation Scenario 🔎

Proxy logs indicate that a host on your network made a few HTTP requests with no User Agent string (the field is empty).

What do you look for to investigate why this is happening and whether an incident has occurred?

You don’t have access to PCAP, but you can use whatever additional data sources you like.

#InvestigationPath #DFIR #SOCAnalyst

A few thoughts on this week's #InvestigationPath Scenario...

You're focused here on whether an incident occurred, and you start with a process name that you know executed. That opens up lots of doors! You could quickly pivot to lots of other artifacts (file hash, parent process, execution location, executing user, and so on).

Probably the most notable thing here is that sqlserver.exe is not the name of the actual SQL Server process from Microsoft... so we've perhaps got something mimicking a legit process name. That tips the disposition scale in favor of malicious activity, but more work to be done. It's always worth your time to Google file names even if you think you know what they are... shout out to @Dfendir_ on twitter, my response of the week who did that thing and found that the activity could be associated with a coin miner (https://twitter.com/Dfendir_/status/1628125705803337745).

When you find malware that might be relevant, you can look for other artifacts of that malware to see if it's present, focusing on things that are strong indicators and easy to find. Of course, the file name is abstracted from the file itself. If you can get the hash and search on that, it will be less abstracted and perhaps get you closer to the capabilities of what you're dealing with.

Beyond that, you've got lots of analysis techniques available:
- Have you seen it anywhere else? (Prevalence)
- Was it launched from an unexpected parent process? (Hierarchy)
- Is it making or receiving suspicious network connections?
... and lots more in the replies.

In this scenario, I also provided some superfluous information about the server sitting in the Amazon cloud. That lets you know about other available evidence (Couldtrail logs), but you don't need those to start this investigation. They might come in handy later.

Speaking of Cloudtrail logs... do you have assets in the cloud? Do you know what unique logging capabilities you can access from your cloud provider and what they can prove? Something to think about... 🚀

#DFIR #SOCAnalyst #Infosec

Investigation Scenario 🔎

One of your web servers hosted in the Amazon cloud launched a new process named sqlserver.exe.

What do you look for to investigate whether an incident occurred?

Assume you have access to whatever digital evidence source you need. Be specific.

#InvestigationPath #DFIR #SOCAnalyst

A lot of responses this week! In an ideal situation, you would know WHY the Jr analyst thinks Cobalt Strike is present on this system and work from that, but you don't know that here. So...

A few folks provided some great critiques on the approach. One recurring theme was that focusing on these specific file names was unlikely to yield results because most attackers will change those defaults. That makes sense... file names are abstractions from the file itself and are easily changed. However... they're also pretty low-effort questions to answer. I think looking for them is fine, but there are lots more things to be done.

Most folks focused on identifying more specific things they would look for from their research and experience. PowerShell artifacts, named pipes, and so on. As I've talked about often, whenever you have named malware, it's always a great idea to find specific known artifacts of the malware you can quickly look for. Pointing this analyst in that direction makes good sense.

So much of learning to be a good analyst is figuring out which investigation path to take... they are many in a scenario like this one. It's learning to spend your time wisely and when to move on to other things. Even some techniques that probably won't yield results, like looking for default named files, are so trivial to execute they're worth a thirty-second SIEM search. There are a lot of ways to spend too much time on this investigation. Focusing too broadly on information-dense evidence sources like PCAP/Memory analysis without specific goals in mind, looking for broader behavioral artifacts instead of CS-specific artifacts, and so on.

One technique I like here that doesn't get mentioned often enough is the strategic use of signature-based detection tools. We think of those tools for real-time detection, but they're super useful in a response scenario too. I'm mostly thinking about techniques like running Suricata against network traffic, YARA against the file system, and Chainsaw + Sigma Rules against the system logs. There's also THOR, which can match YARA + Sigma rules, among others. Those tools cast a broad net, but they're going to automate some of the analysis work and give you a place to dig in, absent some other lead. I'm choosing @danaepp on Twitter as my response of the week for mentioning how the Jr analyst can leverage existing detection rules (here with Velociraptor + YARA) to identify more specific courses of action: https://twitter.com/DanaEpp/status/1622978719118934016. Whenever you're trying to investigate something, looking for existing detection logic across a variety of sources, even without leveraging tools that scan for these things, is an incredibly valuable technique.

All in all, I'd say the Jr analyst from the initial prompt was on the right track with a lot of their ideas. There's more research needed here to find some more specific paths to pursue and a few misconceptions that need clearing up, but those are workable things.

Speaking of information-dense artifact sources. Do you ever over-rely on that sort of data? How would you know if you were? That's something to think about... 🚀 #InvestigationPath #DFIR #ThreatIntel #Malware #SOCAnalyst

Investigation Scenario 🔎

A junior analyst is concerned that Cobalt Strike may be running on a Windows workstation. They proposed the steps in the image below to investigate the event.

What feedback would you give them on their proposed investigation path? What would you prioritize, deprioritize, add, or change?

#InvestigationPath #DFIR #SOCAnalyst #ThreatIntel

The alert tells you that one artifact of Bazar has been discovered. Your first task should be finding at least one other Bazar artifact to determine if the malware has actually infected the system.

With any alert that mentions named malware, you’ve got a leg up because you can leverage everything the world already knows about the malware. But, you’ve got to do the research work! Some Googling reveals lots of published information about Bazar. For example, check out these two articles:

1. https://unit42.paloaltonetworks.com/bazarloader-network-reconnaissance/
2. https://www.fortinet.com/blog/threat-research/new-bazar-trojan-variant-is-being-spread-in-recent-phishing-campaign-part-I

From these articles, you want to look for artifacts that are easy to find given the evidence sources you have available. Ideally, those artifacts are tied to events in the timeline near the event you already know about — the potential C2 traffic. For example, you could…

1. Look for C2 network traffic that matches the pattern in the article
2. Identify executions of new DLLs
3. Seek newly written registry RUN key entries

Among other things…

Not many folks in the replies actually did research on the malware, but a few did mention doing it. My response of the week goes to @thomaspatzke, who captured some of those ideas (https://infosec.exchange/@thomaspatzke/109788268480096606). Doing research is part of the job and a skill to develop. It involves identifying relevant info, synthesizing it, and knowing your evidence sources well enough to focus your efforts. You get better at it by doing it more and internalizing feedback on what works and doesn’t. Lots of analysts feel like spending time reading about malware is distracting them from the real world of looking at the evidence. Overcome that worry -- doing that reading when alerts like this come up is a core part of the work.

By the way... if you were at the #CTISummit, I did some live forecasting for this scenario 😄

Speaking of research… some folks focused on network artifacts while others focused on host artifacts. Where do you normally focus? In what circumstances might that limit you? That’s something to think about… 🚀 #InvPath #DFIR #SOCAnalyst #ThreatIntel

Investigation Scenario 🔎

You received a Suricata NIDS alert indicating that a host attempted a DNS lookup for a domain associated with BAZAR malware command and control.

What do you look for to investigate whether an incident occurred and its extent?

#InvestigationPath #DFIR #SOCAnalyst #malware

For this week's scenario, you know that exfil almost certainly occurred, but not when or how... so that's where you're focused. A lot of folks recognized that immediately -- great! Let's talk about it...

Investigations start with the evidence you already have. In this case, you start with the sample data from the forum post. It can't tell you everything, but it can give you a hint about where to start looking. The first step is determining where that data is normally housed.

The location of that data (whether at rest or in transit) becomes the focus of the investigation. You can consider how users normally access that data (like through a web app) or how someone with root on the box might access it (like direct to files or a DB).

You're taking an inside-out approach here. You know where the finish line was but not which road the attacker took to get there. Each of those pathways involves a different set of artifacts to consider. We're talking about attack surface here.

For example, if the data is normally accessed through a web app. You should consider the use of stolen credentials to access that web app and retrieve the data.

As another example, the data might be accessible (although not in normal practice) through files on disk. Here, you can consider abnormal authentications to that system or executions related to file archiving and transmission, among other things.

I'd refer to this scenario as a data-centric investigation because it's the knowledge of what the attacker accessed that starts the investigation -- we don't encounter these as frequently as some other starting points.

From my research. I find plenty of evidence that good analysts constantly consider the attack surface relevant to data/hosts throughout an investigation. In this scenario, you've got to do that right off the bat to efficiently drive the investigation forward.

Shout out to Sajjad who is my response of the week. He worked under the assumption the data come from a DB server and mentioned some normal and abnormal methods that data might be accessed. (https://www.linkedin.com/feed/update/urn:li:activity:7023664326146220032?commentUrn=urn%3Ali%3Acomment%3A(activity%3A7023664326146220032%2C7023722653874040832)

An investigation like this one could be time-consuming, particularly if you don't have a great collection and monitoring infrastructure in place. It's also a good reminder to document where data lives + the people who manage it and can help identify access pathways.

Speaking of attack surface, how do you normally characterize the attack surface of a given host? There are a few ways to go about that, but, it's something to think about... 🚀

#InvestigationPath #DFIR #SOCAnalyst

Investigation Scenario 🔎

The Windows Event Log service was stopped on a workstation for 16 minutes, then started back up.

What do you look for to investigate whether an incident occurred?

Assume you have access to whatever digital evidence source you need.

#InvestigationPath #DFIR #SOCAnalyst #threathunting #infosec

This week’s investigation scenario was all about research — a critical function of the analyst.

Original Scenario: https://infosec.exchange/@chrissanders88/109665506345228679

Most folks Googled the UA string, and that’s a good idea! But, this one was a little bit deceptive because it required more work than you might think.

If you Google the string, the first result that comes up is a github repo for a C# HTTP bot someone wrote named LiteHTTP. The code makes it look like the bot uses the string I shared as its user agent: https://github.com/zettabithf/LiteHTTP/blob/master/Bot/LiteHTTP/Classes/Communication.cs. If you think about the scenario I described, I said that this was a LINUX host, but this bot is written for a WINDOWS system. At that point some folks said case closed, because the Windows bot won’t run on Linux. But… there’s more to the story.

If you start to look at the other search results, you’ll find quite a few others things. That includes..

1. A ProofPoint article about a cred theft tool called Ovidly
2. A Sandbox report about a suspicious Perl script
3. A Checkpoint article about a Linux trojan named Speakup.

BTW, Shout out to Harlan on LinkedIn, who was my response of the week for going beyond the first result and identifying these other things: https://www.linkedin.com/feed/update/urn:li:activity:7018592428894949377?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A7018592428894949377%2C7018634119542702081%29

This scenario demonstrates some of the difficulty analysts may go through when researching known threats. Even though this string appears pretty unique, it’s easy to assume that the first result you find is all-encompassing. In truth, each source you examine may only have a piece of a broader puzzle.

For this example, you may have found that the string from the scenario is actually the MD5 hash of the word liteHTTP. But, looking through multiple sources, you’ll also find some analysis that makes it clear that some code from the liteHTTP bot appears to have been reused across some of this other malware. That makes sense! Some of these articles suggest that the same author might be responsible for multiple strains of malware, but it could also be that someone simply borrowed from the code that’s publicly available on github. That’s pretty common.

So, how do you approach this? We’re dealing with a Linux system and we’ve found one article that mentions a linux infection https://research.checkpoint.com/2019/speakup-a-new-undetected-backdoor-linux-trojan/, so that’s the place to start trying to match up some of the described capabilities with what we can find on our system. I might start by looking for some of the victim registration commands that the tool reportedly executed post-infection… things like uname, ifconfig, arp, and so on. After that, I might also try to validate that the network traffic matches the format seen in samples mentioned in the article. I’ve probably confirmed an infection at this point, and because the tool has the ability to infect other systems on the network, I’m going to start looking at internal communication and authentication from this system to others that began around this time. That’s not the whole path, but it’s a start.

Also, keep in mind that completely new and unique malware could arise based on the openly available code we’ve discovered. That means we might be dealing with an entirely new set of capabilities that aren’t yet documented anywhere yet. Similarly, this malware could be used to deliver other malware. In one report we see it led to an eventual infection by a cryptocoin miner, but that could easily change to something else. In that case, the analysis may be a bit broader… looking for any suspicious executions or newly established persistence mechanisms in common locations, among other things during this time period.

A lot of the work an analysts does will be researching threats to figure out what you need to look for on your network to see if that threat has manifested there. It may feel like that’s secondary to the primary job role, but it’s a central task in the analysts work and a skill to develop.

BTW, there are some public threat intel sources that are well suited for specific searches with common artifact types you’ll run across. Do you have some reliable favorites? That’s something to think about… 🚀 #InvPath #DFIR #SOCAnalyst #ThreatHunting #infosecurity

Investigation Scenario 🔎

You’ve been alerted to outgoing network communication from a Linux host with the HTTP user agent E9BC3BD76216AFA560BFB5ACAF5731A3.

What do you look for to investigate whether an incident occurred?

Assume you have access to whatever digital evidence source you need.

#InvestigationPath #DFIR #SOCAnalyst #Linux

So many great responses to this scenario. The thing I want to focus my discussion on is clarifying the role of the file. A lot of you did the right thing here by Googling the file type. It’s traditionally associated with Doom (the game). However, that doesn’t mean the sample we found was associated with Doom. It could be a coincidence (random/another tool that also uses that extension) or an intentional collision (for fun/to deceive).

If it’s not related to Doom, does that mean you wasted time researching the file extension? Absolutely not! That research is still a good idea here. It’s low effort, often high reward, and it’s knowledge you can carry forward next time you encounter something similar.

If you do want to take the approach that you should disprove the file is associated with Doom, you can open it up in a hex editor and compare its structure to a Doom WAD file to see if it matches ([https://bw.vern.cc/doom/wiki/WAD](https://bw.vern.cc/doom/wiki/WAD)). Shout out to @da_667 who mentioned that and even did some research to find a reference for the file structure. He had more good ideas in his post, and is my response of the week this time around.

Another strategy is to approach the file more generally without the assumption it’s Doom related. There are many routes to go, but you want to start with things that are high value and low effort. Either way, you can't just trust that it's Doom. If you can determine the true file format, that will shape the rest of your analysis. You can look at the first few “magic” bytes to try and determine a file type ([https://en.wikipedia.org/wiki/List_of_file_signatures](https://en.wikipedia.org/wiki/List_of_file_signatures)) or maybe use the Linux file command.

If you can figure out what type of file you’re dealing with, you can often open and analyze the file in tools that are purpose built for it. For example, if you figure out it’s a sqlite DB file, you could open it in SQLite Database Viewer to see what data is contained there.

Analyzing the strings (FLOSS/CyberChef) or opening it in a text/hex editor are great ideas. It could be a config file or script…something easy to parse visually. You can also look for things like domains and IP addresses, obfuscations, or nefarious functional calls.

After that, you get into searching public sandboxes for the file hash, dropping the file into your own sandbox for behavioral analysis (if it’s executable), looking at other metadata, or performing some static analysis. All in effort to understand the file’s role.

Once again, with so many paths to take the key is focusing on the paths with the best balance of low effort to high reward. Understand what you’re dealing with so you can use the right tools, then move forward. There are lots of good ideas in the responses around other things to be done at this point — prevalence on the network, associating the file with a specific user, and more. But, this investigation really hinges on understanding the role of the file.

By the way, a couple folks mentioned that the file could be encrypted! How would you determine if a file was encrypted, simply obfuscated, or in clear text? That’s something to think about… 🚀 #InvPath #DFIR #SOCAnalyst

Our 2-day "Defending Enterprises - 2023 Edition" threat hunting training is now taking registrations at BruCON, running live on 20-21 April in Belgium!

Book your ticket below.

https://www.brucon.org/2023/brucon-2023-training/defending-enterprises-2023-edition/

#blueteam #threathunting #socanalyst #pentest #training #cybersecurity

Investigation Scenario 🔎

During incident response, you discover a recently created file named 1.wad on a system the attacker accessed.

What do you look for to investigate whether the file is involved in the compromise and how the attacker might have used it?

Assume you have access to whatever digital evidence source you need.

#InvestigationPath #DFIR #SOCAnalyst

I just published an article on Medium that covers some basic tips for beginner soc analysts looking to investigate processes. If you're just starting in this field or want to get a job, I hope you'll find it useful.
Thanks for reading! 😁 #socanalyst #malwareanalysis #azuresecurity

https://medium.com/@borzfabian_7015/using-azure-demo-logs-to-identify-suspicious-processes-for-beginner-soc-analysts-49d7490e800a

A new #sigma rule was created to detect impersonation executions, which can also be found in SOC Prime now.

https://lnkd.in/gagWwKPq

https://lnkd.in/g45UmXmS

#cybersecurity #socanalyst #informationsecurity #blueteam
#ECI #socprime #sigma_hq #sigma_rules