A unique facet of this investigation that I want to focus on is the capabilities of the potential malicious actor. They're certainly more capable than a typical inside user and likely more motivated to cover tracks than an external attacker. With that in mind, you have to consider the potential for deleted files, cleared logs, hidden entities, and more. Since we're concerned about visits to public forums, that might mean expected browser artifacts aren't available. The good thing is that there are often multiple places to find artifacts of visited URLs, even when you only have the disk to work with. For example, registry keys like TypedPaths.

Some evidence sources can prove an event occurred, but they can’t prove it did not. That's why we examine multiple sources, particularly in cases such as this one.

Speaking of covering tracks, what do you suppose are the most common techniques insiders might use to cover tracks on systems they're using for malicious activity? Where would you find artifacts of their occurrence?

That’s something to think about… 🚀 #InvPath #DFIR #SOC

The three most important questions here are...

1. Is this actually 7zip?

2. If so, was it used in a malicious context?

3. If not, what is it?

Those questions aren't specific enough to answer on their own, but they do beget other, more specific questions.

Throughout the responses, you'll see people identifying those exact next moves: hash comparisons to validate the file, contacting the user to check intent, exploring the use of the tool and other executions.

You must get to the specific questions to uncover meaningful evidence and make conclusions. But... those specific questions often start with broader questions that you'll unpack. That's a perfectly solid strategy to take when thinking through your approach.

Speaking of archiving applications... do you know which ones are used in your network? How would you find out?

That’s something to think about… 🚀 #InvPath #DFIR #SOC

In an ideal situation, you'd examine the full command line of the execution. However, I limited the scenario by making those logs unavailable, which is a common scenario on many networks, unfortunately. I did give you a hint, however, that threat actors use this technique quite often. A little bit of research yields plenty of examples... Qbot, APT 32, APT 28, etc.

When you observe a specific suspicious relationship, it's helpful to research it and find instances of known malicious use. Specifically, you want to understand how attackers create the relationship and why it's meaningful to them.

In this case, attackers leverage regsvr32.exe to run executable code, often in the form of DLL files. The location they execute it from may relate to a place where they have easy read/write access, but that's also not easily discernable by other detection tools.

Once you've observed a new or changed relationship that seems favorable to an attacker, you can use your knowledge and research to find other relationships that might build on that one... resulting from it or leading to it.

Speaking of relationships... what other sorts of things might you find running out of C:\Users\Username\Appdata\Roaming? Some interesting behaviors to understand...

That’s something to think about… 🚀 #InvPath #DFIR #SOC

This is an intentionally broad scenario with limited evidence available. There are many ways information could have been communicated, so it helps to think about the most likely scenarios and where evidence of their happening might manifest.

There's a debate about the most likely mechanism of communication, and several ways that might have happened are mentioned: e-mail, chat, USB drive, and so on. It depends a lot on the network. The big challenge here is that there's no time bounding for the potential incident.

Having a time range within which to work in investigations is one of the best allies an analyst can have. We have so much data to deal with that limiting searches by time is the best way to filter down to a manageable amount of data.

Absent a time range, you're exploring ideas about the potential mechanism of communication. An idea I like is identifying executed applications and building a model of typical applications that might be used for communication, and then diving further based on what you find there.

Many investigations, particularly those without specific leads, involve figuring out where to take the first bite and then narrowing down the data into reasonably bite-sized chunks.

With most investigations, you want to let your ideas and investigative questions lead the actions, then pursue data to answer/prove/disprove ideas and reveal more leads. You don't want to haphazardly dive into data without a plan, hoping something reveals itself.

My response of the week goes to @13reak for identifying two strategies based on whether the time frame is known. https://infosec.exchange/@13reak/112286073675099993

That's a solid example of identifying a key data point and approaching the investigation based on what you know. He'll win a free month in my Analyst Skills Vault: https://www.networkdefense.co/skillsvault/

Speaking of endpoint communication, do you know what communication tools your users rely on most often? What would you expect to see, and what would surprise you?

That’s something to think about… 🚀 #InvPath #DFIR #SOC

When the detection signature comes with a reference URL, you should always check it out. The author is helping you out with information that ought to help you investigate the alert.

In this scenario, the reference article is pretty bulky. So, it's a lot to parse which was one of the challenges here. Good analysts can quickly filter through the fluff and find the things that are relevant to an investigation.

The fluff... a lot of the malware reversing information... its internals, the shellcode, encryption mechanisms... probably not super useful to us. We're concerned with interaction points on the system that will manifest in evidence.

Side Note: Many malware analysis profiles seem to be written for other reverses and not analysts, who are the primary consumers of the information. That's always been frustrating. Anyways...

The interaction points we're interested in are the C2 mechanisms, process executions, process injection, persistence mechanisms, and so on. Things we can easily search for.

That said, the signature itself is incredibly specific and unlikely to be a false positive. That makes this one quite a bit more straightforward than some other investigations.

Typically, a malware alert has a signature that identifies one artifact of the malware on a host. The analyst's job is to confirm by finding another artifact. The reference article contains many you could look for, but you might need to find other references, too.

Overall, this alert and its investigation are not the place to focus on investigation paths that are more time-consuming and require broader judgment calls. Focus on specific, highly relevant artifacts, and that'll get you to a disposition faster.

Speaking of malware research, what are some ways you can quickly tell if an analysis report was written for investigators, versus some other role? That’s something to think about… 🚀 #InvPath #DFIR #SOC

There are several ways to pursue this investigation, but I want to focus on the idea of prevalence analysis here. Analysts use prevalence analysis to identify what proportion of a population shares one or more characteristics.

There are a few use cases for prevalence analysis… determining the disposition of an event, assessing impact, or sequencing events on a timeline. At this early stage, we’re concerned primarily with the disposition since we don’t yet know what it is.

If every system of a certain type of role is performing the same POST, then there may be a benign explanation related to that type or role. If this is the only host making the POST, we can’t lean so far in that direction on our dispositional scale.

Dispositional prevalence analysis means we’re looking for how many other places an event or characteristic manifests. For example, has that POST been sent by any other hosts on the network? Have any other hosts on the network communicated with that external IP?

The general maxim is that rare things are more likely to be malicious. If a whole segment of hosts do the same thing, it’s probably benign behavior. Of course, that’s not always true, and it becomes less true as compromise advances.

With prevalence analysis, we can focus the breadth of our search on events on the host itself (local prevalence), our network (network prevalence), or the whole world (global prevalence). Where we focus usually depends on the artifact type.

Consider how we might use these forms of prevalence...

- Local: Do fragments of the potentially encrypted string appear elsewhere on disk?

- Network: How about elsewhere in HTTP traffic on our network?

- Global: How about on other networks (internet or threat intel search)?

This investigation scenario is rich in opportunities for prevalence searches to assess disposition. The great thing about this analysis is that it also inherently helps you assess impact if you do confirm malicious activity.

My response of the week goes to @ido_gat on Twitter: https://x.com/ido_gat/status/1772652020639433165?s=20. They mentioned some great strategies like identifying the source process, reputation research on the destination, and prevalence! 

Speaking of prevalence, what are some of the most common artifacts you would expect to perform prevalence analysis on? Are the mechanisms to do that readily available in your environment? That’s something to think about… 🚀 #InvPath #DFIR #SOC

Lots of good stuff here! Something notable about this scenario is that there are several places you could focus your investigations. We have to deal with often... sources, targets, and even secondary targets (like the DB server behind the web server here).

Looking at the responses, it looks like most folks were focused on the target. Particularly, whether the SQL injection attempts were successful... looking at things like transaction logs, web server logs, or even network traffic to characterize this behavior.

With the target system hosting an internal application, I am more interested in the source of the potential attack than I would normally be if it were some external host attacking an external-facing asset. Think about it this way... if this is malicious, the source is certainly compromised (an attacker is executing commands) while the target has yet to be confirmed as a victim (we don't yet know if the injection was successful).

Of course, we absolutely want to understand whether the attack was successful. But looking at web server logs, SQL transactions logs, and the such... that's time consuming. I think I'd have quicker success trying to prove compromise on the source system since it's on my network

When we think about sources and targets, what are some parameters you use to decide where you should focus your investigation first?

That’s something to think about… 🚀 #InvPath #DFIR #SOC

This exercise is intentionally limited a bit to help you do two things:

1. Consider what you know about the forensic value of the registry

2. Think through the limitations of your conclusions based on the evidence available.

The registry contains a lot of helpful information that can help you get a sense of what’s going on here. Lots of great replies with some ideas here… the affected account, access mechanisms, recently accessed files, and so on.

You can build a pretty good idea of some of the activity leading up to the system being wiped, but you won’t be able to complete the full story of the attack timeline with registry data alone.

Further, many of the artifacts you will identify aren’t things you’d be able to validate with other evidence sources, which puts you in a tricky spot when drawing conclusions. You have to weigh that in your response decision-making.

Remember that it’s possible that the attacker has also accessed other systems on the network. Lots of prevalence searches on the interesting artifacts you find in the registry evidence across other hosts will be warranted.

What evidence source do you rely on most? If you have to examine that source in a vacuum, what limitations does it impose on the conclusions you can draw?

That’s something to think about… 🚀 #InvPath #DFIR #SOC

As you look through the replies to the scenario, take note in the assumptions each person makes. What some call an assumption, others would call a hypothesis; the former is accepted while the latter is questioned. That distinction is critical. It’s okay to pick a likely outcome and pursue evidence that proves or disproves it, you just can’t make the assumption that has happened without evidence in hand. Particularly before you go isolating and quarantining things.

Of course, this does sound like it could be a SIM swapping attack… many of us thought that last week when AT&T went down 😅 But the confluence of a phone issue/outage and a user having a login issue isn’t that unreasonable. I’ve seen it more than once!

Speaking of SIM swapping attacks, what’s your investigative plan if you suspect someone with access to sensitive information in your org is affected by one? Don’t just think about response, but also clear identification…

That’s something to think about… 🚀 #InvPath #DFIR #SOC

Absent specific leads, broad scenarios like this can overwhelm many analysts. Having dozens of paths you could take is often as daunting as having no apparent paths to take.

In a scenario like this, it’s helpful to understand common attacker goals. While attackers accomplish goals differently, we can predict some common actions and devise an investigation plan from that.

When attackers access a system, they are likely to do at least one of these:

1. Execute malware that creates a persistence mechanism
2. Pillage the system for useful user information
3. Steal additional credentials
4. Scan the network for other lateral movement targets

Each of those actions ties to useful evidence, and even though the attacker's actions might take different forms, they often manifest across a predictable and common set of evidence sources.

Usually, you let the evidence you’ve found lead you to the evidence you’ve yet to find… but sometimes you have to make educated guesses based on what is most likely, hoping that a more specific lead reveals itself.

If you have these broad categories of common attacker activity, you can have evidence sources you rely on to help prove those things. Ideally, start with a combo of the most likely + easiest to prove/disprove.

Analysts tend to fall back on things they are most comfortable with. What are you most comfortable with of the four things I listed above? Now, what are you least comfortable with? That’s your opportunity for growth.

A lot of this scenario is about human behavior. What evidence sources on your hosts are most useful for characterizing that behavior and finding things outside the norm? How do you access and manipulate them? That’s something to think about… 🚀 #InvPath #DFIR #SOCAnalyst