Artifact Sweeping with Audit & Remediation (Part 1)
Recently I was participating in a session with one of our customers discussing about Security and how they leverage Carbon Black in their environment. One part that stood out to me and I have abridged below...
RM - What parts of the product are really important to you?
Customer - query and live response comes into play. We do those queries, find those artifacts that are associated with the adversary, collect more information, sweep the environment, ensure that you know the same artifacts are not appearing across the company.
The bit that really struck me was the use of Audit and Remediation to sweep the environment after an event, looking for artifacts that may have been left across the estate. The clue is in the name ‘Remediation’, yet we seem to talk about this in terms of Live Response, gaining access to an endpoint to take immediate action and collect forensics. What we do not do such a wonderful job of is talking about Live Query, it is assumed that this falls more under the ‘Audit’ banner. Live Query is a massively valuable tool in our armory, it strikes me that the more you use it the more you see other avenues to use it, you are bound only by your own imagination.
So, I would like to try and redress the balance in some small way and start the discussion, what are artifacts and how can we use Live Query to sweep our environment looking for them?
Artifact: A piece of data that may or may not be relevant to the investigation / response. Examples include registry keys, files, time stamps, and event logs.
Live Query: Live Query is based on osquery, which exposes an operating system as a high-performance relational database that can be queried for operating system data. Live Query allows the administrator to query current state/config/properties of one or more endpoints. Live Query uses SQL syntax to query data, which is executed on the endpoint and returned to the backend.
As part of our investigations using Carbon Black Enterprise EDR (Endpoint Detection and Response) or Endpoint Standard to Threat hunt we will have gathered information pertaining to an adversary’s activity. Look at any of our TAU-TIN threat reports and you will invariably see a list of sha256, Indicators of Compromise (IOC’s). This is one of the easiest to quantify, a file was run or downloaded, and this is the hash of that file. But how do we search across all our endpoints for that file?
Note that by default a query will run against all endpoints, you can specify a policy or individual endpoints as highlighted.
In this example we have requested the path and sha256 columns from the hash table where any file in c:\temp or sub-directories matches the sha256 hash.
NB. It is best practice not to run these scans across the entire C: drive, we have inbuilt CPU, memory, and time limits on scans to prevent them causing undue performance overheads on a system, too broad a scan is likely to timeout.
During our research we might identify a registry key that provides a marker to activity. This example is looking for a specific scheduled task, note I am marking a field reg_key_present as true or false in the results.
TIP: We cannot search HKEY_CURRENT_USER as osquery does not run in the user context, instead search HKEY_USERS.
There are two tables which are useful for looking for any kind of persistence, ‘scheduled_tasks’ which is exactly as the name suggests and ‘autoexec’ which includes scheduled tasks, drivers, startup items, any executable that is set to auto start. The output is quite verbose, so you need to have identified the task you are looking for <WHERE NAME LIKE ‘%artifact name’;> for example. Anyone looking to maintain persistence in an environment will be tempted by the lure of scheduled tasks, keep an eye on them.
On another occasion you may identify a domain name, again these are often seen in TAU-TIN reports and are commonly used as IOC’s. Any malware beaconing out to Command and Control will likely use DNS (Domain Name Services) for IP resolution, this gives us the opportunity to spot them putting their head above the parapet. OSQuery has a DNS cache table
That relies on a recent lookup, within the last day, but even if this is an historic investigation with the correct DNS logging in place on the clients, we could search the Windows Event Logs for patterns of activity.
Searching the Windows Event Logs does not stop there, this is a wonderful place to find information, for example services stopped, logon events, software uninstalled, even the act of clearing the event log can be seen as an artifact and identified by the Security Event ID 1102.
Recently we also gained the ability to perform Yara searches on endpoints using the Yara table in OSQuery. This is a great open-source security tool, a quick search will reveal loads of information and rules to help identify different families of malware for example. At a basic level Yara enables us to search for patterns within files, so a file hash is quite easily changed and often malware will change dynamically to avoid signature detection based on traditional AV (Anti-Virus) hash matching, but patterns within files or matching based on a file's behavior is much harder to change.
Let us look at an example. I took the Mimikatz software from GitHub and using PeStudio identified the strings m.i.m.i.k.a.t.z and http://blog.gentilkiwi.com/mimikatz. Then using HxD, a Hex editor I searched the files and converted the strings into their Hex equivalent, ‘6D 00 69 00 6D 00 69 00 6B 00 61 00 74 00 7A’ and ‘68 74 74 70 3A 2F 2F 62 6C 6F 67 2E 67 65 6E 74 69 6C 6B 69 77 69 2E 63 6F 6D 2F 6D 69 6D 69 6B 61 74 7A’
I then identified four behaviors of the file, these I just randomly selected, none particularly bad on its own but when all present in the same file worth noting and in this instance an IOC (indicators of compromise) for Mimikatz. Again, each string converted to Hex using HxD.
LsaRetrievePrivateData - ‘4C 73 61 52 65 74 72 69 65 76 65 50 72 69 76 61 74 65 44 61 74 61’
SamEnumerateUsersInDomain - ‘53 61 6D 45 6E 75 6D 65 72 61 74 65 55 73 65 72 73 49 6E 44 6F 6D 61 69 6E’
ClearEventLog - ‘43 6C 65 61 72 45 76 65 6E 74 4C 6F 67’
CreateProcessWithLogon - ‘43 72 65 61 74 65 50 72 6F 63 65 73 73 57 69 74 68 4C 6F 67 6F 6E’
Putting this all together with a condition the below rule is looking for a file with mimikatz referenced inside i.e. either pattern a1 or a2, OR any 3 of the 4 behaviors I highlighted. So why would a genuine file want to pull Local Security Credentials, list all Domain users and Clear the Windows Event logs?
Note how some of the DLLs for example, must have the mimikatz wording embedded into them but the executables also match the patterns of behavior (strings b1-4).
As with the hash searching discussed earlier, the best practice is to think about the time and resource limitations, running a lot of rules at once or searching the entire file structure on a drive will highly likely timeout.
I also said earlier that I would like to start a discussion, sure there are other artifacts, there are different and better ways to find Yara patterns, there are ways to automate everything I discussed (watch this space) so let us hear about them, if you have a great use case and this has in any way piqued your interest, please, please let us know.
In the next blog I will address some Linux and Mac use cases
Associated Content
From the action bar MORE button.