Menu > Articles de la revue de presse : - l'ensemble [tous | francophone] - par mots clé [tous] - par site [tous] - le tagwall [voir] - Top bi-hebdo de la revue de presse [Voir]

---

S'abonner au fil RSS global de la revue de presse

---

Présentation : I ran across this write-up on W32.Brambul recently, and as I often do when I see this sort of thing, I thought about how one might go about trying to find this within an infrastructure, from an endpoint perspective. After all, this is the perspective that most of the threat intelligence that we see tends to leave out. The most obvious indicator would be failed login attempts within the Security Event Log of target systems, and possibly account lockouts. You'd see this sort of indicator either via the SIEM you're using, or if you were proactively hunting within the domain. As something of a side note, I mentioned Ryan's of Tanium presentation at the HTCIA2015 conference a bit ago, where he discussed hunting in the dark . I thought it was a really good presentation as he broke down how to get started. Hunting in any infrastructure can be a bit overwhelming, but if you break your goal down into discrete, manageable steps, it can be easier to get started. As Ryan recommends, starting small is key...you start eating the elephant one bite a time. Looking at the enormity of an infrastructure can make things overwhelming, so start small. Start with examining the contents of the Run key on systems, maybe starting with domain controllers and then once you've automated that, move to workstations. Learn what's normal in your environment. Then move on to the Windows Event Logs. But the point is to not get overwhelmed by the apparent size and scope of the task, and to instead start working with what you have. Okay.,.that said, we'll go back to the Brambul... On the infected systems, looking in the Run key might be a place to start. However, if the malware installs as a service, locating Service Control Manager 7045 event records there shouldn't be many within the System Event Log would be the way to go. If you're using a SIEM, and forwarding the right logs, you could search there, instead. Or set a filter. If you don't have a SIEM, you can use Powershell MS has some good documentation available... or WMI. Something else that may occur on the infected systems is Security Auditing 4648 event records, indicating the use of explicit credentials. This likely won't be definitive without further context, and to be honest, it's not surprising that malware write-ups aren't addressing this sort of indicator. The key is that if you're going to go huntin' within your infrastructure, what do you look for Do you look for malware, when the write-ups you're seeing all talk about how the folks writing this stuff are using high-speed techniques to ensure that the malware avoids detection and is hard to analyze Do you search for file hashes on systems Do you search for IP addresses in your logs Or do you go looking for indicators of behavior So, how is looking beyond low-level technical indicators hashes, IP addresses valuable Remember the Moker write-up This 'new APT' reportedly includes anti-detection and anti-debugging techniques, allowing it to bypass detection. Yet, it apparently persists via the Run key...so, if I just enumerate the values within this key and look for anything suspicious, such as a path that includes C ProgramData . If I did that, and then correlated that information with a new user account being created on the system, would I then be able to determine that the system was infected with something And that's not so much a low-level technical indicator as it is moving closer to a behavior, something that may be anomalous within your infrastructure and indicate that something needs to be looked at a bit closer. Here's another bit of malware that, according to some write-ups, may be associated with Brambul. you'll notice in the write-up that it states If it is successful in logging in, it will set the pourcentsSystem Rootpourcents as a network share named adnim. I added the emphasis, in order to draw your attention to the spelling of the share I did a copy-paste and didn't try to retype that... . If you were hunting in your environment, looking at the values beneath the LanmanServer Shares key within the Registry might help you find this or anything else that might be suspicious , particularly if you don't have auditing for Object Access File Shares enabled. Just for fun, I created a couple of shares using the net share command...one called adnim and one called adnim . Both appeared as values beneath the LanmanServer Shares key. So rather than looking for file hashes on a system, we can start to correlate various indicators, based on time, and also develop context around what we're seeing. The name of the share may change, but if the malware continues to create a share, we know what to look for when we're hunting. Testing and Monitoring If you're testing malware, doing dynamic analysis by running it in a VM or on bare metal , something that I don't seen done very often is running it with monitoring tools such as SysMon or Carbon Black. Why would anyone want to do this After all, who really cares what happens on the endpoint, right Not the malware RE and AV guys. If you're protecting an infrastructure, or responding to a breach, you probably do care, because process creation monitoring is extremely valuable. Here's an example...we've seen malware that persists via a particular key, and at one point that malware stopped using the API and instead used an embedded 'reg add' command to maintain persistence. Okay, so now, we have not only the persistence location, but we also have a command we can monitor for in order to perform detection much closer to the time of infection. Or...and bear with me here...if you don't use reg.exe in your infrastructure, you can take steps to prevent it from being used, even by an account running with System-level privileges. The same holds true for other processes. Consider the malware described above that creates a share...how does it do this Via the API, included as part of the code, or via an embedded net share command Monitoring for this sort of activity within the infrastructure can give us a great deal more visibility into what's going on. For example, if someone archives files via WinRAR and encrypts the archive, the process runs and completes, and the memory used if freed up for use by other processes. However, if we monitor for process creation, we can capture that command line along with the password used . Process creation monitoring provides a great deal of insight into what the bad guys are doing, or are trying to do, and will illustrate behaviors.






Les derniers articles du site "Windows Incident Response" :

- Training Philosophy
- Cool Stuff, re WMI Persistence
- Windows Registry Forensics, 2E
- Event Logs
- Links Plugin Updates and Other Things
- Tools, Links, From the Trenches, part deux
- From the Trenches
- Updated samparse.pl plugin
- The Need for Instrumentation
- Analysis

---

S'abonner au fil RSS global de la revue de presse

---