Sunday, October 2, 2016

Leveraging WMIC for 'live' Remote forensics

This is a continuation of the previous post. As a result, to get the most of this post you should review the previous post.

The idea here is that that you learned a host in your infrastructure is running "VBoxService.exe". You would now like to know if there are other hosts within your environment that is running the same process. To figure out what is going on we can first try the following.

C:\>WMIC /Node:127.0.0.1,10.0.2.15 PROCESS WHERE Name="VBoxService.exe" GET CSName, Name, ExecutablePath, ProcessID, ParentProcessID


From the above, we see we were able to look across hosts 127.0.0.1 and 10.0.2.15 to identify which hosts may be running the "VBoxService.exe" process. However, the problem with this method is its not quite scalable. Imagine appending (or prepending) IPs to the list. This can become a major problem to manage.

The alternative (which is better) is to provide WMIC a list of IPs in a file and let it read the values from the file.

Let's try the previous command again. This time by providing an input file.

I've created a file named "myNodes.txt" which contains the 2 IPs we just used. Below shows the file and its contents.






Now let's run this against WMIC.
C:\>WMIC /Node:127.0.0.1,10.0.2.15 PROCESS WHERE Name="VBoxService.exe" GET CSName, Name, ExecutablePath, ProcessID, ParentProcessID

The output above shows that host "SECURITYNIK-XP" (note the 2 instances of it because basically I was targeting the same system from two different IPs) has the process running.

From the above image, we see that by adding a list of IPs to a file, we were able to determine where a particular process is running within an infrastructure.



Go ahead and try to see how you can leverage WMIC in your environment if you have not been doing so already

Well that's it for this post!

Leveraging WMIC for local 'live' forensics

Let's assume, that you as the incident responder within your office sitting, sipping on some coffee or whatever else you do at the office. Then all of a sudden, you get a call that says, "hey it looks like something is wrong with my computer". So you got up from your desk to see what's going on and decide to leverage the WMIC utility which is built into Microsoft Windows operating system. Leveraging WMIC is helpful because there is no need for any additional tools which are not part of the OS.

So now that you are there, the first thing you decide to do ... after taking a memory dump ... is to run WMIC to get the system name. Let's do that.

C:\>WMIC COMPUTERSYSTEM LIST BRIEF

While this provided helpful information there was more we could have gotten if we had run
C:\>WMIC COMPUTERSYSTEM LIST FULL
However, the previous command would give us probably a little bit more than we need at this time. As a result, let's be picky about the information we would like.

C:\>WMIC COMPUTERSYSTEM GET Domain, Model, Name, PartOfDomain, UserName, SystemType, TotalPhysicalMemory

From the above we see we were able to extract the Domain the computer is in, its name, whether or not it is part of a domain, the username of the currently logged in user, the system type and the total physical memory.

Looks like we at least know a little about the system. Hope you are documenting your steps so far :-)

 Let's look to see what programs are running
 C:\>WMIC PROCESS LIST BRIEF

While the above image shows very useful information, there is still a bit that is left out.

If we were to use the "C:\>WMIC PROCESS LIST FULL" we would get lots of information. More than we need. Let's focus in on the information which would probably be helpful.

C:\>WMIC PROCESS GET Name, ExecutablePath, HandleCount, ProcessID, ParentProcessID

From the above we see we have a nice view which now includes the executable path of the process. We also have the handle count which shows the number of handles which the process has opened. Additionally, we see the process id and parent process id. This is much more useful information.

So now that we've identified the list of processes, let's take a specific process and gather all the information available for it.
C:\>WMIC PROCESS WHERE Processid=824 LIST FULL


From the above we see that we've learned all the information that is available for a specific process

For the rest of the way, we will use "LIST BRIEF", "LIST FULL" AND "GET" as needed. We already know we can get some information from "list brief" and a lot from "list full". However, it is best if we target the information which may be useful to us at for this investigation.

Let's find out the users who are currently created on the system..

C:\>WMIC USERACCOUNT GET Caption, FullName, Name

Now that we have the list of users on the system. Let's take a look at their network login information

C:\>WMIC NETLOGIN GET FullName, UserID, LastLogon, Name, UserType

From the above we were able to grab the logged on user name, full name, last logon and user type

Ok. I will stop now. The idea was to show that you can leverage WMIC which is built into Windows to gather information which you would have typically gathered from other tools, some built into Windows while some are 3rd party.

See the next post for information on leveraging WMIC for "live" remote forensics.

Ahhhh ... That Google interview process - interesting and exciting


Recently I was reached out to for a role within Google as a Manager within its Detection Team. After completing the phone interview, I was invited to be onsite at its office in Mountain View, California. The experience of the onsite interview is something I will appreciate for a very long time.

It started with an interview with a senior leader within Google, then I headed off to lunch with my potential manager. After lunch I had 3 interviews with 4 persons back to back to back consisting of various managers within and around my potential working area. These interviews challenged me in a few instances but generally was interesting but not overly overwhelming.


While it was not overwhelming, there were a few technical areas which I just don't do on a daily basis and was not as sharp at, while there were others which has never been my primary or secondary focus during my career. While most of the questions tried to focus on my thought process, there are just topics in life (like some technical stuff) which you just can't add logic to and if you did, you may seem ignorant about the topic.

While in the end I was not offered the job, I am still flattered that Google thought I was interesting enough to consider making me part of their team. It did massage my ego ;-)

So what's the take away for you if you looking to go work for Google?
If you are interested in working for Google and do get yourself through the door, ensure you are prepared and basically that you know your stuff. While you may be going for one specific role, be prepared for questions that may come on the outskirts of the areas you are being interviewed for. Remember Google is an engineering company :-)

Some other links that may be helpful in preparing you for your Google interview.