Controlled Folder Access is part of Windows Defender Security Centre that works with Windows Defender Anti-Virus to prevent “suspicious” executable files, DLLs, and scripts from writing to (or encrypting) files within certain folders.

What folders are protected?

While additional folders can be added, the following locations will always be monitored when Controlled Folder Access is enabled:

• User: Documents, Pictures, Videos, Music, Desktop, Favorites
• Public: Documents, Pictures, Videos, Music, Desktop

How does Windows determine what `suspicious’ code is?

It’s what Windows Defender Anti-Virus identifies. As such Controlled Folder Access relies on Windows Defender Anti-Virus to be running.

What about application false positives?

It may be the case that legitimate applications are incorrectly flagged by Windows Defender Anti-Virus as being `suspicious’ preventing or hindering legitimate use. Such applications can be white-listed.

To facilitate this, Controlled Folder Access supports an `audit’ mode, where an event is generated when the application would normally be prevented from writing to a protected folder. Those events can be reviewed to identify legitimate applications that can be added to the white-list.

Is Controlled Folder Access enabled by default? How do I configure it?

Controlled Folder Access is not enabled by default and can be configured via:

• The User Interface
• Group Policy (a Group Policy would need to be configured on a system that contains the correct administrative templates for the options to be available for selection): Computer Configuration > Administrative Templates > Windows Components > Windows Defender Anti-Virus > Windows Defender Exploit Guard > Controlled Folder Access
• Manual Registry modification (i.e. via a script)
• PowerShell cmdlets:

Set-MpPreference -EnableControlledFolderAccess [Enable | Disable | Audit]
Add-MpPreference -ControlledFolderAccessProtectedFolders c:\path\to\protect,c:\other\path
Remove-MpPreference -ControlledFolderAccessProtectedFolders c:\path\to\no\longer\protect

Note: Set-MpPreference can also be used to specify folder items but will clear the list first, whereas Add-MpPreference adds to the list.

What Registry keys are used by Controlled Folder Access?

Is Controlled Folder Access enabled?

Registry path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Exploit Guard\Controlled Folder Access
Registry Key: GuardMyFolders
Key Type: REG_DWORD
Key Value: 0

Protected Folders

Registry path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Exploit Guard\Controlled Folder Access\ProtectedFolders
Registry Key: audit
Key Type: REG_DWORD
Key Value: 0

To specify protected folders:

Registry path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Exploit Guard\Controlled Folder Access\ProtectedFolders
Registry Key: Full path to protect, i.e. c:\test
Key Type: REG_DWORD
Key Value: 0</code>

What can be protected? Any limitations?

Network shares and mapped drives can be protected, but Controlled Folder Access does not support the use of:

• Environment Variables
• Wildcards
• The Windows drive (typically C:\)

Seriously, don’t protect the entire Windows drive as Windows will be unable to function correctly and strange behaviour will result.

What happens when write access is blocked?

A notification is displayed that provides the path of the executable that was blocked, and the path of protected folder that the write attempt was for. This information is also recorded in the event log, using the following event values:

• Event ID: 5007: Event when settings are changed
• Event ID: 1124: Audited Controlled folder access event
• Event ID: 1123: Blocked Controlled folder access event

The following image shows the notification of a write action being blocked:

Can the blocked write notification message be customised?

Yes, at least for Enterprise environments. Providing details of who to contact (service desk, IT Security, etc.) can be included in the notification message via the following Group Policy settings:

Computer Configuration > Policies > Adminstrative Templates > Windows Components > Windows Defender Security Center > Enterprise Customization

•  Set “Configure customized contact information” to “Enabled”
•  Set “Configure customized notifications” to “Enabled”
•  Set “Specify contact compant name” to “Enabled” and add the company details
•  Enable and set at least one of the following:
  • “Specify contact email address or EmailID”
  • “Specify contact phone number or Skype ID”
  • “Specify contact web site”

Does Controlled Folder Access work with third-party Anti-Virus applications?

No, or at least not in the tests performed when writing this post. Controlled Folder Access requires the use of Windows Defender Anti-Virus to be active.

Most third-party Anti-Virus solutions replace existing products, and attempting to run multiple Anti-Virus solutions at the same time can significantly hinder system performance, or even lead to each one preventing the other from being able to scan files or removable drives which could lower protections. One Anti-Virus program might flag others as being infected (i.e. triggering on the detection patterns) or malicious, and quarantine key files – potentially breaking that product.

How can I tell Controlled Folder Access and Notifications are configured and working?

Microsoft have produced an ExploitGuard CFA File Creator tool to trigger Controlled Folder Access actions, which causes notifications to be displayed.

Details on the ExploitGuard CFA Demo Tool, and a link to download it, can be found on Microsoft’s web site.

Conclusion

For home users or business that do not have a corporate Anti-Virus solution, Windows Defender Anti-Virus and Controlled Folder Access will be better than nothing.
However, larger businesses typically have existing enterprise-wide Anti-Virus solutions in which significant time and effort (and money) has been invested. It would be difficult to convince the IT Security teams of such companies to throw out that investment, so I don’t expect Controlled Folder Access to be used much in large businesses.

Controlled Folder Access is a new feature, and it may be that Microsoft modify it to work with third-party Anti-Virus products in the future.

The post Windows 10’s “Controlled Folder Access” feature appeared first on Portcullis Labs.

In some cases, an attacker is able to move from having local Administrator access on a workstation to gaining full Domain Admin rights on the Domain in under an hour.

Since Active Directory typically controls access to highly sensitive information, it is important to try and prevent lateral attacks from working. Being able to spot these attacks would also be good.

Limit workstation to workstation communications

It is highly unusual for network users to need to directly communicate with other users’ workstations.

Configure each workstation to use a local firewall to block incoming Windows network traffic (139/TCP, 445/TCP and 137/UDP) from any workstation subnet.

If using a firewall that supports different network zones (such as the Windows Firewall), ensure the appropriate zone profiles are configured, or simply configure all profiles. If your organisation uses VoIP telephones, prevent those subnets from connecting as well to protect against either a malicious internal employee, or in case the attacker is able to convince a user to try changing network connections.

Prevent local users from logging in over the network

If an attacker finds that they cannot directly connect to other workstations to hunt for privileged cached credentials, they may attempt to compromise a server and try to login to workstations from there. To protect against this, configure the User Rights policy ‘Deny access to this computer from the network’ by adding local user accounts.

Use a local Administrator password management tool

Tools, such as Microsoft LAPS, exist that set unique passwords for the local administrator account. By using such tools, when a password exceeds its expiration date the password will be changed automatically when the Group Policy is refreshed. Avoid writing a custom password management system, as it is very difficult to implement such things without error; if an attacker is able to determine a pattern to setting the password, then that defence is gone.

Configure systems via Group Policy

To reduce the risk of credentials being captured, avoid logging into systems where not necessary. Use Group Policies to configure workstations and servers instead of directly logging into them, where possible. Systems may be configured to cache credentials when users login, and this information can be obtained by an attacker and then cracked offline to reveal the plain text password for that user account. If an attacker already has a foothold on a system and a Domain Administrator logs in, the attacker may be able to impersonate the Domain Administrator in order to utilise their privileges within the network Domain.

Use dedicated administrative accounts and workstations

An attacker can only extract privileged password data if it is present on the system. Ensure administrative users have user accounts that are separate from their day-to-day user accounts and configure them so that they cannot login to normal workstations or servers; they should only be used to login to Active Directory servers to manage them, and configure Group Policies to manage other systems.

Dedicated management workstations should not be able to access the Internet or email.

Disable ‘WDigest’

Windows supports several Security Support Providers (SSPs), used to handle authentication requests (including Single Sign On). Until recently (Window 8.1 and Server 2012 R2 or higher), Windows used by default an SSP called ‘WDigest’ – which stored user credentials in plain text in memory, allowing a process with local Administrator privileges to extract the passwords of all logged-in users.

To help address this issue, Microsoft created a new Registry key for ‘WDigest’ to disable storing plain text passwords, which can be applied to Windows, prior to 8.1 and Server 2012 R2 by installing KB2871997 and configuring the following Registry setting:

Registry Path: HKLM\System\CurrentControlSet\Control\SecurityProviders\Wdigest
Key Name: UseLogonCredential
Key Type: REG_DWORD
Key Value: 0

Alternatively, KB2871997 can be configured via Group Policy by installing the PtH.admx/adml files provided with the Microsoft Security Compliance Manager (SCM) via:

Local Policies > Administrative Templates > SCM: Pass the Hash Mitigations > Wdigest Authentication

Apply enhanced credentials protection updates

In addition to the protections added by KB2871997, Microsoft have released an updated that further protects against Pass the Hash (PtH) attacks for Windows 7, Windows 8, Server 2008 R2 and Server 2012.

KB3126593 (MS16-014)

This update adds support for the TokenLeakDetectDelaySecs Registry setting which can be used to force credentials to be cleared after a user logs off. To set clearing credentials 30 seconds after user logout (the default behaviour in Windows 8.1 and Windows 10), configure the following Registry setting:

Registry Path: HKLM\System\CurrentControlSet\Control\Lsa
Key Name: TokenLeakDetectDelaySecs
Key Type: REG_DWORD
Key Value: 30

Upgrade Windows servers and workstations

With each new version of Windows, Microsoft adds additional security features, including protections for the LSASS service to protect against credential stealing and adding additional logging options. Upgrade servers to Server 2016 and upgrade workstations to Windows 10 and configure them to make use of these new features.

Enable event monitoring and investigate alerts

A centralised logging and monitoring solution provides an opportunity for recording actions and events that take place on systems, and prevents a successful attacker from clearing the event log to hide their actions.

Configure all Windows systems to log events to a centralised system and monitor for account login attempts (both successful and unsuccessful).
Any events that reference local accounts (or Domain Administrator/privileged accounts) and not Domain accounts should be investigated as a matter of priority.

The following Windows event codes are generated by Windows 2008 and later:

• Event ID: 4624: Account login successful
• Event ID: 4625: Account login failed

The corresponding events for Windows 2003 and earlier:

• Event ID: 528: Account login successful
• Event ID: 540: Network account login successful
• Event ID: 529: Login failure – Unknown user or bad password

Other potentially interesting event code are:

• Event ID: 4625: An account failed to login (Windows 2008 and later)
• Event ID: 531: Login failure – Account currently disabled (Windows 2003 and earlier)

Conclusion

A number of options have been presented to hinder Lateral Movement attacks, and some readers might be wondering which option to implement. The answer is “all of them, where possible”. Security is a “defence in depth” game, and every obstacle that an attacker has to work around is worth implementing.

In addition to hindering lateral movement, monitoring for attacks or suspicious behaviour and investigating alerts will help identify more sophisticated attacks, as well as indicating that suspicious activities are occurring.

A Red Team Assessment can be undertaken to determine the effectiveness of the security controls in place during an attack against your network. Whilst the assessment is taking place it also provides an opportunity to determine whether the internal monitoring and response capabilities intended to detect and alert when a potential attack is occurring within your network are effective. Following completion of the assessment you will have a clear view of any additional measures that should be implemented to improve both defence and monitoring capabilities within your network.

The post Hindering Lateral Movement appeared first on Portcullis Labs.

Even with password complexity requirements and custom filters there is no built-in way to stop users choosing poor passwords. It is scary how may user accounts are identified with the password Password1 for example. We need a method of detecting password guessing attacks, preferably before someone takes control of the Domain.

By following the instructions below you can get hourly (can be trivially customised) notifications of such horizontal password guessing attacks.

Note: The following method has been developed using Windows 2012.

Configuring the Domain Controller

First we need to configure the Active Directory Domain Controller to log failed logon attempts:

• From the Server Manager tool click Tools and select Group Policy Management, as shown in the screenshot below:
  

  

  Figure 1. Opening the Group Policy Management tool

• Expand the nodes in the left hand pane so you can see the policy Default Domain Controllers Policy for Domain Controllers within the Domain. Right-click it and select Edit, as shown below:
  

  

  Figure 2. Edit the ‘Default Domain Controllers Policy’

• In the Group Policy Management Editor expand “Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies” and then click “Audit Policy”
• Right-click “Audit account logon events” and select “Properties”, as shown below:
  

  

  Figure 3. Editing the policy setting for ‘Audit account logon events’

• Ensure that both “Define these policy settings” and “Failure” are enabled then click “OK”. The following screenshot shows both “Success” and “Failure” are selected:
  

  

  Figure 4. Enabling failure events for the ‘Audit account logon events’ properties

• When you click “OK” the updated policy settings will be visible. Next we force the server to recognise the updated policy settings by running the command gpupdate /force by pressing Windows key + r, as shown below:
  

  

  Figure 5. Forcing the updated policy to take effect

• To test that the policy has taken affect we make a failed logon attempts (from another system). Note the IP address of the machine used in the screenshot below:
  

  

  Figure 6. Triggering a failed logon event with a “net use” command

• By viewing the Event Viewer on the Domain Controller we can see in the following screenshot that failed logon attempts now generate Audit Failure events (in this case EventID 4771) and that the IPAddress shown matches the host from which the logon attempt was made:
  

  

  Figure 7. Confirming a failed logon generates an event

Ok. That’s the Domain Controller logging configured. Now we need a method of parsing the event log to detect failed logon attempts…

Parsing the event logs

PowerShell has a cmdlet called get-WinEvent that allows us to filter out all events with a specific EventId within a given timespan.

$events = get-winevent -EA silentlycontinue -filterhashtable @{LogName='Security';id=4771; `
starttime=(Get-Date).AddHours(-1);endtime=(Get-Date) }

Note: The backtick at the end of the first line is PowerShell’s multiline indicator and is required.

By running the above PowerShell command we get all events from the Security log with an ID value of 4771 from the past hour. If we wanted to change the timespan we could replace AddHours(-1) with AddMinutes(-30) for the last 30 minutes, or AddDays(-1) for the last 24 hours. Those events will be accessed via the $events variable.

If we want to check additional EventIds we simply add extra calls to get-WinEvent like so:

$events += get-winevent -EA silentlycontinue -filterhashtable @{LogName='Security';id=1234; `
starttime=(Get-Date).AddHours(-1);endtime=(Get-Date) }

Note the use of += to append the extra events.

We specify the parameter -EA silentlycontinue to avoid error messages if there are no events returned.

Of course some of those events might well be innocent users who mis-typed their password. Someone performing a horizontal password guessing attack against Active Directory users will be running that attack from a single host on the network (E.g. an IP address). Or several hosts might be being used, each testing a sub-set of user accounts and/or passwords. We want to identify any IP address that failed to logon more than a specified number of times within our timespan.

In order to obtain information from the event entry message we need to convert the event to XML so that we can parse it. We will make a note of each IP address that generated the failed logon event by looping through each event (remember we filtered only those events we are interested in) and increment a counter specific for each unique IP address we encounter.

Once we have counted each failed logon attempt originating from all the source IPs referenced in the log event we simply report on any IP where the counted value exceeds our specified threshold value by sending an email alert.

The complete script

The following PowerShell script implements the complete process:

# Script: detect-horizontal-user-brute-froce-attack.ps1
# Author: Richard Hatch, 2014 - RGH@Portcullis-Security.com

# Number of failed logons within the defined time span
# Total events -gt this value will trick the response action
$threshold = 4

#The email server to use when sending alerts
$EmailServer = "127.0.0.1"

#The email address to send from
$mail_domainSrc = "alerts@mydomain.com"

#clean-up any data from a previous run
Remove-Variable events

#get the events from the local system. RUN ON DC (or central log server)
$events = get-winevent -EA silentlycontinue -filterhashtable @{LogName='Security';id=4771; `
starttime=(Get-Date).AddHours(-1);endtime=(Get-Date)  }

# Copy the following line for each required ID value (and update the ID param!)

# $events += get-winevent -EA silentlycontinue -filterhashtable @{LogName='Security'; `
#id=4771;starttime=(Get-Date).AddHours(-1);endtime=(Get-Date) }

#declare our data hash
$scares = @{}

#process each event
ForEach ($evt in $events)
{
	#convert the event data to xml so we can get items
	$evtxml =
1
$evt.ToXML() $curTargetUserName = "" $curServiceName = "" $curIPAddress = "" $curEventTime = $evtxml.Event.System.TimeCreated.SystemTime #need to loop through each 'data' properties for ($i=0; $i -lt $evtxml.Event.EventData.childNodes.count; $i++) { if ($evtxml.Event.EventData.Data[$i].name -eq "IpAddress") { $curIPAddress = $evtxml.Event.EventData.Data[$i].'#text' } } #end for ($i=0; $i -lt $evtxml.Event.EventData.count; $i++) #If we have never seen this IP failing to logon create a new entry # #Without this check the code attempts to repeatedly create the #same hash entry, causing an error. if (!($scares.ContainsKey($curIPAddress))) { $scares.Add($curIPAddress, 0); #init to 0 } #count this failed logon attempt $scares["$curIPAddress"] += 1 } #end ForEach ($evt in $events) $scares.GetEnumerator() | % { if ( $($_.value) -gt $threshold ) { $attackerIP = $($_.key) $attackerFailedTimes = $($_.value) Write-Host "[!] IP: $($_.key) failed to login $($_.value) times in the last hour" #$mail_domainSrc = [string]([adsi]'').distinguishedName $mail_subject = "ALERT ${mail_domainSrc}: Host $($_.key) may be attacking ActiveDirectory user accounts" $mail_body = " ALERT! A possible brute-force password guessing attack detected within the last hour from the host with the IP $attackerIP. Failed logon count was $attackerFailedTimes $mail_domainSrc " Send-MailMessage -To ITSecurity@mydomain.com -From $mail_domainSrc ` -Subject $mail_subject -Body $mail_body -SmtpServer $EmailServer ` -Priority High } #end if ( $($_.value) -gt $threshold ) } #end $scares.GetEnumerator() | % {

The PowerShell script will diplay information to the PowerShell Console (if visible) and send an email, in this case to ITSecurity@mydomain.com from alerts@mydomain.com, using the Send-MailMessage cmdlet.

We can test the script with the following command:

c:\> powershell -File Detect-horizontal-user-brute-force-attack.ps1
[!] IP: ::ffff:10.1.2.3 failed to login 6 times in the last hour

Note: You may need to first enable external scripting within PowerShell:

PS> Set-ExecutionPolicy unrestricted

For a more secure configuration of PowerShell you can specify Signed instead of Unrestricted. More details on this can be found on Microsoft’s web site.

Running the script automatically

Now we need a method of running the script on the Domain Controller each hour. We can use the task scheduler (as an Administrator):

c:\> schtasks /create /tn AD_PwdGuess_Alerter /tr "powershell -NoLogo -WindowStyle hidden -File detect-horizontal-user-brute-force-attack.ps1 /sc hour /mo 1 /ru "NT AUTHORITY\LOCALSERVICE"

Once we create the scheduled task we need to start it:

c:\> schtasks /run /tn AD_PwdGuess_Alerter

Note: For extra security you should create a service account with the minimum privileges required to access the event log and send Emails, and specify that account in the /ru parameter, in place of NT AUTHORITY\LOCALSERVICE.

And that’s it. You may want to tweak the time period settings and the $mail_domainSr value, and the email settings will need to be updated.

This solution can also be used to cover password attacks on local user accounts through the use of Centralised Event Logging. Also see the National Security Agency’s (NSA) detailed paper on configuring centralised event logging.

detect-horizontal-user-brute-force-attack.zip
February 25, 2014

1.8 KiB
MD5 hash: 08629677479f0cfd01b9fe960b632949
Details

Date:

February 25, 2014

The post Detecting windows horizontal password guessing attacks in near real-time appeared first on Portcullis Labs.

According to the vendor web site (http://www.livetecs.com/): “TimeLive Web timesheet suite is an integrated suite for time record, time tracking and time billing software.”

My local default password list did not have an entry for this software so my next search query was to look for default credentials. Sadly I didn’t find any, but I did find a reference (and a handy screen shot, shown below) that referred to the URI /home/systemsetting.aspx.

/home/systemsetting.aspx

A close look at the screenshot showed a database connection string so I thought I would check the server…

I was able to access the URI without any authentication and was presented with a page that looked very similar to the screen shot. In fact the only difference I noticed was the database connection string. Time to fire up a database tool…

So those credentials worked – I really shouldn’t be able to access that information! There is a tick-box on the page to encrypt the connection string but the default is clearly to not have that enabled.

A closer look at the page showed me two text input boxes to specify (and confirm) the System Admin password. There was no box to provide the current System Admin password(!).

There were also some fields relating to the SMTP settings.

Without knowing anything about how the client used that service I decided it was probably not a good idea to play with the settings so I went to tell the client contact about the database connection string issue. The only way he was able to lockdown access to that page was by altering the filesystem Access Control Lists (ACLs) for the file systemsetting.aspx. The application had no method for restricting access. The contact also stated that the password change functionality would have worked.

After I had finished the pentest job and the report was completed I thought I would check the latest version of TimeLive to see if the database connection string issue was still present.

I downloaded a trial version and installed it into a Windows virtual machine. This version was several releases newer than the one I had seen so I wasn’t optimistic. However the same URI gave me the database connection string but wait…what’s this?

The TimeLive application bundles it’s own MS-SQL database environment and a default install uses the sa account. I connected to the database (reading the connection details from the web page) and confirmed that I could access xp_cmdshell. I (command)-promptly ran whoami and found that yes, I was SYSTEM on the host.

I remembered what my client contact had set about having to modify the underlying Operating System (OS) file ACL permissions to prevent access, so I had a look at the ACLs on several application files. Any local user logged into the host had full permissions on all files belonging to the application, with the exception of the actual database files (which are created by the database engine). Within one of those files I found the database connection string displayed in the web browser, so configuring the web server to block access to /home/systemsetting.aspx would not prevent local host users from being able to elevate their privileges.

I had a quick play with the options offered by systemsettings.aspx and was able to make changes without being logged in. These settings included an email address (presumably where system alerts are sent) and the authentication options for the application. Looks like it can hook into Active Directory (either Microsoft’s or OpenLDAP), so a bad guy could either specify a non-existent login server (to cause a Denial of Service condition), or presumably set up their own that replies to all logins as OK, while capturing those usernames and passwords for later use.

As an added bonus, the application defaults to HTTP and not HTTPS, meaning that any data transmitted over the network between clients and the server is not encrypted.

As I was browsing the application files I noticed the word upload. I though “that’s worth a quick look”

I thought I would look for horizontal privilege escalation so I created two different low-level user accounts to see if user1 could access files from user2. Not being familiar with the application I had to play around with the application before I found where a user could upload files.

After uploading a test file (there was no limitation on file types as the upload feature was for generic project resources) I searched for the file on the file system and checked the ACL settings. Thanks to inherited permissions, uploaded files had “Read and Execute” enabled.

I found that it was possible to upload a .aspx file (as a low-level user) that included VisualBasic code to run calc.exe. When I browsed to the uploaded file, it happily ran it, running under the NETWORK_SERVICE account (which is what the web server was configured to use for applications). It turns out that you don’t need to be logged into the application to access that page, so if a user uploads a maliciously crafted file (by being tricked by an attacker, via malware or by that user being malicious) an unauthenticated attacker simply needs to browse to that content to trigger the coded behaviour.

As a result of this, a security advisory was sent to the vendor, and the following CVEs assigned:

* CVE-2014-1217
* CVE-2014-2042

The moral of this story is that it is important to examine the properties of files installed by an application, as well as the configuration settings used by default. A quick Internet search for the application name and terms like default password or configuration might reveal some interesting results and so is also worth doing.

The post Investigating the TimeLive application appeared first on Portcullis Labs.

The name is derived from “Windows LAN Info”

The auto-find mode (-f parameter) uses the results from the command:

$ find | grep -i enum4linux

Dependencies

winlanfoe is a simple Perl script that uses one module from CPAN (which is typically installed by default).

Run ‘cpan’ as root then install the File::Basename module:

# cpan
cpan[1]#> install File::Basename

Example output 1: Usage information

$ winlanfoe.pl
winlanfoe.pl v0.4 (https://labs.portcullis.co.uk/application/winlanfoe/)
Copyright (C) 2012 Richard Hatch (rgh@portcullis-security.com)

Parses enum4linux output for Windows for hostname, workgroup/domain, domain-member, OS.

Usage:
 ./winlanfoe.pl enum4linux-10.0.0.1.out [ enum4linux-10.0.0.2.out ]
or
 ./winlanfoe.pl -f   # To search the current directory tree for enum4linux files

Example output 2: A single Windows 2008 R2 SP1 host

$ winlanfoe.pl w2008r2-enum4linux.out
winlanfoe.pl v0.4 (https://labs.portcullis.co.uk/application/winlanfoe/)
Copyright (C) 2012 Richard Hatch (rgh@portcullis-security.com)

Note: OS Version is taken from enum4linux. You might get more precise results with:
# msfcli auxiliary/scanner/smb/smb_version RHOSTS=1.2.3.4 e, or examining nessus output

Domain: CORP, Hostname: W2008R2DC, IP: 172.16.1.10, OS: Windows Server 2008 R2 Enterprise 7601 Service Pack 1, Domain Controller

Example output 3: The auto-find results mode

$ winlanfoe.pl -f
winlanfoe.pl v0.4 (https://labs.portcullis.co.uk/application/winlanfoe/)
Copyright (C) 2012 Richard Hatch (rgh@portcullis-security.com)

Note: OS Version is taken from enum4linux. You might get more precise results with:
# msfcli auxiliary/scanner/smb/smb_version RHOSTS=1.2.3.4 e, or examining nessus output

Domain: CORP,      Hostname: WIN7ALICE,    IP: 172.16.1.11,  OS: Windows 7 Ultimate 7600,
Domain: CORP,      Hostname: W2008R2DC,    IP: 172.16.1.10,  OS: Windows Server 2008 R2 Enterprise 7601 Service Pack 1, Domain Controller

Wrkgrp: WORKGROUP, Hostname: OFFICEMONKEY, IP: 172.16.1.102, OS: Windows 5.1 (XP),
Wrkgrp: WORKGROUP, Hostname: WIN2K3SP1,    IP: 172.16.1.101, OS: Windows Server 2003 3790 Service Pack 1,

winlanfoe-0.4.tgz
October 10, 2013
Version: 0.4

11.2 KiB
MD5 hash: 217be9b7cfa757aa4ad87113781387e3
Details

Date:

October 10, 2013

The post winlanfoe appeared first on Portcullis Labs.