Month: August 2021

How to Gain More from
your Connection to an OT Network

One of the most productive and non-intrusive tools in the Cyber Security
Engineer’s bag is passive Network Traffic Analysis (NTA).  Providing
network maps, inventory, and firmware information among other benefits provides
insights that are not generally known any other way.  Manual inventory
collection methods are error-prone and expose this information to interception
over corporate email networks, shared file folders, etc.  But how do we
implement this kind of system without causing any bumps in the road for
real-time processes?  What are the risks?  Which methods are
best?  The best sensor does no good unconnected and is of little value
connected in the wrong part of the network. 

 To discuss this, I will use a diagram that was developed
for my last blog post Designing a Robust Defense for Operational Technology Using
Azure Defender for IoT (microsoft.com).  This diagram (below) shows an
example OT network monitored by Azure Defender for IoT.
Defender for IoT is an agentless passive Network Traffic Analysis
tool with strong roots in Operational Technology, now expanding to IoT.
Defender for IoT discovers OT/IoT devices, identifies vulnerabilities, and
provides continuous OT/IoT-aware monitoring of network traffic.  The
recommended locations for Azure Defender for IoT  (AD4IoT) are shown in red color.  Why have these locations been
chosen?  To explain this, we will break this network into pieces and
address these issues for each type of traffic.

 

 

 Starting with the lower portion of this sketch, let’s look at traffic flows
around the PLCs. 

 

  1. The first arrow shows traffic between
a PLC and its ethernet-connected Input/Output (I/O) modules.  This traffic
utilizes simplistic protocols and is very structured and periodic.  It can
be leveraged as a threat to the overall OT system and is more vulnerable when
I/O is remote from the PLCs in unsecured areas.  Malicious applications
could perform inappropriate control actions and/or falsify data.  Firmware
problems in I/O modules often go unpatched unless some form of undesirable
behavior is experienced. In certain families of PLCs or controllers, the
Defender for IoT can provide data on firmware levels and types of I/O modules
if this data is requested by an HMI or historian. 

 The mechanism to monitor this traffic is
to span switches used in the I/O subsystem as shown here.  If they are
unmanaged switches, taps may be located at the connection to the PLC or
controller.

 2. The second arrow identifies traffic
from Variable Frequency Drives or similar equipment often interfaced with the
PLCs or Controllers.  This communication may be Modbus, Rockwell Protocols,
or CIP.  Equipment could be damaged or destroyed by inappropriate commands
sent to such devices.  Good engineering practice would put bounds of
reasonability around all potential setpoints, but this may not be the
case.  These protocols are well understood and in the public domain. 
A man-in-the-middle attack could affect this type of equipment. 
Monitoring these communications can identify inappropriate function calls,
program or firmware changes, and parameter updates. As above, switch span or
taps are the mechanisms to monitor this traffic.

 3. Custom engineered systems may utilize
well-known, open OT protocols such as Modbus, OPC, or others.  This
traffic should be monitored even if it is not fully understood as the behavior
patterns should be very predictable.  It is common for these systems to
utilize unusual functions and atypical ranges for data.  This is the
result of a developer reading a protocol spec with no actual field experience
with the protocol.  Custom alerts can be configured and tuned based on the
nature of the data.  Since such systems are engineered to order for a
specific purpose, the damage could have long-term implications on plant
production.

 4. Traffic crossing OT Access-level
switches should always be monitored.  This is the primary point at which
PLCs or controllers communicate with HMIs, engineering stations, and sometimes
historians.  The problem here is that these switches carry the actual OT
control traffic.  Any action that could compromise this traffic affects
the reliability of the OT system.  Many switches at the I/O and access
layers may be unmanaged devices.  By unmanaged, I mean that they are not
configurable and therefore cannot support a SPAN (or mirror) session. 

 Unmanaged switches is not an
insurmountable hurdle.  Two possible paths may be followed from this
point.  The least intrusive is to install network taps.  The security
engineer should consult with the OT engineer on the most valuable locations for
taps.  Since a stand-alone tap monitors only one data stream, the most
valuable assets (compromise targets) should be monitored. These would normally
be at least the engineering station, historian and/or alarms server (if
appropriate), and HMIs, particularly those with engineering tools
installed.  If it is necessary to monitor all traffic, a tap aggregator
may be used.

Another approach would be to replace the
unmanaged switches with managed switches.  This may sound daunting but
usually is not.  Most managed switches are configured to “wake up” in a
basic mode which approximates an unmanaged switch.  So replacement, while
requiring a system shutdown, can be accomplished rather quickly and have the
system up and functioning again.  Once this is done, the configuration can
be added to provide basic security and copy traffic to a SPAN or mirror
port.  Make sure these configurations are saved as most switches make
changes to operating memory which is not stored on power reset.  It is
generally recommended to discuss this change with your OT support personnel
and/or OEM service engineers.  They probably have some standard switch
configurations that they apply when a customer requests managed switches. 
Additionally, they should be able to provide you with approximate bus speeds
needed to support OT traffic with mirroring.

What are the risks? In the case of switch SPAN (SwitchPort ANalyzer), or mirror
sessions, the only concern of serious significance is the current traffic level
on the switch.  If a SPAN session is added to a heavily loaded switch, the
SPAN may drop packets because the SPAN session is a lower priority than actual
switching traffic. This could mean that some packets might slip through
unmonitored.  However, it does not affect the normal functioning of the
switch for ICS traffic.  Some switches, if they are greatly overloaded can
revert to ‘flood mode’ in which they act as a network hub.  This situation
is extremely rare.  If switch SPANning is chosen as a method, it is wise
to monitor network traffic on the switch prior to adding the session. 
Assume that a full switch span will double the switch backbone traffic. 

 If network taps are installed, the risks are insignificant.  Passive
taps should of course be chosen.  Passive means that the tap continues to
pass control traffic even if it loses power.  Passive taps are simply
inserted in-line with the existing traffic, see sketch below. 
Installation needs to be coordinated with OT engineers to limit the impact on
operating processes. 

 

 Next, we will discuss special equipment including analysis devices and
robotics.  This portion of the overall diagram is shown below.  

    

Network traffic to analyzers typically looks like normal PC traffic using
common IT protocols.  Most analyzers have some form of controller that is
designed for a specific function.  Sometimes the PC is the
controller, utilizing specialized I/O boards included in the machine. Some
analyzers or groups of analyzers may be managed by mini computers.  
In any case, from a network security perspective, these devices appear on the
network as computers, not analyzers per se.  Patching of these customized
machines often lags behind the upgrade strategies used for standard IT
equipment.  Upgrades to analysis systems must be approved by, and often be
implemented by the OEMs which may be expensive and involve downtime. Because of
infrequent patching and/or OS upgrades, this equipment can become a security
liability on a lab network. Ideally, lab equipment should be separated either
physically onto separate networks or via VLANs, but such changes may require
extensive planning and testing and still can be disruptive to ongoing lab
processes.

Most major medical laboratories utilize either a LIMS (Laboratory
Information Management System) or a middleware server to collect analytics data
from these devices and forward that data to a patient information database
managed either locally or in the cloud (see sketch below).  Hence, the
traffic to/from the analyzer will be most easily recognized by the ultimate
destination at the middleware or LIMS.  Since these potentially vulnerable
machines may process interactions with users on the lab network for input data
or maintenance functions, they should be monitored more closely than fully
patched IT machines.  This presents a challenge to lab IT managers who may
want to gain a handle on this type of OT equipment in their network but may not
have good inventory information. 

Since medical testing facilities utilize normal switched networks,
monitoring should be installed at an appropriate location to ‘see’ all the
traffic from analyzers to the middleware or LIMS server.  This could be
either core or distribution level switches depending on the network
design.  Standard SPAN or mirror traffic can be used.

Dual-homed machines present special security challenges since they could be
converted to active routers by malware.  It is common for expensive lab or
analysis equipment to be leased.  OEM terms and conditions specify how
this equipment may be used and what service it requires to achieve contracted
performance.  This is often monitored via a ‘secure’ datalink to the
manufacturer’s support site.  These may or may not be
bi-directional.  These links are generally firewalled, either by the OEM,
by the customer or by both.  Bi-directional links are inherently a threat. 
Remote access to a computer on the lab network can put much more than that
computer in jeopardy. 

 

 

In robotic applications, the primary issue is the speed of response. 
The control systems are complex, utilizing high-level programming
toolsets.  The low-level communication may not utilize standard ethernet
framing.  Robot protocols vary widely and include Ethernet/IP, DeviceNet,
Profibus-DP, Profinet, CC-Link, and EtherCat protocols.  Physical media
may be Cat5/6, but RG-6 coaxial, twisted pair, RS-485, and fiber are also
used.  Monitoring the low-level communication between controllers and
robots requires careful coordination with the equipment designer and should not
be attempted casually.  Network monitoring should utilize taps. Switch
SPAN, or mirroring is not recommended. 

 As described above, most industrial robots are programmed using a computer
workstation.  Downloading and selection of programs may be manual or
automated using standard network protocols. So, monitoring should focus on the
programming workstations and the source of robot program selections. 
Robot program file downloads may be transferred from a central server. 
These could occur over SFTP, FTP, SMB, or other methods. 

 Finally, we would like to address the OT interface to the business
(Enterprise) network.  This can be a gateway for potential threats to OT
systems.  Some vulnerabilities that may be unsuccessful in the IT network
space may cause severe problems in the OT space because the machines may not be
patched.  Out of date and unsupported operating systems may be in
use.  As a result, traffic that enters from the Enterprise network and
ultimately reaches the OT network should be monitored. 

 Generally, good practice prevents any direct traversal of the DMZ.  For
instance, remote desktop sessions should be hosted by a RAS server in the DMZ
which is then used to open a remote desktop session into an OT machine with
different credentials. Elaborate credential systems with short password lives
attempt to increase the challenge for attackers attempting to gain
control.  Well designed implementations keep all machines in the DMZ
patched up-to-date which should limit the effect of known
vulnerabilities. 

 Zero day vulnerabilities will always be a threat prior to discovery. 
So, monitoring sessions entering the DMZ from the Enterprise and those leaving
the DMZ for the OT network are an important part of a security design. 
Similarly, monitoring traffic from the OT network to a Historian server and
Enterprise connections to that same server could uncover issues.  Since
these sessions are often encrypted, efforts should focus on the legitimacy of
the Enterprise hosts, times of access, data rates, and other indicators to
validate these externally generated sessions.

 The DMZ is also used as a connection point for a variety of other facility
systems such as IP phones; perimeter security systems; weather stations;
contracted supply systems like water purification, compressed air supply and
the like; wireless devices; etc.  In most cases, these various systems are
assigned separate VLANs and subnets.  By monitoring all the VLANS in this
zone, suspicious traffic can be identified and managed.  Traffic
originating from any of these devices to the ICS network should not normally
exist. 

Subnet-to-subnet traffic could be cause for concern.  This is another
area where Defender for IoT can help.  By mapping the assets, assigning
them to VLANs, subnets, and user assigned subsystems, communication between the
various device groups can be easily seen greatly aiding efforts to perform or
monitor network segregation.  

 The visual network map produced by Defender for IoT in conjunction with the
filtering capabilities on the map make it easy to identify interconnections
between various plant control systems. Having a powerful visual of
group-to-group communication makes the effort of segmentation much
easier.  This process is a long and tedious one using arp tables on
switches.  Also, if this effort is underway, the map will show areas that
may have been overlooked.

 Conclusions:

 Well-engineered connections to ICS networks can yield valuable results,
including accurate inventories, network maps, and improved security with no
risk to the reliability of the underlying OT systems.  This information
can be combined, in Azure Sentinel or other
SIEM/SOAR solutions, with agent-based Defender for endpoint data to produce a
complete picture of OT networks.  Custom-designed playbooks can assist
your analysts in responding to OT or IoT issues.  

Teamwork between OT engineers and IT security personnel can yield benefits
for both groups while presenting a more challenging landscape to potential
intruders.

 

As we know, each organization is unique and have different use cases and
scenarios in mind when it come to security operations. Nevertheless we’ve
identified several use cases that are common across many SOC teams.

Azure Sentinel now provides built-in watchlist templates, which you can
customize for your environment and use during investigations.

After those watchlists are populated with data, you can correlate that data
with analytics rules, view it in the entity pages and investigation graphs as
insights, create custom uses such as to track VIP or sensitive users, and more.

Watchlist templates currently include:

• VIP
  Users.
  A list of user accounts of employees that have high impact value in the
  organization.
• Terminated
  Employees.
  A list of user accounts of employees that have been, or are about to be,
  terminated.
• Service
  Accounts.
  A list of service accounts and their owners.
• Identity
  Correlation.
  A list of related user accounts that belong to the same person.
• High
  Value Assets.
  A list of devices, resources, or other assets that have critical value in
  the organization.
• Network
  Mapping.
  A list of IP subnets and their respective organizational contexts.

 

Watchlists
templates insights in entity pages

 

We’ve created the watchlists templates schemas to be super easy and extensible, in order for
you to populate it with the relevant data. more information about using the
watchlists templates can be found here.

 

What’s next?

 

Beside surfacing the watchlists templates data inside the entity pages,
we’re working on embedding this information in the UEBA anomalies, and the
entity risk score which is planned next. Understanding if a user is a
VIP/Terminated or an asset is an HVA is important to provide both context and
security value for the analyst while investigating.

 

In collaboration with the Microsoft Threat Intelligence Center (MSTIC), we
are excited to announce Fusion
detection for ransomware is now publicly available!

 

These Fusion detections correlate alerts that are potentially associated
with ransomware activities that are observed at defense evasion and execution
stages during a specific timeframe. Once such ransomware activities are
detected and correlated by the Fusion machine learning model, a high
severity incident titled “Multiple alerts possibly related to Ransomware
activity detected” will be triggered in your Azure Sentinel workspace.

 

In order to help your analyst quickly understand the possible attack, Fusion
provides you with a complete picture for the suspicious activities happened on
the same device/host by correlating signals from Microsoft products as well as
signals in network and cloud. Supported data connectors include:

• Azure Security Center
• Microsoft Cloud App Security
• Microsoft Defender for Endpoint
• Microsoft Defender for Identity
• Azure Sentinel scheduled analytics rules. Fusion only
  considers scheduled analytics rules with tactics information.

 

The screenshot below shows a Fusion incident with 22 alerts. It correlates
low severity signals that were detected around the same timeframe from the
network and the host to show a possible ransomware attack and the different
techniques used by attackers.

 

 

 

For more information, see Multiple alerts possibly related to Ransomware activity
detected.

 

Why Fusion detection for ransomware?

Ransomware attack is a type of attack that involves using
specific types of malicious software or malware to make network or system
inaccessible for the purpose of extortion – ‘ransom’. There is no doubt that
ransomware attacks have taken a massive turn in being the top priority as a
threat to many organizations. A recent report released by PurpleSec revealed that the
estimated cost of ransomware attacks was $20 billion in 2020 and with downtime
increasing by over 200% and the cost being 23x higher than 2019.

 

Preventing such attacks in the first place would be the ideal solution but
with the new trend of ‘ransomware as a service’ and human operated ransomware,
the scope and the sophistication of attacks are increasing – attackers are
using slow and stealth techniques to compromise network, which makes it harder
to detect them in the first place.

 

With Fusion detection
for ransomware that captures malicious activities at the defense evasion and
execution stages of an attack, it gives security analysts an opportunity to
quickly understand the suspicious activities happened around the same timeframe
on the common entities, connect the dots and take immediate actions to disrupt
the attack. When it comes to ransomware attacks, time more than
anything else is the most important factor in preventing more machines or the
entire network from getting compromised. The sooner such alerts are raised to
security analysts with the details on various attacker activities, the faster
the ransomware attacks can be contained and remediated. A detection like this
will help analysts by giving the compilation of attacker activity around
execution stage helping reduce MTTD (Mean Time to Detect) and MTTR (Mean Time
to Respond).

 

Examples of the Fusion detection for ransomware

In the Incident 1
example, Fusion correlates alerts triggered within a short timeframe on the
same device, indicating a possible chain of attacks from how the attackers got
in through possible RDP brute-force attack, followed by the use of a ‘Cryptor’
malware and potential phishing activities using malicious document associated
with the EUROPIUM activity group, to the detection of Petya and WannaCrypt
ransomware in the network.

 

Incident 1

 

 

Incident 2
below is another example of the Fusion ransomware detection that was confirmed
as true positive. This incident correlates alerts showing ransomware activities
at defense evasion and execution stages on the same host, along with additional
suspicious activities detected during the same timeframe to show you possible
techniques used by attackers to compromise the host.

 

Incident 2

 

In these Fusion incidents, the alerts related to ransomware/malware
detection might indicate that the ransomware/malware was stopped from
delivering its payload but it is prudent to check the machine for signs of
infection. Attackers may continue malicious activities after ransomware was
prevented – it is also important that you investigate the entire network to
understand the intrusion and identify other machines that might be impacted by
this attack.

 

What’s next after receiving the Fusion detection?

After receiving Fusion detentions for possible ransomware activities, we
recommend you to check with the machine owner if this is intended behavior. If
the activity is unexpected, treat the machine as potentially compromised and
take immediate actions to analyze different techniques used by attackers to
compromise the host and to evade detection in this potential ransomware attack.
Here are the recommended steps:

 

1. Isolate the machine from the network to prevent
   potential lateral movement.
2. Run a full antimalware scan on the machine, following
   any resulting remediation advice.
3. Review installed / running software on the machine,
   removing any unknown or unwanted packages.
4. Revert the machine to a known good state, reinstalling
   operating system only if required and restoring software from a verified
   malware-free source.
5. Resolve to recommendations from alert providers (e.g. Azure Security Center and Microsoft Defender) to prevent future breaches.
6. Investigate the entire network to understand the
   intrusion and identify other machines that might be impacted by this
   attack.

 

As you investigate and close the Fusion incidents, we encourage you to provide feedback
on whether this incident was a True Positive, Benign Positive, or a False
Positive, along with details in the comments. Your feedback is
critical to help Microsoft deliver the highest quality detections!

 

 Recent reports show the high extent to which information workers are
utilizing cloud apps while doing their everyday tasks. In an average
enterprise, there are more than 1500 different cloud services used, where less
than 12% of them are sanctioned or managed by the IT teams. Considering that
more than 78GB of data is being uploaded monthly to risky apps we conclude that
most organizations are exposed to potential data loss or risks coming out of
these cloud applications.

 

Shadow IT usage of risky apps is usually mitigated by a strict approach of
blocking any usage of these cloud apps that do not meet certain risk criteria,
this approach is already enabled today by using Microsoft’s Cloud App Security Shadow IT Discovery capabilities
with its native integration with Microsoft Defender for Endpoints and it’s
native integration with other 3^rd party network appliances. 

But what about apps that are widely used by
employees and enable their productivity (especially in the Work from
home/Covid-19 era) and their risk is not conclusive enough for a strict block.
To enable the delicate balance between employee’s productivity, and the need
for risk and compliance awareness, organizations need to take a gradual
approach:

• Warn users that this app is not recommended/allowed but
  allows users to bypass to enable productivity. 
• IT can monitor access and bypasses such apps and learn
  usage trends and importance.
• IT can offer sanctioned and managed alternatives for
  the users by creating a contextual company web page that provides
  sanctioned alternatives in the organization. 

We are pleased to announce the public
preview for a new endpoint-based capability to allow management
and control of Monitored cloud applications, manage these Monitored
applications applying soft block experience for end-users when accessing these
apps. Users will have an option to bypass the block.
IT admins will be able to add a dedicated custom redirect link so users can get
more context on why they were blocked in the first place and what valid
alternatives do they have for such apps in the organization.

Besides enabling the soft block experience, admins will be able to
continuously monitor these apps and understand how many of the users adhered to
the block and chose other alternatives, or, decided to bypass the block and
continue using the app – this will serve as a strong indication, org-wide,
whether this app is necessary and should be considered for deeper management by
IT.

By adopting a more gradual and less strict approach for blocking cloud
applications, IT organizations can reduce their overhead of handling exception
requests, but in parallel drive employee awareness.

 

How does it work?

 

 In Cloud App security, tag the targeted
app as Monitored.

 

The corresponding URL/Domains indicators will appear in the Microsoft
Defender for Endpoints security portal as a new URL/Domain indicator with
action type Warn.

 

When a user attempts to access the Monitored
app, they will be blocked by Windows defender network protection but will allow
the user to bypass the block or get more details on why he was blocked by
redirecting him to a dedicated custom web page managed by the organization.

 

 

Over time, an IT admin can monitor the usage pattern of the app in Cloud App
Security’s discovered app page and monitor how many users have bypassed the
warning message.

 

 

 

Get started

After you have verified that you have all the integration prerequisites listed
in this article, follow the steps below to start warning on access
to Monitored apps with Cloud App Security and Microsoft Defender for Endpoint.

Step 1

In Microsoft 365 Defender, go to settings >
Endpoints > Advanced features and enable Microsoft Cloud App Security
integration and Custom
network indicators.

 

Step 2

In the Microsoft Cloud App Security portal, go
to  Settings > Microsoft Defender for Endpoint:

• Mark the checkbox to enable blocking of endpoint access
  to cloud apps marked as unsanctioned in Cloud App Security
• [Optional] Set a custom redirect URL for a company
  coaching page.
• [Optional] Set the Bypass duration time after which the
  user will get warned once again on access to the app.

 

 

 

 With the massive volume of emails sent each day, coupled with the many methods that attackers use to blend in, identifying the unusual and malicious is more challenging than ever. An obscure Unicode character in a few emails is innocuous enough, but when a pattern of emails containing this obscure character accompanied by other HTML quirks, strange links, and phishing pages or malware is observed, it becomes an emerging attacker trend to investigate. We closely monitor these kinds of trends to gain insight into how best to protect customers.

This blog shines a light on techniques that are prominently used in many recent email-based attacks. We’ve chosen to highlight these techniques based on their observed impact to organizations, their relevance to active email campaigns, and because they are intentionally designed to be difficult to detect. They hide text from users, masquerade as the logos of trusted companies, and evade detection by using common web practices that are usually benign:

• Brand impersonation with procedurally-generated graphics
• Text padding with invisible characters
• Zero-point font obfuscation
• Victim-specific URI

We’ve observed attackers employ these tricks to gain initial access to networks. Although the examples we present were primarily seen in credential theft attacks, any of these techniques can be easily adapted to deliver malware.

By spotting trends in the threat landscape, we can swiftly respond to potentially malicious behavior. We use the knowledge we gain from our investigations to improve customer security and build comprehensive protections. Through security solutions such as Microsoft Defender for Office 365 and the broader Microsoft 365 Defender, we deliver durable and comprehensive protection against the latest attacker trends.

Brand impersonation with procedurally-generated graphics

We have observed attackers using HTML tables to imitate the logos and branding of trusted organizations. In one recent case, an attacker created a graphic resembling the Microsoft logo by using a 2×2 HTML table and CSS styling to closely match the official branding.

Spoofed logos created with HTML tables allow attackers to bypass brand impersonation protections. Malicious content arrives in users’ inboxes, appearing to recipients as if it were a legitimate message from the company. While Microsoft Defender for Office 365 data shows a decline in the usage of this technique over the last few months, we continue to monitor for new ways that attackers will use procedurally-generated graphics in attacks.

Figure 1. Tracking data for small 2×2 HTML tables

How it works

A graphic resembling a trusted organization’s official logo is procedurally generated from HTML and CSS markup. It’s a fileless way of impersonating a logo, because there are no image files for security solutions to detect. Instead, the graphic is constructed out a specially styled HTML table that is embedded directly in the email.

Of course, inserting an HTML table into an email is not malicious on its own. The malicious pattern emerges when we view this technique in context with the attacker’s goals.

Two campaigns that we have been tracking since April 2021 sent targets emails that recreated the Microsoft logo. They impersonated messages from Office 365 and SharePoint. We observed the following email subjects:

• Action Required: Expiration Notice On <Email Address>
• Action Required: 3 Pending Messages sent <date>
• New 1 page incoming eFax© message for “<Email Alias>”

Figure 2. Sample emails that use HTML code to embed a table designed to mimic the Microsoft logo

Upon extracting the HTML used in these emails, Microsoft analysts determined that the operators used the HTML table tag to create a 2×2 table resembling the Microsoft logo. The background color of each of the four cells corresponded to the colors of the quadrants of the official logo.

Figure 3. Page source of the isolated HTML mimicking the Microsoft logo

HTML and CSS allow for colors to be referenced in several different ways. Many colors can be referenced in code via English language color names, such as “red” or “green”. Colors can also be represented using six-digit hexadecimal values (i.e., #ffffff for white and #000000 for black), or by sets of three numbers, with each number signifying the amount of red, green, or blue (RGB) to combine. These methods allow for greater precision and variance, as the designer can tweak the numbers or values to customize the color’s appearance.

Figure 4. Color values used to replicate the Microsoft logo

As seen in the above screenshot, attackers often obscure the color references to the Microsoft brand by using color names, hexadecimal, and RGB to color in the table. By switching up the method they use to reference the color, or slightly changing the color values, the attacker can further evade detection by increasing variance between emails.

Text padding with invisible characters

In several observed campaigns, attackers inserted invisible Unicode characters to break up keywords in an email body or subject line in an attempt to bypass detection and automated security analysis. Certain characters in Unicode indicate extremely narrow areas of whitespace, or are not glyphs at all and are not intended to render on screen.

Some invisible Unicode characters that we have observed being used maliciously include:

• Soft hyphen (U+00AD)
• Word joiner (U+2060)

Both of these are control characters that affect how other characters are formatted. They are not glyphs and would not even be visible to readers, in most cases. As seen in the following graph, the use of the soft hyphen and word joiner characters has seen a steady increase over time. These invisible characters are not inherently malicious, but seeing an otherwise unexplained rise of their use in emails indicates a potential shift in attacker techniques.

Figure 5. Tracking data for the invisible character obfuscation technique

How it works

When a recipient views a malicious email containing invisible Unicode characters, the text content may appear indistinguishable from any other email. Although not visible to readers, the extra characters are still included in the body of the email and are “visible” to filters or other security mechanisms. If attackers insert extra, invisible characters into a word they don’t want security products to “see,” the word might be treated as qualitatively different from the same word without the extra characters. This allows the keyword to evade detection even if filters are set to catch the visible part of the text.

Invisible characters do have legitimate uses. They are, for the most part, intended for formatting purposes: for instance, to indicate where to split a word when the whole word can’t fit on a single line. However, an unintended consequence of these characters not displaying like ordinary text is that malicious email campaign operators can insert the characters to evade security.

The animated GIF below shows how the soft hyphen characters are typically used in a malicious email. The soft hyphen is placed between each letter in the red heading to break up several key words. It’s worth noting that the soft hyphens are completely invisible to the reader until the text window is narrowed and the heading is forced to break across multiple lines.

Figure 6. Animation showing the use of the invisible soft hyphen characters

In the following example, a phishing email has had invisible characters inserted into the email body: specifically, in the “Keep current Password” text that links the victim to a phishing page.

Figure 7. Microsoft Office 365 phishing email using invisible characters to obfuscate the URL text.

The email appears by all means “normal” to the recipient, however, attackers have slyly added invisible characters in between the text “Keep current Password.” Clicking the URL directs the user to a phishing page impersonating the Microsoft single sign-on (SSO) page.

In some campaigns, we have seen the invisible characters applied to every word, especially any word referencing Microsoft or Microsoft products and services.

Zero-point font obfuscation

This technique involves inserting hidden words with a font size of zero into the body of an email. It is intended to throw off machine learning detections, by adding irrelevant sections of text to the HTML source making up the email body. Attackers can successfully obfuscate keywords and evade detection because recipients can’t see the inserted text—but security solutions can.

Microsoft Defender for Office 365 has been blocking malicious emails with zero-point font obfuscation for many years now. However, we continue to observe its usage regularly.

Figure 8. Tracking data for emails containing zero-point fonts experienced surges in June and July 2021

How it works

Similar to how there are many ways to represent colors in HTML and CSS, there are also many ways to indicate font size. We have observed attackers using the following styling to insert hidden text via this technique:

• font-size: 0px
• font-size: 0.0000em
• font-size: 0vw
• font-size: 0%
• font: italic bold 0.0px Georgia, serif
• font: italic bold 0em Georgia, serif
• font: italic bold 0vw Georgia, serif
• font: italic bold 0% Georgia, serif

Being able to add zero-width text to a page is a quirk of HTML and CSS. It is sometimes used legitimately for adding meta data to an email or to adjust whitespace on a page. Attackers repurpose this quirk to break up words and phrases a defender might want to track, whether to raise an alert or block the content entirely. As with the invisible Unicode character technique, certain kinds of security solutions might treat text containing these extra characters as distinct from the same text without the zero-width characters. This allows the visible keyword text to slip past security.

In a July 2021 phishing campaign blocked by Microsoft Defender for Office 365, the attacker used a voicemail lure to entice recipients into opening an email attachment. Hidden, zero-width letters were added to break up keywords that might otherwise have been caught by a content filter. The following screenshot shows how the email appeared to targeted users.

Figure 9. Sample email that uses the zero-point font technique

Those with sharp eyes might be able to spot the awkward spaces where the attacker inserted letters that are fully visible only within the HTML source code. In this campaign, the obfuscation technique was also used in the malicious email attachment, to evade file-hash based detections.

Figure 10. The HTML code of the email body, exposing the use of the zero-point font technique

Victim-specific URI

Victim-specific URI is a way of transmitting information about the target and creating dynamic content based upon it. In this technique, a custom URI crafted by the attacker passes information about the target to an attacker-controlled website. This aides in spear-phishing by personalizing content seen by the intended victim. This is often used by the attacker to create legitimate-seeming pages that impersonate the Single Sign On (SSO) experience.

The following graph shows cyclic surges in email content, specifically links that have an email address included as part of the URI. Since custom URIs are such a common web design practice, their usage always returns to a steady baseline in between peaks. The surges appear to be related to malicious activity, since attackers will often send out large numbers of spam emails over the course of a campaign.

Figure 11. Tracking data for emails containing URLs with email address in the PHP parameter

In a campaign Microsoft analysts observed in early May 2021, operators generated tens of thousands of subdomains from Google’s Appspot, creating unique phishing sites and victim identifiable URIs for each recipient. The technique allowed the operators to host seemingly legitimate Microsoft-themed phishing sites on third-party infrastructure.

How it works

The attacker sends the target an email, and within the body of the email is a link that includes special parameters as part of the web address, or URI. The custom URI parameters contain information about the target. These parameters often utilize PHP, as PHP is a programming language frequently used to build websites with dynamic content—especially on large platforms such as Appspot.

Details such as the target’s email address, alias, or domain, are sent via the URI to an attacker-controlled web page when the user visits the link. The attacker’s web page pulls the details from the parameters and use that to present the target with personalized content. This can help the attacker make malicious websites more convincing, especially if they are trying to mimic a user logon page, as the target will be greeted by their own account name.

Custom URIs containing user-specific parameters are not always, or even often, malicious. They are commonly used by all kinds of web developers to transmit pertinent information about a request. A query to a typical search engine will contain numerous parameters concerning the nature of the search as well as information about the user, so that the search engine can provide users with tailored results.

However, in the victim identifiable URI technique, attackers repurpose a common web design practice to malicious ends. The tailored results seen by the target are intended to trick them into handing over sensitive information to an attacker.

In the Compact phishing campaign described by WMC Global and tracked by Microsoft, this technique allowed the operators to host Microsoft-themed phishing sites on any cloud infrastructure, including third-party platforms such as Google’s Appspot. Microsoft’s own research into the campaign in May noted that not only tens of thousands of individual sites were created, but that URIs were crafted for each recipient, and the recipient’s email address was included as a parameter in the URI.

Newer variants of the May campaign started to include links in the email, which routed users through a compromised website, to ultimately redirect them to the Appspot-hosted phishing page. Each hyperlink in the email template used in this version of the campaign was structured to be unique to the recipient.

The recipient-specific information passed along in the URI was used to render their email account name on a custom phishing page, attempting to mimic the Microsoft Single Sign On (SSO) experience. Once on the phishing page, the user was prompted to enter their Microsoft account credentials. Entering that information would send it to the attacker.

Microsoft Defender for Office 365 delivers protection powered by threat intelligence

As the phishing techniques we discussed in this blog show, attackers use common or standard aspects of emails to hide in plain sight and make attacks very difficult to detect or block. With our trend tracking in place, we can make sense of suspicious patterns, and notice repeated combinations of techniques that are highly likely to indicate an attack. This enables us to ensure we protect customers from the latest evasive email campaigns through Microsoft Defender for Office 365. We train machine learning models to keep an eye on activity from potentially malicious domains or IP addresses. Knowing what to look out for, we can rule out false positives and focus on the bad actors.

This has already paid off. Microsoft Defender for Office 365 detected and protected customers from sophisticated phishing campaigns, including the Compact campaign. We also employed our knowledge of prevalent trends to hunt for a ransomware campaign that might have otherwise escaped notice. We swiftly opened an investigation to protect customers from what seemed at first like a set of innocuous emails.

Trend tracking helps us to expand our understanding about prevalent attacker tactics and to improve existing protections. We’ve already set up rules to detect the techniques described in this blog. Our understanding of the threat landscape has led to better response times to critical threats. Meanwhile, deep within Microsoft Defender for Office 365, rules for raising alerts are weighted so that detecting a preponderance of suspicious techniques triggers a response, while legitimate emails are allowed to travel to their intended inboxes.

Threat intelligence also drives what new features are developed, and which rules are added. In this way, generalized trend tracking leads to concrete results. Microsoft is committed to using our knowledge of the threat landscape to continue to track trends, build better protections for our products, and share intelligence with the greater online community.

You are subscribed to National Cyber Awareness System Current Activity for
Cybersecurity and Infrastructure Security Agency. This information has recently
been updated, and is now available.

CISA
Provides Recommendations for Protecting Information from Ransomware-Caused Data
Breaches

08/18/2021 12:30 AM EDT

 

Original
release date: August 18, 2021

CISA has released the fact sheet Protecting
Sensitive and Personal Information from Ransomware-Caused Data Breaches to
address the increase in malicious cyber actors using ransomware to exfiltrate
data and then threatening to sell or leak the exfiltrated data if the victim
does not pay the ransom. These data breaches, often involving sensitive or
personal information, can cause financial loss to the victim organization and
erode customer trust.

The fact sheet provides information for organizations to use in preventing
and responding to ransomware-caused data breaches. CISA encourages
organizations to adopt a heightened state of awareness and implement the
recommendations listed in this fact sheet to reduce their risk to ransomware
and protect sensitive and personal information. Review StopRansomware.gov for
additional ransomware resources.

Control
assessments are not about checklists, simple pass/fail results, or generating
paperwork to pass inspections or audits. The testing and evaluation of controls
in a system or organization to determine the extent to which the controls are
implemented correctly, operating as intended, and producing the desired outcome
are critical to managing and measuring risk. Additionally, control assessment
results serve as an indication of the quality of the risk management processes,
help identify security and privacy strengths and weaknesses within systems, and
provide a road map to identifying, prioritizing, and correcting identified
deficiencies. 

Draft NIST Special Publication (SP) 800-53A Revision 5, Assessing Security and Privacy Controls in Information Systems
and Organizations, provides organizations
with a flexible, scalable, and repeatable assessment methodology and assessment
procedures that correspond with the controls in NIST SP 800-53, Revision 5.
Like previous revisions of SP 800-53A, the generalized assessment procedures
provide a framework and starting point to assess the enhanced security
requirements and can be tailored to the needs of organizations and assessors.
The assessment procedures can be employed in self-assessments or independent
third-party assessments.

In
addition to the update of the assessment procedures to correspond with the
controls in SP 800-53, Revision 5, a new format for assessment procedures in
this revision to SP 800-53A is introduced to:

• Improve the efficiency of
  conducting control assessments,
• Provide better traceability
  between assessment procedures and controls, and
• Better support the use of
  automated tools, continuous monitoring, and ongoing authorization
  programs.

NIST
is seeking feedback on the assessment procedures in this publication and in
electronic versions (OSCAL, CSV, and plain text), including the assessment
objectives, determination statements, and potential assessment methods and
objects. We are also interested in the approach taken to incorporate
organization-defined parameters into the determination statements for the
assessment objectives. To facilitate their review and use by a broad range of
stakeholders, the assessment procedures are available for comment and use in
PDF format, as well as comma-separated value (CSV), plain text, and Open
Security Controls Assessment Language (OSCAL) formats.

The comment period is open through October 1, 2021. See
the publication
details for a copy of the draft and associated files, and
instructions for submitting comments. We encourage you to submit comments using
the comment template provided.

Please
submit inquiries to [email protected].

 Cyber
attacks are a reality. Sometimes even with the best protective measures in
place, adversaries can breach perimeter defenses and find their way into systems.

Draft
NIST Special Publication (SP) 800-160, Volume 2, Revision 1, Developing
Cyber-Resilient Systems: A Systems Security Engineering Approach,
turns the traditional perimeter defense strategy on its head and moves
organizations toward a cyber resiliency strategy that facilitates defending
systems from the inside out instead of from the outside in. This guidance helps
organizations anticipate, withstand, recover from, and adapt to adverse
conditions, stresses, or compromises on systems – including hostile and
increasingly destructive cyber attacks from nation states, criminal gangs, and
disgruntled individuals.

This
major update to NIST’s flagship cyber resiliency publication offers significant
new content and support tools for organizations to defend against cyber
attacks, including ever-growing and destructive ransomware attacks. The
document provides suggestions on how to limit the damage that adversaries can
inflict by impeding their lateral movement, increasing their work factor, and
reducing their time on target.

In
particular, the draft publication:

• Updates the controls that
  support cyber resiliency to be consistent with NIST SP 800-53,
  Revision 5
• Standardizes a single threat
  taxonomy (i.e., Adversarial Tactics, Techniques, and Common Knowledge
  [ATT&CK] framework)
• Provides a detailed mapping and
  analysis of cyber resiliency implementation approaches and
  supporting NIST SP 800-53 controls to
  the ATT&CK framework techniques, mitigations, and
  candidate mitigations

The public comment period is open through September 20, 2021. See the publication
details for a copy of the draft and instructions for submitting
comments.

NOTE:
A call for patent claims is included on page v of this
draft.  For additional information, see the Information
Technology Laboratory (ITL) Patent Policy–Inclusion of Patents in ITL
Publications.

Publication
details:
https://csrc.nist.gov/publications/detail/sp/800-160/vol-2-rev-1/draft

ITL
Patent Policy:
https://www.nist.gov/itl/information-technology-laboratory-itl-patent-policy-inclusion-patents-itl-publications

 To continue to enable our customers to apply Microsoft Compliance solutions
to their entire data landscape including non-Microsoft systems we are
constantly expanding our Compliance ecosystem. Data connectors are built-in to
our Compliance platform and enable high-fidelity data ingestion. Once data is
ingested it is available for multiple compliance scenarios including Litigation
hold, eDiscovery, Retention settings, Records management, Communication
compliance as well as Insider risk management.

 

Data connectors
growth

Today we are excited to announce the addition of two new partners 17a-4 and
Cell Trust. These two new partners are bringing a wealth of new connectors and
categories of non-Microsoft data sources. Overall this has helped further
expand our connector catalog from 39 connectors – as announced earlier this year – to a total
of 65 connectors available in our connector gallery.

 

17a-4 connectors

17a-4 LLC focuses on assisting clients with SEC and FINRA compliance
requirements and the associated rules that govern Business Communications,
Electronic Messaging, and Books and Records.

 

“DataParser’s integration with Microsoft Compliance solutions further
enhances 17a-4’s partnership with Microsoft,” said Charles Weeden, Managing
Partner 17a-4, LLC. “With DataParser connectors, clients can bring users’ Zoom,
Slack, Webex, Bloomberg, etc. data into Microsoft 365 to benefit from various
compliance solutions including Litigation hold, eDiscovery, Retention, Records
Management and Communication Compliance.”

 

CellTrust connectors

CellTrust provides compliant and secure mobile communications for regulated
industries. CellTrust SL2™ is a communication platform for voice, text / SMS,
and chat.

 

“CellTrust is thrilled our flagship SL2™ is now available for use with
Microsoft Compliance solutions,” said Sean Moshir, CEO and Chairman. “SL2 keeps
personal and business mobile communications separate on a single device,
provides a dedicated Mobile Business Number™, and simultaneously captures
business data for various compliance solutions including Litigation hold,
eDiscovery, Retention, Records Management, and Communication Compliance – while
enhancing mobile collaboration and driving productivity within a secure
environment.”

 

Data connectors in
GCC

We have heard from our customers that governing data is critical to adhere
to compliance regulations. In a world where government employees work and
provide public services remotely, information is stored across numerous devices
in multiple disparate locations from on-premises to the cloud. This situation
makes it challenging to secure and govern data and to comply with regulations.
Today we are excited to announce the general availability of the following data
connectors – from our partner TeleMessage – for the Government Community Cloud
(GCC). This will provide government organizations with significantly greater
depth in governing critical data.

•    AT&T SMS/MMS
•   Bell SMS/MMS
•  Enterprise Number Archive
•  O2 Telefónica
•  Telus Text
•  Verizon SMS/MMS
• Android Archiver

More details on all the available external data sources along with supported
solutions are available here.

 Today, we are excited to announce that predictive vulnerability management
platform, DeepSurface,
has integrated across our threat and vulnerability management capabilities in
Microsoft Defender for Endpoint. Now, Microsoft Defender for Endpoint customers
can import vulnerability information across Microsoft, Linux and MacOS hosts
directly into the DeepSurface vulnerability management platform, further
strengthening our focus on interoperability.

 

“As the volume of
vulnerabilities increases, it’s critical that vulnerability management teams
can quickly identify which matter to their domain and filter out any that don’t
pose any risk to their organization. The status quo has been to juggle multiple
platforms and spend hours manually prioritizing vulnerabilities – this
integration between Microsoft and DeepSurface streamlines the number of
platforms for end-users and provides comprehensive, real-time insight into
their threat stance.” – Tomer Teller, Principal Security PM Lead,
Threat & Vulnerability Management at Microsoft

 

DeepSurface considers more than 50 different attributes of an environment to
contextualize vulnerabilities – and chains of vulnerabilities – within an
organization’s digital infrastructure to predict where an attacker could cause
the most damage and provides users with actionable intelligence on how to
reduce the most risk, fastest. Now, users of Microsoft Defender for Endpoint
have an integrated solution, easily operationalized in just a few minutes, that
provides them with at-a-glance insight into their threat stance.

 

Image
1 shows DeepSurface’s Risk Insight model. The paretograph shows all the patches
on your network and the relative risk they pose to your business, as well as
the number of affected hosts and number of vulnerabilities on your network.

 

 

DeepSurface integrates with Microsoft Defender for Endpoint APIs to collect
vulnerabilities and identify missing patches, then prioritizes the patches,
hosts and vulnerabilities based on a holistic threat model of your
infrastructure.

 

Image
2 shows the risk pathways or hacker roadmap of vulnerabilities and chains of
vulnerabilities that could be exploited on a network. By visualizing the most
exploitable risk paths, DeepSurface can help you identify which paths pose the
most risk to your business and prioritize where to patch first.

 

 

When viewing a specific patch, DeepSurface can show users which hosts are
affected, and the severity of the risk for each host after taking the holistic
context of your network into account.  DeepSurface also provides
information about patch supersedence, and extra steps required to fully mitigate
the vulnerabilities covered by the patch.

 

Integration is quick and seamless. All you have to do is add your API key to
the DeepSurface console (see screenshot below). Documentation is available for
DeepSurface customers.

 

Image
3: DeepSurface setup console to configure the Microsoft Defender for Endpoint
integration.

 

 

For additional details, you can view the full press release here.

 

At Microsoft, we believe that when solutions work well together, customers
benefit and can build stronger defenses. That’s why the Microsoft threat and
vulnerability management APIs give partners like DeepSurface, as well as
security full access to the threat and vulnerability management dataset,
allowing them to build integrations or other custom workflows.

 

More information and
feedback

• The threat and vulnerability management capabilities
  are part of Microsoft Defender for Endpoint and enable
  organizations to effectively identify, assess, and remediate endpoint
  weaknesses to reduce organizational risk.
• Documentation on how to configure the integration is
  available for DeepSurface customers in the product portal.