VirusTotal Multisandbox += Microsoft Sysinternals

We welcome the new multisandbox integration with Microsoft sysinternals. It was also recently announced on the sysinternals blog as part of their 25th anniversary. This industry collaboration will greatly benefit the entire cybersecurity community… Continue reading VirusTotal Multisandbox += Microsoft Sysinternals

Sysmon DNS Logging, Gravwell – Paul’s Security Weekly #608

We welcome back Corey Thuen, Founder and CEO of Gravwell, to talk about security analytics using the new Sysmon DNS logging that dropped this week! To get involved with Gravwell, visit: https://securityweekly.com/gravwell Full Show NotesFollow us on Tw… Continue reading Sysmon DNS Logging, Gravwell – Paul’s Security Weekly #608

Offensive Operating Against SysMon, Carlos Perez – Paul’s Security Weekly #577

Carlos Perez delivers the Technical Segment on How to Operate Offensively Against Sysmon. He talks about how SysMon allows him to create rules, and track specific types of tradecraft, around process creation and process termination. He dives into netwo… Continue reading Offensive Operating Against SysMon, Carlos Perez – Paul’s Security Weekly #577

toolsmith #110: Sysinternals vs Kryptic

26 OCT 2015 marked some updates for the venerable Windows Sysinternals tool kit, presenting us with the perfect opportunity to use them in a live malware incident response scenario. Immediately relevant updates include Autoruns v13.5, Sigcheck v2.30, RAMMap v1.4, and Sysmon 3.11.
Quoting directly from the Sysinternals Site Discussion, the updates are as follows:

  • Autoruns: the most comprehensive autostart viewer and manager available for Windows, now shows 32-bit Office addins and font drivers, and enables re-submission of known im  ages to Virus Total for a new scan.
  • Sigcheck: displays detailed file version information, image signing status, catalog and certificate store contents an now includes updated Windows 10 certificate OIDs, support for checking corresponding MUI (internationalization strings) files for more accurate version data, the version company name, and the signature publisher for signed files.
  • RAMMap: a tool that reports detailed information about physical memory usage, is now compatible with Windows 10 and includes a bug fix.
  • Sysmon: logs security relevant process, network and file events to the event log. This update fixes a memory leak for DLL image load event monitoring and removes a misleading warning when processing configuration files. 

For Sysmon we’ll include use of the 20 JULY 2015 update to 3.1 as well, given that, since last we discussed Sysmon@markrussinovich and team have added information about the thread initialization function for CreateRemoteThread events, including the DLL and function name and address.
I grabbed a Kryptik sample, a Zbot/FakeAV variant, from VirusShare that exhibits well using these tools. VirusTotal reference to this sample is here. A Windows 7 x64 virtual machine fell victim to this malware and gave up perfect indicators via these Sysinternals specialists.

Autoruns:
Beginning with Autoruns v13.5, an immediate suspect presented itself per Figure 1.

Figure 1

I am pretty darned sure that C:\users\malman\appdata\roaming\ibne\haho.exe does not serve a legitimate purpose, and more importantly, sure as hell doesn’t belong in HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run,  malware’s favorite start-me-up. Right click the entry in Autoruns, select Check VirusTotal, and you’ll get a fairly quick answer. You’ll see a Scanning File status under the VirusTotal column header while its scanning. Turns out haho.exe is not an OLE server and is a password stealing Kryptik variant. 🙂

Sigcheck:
I first ran sigcheck C:\users\malman\appdata\roaming\ibne\haho.exe and received the details expected regarding the version company name as well as signature publisher, specifically the lack thereof here. The sample was not signed and sigcheck validated its lack of legitimacy by confirming the Company as eSafe (its not), the Publisher as n/a, and the Description as OLE Server, all noted in Figure 2.

Figure 2

As a counterpoint to a malicious file, when you run sigcheck against a legitimate (usually), signed file such as C:\Windows\System32\notepad.exe, you receive much more robust comforting results as seen in Figure 3.

Figure 3

RAMMap:
Once you’ve established some useful indicators such as haho.exe, its installation path and subsequent registry key, you can derive related and useful information using RAMMap live on the victim system as done with Sigcheck. You’re likely accustomed to thinking that RAMMap is just a pretty picture of memory usage, but it does offer more. You can use the RAMMap Processes tab to determine active sessions, PID, and memory utilization, which I’ve done for out malicious process in Figure 4.

Figure 4

Similar results are derived from the File Summary tab including total and standby memory utilized.

Figure 5

Both views were sorted, then searched specifically for C:\users\malman\appdata\roaming\ibne\haho.exe as discovered with Autoruns,

Sysmon:
With the 20 JUL 2015 update to Sysmon comes the addition of Event ID 8 for CreateRemoteThread events. This is an absolute bonus as malware often injects DLLs using the CreateRemoteThread function. There’s a great reference to this method at the War Room.
For Sysmon reference, I’ll point you back to my post, Sysmon 2.0 & EventViz.
To help elaborate on Sysmon results I took advantage of @matt_churchill‘s Sysmon_Parse script, which in turn utilizes Microsoft’s essential Log Parser, @TekDefense‘s TekCollect, @nirsoft‘s IPNetInfo and @woanware‘s virustotalchecker . Its installation and use guidelines are written right into the script as remarks, it’s incredibly straightforward. You may run into a glitch with httplib2, a Python dependency for the TekCollect script. Overcome it by downloading source, copying it to the Lib folder of your Python interpreter installation (commonly C:\Python27 on Windows), changing directory to C:\Python27\Lib\httplib2 and running python setup.py install. Thereafter you need only run sysmon_parse.cmd and make use of results found in the Results_date directory, in individual text files. Sysmon_Parse first robocopies the Sysmon event log to a temporary .evtx, then parses it to a CSV file, sysmon_parsed.txt, with Log Parser. Note that you can supply an event log from other machines for Sysmon_Parse to crunch, on an analysis workstation rather than the victim host. Sysmon_Parse then calls TekCollect to extract artifacts such as MD5, SHA1, and SHA256 hashes, assuming you’ve enabled all hash types with sysmon -c -n -l -h md5,sha1,sha256. TekCollect also parses out all domains, URLs, IPs, and executables noted in the Sysmon log. The IPs should match your Sysmon Event ID 3s (Network Connection) quite nicely. I also found the SHA1 for this sample, dc965d0a38505001c800049a6c39817aec3616f0, in the Sysmon_Parse SHA1 text results, so clearly that TekCollect parser works well.
In this case, we’re curious to determine if haho.exe used CreateRemoteThread by filtering for Event ID 8. The answer is, of course; an example result reads as follows:
19564,2015-11-05 02:07:21,8,Microsoft-Windows-Sysmon,WIN-QN9NR3Q1MNR,S-1-5-18,2015-11-05 02:07:21.631|{2F96EDF1-B473-563A-0000-00106D1E1000}|1756|C:\Users\malman\AppData\Roaming\Ibne\haho.exe|{2F96EDF1-B9D8-563A-0000-0010BF9B2000}|568|C:\Windows\SysWOW64\WerFault.exe|1008|0x00000000000A45E0||
The source PID is 1756, the source image is our Kryptik friend haho.exe the target PID is 568 and the target image is WerFault.exe, used for Windows Error Reporting. 
CreateRemoteThread tracking is a great addition to Sysmon, already an outstanding tool.

Wrap Up

You’ve got a lot to take a look at packed in here. In addition to the Sysinternals updates, Sysmon_Parse and it’s dependencies give you a lot to consider, or reconsider, for your DFIR toolkit.
You’ve gotten a look at using them all to inspect a host pwned by a Kryptik/Zbot sample and learned that you can quickly discover quite a bit about malware behavior using just a few simple but powerful tools. Hopefully your inspired to grab this sample (I’ll send it to you if you ask), and experiment with this excellent collection of DFIR goodness.

Ping me via email or Twitter if you have questions: russ at holisticinfosec dot org or @holisticinfosec.

Cheers…until next month. Continue reading toolsmith #110: Sysinternals vs Kryptic

toolsmith #110: Sysinternals vs Kryptic

26 OCT 2015 marked some updates for the venerable Windows Sysinternals tool kit, presenting us with the perfect opportunity to use them in a live malware incident response scenario. Immediately relevant updates include Autoruns v13.5, Sigcheck v2.30, RAMMap v1.4, and Sysmon 3.11.
Quoting directly from the Sysinternals Site Discussion, the updates are as follows:

  • Autoruns: the most comprehensive autostart viewer and manager available for Windows, now shows 32-bit Office addins and font drivers, and enables re-submission of known im  ages to Virus Total for a new scan.
  • Sigcheck: displays detailed file version information, image signing status, catalog and certificate store contents an now includes updated Windows 10 certificate OIDs, support for checking corresponding MUI (internationalization strings) files for more accurate version data, the version company name, and the signature publisher for signed files.
  • RAMMap: a tool that reports detailed information about physical memory usage, is now compatible with Windows 10 and includes a bug fix.
  • Sysmon: logs security relevant process, network and file events to the event log. This update fixes a memory leak for DLL image load event monitoring and removes a misleading warning when processing configuration files. 

For Sysmon we’ll include use of the 20 JULY 2015 update to 3.1 as well, given that, since last we discussed Sysmon@markrussinovich and team have added information about the thread initialization function for CreateRemoteThread events, including the DLL and function name and address.
I grabbed a Kryptik sample, a Zbot/FakeAV variant, from VirusShare that exhibits well using these tools. VirusTotal reference to this sample is here. A Windows 7 x64 virtual machine fell victim to this malware and gave up perfect indicators via these Sysinternals specialists.

Autoruns:
Beginning with Autoruns v13.5, an immediate suspect presented itself per Figure 1.

Figure 1

I am pretty darned sure that C:usersmalmanappdataroamingibnehaho.exe does not serve a legitimate purpose, and more importantly, sure as hell doesn’t belong in HKCUSOFTWAREMicrosoftWindowsCurrentVersionRun,  malware’s favorite start-me-up. Right click the entry in Autoruns, select Check VirusTotal, and you’ll get a fairly quick answer. You’ll see a Scanning File status under the VirusTotal column header while its scanning. Turns out haho.exe is not an OLE server and is a password stealing Kryptik variant. 🙂

Sigcheck:
I first ran sigcheck C:usersmalmanappdataroamingibnehaho.exe and received the details expected regarding the version company name as well as signature publisher, specifically the lack thereof here. The sample was not signed and sigcheck validated its lack of legitimacy by confirming the Company as eSafe (its not), the Publisher as n/a, and the Description as OLE Server, all noted in Figure 2.

Figure 2

As a counterpoint to a malicious file, when you run sigcheck against a legitimate (usually), signed file such as C:WindowsSystem32notepad.exe, you receive much more robust comforting results as seen in Figure 3.

Figure 3

RAMMap:
Once you’ve established some useful indicators such as haho.exe, its installation path and subsequent registry key, you can derive related and useful information using RAMMap live on the victim system as done with Sigcheck. You’re likely accustomed to thinking that RAMMap is just a pretty picture of memory usage, but it does offer more. You can use the RAMMap Processes tab to determine active sessions, PID, and memory utilization, which I’ve done for out malicious process in Figure 4.

Figure 4

Similar results are derived from the File Summary tab including total and standby memory utilized.

Figure 5

Both views were sorted, then searched specifically for C:usersmalmanappdataroamingibnehaho.exe as discovered with Autoruns,

Sysmon:
With the 20 JUL 2015 update to Sysmon comes the addition of Event ID 8 for CreateRemoteThread events. This is an absolute bonus as malware often injects DLLs using the CreateRemoteThread function. There’s a great reference to this method at the War Room.
For Sysmon reference, I’ll point you back to my post, Sysmon 2.0 & EventViz.
To help elaborate on Sysmon results I took advantage of @matt_churchill‘s Sysmon_Parse script, which in turn utilizes Microsoft’s essential Log Parser, @TekDefense‘s TekCollect, @nirsoft‘s IPNetInfo and @woanware‘s virustotalchecker . Its installation and use guidelines are written right into the script as remarks, it’s incredibly straightforward. You may run into a glitch with httplib2, a Python dependency for the TekCollect script. Overcome it by downloading source, copying it to the Lib folder of your Python interpreter installation (commonly C:Python27 on Windows), changing directory to C:Python27Libhttplib2 and running python setup.py install. Thereafter you need only run sysmon_parse.cmd and make use of results found in the Results_date directory, in individual text files. Sysmon_Parse first robocopies the Sysmon event log to a temporary .evtx, then parses it to a CSV file, sysmon_parsed.txt, with Log Parser. Note that you can supply an event log from other machines for Sysmon_Parse to crunch, on an analysis workstation rather than the victim host. Sysmon_Parse then calls TekCollect to extract artifacts such as MD5, SHA1, and SHA256 hashes, assuming you’ve enabled all hash types with sysmon -c -n -l -h md5,sha1,sha256. TekCollect also parses out all domains, URLs, IPs, and executables noted in the Sysmon log. The IPs should match your Sysmon Event ID 3s (Network Connection) quite nicely. I also found the SHA1 for this sample, dc965d0a38505001c800049a6c39817aec3616f0, in the Sysmon_Parse SHA1 text results, so clearly that TekCollect parser works well.
In this case, we’re curious to determine if haho.exe used CreateRemoteThread by filtering for Event ID 8. The answer is, of course; an example result reads as follows:
19564,2015-11-05 02:07:21,8,Microsoft-Windows-Sysmon,WIN-QN9NR3Q1MNR,S-1-5-18,2015-11-05 02:07:21.631|{2F96EDF1-B473-563A-0000-00106D1E1000}|1756|C:UsersmalmanAppDataRoamingIbnehaho.exe|{2F96EDF1-B9D8-563A-0000-0010BF9B2000}|568|C:WindowsSysWOW64WerFault.exe|1008|0x00000000000A45E0||
The source PID is 1756, the source image is our Kryptik friend haho.exe the target PID is 568 and the target image is WerFault.exe, used for Windows Error Reporting. 
CreateRemoteThread tracking is a great addition to Sysmon, already an outstanding tool.

Wrap Up

You’ve got a lot to take a look at packed in here. In addition to the Sysinternals updates, Sysmon_Parse and it’s dependencies give you a lot to consider, or reconsider, for your DFIR toolkit.
You’ve gotten a look at using them all to inspect a host pwned by a Kryptik/Zbot sample and learned that you can quickly discover quite a bit about malware behavior using just a few simple but powerful tools. Hopefully your inspired to grab this sample (I’ll send it to you if you ask), and experiment with this excellent collection of DFIR goodness.

Ping me via email or Twitter if you have questions: russ at holisticinfosec dot org or @holisticinfosec.

Cheers…until next month. Continue reading toolsmith #110: Sysinternals vs Kryptic

toolsmith: Sysmon 2.0 & EventViz

Prerequisites
Windows operating system
R 3.1.2 and RStudio for EventViz
Congratulations and well done to Josh Sokol for winning 2014 Toolsmith Tool of the Year with his very popular SimpleRisk!
Overview
Sysmon 2.0 was welcomed to the world on 19 JAN 2015, warranting immediate attention as part of The State of Cybersecurity focus for February’s ISSA Journal. If you want to better understand the state of cybersecurity on your Windows systems, consider System Monitor (Sysmon) a requirement. Sysmon is “a Windows system service and device driver that, once installed on a system, remains resident across system reboots to monitor and log system activity to the Windows event log. It provides detailed information about process creations, network connections, and changes to file creation time.” The real upside is that you can ship related events using Windows Event Collection or the agent provided as part of your preferred SIEM implementation. You can also conduct simple exports of EVTX files during forensic or malware runtime analysis for parsing and queries. I built EventViz in R, as a Shiny app, to simplify this process and read CSV exports from Windows Event Viewer. It’s a work in progress to be certain, but one you can make immediate use of in order to pivot on key data in Sysmon logs.
I pinged Thomas Garnier, who along with Microsoft Azure CTO Mark Russinovich, created Sysmon. Thomas pointed out that the need to understand our networks, how they are used or abused, has never been higher. He also reminded us that, unfortunately, there is a gap between the information needed by network defenders and the information provided by operating systems across versions. To that end, “Sysinternals Sysmon was created to provide rich information across OS versions while running in the background staying resident across reboots. It provides detailed information on process creation, image loading, driver loading, network connections and more. It allows you to easily filter generated events and update its configuration while it is still running. All the activities are captured in the Windows event log to integrate with existing Windows Event Collection or SIEM solutions.
Of the eight Event IDs generated by Sysmon, you can consider six immediately useful for enhancing situational awareness and strengthened defenses. You’ll want to tune and optimize how you configure Sysmon so you don’t flood your logging systems with data you determine later isn’t as helpful as you hoped. The resulting events can be quite noisy given the plethora of data made available per the following quick event overview:
·         Event ID 1: Process creation
o   The process creation event provides extended information about a newly created process.
·         Event ID 2: A process changed a file creation time
o   The change file creation time event is registered when a file creation time is explicitly modified by a process. Attackers may change the file creation time of a backdoor to make it look like it was installed with the operating system, but many processes legitimately change the creation time of a file.
·         Event ID 3: Network connection
o   The network connection event logs TCP/UDP connections on the machine. It is disabled by default.
·         Event ID 4: Sysmon service state changed
o   The service state change event reports the state of the Sysmon service (started or stopped).
·         Event ID 5: Process terminated
o   The process terminate event reports when a process terminates.
·         Event ID 6: Driver loaded
o   The driver loaded events provides information about a driver being loaded on the system.
·         Event ID 7: Image loaded
o   The image loaded event logs when a module is loaded in a specific process. This event is disabled by default and needs to be configured with the –l option.
I love enabling the monitoring of images loaded during malware and forensic analysis but as the Sysmon content says, “this event should be configured carefully, as monitoring all image load events will generate a large number of events.” I’ll show you these Event IDs come to play during review of a system compromised by a Trojan:Win32/Beaugrit.gen!AAA sampleusing EventViz to analyze Sysmon logs. Beaugrit.gen is a rootkit that makes outbound connections to request data and download files while also interacting with Internet Explorer.
Sysmon installation
I had the best luck downloading Sysmon and unpacking it into a temp directory.  From an administrator command prompt I changed directory to the temp directory and first ran Sysmon.exe -accepteula –i. This accepts the EULA, installs Sysmon as a service, and drops Sysmon.exe in C:Windows, making it available at any command prompt path. I exited the first administrator command prompt, spawned another one, and ran sysmon –m.  This step installs the event manifest, which helps you avoid verbose and erroneous log messages such as “The description for Event ID 5 from source Microsoft-Windows-Sysmon cannot be found.” I followed that with sysmon -c -n -l -h md5,sha1,sha256. The -c flag updates the existing configuration, -nenables logging of network connections (Event ID 3), -l enables logging the loading (can be noisy) of modules (Event ID 7), and -h defines what hashes you wish to collect as part of event messaging. You may be happier with just one hash type configured to again reduce volume. Once installed and properly configured you’ll find Sysmon logs in the Event Viewer under Applications and Services Logs | Microsoft | Windows | Sysmon | Operational as seen in Figure 1.
Figure 1 – Sysmon Operational log entries in Event Viewer

The physical system path is %SystemRoot%System32WinevtLogsMicrosoft-Windows-Sysmon%4Operational.evtx. You can optionally define configuration preferences with a config.xml file, refer to Sysmon documentation for specifics. To create Sysmon CSV files that can be analyzed with EventViz, right click the Operational log as seen in Figure 1 and Save All Event As sysmon.csv. The will result in a CSV version of all Sysmon log entries written to the system your analyzing. Remember that all Windows event logs are set to 65536KB and to overwrite as needed by default. You’ll likely want to factor for updating this to ensure an appropriately sized log sample in order to conduct proper investigations, particularly if you’re not shipping the logs off system.

Analysis with EventViz
Collecting logs is one thing but making quick use of them is the real trick. There are so many ways and means with which to review and respond to particular events as defined by detection and rules logic. Piping Sysmon logs to your collection mechanism is highly recommended. Windows Event Collection/Windows Event Forwarding are incredibly useful, the results of which can be consumed by numerous commercial products. Additionally there are free and open source frameworks that you can leverage. Enterprise Log Search and Archive (ELSA) immediately comes to mind as does the ELK stack (Elasticsearch, Logstash, Kibana). See Josh Lewis’ Advanced ThreatDetection with Sysmon, WEF and Elasticsearch (AKA Panther Detect) as a great reference and pointer.
There are also excellent uses for Sysmon that don’t require enterprise collection methods. You may have single instances of dedicated or virtual hosts that are utilized for runtime analysis of malware and/or other malfeasance. I utilized just such a Windows 7 SP1 virtual machine to test Sysmon capabilities with the above mentioned Beaugrit.gen sample. You can of course utilize the built-in Windows Event Viewer but ease of use and quick pivots and queries are not its strong suit. I’ve started on EventViz to address this issue and plan to keep developing against it. For folks with an appreciation for R, this is a nice exemplar for its use. If you need a good primer on using R for information security-related purposes, I’ve got you covered there. In January, ADMIN Magazine published my article SecurityData Analytics and Visualization with R, which is a convenient and directly useful way for you to get your feet wet with R.
Use of EventViz currently assumes you’ve got a version of R installed, as well as RStudio. At an RStudio console prompt be sure to run install.packages(“shiny”)as EventViz is a Shiny app that requires the Shiny package. Create a directory where you’d plan to store R scripts, and create an apps directory therein, and an EventVizdirectory in the apps directory. Mine is C:codingRappsEventViz as an example. Copy server.R and ui.R, as well as the example CSV file we’re discussing here, to the EventVizdirectory; you can download them from my Github EventViz repository.  Open server.Rand ui.R and click Run App as seen in Figure 2.
Figure 2 – Run the EventViz Shiny app
Give it a few minutes it may take a bit to load as it is a crowded log set given the verbosity of Event ID 7 (Image loaded), again, enable it with caution. I’m working on EventViz performance with larger files but you’ll see how Event ID 7 helps us here though. Once it’s loaded you’ll have Figure 3 in a Shiny window. You also have the option to open it in a browser.
Figure 3 – EventViz UI
Each of the drop-down menus represents a column heading in the sysmon.csv albeit with a little manipulation via R where I renamed them and added a header for the messages column.
I’ll work with a bit of insider knowledge given my familiarity with the malware sample but as long as you have a potential indicator of compromise (IOC) such as an IP address or malicious executable name you can get started. I knew that the sample phones home to 920zl.com. When I conducted a lookup on this domain (malicious) it returned an IP address of 124.207.29.185 in Beijing. You may now imagine my shocked face. Let’s start our results analysis and visualization with that IP address. I copied it to the EventViz search field and it quickly filter two results from 9270 entries as seen in Figure 4. This filter is much faster than the initial app load as the whole data set is now immediately available in memory. This is both a benefit and a curse with R. It’s performant once loaded but a memory hog thereafter and it’s not well known for cleaning up after itself.
Figure 4 – EventViz IP address search results
Sysmon Event ID 3 which logs detected network connections trapped C:tmpserver.exemaking a connection to our suspect IP address. Nice, now we have a new pivot options. You could use the Event ID drop-down to filter for all Event ID 3’s for all network connections. I chose to filter Sysmon Event ID 7 and searched server.exe. The results directly matched Virus Total behavioral information for this sample, specifically the runtime DLLs. Sysmon’s Event ID 7 ImageLoad logic clearly shows server.exe acting as indicated by VirusTotal per Figure 5. 
Figure 5 – EventID 7 ImageLoad matches VirusTotal
Drill in via Event ID 1 ProcessCreate and you’ll find that server.exewas spawned by explorer.exe. The victim (me) clicked it (derp). There are endless filter and pivot options given the data provided by Sysmon and quick filter capabilities in EventViz. Eventually (pun intended), EventViz will allow you to also analyze other Windows event log types such as the Security log.
In Conclusion
Sysmon clearly goes above and beyond default Window event logging by offering insightful and detailed event data. Coupled with collection and SIEM deployments, Sysmon can be an incredible weapon as part of your detection logic. Marry your queries up with specific threat indicators and you may be both pleased and horrified (in a good way) with the results. Watch the TechNet blog and the Sysinternals site for further updates to Sysmon. For quick reviews during runtime analysis or dirty forensics a viewer such as EventViz might be useful assuming you export to your Sysmon EVTX file to CSV. Keep an eye on the Github site for improvements and updates. I plan to add a file selector so you can choose from a directory of CSV files. For other feature requests you can submit via Github.
Ping me via email or Twitter if you have questions (russ at holisticinfosec dot org or @holisticinfosec).
Cheers…until next month.

Acknowledgements 
Thomas Garnier, Sysmon 2.0 developer

Continue reading toolsmith: Sysmon 2.0 & EventViz