Kansa: Powershell profiles potentially hazardous

On the very day I published my previous post, Kansa: Collecting WMI Event Consumer backdoors, Mark Russinovich announced the release of a new version of Autoruns that collects WMI related ASEPs. I had a chance to play around with it on a machine with a WMI Event Consumer, Event Filter and Filter-to-Consumer Binding configured and indeed, Autoruns now picks up the Event Consumers. I still recommend using Kansa's Get-WMIEvtFilter.ps1 and Get-WMIFltConBind.ps1 collector modules to grab the other two essential pieces that make Event Consumer backdoors possible. The Event Filter is the piece that will tell you what triggers the Event Consumer.

In this post I want to cover another "auto start extension point" or ASEP and it happens to be another that is not covered by Autoruns, yet. It also happens to be specific to Powershell. The Windows Powershell Profile is a script that runs, if present, each time a user or SYSTEM opens a Powershell shell. It's akin to a .bash_profile or similar shell profile on *nix systems.

Adversaries can modify an existing Powershell profile for either a user or the default system profile, planting code enabling them to maintain persistence or perform any task that Powershell is capable of given the context of the script (non-administrator users obviously being less capable than administrators or SYSTEM).

Kansa's Get-PSProfiles.ps1 collector will enumerate local accounts on remote systems and check each of them for Powershell profiles. Where Powershell profiles exist, Get-PSProfiles will collect them all in a zip file (it will also check for and collect the default Powershell profile). The zip file will then be sent back to the host where Kansa was run.

Powershell profiles can be located in a few different locations. For user profiles, they are in:

$env:userprofile\Documents\WindowsPowershell\Microsoft.Powershell_profile.ps1

And the default system profile is in:

$env:windir\System32\WindowsPowershell\v1.0\Microsoft.Powershell_profile.ps1

User Powershell profiles on XP systems are in a slightly different path and Kansa will not acquire them.

Unfortunately, there's no quick way of analyzing the collected profile scripts for malicious capabilities, at least not that I'm aware of. Analysts will have to spend time reviewing profiles for suspect code. This is a good time to mention that any ASEP script, not just Powershell profiles could be modified by adversaries to perform nefarious actions.

This is another painful reminder of the asymmetry of information security. Adversaries have many places to hide malicious bits and may only need one (or none, if they have a big enough key ring of credentials). Incident responders, depending on the nature of the incident, may have to review every known ASEP.

Enjoy the code review and happy hunting!

How quickly we forget

Date: Thu, 8 Jan 2009 08:26:45 -0800 (PST)
From: Rob Lee
Reply-To: Rob Lee
Subject: Re: [GCFA] Compiling evidence boils down to a matter of time
To: Dave Hull
Cc: GCFA
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-496094974-1231432005=:13648"
Message-ID: <1401.13648.qm@web42107.mail.mud.yahoo.com>

--0-496094974-1231432005=:13648
Content-Type: text/plain; charset=us-ascii

Done. That takes care of Windows 7 and Window Server 2008. Can you verify it can adjust all four timestamps or just a few of them? We can then add that to our list of known default programs. Also, can you document how it is used and what traces are left in its use?

What type of beer do you like and what is the next SANS conference you will be at?

--Rob


______________________________________________________________________________________________





________________________________
From: Dave Hull
To: Rob Lee
Cc: GCFA
Sent: Thursday, January 8, 2009 11:11:17 AM
Subject: Re: [GCFA] [HTCC] Compiling evidence boils down to a matter of time

Interesting thread. Windows 7 and Windows Server 2008 ship with
Powershell. Powershell can be used to modify timestamps. See this
entry on my blog for more info:

http://trustedsignal.blogspot.com/search/label/timestamps

Where's my six pack? ;)

--
Dave Hull
Trusted Signal
CISSP, GCFA, GCIH, GREM, SSP-MPA, CHFI
Public key: http://trustedsignal.com/pubkey.txt
Fingerprint: 4B2B F3AD A9C2 B4E1 CBDF B86F D360 D00F C18D C71B

"Great minds discuss ideas; Average minds discuss events; Small minds
discuss people." -- Eleanor Roosevelt

--0-496094974-1231432005=:13648

Touch on Windows via PowerShell

A forensic investigator recently inquired about a touch equivalent for the Windows environment. If you don't know touch is a command in the *nix environment that allows you to modify file timestamps arbitrarily.

My first thought was that maybe wmic could accomplish the task. Turns out wmic can only read timestamps, not set them.

More digging revealed that Microsoft's PowerShell could be used to modify file timestamps.

Below is the nitty and the gritty.

From within powershell:

$(Get-Item ).creationtime=$(Get-Date "mm/dd/yyyy hh:mm am/pm")
$(Get-Item ).lastaccesstime=$(Get-Date "mm/dd/yyyy hh:mm am/pm")
$(Get-Item ).lastwritetime=$(Get-Date "mm/dd/yyyy hh:mm am/pm")

There are also utc timestamp attributes (CreationTimeUtc, etc.). I
haven't touched (no pun intended) those.

Here's a sample run from my PowerShell prompt (PS>):

PS > date

Thursday, August 14, 2008 9:38:47 am

PS> echo > test.txt

PS> dir
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 8/14/2008 9:38 AM 0 test.txt

PS>$(get-item test.txt).lastwritetime=$(get-date "08/31/2012")

PS>dir
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 8/31/2012 12:00 AM 0 test.txt


You can use these commands to change timestamps such that their
CreationTime is later than their other timestamps.

Fun stuff.