(I) Powershell logging, what everyone needs to know about it

Powershell is, well powerful. Microsoft is making Powershell the future of Windows Management starting with Windows Server 2012. For us security peeps, Powershell is capable of doing a LOT of security tasks, like Ben Ten, @Ben0xA showed at his Powershell workshop at BSidesDFW. With all the capabilities Powershell has leveraging .NET, you and the hackers can do just about anything!

So how do we monitor and defend against such a powerful hacker tool? MetaSploit and the Social Engineering Toolkit uses Powershell as does PowerCat, a Powershell netcat tool. Powershell is used since commands can be executed and no files are dropped on disk, unless you want to, making it VERY hard to detect... Or is it hard to detect?

You log it, that's how. But alas, Microsoft does not enable what you need by default so you must do some work to get the commands properly logged. If Powershell is executed you will see EventID 4688, but that only tells you Powershell executed, not what was executed. We security peeps need more details, but first execute a few Powershell commands and look at the logs. see any command lines???? Nope...

If you want to improve your security posture and protect against Powershell misuse and abuse, and just plain know what the heck is going on with Powershell in your environment, give this a test drive.

1. Create an All User profile (profile.ps1) so you can enable some global variables
2. Enable two global variables so Powershell will log what is entered at the Command Line
3. Increase the size of the two PowerShell Logs
4. Gather the two PowerShell logs
5. Enable file auditing to profile.ps1 so you know if anyone changes the default profile! Most important in case the bad guys look for, modify and/or delete it.

#1. Create profile.ps1 in \Windows\System32\WindowsPowerShell\v1.0. Add something to the beginning of the profile so you know the profile is working, for example; change the drive letter to D:, assuming you have one, or echo a Reg Rey or write a Reg Key entry (great to log for later).

#2. Add the following two variables to your profile.ps1
a) $LogCommandHealthEvent = $true
b) $LogCommandLifecycleEvent = $true

Sample profile.ps1
----------------------

CD D:\
$LogCommandHealthEvent = $true
$LogCommandLifecycleEvent = $true

WARNING: If you use usernames and passwords in Powershell scripts, this will show them in the logs. Of course you know to rotate these Creds frequently

#3. Increase the size of the Powershell logs so they collect a LOT of stuff. Do this by opening Event Viewer, navigate to "Applications and Services Logs" right-click and selecting properties of the logs "Windows Powershell" and "Microsoft\Windows\Powershell\Operational" logs, increase their sizes and be generous.

#4. Gather the Powershell logs however you can, through wevtutil, Powershell, or a log agent like Splunk. Below I have included a Splunk query for harvesting Powershell commands being executed, enjoy.

#5. Enable File Auditing on the profile.ps1 file for any changes or deletion so you can alert on this condition in case the bad guys modify and/or delete your default profile. Do this by right clicking on the profile.ps1 file in Explorer, selecting Security, Advanced, Auditing, Continue, Add, type Everyone, Check Names, OK and then select the following properties:
a) Create Files
b) Write Attributes
c) Delete
d) Change permissions
e) Take ownership

Now you will audit any changes, ownership and deletions to the profile.ps1 file. Look in Event Viewer for EventID 4663 Accesses = DELETE and Accesses = WriteData. Test it!



And there you have it, go ahead and test your new settings and execute some Powershell commands and see how it logs unlike before so you can catch your Pentesters, hackers or nefarious admins using Powershell for more than just administration.

For you Splunkers, here is a query I threw together to monitor what Powershell Command Line parameters are being used. Filter out the good to look for the bad.

1. Add Powershell to your inputs.conf (tweak as needed)

[WinEventLog:Microsoft-Windows-PowerShell/Operational]
disabled = false

[WinEventLog:Windows PowerShell]
disabled = 0
start_from = oldest
current_only = 0
checkpointInterval = 5

2. Create a query like the following:

index=* LogName="*Powershell*" | eval Message=split(Message,". ") | eval Message=mvindex(Message,0) | eval MessageA=split(_raw,"Details:") | eval Message1=mvindex(MessageA,1) | eval Message1 = replace (Message1,"[\n\r]","!!") | eval MessageC=split(Message1,"!!") | eval Message2=mvindex(MessageC,2) | eval Message3=mvindex(MessageC,3) | eval Message4=mvindex(MessageC,4) | eval Message4=split(Message4,"=") | eval PS_Ver=mvindex(Message4,1) | eval Message5=mvindex(MessageC,5) | eval Message6=mvindex(MessageC,6) | eval Message6=split(Message6,"=") | eval Engine_Ver=mvindex(Message6,1) | eval Message7=mvindex(MessageC,7) | eval Message8=mvindex(MessageC,8) | eval Message8=split(Message8,"=") | eval PLine_ID=mvindex(Message8,1) | eval Message9=mvindex(MessageC,9) | eval Message9=split(Message9,"=") | eval Command_Name=mvindex(Message9,1) | eval Message10=mvindex(MessageC,10) | eval Message10=split(Message10,"=") | eval Command_Type=mvindex(Message10,1) | eval Message11=mvindex(MessageC,11) | eval Message11=split(Message11,"=") | eval Script_Name=mvindex(Message11,1) | eval Message12=mvindex(MessageC,12) | eval Message12=split(Message12,"=") | eval Command_Path=mvindex(Message12,1) | eval Message13=mvindex(MessageC,13) | eval Message13=split(Message13,"=") | eval Command_Line=mvindex(Message13,1) | table _time, host, ComputerName, TaskCategory, EventCode, Message, PS_Ver, Engine_Ver, PLine_ID, Command_Name, Command_Type, Script_Name, Command_Path, Command_Line

I split my raw logs versus using RegEx as they are more readable in the future and by others. Powershell logs use a strange end of line carriage return, so another Splunk Ninja Tip on parsing Splunk Logs.

Use SplunkStorm for FREE and test it out!!

Happy PowerLogging!!!

#InfoSec #HackerHurricanel

(I) Malware Management takes care of variants like Backoff.C!tr.spy

We all knew variants of BackOff would occur and infections spreading to other retailers and PoS machines.

By practicing the process of Malware Management you can keep up with variants of malware as they are discovered and reports or Blogs written. Then you can tweak your scripts and tools to detect the variants.


As we expected the Malware would move from mimicking Adobe and Java to being random named directories and random named files. Remember, Malware Management is about the known and unknown, so locations used are key to look for new things of any names and filter out the knowns.

The new variant of BackOff uses the Run key gain persistence and launch and uses ports 443 to talk to various domains, guaranteed to change, but notice they are .ru for you network NetFlow geeks.


If you are practicing Malware Management, using "Sha1Deep64 -r", a script, tool, file auditing in logs or my favorite defensive tool BigFix, you can look for any new directories and files being dropped in this location, common for all the PoS malware discovered thus far and detect the new variant fast!

Fortinet Blog on BackOff variant

Fortinet details on BackOff variant

#InfoSec #HackerHurricane

(I) BlackEnergy - you guessed it, more Malware Management goodness trying to act like Adobe

When is something that looks like Adobe, not Adobe? When it's Malware of course.

Like the BackOff malware BlackEnergy also tries to fool the user or admins and hide as an Adobe application. See a pattern yet?

BlackEnergy uses similar user based areas to store the malware, but also uses the Windows structure as well!

BlackEnergy is a great example of the Malware Management Framework working yet again. There is something interesting about the malware that I may not have covered before in regards to the Windows directories that is important.

First off, yet again AppData is getting used for file drops. Unlike BackOff which used AppData\Roaming (%AppData%), BlackEnergy uses the %LocalAppData% variable which points to the users AppData\Local directory and in this case creates a directory called "Adobe" to drop the three .DAT and one .SOL files. Even more interesting, it drops five additional .DAT files into \Windows\System32\Drivers!

Why is this interesting for Malware Management? The Windows \Drivers directory contains mostly .SYS files and only 3 other odd file types. So if you were looking at five new .DAT files in your script/tool output, this should strike you as odd and warrant an investigation. On top of the fact the malware dropped similar .DAT files in \AppData\Local\Adobe.

BlackEnergy used the AutoRuns Startup folder to launch the malware, a typical place to look if you are an a incident Responder or Blue Team defender. The important take-away for BlackEnergy is to focus on NEW file types that are not like what is already there, in this case .SYS files.

You should then automatically look to see if any of these .DAT files are executables (Starting with MZ) and thus realize instantly they are bad if they are executables. Using 'Sigcheck -e' is great way to check to see if a file is an executable as many malware files are called by the launcher and named just about anything, but are indeed executables, which is bad.

So yet another example of Malware Management being applied to improve your security posture.


SecureList Research on BlackEnergy

#InfoSec #HackerHurricane