The discussion of live respnose is posted below. anythe question based on the live response...

Watch the archived webinar shown below and answer the questions listed below. Your answers should be complete, but brief.

NOTE: Glossary at the end. NOTE: The webinar gets technical after slide 21stick with it. Focus on high-level, cursory understanding after that. https://www.fireeye.com/blog/threat-research/2014/02/qa-webinar-followup-fresh-prints-malware-network-danger.html

Fresh Prints of Mal-ware: A Lively Analysis of Live Response Original Date: August 29, 2013 ET What questions does live response answer?

What are the stated benefits of live response? (early/later in webinar not on all one slide) In the case study involving 10,000 systems and 30 compromised systems, how did live response help focus investigative efforts on 6 systems needing analysis?

What do you think happens with other 24 systems?

When is live response NOT a good idea? What are the basic steps to perform live response?

What are the challenges when collecting data during triage?

Why do you think What data did the attacker take? is the most frequent question clients ask live response and forensics experts?

What are some conceptual, general approaches incident responders use identify whether data was stolen and/or what data was stolen?

Why is it important to determine what lateral movement occurred?

List and briefly explain the keys to live response success outlined at the end of the webinar.?

"

If the victim is already beaconing out to an attacker network and its Windows, won't the evil domain be in the DNS cache on the Windows system itself?

Yes. If you identify malware on any system beaconing out an evil domain, we would suggest you implement a group policy that will flush the DNS cache on each system on your domain. After flushing the DNS cache and enforcing firewall rules to only allow outbound DNS queries from the internal DNS servers, then you can apply the technique that we mentioned in the webinar to identify all systems going out to the honeypot at that point. You can also implement a DNS sinkhole to direct communications back to the local host when querying the internal DNS server for the evil domain.

Will adding a DNS record for an evil domain stop browsers that are using a proxy?

Yes. If you have a browser that has a proxy hard-coded in the browser itself, it's going to use that proxy to connect out. But the types of malware we're talking about are not within the browsers themselves. Malware that is on the Windows or Linux systems themselves use the same DNS server that the infected system uses; whereas a browser will use the proxy, which will in turn use the DNS server that the proxy uses. Also keep in mind that all systems will first look at the local host for DNS resolution, and if the domain of interest is not defined in the local host file, then it will query the DNS server internally/externally - depending on how it's configured.

Please remember that if you have implemented DNS records to sinkhole an evil domain, it may not work if you haven't implemented the proper firewall rules that explicitly allow DNS queries from only your internal DNS servers.

Regarding magic packet, there's an assumption that there's malware running on the system.

That's correct. There has to be malware on the system for the magic packet method to work. Another question we got on the magic packet method was whether or not it uses unsigned drivers. On most cases, attackers use unsigned binaries, but attackers can also sign their malware.

Speaking of signatures and drivers, that's a very good question. As Lianis mentioned, we have seen malware that's actually signed; attackers will actually steal legitimate certificates and will sign their malware with them. Checking for unsigned signatures is a good indicator, but it's not a silver bullet when detecting malicious drivers.

Integrity checking is another good method to implement on external facing servers. Hashing all the DLLs and executables from a clean base image of your externally facing server and then comparing those hashes to your external servers on a monthly basis may result in some discrepancies. Those discrepancies can later be investigated and marked as a false positive or malware. Try to answer questions like: Is that discrepancy signed? What's the MD5 of file? Is that MD5 publicly known or is it unique? You can also acquire the file and perform basic triage against the file to better determine if it's malicious or not.

One thing to add, in cases where attackers use stolen certificates to sign their malware, the binary may be signed, but the signature may not verify. This occurs if the legitimate owner of the certificate revokes the certificate. Identifying binaries that are signed but not verified is a method investigators can use when looking for malware on a system.

What's the most popular attack vector we're seeing attackers use right now?

The most popular attack vector we see is phishing. Even though everyone knows about phishing, it is still very effective and works. This can be accomplished through a user clicking on a link that exploits the browser and executes a drive-by download attack, or by attaching malware to the email and enticing users to execute it.

The second most popular attack vector is exploiting web front ends through SQL injection. Those two are the most popular attack vectors that we see in our investigations.

What's the difference between the magic packet and port knocking?

For those of you who don't know what port knocking is, it's essentially a method of dynamically opening ports through a special sequence of connection attempts. The difference is that the firewall would have to be configured to open a specific port if the correct sequence was issued. Whereas with the magic packet, a port such as TCP port 443 or TCP port 80 would already be open and all incoming connections would make it through the firewall. Then the malware will actually rewrite the IP header and cause the connection packet to be transmitted on a different port high up on the stack once it's already on the host.

So it's not like port knocking, in that port knocking requires the firewall to be configured a special way and will open ports on the firewall itself. Furthermore, port knocking is normally configured for legitimate use for system administrators to use when trying to prevent attackers from port scanning their network and obtaining valid results.

Would blocking recursive DNS requests from your network prevent a system from resolving malicious domains? Yes; however, this could hinder your day-to-day operations, depending on how you have your DNS service set up. For those of you who are not familiar, if you block recursive DNS requests, then the authoritative DNS server will not be able to find your domain; instead, you resolve other people's domains. A more practical solution would be to create the explicit firewall rules we mentioned earlier and DNS sinkholes if you have identified the malicious domains.

How do you enable DNS logging on Windows?

This depends on the size of your business and/or who you are. If you are a small business or have a home network, you are likely using your Internet Service Provider (ISP) to control your DNS requests, and your requests are probably going through your router.

If you have a Windows DNS server in place internally, then you can enable DNS logging by opening the Domain Name System Microsoft Management Console (DNS MMC) within the administrative tools area. Right click on the DNS server(s) that are within the management console and go to properties. There will be a tab in the properties window called "Debug Logging." This will allow you to enable DNS logging and set the maximum size of the log and the destination path where you want the log to be saved.

Please keep in mind that you can back up the log files to a flash drive/external hard drive if you need to reference them later and don't have enough storage space to keep them.

How do you detect malware that modifies the IP headers?

How we look for malware that modifies IP headers is not any different than how we look for other types of malware.

Compromised clients either find out themselves, or they are notified by a government entity or an ISP provider. In either case, the client will have some information we can use to pivot our investigation. This can be a malicious IP/FQDN, a timeframe, a host name or a compromised account, etc.

One method we use to identify malware is time-lining - or examining the timeline - around periods of known attacker activity. We look for files and Registry keys that were modified or created during that time frame. We also look at services and other Registry keys that the attacker may use as a persistence mechanism. We look for binaries that aren't signed, or verified, [within/and?] files in directories not commonly modified by users, such as System32 or the Windows directory, etc.

How do you determine if it was phishing or SQL injection for the initial attack vector during our investigation?

That's a good question. Part of investigating is time-lining, and there is an earliest date of compromise; this date goes back to the earliest time you found the backdoor or any malware on any system. Let's say you have 10 infected systems; one of those systems will likely have a file created time stamps that is earlier than the other 9 systems. At that point, you may want to investigate the email logs or the PST files that are on that system to determine if they were phished during that time window.

As for SQL injection, you look at the web server logs. This can be IIS, Apache or any other web server that has logs and you suspect was attacked. You can also look at database logs, but most systems don't log those because it requires a lot of resources to maintain those logs. You will notice a ton of SQL syntax in the GET requests of the logs, which is common for SQL injection. Those are ways to identify phishing or SQL injection, depending on your situation.

How much do new advanced malware techniques affect the use of traditional dynamic analysis, and what is a good dynamic solution for analyzing these advanced malware?

For dynamic analysis, there are a variety of tools you can use that are not dependent on the type of malware. A tool called "FakeNet" which Michael Sikorski published with his book Practical Malware Analysis, is a great tool that will capture all the DNS requests that an executable tries to connect out on, without allowing communication out, which will prevent you from communicating with malicious domains.

Another excellent tool is Capture-BAT. Capture-BAT logs every single registry key a file read/writes to and will log every file or directory that is read/written to. This can be useful if you see malware reading a particular file on disk. That file could be an encrypted file that has all the domains it needs to connect out to or other information needed for the malware to function. Sysinternals is also a great suite that has a bunch of tools inside of it as well, like Strings and ProcMon. Those are also great dynamic analysis tools that are still used traditionally, but can also be used in these advanced malware as well.

One thing to add, if the malware uses complex algorithms to calculate the C2 server, then dynamic analysis will only get you so far. In such cases, you will still have to do reverse engineering. By DGA, again, we mean domain generating algorithms.

We've been seeing it more these days, just because it's a new technique, but we don't see it that commonly in our investigations, because it's more difficult for the author to create it. Even without DGA, attackers are still getting by. Attackers still compromise environments and are successful at doing it. Therefore, it's not necessary to create malware with DGA capability. It just makes it more difficult for the analyst to identify where the C2 server will be next.

It's not a one-off either. We've seen it during our investigations multiple times, and we do see it becoming more popular. As system administrators get more advanced, their IT security starts to advance as well, which requires attackers to implement more complex mechanisms such as DGA. But it's not as common as standard malware or standard communications that we normally see in malware."