Any Powershell gurus here?

  • SpinRite v6.1 Release #3
    Guest:
    The 3rd release of SpinRite v6.1 is published and may be obtained by all SpinRite v6.0 owners at the SpinRite v6.1 Pre-Release page. (SpinRite will shortly be officially updated to v6.1 so this page will be renamed.) The primary new feature, and the reason for this release, was the discovery of memory problems in some systems that were affecting SpinRite's operation. So SpinRite now incorporates a built-in test of the system's memory. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
    /Steve.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in please checkout the “Tips & Tricks” page for some very handy tips!

    /Steve.
  • BootAble – FreeDOS boot testing freeware

    To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.

    GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.

    The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.

    You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.

    (You may permanently close this reminder with the 'X' in the upper right.)

airchie

Member
Nov 9, 2020
14
13
Hi guys,

As part of my SOC Analyst role I often come across malicious PS scripts.
I often have to try to deobfuscate them before I can try to work out what they're doing which is one of the questions I want to ask.
Once I have deobfuscated them enough to get a feel for what they're doing, they almost always create a new browsing object to download a malicious payload.

So I have a couple of questions I'd like to pose tot he group:
1. Is there any easy way to get scripts deobfuscated?
The machine obviously needs to deobfuscate them to know which cmdlets to invoke with which parameters etc.

2. Is there any way to "disable" or monitor specific cmdlets?
Particularly the ones that create new web objects?

Thanks in advance. :)
 
Hi Archie.
Were I in your shoes I would start with a execution-policy change.
Powershell 101.
Know who has rights to run a script.
PS C:\Windows> Get-ExecutionPolicy -List

Scope ExecutionPolicy
----- ---------------
MachinePolicy Undefined
UserPolicy Undefined
Process Undefined
CurrentUser Undefined
LocalMachine Bypass

Now set that policy by scope of user.
Set-ExecutionPolicy -ExecutionPolicy Restricted -Scope CurrentUser

Needless to say the this is a big hammer and its going to make sysadmin jobs tougher.
Stop it all,,, where you can,, and at least the target get much smaller.

Monitoring command-lets.
Try adding Start-Transcript to the default profile.
Assuming "they" dont think about Stopping it, This should capture all actions performed in a PS instance.

Tel
 
Upvote 0
  • Like
Reactions: Telmeanius
Upvote 0
Agree, you could change the execution policy. You could also try to setup a way to scrape and report on the Powershell event logs.
 
Upvote 0
I cannot answer the OP original question. But, as a simple one person end user, I prefer to disable PowerShell completely although I haven't actually done that in Win 7. But, my feeling is that I just don't need the functionality nor the attack surface. Same as Java years ago. Of course, this may not actually be possible. If it's possible, in corporate settings, this may not be practical.

May your bits be stable and your interfaces be fast. :cool: Ron
 
Upvote 0
A lot of rmm(remote management) services and applications use Powershell. You can, however, set ACL's(still learning how myself) though in most enterprise applications you run a Powershell script via an rmm agent and disable remote PowerShell altogether. Dato and Pulseway both use Powershell scripts but run them locally via the agent with secure transfer of the script.
 
  • Like
Reactions: rfrazier
Upvote 0