Category Archives: Data Security

[Podcast] Deleting a File Is More than Placing It into the Trash

[Podcast] Deleting a File Is More than Placing It into the Trash

Leave a review for our podcast & we'll send you a pack of infosec cards.


When we delete a file, our computer’s user interface makes the file disappear as if it is just a simple drag and drop. The reality is that the file is still in your hard drive.

In this episode of the Inside Out Security Show, our panelists elaborate on the complexities of deleting a file, the lengths IT pros go through to obliterate a file, and surprising places your files might reside.

Kris Keyser explains, “When you’re deleting a file, you’re not necessarily deleting a file. You’re deleting the reference to that file.”

Other Articles Discussed:

Instead of “Tool of the Week”, we learned about a coveted certification from a Blackhat attendee: Offensive Security Certified Professional. It is a 24-hour lab test to demonstrate your understanding of identifying vulnerabilities, pen testing, etc.

Panelists: Kris Keyser, Jeff Peters, Forrest Temple

Dedham Savings Uses Varonis to Build Trust with Their Customers and Stop Su...

Dedham Savings Uses Varonis to Build Trust with Their Customers and Stop Surprises

Case Study

Trust is important in all relationships, but even more so for a community bank like Dedham Savings. Charged with protecting the sensitive financial data of their customers, Dedham turned to Varonis.

During a Varonis risk assessment, they discovered a large amount of stale customer data on their network: data that they could immediately take off the network, reducing the potential severity of a data breach and instantly improving their security posture.

With default network tools, it’s hard for any IT team to deeply understand exactly what is happening on their network – and they don’t have insight into the behaviors of users on their network: what files they’re using, what they have access to but really shouldn’t and how their network access profile matches others in their department.

As Jim Hanlon, Senior Vice President & CTO of Dedham Savings Bank, says: “The more customer data that you have on your network, the more risk there is. You really do need [something] like Varonis managing these vast amounts of data and to protect your customer data” – see how Dedham Savings uses Varonis in this quick one minute video.

 

[Podcast] Are Cyber War Rooms Necessary?

[Podcast] Are Cyber War Rooms Necessary?

Leave a review for our podcast & we'll send you a pack of infosec cards.


While some management teams are afraid of a pentest or risk assessment, other organizations – particularly financial institutions – are well aware of their security risks. They are addressing these risks by simulating fake cyberattacks. By putting IT, managers, board members and executives who would be responsible for responding to a real breach or attack, they are learning how to respond to press, regulators, law enforcement, as well as other scenarios they might not otherwise expect.

However, other security experts would argue that cyber war rooms are financially prohibitive for most organizations with a limited budget. What’s more, organizations should keep in mind that not all attacks have to be complicated. If organizations curb phishing attacks or achieve a least privilege model, they would already significantly reduce their risk.

Other Articles Discussed:

  • Dark web marketplaces AlphaBay and Hansa shut down
  • Every voting machine gets hacked at DEF CON
  • Real life Minority Report
  • German judge rule that keylogging employees is illegal

Tool of the week: Reply All Podcast: Long Distance

Panelists: Mike Buckbee, Kris Keyser, Kilian Englert

 

 

Working With Windows Local Administrator Accounts, Part III

Working With Windows Local Administrator Accounts, Part III

One point to keep in mind in this series is that we’re trying to limit the powers that are inherent in Administrator accounts. In short: use the Force sparingly. In the last post, we showed it’s possible to remove the local Administrator account and manage it centrally with GPOs. Let’s go over a few things I glossed over last time, and discuss additional ways to secure these accounts.

Restricted Groups: Handle with Care

In my Acme environment, the Restricted Groups GPO is used to push out a domain-level group to the local Administrators group in each of the OUs: one policy for Masa and Pimiento, another for Taco. It’s a neat trick, and for larger domains, it saves IT from having to do this through scripts or spending time performing this manually.

To refresh memories, here’s how my GPO for Restricted Groups looked:

Replaces local  Administrators groups with Acme-IT-1.

By using the “Member of this group” section, I’m forcing the Group Policy Manager to replace, not add, Acme-IT-1 to each local Administrators group in my OU. The problem is you may overwrite existing group members, and you don’t know what services or apps depend on certain local accounts being there.

You’ll likely want to evaluate this idea out on a small sample. This may involve more work— local scripts to re-add those accounts, or possibly creating new domain level accounts that can be added into the above.

Or if you prefer, you can use Group Policy Preferences (GPP). It has an update option for adding a new group (or user) under a local Administrator account (below). We know not to use GPP to reset local Administrator account passwords, right?

With GPP, you can add Acme-IT-2 to the local Administrators groups.

Even More Secure

There is, sigh, a problem in using Restricted Groups and centrally managed domain-level Administrator accounts. Since all users by default,  are under Domain Users, it means that local Administrators can be exploited through Pass-the-Hash (PtH) techniques — get NTLM hash, and pass to psexec — to log on to any other machine in the network.

This was the conundrum we were trying to grapple with in the first place! Recall: local Administrators are usually given simple — easily guessable or hackable — passwords which can then be leveraged to log on to other machines. We wanted to avoid having an Administrator-level local account that can be potentially used globally.

As I mentioned in the second post, this security hole can be addressed by creating a GPO – under User Rights Assignment — to restrict network access all together. This may not be practical in all cases for Administrators accounts.

Another possibility is to limit the machines that these domain-level Administrator accounts can log into. And again we make a lifeline call to User Rights Assignment, but this time enlisting the “Allows log on locally” property, adding the Acme-IT-1 Administrators group (below). We would do the same for the other OU in the Acme domain, but adding the Acme-IT-2 group.

This GPO prevents accounts from logging on to machines outside the specified domain. So even if a clever hacker gets into the Acme company, he could PtH with Administrator account but only within the OU.

It’s a reasonable solution. And I do realize that many companies likely already use this GPO property for ordinary user accounts, just for reasons I noted above.

Additional Thoughts

In writing this brief series, you quickly come to the conclusion that zillions of IT folks already know in their bones: you’re always trying to balance security against convenience. You won’t have a perfect solution, and you’ve probably erred on the side of convenience (to avoid getting shouted at by the user community).

Of course, you live with what you have. But then you should compensate for potential security holes by stepping up your monitoring game! You know where this is going.

One final caveat goes back to my amazing pen testing series where I showed how delegated Administrator groups can be leveraged to allow hacker to hop more freely around a domain—this has to do with accounts being in more than one Active Directory group. Take another look at it!

[Podcast] Roxy Dee, Threat Intelligence Engineer

[Podcast] Roxy Dee, Threat Intelligence Engineer

Leave a review for our podcast & we'll send you a pack of infosec cards.


Some of you might be familiar with Roxy Dee’s infosec book giveaways. Others might have met her recently at Defcon as she shared with infosec n00bs practical career advice. But aside from all the free books and advice, she also has an inspiring personal and professional story to share.

In our interview, I learned about her budding interest in security, but lacked the funds to pursue her passion. How did she workaround her financial constraint? Free videos and notes with Professor Messer! What’s more, she thrived in her first post providing tech support for Verizon Fios. With grit, discipline and volunteering at BSides, she eventually landed an entry-level position as a network security analyst.

Now she works as a threat intelligence engineer and in her spare time, she writes how-tos and shares sage advice on her Medium account, @theroxyd

Transcript

Cindy Ng: For individuals who have had a nonlinear career path in security, Threat Intelligence Engineer Roxy Dee knows exactly what that entails. She begins by describing what it was like to learn about a new industry with limited funding, and how she studied security fundamentals in order to get her foot in the door. In our interview, she reveals three things you need to know about vulnerability management, why fraud detection is a lot like network traffic detection, and how to navigate your career with limited resources.

We currently have a huge security shortage, and people are making analogies as to the kind of people we should hire. For instance, if you’re able to pick up music, you might be able to pick up technology. And I’ve found that in security it’s extremely important to be detail oriented, because the adage is the bad guys only need to be right once and security people need to be right all the time. And I had read on your Medium account the way you got into security, for practical reasons. And so let’s start there, because it might help encourage others to start learning about security on their own. Tell us what aspect of security you found interesting and the circumstances that led you in this direction. –

Roxy Dee: Just to comment on what you’ve said. Actually, that’s a really good reason to make sure you have a diverse team is because everybody has their own special strengths and having a diverse team means that you’ll be able to fight the bad guys a lot better because there will always be someone that has that strength where it’s needed. The bad guys, they can develop their own team the way they want and so it’s important to have a diverse team because every bad guy you meet is going to be different. That’s a very good point, itself.

Cindy Ng: Can you clarify “diverse?” You mean everybody on your team is going to have their own specialty that they’re really passionate about? By knowing what they’re passionate about, you know how to leverage their skill set? Is that what you mean by diversity?

Roxy Dee: Yeah. That’s part of it. I mean, just making sure that you don’t have the same person. For example, I’ll tell my story like you asked in the original question. As a single mom, I have a different experience than someone that has had less difficulties in that area, so I might think of things differently, or be resourceful in different ways. Or I’m not really that great at writing reports. I can write well, but I haven’t had the practice of writing reports. Somebody that went to college, they might have that because they were kind of forced to do it, by having people from different backgrounds that have had different struggles.

And I got into security because I was already into phone phreaking, which is a way of hacking the phone system. And so for me, when I went to my first 2600 Meeting and they were talking about computer security and information security, it was a new topic and I was kind of surprised. I was like, “I thought 2600 was just about phone hacking.” But I realized that at the time…It was 2011, and phone hacking had become less of a thing and computer security became more of something. I got the inspiration to go that route, because I realized that it’s very similar. But as a single mom, I didn’t have the time or the money to go to college and study for it. So I used a lot of self-learning techniques, I went to a lot of conferences, I surrounded myself with people that were interested in the topic, and through that I was able to learn what I needed to do to start my career.

Cindy Ng: People have trouble learning the vocabulary because it’s like learning a new language. How did you…even though you were into phone hacking and the transition into computer security, it has its own distinct language, how did you make the connections and how long did it take you? What experiences did you surround yourself with to cultivate a security mindset?

Roxy Dee: I’ve been on computers since I was a little kid, like four or five years old. So for me, it may not be as difficult for me as other people, because I kind grew up on computers. Having that background helped. But when it came to information security, there were a lot of times where I had no idea what people were saying. Like I did not know what “Reverse Engineering” meant, or I didn’t know what “Trojan” meant. And now, it’s like, “Oh, I obviously know what those things are.” But I had no idea what people were talking about. So going to conferences and watching DEF CON talks, and listening to people. But by the time I had gone to DEF CON about three times, I think it was my third time I went to DEF CON, I thought, “Wow. I actually know what people are saying now.” And it’s just a gradual process, because I didn’t have that formal education.

There were a few conferences that I volunteered at. Mostly at BSides. And BSides are usually free anyway. When you volunteer, you become more visible in the community, and so people will come to you or people will trust you with things. And that was a big part of my career, was networking with people and becoming visible in the community. That way, if I wanted to apply for a job, if I already knew someone there or if I knew someone that knew someone, it was a lot easier to get my resume pushed to the hiring manager than if I just apply.

Cindy Ng: How were you able to land your first security job?

Roxy Dee: And as far as my first InterSec job, I was working in tech support and I was doing very well at it. I was at the top of the metrics, I was always in like the top 10 agents.

Cindy Ng: What were some of the things that you were doing?

Roxy Dee: It was tech support for Verizon Fios. There was a lot of, “Restart your router,” “Restart your set-top box,” things like that. But I was able to learn how to explain things to people in ways that they could understand. So it really helped me understand tech speak, I guess, understand how to speak technically without losing the person, like a non-technical person.

Cindy Ng: And then how did you transition into your next role?

Roxy Dee: It all had to do with networking, and at this point, I had volunteered for a few BSides. So actually, someone that I knew at the time told me about a position that was an entry-level network security analyst, and all I needed to do was get my Security+ certification within the first six months of working there. And so it was an opportunity for me because they accepted entry-level. And when they gave me the assessment that they give people they interview, I aced it because I had studied already about networking through a website called “Professor Messer.” And that website actually helped me with Security+ as well, and I was just able to do that through YouTube videos, like his entire website is just YouTube videos. So once I got there, I took my Security plus and I ended up, actually, on the night shift. So I was able to study in quiet during my shift every day at work. I just made it a routine, “I have to spend, you know, this amount of time studying on,” whatever topic I wanted to move forward with, which I knew what to study because I was going to conferences and I was taking notes from the talks, writing down things I didn’t understand or words I didn’t know and then later I was researching that topic so I could understand more. And then I would watch the talk again with that understanding if it was recorded, or I would go back to my notes with that understanding. The fact that I was working overnight and I was not interrupted really helped, and then from there…and that was like a very entry-level position. And from there, I went to a cloud hosting company, secure cloud hosting company with a focus on security and the great thing about that was that it was a startup. They didn’t have a huge staff, and they had a ton of things that they had to do and a bunch of unrealistic deadlines. So they would constantly be throwing me into situations I was not prepared for.

Cindy Ng: Can you give us an example?

Roxy Dee: Yeah. That was really like the best training for me, is just being able to do it. So when they started a Vulnerability Management Program, I have no experience in vulnerability management before this and they wanted me to be one of the two people on the team. So I had a manager, and then I was the only other person. Through this position, I learned what good techniques are and I was also inspired to do more research on it. And if I hadn’t been given that position, I wouldn’t have been inspired to look it up.

Cindy Ng: What does Vulnerability Management entail, three things that you should know?

Roxy Dee: Yeah. So Vulnerability Management has a lot to do with making sure that all the systems are up to date on patching. That’s one of them. The second thing I would say that’s very important is inventory management, because there were some systems that nobody was using and vulnerabilities existed there, but there was actually no one to fix them. And so if you don’t take proper inventory of your systems and you don’t do, you know, discovery scans to discover what’s out there, you could have something sitting there that an attacker, once they get in, they could use or they might have access to. And then another thing that’s really important in Vulnerability Management is actually managing the data because you’ll get a lot of data. But if you don’t use it properly it’s pretty much useless, if you don’t have a system to track when you need to have this remediated by, what are your compliance requirements? And so you have to track, “When did I discover this and when is it due? And what are the vulnerabilities and what are the systems? What do the systems look like? So there’s a lot of data you’re going to get and you have to manage it, or you will be completely unable to use it.

Cindy Ng: And then you moved on into something else?

Roxy Dee: Oh, yes. Actually, it being a startup kind of wore on me, to be honest. So I got a phone call from a recruiter, actually, while I was at work.

This was another situation where I had no idea how to do what I was tasked with, and the task was…So from my previous positions, I had learned how to monitor and detect, and how to set up alerts, useful alerts that can serve, you know, whatever purpose was needed. So I already had this background. So they said, “We have this application. We want you to log into it, and do whatever you need to do to detect fraud.” Like it was very loosely defined what my role was, “Detect bad things happening on the website.” So I find out that this application actually had been stood up four years prior and they kind of used it for a little while, but then they abandoned it.

And so my job was to bring it back to life and fix some of the issues that they didn’t have time for, or they didn’t actually know how to fix or didn’t want to spend time fixing them. That was extremely beneficial. I had been given a task, so I was motivated to learn this application and how to use it, and I didn’t know anything about fraud. So I spent a lot of time with the Fraud Operations team, and through that, through that experience of being given a task and having to do it, and not knowing anything about it, I learned a lot about fraud.

Cindy Ng: I’d love to hear from your experience what you’ve learned about fraud that most people might not know.

Roxy Dee: What I didn’t consider was that, actually, fraud detection is very much like network traffic detection. You look for a type of activity or a type of behavior and you set up detection for it, and then you make sure that you don’t have too many false positives. And it’s very similar to what network security analysts do. And when I hear security people say, “Oh, I don’t even know where to start with fraud,” well, just think about from a network security perspective if you’re a network security analyst, how you would go about detecting and alerting. And the other aspect of it is the fraudulent activity is almost always an anomaly. It’s almost always something that is not normal. If you’re just looking around for things that are off or not normal, you’re going to find the fraud.

Cindy Ng: But how can you can tell what’s normal and what’s not normal?

Roxy Dee: Well, first, it’s good to look up all sorts of sessions and all sorts of activity and get like a baseline of, you know, “This is normal activity.” But you can also talk to the Fraud team or, you know, or whatever team handles…It’s not specific to fraud, but, you know, if you’re detecting something else, talk to the people that handle it. And ask them, “What would make your alerts better? What is something that has not been found before or something that you were alerted to, but it was too late?” And ask just a bunch of questions, and then you’ll find through asking that what you need to detect.

Like for example, there was one situation where we had a rule that if a certain amount was sent in a certain way, like a wire, that it would alert. But what we didn’t consider was, “What if there’s smaller amounts that add up to a large amount?” And understanding…So we found out that, “Oh, this amount was sent out, but it was sent out in small pieces over a certain amount of time.” So through talking to the Fraud Operations team, if we didn’t discuss it with them, we never would have known that that was something that was an issue. So then we came up with a way to detect those types of fraudulent wire transfers as well.

Cindy Ng: How interesting. Okay. You were talking about your latest role at another bank.

Roxy Dee: I finished my contract and then I went to my current role, which focuses on a lot more than just online activity. I have more to work with now. With each new position, I just kind of layered more experience on top of what I already knew. And I know it’s better to work for a company for a long time and I kind of wish these past six years, I had been with just one company.

Each time that I changed positions, I got more responsibility, pay increase, and I’m hoping I don’t have to change positions as much. But it kind of gave me like a new environment to work with and kind of forced me to learn new things. So I would say, in the beginning of your career, don’t settle. If you get somewhere and you don’t like what you’re being paid, and you don’t think your career is advancing, don’t be afraid to move to a different position, because it’s a lot harder to ask for a raise than to just go somewhere else that’s going to pay you more.

So I’m noticing a lot of the companies that I’m working for, will expect the employees to stay there without giving them any sort of incentive to stay. And so when a new company comes along, they say, you know, “Wow. She’s working on this and that, and she’s making x amount. And we can take all that knowledge that she learned over there, and we can basically buy it for $10,000 more than what she’s making currently.” So companies are interested in grabbing people from other companies that have already had the experience, because it’s kind of a savings in training costs. So, you know, I try to look every six months or so, just to make sure there’s not a better deal out there, because they do exist. And I don’t know how that is in other fields, though. I know in information security, we have that. That’s just the nature of the field right now.

Cindy Ng: I think I got a good overview of your career trajectory. I’m wondering if there’s anything else that you’d want to share with our listeners?

Roxy Dee: Yeah. I guess, I pretty much have spent…So the first two or three years, I spent really working on myself, and making sure that I had all the knowledge and resources I needed to get that first job. The person that I was five or six years ago is different than who I am now. And what I mean is, my situation has changed a bit, to where I have more income and I have more capabilities than I did five years ago. One of the things that’s been important to me is giving back and making sure that, you know, just because I went through struggles five years ago…You know, I understand we all have to go through our struggles. But if I can make something a little bit easier for someone that was in my situation or maybe in a different situation but still needs help, that’s my way of giving back.

And spending $20 to buy someone a book is a lot less of a hit on me financially than it would have been five years ago. Five years ago, I couldn’t afford to drop to even $20 on a book to learn. I had to do everything online, and everything had to be free. I just want to encourage people, if you see an opportunity to help someone and, you know, for example, if you see someone that wants to speak at a conference and they just don’t have the resources to do so. And you think, “Well, this $100 hotel a night, a hotel room is less of a financial hit to me than to, you know, than to that person. And that could mean the difference between them having a career-building opportunity or not having that.” Just seek out ways to help people. One of the things I’ve been doing is the free book giveaway, where I actually have people sending me Amazon gift cards and there is actually one person that’s done it consistently in large amounts. And what I do with that is, like every two weeks, I have a tweet that I send out that if you reply to it with the book that you want, then you can win that book up until I run out of money, up until I run out of Amazon dollars.

Cindy Ng: Is this person an anonymous patron or benefactor? This person just sends you an Amazon gift card…with a few bucks and you share it with everyone? That’s so great.

Roxy Dee: And other people have sent me, you know, $20 to $50 in Amazon credits, and it’s just a really good…It kind of happen accidentally, and there’s the story of it on my Medium account.

Cindy Ng: What were the last three books that you gave away? – Oh, the last three? Well… – Or the last one, if you…

Roxy Dee: …the most popular one right now, this is just based on the last one that I did, is the Defensive Security Handbook. That was the most popular one. But I also get a lot of requests for Practical Packet Analysis by Chris Sanders and Practical Malware Analysis. And so this one, actually, this is a very recent book that came out called the Defensive Security Handbook. That’s by Amanda Berlin and Lee Brotherston. And that’s about…it says, “Best practices for securing infrastructure.” So it’s a blue team-themed book. That’s actually sold over 1,000 copies already and it just came out recently. It came out about a month ago. Yeah. So I think that’s going to be a very popular book for my giveaways.

Cindy Ng: How are you growing yourself these days?

Roxy Dee: Well, I wanted to spend more time writing guides. I just want to write things that can help beginners. I have set up my Medium account, and I posted something on setting up a honeypot network, which is a very…it sounds very complicated, but I broke it down step by step. So my goal in this was to make one article where you could set it up. Because a lot of the issues I was having was, yeah, I might find a guide on how to do something, but it didn’t include every single step. Like they assumed that you knew certain things before you started on that guide. So I want to write things that are easy for people to follow without having to go look up other sources. Or if they do have to look up another source, I have it listed right there. I want to make things that are not assuming that there’s already prior knowledge.

Cindy Ng: Thank you so much for sharing with me, with our listeners.

Roxy Dee: Thank you for letting me tell my story, and I hope that it’s helpful to people. I hope that people get some sort of inspiration, because I had a lot of struggles and, you know, there’s plenty of times I could have quit. And I just want to let people know that there are other ways of doing things and you don’t have to do something a certain way. You can do it the way that works for you.

 

Introducing Our New DataPrivilege API and a Preview of Our Upcoming GDPR Pa...

Introducing Our New DataPrivilege API and a Preview of Our Upcoming GDPR Patterns

GDPR Patterns Preview

We’re less than a year out from EU General Data Protection Regulation (GDPR) becoming law, and hearing that our customers are facing more pressure than ever to get their data security policies ready for the regulation.  To help enterprises quickly meet GDPR, we’re introducing GDPR Patterns with over 150 patterns of specific personal data that falls in the realm of GDPR, starting with patterns for 19 countries currently in the EU (including the UK).

Using the Data Classification Framework as a foundation, GDPR Patterns will enable organizations to discover regulated personal data: from national identification numbers to IBAN to blood type to credit card information. This means that you’ll be able to generate reports on GDPR applicable data: including permissions, open access, and stale data.  These patterns and classifications will help enterprises meet GDPR head on, building out security policy to monitor and alert on GDPR affected data.

Try it today and discover how you GDPR Patterns will help prepare you for 2018 and keep your data secure.

IAM & ITSM Integration with DataPrivilege

We’ve been talking a lot lately about unified strategies for data security and management, and the challenge of juggling multiple solutions to meet enterprise security needs.

DataPrivilege puts owners in charge of file shares, SharePoint sites, AD security and distribution groups by automating authorization requests, entitlement reviews and more. DataPrivilege now includes a new API so customers can take advantage of its capabilities by integrating with other technologies in the security ecosystem, like IAM (Identity and Access Management) and ITSM (IT Service Management) Solutions.

Our new DataPrivilege API provides more flexibility for IT and business users so they can unify and customize their user experience and workflows. With the API, you’ll be able to synchronize managed data with your IAM/ITSM solution and return instructions to DataPrivilege to execute and report on requests and access control changes.  You’ll be able to use the integration to externally control DataPrivilege entitlement reviews, self-service access workflows, ownership assignment, and more.

Ask for a demo and see how it works with your current set up.

 

Working With Windows Local Administrator Accounts, Part II

Working With Windows Local Administrator Accounts, Part II

Before we delve into Restricted Groups, I thought it might be worthwhile to take a closer look at how hackers take advantage of Administrator passwords. For Pass-the-Hash fans, this post will show you how hashes can be used even with local accounts. I also had a chance to try Windows Local Administrator Passwords Solution or LAPS. Spoiler alert: LAPS scares me a little.

Passing Local Hashes

After writing the first post, I realized that you don’t necessarily need hashes of domain accounts. In fact, Windows also stores the hashes of local accounts in its Security Accounts Manager (SAM) database. Hash dumping tools such as crackmapexec and mimikatz let you view these hashes.

This leads to a more direct lateral movement tactic. As I pointed out last time, it is not unusual for local Administrator accounts to have exactly the same password on more than one machine. This would also mean the NTLM hashes would be the same as well.

Let’s say a hacker gains access to a server, and assuming he has enough privileges, then uses mimikatz to see if a local Administrator account is available. He can then try an experiment and pass the Administrator hash into, say, psexec to pop a shell on another server and gain Administrator privileges there as well.

You see what I’m getting at?  If you assume that Administrator passwords are the same on different machines, then you’re no longer dependent on a domain-level user to have left a hash in the LSASS memory of that box. This post explains more about LSASS if you’re confused by the last sentence.

On the other hand, the local user hashes are always there! Being a hacker or pen tester means that you’re always testing different ideas and playing the odds. So let’s go for broke!

Back in my Acme domain, I set the same local Administrator password on both my Masa and Taco servers – Taco is also my domain controller. In this scenario, I’m already on Masa, I’ve uploaded mimikatz and psexec.

By the way, both these tools have source code, so it wouldn’t be that difficult to make them fully undetectable after a few tweaks.

I was now flying under the radar on Masa, but couldn’t find anything interesting there. To begin my lateral move, I loaded mimikatz and dumped the hashes with the lsadump::samcommand.

Assuming that Taco also has the same Administrator password, I then use sekurlsa:pth to launch psexec and gain a shell on Taco (below).

Just try passing-the-hash with the local Administrator account. What do you have to lose?

Amazing!

When I changed the Taco Administrator’s password, this ploy didn’t work, and psexec was unable to pop a shell.

Lesson learned: it’s good idea to have different Administrator passwords.

LAPS and Aspirin

If you’re going to keep the local Administrator passwords, then you need to manage them. As I wrote about last time, these accounts can be disabled, and Restricted Groups can be used to delegate Administrator privileges to domain-level accounts.

In any case, people still want these local accounts. Microsoft apparently heard the collective cry of IT administrators, and in 2015 they released their Local Administrator Passwords Solution. It’s described with these words: “…solution to the issue of using a common local account with an identical password on every computer in a domain. LAPS resolves this issue by setting a different, random password for the common local administrator account on every computer in the domain.”

Seems simple. However as we’ve noted before,  Microsoft never, ever does anything nice and easy.

The first tip off was the LAPS architecture (see below).

Plans for the invasion of Mars.

Hmm, there is a client and server side to this. The documentation also indicates PowerShell scripts have to be run, and then there’s something about changing the Active Directory schema.

I boldly took the LAPS challenge and went as far as I could with the installation before the pounding in my head got to me.

This is not an easy install. LAPS is loaded onto your domain controller as well as on client computers that you want managed. Yeah, you use the Group Management Console to push out LAPS to the clients.

If you do the installation correctly, you’ll see the following interface pop up when you navigate in the GPO editor to Computer Configuration>Administrative Templates>LAPS.

I was afraid to pull the trigger on this. In theory, LAPS generates random passwords that are now centrally located on Active Directory in a new attribute as plaintext — that’s why you needed to update the AD schema.

Some security pros have pointed out that LAPS may, ahem, have its own problems. Essentially, you’re shifting the problem from local computers to Active Directory.

Back to Restricted Groups

After returning from my LAPS detour, I began to see Restricted Groups as the most practical way to manage local Administrator accounts. I started on this process in the previous post when I created a new AD group called Acme-IT, which then was pushed out and placed under the local Administrators group for each machine in the Acme domain

It’s a neat trick, and Restricted Groups allow IT to centrally control local Administrator access.

It would even be neater if I could segment my domain so that one group of users would be local Administrators for a subset of machines, and another group would control a different subset –creating as many sub-groupings as needed.

Otherwise, I’d fall into the trap of allowing a small group of users to have local Administrator access to the entire domain! No bueno.

And that’s where Organizational Units (OUs) come into play. It’s a way to divide up the domain so that you can associate specific GPOs with each OU subgroup.

You first set up these OU sub-divisions in Active Directory Users and Computer (below). For each OU, I assigned a subset of the domain’s computers. In my scenario, Acme-1 is associated with the Masa and Pimiento servers, and Acme-2 is associated with Taco, the domain controller.

Two new OUs join the Acme domain: Acme-1 and Acme-2.

I also had to remember to create Active Directory groups that will be associated with each of these OUs — Acme-IT-1 and  Acme-IT-2.

Now when I’m back in the Group Management Console, these OUs show up under the Acme domain (below). I added a Restricted Groups policy under each OU, making sure that the appropriate AD groups were used.

The OU payoff: segmented GPO policies!

It’s simpler than it sounds. In short: I’m enabling members of Acme-IT-1 to be an Administrator for Masa and Pimiento, and Acme-IT-2 members for Taco.

We’ll finish up this incredibly exciting topic in the next post and, as always, I’ll have a few closing thoughts. In the meantime, take a few aspirins for getting this far in the series.

 

Continue reading the next post in "Working With Local Administrator Accounts"

Working With Windows Local Administrator Accounts, Part I

Working With Windows Local Administrator Accounts, Part I

In writing about hackers and their techniques, the issue of Windows local Administrator accounts often comes up. Prior to Windows 7, the Administrator account was created by default with no password. This was not a good security practice, and hackers have been taking advantage ever since.

Starting in Windows 7, the local Administrator accounts were disabled by default. And you should disable them in your domain regardless of which Windows OS you have! But for various reasons, some of them based on mistaken ideas, the local Administrator accounts hang around on many installations. They’ve too often been given easily guessable passwords by IT, and sometimes the same password across large parts of the domain.

If hackers can get a foothold on the system, they’ll look for this privileged local Administrator account as part of their evil checklist. They’ll then try to use these accounts as they start the lateral movement phase of their post-exploitation.

In short: they guess the local Administrator’s account password, grab the hashes of domain-level users with mimikatz, and then move around the network.

But I Need It!

Or they may not even have to grab hashes of domain-level users. In many environments, the local Administrator account passwords themselves are set using the same pattern: once you guess one, you can figure out the whole shebang.

In the real world, you may have to deal with IT staff arguing the Administrator accounts need to be available — perhaps because processes or software is dependent on their existence.

Is there a way to keep the Administrator accounts but lessen their power?

Microsoft has a few recommendations on how to secure them. Essentially, you configure a Group Policy Object (GPO) to disable network access, remote desktop, and a few other services through User Rights Assignment.

Enabling “deny access to this computer from the network” in the User Rights Assignment GPO.

Just to see this how would work, I went back to my now famous Acme domain that I set up up in Amazon Web Services.

Let’s assume passwords for Acme’s local Administrator accounts are based on a pattern — the server name followed by a numeric sequence — as a memory convenience for the beleaguered IT staff.

In my pretend scenario, I used the vanilla psexec utility — which by the way played a part in the recent NotPetya ransomware outbreak — to laterally move to the Taco server. Putting on my pen-testing hat, I entered my guess for the Administrator password to Taco, and miraculously it worked.

You can see the results of my psexec activities below before I set the “deny network access” GPO.

Taking advantage of silly Administrator passwords with psexec.

After I set the GPO, the psexec utility complained that my user name or password was invalid — User Rights Assignment was doing its job. If you’re trying this at home, remember to run gpupdate /forceon the domain controller to trigger the GPOs to sync to all the domain members.

This is a compromise solution that lets you keep the local Administrator accounts but prevents hackers from easily exploiting them to move around the network.

Don’t Change Passwords With Group Policy Preferences

The right thing to do is to disable the local Administrator, and then set up domain-level groups with restricted privileges under the local Administrators group. We’ll start discussing how to do this further below.

But let’s say your heart is set on keeping these local Administrator accounts; you realize the passwords were set for convenience (and not for security);  and you now want to improve the passwords on a global level.

Once upon a time, Microsoft introduced Group Policy Preferences (GPP) in Windows server 2008 to extend GPP. One of the new GPP capabilities allowed you to update user and group information on a domain basis.  At one point, you were allowed to change passwords and then push out the updated passwords across the domain

However, hackers found a major vulnerability in GPP’s  password distribution process. While Windows encrypted the password, they released — duh! — the encryption key in their technical documentation.

They’ve since put out a patch for it, and in the AWS instance I was most recently working with, the password entry was disabled — it’s grayed out in the graphic below.

In my AWS environment, the GPP feature for updating passwords is disabled. You may not be so lucky.

However, early on in my experimenting I launched an unpatched AWS instance, where I was able to enter the password. And sure enough I could pull up the AES-encrypted password from the SYSVOL folder.

And there are no doubt many more servers out in this world without the GPP patch. In fact, pen testing utilities such as crackmapexec search for encrypted passwords — see the -gpp-passwords option — in the SYSVOL folder and then conveniently decrypts them.

Thankfully, Microsoft came out with another way to do bulk updates of Administrator passwords, giving it the catchy name of Local Administrator Password Solution, or LAPS. You can download it here. I plan on giving it a try, and I’ll let you know the results.

Restricted Groups

The better way to handle local Administrator accounts is through the Restricted Groups GPO, found under Computer Configuration > Policies > Windows Settings> Security Settings. This GPO manages the local Administrators group by letting you add a domain-level group under it and then pushing the changes out across the domain. In short: you have a special group of users that’s centrally controlled with just the privileges to do the local administrative work they need.

For my Acme domain, I delegated local Administrator powers to the Acme-IT group (below).

Restricted Groups! Control local Administrators across the domain in one swoop.

There are additional subtleties in working with Restricted Groups that we’ll get to next time. And we’ll also take up Organizational Units or OUs, which gives us the power to segment the domain and improve the security of our Restricted Groups.

 

Continue reading the next post in "Working With Local Administrator Accounts"

How to Better Structure AWS S3 Security

How to Better Structure AWS S3 Security

If the new IT intern suggests that you install a publicly accessible web server on your core file server – you might suggest that they be fired.

If they give up on that, but instead decide to dump the reports issuing from your highly sensitive data warehouse jobs to your webserver – they’d definitely be fired.

But things aren’t always so clear in the brave new world of the cloud – where services like Amazon’s Simple Storage Service (S3), which performs multiple, often overlapping roles in an application stack, is always one click away from exposing your sensitive files online.

Cloud storage services are now more than merely “a place to keep a file” – they often serve as both inputs and outputs to more elaborate chains of processes. The end result of all of this is the recent spate of high profile data breaches that have stemmed from S3 buckets.

An S3 Bucket Primer

S3 is one of the core services within AWS. Conceptually, it’s similar to an infinitely large file server at a remote site or a FTP server that you’re connecting to from across the Internet.

However, S3 differs in a few fundamental ways that are important to understand: failing to do so will trip you up and may result in insecure configurations.

S3 is organized around the concepts of Buckets and Objects, instead of servers with files.

Buckets are the top level organizational resource within S3 and are always assigned a DNS addressable name. Ex: http://MyCompanyBucket.s3.amazonaws.com

This might trick you into thinking of a bucket like a server, where you might create multiple hierarchies within a shared folder for each group that needs access within your organization.

Here’s the thing:

  • There’s no cost difference between creating 1 bucket and a dozen
  • By default you’re limited to a 100 buckets, but getting more is as simple as making a support request.
  • There is no performance difference between accessing a 100 files on one bucket or 1 file in a 100 different buckets.

With these facts in mind, we need to steal a concept from computer science class: the Single Responsibility Principle.

Within a network, a file server is a general resource typically used by lots of different departments for all kinds of work.

S3 allows you to devote a bucket to each individual application, group or even an individual user doing work. For security (and your sanity as a sysadmin) you want the usage of that bucket to be as narrowly aligned as possible and devoted to a single task.

A significant number of the unintentional data exposure incidents on S3 appear to have been caused by public facing S3 buckets (for websites) that were also (likely accidently) used for the storage of sensitive information.

Sidebar: A warning sign is often found in the bucket naming. Generic, general names like: ‘mycompany’ or ‘data-store’ are asking for trouble. Ideally you should establish a naming convention like: companyname-production/staging/development-applicationname

Bucket Policies

Policies are the top level permission structures for buckets. They define:

  • Who can access a bucket (what users/principals)
  • How they can access it (http only, using MFA)
  • Where they can access it from (a Virtual Private Cloud, specific IP)

Policies are defined in blocks of JSON that you can either write by hand or use AWS’s Policy Generator – https://awspolicygen.s3.amazonaws.com/policygen.html – to create.

Benefit #1 of organizing your buckets into narrowly defined roles: your bucket policies will be an order of magnitude simpler, since you won’t have to try to puzzle out conflicting policy statements or even just read through (up to 20kb!) of JSON to try and reason out the implications of a change.

Example Bucket Policy



{
  "Version": "2012-10-17",
  "Id": "S3PolicyId1",
  "Statement": [
    {
      "Sid": "IPAllow",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::examplebucket/*",
      "Condition": {
         "IpAddress": {"aws:SourceIp": "54.240.143.0/24"},
         "NotIpAddress": {"aws:SourceIp": "54.240.143.188/32"} 
      } 
    } 
  ]
}

Narrow buckets mean simpler policies, which in turn mean less likelihood of accidentally over permissioning users – and unintentionally creating a data breach.

Think of Bucket Policies as how the data should be treated.

IAM Policies in S3

Identity and Access Management IAM policies, on the other hand, are all about what rights a user/group has to a resource in AWS (not just S3).

You can apply both IAM and Bucket policies simultaneously: access attempts will calculate the least privilege union of the two policies and take action accordingly.

Further Reading: IAM Policies and Bucket Policies and ACLs! Oh, My!

VPC Endpoints in S3

A very powerful, but often underutilized tool in securing AWS services is to divide applications into different logically separated application groups inside of a Virtual Private Cloud.

On a grander scale than simply designating a bucket for a particular purpose, a VPC is a logically separated set of Amazon Web Services (including S3) that can be cordoned off for greater security.

Most of the large databreaches that have surfaced regarding groups using S3 have NOT been website related. Organizations are using a variety of AWS’s tools like RedShift and Quicksite to do analysis of massive amounts of (potentially) sensitive data: analysis, reports and raw data that should not be placed on a public network.

The tool of choice to separate this is AWS’s Virtual Private Cloud. With VPC you can define a set of services that will be unable to connect to the general Internet, and only be accessible via a VPN (IPSEC) connection into the VPC.

Think of a VPN connected VPC as a separate section of your internal network – and resources like S3 within the VPC aren’t publicly addressable:

  • A bot scanning for open buckets won’t be able to see them.
  • Your new data scientist can’t accidently leave a bucket publicly accessible because they were trying to download a report.
  • Day to day users of the services don’t have to try and figure out if their actions will cause chaos and destruction.

Enable S3 Logging

By default, S3 doesn’t maintain access logs for objects (files) in a bucket. On a per bucket basis you can enable access logs to write to another S3 bucket.

http://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html

Reviewing access periodically can give you great insight into if your data is being accessed from an unknown location, or in the case of a data breach, how and when exfiltration occurred.

S3 stores raw logs to the logging bucket where you can parse them with a number of different open source tools, like:



More recently, AWS Athena was launched. It’s a new service that lets you directly run SQL queries against structured data sources like JSON, CSV and log files stored in S3.

In Conclusion

AWS S3 is a powerful and extremely useful service that increases the capabilities of IT and application groups. Properly administered, it can be a safe and powerful tool for data storage and as the base of more complex applications.

Steps to keep your data secure on AWS S3:

  1. Review which of your S3 buckets are open to the public internet
  2. Split S3 Buckets to 1 per application or module
  3. Separate concerns with VPC S3 Endpoints
  4. Log everything

[Podcast] Blackhat Briefings That Will Add to Your Tool Belt

[Podcast] Blackhat Briefings That Will Add to Your Tool Belt

Leave a review for our podcast & we'll send you a pack of infosec cards.


We’re counting down to Blackhat USA to attend one of the world’s leading information security conference to learn about the latest research, development and trends.

We’ll also be at booth #965 handing out fabulous fidget spinners and showcasing all of our solutions that will help you protect your data from insider threats and cyberattacks.

In this podcast episode, we discussed not only sessions you should attend, but also questions to ask that will help you reduce risk. We even covered why it isn’t wise to only rely on important research methods like honeypots save you from insider threats or other attacks.

Tool of the Week: Virtual Private Cloud (VPC)

Panelists: Kris Keyser, Kilian Englert, Mike Buckbee

Global Manufacturer Relies on DatAdvantage as it Moves to the Cloud

Global Manufacturer Relies on DatAdvantage as it Moves to the Cloud

Dayton Superior is a leading manufacturer for the non-residential concrete construction industry. With thousands of products used in more than one million buildings, bridges and other structures worldwide, Dayton Superior has an ongoing need to monitor and protect information on its network.

The Ohio-based company first began using DatAdvantage several years ago after a major acquisition in which company’s employees were merged into a single IT environment. DatAdvantage gave Dayton Superior deep visibility into the files on their network. For the first time, the company could locate missing files and lock down access to individual users, departments or project teams.

Now, nearly seven years after Dayton Superior first turned to Varonis for insight into its on-premises IT systems, the company will be using DatAdvantage for their new cloud-based environment with Microsoft Office 365 OneDrive for Business and SharePoint.

By moving to the cloud, Dayton Superior aims to decrease its need for internal storage while providing employees with flexible access to documentation from remote devices. Once the migration is complete, DatAdvantage will continue to help the company monitor activity, track user behavior, and control user access to files on the network.

 

Click here to read the full case study