Securing telnet connections with stunnel

Telnet is a client-server protocol that connects to a remote server through TCP over port 23. Telnet does not encrypt data and is considered insecure and passwords can be easily sniffed because data is sent in the clear. However there are still legacy systems that need to use it. This is where stunnel comes to the rescue.

Stunnel is designed to add SSL encryption to programs that have insecure connection protocols. This article shows you how to use it, with telnet as an example.

Server Installation

Install stunnel along with the telnet server and client using sudo:

sudo dnf -y install stunnel telnet-server telnet

Add a firewall rule, entering your password when prompted:

firewall-cmd --add-service=telnet --perm
firewall-cmd --reload

Next, generate an RSA private key and an SSL certificate:

openssl genrsa 2048 > stunnel.key
openssl req -new -key stunnel.key -x509 -days 90 -out stunnel.crt

You will be prompted for the following information one line at a time. When asked for Common Name you must enter the correct host name or IP address, but everything else you can skip through by hitting the Enter key.

You are about to be asked to enter information that will be
incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [XX]:
State or Province Name (full name) []:
Locality Name (eg, city) [Default City]:
Organization Name (eg, company) [Default Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:
Email Address []

Merge the RSA key and SSL certificate into a single .pem file, and copy that to the SSL certificate directory:

cat stunnel.crt stunnel.key > stunnel.pem
sudo cp stunnel.pem /etc/pki/tls/certs/

Now it’s time to define the service and the ports to use for encrypting your connection. Choose a port that is not already in use. This example uses port 450 for tunneling telnet. Edit or create the /etc/stunnel/telnet.conf file:

cert = /etc/pki/tls/certs/stunnel.pem
sslVersion = TLSv1
chroot = /var/run/stunnel
setuid = nobody
setgid = nobody
pid = /
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
accept = 450
connect = 23

The accept option is the port the server will listen to for incoming telnet requests. The connect option is the internal port the telnet server listens to.

Next, make a copy of the systemd unit file that allows you to override the packaged version:

sudo cp /usr/lib/systemd/system/stunnel.service /etc/systemd/system

Edit the /etc/systemd/system/stunnel.service file to add two lines. These lines create a chroot jail for the service when it starts.

Description=TLS tunnel for network daemons

ExecStartPre=-/usr/bin/mkdir /var/run/stunnel
ExecStartPre=/usr/bin/chown -R nobody:nobody /var/run/stunnel


Next, configure SELinux to listen to telnet on the new port you just specified:

sudo semanage port -a -t telnetd_port_t -p tcp 450

Finally, add a new firewall rule:

firewall-cmd --add-port=450/tcp --perm
firewall-cmd --reload

Now you can enable and start telnet and stunnel.

systemctl enable telnet.socket stunnel@telnet.service --now

A note on the systemctl command is in order. Systemd and the stunnel package provide an additional template unit file by default. The template lets you drop multiple configuration files for stunnel into /etc/stunnel, and use the filename to start the service. For instance, if you had a foobar.conf file, you could start that instance of stunnel with systemctl start stunnel@foobar.service, without having to write any unit files yourself.

If you want, you can set this stunnel template service to start on boot:

systemctl enable stunnel@telnet.service

Client Installation

This part of the article assumes you are logged in as a normal user (with sudo privileges) on the client system. Install stunnel and the telnet client:

dnf -y install stunnel telnet

Copy the stunnel.pem file from the remote server to your client /etc/pki/tls/certs directory. In this example, the IP address of the remote telnet server is

sudo scp myuser@

Create the /etc/stunnel/telnet.conf file:

cert = /etc/pki/tls/certs/stunnel.pem

The accept option is the port that will be used for telnet sessions. The connect option is the IP address of your remote server and the port it’s listening on.

Next, enable and start stunnel:

systemctl enable stunnel@telnet.service --now

Test your connection. Since you have a connection established, you will telnet to localhost instead of the hostname or IP address of the remote telnet server:

[user@client ~]$ telnet localhost 450
Trying ::1...
telnet: connect to address ::1: Connection refused
Connected to localhost.
Escape character is '^]'.

Kernel 5.0.9-301.fc30.x86_64 on an x86_64 (0)
server login: myuser
Password: XXXXXXX
Last login: Sun May  5 14:28:22 from localhost
[myuser@server ~]$

3 investments Microsoft is making to improve identity management

As a large enterprise with global reach, Microsoft has the same security risks as its customers. We have a distributed, mobile workforce who access corporate resources from external networks. Many individuals struggle to remember complex passwords or reuse one password across many accounts, which makes them vulnerable to attackers. As Microsoft has embraced digital transformation for our own business, we shifted to a security strategy that places strong employee identities at the center. Many of our customers are on a similar journey and may find value in our current identity management approach.

Our goal is to reduce the risk of compromised identity and empower people to be efficient and agile whether they’re on our network or not.

Our identity management solutions focus on three key areas:

Read on for more details for each of these investment areas, advice on scaling your investment to meet your budget, and a wrap-up of some key insights that can help you smoothly implement new policies.

Securing administrator accounts

Our administrators have access to Microsoft’s most sensitive data and systems, which makes them a target of attackers. To improve protection of our organization, it’s important to limit the number of people who have privileged access and implement elevated controls for when, how, and where administrator accounts can be used. This helps reduce the odds that a malicious actor will gain access.

There are three practices that we advise:

  • Secure devices—Establish a separate device for administrative tasks that is updated and patched with the most recent software and operating system. Set the security controls at high levels and prevent administrative tasks from being executed remotely.
  • Isolated identity—Issue an administrator identity from a separate namespace or forest that cannot access the internet and is different from the user’s information worker identity. Our administrators are required to use a smartcard to access this account.
  • Non-persistent access—Provide zero rights by default to administration accounts. Require that they request just-in-time (JIT) privileges that gives them access for a finite amount of time and logs it in a system.

Budget allocations may limit the amount that you can invest in these three areas; however, we still recommend that you do all three at the level that makes sense for your organization. Calibrate the level of security controls on the secure device to meet your risk profile.

Eliminating passwords

The security community has recognized for several years that passwords are not safe. Users struggle to create and remember dozens of complex passwords, and attackers excel at acquiring passwords through methods like password spray attacks and phishing. When Microsoft first explored the use of Multi-Factor Authentication (MFA) for our workforce, we issued smartcards to each employee. This was a very secure authentication method; however, it was cumbersome for employees. They found workarounds, such as forwarding work email to a personal account, that made us less safe.

Eventually we realized that eliminating passwords was a much better solution. This drove home an important lesson: as you institute policies to improve security, always remember that a great user experience is critical for adoption.

Here are steps you can take to prepare for a password-less world:

  • Enforce MFA—Conform to the fast identity online (FIDO) 2.0 standard, so you can require a PIN and a biometric for authentication rather than a password. Windows Hello is one good example, but choose the MFA method that works for your organization.
  • Reduce legacy authentication workflows—Place apps that require passwords into a separate user access portal and migrate users to modern authentication flows most of the time. At Microsoft only 10 percent of our users enter a password on a given day.
  • Remove passwords—Create consistency across Active Directory and Azure Active Directory (Azure AD) to enable administrators to remove passwords from identity directory.

Simplifying identity provisioning

We believe the most underrated identity management step you can take is to simplify identity provisioning. Set up your identities with access to exactly the right systems and tools. If you provide too much access, you put the organization at risk if the identity becomes compromised. However, under-provisioning may encourage people to request access for more than they need in order to avoid requesting permission again.

We take these two approaches:

  • Set up role-based access—Identify the systems, tools, and resources that each role needs to do their job. Establish access rules that make it easy to give a new user the right permissions when you set up their account or they change roles.
  • Establish an identity governance process—Make sure that as people move roles they don’t carry forward access they no longer need.

Establishing the right access for each role is so important that if you are only able to follow one of our recommendations focus on identity provisioning and lifecycle management.

What we learned

As you take steps to improve your identity management, keep in mind the following lessons Microsoft has learned along the way:

  • Enterprise-level cultural shifts—Getting the technology and hardware resources for a more secure enterprise can be difficult. Getting people to modify their behavior is even harder. To successfully roll out a new initiative, plan for enterprise-level cultural shifts.
  • Beyond the device—Strong identity management works hand-in-hand with healthy devices.
  • Security starts at provisioning—Don’t put governance off until later. Identity governance is crucial to ensure that companies of all sizes can audit the access privileges of all accounts. Invest early in capabilities that give the right people access to the right things at the right time.
  • User experience—We found that if you combine user experience factors with security best practices, you get the best outcome.

Learn more

For more details on how identity management fits within the overall Microsoft security framework and our roadmap forward, watch the Speaking of security: Identity management webinar.

Use udica to build SELinux policy for containers

While modern IT environments move towards Linux containers, the need to secure these environments is as relevant as ever. Containers are a process isolation technology. While containers can be a defense mechanism, they only excel when combined with SELinux.

Fedora SELinux engineering built a new standalone tool, udica, to generate SELinux policy profiles for containers by automatically inspecting them. This article focuses on why udica is needed in the container world, and how it makes SELinux and containers work better together. You’ll find examples of SELinux separation for containers that let you avoid turning protection off because the generic SELinux type container_t is too tight. With udica you can easily customize the policy with limited SELinux policy writing skills.

SELinux technology

SELinux is a security technology that brings proactive security to Linux systems. It’s a labeling system that assigns a label to all subjects (processes and users) and objects (files, directories, sockets, etc.). These labels are then used in a security policy that controls access throughout the system. It’s important to mention that what’s not allowed in an SELinux security policy is denied by default. The policy rules are enforced by the kernel. This security technology has been in use on Fedora for several years. A real example of such a rule is:

allow httpd_t httpd_log_t: file { append create getattr ioctl lock open read setattr };

The rule allows any process labeled as httpd_t to create, append, read and lock files labeled as httpd_log_t. Using the ps command, you can list all processes with their labels:

$ ps -efZ | grep httpd
system_u:system_r:httpd_t:s0 root 13911 1 0 Apr14 ? 00:05:14 /usr/sbin/httpd -DFOREGROUND

To see which objects are labeled as httpd_log_t, use semanage:

# semanage fcontext -l | grep httpd_log_t
/var/log/httpd(/.)? all files system_u:object_r:httpd_log_t:s0
/var/log/nginx(/.)? all files system_u:object_r:httpd_log_t:s0

The SELinux security policy for Fedora is shipped in the selinux-policyRPM package.

SELinux vs. containers

In Fedora, the container-selinux RPM package provides a generic SELinux policy for all containers started by engines like podman or docker. Its main purposes are to protect the host system against a container process, and to separate containers from each other. For instance, containers confined by SELinux with the process type container_t can only read/execute files in /usr and write to container_file_t files type on host file system. To prevent attacks by containers on each other, Multi-Category Security (MCS) is used.

Using only one generic policy for containers is problematic, because of the huge variety of container usage. On one hand, the default container type (container_t) is often too strict. For example:

  • Fedora SilverBlue needs containers to read/write a user’s home directory
  • Fluentd project needs containers to be able to read logs in the /var/log directory

On the other hand, the default container type could be too loose for certain use cases:

  • It has no SELinux network controls — all container processes can bind to any network port
  • It has no SELinux control on Linux capabilities — all container processes can use all capabilities

There is one solution to handle both use cases: write a custom SELinux security policy for the container. This can be tricky, because SELinux expertise is required. For this purpose, the udica tool was created.

Introducing udica

Udica generates SELinux security profiles for containers. Its concept is based on the “block inheritance” feature inside the common intermediate language (CIL) supported by SELinux userspace. The tool creates a policy that combines:

  • Rules inherited from specified CIL blocks (templates), and
  • Rules discovered by inspection of container JSON file, which contains mountpoints and ports definitions

You can load the final policy immediately, or move it to another system to load into the kernel. Here’s an example, using a container that:

  • Mounts /home as read only
  • Mounts /var/spool as read/write
  • Exposes port tcp/21

The container starts with this command:

# podman run -v /home:/home:ro -v /var/spool:/var/spool:rw -p 21:21 -it fedora bash

The default container type (container_t) doesn’t allow any of these three actions. To prove it, you could use the sesearch tool to query that the allow rules are present on system:

# sesearch -A -s container_t -t home_root_t -c dir -p read 

There’s no allow rule present that lets a process labeled as container_t access a directory labeled home_root_t (like the /home directory). The same situation occurs with /var/spool, which is labeled var_spool_t:

# sesearch -A -s container_t -t var_spool_t -c dir -p read

On the other hand, the default policy completely allows network access.

# sesearch -A -s container_t -t port_type -c tcp_socket
allow container_net_domain port_type:tcp_socket { name_bind name_connect recv_msg send_msg };
allow sandbox_net_domain port_type:tcp_socket { name_bind name_connect recv_msg send_msg };

Securing the container

It would be great to restrict this access and allow the container to bind just on TCP port 21 or with the same label. Imagine you find an example container using podman ps whose ID is 37a3635afb8f:

# podman ps -q

You can now inspect the container and pass the inspection file to the udica tool. The name for the new policy is my_container.

# podman inspect 37a3635afb8f > container.json
# udica -j container.json my_container
Policy my_container with container id 37a3635afb8f created!

Please load these modules using:
# semodule -i my_container.cil /usr/share/udica/templates/{base_container.cil,net_container.cil,home_container.cil}

Restart the container with: "--security-opt label=type:my_container.process" parameter

That’s it! You just created a custom SELinux security policy for the example container. Now you can load this policy into the kernel and make it active. The udica output above even tells you the command to use:

# semodule -i my_container.cil /usr/share/udica/templates/{base_container.cil,net_container.cil,home_container.cil}

Now you must restart the container to allow the container engine to use the new custom policy:

# podman run --security-opt label=type:my_container.process -v /home:/home:ro -v /var/spool:/var/spool:rw -p 21:21 -it fedora bash

The example container is now running in the newly created my_container.process SELinux process type:

# ps -efZ | grep my_container.process
unconfined_u:system_r:container_runtime_t:s0-s0:c0.c1023 root 2275 434 1 13:49 pts/1 00:00:00 podman run --security-opt label=type:my_container.process -v /home:/home:ro -v /var/spool:/var/spool:rw -p 21:21 -it fedora bash
system_u:system_r:my_container.process:s0:c270,c963 root 2317 2305 0 13:49 pts/0 00:00:00 bash

Seeing the results

The command sesearch now shows allow rules for accessing /home and /var/spool:

# sesearch -A -s my_container.process -t home_root_t -c dir -p read
allow my_container.process home_root_t:dir { getattr ioctl lock open read search };
# sesearch -A -s my_container.process -t var_spool_t -c dir -p read
allow my_container.process var_spool_t:dir { add_name getattr ioctl lock open read remove_name search write }

The new custom SELinux policy also allows my_container.process to bind only to TCP/UDP ports labeled the same as TCP port 21:

# semanage port -l | grep 21 | grep ftp
ftp_port_t tcp 21, 989, 990
# sesearch -A -s my_container.process -c tcp_socket -p name_bind
allow my_container.process ftp_port_t:tcp_socket name_bind;


The udica tool helps you create SELinux policies for containers based on an inspection file without any SELinux expertise required. Now you can increase the security of containerized environments. Sources are available on GitHub, and an RPM package is available in Fedora repositories for Fedora 28 and later.

Photo by Samuel Zeller on Unsplash.


Oversharing and safety in the age of social media

Many years ago, I worked with healthcare organizations to install infrastructure to support the modernization of their information systems. As I traversed hospitals – both in public and private sectors – I was often struck by one particular best practice: the privacy reminders were ubiquitous. If I stepped into an elevator or walked down a hallway, there was signage to remind everyone about patient privacy. Nothing was left to chance or interpretation. This was also pre-social media, so the concerns ranged from public conversations or inappropriate use of email, to leaving a document on a public printer.

Fast forward to 2019. Our society and culture have changed. We are much freer with our personal information on social media. We talk openly about our lives and post pictures and family information in the wild. We are less concerned about our privacy, as we use these platforms to connect with others – a connection we might be denied given our busy lives. However, as has oft been written, these platforms can be a cache of riches for someone seeking to steal your identity or compromise your email and other accounts. This same type of free flow of information is also following us to other parts of our lives and making it easier for the bad guys to attack and profit. Let me explain with a few examples.

I travel a bit (okay, a lot). While my global travel is mostly for work, this provides an informative world lens for people watching and listening. I am often between flights in an airport reading or catching up on email and overhear a wide variety of conversations – without even trying. Recently, I was in the U.S., delayed at the Chicago O’Hare airport for several hours as “there is (was) weather in Chicago,” the worst phrase in the US travel industry. I overheard a man on the phone discussing his declined credit card in detail, including his full name, billing ZIP code, card number, expiration date, and so on. My shock quickly faded when I started thinking about how many other times I was in public and overheard things that could lead to financial or IP or other loss for an individual or company. The number is non-trivial. That’s when I decided to tweet some simple advice, and solicit input via my twitter feed.

The results were equally horrifying and amusing. Some even thought my post was an attempt in social engineering. Overall, the response convinced me to write a blog as the evidence I gathered suggests this isn’t a small problem. Rather, it’s a real problem. So let me start by sharing some examples and then make some suggestions (which may seem obvious to many of you) on how to protect your privacy and security.

So how do you protect yourself from theft of personal or proprietary company information in public? The super obvious, somewhat flippant answer is: don’t share any of this type of information in public. But, at times, this is easier said than done. If you travel as much as I do, it becomes impossible to refrain from conducting some confidential business whilst you are on the road. So how do you actually protect yourself?

Many people will read this blog and say, “well that’s obvious,” but sadly it is not, based on what I have personally observed and the feedback I received in preparation for this post. When in these types of situations, my recommendations are:

  • Use privacy screens on your laptop and your phone when in public, in meetings, and on airplanes. I cannot tell you how much confidential information I could have obtained just sitting behind someone on a plane.
  • Do not discuss confidential information in a public place: restaurant, club, elevator, airplane, etc. Based on the Twitter solicited feedback, people somehow think planes are cones of silence.
  • If you must conduct personal/confidential business on the road, wait until you arrive at your hotel or find a quiet place in the airport/club/restaurant where your back is to a wall and you can see anyone who is located by you. Use your best judgment.
  • Never give anyone your password. I don’t know how to say this more strongly. Do not ever give anyone your password.
  • Use a password manager. Don’t reuse passwords. This way if someone does obtain one of your passwords, you limit your exposure.
  • Be cognizant of what you put on social media. I am very active on social media but, remember, your information can and will be used against you. Be careful of when and how you post to avoid advertising when your home will be vacant for vacation or any personally identifiable information that could expose your passwords.
  • If someone calls you claiming to be from your bank, the IRS, the police, your company, a tech support organization, offer to call them back from a number that is published on their legitimate website or the back of your credit card, etc. Do not give any confidential information to an inbound caller.
  • Use encryption for sensitive data and sensitive communications.
  • If you must install IoT devices at home, segment them to a unique network.
  • If you are renting a private vacation home, there are some very good apps to scan the network to make certain you have privacy (e.g., cameras in a location that was not disclosed by the owner)
  • I am not a fan – at all – of listening devices at home, but if you do have one, remember there is a possibility we will find out all of your conversations were recorded. Be aware of what you say….

The world is quickly evolving as we embrace more technology. The onus is largely on users to protect yourselves. While this blog is just a high-level discussion on social engineering and privacy, using common sense is always your best defense.


Introducing Security Policy Advisor—a new service to manage your Office 365 security policies

Securing your users has never been more important, or more difficult. For many, it’s become a scramble to simply stay ahead of the latest threats. And all too often the complexity and variety of the security solutions themselves only adds to your burden. What most people really need is someone to help shoulder the load. We hear you. And that’s why we’re taking steps to provide new, easy-to-use capabilities that support you as you protect the people, apps, devices, and data in your organizations.

Today, we’re excited to announce the public preview of Security Policy Advisorthe first in a series of security investments to further strengthen the apps in Office 365 ProPlus. Security Policy Advisor is a service that offers an easier, more effective way to manage your security policies. It provides custom policy recommendations, supported with rich data insights into how these policies would impact your group’s use of features in Officeallowing you to make decisions with full information.

Simplify policy management across devices

Earlier today, we announced the release of our new Office cloud policy service, an easy-to-use cloud-based tool that allows you to define policies for Office 365 ProPlus and assign them to users via Azure Active Directory groups. Once defined, policies are automatically enforced as individuals sign in. What’s more, Office cloud policy service extends your reach to managed and unmanaged devices without requiring any on-premises infrastructure or modern device management services. If you have a BYOD policy or users who occasionally sign in to Office 365 ProPlus from other devices, you’re covered.

Manage and monitor policy configurations with confidence

Now, we’re building on this service to help you secure your organization with confidence, taking the guesswork out of configuring security policies. In the past, the burden fell to you alone to determine if a particular policy would help or hurt a specific group. Setting macro policies, for example, involved numerous group policy objects (GPOs), each with multiple settings, detailed yet always too generic security baseline studies, and cumbersome deployment. And in the end, you still had to wait for frustrated support calls to know the user impact.

Security Policy Advisor changes the game with knowledge already available within your organization. It analyzes how individuals use Office and then recommends specific policies to boost your security profile. Even better, for each recommendation, you can see how people would be impacted, giving you greater confidence in choosing policies that are right for your environment. It may recommend, for example, disabling VBA macros in Word or macros in Excel files from the web—providing relevant threat intelligence (if available) and identifying just how frequently individuals in your group use those features and would be impacted by the policy.

When you’re ready, you can apply policies at the app, feature, or group level—all with one click.

The job doesn’t end once a policy is applied. In a dynamic workplace needs evolve, groups change, and a set of policies that worked just months ago may actually become a hinderance. Security Policy Advisor actively monitors policy impact on your employees, highlighting areas worth your attention or suggesting changes if needed. If you’ve enabled individuals to override specific policies, you’ll see how this is used. With cloud-based management, you can update or even roll back at the push of a button.

And rest assured: if you are currently using GPOs, they can run in parallel with any changes you make with the Office cloud policy service. Existing policies are retained and, if there are any conflicts, policies you apply via Office cloud policy service will always take precedence.

See what Security Policy Advisor recommends for you

Security Policy Advisor is now available in preview in English (en-us) with broad availability in coming weeks. If you’re an administrator in an organization that has deployed Office 365 ProPlus, you can start right now by signing in to the Office client management portal and configuring Office policies. For each configuration you create and assign to a group, you’ll receive recommendations with supporting data that you can review and deploy to users as a policy. Visit Tech Community for additional information and documentation.

This is just the beginning of a set of new security capabilities we’re working on for ProPlus. We’re looking forward to hearing your feedback, and we’ll have more to share with you later this year.


How to steer clear of tax scams

In the month of February, we saw an average of 300,000 phishing attempts across Microsoft’s browsing platforms daily. Our security experts expect these attempted scams to become increasingly more prevalent through the April 15 Tax Day, especially in the two weeks leading up to it, when about 25 percent of people file their taxes. The phishing campaigns we’ve seen aren’t just in the U.S., though; we’ve also recently uncovered similar tactics in Canada, Brazil and India. It’s important for users across the globe to follow best practices and stay vigilant.

With less than a month until the filing deadline in the U.S., we are urging the public to take the following simple steps to avoid tax scams – especially during the last-minute rush to file taxes.

  • Watch for suspicious emails. Be suspicious of all links and attachments, especially when the email seems “off” or unexpected – like an unexpected email from your credit card company, or financial institution. Phish-y emails often include spelling and grammatical errors, or will ask you to send personal information. In these cases, you can apply additional scrutiny on the sender, the content, and any links and attachments. If you know the sender, for example, you can double-check with them before opening or downloading the file.
  • Carefully inspect URLs. Hover over links to verify that the URL goes to the website where it’s supposed to direct you. Is it pointing to the site you expected? URL shorteners provide a lot of convenience, but can make this inspection difficult. If you’re unsure, rather than clicking a link, use search engines like Bing to get to the tax-related website you’re looking for and log in from there.
We recently discovered a phishing campaign targeting Canadian Tax payers where scammers were pretending to help Canadian taxpayers get their refunds, but really aimed to steal banking credentials. We’ve also seen old phishing documents resurface – these claim to be from the Canada Revenue Agency (CRA), inform victims that they have a refund via e-transfer from the CRA, and ask them to divulge their bank details where the funds will be “deposited”. We’ve also seen similar campaigns in Brazil and India.
  • Be wary of any attachments. If you haven’t just made a purchase for tax software, don’t be tricked by getting an email with an invoice from a tax preparation company. Sending fake invoices for services is one of the top methods attackers use to trick people into opening a malicious attachment that could automatically execute malware on your computer. Malicious attachments could also contain links that download and execute malicious programs. We’ve seen PDFs that contain innocuous-looking links that lead to people accidentally downloading malicious software designed to steal credentials, like usernames and passwords.
  • Don’t rely on passwords alone. Scammers take advantage of weak or stolen passwords used across multiple websites, so don’t just rely on your password to keep you safe. When possible, always use multi-factor authentication like the Microsoft Authenticator app for managing your sign-ins for Microsoft accounts and others, and Windows Hello for easy and secure sign-in to your Windows 10 device. These solutions enable biometric authentications like your face or fingerprint to quickly and safely sign in across devices, apps and browsers without you having to remember passwords. Did you know that with a Microsoft Account, you can securely and automatically sign-in to other Microsoft cloud-based applications including Bing, MSN, Cortana,, Xbox Live (PC only), Microsoft Store and Office?
  • Keep software current. Run a modern operating system, like Windows 10 or Windows 10 in S mode, with the latest security and feature updates, in tandem with next-generation anti-malware protection, such as Windows Defender Antivirus.

Microsoft security solutions can proactively inspect links and attachments, as well as block phishing documents and other malicious downloads to help protect users, even if they accidentally click a phishing link or open a malicious attachment. We expect tax scams to be on the rise in the next several months as global tax deadlines approach so our experts will be on the lookout for new campaigns.

Here’s a couple of examples of what we’ve seen just in the last few weeks: two documents named irs_scanned_551712.doc and Tax(IP.PIN).doc. You’ll notice that the security tools built into Microsoft Office caught these and displayed a warning at the top. Before enabling content like these, ensure that the sender is a trusted source, and notice things like missing or misspelled words.

tax-related phishing document with malicious macro code

tax-related phishing document with malicious macro code

Be on the lookout for scams like we’ve described here. There will undoubtedly be more schemes that crop up. Stay vigilant! Learn how to report phishing scam websites through Microsoft Edge or Internet Explorer and suspicious email messages through, Outlook 2016, or Office 365.

Keep these tips and tricks handy, and share with your networks so we can increase awareness of and stop the spread of Tax Day scams! For more information about Microsoft Security, please visit

New capabilities announced for Azure Security Center

Microsoft Azure Security Center—the central hub for monitoring and protecting against related incidents within Azure—has released new capabilities. The following features—announced at Hannover Messe 2019—are now generally available for the Azure Security Center:

  • Advanced Threat Protection for Azure Storage—Layer of protection that helps customers detect and respond to potential threats on their storage account as they occur—without having to be an expert in security.
  • Regulatory compliance dashboard—Helps Security Center customers streamline their compliance process by providing insight into their compliance posture for a set of supported standards and regulations.
  • Support for Virtual Machine Scale Sets (VMSS)—Easily monitor the security posture of your VMSS with security recommendations.
  • Dedicated Hardware Security Module (HSM) service, now available in U.K., Canada, and Australia—Provides cryptographic key storage in Azure and meets the most stringent customer security and compliance requirements.
  • Azure disk encryption support for VMSS—Now Azure disk encryption can be enabled for Windows and Linux VMSS in Azure public regions—enabling customers to help protect and safeguard the VMSS data at rest using industry standard encryption technology.

In addition, support for virtual machine sets are now generally available as part of the Azure Security Center. To learn more, read our Azure blog.


Microsoft Graph Security Hackathon winners announced

Bringing together information from multiple disconnected security systems to solve today’s security challenges is complex. We recently asked Microsoft Graph Security Hackathon participants to come up with innovative solutions using the Microsoft Graph Security API, and they did not disappoint.

We were excited to get a diverse set of submissions that covered real world security use cases, including security operations, user risk management, alerts enrichment, incident response, and analytics. It was truly inspiring to see the effort and creativity that teams and individuals put into their applications.

With that, please join us in congratulating the winners of the Microsoft Graph Security Hackathon.

First place: Microsoft User Security Evaluation Reporter

The Microsoft User Security Evaluation Reporter (MS-USER), from Darren Robinson, helps service desks and cybersecurity leads get instant visibility into their organization’s user security posture. Leveraging the Graph Security API and Microsoft Secure Score, the MS-USER app pulls together user and event information and includes recommended actions for remediating risks. The application also checks against the Have I Been Pwned database to give administrators and service desk personnel additional context on a user’s password security. This solution makes it easy to reach out to users and give them simple, actionable advice to improve their security, and as a result, the security of the rest of the organization. Darren will be joining us at our session at the Microsoft Build conference in Seattle, Washington, May 6-8, 2019. Definitely take a moment to check out his app today at

Runner up: Microsoft Graph Security—Security Alerts Enrichment

The Security Alerts Enrichments solution, submitted by Josh Rickard, is based on the Swimlane platform and ties together alerts with threat indicators and actions. The team created two applications that use Graph Security alerts to automate the creation of a threat intelligence feed, which can then be used to automate remediation of threats in the customer’s on-premises firewall appliance, which in this case is the Palo Alto Panorama Firewall. The second application ties in five different threat intelligence sources for enrichment. This is a great example of the power of a Security Orchestration Automation and Response (SOAR) solution. We encourage you to check it out at

Popular choice: OneGraph

The OneGraph application, from Abhishek Joshi, enables organizations to quickly investigate, analyze, and respond to security threats. The application allows users can get a quick view of all their alerts and statuses, and easily drill down into things like specific threats, users affected, and alerts from specific providers. We really liked the tie-in with Microsoft Planner that allows for alerts to get assigned to specific people or groups. The integration with Microsoft Teams was a great use case that enables quick response. We hope you take a moment to look at this app at

Again, congratulations to the winners and a huge thank you to all participants in the hackathon. We also wanted to take a moment to thank our all-star panel of judges for taking time out of their busy schedules to review and provide feedback on all the submissions. Many thanks for the support to Ann Johnson, Rich Howard, Scott Hanselman, Mark Russinovich, Troy Hunt, and Olli Vanhoja.

Finally, if any of this has inspired to you develop your own security app or solution, here are some resources to get you started:


New steps to protect customers from hacking

Today, court documents were unsealed detailing work Microsoft’s Digital Crimes Unit has executed to disrupt cyberattacks from a threat group we call Phosphorus – also known as APT 35, Charming Kitten, and Ajax Security Team – which is widely associated with Iranian hackers. Our court case against Phosphorus, filed in the U.S. District Court for Washington D.C., resulted in a court order enabling us last week to take control of 99 websites the group uses to conduct its hacking operations so the sites can no longer be used to execute attacks.

Microsoft’s Digital Crimes Unit (DCU) and the Microsoft Threat Intelligence Center (MSTIC) have been tracking Phosphorus since 2013. Its activity is usually designed to gain access to the computer systems of businesses and government agencies and steal sensitive information. Its targets also include activists and journalists – especially those involved in advocacy and reporting on issues related to the Middle East.

Phosphorus typically attempts to compromise the personal accounts of individuals through a technique known as spear-phishing, using social engineering to entice someone to click on a link, sometimes sent through fake social media accounts that appear to belong to friendly contacts. The link contains malicious software that enables Phosphorus to access computer systems.

Phosphorus also uses a technique whereby it sends people an email that makes it seem as if there’s a security risk to their accounts, prompting them to enter their credentials into a web form that enables the group to capture their passwords and gain access to their systems.

Both attack methods employ the use of websites that incorporate the names of well-known brands, like Microsoft, to appear authentic. Websites registered and used by Phosphorus include, for example,,,, and

While we’ve used daily security analytics tracking to stop individual Phosphorus attacks and notify impacted customers, the action we executed last week enabled us to take control of websites that are core to its operations. Our work to track Phosphorus over multiple years and observe its activity enabled us to build a decisive legal case and execute last week’s action with confidence we could have significant impact on the group’s infrastructure.

The action we executed last week enabled us to take control of 99 websites and redirect traffic from infected devices to our Digital Crime Unit’s sinkhole. The intelligence we collect from this sinkhole will be added to MSTIC’s existing knowledge of Phosphorus and shared with Microsoft security products and services to improve detections and protections for our customers.

Throughout the course of tracking Phosphorus, we’ve worked closely with a number of other technology companies, including Yahoo, to share threat information and jointly stop attacks. We are grateful for their partnership. We also worked with each domain listing company listed in our suit prior to filing it and are grateful for their support and help in transferring the website domains registered by Phosphorus to us once a court order was granted. Our case against Phosphorus is similar to cases we’ve filed against another threat group called Strontium. We have used this approach 15 times to take control of 91 fake websites associated with Strontium. The legal filings in our case against Phosphorus can be found here.

Tags: , ,


From Microsoft Defender ATP alert to protecting customers: Follow the journey

With Microsoft continuously improving kernel mitigations and raising the bar for exploiting native kernel components, third-party kernel drivers are becoming a more appealing target for attackers and an important area of research for security analysts. A vulnerability in a signed third-party driver could have a serious impact: it can be abused by attackers to escalate privileges or, more commonly, bypass driver signature enforcement—without the complexity of using a more expensive zero-day kernel exploit in the OS itself.

Computer manufacturers usually ship devices with software and tools that facilitate device management. These software and tools, including drivers, often contain components that run with ring-0 privileges in the kernel. With these components installed by default, each must be as secure as the kernel; even one flawed component could become the Achilles’ heel of the whole kernel security design.

We discovered such a driver while investigating an alert raised by Microsoft Defender Advanced Threat Protection’s kernel sensors. We traced the anomalous behavior to a device management driver developed by Huawei. Digging deeper, we found a lapse in the design that led to a vulnerability that could allow local privilege escalation.

We reported the vulnerability (assigned CVE-2019-5241) to Huawei, who responded and cooperated quickly and professionally. On January 9, 2019, Huawei released a fix. In this blog post, we’d like to share our journey from investigating one Microsoft Defender ATP alert to discovering a vulnerability, cooperating with the vendor, and protecting customers.

Detecting kernel-initiated code injections with Microsoft Defender ATP

Starting in Windows 10, version 1809, the kernel has been instrumented with new sensors designed to trace User APC code injection initiated by a kernel code, providing better visibility into kernel threats like DOUBLEPULSAR. As described in our in-depth analysis, DOUBLEPULSAR is a kernel backdoor used by the WannaCry ransomware to inject the main payload into user-space. DOUBLEPULSAR copied the user payload from the kernel into an executable memory region in lsass.exe and inserted a User APC to a victim thread with NormalRoutine targeting this region.


Figure 1. WannaCry User APC injection technique schematic diagram

While the User APC code injection technique isn’t novel (see Conficker or Valerino’s earliest proof-of-concept), detecting threats running in the kernel is not trivial. Since PatchGuard was introduced, hooking NTOSKRNL is no longer allowed; there’s no documented way drivers could get notification for any of the above operations. Hence, without proper optics, the only sustainable strategy would be applying memory forensics, which can be complicated.

The new set of kernel sensors aim to address this kind of kernel threat. Microsoft Defender ATP leverages these sensors to detect suspicious operations invoked by a kernel code that might lead to code injection into user-mode. One such suspicious operation triggered this investigation.

Investigating an anomalous code injection from the kernel

While monitoring alerts related to kernel-mode attacks, one alert drew our attention:


Figure 2. Microsoft Defender ATP kernel-initiating code injection alert

The alert process tree showed an abnormal memory allocation and execution in the context of services.exe by a kernel code. Investigating further, we found that an identical alert was fired on another machine around the same time.

To get a better understanding of the observed anomaly, we looked at the raw signals we got from the kernel sensors. This analysis yielded the following findings:

  • A system thread called nt!NtAllocateVirtualMemory allocated a single page (size = 0x1000) with PAGE_EXECUTE_READWRITE protection mask in services.exe address space
  • The system thread then called nt!KeInsertQueueApc to queue User APC to a services.exe arbitrary thread with NormalRoutine pointing to the beginning of the executable page and NormalContext pointing to offset 0x800

The payload copied from kernel mode is divided into two portions: a shellcode (NormalRoutine) and a parameter block (NormalContext). At this point, the overall behavior looked suspicious enough for us to proceed with the hunting. Our goal was to incriminate the kernel code that triggered the alert.

Incriminating the source

In user-mode threats, the caller process context could shed light on the actor and link to other phases in the attack chain. In contrast, with kernel-mode threats, the story is more complicated. The kernel by nature is asynchronous; callbacks might be called in an arbitrary context, making process context meaningless for forensics purposes.

Therefore, we tried to find an indirect evidence to third-party code loaded into the kernel. By inspecting the machine timeline, we found that several third-party drivers were loaded earlier that day.

We concluded based on their file path that they are all related to an app from Huawei called PC Manager, a device management software for Huawei MateBook laptops. The installer is available on Huawei website, so we downloaded it for inspection. For each Huawei driver we used dumpbin.exe to examine imported functions.

And then we had a hit:

figure-03-dumpbin-utility-used-to-detect-user-APC injection-primitives

Figure 3. dumpbin utility used to detect user APC injection primitives

HwOs2Ec10x64.sys: Unexpected behavior from a driver

Hunting led us to the kernel code that triggered the alert. One would expect that a device management software would perform mostly hardware-related tasks, with the supplied device drivers being the communication layer with the OEM-specific hardware. So why was this driver exhibiting unusual behavior? To answer this question, we reverse-engineered HwOs2Ec10x64.sys.

Our entry point was the function implementing the user APC injection. We found a code path that:

  1. allocates RWX page in some target process;
  2. resolves CreateProcessW and CloseHandle function pointers in the address space of the target process;
  3. copies a code area from the driver as well as what seemed to be a parameter block to the allocated page; and
  4. performs User APC injection targeting that page

The parameter block contains both the resolved function pointers as well as a string, which was found to be a command line.


Figure 4. User APC injection code

The APC normal routine is a shellcode which calls CreateProcessW with the given process command line string. This implied that the purpose of the code injection to services.exe is to spawn a child process.


Figure 5. User shellcode performing process creation

Inspecting the xrefs, we noticed that the injection code originated from a create-process notify routine when Create = FALSE. Hence, the trigger was some process termination.

But what command does the shellcode execute? Attaching a kernel debugger and setting a breakpoint on the memcpy_s in charge of copying the parameters from kernel to user-mode revealed the created process: one of Huawei’s installed services, MateBookService.exe, invoked with “/startup” in its command line.


Figure 6. Breakpoint hit on the call to memcpy_s copying shellcode parameters

Why would a valid service be started that way? Inspecting MateBookService.exe!main revealed a “startup mode” that revived the service if it’s stopped – some sort of watchdog mechanism meant to keep the Huawei PC Manager main service running.


Figure 7. MateBookService.exe /startup code path

At this point of the investigation, the only missing piece in the puzzle was making sure the terminated process triggering the injection is indeed MateBookService.exe.


Figure 8. Validating terminated process identity

The code path that decides whether to inject to services.exe uses a global list of watched process names. Hitting a breakpoint in the iteration loop revealed which process was registered: it was MateBookService.exe, as expected, and it was the only process on that list.


Figure 9. Breakpoint hit during process name comparison against global list

HwOs2Ec10x64.sys also provided process protection against external tampering. Any attempt to force MateBookService.exe termination would fail with Access Denied.

Abusing HwOs2Ec10x64.sys process watch mechanism

The next step in our investigation was to determine whether an attacker can tamper with the global watched process list. We came across an IOCTL handler that added an entry to that list. MateBookService.exe process likely uses this IOCTL to register itself when the service starts. This IOCTL is sent to the driver control device, created from its DriverEntry.


Figure 10. HwOs2Ec10x64.sys control device creation with IoCreateDevice

Since the device object is created with IoCreateDevice, Everyone has RW access to it. Another important observation was that this device isn’t exclusive, hence multiple handles could be opened to it.

Nevertheless, when we tried to open a handle to the device \\.\HwOs2EcX64, it failed with Last Error = 537, “Application verifier has found an error in the current process”. The driver was rejecting our request to open the device. How is access enforced? It must be on the CreateFile path; in other words, in HwOs2Ec10x64.sys IRP_MJ_CREATE dispatch routine.


Figure 11. IRP_MJ_CREATE dispatch routine

This function validates the calling process by making sure that the main executable path belongs to a whitelist (e.g., C:\Program Files\Huawei\PCManager\MateBookService.exe). This simple check on the initiating process name, however, doesn’t guarantee the integrity of the calling process. An attacker-controlled instance of MateBookService.exe will still be granted access to the device \\.\HwOs2EcX64 and be able to call some of its IRP functions. Then, the attacker-controlled process could abuse this capability to talk with the device to register a watched executable of its own choice. Given the fact that a parent process has full permissions over its children, even a code with low privileges might spawn an infected MateBookService.exe and inject code into it. In our proof-of-concept, we used process hollowing.


Figure 12. Procmon utility results showing POC process start/exit & IL

Because watched processes are blindly launched by the watchdog when they’re terminated, the attacker-controlled executable would be invoked as a child of services.exe, running as LocalSystem, hence with elevated privileges.


Figure 13. Procexp utility process-tree view showing LPE_POC running as LocalSystem

Responsible disclosure and protecting customers

Once we had a working POC demonstrating the elevation of privilege from a low-integrity attacker-controlled process, we responsibly reported the bug to Huawei through the Microsoft Security Vulnerability Research (MSVR) program. The vulnerability was assigned CVE-2019-5241. Meanwhile, we kept our customers safe by building a detection mechanism that would raise an alert for any successful privilege escalation exploiting the HwOs2Ec10x64.sys watchdog vulnerability as we described.


Figure 14. Microsoft Defender ATP alerting on the privilege escalation POC code

Abusing a second IOCTL handler

Having been able to freely invoke IOCTL handlers of the driver from user-mode, we looked for other capabilities that can be abused. We found one: the driver provided a capability to map any physical page into user-mode with RW permissions. Invoking this handler allowed a code running with low privileges to read-write beyond the process boundaries—to other processes or even to kernel space. This, of course, means a full machine compromise.

We also worked with Huawei to fix this second vulnerability, which was assigned CVE-2019-5242. Huawei addressed the flaw in the same security advisory.

We presented our research at the Blue Hat IL Conference in February. Watch the video recording here, and get the slide deck here.


The two vulnerabilities we discovered in a driver prove the importance of designing software and products with security in mind. Security boundaries must be honored. Attack surface should be minimized as much as possible. In this case, the flaws could have been prevented if certain precautions were taken:

  • The device object created by the driver should be created with a DACL granting SYSTEM RW access (since only the vendor’s services were communicating directly with the driver)
  • If a service should persist, developers should check that it’s not already provided by the OS before trying to implement a complex mechanism
  • User-mode shouldn’t be allowed to perform privileged operations like writing to any physical page; if needed, the driver should do the actual writing for well-defined, hardware-related scenarios

Microsoft’s driver security checklist provides some guidelines for driver developers to help reduce the risk of drivers being compromised.

Our discovery of the driver vulnerabilities also highlights the strength of Microsoft Defender ATP’s sensors. These sensors expose anomalous behavior and give SecOps personnel the intelligence and tools to investigate threats, as we did.

Anomalous behaviors typically point to attack techniques perpetrated by adversaries with only malicious intent. In this case, they pointed to a flawed design that can be abused. Nevertheless, Microsoft Defender ATP exposed a security flaw and protected customers before it can even be used in actual attacks.

Not yet reaping the benefits of Microsoft Defender ATP’s industry-leading optics and detection capabilities? Sign up for free trial today.

Amit Rapaport (@realAmitRap)
Microsoft Defender Research team