Tuesday, December 24, 2013

T'was The Scan Before Christmas

Twas the scan before Christmas, when all through the NOCs
Not an admin was patching, not even for SOX.
The cat5 was strung up in beautiful spindles,
As the hope it would stay that way quickly dwindles.

The servers were nestled all snug in their racks,
While disks hummed and lights flashed on jacks.
The sysadmin in his Tux shirt, and I in my cap,
Had just hyped up on coffee to stave off a nap.

When on the monitoring screen arose such a clatter,
I turned just slightly to see what was the matter.
Away to my command prompt I typed in a flash,
Right-click, open, come to me bash.

I panic, I sweat, the desk meets my head,
What piece of shit did they successfully embed.
When, what to my wondering eyes should appear,
But a dude with no pants on, it was perfectly clear.

With a high-gain antenna along for his quest,
I knew in a moment it was a pentest.
More rapid than fiber his fingers did fly,
A grumble he made, the jr. admin starts to cry.

Now APT! Now phish! Now, vuln and attack!
On HIV! On, encrypt! On, cyber and crack!
To Hell we must go! Turn up the dubstep!
To deal with the vendors, cope with inept!

As the time comes around to check mark the boxes,
To keep vendors happy, those damn sly foxes.
So on to the testing, start up the scan,
Lets punch some holes in that software tincan.

And then, in a twinkling, I heard in his voice,
Spearfishing will be my method of choice.
As I drew in my head, and was turning around,
His eyes said don't worry, just CTF down.

He now spent time waiting, biding his time,
For what he had set was a victimless crime.
A shell he had wanted, now shown on his screen,
His face had lit up like an excited pre-teen.

His eyes-how they twinkled! His neck-beard so hairy!
His legs were so placid, his name, maybe Gary?
His teeth were clenched in a victory smile,
As he exported his findings to an ascii text file.

The scope he was given, made him laugh just a bit,
POS systems are not something to omit.
But write his report he shall do with a grin,
Oh, your whole network, the places he's been!

Default creds, sa password, and local admin,
PCI data, HIPAA, and click to login.
Metasploit helped with a bit of SET magic,
The board's quote? "This is fucking tragic."

He said no worries, we're here to help you out,
This place will be cleaned, beyond any doubt.
To defcon, derbycon, shmoocon you'll go,
Oh, all the wonderful things you'll now know!

He left in a fluster, red team let's leave!
These admins need some good time to greive.
But I heard him exclaim, ‘ere he stomped out of sight,
Pwny Christmas to all, and to all a good fight!

(What happens when I work on Christmas Eve)

Thursday, December 5, 2013

Internal Social Engineering Documents

So I know it's not pretty, but I'll work on that later. I've added a second "Downloads" page linked to my Google Drive. These are documents that I've worked on for our internal Social Engineering and Training program. The program is still being developed, but I've stripped out all of our company headers and info so you can customize as you wish.

Friday, November 29, 2013

Mapping drives with Group Policy to a DFS Target that is using ABE

This blog post is something that we'll be migrating towards to fix several annoyances that I have with our infrastructure. We have one giant clusterfuck of login scripts here. At a certain point someone thought it would be a great idea to give every AD user their own to map drives with and not standardize anything. We also have WAY too many file servers with user and department drives. Combination of clustered/standalone, physical/virtual, windows 2003/2008/2008R2. We'll be moving away from all of them to groups of DFS namespaces. I've created two servers DFS01 and DFS02. They will be housing the Depts DFS namespace on their E: drives. After all department drives have been moved over, we will also have a set for home drives, and certain areas that would need their own.

The Design:

Using the GPO over all of my users I entered in a drive mapping to the DFS namespace with Item-level targeting. We have many people that need access to more than one department drive, so why use up drive letters needlessly? When these department drives were mapped I didn't want anyone to see a department they either weren't a member of or didn't manage. The department drive will be the T: mapped drive for everyone, company wide, and the departments you need to view will show up based on what AD security group you are a member of. Everything will be setup for growth, using best practices. No more adding user accounts to shares and NTFS permissions, or file servers crashing and preventing logins for hours, or a 3TB clustered file server decide it wants to chkdsk in the middle of the day, should I go on? no? fine then.....


  1. Install DFS - It's a Role Service under File Services. If you are unsure how to do this, google it, or wing it. It's not that bad.
  2. On the E: drive I created two folders "DFS" and "Shares". I've shared "Shares" as Shares$ with Authenticated Users having Read NTFS permission.

File Share Creation:

  1. Navigate to your "Shares" folder and create your first folder that you plan on mapping DFS to. In this example I have created a BusAnalysts folder that only has Admins and the DFS-BusAnalyst security group in AD as read/change for NTFS permissions. I'll also follow the same structure to create a CareMgmt folder to show that one will show up and the other won't later on when ABE has been finished.

Distributed File Servers and Access-Based Enumeration:

  1. Open up DFS Management
  2. Right-click on Namespaces and select "New Namespace"
  3. Enter the Name of your DFS Server, ours is listed as DFS-SERVER01, and in later screenshots is changed to a blurry spot DFS01.
  4. Now select your DFS name, ours will be "Depts".
  5. Select Edit Settings. The local path of the shared folder needs to point to the DFS folder that was created in step 2. The default points to the C: drive, and that's not what you want. The permissions will be set to the same (Everyone removed, & Authenticated Users = Read) under Customize. Click "OK">"OK">"Next".
  6. Select the defaults on the next screen and then "Next".
  7. Verify all the information is correct and click "Create" then "Close".
  8. Next we have to enable ABE. Right-click on your namespace go to Properties>Advanced and select "Enable access-based enumeration for this namespace" and "OK".
  9. Now create a new DFS Folder that will map to your shared sub-folder. The preview of the namespace should be pointed to where you specified in step 5, and will show up as a shortcut in that folder when you view it on the server. The folder targets should be pointing to the folder under Shares$. Click "OK".
  10. This is the part that pretty much eluded me for a week or so. I guess I just assumed ABE would pick up and do the right thing without any additional intervention.... WRONG!!   soooo Right-click on your newly created DFS folder and go to Properties>Advanced> and select the "Set explicit view permissions on the DFS folder" radio button. Add your specific DFS group to be able to see this DFS target, in this case it's DFS-BusAnalyst. I'll do the same thing for the CareMgmt folder as well as every other DFS folder that is added.

Group Policy Drive Mapping:

  1. In the proper GPO (where your users are located) navigate to User Configuration>Preferences>Windows Settings>Drive Maps to create a new drive mapping.
  2. The location will be the DFS target, in this case it's \\domain.local\depts, I've labeled it as "Department Drive", and I'm using the T: drive.
  3. Navigate to the Common tab and select "Item-level Targeting".
  4. Under "Targeting" we'll want a rule saying that it will apply to any user that is in a certain security group. Our naming convention will be DM(drive map)-ABCD(company name)-DFS-DEPT. So as long as you are in the DM-ABCD-DFS-DEPT you will have a T: drive mapped to //domain.local/depts when you login.

And we're done! On our way to becoming that much more organized :)

Friday, September 6, 2013

Cisco SNMP v3 settings for PacketFence using clogin via Rancid

First off, could I really fit any more key words into the post title?

Secondly, I'm fairly new to scripting and linux in general. So forgive me if I get some terms or other stuff way wrong. I've recently been tasked with setting up a NAC (Network Access Control) for our network. We're starting small, only conference rooms at first. We have around 40 or so conference rooms, I think.... The goal is to use PacketFence by Inverse to allow guests and vendors access to our guest network, and employees access to our internal network.

PF will allow you to push switch vlan changes via snmp, but one of the big hurdles for me was the SNMP v3 setup since I've never set it up before. After figuring it out on a single switch I realized that I didn't want to manually make changes to all of our Cisco switches. Which lead me to clogin that comes with Rancid (Really Awesome New Cisco confIg Differ). clogin will allow you to make multiple changes using a command file to the switch(es) of your choosing.

Third, I hope you enjoy my liberal use of smudgery.

Step 1: Install Rancid: http://www.shrubbery.net/rancid/RhysEvans_overview_0.3.pdf
Step 2: Setup switch in PF:

Step 3: Setup the .cloginrc file
This file (under root) holds all of the usernames/passwords that clogin will use when attempting to auth to a device. We use ssh on everything and setup a TACACS account specifically for packetfence testing. This is what I've added to the bottom of ./cloginrc

add user * {PFTestAccount}
add userpassword * {TermPassword} {EnablePassword}
add password * {TermPassword} {EnablePassword}
add method * ssh telnet

Step 4: Send global switch commands via clogin. In the default setup clogin is located under /usr/local/rancid/bin and must be ran as the user rancid if you've followed the instructions above.

Global commands, saved in SNMPv3.txt:

snmp-server engineID local 123450000000000000000000
snmp-server group PFREADGROUP v3 priv notify *tv.00000000.00000000.00000000.0
snmp-server group PFWRITEGROUP v3 priv read PFREADVIEW write PFWRITEVIEW
snmp-server community PFREADWRITESTRING RW
snmp-server enable traps port-security
snmp-server enable traps port-security trap-rate 2
snmp-server host 172.16.x.x OtherCorpReadOnlyString
snmp-server host 172.16.x.y version 3 priv PFREADUSER port-security

Clogin command: 

 ./clogin -x /usr/local/rancid/scripts/SNMPv3.txt 172.16.x.y


Step 5: Interface config:
Now there are a couple ways we could go with this. We could include this config in with clogin as long as we could pick the same port on ever switch. I have yet to find a way to prompt for each switch with my limited knowledge. Or the way I'll be doing it, going through and finding out which port on which switch I need setup, and creating a different command file for clogin to pull from. It's probably not the best way, but still better than logging manually into each switch and running every command.

## mac-address should follow this format: fa0/1...fa0/48 = 10001...10048
## or gi0/1.....gi0/48 = 10101....10148
## vlan 311 is the PF Registration vlan

int fa1/0/46
 switchport access vlan 311
 switchport mode access
 switchport port-security maximum 2 vlan access
 switchport port-security
 switchport port-security violation restrict
 switchport port-security mac-address 0200.0001.0046 vlan access

Wednesday, August 14, 2013

1-2-3 SET

So yesterday was my second SE campaign to enlighten a subset of our users. Here is a n00b's guide written by a self proclaimed n00b....


So using The Social Engineering Toolkit has been most of my hands-on knowledge when it comes to anything SE. I've only been using it for around 8 months at this point, and I've learned a little bit. When our company decided that it would be too expensive for regular user training we decided to try and make things interesting instead. The plan is still forming, but we've gotten good feedback so far.

The Plan:

The idea is to run a blatantly obvious SE attempt at a subset of users each month from a gmail account. I made the account ourITdepartment@gmail.com. SET will allow you to auth to gmail to send out the campaign email. The targets will receive a plain html email with a link that takes them to a credential harvester embedded in a cloned website of my choosing. After we obtain their credentials this is what they see:

This slideshow takes them through some normal "don't click shit" information, just in a professional format. I may upload the full slide deck, but it still needs a little work. As time goes on and we get less hits, we'll up the complexity.

First Attempt:

Using ./theHarvester.py from Marcus Carey (@marcusjcarey) I scanned for our domain to pull the first list of users, which got me about 50.

./theHarvester.py -d mydomain.com -l 500 -b google

Every year we fill out an employee survey with a third party company. Since we had just completed it I figured an email about the survey results being in would yield a good hit rate.

The link took them to a clone of Survey Monkey's login page. Which yielded a surprising 15/50 credentials being harvested, 3/50 reports of a suspicious email to our helpdesk, and 1 call from a nurse letting us know that she no longer has any respect for us and has lost our trust.

Second Attempt:

To gather a list of users that are more likely to be targeted from the outside we have an active sender list on our postfix mail filtering box. There are about 600 or so that normally get email from outside addresses, out of the 1,400 total mailboxes we have. I took the first 200 this month and will continue on until everyone has been hit with an easy campaign.

At the beginning of the year we switched to an HR system "in the cloud" that uses AD Federated Services to auth our users. I figured a clone of that site would work well, accompanied with this email.

So far we are at 47/200 and they are still rolling in.

1-2-3 SET:

What Comes Next?
So we're currently working on a database to bind to MS Active Directory and store the results of each month. It would allow us to run reports on most phished users, who each campaign hits, etc. All the data from the xml report will be pulled in also.

Wednesday, August 7, 2013

ldap on Apache to MS Active Directory

So I've recently struggled with ldap syntax in several different programs. Most recently I have setup viewvc on a Centos box to see config diffs easier in RANCID. After going around and around, knowing that I've done this in the past and struggled. I finally figured I should have a central repository for all the random things that I do and forget. So here it is. Part of my httpd.conf that allows for ldap to MS Active Directory.

I have yet to understand why some things have quotes and some don't....but it works...so whatever

<Directory "/var/www/cgi-bin">
    AllowOverride None
    Order allow,deny
    Allow from all

<Location "/">
    AuthType Basic
    AuthName "Whatever You Want Here"
    AuthBasicProvider ldap
    AuthzLDAPAuthoritative off
    AuthLDAPBindDN "CN=ldapuser,OU=Service Accounts,OU=IT,OU=Users,DC=domain,DC=local"
    AuthLDAPBindPassword "InsertPasswordHere"
    AuthLDAPURL "ldap://domain.local/OU=IT,OU=Users,DC=domain,DC=local?sAMAccountName?sub?(objectClass=*)"
    Require ldap-group CN=GroupNameHere,CN=Users,DC=domain,DC=local

Hello World

Creating this blog to document some of the practices, procedures, and tech solutions that I've put into place working in Healthcare IT and IT in general.

I'm a n00b at a lot of things, especially anything *nix related. But through Twitter, Vimeo, and a load of other online help I'm getting a little smarter. One step at a time. :)

You can follow me on Twitter @Infosystir