Detect

Audit Scheduled tasks using Azure Sentinel

hunting queries

Azure Sentinel is a powerful cloud based SIEM solution.
This blog series will be on how to work with Sentinel.

It will be example based on different solutions which we might run into.

This first post is about how you can work with logs and get insight in Scheduled Tasks as a way for attackers to persist in your network

For further information regards Sentinel, visit https://azure.microsoft.com/en-us/services/azure-sentinel/

Scheduled Tasks

By default there are no events created if someone creates or modifieds a scheduled task. To enable logging you have to enable logging of object access.

To view current settings, use the following command:

auditpol.exe /get /category:*

Only Success is required for this. This enables us to get the event 4698

To enable logging, create a new GPO and assign the following settings (depending if you want success/failure or only success)

You also have to configure your agents to send log to your workspace, you can download the agent from the Azure Sentinel workspace / <workspace name> / Advanced Settings

Otherwise, you can add the Sentinel workspace to your existing agents

$Agent = New-Object -ComObject AgentConfigManager.MgmtSvcCfg
$ID= "<WorkspaceID>"
$Key = "<key>"
$Agent.AddCloudWorkspace($ID,$Key)
restart-service HealthService

In Azure Sentinel – Data connectors, configure Security Events

Azure Sentinel Connectors

Verify heartbeats from computers


Heartbeat | summarize argmax(TimeGenerated, *) by Computer


So now we have logs from 2 computers and now we want to query Scheduled Tasks

A simple way is to just query the EventID

sentinel

We can use project to format our table but we still want to get information about the tasks that were created to get a better overview


According to documentation we can use Parse operator into one or more calculated columns

https://docs.microsoft.com/en-us/azure/kusto/query/parseoperator

//Example
SecurityEvent
| where EventID == "4698"
| parse EventData with * '"SubjectUserName">' SubjectUserName '<' * '"SubjectDomainName">' SubjectDomainName '<' *

This query will

  • Select all events where eventid=4698
  • parse the column event data and look for ‘”SubjectUserName”>’
  • Put everyting to a column named SubjectUserName until character ‘<‘
  • the wildcard will run the samething again
  • Continue parsing until ‘”SubjectDomainName”>’
  • Put everything into column SubjectDomainName until character ‘<‘
sentinel

To continue this to get some really useful information we continue to parse the content until we get everything we need

//Sec-Labs Demo - Sentinel Hunting for Scheduled Tasks Persistance
let start=datetime("2019-03-12T19:39:47.762Z");
let end=datetime("2019-03-19T22:39:47.762Z");
SecurityEvent
|where TimeGenerated > start and TimeGenerated < end
| where EventID == "4698"
| parse EventData with * '"SubjectUserName">' SubjectUserName '<' * '"SubjectDomainName">' SubjectDomainName '<' * '"TaskName">\\' TaskName '<' * 'Author>' Author '<' * '<Command>' SchedCommand '</Command' * 'Arguments>' SchedArgs '</Arguments' * 'WorkingDirectory>' SchedDir '&' *
| where isnotempty (SubjectUserName) 
| project TimeGenerated,SubjectUserName,Computer,Activity,SubjectDomainName,TaskName,SchedCommand,SchedArgs,SchedDir
| project-rename CreatedBy = SubjectUserName

hunting queries

To rename columns, you can use project-rename <new name> = <old column name>

Happy Hunting!

Problems with self-encrypting drives

Microsoft has published ADV180028

The advisory explains the recently discovered vulnerabilities for self-encrypting drives. SED’s means that the drive is encrypted using the hardware instead of software only encryption provided by BitLocker Drive Encryption™.

The vulnerability was discovered by Carlo Meijer and Bernard van Gastel from the Radboud University in the Netherlands.

Verify encryption method using Powershell

Get-BitLockerVolume | select encryptionmethod,mountpoint,VolumeType

bitlocker

In this example, the device is not vulnerable since hardware encryption is not present.

This code smippet will return if the machine is vulnerable or not (compliant $true) (vulnerable $false) based on encryption method which can be used with SCCM to get an overview in larger Environments.
$BitlockerVolume = Get-BitLockerVolume | select encryptionmethod,mountpoint,VolumeType,ProtectionStatus |? { $_.VolumeType -eq "OperatingSystem" -and $_.ProtectionStatus -eq "On" }

switch ($BitlockerVolume.encryptionmethod) {
Aes128 { $true }
Aes256 { $true }
Aes128Diffuser { $true }
Aes256Diffuser { $true }
XtsAes128 { $true }
XtsAes256 { $true }
Default { $false }
}

This work was done together with Jörgen Nilsson (https://ccmexec.com) who has a detailed post about this and how to use SCCM to get the current status of compliant devices which is linked to below. He also provided a cab-fil which can be imported

Bitlocker Compliance using SCCM including Hardware encryption check

New features added to WD ATP

In the September release one of our most wanted features was added to WD ATP preview, Custom detection with scheduled queries.

This means that you can now develop your own hunting queries and run them every day automatically.

For this example we created a query to find a simple reverse shell from a Linux machine which runs Ziften.

Next step is to create a detection rule for the Query

detection rule

You can add Alert Title, Severity, Category, Description and Recommended actions.

It will be good if you add some details in the recommended actions if someone else will take action on the alert, or at least add a pointer to where they can find further information on requred actions. (Information sharing is important).

It’s possible to change this infomation later on.

detection rule page

On the Detection Rule page you can see the alerts and other information regards the detection rule.

All the rules will be listed at the left side in the hunting section.

custom detection

For further infomation about the new preview features please go to this url:

https://techcommunity.microsoft.com/t5/What-s-New/WDATP-September-2018-preview-features-are-out/m-p/242254#M95

Happy hunting!

/Sec-Labs

6000+ sites are still leaking sensitive WordPress config files

Well, this isn’t anything new, not at all!

Google Hacking Database has been around for a long time.

We started to dig into WordPress config files and realized that it’s very common to create a backup of your config file, which is not a bad idea.

This config file contains the base configuration of a wordpress installation like Database Connection (user name, password, ost) and other sensitive information.

Example

config

What’s really bad is that some admins seems to store the file in the web root and changed the extension to txt will will be read in the browser.

If we change the file extension to .txt it will be managed by the web server/php interpreter as any other txt file and present the content to the user.

So if we look at one part that exists in the WordPress config file.
“define(‘AUTH_KEY’, ‘” and we also have some other phrases like “wp-config.php”.

If you want an idea of how bad it is we can let google sort that out for us using some search operands available.
Since google knows the content of all files it has indexed which are most of them we just search for the content using “intext:” and filter on txt files using “filetype:”

intext:define(‘AUTH_KEY’, ‘ wp-config.php filetype:txt

The result shows about 6000+ results (and probably some false positives in the results).

ghdb

This file is not something that would be read by the user and you should not be able to download the php file either ;).

What you need to do

  • Don’t place sensitive files in the web root that doens’t have to be there
  • Configure permissions
  • Definitely don’t place backup files in the webroot, in case you don’t have to temporarily to reinstall a web application but otherwise, keep them away from the internet

Working with Roles in Windows Defender ATP

As with everything else we want to apply a least privilege access.

If you need permission to do X you should only have access to do X and not several other things.

That’s why you should define the roles and reponsibilities in your organization to make sure you can apply a least privilege strategy.

Many products supports RBAC and should be used.

Working with Roles in Windows Defender ATP is very simple. You can enable it in Settings menu.

Settings > Roles > Enable Roles

enableRoles

The Global administrator role is added by default and have full permissions which can’t be changed.

Creating Roles

It’s not a bad idea to create a few roles, even if it’s just ju who are the complete security team. One reason is organizational changes and one important reason is that we don’t want people to work as global administrators.

Create Role

In Settings > Permissions > Roles > Add Role

createrole

Assign Azure AD group to the role

aadgroups

 

One example of roles setup could be:

  • Viewonly – For managers, able to view data
  • ATP-Users – Teams working with ATP, run scans, threat remediation etc
  • ATP-Administrators – ATP Admins, change settings and manage security roles

Depending on your organization you might need more defined roles list.

Here is the permission list and sub items is what will be granted more specific to the role.

  • View Data
    • View Data
  • Alerts investigation
    • Manage alerts
    • Initiate automated investigations
    • Run scans
    • Collect investigation packages
    • Manage machine tags
  • Active remediation actions
    • Take responsive actions
    • Approve or dismiss pending remediation actions
  • Manage security settings
    • Configure alert suppression settings
    • Manage allowed/blocked lists for automation
    • Manage folder exclusions for automated (applies globally)
    • Onboard and offboard machines
    • Manage email notifications

Working with Machine Groups

To be able to separate duties even further and configure different automatic remediation rules for different Machines we have the Machine Groups features.

Machine Groups is a way to group onaboarded Machines based on Name, Domain, Machine Tag and Operating System.

machinegroup

When using the “Show preview” at the bottom of the configuration page, you can see which onboarded machines will added to the Group.

You can select automation level

  • Semi – Require approval for any remediation
  • Semi – Require approval for non-temp folders remediation
  • Semi – Require approval for core folders remediation
  • Full – Remediate threats automatically

And you can assign a Azure AD userg group with roles to the machine group

mg_usergroup

The Groups, depending on how you defined group membership rules, will be populated automatically.

change_preview

more information about Machine Groups can be found here:
https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-atp/machine-groups-windows-defender-advanced-threat-protection

more information about RBAC in WD ATP can be found here:
https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-atp/assign-portal-access-windows-defender-advanced-threat-protection

Happy Hunting!

/Sec-Labs R&D

 

 

 

Threat Hunting with Windows Defender ATP

A while ago Microsoft released the Threat Hunting capatibilities in WD ATP.

This is a great feature since you’re able to query a lot of things across your devices.

Example scenario:

Let’s say you receive IoC’s for an ongoing attack or investigate threat actors with known files or IP’s you can Query these IoC’s on both on-prem devices and devices which only exists on the internet and never in the office.

That’s one of the benefits of using cloud security services.

As we wrote in the last post it’s now possible to onboard older operating systems like Windows 7 and Windows 8.1. There is also possible to onboard Linux systems and Macs

linux_mac_atp

Threat Hunting

hunting_atp

The hunting capatibilities in WD ATP involves running queries and you’re able to query almost everything which can happen in the Operating System.

If you’re familiar with Sysinternals Sysmon your will recognize the a lot of the data which you can query.

 

AlertEvents
AlertId, EventTime, MachineId, ComputerName, Severity, Category, Title, ActionType, FileName, SHA1, RemoteUrl, RemoteIP, ReportId

MachineInfo
EventTime, MachineId, ComputerName, ClientVersion, PublicIP, OSArchitecture, OSPlatform, OSBuild, IsAzureADJoined, LoggedOnUsers, MachineGroup, ReportId,

ProcessCreationEvents
EventTime, MachineId, ComputerName, ActionType, FileName, FolderPath, SHA1, SHA256, MD5, ProcessId, ProcessCommandLine, ProcessIntegrityLevel, ProcessTokenElevation, ProcessCreationTime, AccountDomain, AccountName, AccountSid, InitiatingProcessAccountDomain, InitiatingProcessAccountName, InitiatingProcessAccountSid, InitiatingProcessIntegrityLevel, InitiatingProcessTokenElevation, InitiatingProcessSHA1, InitiatingProcessSHA256, InitiatingProcessMD5, InitiatingProcessFileName, InitiatingProcessId, InitiatingProcessCommandLine, InitiatingProcessCreationTime, InitiatingProcessFolderPath, InitiatingProcessParentId, InitiatingProcessParentFileName, InitiatingProcessParentCreationTime, ReportId

NetworkCommunicationEvents
EventTime, MachineId, ComputerName, ActionType, RemoteIP, RemotePort, RemoteUrl, LocalIP, LocalPort, LocalIPType, RemoteIPType, InitiatingProcessSHA1, InitiatingProcessMD5, InitiatingProcessFileName, InitiatingProcessId, InitiatingProcessCommandLine, InitiatingProcessCreationTime, InitiatingProcessFolderPath, InitiatingProcessParentFileName, InitiatingProcessParentId, InitiatingProcessParentCreationTime, InitiatingProcessAccountDomain, InitiatingProcessAccountName, InitiatingProcessAccountSid, InitiatingProcessIntegrityLevel, InitiatingProcessTokenElevation, ReportId

FileCreationEvents
EventTime, MachineId, ComputerName, ActionType, FileName, FolderPath, SHA1, SHA256, MD5, FileOriginUrl, FileOriginReferrerUrl, FileOriginIP, InitiatingProcessAccountDomain, InitiatingProcessAccountName, InitiatingProcessAccountSid, InitiatingProcessMD5, InitiatingProcessSHA1, InitiatingProcessFolderPath, InitiatingProcessFileName, InitiatingProcessId, InitiatingProcessCommandLine, InitiatingProcessCreationTime, InitiatingProcessIntegrityLevel, InitiatingProcessTokenElevation, InitiatingProcessParentId, InitiatingProcessParentFileName, InitiatingProcessParentCreationTime, ReportId

RegistryEvents
EventTime, MachineId, ComputerName, ActionType, RegistryKey, RegistryValueType, RegistryValueName, RegistryValueData, PreviousRegistryValueName, PreviousRegistryValueData, InitiatingProcessAccountDomain, InitiatingProcessAccountName, InitiatingProcessAccountSid, InitiatingProcessSHA1, InitiatingProcessMD5, InitiatingProcessFileName, InitiatingProcessId, InitiatingProcessCommandLine, InitiatingProcessCreationTime, InitiatingProcessFolderPath, InitiatingProcessParentId, InitiatingProcessParentFileName, InitiatingProcessParentCreationTime, InitiatingProcessIntegrityLevel, InitiatingProcessTokenElevation, ReportId

LogonEvents
EventTime, MachineId, ComputerName, ActionType, AccountDomain, AccountName, AccountSid, LogonType, ReportId

ImageLoadEvents
EventTime, MachineId, ComputerName, ActionType, FileName, FolderPath, SHA1, MD5, InitiatingProcessAccountDomain, InitiatingProcessAccountName, InitiatingProcessAccountSid, InitiatingProcessIntegrityLevel, InitiatingProcessTokenElevation, InitiatingProcessSHA1, InitiatingProcessMD5, InitiatingProcessFileName, InitiatingProcessId, InitiatingProcessCommandLine, InitiatingProcessCreationTime, InitiatingProcessFolderPath, InitiatingProcessParentId, InitiatingProcessParentFileName, InitiatingProcessParentCreationTime, ReportId

MiscEvents
EventTime, MachineId, ComputerName, ActionType, FileName, FolderPath, SHA1, MD5, AccountDomain, AccountName, AccountSid, RemoteUrl, RemoteComputerName, ProcessCreationTime, ProcessTokenElevation, LogonId, RegistryKey, RegistryValueName, RegistryValueData, RemoteIP, RemotePort, LocalIP, LocalPort, FileOriginUrl, FileOriginIP, AdditionalFields, InitiatingProcessSHA1, InitiatingProcessSHA256, InitiatingProcessFileName, InitiatingProcessFolderPath, InitiatingProcessId, InitiatingProcessCommandLine, InitiatingProcessCreationTime, InitiatingProcessParentId, InitiatingProcessParentFileName, InitiatingProcessParentCreationTime, InitiatingProcessMD5, InitiatingProcessAccountDomain, InitiatingProcessAccountName, InitiatingProcessAccountSid, InitiatingProcessLogonId, ReportId

The query language is very similar to Splunk and adoption to these queries should be straight forward

ProcessCreationEvents
| where EventTime > ago(30d)
| where FileName in~ ("powershell.exe", "powershell_ise.exe")
| where ProcessCommandLine has "Net.WebClient"
or ProcessCommandLine has "DownloadFile"
or ProcessCommandLine has "Invoke-WebRequest"
or ProcessCommandLine has "Invoke-Shellcode"
or ProcessCommandLine has "Invoke-Mimikatz"
or ProcessCommandLine has "http:"
| project EventTime, ComputerName, InitiatingProcessFileName, FileName, ProcessCommandLine
| top 100 by EventTime

Use “Project” to select which columns you want in the output and you can export the result to a spreadsheet.

output

In the above example we ran a query to find malicious powershell commands being executed.

You can also, for example, query all powershell executions from Office applications

ProcessCreationEvents
| where EventTime > ago(14d)
| where ProcessCommandLine has "powershell"
| where InitiatingProcessFileName in~ ("winword.exe", "excel.exe", "powerpoint.exe")

You can also use the quick search to finns URL’s, File hashes, IPs

quick search

The output will show you hits in organization and prevalance world wide which will give you more indication of a threat.

When we search for a filehash we can also submit the file for deeper analysis.

Microsoft has a Github repositories to help you with example queries

https://github.com/Microsoft/WindowsDefenderATP-Hunting-Queries

Sharing Queries

When working in a team it’s a good idea to share your queries to let your colleagues to use your hunting queries.

sharing_queries

The language reference is available here
https://docs.loganalytics.io/docs/Language-Reference/

 

Happy Hunting!

 

/Sec-Labs R&D

Onboarding older Windows Versions to WD ATP

Today Microsoft announced  that it’s now possible to onboard older legacy operatingsystems to ATP (Advanced Threat Protection) when the public preview that is available.

  • Windows 7 SP1 Enterprise
  • Windows 7 SP1 Pro
  • Windows 8.1 Pro
  • Windows 8.1 Enterprise

Even though we Always recommend using the latest versions there might be scenarios where you need the advanced detection and response capatibilities and  of ATP and it’s not possible to upgrade the machines.

The difference between Windows 10 and the older versions is that is not built-in and you have to install an Microsoft Monitoring agent which will connect to your workspace and report the sensor data.

Installing the agent

64-bit agent is available here:
https://go.microsoft.com/fwlink/?LinkId=828603

32-bit agent is available here:
https://go.microsoft.com/fwlink/?LinkId=828604

When you have downloaded the setup file you extract it using “/c” parameter

Install command
setup.exe /qn NOAPM=1 ADD_OPINSIGHTS_WORKSPACE=1 OPINSIGHTS_WORKSPACE_AZURE_CLOUD_TYPE=0 OPINSIGHTS_WORKSPACE_ID= OPINSIGHTS_WORKSPACE_KEY= AcceptEndUserLicenseAgreement=1

The workspace ID and Key is available in your ATP Portal https://securitycenter.windows.com

 

The clients will connect to the service using HTTPS and can be a direct connection or through a proxy or OMS gateway.

Agent Resource Ports
*.oms.opinsights.azure.com 443
*.blob.core.windows.net 443
*.azure-automation.net 443
*.ods.opinsights.azure.com 443
winatp-gw-cus.microsoft.com 443
winatp-gw-eus.microsoft.com 443
winatp-gw-neu.microsoft.com 443
winatp-gw-weu.microsoft.com 443
winatp-gw-uks.microsoft.com 443
winatp-gw-ukw.microsoft.com 443

 

When your clients are configured you should start seeing them in the ATP console

As you may have noticed there’s a link to Azure ATP alerts where you can dig further on advanced attacks in your environment.

On the following link you can find more information about onboarding older Windows Versions to Defender ATP
https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-atp/onboard-downlevel-windows-defender-advanced-threat-protection

Happy Hunting

 

/SEC-LABS R&D

 

 

Controlling Auto Forward Rules of Emails to avoid data leakage

Email Forwarding is a challenge when it comes to modern attacks, and it was recently used as one of the tools in a crimecase in Sweden. Basically the attackers forwarded all emails from the victims to themselves to be able to track the victims very easily and to gain insights and data for social engineering attacks. Multifactor auth via e-mail or password reset links where obtained and could easly be used to manipulate and gain access.

Email forwarding can be created in Outlook or the the web application (OWA) by the users or an attacker with access to a user account.

The solution for this is very easy.
You can block email forwarding and redirects in general and allow it where it’s necessary (if you do have that scenario).

Block autoforward domain wide for Office 365 using PowerShell:

Set-RemoteDomain Default -AutoForwardEnabled $false

It is possible to configure this on a per domain basis.
For instance, if you need to allow forward to specific domain.

To view all forwarding rules today both on-prem and cloud you can use the following script.
The only difference is the connection part.

View the Rules

Function Get-AutoForwardRules
{
foreach ($a in (Get-Mailbox -ResultSize Unlimited |select PrimarySMTPAddress))
{
Get-InboxRule -Mailbox $a.PrimarySMTPAddress |
?{($_.ForwardTo -ne $null) -or ($_.ForwardAsAttachmentTo -ne $null) -or ($_.DeleteMessage -eq $true) -or ($_.RedirectTo -ne $null)} |
select Name,Identity,ForwardTo,ForwardAsAttachmentTo, RedirectTo, DeleteMessage
}
}

#Example

Get-AutoForwardRules

To get the PowerShell module for office 365 which supports MFA.

Download the PowerShell Module (available in the 365 admin portal)

Connect using: Connect-EXOPSSession -UserPrincipalName user@example.com

Security Features in Office 365

Depending on your Office 365 Subscription you might get a warning email when someone tries to define a forwarding rule

 

This is an example for Exchange Online

$Mailboxes = Get-Mailbox -ResultSize "Unlimited"
$Count = 1
ForEach ($Mailbox in $Mailboxes)
{
Write-Progress -Activity "Checking inboxrules..." -Status "User $($Mailbox.PrimarySmtpAddress) ($count/$($Mailboxes.count))" -PercentComplete ($Count / $Mailboxes.count*100)
$MailboxWithRule = Get-InboxRule -Mailbox $Mailbox.Alias | Where-Object {($_.RedirectTo -ne $null) -and ($_.ForwardTo -ne $null) -and ($_.ForwardAsAttachmentTo -ne $null)}
if ($MailboxWithRule -ne $Null) {
Write-Host "Mailbox $($Mailbox.PrimarySmtpAddress) has these rulez:" $MailboxWithRule |
fl Name, Identity, RedirectTo, ForwardTo, ForwardAsAttachmentTo
}
$count++
}

Windows Event Forward and Custom Logs

First of all, this post is more about configuring custom event channels than configure WEF.

 

There is more than one way to work with event logs and the most important is to start working with event logs.

Some of the benefits is one place to find the logs for multiple systems and if someone clears, for example, the security log it’s important that you can find the log events before that happened and have alerts triggered on the clearing event.

Using the WEC (Windows Event collector) service is a free option and one of the most frequent used way to gather logs from Windows Clients.

So where do these events end up?

 

Windows Event Forward uses WinRM to forward the logs from the source to the server which runs the Windows Event Collector Service.

There are 2 different options where one option is to let the WEC server to connect to the client and poll the events and the other options is to let the client to push the events to the WEC server.

This is configured in the subscription part in Event Viewer

Besides the Subscription types you also must configure the Destination log (Default Forwarded Events) and select which events will be forwarded.

There are a few git projects for events in xml(xpath) format which you can use to automatically update the events.

 

There are more than security people which wants to be able to forward events.

IT operations and endpoint management teams would benefit from WEF by being able to collect errors and other events that might help with troubleshooting.

If you are about to publish new applocker rules you could set them in Audit mode and collect and analyze information where the rules would impact on a user.

Since we have multiple user cases for WEF you may want to separate the logs into different logs.

Security people maybe don’t want the support-.log to fill their selections of security related events.

You may want to forward the security logs into a SIEM solution like Splunk or QRADAR and don’t want to waist SIEM data license with non-security events.

 

To achieve this, we create a custom log.

Using Ecmangen.exe (provided in one of the Windows 10 SDKs, beware of that this tool is removed from the latest releases)

Save the output to c:\temp\WEF and run the following commands

“C:\Program Files (x86)\Windows Kits\10\bin\x64\mc.exe” C:\temp\wef\WEFEvents.man

“C:\Program Files (x86)\Windows Kits\10\bin\x64\mc.exe” -css WEFEvents.DummyEvent C:\temp\wef\WEFEvents.man

 “C:\Program Files (x86)\Windows Kits\10\bin\x64\rc.exe” C:\temp\wef\WEFEvents.rc

 “C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe” /win32res:C:\temp\wef\WEFEvents.res /unsafe /target:library /out:C:\temp\wef\WEFEvents.dll C:\temp\wef\WEFEvents.cs

Copy the WEFEvents.dll and WEFEvents.man to c:\windows\system32 and register with:

wevtutil im c:\Windows\system32\WEFEvents.man

 

You will now be able to use these logs for WEF.

You can have, for example, one for servers one for clients. One with a SPLUNK forwarder and one inserted to a database with a nice custom interface which suites your need depending of what you have.

 

 

 

 

 

 

 

 

KrackAttack – Vulnerability in WPA2 – Disclosed

A security researcher Mathy Van Hoef will disclose a vulnerability in WPA2 within a few hours.

The vulnerability leaves Wi-Fi traffic open to eavesdropping and it will be possible to inject malicious content and much more.

CVE’s
CVE-2017-13077
CVE-2017-13078
CVE-2017-13079
CVE-2017-13080
CVE-2017-13081
CVE-2017-13082

 

Important URLs
https://www.krackattacks.com/
https://github.com/valentijnscholten/krackattacks/

 

Van Hoef on Twitter
https://twitter.com/vanhoefm

::Updates::

From Krackattacks.com

Our main attack is against the 4-way handshake of the WPA2 protocol. This handshake is executed when a client wants to join a protected Wi-Fi network, and is used to confirm that both the client and access point possess the correct credentials (e.g. the pre-shared password of the network). At the same time, the 4-way handshake also negotiates a fresh encryption key that will be used to encrypt all subsequent traffic. Currently, all modern protected Wi-Fi networks use the 4-way handshake. This implies all these networks are affected by (some variant of) our attack. For instance, the attack works against personal and enterprise Wi-Fi networks, against the older WPA and the latest WPA2 standard, and even against networks that only use AES. All our attacks against WPA2 use a novel technique called a key reinstallation attack (KRACK):

  • Basically all Wireless networks are vulnerable and the vendors are working to get the patches out.
  • Microsoft was mitigating this on the client side in the October patch release cycle
  • If you won’t get an update to your router your really only option is to get a new one (if it’s out of support)
  • Recommendations are to apply patches as soon as they’re available.

 

 

This post will be updated