By default, Windows caches up to 10 credentials on local computer and these cached credentials never expire. They are stored in the registry under HKLM\Security\Cache key.

Note that you will need to give yourself Read permission

All credentials are hashed in the NL$x value format and cannot be viewed plainly and easily decrypted, fortunately. However, it could still potentially be risky because once the hackers get their hands on these data they can use a brute-force attack against these hashes to decrypt the password.

So, here are a few approaches to limit the cache credentials on Windows computers.

First of all, add all accounts in Domain Admin group to the Protected Users group so the credentials for these accounts won’t be cached locally. However, if you have some apps that integrates with AD you may find difficulty signing in using your own password.

Then, turn on BitLocker disk encryption if possible. Once encrypted, hackers won’t be able to do anything with it.

If BitLocker is not possible, disable cached credentials on all desktops and limit to only 1 for all laptops.

It’s easier to do so through GPO. Head over to the following location,

Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options

And set the Interactive Logon: Number of previous logons to cache to 1 for laptops and 0 for desktops.

Additionally, you can display a notification of using cached credentials by enabling the policy Report when logon server was not available during user logon under the following location:

Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Logon Options

Not anymore with the use of TLS, StartTLS, or even better S/MIME which is suitable for your most sensitive information.

Every email sent through TLS is encrypted to protect the message in transit from one server to another. It requires both mail servers to follow along in order for the encryption to work. But not all mail servers are equally made. If an email is sent via TLS but the other end doesn’t accept TLS, the email will be degraded from TLS. Like back to the old days, email gets decrypted and delivered in plain text. Bad news for you but good news for the man in the middle.

According to Google, during a 3-month period between March 11, 2019, and June 9, 2019, 89% of emails going out from Gmail and 94% of email received by Gmail are encrypted. And who are the top bad guys?

So how to tell if my incoming emails are encrypted

Gmail

Google is on top of a lot of things. This is no different. If you are using Gmail as your main mail app, you can easily tell whether the email you received has never been intercepted by the man in the middle.

When you get an email, click the little down arrow to reveal the header and you will find if the message was received through TLS or other encryption method.

Outlook

Not as easy as Gmail but still can be done. Open the email you received from outside, click File > Properties.

And look through the Internet headers section. If you see the word TLS in there somewhere you can safely tell your email is safe during the transition.

How to tell if email I am sending is encrypted

For Gmail, if you have S/MIME enabled on your account, you will see a lock icon that shows the level of encryption supported by your message’s recipients. Otherwise, there is no direct way to tell whether your email will be safe all the way to the other end.

But there are a few workarounds that we can still take.

First, we can start with an introduction email and only start sending confidential content after receiving one email from other party and verified that it’s safe.

Or, we can use a TLS checker to scan and verify that the mail server used by the domain you are communicating with supports at least TLS. It’s safe to email me confidential stuff because it’s OK in the TLS column like below.

But never send confidential emails to the mail server that’s not safe like below.

Last, if you are using Gmail and need the highest security for sending confidential via email, you can turn on the Confidential Mode so entire email communication will be secured.

Take this as a skeleton and flesh it out on your own. Take an hour or two and research the things I talk about. Tailor this to your own environment and users. Make it relevant to your people. Include corporate stories, include your audience, exclude yourself.

This ain’t about how smart you are at infosec, and I can’t stress this enough, talk about how people can defendthemselves. Give them things to look for and action they can take. No one gives a shit about your firewall rules.

You can also check the slideshow directly here.

What is KRBTGT?

The KRBTGT is a local default account that acts as a service account for the Key Distribution Center (KDC) service. It’s created automatically when a new domain is created.

• It cannot be deleted
• its name cannot be changed
• it cannot be enabled
• it only belongs to the following two groups
  • Domain Users
  • Denied RODC Password Replication Group

KDC service handles all Kerberos ticket requests so KRBTGT account in AD plays a key role that encrypts and sign all Kerberos tickets for the domain.

You can also use the PowerShell code to get the account’s detail as well:

Get-AdUser krbtgt -property created, passwordlastset, enabled, sid, distinguishedname

How it works:

1. User logs on with AD user name and password to a domain-joined computer (usually a workstation).
2. The user requests authentication by sending a timestamp (Pre-auth data) encrypted with the users password-based encryption key (password hash).
3. User account (user@adsecurity.org) requests a Kerberos service ticket (TGT) with PREAUTH data (Kerberos AS-REQ).
4. The Kerberos server (KDC) receives the authentication request, validates the data, and replies with a TGT (Kerberos AS-REP).

Why do you need to update its password?

99.99% of the time, the KRBTGT account’s password has not changed since the AD Domain was set up. But since it’s a domain account, all writable DCs know the account password in order to decrypt Kerberos tickets for validation.

Because of that, the attackers may use the KRBTGT account to persist on the network even if every other account has its password changed. During an incredibly awesome talk (Video) at the Black Hat 2014 security conference in Las Vegas, NV in early August, Skip Duckwall & Benjamin Delpy spoke about a method (using Mimikatz) to generate your own Kerberos tickets (aka the Golden Ticket).

And that’s why Microsoft now recommends that the KRBTGT password change on a regular basis.

How to change the password?

Microsoft posted a KRBTGT account password PowerShell script on TechNet that will change the KRBTGT account password once for a domain, force replication, and monitor change status.

Note that changing the KRBTGT account password in a 2008 (or higher) DFL will not cause replication issues.

There are two KRBTGT Password Change Scenarios:

• Maintenance: Changing the KRBTGT account password once, waiting for replication to complete (and the forest converge), and then changing the password a second time, provides a solid process for ensuring the KRBTGT account is protected and reduces risk (Kerberos and application issues).
• Breach Recovery: Changing the KRBTGT account password twice in rapid succession (before AD replication completes) will invalidate all existing TGTs forcing clients to re-authenticate since the KDC service will be unable to decrypt the existing TGTs. Choosing this path will likely require rebooting application servers (or at least re-starting application services to get them talking Kerberos correctly again).

Resources:

• Kerberos & KRBTGT: Active Directory’s Domain Kerberos Service Account
• Active Directory Accounts
• Reset the krbtgt account password/keys

Newly added to the list is the password hashes in NTLM format, which can be used to compare to the hashes in any AD environment. That’s a wonderful news to those mostly working in a Windows environment, myself included.

Here are the steps how this can be done. I personally haven’t got chance to test it myself but sure will in the near future.

1. Download the entire 517M NTLM passwords either as a torrent or courtesy of Cloudflare aggressively caching them.
2. Export AD hashes either using PowerShell or the built-in ntdsutil command line.
3. Check out the Match-ADHashes PowerShell script on GitHub or the Compromise Checker by Semrau Security.

If someone accidentally adds dots to your address when emailing you, you’ll still get that email. For example, if your email is johnsmith@gmail.com, you own all dotted versions of your address:

• john.smith@gmail.com
• jo.hn.sm.ith@gmail.com
• j.o.h.n.s.m.i.t.h@gmail.com

The intention of this is good but it also opens a door for a phishing scam. Here is an example.

James Hfisher received an email from Netflix asking him to update his payment details.

Since the email is genuinely from Netflix, he clicked the link. It logged him in and directed him to an “Update your credit or debit card” page, which again is genuinely hosted on Netflix. No phishing spotted so far.

But then, he found that he doesn’t recognize the credit card number shown on the Update page, never seen that number and certainly never used one. What’s going on?

James finally realized that the email was sent to james.hfisher@gmail.com with a dot in it while the one he uses doesn’t. The email was supposed to be bounced but instead, it ended up in James’ inbox, thanks to Gmail’s dots don’t matter feature.

Here is how this runs down, concluded by James eventually.

1. Hammer the Netflix signup form until you find angmail.com address which is “already registered”. Let’s say you find the victim,jameshfisher
2. Create a Netflix account with address,james.hfisher.
3. Sign up for a free trial with a throwaway card number.
4. After Netflix applies the “active card check”, cancel the card.
5. Wait for Netflix to bill the canceled card. Then Netflix emailsjames.hfisher for a valid card.
6. Hope Jim reads the email to james.hfisher, assumes it’s for his Netflix account backed by jameshfisher, then enters his card,**** 1234.
7. Change the email for the Netflix account to eve@gmail.com, kicking Jim’s access to this account.
8. Use Netflix free forever with Jim’s card **** 1234!

So, dots do matter in some cases.

/via James Hfisher/

This cheat sheet is intended to run down the typical steps performed when conducting a web application penetration test. I will break these steps down into sub-tasks and describe the tools I recommend using at each level.

Many of the ideas presented in this sheet come from the fantastic teachings of Tim “lanmaster53” Tomes, who has kindly allowed me to share them with you here. If you or anyone you know is interested in web application penetration testing Training I highly recommend that you or your company consider Tim.

Please bear in mind that these steps are iterative so in a typical engagement you can expect to do them multiple times. This is particularly true if you manage to traverse different levels of access in an application (e.g. elevate from a regular user to an admin).

Finally, throughout this sheet, I will heavily discuss tools included in PortSwigger’s Burp Suite Professional which is a paid product intended for professional use. I apologize if this dissuades you, but at the price they offer the tool for I consider it a bargain.

/via JDow.io/

Two-dimensional barcodes and QR codes can hold a great deal of information, and the codes printed on airline boarding passes may allow someone to discover more about you, your future travel plans, and your frequent flyer account.

Thanks to KrebsOnSecurity for this valuable info.

The standards for the boarding pass barcodes are widely available and have been for years. Check out this document (PDF) from the International Air Transport Association (IATA) for more on how the barcode standards work and have been implemented in various forms.

For the same reason, It’s also not a good idea posting your boarding pass on social networks like Facebook without blurring out the critical information such as barcodes. In some worst cases, it can get your account stolen.

Interested in learning what’s in your boarding pass barcode? Take a picture of the barcode with your phone, and upload it to this site. This blog on the same topic from several years back includes some helpful hints on how to decode the various information fields that get dumped by the barcode reader.