#invpath — Public Fediverse posts

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

The investigation must start with understanding what the script is actually doing — a lot of y’all jumped on that quickly and found that it’s basically an obfuscated method for running the whoami command.

The whoami command is a legitimate tool, but attackers often use it to test successful exploitation or to ascertain their current user context and privilege level. Here are some great examples of that: https://attack.mitre.org/techniques/T1033/

Because of the obfuscation, that alone is nearly enough to classify the event as malicious, but… this could also be a pen tester or security researcher on your network. That’s worth ruling out, and it should be quick to do so.

If there’s no benign explanation, then the investigation turns into whatever workflow you might use to expand the attack timeline relevant to the execution of malicious code. The replies contain lots of good ideas, but that involves a lot of time-centric queries surrounding things like…

- Other executions

- Newly written files

- Suspicious file downloads

- And more…

By the way, let’s say someone does run “whoami” on a host on your network. What’s your process to quickly determine if it’s legitimate activity? Do you have one? That’s something to think about… 🚀 #InvPath #DFIR #SOC

I think more folks struggled with this scenario than others, perhaps because it’s less common, and folks don’t quite understand how drivers might be used maliciously.

Because HW.sys is generally a benign driver, a good place to start is by checking out the LOLDrivers project... There’s a great entry for this file here: https://lnkd.in/eRuGSw3S. You’ll see that this file has been associated with vulnerabilities, and some malicious samples are provided.

Ultimately, malicious drivers are all about the execution of the attacker's code. That’s particularly impactful because of how those drivers are loaded and the level of system access they might have.

From an investigation perspective, it’s likely quicker to prove that the file is benign by comparing it to known good hashes or samples across the environment or other environments. It’s also useful to treat the investigation as one where you’re looking for potential execution of unwanted code, keeping in mind that there might be some track covering or anti-forensics going on. That means verifying findings with multiple data sources where possible.

What would your workflow look like to verify whether a driver is legitimate, should you encounter a similar finding as the one in this scenario? That’s something to think about… 🚀 #InvPath #DFIR #SOCAnalyst

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

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

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

Theories about this one had RANGE! The benign/technical (malfunctioning mouse), the benign/no-tech (use mis-reported), the benign/low-tech (a prank with a wireless mouse), and the malicious/high-tech (attacker used remote mgmt software)… among others!

A lot of folks posited their “most likely” explanation. When we forecast possible timelines, the one we want to pursue is usually the one that is some combination of the most likely + the quickest to investigate. Whatever path you pursue, you want to be deliberate about it. Try to prove or disprove your hypothesis quickly, remembering that disproving is often faster when possible. You only have to disprove it once, but you might have to collect a lot of evidence to prove it.

Right off the bat, getting as precise a time range for the activity as you can is helpful, because a lot of the queries you’ll make (executions, file reads, device use, etc) will begin within that range so you can find out what exactly happened on the system. Should out to Matthew Turner, who mentioned the importance of establishing the timeframe and clarifying what the user saw. That's my response of the week. Some of this hinges on just how random or intentional the mouse movements were. https://www.linkedin.com/feed/update/urn:li:activity:7010983533867409408/?commentUrn=urn%3Ali%3Acomment%3A(activity%3A7010983533867409408%2C7011376618833158144)&dashCommentUrn=urn%3Ali%3Afsd_comment%3A(7011376618833158144%2Curn%3Ali%3Aactivity%3A7010983533867409408)

In terms of the pranks, looking for new devices plugged into the system around this time frame works (on Windows, you’re looking in the registry or event logs). You could also inventory wireless devices in the near area and try to see if those were plugged into the system. Of course, beware that some of the reported info about USB devices isn't always as it seems: https://www.sans.org/blog/the-truth-about-usb-device-serial-numbers/.

For potential malicious use of remote management software, you’re likely looking for newly installed or running and executed processes tied to those tools. You’ll consider the commercial and free tools (TeamViewer, VNC, etc) along with the explicitly malicious RATs. Not for nothing, you should also consider whatever software your support team uses for remote troubleshooting. It could be a support person using that tool to fix something or mistakingly connecting to the wrong system. Either way, check your ticketing system and the app logs 😂

I actually investigated this scenario once. The box was clean, but we did find evidence that some other wireless USB mice had been plugged into it at various times. Ultimately, nobody fessed up, so it remained an unsolved mystery.

One more interesting facet of this case to consider… the user SAW the mouse moving. Some remote access tools lock the screen under remote control, and others don’t. Do you know which is which? Something to think about… 🚀

#InvPath #DFIR #SOCAnalyst #DigitalForensics #ThreatHunting