General Blog

Your Microsoft Teams chats aren’t as private as you think..

Encrypt and Anonymize Your Internet Connection for as Little as $3/mo with PIA VPN. Learn More

Microsoft Teams is a proprietary business communication platform developed by Microsoft, as part of the Microsoft 365 family of products. Teams primarily competes with the similar service Slack, offering workspace chat and videoconferencing, file storage, and application integration, and is used by hundreds of thousands of organizations across the world.

While some companies have policies that instruct users not to send sensitive information through cleartext channels, like Microsoft Teams, I’ve came across many organizations that do not adopt this behavior. A compromised Office 365 account could lead to all kinds of trouble, including giving an attacker access to communicated passwords, AWS keys, or PII through Microsoft Teams. To help counter this, companies may implement strict Conditional Access Policies and require MFA in order to gain access to a user’s Office 365 account. But what if I told you that you didn’t need the Office 365 account to read messages sent in Microsoft Teams?

Follow along and I’ll show you how access to a hard drive could be all an attacker needs to gain access to your “secret” Teams chats.


Where do Microsoft Teams messages live?

It’s no secret that Microsoft Teams is a cloud-based collaboration tool, so there is no doubt that the data sent to/from Microsoft Teams is stored in Microsoft’s cloud. However, it turns out that chat messages sent through Microsoft Teams also gets stored locally on a filesystem in the following location.

%AppData%\Microsoft\Teams\IndexedDB\https_teams.microsoft.com_0.indexeddb.leveldb

Within this directory is a .log file that contains a lot of information. At first glance, you may think the file just contains a bunch of computer gibberish, but sorting through the data can reveal some valuable secrets.


Let’s prove a concept.

So take a scenario where an end-user asks another end-user for help signing into an account. In this case, Michael Scott is asking Pam for his computer login since he can never remember. He sends the message through Teams, perhaps on his phone, and Pam replies.

Now let’s go review that log file on either one of their computers that has Teams up and running. Any user that has local administrator access to this computer would be able to access this file, even for other users on the system.

Surely there is a way to parse this data natively in Windows, but the following command works very nicely in Linux, so I will just copy the log file off the system and place it onto my Kali box.

cat teams.log | grep \<div\> -A 2 | grep '\<div\>\|display' | cut -d ">" -f 2 | cut -d "<" -f 1 | uniq | sed 's/imdisplayname//g' | tr -d \" 

The output of the command isn’t the most graceful, but there’s enough text here to make out the gist of the conversation.

@_Xenov made a PowerShell parser that you can find below, or on GitHub.

$firstString = "<div"
$secondString = "div>"

$importPath = "$Env:AppData\Microsoft\Teams\IndexedDB\https_teams.microsoft.com_0.indexeddb.leveldb\*.log"

$text = Get-Content $importPath

#Sample pattern
$pattern = "(?<=$firstString).*?(?=$secondString)"

$output = [regex]::Matches($text,$pattern).value

$hash = @{} 
echo $output | %{if($hash.$_ -eq $null) { $_ }; $hash.$_ = 1} 

Why do we care?

Armed with this information, why does this matter? This is an important attack vector for the following reasons.

Organizations that communicate credentials over Microsoft Teams. As a Penetration tester, I’ve seen passwords, social security numbers, addresses, AWS keys, sensitive admin panels, and much more be communicated through Microsoft Teams. All of this could be potentially accessible to any user who gains access to a system or hard-drive that has ran the software.

Organizations that give everybody local admin rights. Many organizations still provide end-users local admin rights on their computer systems. Imagine a scenario where an end-user is compromised and runs a piece of malware that made it through the email security filter. This would allow a remote, unauthenticated threat actor full access to the filesystem, and therefor, any Microsoft Teams chat logs on this system.

Organizations that assign multiple users to the same system. Given that a user has a local admin rights, they’d have read access to any other user’s AppData directory. This would allow them to read the messages of other users on the same system as them, without ever generating access logs or needing to authenticate to Office 365.

Old hard drives that aren’t properly encrypted or wiped. When’s the last time you discarded a computer or hard-drive? Did you wipe it first? Did you ensure that all blocks on the drive has been rewritten? Did you have encryhption enabled before-hand? If the answer to any of these questions is “no”, then the next owner of that hard-drive may be able to read your Teams chat history.


Where do we go from here?

I’ve only performed very little research on this so far, and I’m left with many questions.

  1. How long do these chat messages stay in the log file?
  2. Is this limited to only chat messages, or can we extract details about Team Channel updates as well?
  3. What about attachments or images being transferred?
  4. Can scripts or tools be written to easily parse this in a much more efficient manner?

While I will continue to research this and develop my own tools, this is where I look to the community. If you know of security research on this topic, or a tool that is already developed that can easily parse these log files, please let me know.

This article may be updated as time goes on.

General Blog

Disabling LLMNR and NBT-NS in Your Network

I’ve made a handful of articles on attacking LLMNR within Active Directory environments, but I’ve never made anything that helps IT Admins mitigate this vulnerability. This post intends to serve as a guide for patching this vulnerability that is enabled by default in Windows.

Keep in mind that we need to not only disable LLMR, but also NBT-NS.

Table of Contents:

  • What is LLMNR & NBT-NS?
  • Great! So how can I exploit this?
  • Eek. So how do we patch this?
    • Disable LLMNR via Group Policy
    • Disable LLMNR via Command Line
    • Disable NBT-NS via Registry
    • Disable NBT-NS via PowerShell

What is LLMNR & NBT-NS?

Crowe.com does a fantastic job at giving you a high-level overview of what NetBIOS & link-local multicast name resolution do. Instead of reinventing the wheel, I will simply provide an excerpt from their website below.

“NetBIOS and LLMNR are protocols used to resolve host names and facilitate communication between hosts on local networks. NetBIOS is generally outdated and can be used to communicate with legacy systems. LLMNR is designed for consumer-grade networks in which a domain name system (DNS) server might not exist.”

If none of this sounds familiar, I highly recommend checking out the below link and reading more about these protocols before moving on.

https://www.crowe.com/cybersecurity-watch/netbios-llmnr-giving-away-credentials


Great! So how can I exploit this?

When a computer requests access to a legitimate network resource, it usually follows a set of pre-defined queries. LLMNR and NetBIOS come into play as last resort options when other methods (such as DNS or local hosts files) don’t prove helpful. Since LLMNR & NetBIOS will attempt name resolution via broadcasted requests to the broadcast-domain, we can set up tools to listen for these requests and respond back pretending to be the intended recipient.

Name Resolution Response Attack

If you’re interested in learning how attackers abuse this protocol, check out one of my guides below.


Eek. So how do we patch this?

Disable LLMNR via Group Policy

In Windows Active Directory, resolving this problem is as simple as applying a GPO. Sign into your Domain Controller and navigate to the Group Policy Management Editor. You’ll want to right click on your FQDN and select Create a GPO in this domain, and Link it here.

Go ahead and give it a name and click OK.

Then you’ll want to right-click on it and select Edit.

Now we just need to navigate to the following policy.

Computer Configuration -> Administrative Templates -> Network -> DNS Client -> Turn Off Multicast Name Resolution

Enable the policy by changing its value to Enabled.

Disable LLMNR via PowerShell / Command Line

But what do you do if you aren’t working with a Windows Active Directory domain? You can still patch this problem using the command line.

REG ADD  “HKLM\Software\policies\Microsoft\Windows NT\DNSClient”
REG ADD  “HKLM\Software\policies\Microsoft\Windows NT\DNSClient” /v ” EnableMulticast” /t REG_DWORD /d “0” /f

Disable NBT-NS via Registry

Open the registry by typing Regedit in the run dialogue. Navigate to registry key at the following location.

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\

From here, we’ll be presented with multiple keys, each represents a network interface. You’ll want to adjust the NetbiosOptions value on each from the default of zero, to a value of 2.

Disable NBT-NS via PowerShell

To take care of the above mention step via PowerShell, you can run the following commands.

$regkey = "HKLM:SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces"
Get-ChildItem $regkey |foreach { Set-ItemProperty -Path "$regkey\$($_.pschildname)" -Name NetbiosOptions -Value 2 -Verbose}

That’s it! You should be all set.

General Blog, Pentesting

Installing Covenant C2 on Windows

Covenant C2 is described by its authors as “A . NET command and control framework that aims to highlight the attack surface of . NET, make the use of offensive . NET tradecraft easier, and serve as a collaborative command and control platform for red teamers.”

This post is meant to supplement a video that I uploaded to my YouTube channel.


Installing Prerequisites

To begin, we have some prerequisites to install. They both can be found at the following links. Both installers work well with default settings and just basic “Next, Next, Finish”.

https://dotnet.microsoft.com/download/dotnet-core/3.1

https://git-scm.com/download/win


Creating Windows Defender Exclusion

Once installed, let’s create a directory at the following location.

mkdir c:/opt

And then you can add the Exclusion in Windows Defender.


Downloading and Building Covenant

Launch Git as Administrator and run the following commands.

cd c:/opt
git clone --recurse-submodules https://github.com/cobbr/Covenant
cd Covenant/Covenant
dotnet run

Once its finished, you can access Covenant via https://127.0.0.1:7443

General Blog

Importing Email Addresses & Domains to Blacklist in Office 365 Using PowerShell


Preparing the List

I recently had to migrate away from our third-party spam filter. I was able to get them to send us a CSV file that contains a list of all our blocked domains/email addresses, but that list was not very clean.

For example, it looked like this with a mix of domains and email addresses.

In order to make this work, I needed to clean up the list to extract emails to one file, and domains to another. To do that, I used the following commands within Kali Linux to make two new files; one that contains a list of emails, and a 2nd that contains a list of domains.

cat tmp.txt | grep @ | sort -u > emails.txt

cat tmp.txt | grep -v @ | sort -u > domains.txt


The PowerShell Section

Regardless which of the below scripts you use, you’ll need to connect to Exchange Online using something like the below.

$UserCredential = Get-Credential
$Session = New-PSSession –ConfigurationName Microsoft.Exchange –ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential –Authentication Basic -AllowRedirection
Import-PSSession $Session

Importing Domains to Block List

With our lists ready, I used the following code to import the domains.

$domains = "C:\temp\domains.txt" # EDIT THIS

$count = 1
foreach ($content in ($total = get-content $domains)){
	$totalcount = $total.count
	Set-HostedContentFilterPolicy -Identity Default –BlockedSenderDomains @{add=$content}
	write-host "Added $count entries of $totalcount : $content"
	$count += 1
}

Importing Emails to Block List

With our lists ready, I used the following code to import the email addresses.

$emails = "C:\temp\emails.txt" # CHANGE THIS

$count = 1
foreach ($content in ($total = get-content $emails)){
	$totalcount = $total.count
	Set-HostedContentFilterPolicy -Identity Default –BlockedSenders @{add=$content}
	write-host "Added $count entries of $totalcount : $content"
	$count += 1
}


How do we know this worked?

Let’s head over to the Exchange Admin Center. From there, we’ll go into Protection and find the Spam Filter.

Open up the Default policy and head over to the Block Lists. You should see your entries here.

General Blog

Symmetric Encryption vs Asymmetric Encryption


Symmetric Encryption

A single, shared key is used to both encrypt and decrypt the data. You’ll want to handle this key with caution and only share it to those that need access to that data.

Pros:

  • Works great if we only need to secure data for a single machine or a single user.
  • Very fast to use. Uses little resources.
  • Because of this, it is efficient for large data.

Cons:

  • Does not scale very well. Since users must have the key to encrypt/decrypt the information, this key needs to be shared around to everybody who uses it, making it a lot harder to manage and keep secure.
  • Since you don’t want to make this single key public, actually sharing the key so that people can encrypt their communication to you can be difficult and opens the door for the key to be stolen by an intruder.

What are some algorithms that use this type of encryption?

  • AES (Advanced Encryption Standard)
  • DES (Data Encryption Standard)
  • Twofish
  • Serpent

Great, so when would you actually use this type of encryption?

While symmetric encryption is an older method of encryption, it is faster and more efficient than asymmetric encryption, which takes a toll on networks due to performance issues with data size and heavy CPU use. Due to the better performance and faster speed of symmetric encryption (compared to asymmetric), symmetric cryptography is typically used for bulk encryption / encrypting large amounts of data, e.g. for database encryption. 

  • This is a great solution for data at rest. If the data is already present, you have no need to transfer it (and therefor transfer your encryption keys).
  • Payment applications where there are card transactions and PII needs to be protected.
  • Validations to confirms that the sender of the message is who they claim to be.
  • Random number generation or hashing for password storage.

Asymmetric Encryption

Oftentimes referred to public key cryptography. Unlike Symmetric Encryption, two keys are needed in Asymmetric Encryption. You have a private key that you never share with anybody else. Then, there is a public key that everybody can use. Anybody can see it, so you don’t need to worry about securing it. You can’t derive the private key from the public key.

The idea behind this is that anybody can encrypt data with your public key (since the key is readable by anybody), but the only key that can decrypt that data is the private key owned and secured by you. This means that only you should be able to decrypt the data because, in theory, nobody else would have the private key.

Pros:

  • Public key can be shared, resolving the problem of securely transporting keys.
  • Allows you to create secure encrypted channels across multiple devices and users a lot easier.

Cons:

  • Very resource intensive. Takes a lot of time to properly decrypt the message.
  • Because it’s slow, designed for small data. Inefficient for large data.

So what are some algorithms that use this type of encryption?

  • RSA
  • Diffie-Hellman
  • TLS

Great, so when would you actually use this type of encryption?

Asymmetric encryption is best useful in cases where data is in transit, or to create digital signatures that provide a layer of validation and security to messages sent through a non-secure channel.

General Blog

Let’s Talk Basics About Cross Site Request Forgery (CSRF)

It became apparent to me that my understanding of CSRF was lacking, or uh, basically non-existent. This post aims to fix that! Come learn about it along with me.

Note: This particular post is NOT a hacking tutorial on abusing CSRF, though I’m sure I will post one in the near future (make sure to subscribe or hit up my Twitter feed so you’ll know when that comes out).


What is Cross Site Request Forgery?

Well we know that it is consistently in the OWASP Top 10 for web application vulnerabilities, but what does it actually do?

CSRF is when another website is able to make a request, as a victim user, to the target website. What does that mean? Well, it means that an attacker may trick the users of a web application into performing unwanted tasks, such as transferring funds, changing their email address, deleting their account, posting a comment, etc.

Let’s say there is a web application running on vulnerable.com (please don’t try to actually visit this site, I have no idea what is there and whether or not its a valid webpage). In our fake scenario, vulnerable.com hosts a simple web application where you can create an account and post a comment on a text board. There is also a page for you to be able to delete your account. Normally, if an end-user wanted to actually delete their account, they would browse to this page, click the confirmation button, and then a request would be made to the webserver that looks something like this:

POST /delete_my_account HTTP/1.1
Host: vulnerable.com
Content-Type: application/x-www-form-urlencoded
Cookie: SessionID=d42be1j5

delete = 1

The key items to note about this is that there is a POST request to vulnerable.com/delete_my_account for a specific SessionID. Now in a perfect world, the only person who would initate this request would be the actual end-user behind that SessionID, but what if us — evil hackers — wanted to delete the account for them without their consent?

This is where CSRF comes in. Let’s, as attackers, spin up a malicious webpage at evil.com (same disclaimer as before) and add code so that we initiate that same request mentioned above once a user accesses our webpage. If vulnerable.com doesn’t have protections in place, we could leverage CSRF to send the same POST request and delete user accounts on a completely separate website without the users consent.


So how do we mitigate this?

There are a number of mitigation techniques.

Add a hash (session id, function name, service-side secret) to all forms.
This method involves including a random, unique identifier to webforms when a user accesses the page. The idea behind this technique is that attack webservers will not possibly be able to know what unique identifier is being used for the victim user on the target website. This means that even if they attempt a CSRF attack, the target website will notice that the unique identifier is missing and reject the POST request.

Checking the Referrer header in the client’s HTTP request.
When a web request is submitted, there is typically a referrer header added that specifies where that web request originated. Ensuring that the request has come from the original site means that attacks from other sites will not function.

Note: This method may not always be reliable for web-developers if the user utilizes ad-blocker or additional privacy protection methods, as the referrer header on a valid web request may indicate the request came from one of these third parties.

Signing off of webpages when not in use.
While CSRF is really a problem with the web application, and not the end user utilizing the webpage, users can protect themselves by signing out or killing any active sessions for their sensitive webapps BEFORE browsing the web or accessing a different page.

General Blog

Have a WebApp? Here Are Three HTTP Headers Leaking Your Server Information

This post intends to discuss the three most common HTTP headers that leak server information. While these headers don’t do anything to help protect against attacks, they can be used by attackers to enumerate the underlying technologies behind the application during the early enumeration phase of an attack.

If you’d like to learn more about HTTP headers that can help mitigate a range of attack vectors, check out my previous post What are Web Application HTTP Security Headers? When do you use them?


SERVER

What does this header do?
This header contains information about the software used by the back-end server (type and version).

EXAMPLE:

We’re able to identify that this webserver is running IIS 8.5 based on the Server header.


X-POWERED-BY

What does this header do?
It contains the details of the web framework or programming language used in the web application. 

EXAMPLE:

We’re able to identify example what PHP version is being used on this webserver by it’s X-Powered-By header.


X-ASPNET-VERSION

What does this header do?
As the name suggests, it shows the version details of the ASP .NET framework. This information may help an adversary to fine-tune its attack based on the framework and its version.

EXAMPLE:

We’re able to identify exactly what ASP .NET version is running on this webserver based on the X-AspNet-Version header.


Why do we care? What can do we do about it?

Why is this dangerous?
Because these headers can leak software information, this allows an attacker to know what exact web technologies are in place and what their associated version(s) are. Armed with this information, they can then hunt for public known exploits on those versions.

What is your recommendation?
The server information can be masked by re-configuring the webserver to read something other than the actual server technologies in place.

General Blog

What are Web Application HTTP Security Headers? When do you use them?

This post intends to serve as a guide for some of the most common HTTP Headers web applications use to prevent exploitation of potential vulnerabilities. Within this article, you will discover the name of the various headers, along with their use case and various configuration options.

If you’d like to learn more about which headers may be leaking information about the software running on your webserver, check out my other post titled Have a WebApp? Here Are Three HTTP Headers Leaking Your Server Information.

Table of Contents:

  • Strict-Transport-Security
  • Content-Security-Policy
  • Access-Control-Allow-Origin
  • Set-Cookie
  • X-Frame-Options
  • X-XSS-Protection
  • Additional Resources

STRICT-TRANSPORT-SECURITY

What does this header do?
HTTP Strict Transport Security instructs the browser to access the webserver over HTTPS only.

Why would we use this?
By enforcing the use of HTTPS, we’re ensuring that users accessing the web page has a secure, encrypted connection. This can also help users notice whether or not they are victim to man in the middle attacks if they receive certificate errors when a valid certificate is in place on the webpage.

What values can we set this header to?
There are 3 directives for this header:

  • Max-Age : Default value of 31536000. This is the maximum age (time) for which the header is valid. The server updates this time with every new response to prevent it from expiring.
  • IncludeSubDomains : This applies control over subdomains of the website as well.
  • Preload : This is a list that is maintained by Google. Websites on this list will automatically have HTTP enforced in the Google Chrome browser.

CONTENT-SECURITY-POLICY

What does this header do?
Content Security Policy is used to instruct the browser to load only the allowed content defined in the policy. This uses a whitelisting approach which tells the browser from where to load the images, scripts, CSS, applets, etc.

Why would we use this?
If implemented properly, we would be able to prevent exploitation of Cross-Site Scripting (XSS), Clickjacking, and HTML Injection attacks. We do this by carefully specifying where content can be loaded from, which hopefully isn’t a location that attackers have control of.

What values can we set this header to?
The values can be defined with the following directives:

  • default-src
  • script-src
  • media-src
  • img-src
EXAMPLE:

Content-Security-Policy: default-src 'self'; script-src runscript.com; media-src online123.com online321.com; img-src *;

This is would be interpreted by the browser as:

  • default-src 'self' : Load everything from the current domain.
  • script-src runscript.com : Scripts can only be loaded from runscript.com
  • media-src online123.com online321.com : Media can only be loaded from online123.com and online321.com.
  • img-src * : Images can be loaded from anywhere.

ACCESS-CONTROL-ALLOW-ORIGIN

What does this header do?
This header indicates whether the response can be shared with requesting code from the given origin.

Why would we use this?
This is used to take a whitelisting approach on which third parties are allowed to access a given resource. For example, if site ABC wants to access a resource on site XYZ (and is allowed to), XYZ will respond with a Access-Control-Allow-Origin header with the address of site ABC to instruct the browser that this is allowed.

What values can we set this header to?
The following directives can be used:

  • * : For requests without credentials, you can specify a wildcard to tell browsers to allow requesting code from any origin to access the resource.
  • <origin> : Specifics a single origin.
  • null : This should not be used.

SET-COOKIE

What does this header do?
This response header is used to send cookies from the server to the user agent, so the user agent can send them back to the server later. One important use of cookies is to track a user session, and can oftentimes contain sensitive information. Because of this, there are additional attributes that we can set for securing the cookies.

Why would we use the additional attributes?
Using these additional attributes can help protect the cookies against unauthorized access.

What values can we apply?
While there are many attributes for a cookie, the following are most important from a security perspective.

  • Secure : A cookie set with this attribute will only be sent over HTTPS and not over the clear-text HTTP protocol (which is susceptible to eavesdropping).
  • HTTPOnly : The browser will not permit JavaScript code to access the contents of the cookies set with this attribute. This helps in mitigating session hijacking through

X-FRAME-OPTIONS

What does this header do?
This header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe> or <object>.

Why would we use this?
Use this to avoid clickjacking attacks. Without clickjacking protections, an adversary could trick a user to access a malicious website which will load the target application into an invisible iframe. When the user clicks on the malicious application (ex. a web-based game), the clicks will be ‘stolen’ and sent to the target application (Clickjacking). As a result, the user will click on the legitimate application without his consent, which could result in performing some unwanted actions (ex. delete an account, etc).

What values can we set this header to?
There are 3 directives we can use:

  • deny : This will not allow the page to be loaded in a frame on any website.
  • same-origin : This will allow the page to be loaded in a frame only if the origin frame is same.
  • allow-from uri : The frame can only be displayed in a frame on the specified domain/origin.

X-XSS-PROTECTION

What does this header do?
This header enables the Cross-site scripting (XSS) filter built into most recent web browsers.

Why would we use this?
The sole purpose is to protect against Cross-Site Scripting (XSS) attacks.

What values can we set this header to?
There are 3-modes that we can set this header to:

  • 0; : Disables the XSS filter.
  • 1; : Enables the filter. If an attack is detected, the browser will sanitize the content of the page in order to block the script execution.
  • 1; mode=block : Will prevent the rendering of the page if an XSS attack is detected.

Additional Resources

This is nowhere near an exhaustive list of the different security headers that you should be using. Should you like to learn more or dive into this topic deeper, I’d recommend checking out the following websites:

Essential HTTP Headers for Securing Your Web Server

Mozilla’s HTTP Headers Documentation

General Blog

My Top 3 OSCP Resources (Ippsec, TheCyberMentor, & 0xdf)


I have seen many people ask the community for help regarding good resources and figured I should create this post to share my two cents on the topic. I started this journey about 6-8 months ago and have soaked in a ton of content during that time.


 TheCyberMentor

Use this when first starting out! He has a pentesting for noobs series that goes through the HackTheBox materials and it’s fantastic for learning basic methodologies and things you need to know from ground zero. He’ll walk you through some easy boxes and hold your hand as you’re exploring this for this first time. His material is heavy on Metasploit, which is a tool that you’ll want to be familiar with, but don’t rely on it too much as you can’t use it more than once on the OSCP exam.

Link to his YouTube

Link to his Twitter


Ippsec

I swear this man is a god and the amount of knowledge that he has obtained on the topic of hacking is tremendous. I believe that his content is developed with a more intermediate target audience in mind, so he doesn’t always explain the basic stuff like TheCyberMentor does. Start with TCM, and move to Ippsec once you’ve got the basics down. Don’t sleep on Ippsec!!! His videos are long, and there are plenty out there, but he teaches so much. I’ll spend hours dissecting 15mins of his video just taking notes so I can use tips he’s shown me later.

Link to his YouTube

Link to his Twitter


0xdf

Their blog posts are some of the best written HackTheBox write-ups I’ve come across. They do a great job at breaking down multiple attack avenues and explaining the concepts. If you’d rather skim through a blog than watch a video, this is the place to go. Their posts are easy to follow, and I’ve learned some awesome tricks while going through them.

Link to their blog

Link to their Twitter


Obviously this is far from an exhaustive list, but it should provide a great starting point for those entering this journey with us. I’d love to hear about which resources you use as well!

General Blog, General IT, Windows Updates/Patches

Patching CVE-2020-0601 | Windows CryptoAPI Spoofing Vulnerability

As I’m sure you’ve heard, there were a handful of critical vulnerabilities announced in this week’s Patch Tuesday. Included in the list of vulnerabilities is a flaw within CryptoAPI that would allow an attacker to digitally sign malicious software updates as the legitimate creator of the software. While Microsoft lists this vulnerability with a severity level of Critical, an attacker would need to first insert themselves as a Man in The Middle to be able to intercept a device’s software update request and return back a digitally signed malicious executable.

Table of Contents
– Affected Operating Systems
– KB’s Needed to Patch Vulnerability

If you have the time, I’d highly recommend the below Webcast on this topic from the SANS Institute’s YouTube page. It goes above any beyond any level of detail I would be able to.


Affected Operating Systems

  • Windows 10
  • Windows Server 2016
  • Windows Server 2019

Note: Windows 7 and older are NOT vulnerable. The Windows Update Service itself is NOT vulnerable.


Patching CVE-2020-0601

Microsoft’s official documentation on this topic can be found at the below link. https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0601

The exact patch that you need depends on the exact OS Build of Windows 10 you’re running. Below is a list of the related KBs and which Operating System they patch. This list is current as of this blog’s posted date.

I recommend searching for your Build of Windows 10 by using Ctrl+F and typing the version (I.E 1909, 1903, etc.)


ArticleKB4528760
Download Linkhttps://www.catalog.update.microsoft.com/Search.aspx?q=KB4528760
Operating System(s)Windows Server, version 1903 (Server Core installation)
 Windows Server, version 1909 (Server Core installation)
 Windows 10 Version 1903 for 32-bit Systems
 Windows 10 Version 1903 for ARM64-based Systems
 Windows 10 Version 1903 for x64-based Systems
 Windows 10 Version 1909 for 32-bit Systems
 Windows 10 Version 1909 for ARM64-based Systems
 Windows 10 Version 1909 for x64-based Systems

ArticleKB4534273
Download Linkhttps://www.catalog.update.microsoft.com/Search.aspx?q=KB4534273
Operating System(s)Windows Server 2019
 Windows Server 2019 (Server Core installation)
 Windows 10 Version 1809 for 32-bit Systems
 Windows 10 Version 1809 for ARM64-based Systems
 Windows 10 Version 1809 for x64-based Systems

ArticleKB4534293 
Download Linkhttps://www.catalog.update.microsoft.com/Search.aspx?q=KB4534293
Operating System(s)Windows Server 2016, version 1803 (Server Core Installation)
 Windows 10 Version 1803 for 32-bit Systems
 Windows 10 Version 1803 for ARM64-based Systems
 Windows 10 Version 1803 for x64-based Systems

ArticleKB4534276 
Download Linkhttps://www.catalog.update.microsoft.com/Search.aspx?q=KB4534276
Operating System(s)Windows 10 Version 1709 for 32-bit Systems
 Windows 10 Version 1709 for ARM64-based Systems
 Windows 10 Version 1709 for x64-based Systems

ArticleKB4534271 
Download Linkhttps://www.catalog.update.microsoft.com/Search.aspx?q=KB4534271
Affected O/SWindows Server 2016
 Windows Server 2016 (Server Core installation)
 Windows 10 Version 1607 for 32-bit Systems
 Windows 10 Version 1607 for x64-based Systems