Powershell: Active User on Target?

In Powershell, if you're investigating a remote box, you can easily determine if there's an active session, but how do you find out if the user's actually sitting at the desk or not?

Easy, sort of... here are some tips:

To determine if there's a session on the box:

Get-WMIObject win32_LoggedOnUser

We could also run:

wmic /node:"workstation_name" COMPUTER GET USERNAME

If you omit the "/node" arg, it will perform the query locally. Additionally, on pre-Windows 8, there's the qwinsta command.

If there is a user logged in, we can determine if the the user is most likely sitting in front of the workstation with the following:

Get-Process -name explorer.exe

Since explorer.exe is the process that runs the graphical user interface, it's a safe bet to assume someone is logged in.  If the Explorer process doesn't exist, then there should be an instance of the logonui process:

get-process -name logonui.exe

If a logonui.exe process is present, this indicates that the logon screen is present.  If the win32_LoggedOnUser class or wmic query returns a user AND logonui is present, that very most likely means the workstation is locked.

Creating Simple x64 Shellcode

Save this as shell.asm

global _start

_start:
    jmp short        shell_call    ; jump to call

shellcode:
    pop        rsi        ; Store address of "/bin/sh" in ESI
    xor        rax, rax    ; Zero
    mov byte    [rsi + 7],al    ; Null byte
    mov qword    [rsi + 8],rsi    ;
    mov qword    [rsi + 16],rax    ; Null pointer
    lea        rdi, [rsi]    ; Copy sh string into rdi
    lea        rsi, [rax]    ; Third execve (Null)
    lea        rdx, [eax]     ; Second execve arg (Null)
    xor        al, 0x3b    ; x64 execve syscall
    syscall

shell_call:
    call    shellcode    ; call shellcode and push db onto stack
    db    "/bin/sh"

Assemble the asm file with nasm:
nasm -f elf64 shell.asm -o shell.o

You can view the assembly code by dumping the object file with objdump:
objdump -D shell.o

You can test the functionality of the shellcode by linking the file into an executable.  Due to the way the ASM code is written,  I specified -N to make the .text section read/write:

ld -N -o shell shell.o

Malware Analysis: Re-writing a File Header (Magic Bytes)

Here are a couple of examples of how to re-write a file header.  Note: these are actual JPG's so the JFIF portion of the header will still be intact.  The point is the re-write of the first two bytes of the file.

Say, if you run into a situation where malware is downloaded as one file type, but subsequently rewritten on the target infection point for the sake of bypassing defense mechanisms.

In the first example, we use xxd to examine the first two bytes of a file.  In this case, the file is presented as a .JPG, but suppose it's actually an executable.  In order to analyze the file, we overwrite the header from its current state of ff d8 to 4d 5a.

Here, we've piped the 4d 5a bytes into dd, overwriting the first two bytes of the already-existing an.jpg file, specifying a byte size of 1 and a count of 2.  We can verify the over-write worked by re-running the xxd command to look at the first two bytes.

We can also use Python's print functionality:

In Powershell, the process is almost as simple.  First, read the file into a byte array with the system.io assembly, then overwrite the 0 and 1 position bytes and write the array back to disk. Verify with get-content that the ordinals returned are 77 and 90.  :

Installing Kali Tools on Windows 10 Subsystem for Linux

If you haven't been keeping up with the times, let me learn ya a little sumpin' sumpin'.  There is meow a bash/linux/Ubuntu environment in Windows 10.  I've played with it a little thus far and have been pretty impressed.  For one reason or another, if you're a security practitioner, you may be interested in Kali tools for the sweet, new Subsystem for Linux in Windows.  While there are still some bugs, it's still fun to play with.  I've broken down the instructions to get Kali's tools up and running on the environment, which is Ubuntu-flavored.  The instructions are in layman's terms for those of you that may not be as experienced, but want to learn anyways. Also, the instructions are brief to cut straight to the chase.  As general overview, what needs to happen is: enable the subsystem, turn on developer mode, update the system, and lastly, use Katoolin to install Kali tools.

Before beginning, make sure your Windows 10 build is on the latest build and up-to-date.

Enable the Windows Subsystem for Linux
From the Windows Menu Type Powershell, right click the Powershell icon and select "Run as Administrator", then run the following command to enable the subsystem

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux 

After, perform the requested reboot.

Turn on Developer Mode in Windows
From the Windows Menu,
1. Type Settings and click to open the control panel
2. Select Update & Security 
3. On the next screen, left side, select "For Developers"

Enter the Bash Environment
1. Type "bash" and hit enter.  Boom! You're in!

Installing Kali tools
You'll want to use the Katoolin script that automates the install of Kali tools on an Ubuntu distro, which is what the bash environment is based on.

Install the Git client and Update
This should now be installed by default, but if it's not for whatever reason, do it manually.
1. sudo apt-get install git 
2. sudo apt-get update

Install Python
Oddly enough, Python wasn't installed on my initial install. You'll need it for Katoolin (let alone Kali).

sudo apt-get install python

Download (clone) the Katoolin package/script
1. sudo git clone https://github.com/LionSec/katoolin.git

As an optional step/side note, if you intend to run Katoolin in the future for update purposes, you can copy it to the /usr/bin directory.

   a. sudo cp katoolin/katoolin.py /usr/bin/katoolin

   Make it executable
   b. sudo chmod +x /usr/bin/katoolin

Running Katoolin 
Once you've successfully cloned Katoolin, change into the katoolin directory and make the katoolin.py script executable.
Note: the katoolin directory is in the directory you were in when you performed the clone command.

1. cd katoolin
2. chmod +x katoolin.py
3. python katoolin.py

You should have this pretty screen:

4. Type 1 and hit enter to select "Add Kali repositories & Update".  
5. Type 1 and hit enter again to select "Add kali linux repositories"

From here, there's a menu option to view your sources.list, which is where the script adds your Kali repository.  Alternatively, you can run 

cat /etc/apt/sources.list and you should see the following lines added:

# Kali linux repositories | Added by Katoolin

deb http://http.kali.org/kali kali-rolling main contrib non-free

Note: If you run the Katoolin script multiple times, it doesn't check to see if it has already updated the file.  It blindly drops another round of lines, which will throw some warnings when you update, but won't mess anything up.

Sweet! You've added the repos, which will allow you to update the Kali tools over time. 

6.  Type "back" and hit enter to return to the main menu.  

7.  Type 2 and hit enter to select "View categories"

8.  You can pick and choose, what packages you want to install, but I went ahead and nuked the site from orbit and selected 0 to install all. Why would you not?

By this point everything should be installing.  It'll take a while to get everything installed:

Whammy! You're done!

An extra note:  I tested a few tools and they worked.  Others didn't.  Nmap for example, didn't :( I haven't had the chance to dig in and figure out exactly why.  I'm sure there's still a lot of porting that needs to happen, but this is an awesome start!

I hope this was helpful.  If you come across any issues, please be sure to drop a comment and I'll update the instructions accordingly.  

Forensics: Parsing Lnk Files with Powershell

Content moved to my new blog. Please visit: https://www.justcyberythings.com/blog/2018/6/12/forensics-parsing-lnk-files-with-powershell

ProTip: Avoid "Credential Stuffing" Attacks

The other day I was thinking about how easy it would be to compromise a large amount of user accounts all over the internet that were associated with data breaches.  After that random thought a few days later, ironically, I read this article (published a little over a week ago):
http://www.bankinfosecurity.com/hacker-group-31337-dumps-data-stolen-from-mandiant-analyst-a-10160

The cyber security industry refers to this as "credential stuffing." With this type of attack, a hacker essentially takes your credentials and re-uses them in an attempt to gain access to other sites that you have an account with.  I've always known it was a possibility, but I had never really thought of the technical requirements to pull it off.  When I did stop to think about it, it literally took me less than a minute to conclude that Stevie Wonder could probably do this with a spoon.  Which leads me to why I'm doing this quick write-up.

I'm going to try to keep this as close to layman's terms as possible for understand-ability.  So, if you feel like you need to chime in with the mathematics on password entropy, don't.  Piss up a rope instead.

This is for my homies out there.

The Skinny

By default, humans hate managing passwords.  You have your personal accounts, work accounts and all of them have annoying password policies.  There have been a few cases where I've literally wanted to find the security engineer of the website and punch him/her in the face.  With that said, there's a tendency for us to use the same passwords across multiple sites.  Doing so definitely makes your life easier, but in the likely event of a data breach, you've exposed yourself to being e-fondled by dudes who are better at the internet than you are.  Typically, what happens when a data breach occurs and your account is compromised, that information is either dumped on sites like PasteBin or sold on the black market for bad guys to do with the data as they choose.  Sometimes, the passwords are in clear text, sometimes they need to be cracked, which isn't the toughest feat nowadays.  Now, a few words on the implications over time.

Even if you change the password associated with your user account after finding out that site was compromised, you're not in the clear.  Before I continue, stop and think about how many different sites you use the same username (most often your e-mail address) and password...

Yup, thought so.

So, you changed your password after the breach.  You're good to go, right? Wrong.  The issue is: it's pretty trivial to take that compromised username and password combination, feed it into a script and spray it at a long list of websites.  This is essentially a "bot" that takes the username and password you had during the time of the breach and tries to log in to a long list of websites.  These attacks aren't very complicated either.  Literally, a middle schooler with some programming expertise could pull it off to some degree.  Yes, there are mitigating controls out there such as multi-factor authentication, but not all sites use them.

Think about it: In the LinkedIn breach alone, it was reported that somewhere around 6.5 million accounts were leaked.  If I took those 6.5 million credentials and sprayed them at a list of 100 popular websites, how many log in attempts would be successful?  Yeah, it's hard to quantify, but the number sure wouldn't be anything close to zero.  For the hacker, it's essentially a lotto, but with much better odds than a scratch off.

Tips and Things to Consider

• Don't get complacent and use the same password for every site you have an account with.  If you absolutely have to be lazy, at least use a subset of passwords so a hacker doesn't have credentials for all of your accounts if one site is breached.

• Password length is generally a better rule-of-thumb.  When feasible, use length and complexity, but again, if you insist on being lazy, lengthy passwords are better than short complex ones. Example: "My Anaconda don't want none unless you got buns, hun!" is less likely to get cracked that "pIcKl3s!!"

• Just because the username and password associated with a breached website doesn't mean much to you, keep in mind that for a hacker, it could be used as a stepping stone to gather intelligence on you, which could subsequently assist them in compromising your other accounts that do have value to you; e.g., you have a profile that has your biography information in it.  Hackers can use this to guess passwords for other sites, or answer security questions.

• Don't get stuck with "favorite" passwords.  Just because a significant amount of time has passed since a breach occurred that you were a victim to, doesn't mean it's safe to use at some later time.  Hackers know this, and will wait for some arbitrary amount of time before re-attempting a login with those credentials.

• Go to https://haveibeenpwned.com/ and see if you've been apart of any breach.  The site maintains a list of accounts that have been associated with past breaches.  If you're on that list (which you probably are) that should be enough to convince you that you should rotate passwords over time.

• There are password managers out there that you can use to help manage all of your passwords, but keep in mind they're targets for hackers and the implications are pretty obvious if it's compromised. 

Stay safe out there.