Monday, September 15, 2014

IPV6 – Enable or Disable

Source -

Here is a great article from Microsoft PFE on IPV6.

What’s Microsoft Recommend Setting for IPv6?

The long standing recommendation has been to leave IPv6 and IPv4 enabled on post XP Windows clients and server. The point is covered in the “What are Microsoft’s recommendation about disabling IPv6” section of the IPV6 FAQ:

“It is unfortunate that some organizations disable IPv6 on their computers running Windows 7, Windows Vista, Windows Server 2008 R2, or Windows Server 2008, where it is installed and enabled by default. Many disable IPv6-based on the assumption that they are not running any applications or services that use it. Others might disable it because of a misperception that having both IPv4 and IPv6 enabled effectively doubles their DNS and Web traffic. This is not true.

From Microsoft's perspective, IPv6 is a mandatory part of the Windows operating system and it is enabled and included in standard Windows service and application testing during the operating system development process. Because Windows was designed specifically with IPv6 present, Microsoft does not perform any testing to determine the effects of disabling IPv6. If IPv6 is disabled on Windows 7, Windows Vista, Windows Server 2008 R2, or Windows Server 2008, or later versions, some components will not function. Moreover, applications that you might not think are using IPv6—such as Remote Assistance, HomeGroup, DirectAccess, and Windows Mail—could be.

Therefore, Microsoft recommends that you leave IPv6 enabled, even if you do not have an IPv6-enabled network, either native or tunneled. By leaving IPv6 enabled, you do not disable IPv6-only applications and services (for example, HomeGroup in Windows 7 and DirectAccess in Windows 7 and Windows Server 2008 R2 are IPv6-only) and your hosts can take advantage of IPv6-enhanced connectivity.”

Leaving IPv6 enabled on current Windows client and server operating systems remains the best practice configuration. The PFE blog team has written several posts around IPv6:


Read more at source -

Monday, August 18, 2014

Command Line Syntax Key

Source -


I came across this link -  These are basic information but some times you won’t be able find these details. So I adding them to my blog reference :)


Text without brackets or braces - Items you must type as shown

<Text inside angle brackets> - Placeholder for which you must supply a value

[Text inside square brackets] - Optional items

{Text inside braces} - Set of required items; choose one

Vertical bar (|) - Separator for mutually exclusive items; choose one

Ellipsis (…) - Items that can be repeated

Monday, July 21, 2014

PowerShell Tips, Tricks and Useful Commands #13

PowerShell scripts can be run as a scheduled job using using Windows scheduler.  Create a batch file with the following syntax/commands:


Powershell.exe “c:\scripts\mytestscript.ps1”


Microsoft Unified Technology Event

Source -

Over the past few months, it has been awesome to connect with our technical communities, customers, and partners at the SharePoint Conference, Lync Conference, Exchange Conference, Project Conference, and most recently, at TechEd North America. While the world is increasingly digital, there is still no replacement for time together, in person, to talk tech and business, and simply get to know each other better. Hands down, my favorite weeks of the past year have been those spent at these conferences, meeting with many, many of you!

As we took stock of the past conferences and looked forward to the next year of conferences, we decided we can do better – better for our technical communities, better for our business customers, better for our partners, and better for Microsoft. Part of this is a recognition that as our industry continues to evolve, so must our approach to creating valuable experiences for all of you. Part of this recognition is feedback from attendees across the past conferences asking for more content and product team engagement across Microsoft versus just within one product area. And, part of this is a recognition that Microsoft’s own cloud first, mobile first strategy must carry through to our conferences for all of us to be successful together.

With that backdrop, I am thrilled to announce we will be hosting an inaugural, unified Microsoft commercial technology conference the week of May 4, 2015 in Chicago, Illinois. We’re bringing the best of what made our past conferences so valuable, plus adding more of what you’ve asked for including…

  • Clearer visibility into Microsoft’s future technology vision and roadmap
  • Unparalleled access to Microsoft senior leaders and the developers who write the code – many of whom will present and engage with you and answer your questions
  • A broader range of learning opportunities across all of Microsoft’s technologies, including actionable best practices from industry experts
  • Deep community interaction with the top technology professionals and industry peers in structured and informal settings
  • Epic after-hour festivities for you to unwind and turn up the fun!

If you attended the SharePoint Conference, Exchange Conference, Lync Conference or Project Conference, this is the conference for you. And, if you’re interested in or already using Office 365, this is the conference for you.


Read more at source.

Thursday, July 17, 2014

Preventing Kerberos change password using RC4 secret keys

Source -

This topic for the IT professional explains some limitations in the Kerberos protocol that could lead to a malicious user taking control of a user’s account. There is a limitation in the Kerberos Network Authentication Service (V5) standard (RFC 4120), which is well-known within the industry, whereby an attacker can authenticate as a user or change that user’s password if the attacker knows the user’s secret key.

Possession of a user’s password-derived Kerberos secret keys (RC4 and Advanced Encryption Standard [AES] by default) is validated during the Kerberos password change exchange per RFC 4757. The user’s plaintext password is never provided to the Key Distribution Center (KDC), and by default, Active Directory domain controllers do not possess a copy of plaintext passwords for accounts. If the domain controller does not support a Kerberos encryption type, that secret key cannot be used to change the password.

In the Windows operating systems designated in the Applies To list at the beginning of this topic, there are three ways to block the ability to change passwords by using Kerberos with RC4 secret keys:

  • Configure the user account to include the account option Smart card is required for interactive logon. This limits the user to only signing in with a valid smart card so that RC4 authentication service requests (AS-REQs) are rejected. To set the account options on an account, right-click on the account, the click Properties, and click the Account tab.
  • Disable RC4 support for Kerberos on all domain controllers. This requires a minimum of a Windows Server 2008 domain functional level and an environment where all Kerberos clients, application servers, and trust relationships to and from the domain must support AES. Support for AES was introduced in Windows Server 2008 and Windows Vista.
  • Deploy domains set to a Windows Server 2012 R2 domain functional level, and configure users as members of the Protected Users security group. Because this feature disrupts more than just RC4 usage in the Kerberos protocol, see resources in the following See also section.


Read more at source -

Wednesday, July 16, 2014

Why the Microsoft Active Directory design flaw isn't serious

Source -

Experts are skeptical of the threat posed by a reported design flaw in Microsoft Active Directory, which is used by many enterprises to control employee access to the corporate network.

Israeli security firm Aorato reported Monday that it created a proof-of-concept attack in which it was able to change a person's network password, thereby making it possible to access other sensitive systems.

Aorato claims the problem stems from Active Directory's backward compatibility with an authentication protocol called NTLM that was the default in versions of Windows older than Windows XP SP3.

Newer versions of Windows use a more secure protocol called Kerberos, which Microsoft has been encouraging customers to upgrade to for years.

NTLM is vulnerable to a so-called "pass-the-hash" attack in which an attacker steals the login credentials for a computer and then uses the hash for those credentials in changing a user's password. The new password can then be used to access other services, such as remote desktop protocol (RDP) or the Outlook web application.

Microsoft says Aorato has not shown anything new.

"This is a well-known industry limitation in the Kerberos Network Authentication Service standard," the company said in a statement sent to CSOonline Tuesday. "Information on how to manage this limitation when using Windows can be found on the Microsoft TechNet site."

Security experts agreed that the problem is not a major risk for businesses.

"It does not seem to be as serious as pictured since the conditions where an actual attack can happen are very complex," Ehsan Foroughi, director of research at Security Compass, said.

Zak Dehlawi, a senior security engineer for Security Innovation agreed, saying pass-the-hash attacks are "most commonly a post-exploitation technique."

"An attacker would already need to have gained access to a victim machine through other vulnerabilities before attempting this new procedure," Dehlawi said.

Foroughi was more troubled by Aorato's contention that Windows' event logging system would not show any indication of a pass-the-hash attack.

"The logging part is the most troubling issue for forensics sake," Foroughi said. "But there is not enough there to warrant enterprises to stop using Active Directory tomorrow."

Read more at source -

Tuesday, July 15, 2014

Active Directory Vulnerability Disclosure – Aorato’s Blog

Source -

Nearly all advanced targeted attacks involve stolen credentials and identity theft. As part of our ongoing research on advanced attacks, we expose a critical Active Directory flaw which enables an attacker to change the victim’s password. This attack can be performed despite current identity-theft protection measures.

Since 95% of all Fortune 1000 companies have an Active Directory deployment, we consider this vulnerability highly sensitive.

Using the new password, an attacker can fully impersonate the victim to access various enterprise services which require the explicit use of the victim’s password such as Remote Desktop Protocol (RDP) Logon and Outlook Web Access (OWA).

The worse part? Logged events miss the vital indication of an identity theft attack. The attacker can perform this activity unbeknownst to event logs, making log-based SIEMs and Big Data Security Analytics useless against these kinds of advanced attacks.

High-Level Anatomy of an Attack

  1. Attacker uses a publicly-available free penetration testing tool (such as WCE or Mimikatz) that steals an authentication component, named NTLM hash, from the employee’s device. The NTLM hash resides by default on all devices that connect to enterprise resources.
    Since this authentication component is known to be a security hazard which leads to identity theft attacks, through the notorious Pass-the-Hash (PtH) attack, protections have been placed to prevent its misuse. For example, many enterprises try to limit the use Active Directory’s older – yet still enabled by default –authentication protocol (i.e. NTLM). In other scenarios, enterprises log and audit NTLM activity.
  2. The attacker forces the client to authenticate to Active Directory using a weaker encryption protocol. At this stage, the attacker uses the Active Directory flaw where the encryption protocol relies on the NTLM hash.
    This activity is not logged in system and 3rd party logs- even those that specifically log NTLM activity. As a result, no alerts, or forensic data, ever indicate that an attack takes place.
  3. The attacker proves its so-called legitimate identity to Active Directory using the weaker authentication protocol. Consequently, the attacker is able to:
      • Authenticate themselves to restricted services
      • Change the password of the victim
  4. The attacker uses the changed password to fully steal the identity of the victim and access all of the victim’s enterprise resources.

Following Responsible Disclosure

We have provided Microsoft a full and responsible disclosure of this episode. In fact, Microsoft recognized our findings to be valid but confirmed that this is a “limitation” that cannot be fixed as it stems from the design of the authentication protocols. Additionally, since these protocols’ specifications are publicly available, Microsoft considers this “limitation” to be “well known”.

This is where we disagree:

  • We consider the fact that attackers can change the victim’s password by only knowing the NTLM hash to be a flaw. If this flaw is by design, this simply makes it a “by-design” flaw.
  • While Microsoft considered the protocol’s design limitation public and “well known”, it is the combination of the different aspects which makes this revelation novel. In fact, each piece of the protocol within itself is indeed public knowledge, appearing in various public documents. However, the actual correlation- and its dire consequence – when placing the pieces together has never been investigated before.
  • The fact that this behavior is not logged has not been addressed by Microsoft.

Since we consider this issue a “by design” flaw, it also requires its own set of mitigation measures which we provide at the end of this entry.
Additionally, the Microsoft official statement is provided in its entirety at the bottom of this blog.

Technical Details

The Protocols behind Active Directory: NTLM and Kerberos

For the techie readers who are already familiar with NTLM and Kerberos: feel free to skip this section.

To understand this vulnerability, let’s first take a look at the protocols behind Active Directory’s Single Sign On (SSO) authentication – NTLM and Kerberos. SSO is what allows users to provide their password only once even though they access various services – whether in the corporate network or in the Cloud. As mentioned, the underlying SSO authentication protocols are NTLM and Kerberos. NTLM is the older Windows’ authentication protocol which, although still enabled by default due to backward compatibility reasons, suffers from security issues and so has been superseded by the Kerberos protocol. 

Both the NTLM and Kerberos protocols are based on using the user’s password as a proof of the user’s identity. The key difference between them is the way they use of the user’s password:

  • The NTLM protocol computes a relatively weak cryptographic hash function based on the user’s password to create the NTLM hash. From that point on, the protocol uses that NTLM hash as a replacement for the user’s password in order to authenticate to various services.
  • Kerberos works by exchanging the password for a ticket (formally known as the TGT – Ticket Granting Ticket). This time around, Kerberos uses safer cryptographic methods than that of NTLM’s. The Kerberos ticket contains all of the user’s relevant authentication and authorization information. This information enables the KDC (i.e. the Key Distribution Center. Consider it as the Kerberos’ “key master” which grants specific access to other organizational services) to rely solely on the ticket information for the user’s authentication and authorization.

It’s important to stress is that Kerberos supersedes NTLM due to security issues. Accordingly, there shouldn’t be a dependence of Kerberos on NTLM.

The Active Directory Vulnerability: NTLM’s Hash is Kerberos’ RC4-HMAC Key

The thing is that Windows supplemented the Kerberos standard with an encryption method that allows users to obtain a ticket with… the older NTLM hash.

Microsoft’s reasoning?  To support a slick upgrade from strictly NTLM supporting versions (Windows NT 4.0 and lower) to Kerberos supporting versions (Windows 2000 and thereafter).

Technically, this upgrade was achieved by adding support in Kerberos for the encryption algorithm named RC4-HMAC.
And herein lies the problem: the RC4-HMAC encryption algorithm uses the NTLM hash as its key.

This fact is explicitly stated in section 2 of RFC 4757: “The key used for RC4-HMAC is the same as the existing Windows NT key (NT Password Hash) for compatibility reasons.”

Other than the RC4-HMAC encryption, Kerberos supports other stronger ciphers such as the AES encryption (or more formally: “AES256-CTS-HMAC-SHA1″), which is the default encryption for Kerberos in Windows. The stronger encryption methods do not accept the NTLM hash as their key. 

(in)Security Side-Effect: Attacker Can Access Sensitive Enterprise Resources albeit Protection Measures

The side-effect of this vulnerability? Attackers can obtain a valid Kerberos ticket if they are able to obtain a user’s NTLM hash.

The reason is that they can change the encryption settings from the default, stronger, AES encryption to the weaker RC4-HMAC and use the stolen NTLM hash as the Kerberos’ password encryption key. As a result, attackers can prove their identity to Active Directory and in turn, receive a valid Kerberos ticket.

As opposed to other attacks which relied on the direct use of the stolen NTLM hash such as Pass-the-Hash (PtH), in this attack the attackers can obtain a fresh, legitimate Kerberos ticket with by the stolen NTLM hash. This fact changes the main tactic used by targeted attacks, namely carrying out an attack using PtH.

Unfortunately, many mitigation and solutions to counter Pass-the-Hash are based on allowing only Kerberos authenticated users or detecting anomalous NTLM authentication. However, as demonstrated, an attacker using this vulnerability can create a valid Kerberos ticket and authenticate to various systems by impersonating the victim whose NTLM hash was stolen. Consequently, these anti-PtH techniques are rendered useless.

The Security Impact: Attacker Can Change the Victim’s Password

The dire consequence? Attackers can use the stolen NTLM hash to change the victim’s password to one of their choice.

To see how, let’s first take a look at the Change Password mechanism. Naturally, changing the password is an ultra-sensitive operation. In fact, as opposed to all other activities that can be executed by anyone who has access the computer, changing the password requires knowledge of the older password to prevent attackers who have already gained temporary access to the computer from making the access persistent.


Read more at source -

Sunday, June 29, 2014

MacBook Air for Surface Pro 3 trade-in

Source -

According to Zdnet, Microsoft is offering MacBook Air owners up to $650 in store credit for trading in their Apple devices for its new Surface Pro 3 tablets.

The new promotion, running June 20 to July 31, 2014 -- "or while supplies last" -- requires users to bring MacBook Airs into select Microsoft retail stores in the U.S., Puerto Rico and Canada. (The trade-in isn't valid online.)

Microsoft execs have been touting the Surface Pro 3 as the tablet that can replace users' existing laptops, including MacBook Airs. Microsoft's site

Read more at source

Thursday, April 24, 2014

Forefront Identity Manager vNext Roadmap

Source -

Back in December we announced that we would be shipping the next version of Forefront Identity Manager in the first half of 2015.

Today we would like to provide an update with further details of this release, including our approach and the investments we are making to enhance our on-premises, private cloud and hybrid cloud identity management solutions.

Forefront Identity Manager helps your organization ensure users have appropriate access corporate information regardless of where it is located—in your datacenter or in the cloud, by providing self-service identity management, automated lifecycle management across heterogeneous platforms, a rich policy framework for enforcing security policies, and detailed audit capabilities.

Our approach to the next version of Identity Manager is guided by the following customer feedback and innovation goals:

  • Continue to address risks to critical assets, by enhancing and expanding the available protections for enterprise identity, ensuring the enterprise’s identity infrastructure is resilient to targeted attacks

  • Enable the mobile access scenarios that customers are looking to adopt and manage from a broad range of devices across on-premises and cloud services

  • Connect with Azure Active Directory to integrate with its features and extend the reach of enterprise identity to a range of Software-as-a-Service applications 

  • Deliver easy-to-deploy end-to-end scenarios that complement investments in Windows, Office, Microsoft Azure, and Active Directory with end user self-service, delegation and configurable policies

We have three major investment areas for this release of Identity Manager:

  • Hybrid scenarios that leverage cloud-based services delivered in Microsoft Azure, including Multi-Factor Authentication, Azure Active Directory application integration, analytics and reporting 

  • Support for the latest platforms and mobile devices with modern user interfaces 

  • Improved security with additional controls, analytics and auditing of administrative and privileged user identities and their access to Active Directory, Windows Server and applications 

As part of the next release, we will also move Identity Manager under the Microsoft brand, so this release will be known as Microsoft Identity Manager. 

Read more at source -

Wednesday, April 23, 2014

The end is nigh for Google Glass

Source -

There's no doubt that Google Glass was an interesting project, but it was also a deeply flawed project, and as one its most ardent supporters gives up on it, it's only a matter of time until it joins devices such as the Zune, the Kin, the PlayBook, and the Xoom in tech hell.

Google Glass(Source: Google)

The idea of a head-wearable computer with integrated prism projector optical display should have gotten all the geeks, nerds, and tech heads drooling. And for a while it did, but it only took a year for the project's most voracious supporter – Robert Scoble – to declare that the device that has been almost consistently on his face for the past year is "freaky and weird."

read more at source -

Popular Posts


Twitter Delicious Facebook Digg Stumbleupon Favorites More