Honey Accounts

I recently saw a tweet mentioning the use of an AD account with the password in the description attribute and logon hours set to none. I can’t find that tweet anymore so I apologize for the lack of attribution.

The idea is that when someone does breach your network perimeter, some of the first steps in performing recon is collecting information from Active Directory. In this recon, they stumble on a DA account called ‘helpdeskDA’. They even discover a password in the description! Well this looks like an easy win and a critical finding. In order to figure out how to leverage this new found user, the attacker attempts to RDP or use psexec to move to a higher value target. In doing so, AD checks the credentials and returns to the attacker that his newfound account is not allowed to login during this time. Meanwhile, this login attempt has triggered an alert and is being investigated.

I personally love security tools that aren’t just blinky lights and can run natively on devices we already possess. I took a stab at setting this up in my test environment

Setting up the AD Account:

  1. Create your new account in AD Users and Groups and add to the Domain Administrators group.
  2. Set the user description to something believable or just set the password in there and let the attacker make their own assumptions.

  1. Go to the Account tab and select Logon Hours…
  2. Set Logon Denied to 24×7

Q:\Restricted\SECURITY\Application Security Analyst\HoneyAccounts\AD\login.png

Group Policy:

There are a couple Group Policy options that need to be enabled in order for this to work. Depending on your organization, these are already configured.

  1. Edit the Default Domain Policy.

  1. Navigate to: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> Account Logon -> Audit Kerberos Authentication Services and set to audit Failure events.

Q:\Restricted\SECURITY\Application Security Analyst\HoneyAccounts\GP\gp_config1.png

Don’t forget to update group policy on the client by running: gpupdate /force

Event Viewer:

Here is an example of what the event now looks like in Event Viewer.

Q:\Restricted\SECURITY\Application Security Analyst\HoneyAccounts\EventViewer\eventLog.png

And here is the XML view with more details, this is important for writing our event trigger in Task Scheduler. Note the event ID. A normal failed login is event ID 4625. However, since this won’t be a traditional failed login due to the login hours, it falls under 4768 which indicates that the Kerberos authentication ticket was requested and failed due to various reasons, in this case the logon hours.

Q:\Restricted\SECURITY\Application Security Analyst\HoneyAccounts\EventViewer\eventDetails.png

Task Scheduler:

Configuring the task scheduler took a bit of time. This is due to the way the event was logged. Since it is not the traditional 4625 failed login event, the event trigger based on User did not work. I had to write a custom XML trigger rule to catch the username in this context.

  1. Open Task Scheduler and create a new task. Name it whatever you like and make sure to select ‘Run whether user is logged on or not’.

Q:\Restricted\SECURITY\Application Security Analyst\HoneyAccounts\TaskSched\step1_CreateTask.png

  1. Move to the trigger tab and edit trigger.

Q:\Restricted\SECURITY\Application Security Analyst\HoneyAccounts\TaskSched\step2_NewTrigger-Custom.png

  1. Select New Event Filter and select the XML tab. Check Edit query manually. Modify the following query to fit your user and domain. Since we don’t know what username format the attacker will use, we need some OR statements in there to cover our bases. Typically, we could use the SID but in Event 4678, it is not logged. You can also add granularity and only log on certain events but in this case, I thought it best to alert on any account activity.

Q:\Restricted\SECURITY\Application Security Analyst\HoneyAccounts\TaskSched\step3_EventCustomFilter.png

  1. You should be able to save that and move to the Action tab. You can do whatever sort of event here that you like. I chose a powershell script that alerts various people and provides details about the event.

Q:\Restricted\SECURITY\Application Security Analyst\HoneyAccounts\TaskSched\step4_actionEmail.png

  1. Select Start the task only if computer is on AC power.

Q:\Restricted\SECURITY\Application Security Analyst\HoneyAccounts\TaskSched\step5_conditionsTask.png

Powershell Script:

function sendMail{

Write-Host "Sending Email"

#SMTP server name

$smtpServer = "smtpserver"

#Creating a Mail object

$msg = new-object Net.Mail.MailMessage

#Creating SMTP server object

$smtp = new-object Net.Mail.SmtpClient($smtpServer)

$file = "C:\users\Administrator\Desktop\alert.txt"

$att = new-object Net.Mail.Attachment($file)

#Email structure

$msg.From = "[email protected]"

$msg.ReplyTo = "[email protected]"

$msg.To.Add("[email protected]")

$msg.To.Add("[email protected]")

$msg.subject = "ALERT:Honey Account"

$msg.body = "Honey Account Activity Detected"


#Sending email




function collectDetails{

 $attachment= Get-WinEvent -LogName "Security" -FilterXPath "*[EventData[(Data='[email protected]' or Data='ws_admin' or Data='SECURITY-DC\ws_admin')]]" | Format-List -Property * | Out-File C:\users\Administrator\Desktop\alert.txt


#Calling function



HTTP Security Headers

HTTP security headers seem to be findings on nearly every assessment I have been doing lately. I decided to come up with some handy quick references for these headers in order to better understand them. HTTP Response headers are a way for a server and client to exchange information. In this case, these headers are enforced to ensure that the client is protected from common client side vulnerabilities.


Content-Security-Policy – CSP is a HTTP security header that allows the web application to specify the source for any file that must be loaded from a separate domain. Its main use is to prevent cross-site scripting (XSS) and other injection techniques that load malicious data from an external source. An example of a CSP that restricts the source for all scripts, images and fonts would look like this:

Content-Security-Policy: default-src 'self'

If you were to add sources for other script, you could simply append the trusted domain. It even accepts wildcards for specifying subdomains.

Content-Security-Policy: default-src 'self' *.jordanpotti.com

You can get more granular and specify image-src, media-src, child-src and a host of other restrictions. You can also use report-uri in order to POST reports of policy failures to a URI of your choice. Here is an example of that:

Content-Security-Policy: default-src 'self' *.google.com ; report-uri https://errorcollector.jordanpotti.com/collection.php

Reporting these violations could give your developers diagnostic information as well as possibly alert you to a vulnerability or attempt to exploit a vulnerability.

Perhaps the most beneficial feature is CSP’s ability to prohibit inline JavaScript from executing. This prevents malicious code from being inserted into the page, the downside is that you now have to migrate all of you JavaScript to External Resources. Using External Resources is best practice so doing this increases your security as well as code cleanliness.

For more information on CSP, visit: https://content-security-policy.com/

Subresource Integrity:

Subresource Integrity – SRI is similar to CSP as it applies a layer of security to the scripts and other external data sources your application may use. SRI works by verifying the hash of an external data source before attempting to use it. This works by taking the hash of the external data and placing it in an ‘integrity’ attribute inside a <script> or <link> element. If the external data source inside that element do not match the provided integrity hash value, the resource is not loaded.

<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js" integrity="sha384-Tc5IQib027qvyjSMfHjOMaLkfuWVxZxUPnCJA7l2mCWNIpG9mGCD8wGNIcPD7Txa" crossorigin="anonymous"></script>

You can also use Content-Security-Policy to require that all scripts run have Subresource Integrity set in order to run. Applying this to our last CSP policy, it would look like this:

Content-Security-Policy: default-src 'self' *.google.com ; report-uri https://errorcollector.jordanpotti.com/collection.php ; require-sri-for script;

For more information on SRI, visit: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

CroSs Origin Resource Sharing

CORS is a way for applications to access resources not stored locally. CORS aims at scaling back the restrictions of the same-origin policy in order to allow the legitimate sharing of web resources.  In the above sample for SRI, we used crossorigin=”anonymous”, this specifies that this resource can be accessed without providing credentials.

The most basic CORS request are simple, they consist of the request to the resources from the client, and a response stating the resource it is requesting, the typical headers as well as a Origin header. The Origin header is similar to the Referrer header except that is has less information. For example, the Referrer header states the entire path and the Origin header only states the server name. When the server receives the CORS request, it verifies if the Origin is allowed. If it is allowed, Access-Control-Allow-Origin is set as a response header.

Access-Control-Allow-Origin: https://jordanpotti.com

When the browser receives the response, it verifies that server name sent back the browser in the new header matches the site the browser is visiting. Access-Control-Allow-Credentials also allows the passing of credentials through these requests in order to access to protected content. Some sites allow all by specifying a wild card ‘*’ for allowed Origins. This is a very dangerous practice and can open the door to a multitude of attacks.

To read more on the security of CORS, read this: http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html

For more information on CORS, visit: https://www.w3.org/TR/cors/


X-Frame-Options has a very specific purpose. It is used to prevent malicious iframe’s from loading on a site. In regards to other HTTP headers, it is fairly simple with only three directives. DENY, SAMEORIGIN, an ALLOW-FROM ‘domain’. This is to enforce the source of <iframe>, <frame> and <object>. The most common I have seen is SAMEORIGIN which enforces the source to come from the sites own domain.

X-Frame-Options: SAMEORIGIN or X-Frame-Options: ALLOW-FROM https://jordanpotti.com

For more information on X-Frame-Options, visit: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options


X-XSS-Protections is similar to X-Frame-Options in that it has a narrower scope than some other security headers. It has the ability to report violations, block a page from rendering is it detects a XSS attack as well as the ability to report only and not block. It has two main directives; 0 and 1. 0 disables XSS filtering and 1 enables it. If set to 1 with no other options, the browser will sanitize the page by removing the detected XSS portions. Adding mode=block will prevent the page from loading at all if XSS is detected.

X-XSS-Protection: 1; mode=block

For more information on X-XSS-Protection, visit: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection


X-Content-Type is a HTTP header that tells the server not to overwrite the response content-type. If the server specifies content as non-executable such as text/html, the browser will render it that way. It only has one option making it very easy to setup.

X-Content-Type-Options: nosniff

For more information on X-Content-Type-Options, visit: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options

HTTP Strict-Transport-Security

HSTS is a way for a server to tell the browser to always upgrade a connection to HTTPS. If set, any pages on that domain that only work over HTTP will no longer work.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

This specifies how long the browser should respect this header, it covers all sub-domains, and it also is eligible for being added to a browsers HSTS list. This will enforce HTTPS on your site even after the HSTS header is removed.

Visit: https://hstspreload.org/ to add your site to the HSTS hard-coded list.

For more information on HSTS, visit: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security


To view how your site rates, check: https://securityheaders.io/ . Scott Helme also has a pretty informative post on these headers as well so go check that out to learn more.



How I Gained Access to Nearly Half A Million College Transcripts

Last year I spent some time digging into bug bounty programs. Since I was quite new to the scene, I spent most of my time just figuring out how a lot of the tools worked, as well as figuring out a good process that worked for me. I spent loads of time in the Web Application Hackers Handbook and tried to figure out what looked normal, and what didn’t look normal.

My first bug however wasn’t from a bug bounty. It was on a massive university system. This system has collectively approximately 500,000 enrolled students at this time.

Now I do not recommend going bug hunting on a system that isn’t part of a bounty program or one that you do not have explicit authorization to do so.

I came across this bug sort of by accident. While I was checking my academic record, or my transcript, I noticed something strange. The URL had two suspicious parameters that seemed to be sequential and pre-fixed with the current days date. One was jobQSeqNo and the other was job_id. Out of curiosity, I tried to open the link in an incognito window, which stripped my cookies from the request. I still could see my transcript..

That seemed strange since the URL did not provide any sense of obscurity. Using Burp Intruder, I cycled the numbers in the two identified parameters and started seeing hundreds and hundreds of transcripts. It turns out there was no authentication checked on the page as well as easily guessable URL parameters. I immediately contacted the security team for the system and they responded and resolved the vulnerability quite quickly. Luckily they did not sue me and my transcripts are safe now. Win, Win. They were even okay with disclosing, which was quite surprising, so kudos to them.

Some of the information gleaned from someone’s transcript includes:

  • Student ID Number
  • Student Name
  • Degree
  • Courses Taken
  • Grades for Each Course
  • Total GPA

This information is protected by FERPA, in fact, at the bottom of each report, there was a FERPA statement.

Overall, there aren’t many technical details to include. It really consisted of some curiosity, Burp Intruder, and a list of 1000 sequential numbers.

Here are the Intruder results showing quite a few results:

How I Got Started in InfoSec

Lately there seems to be a huge movement to help get more people in infosec roles. I have been seeing more and more talks at cons regarding this topic as well as helpful blogs and other resources. There is even a project called InfoSec Mentors that helps put mentees in touch with mentors already in the infosec community. I think this is great and would have liked to have something like this earlier on in my pursuit of a career in infosec.

I want to share my story in the hopes that someone will be able to relate and maybe get some pointers. Since I am still a student who has recently accepted a job as an Application Security Analyst, I thought it would be nice to share how I am feeling about that as well as how I got here.

How I got here.. (tl;dr at the end of the post)

I began my path towards a career in IT in my late teens when I started an AAS in Network Administration. At that point, even an IT Helpdesk job was out of reach since I really didn’t know much. About a semester in, I saw an opening for a contract job helping a local hospital upgrade to Windows 7. I of course applied to this for some exposure and ended up working that contract for a couple months. The contracting company ran an IT services firm and ended up giving me a full-time job offer in their NOC (Network Operations Center). I honestly do not believe they hired me because I knew what I was doing. They hired me because they heard good things about me from the hospital I was contracted to work with. This is when I learned that hard work and a good attitude goes much further than raw knowledge.

I put a year or so into that NOC job where I learned the basics of System Administration. This job was fundamental in building a base of knowledge on how networks actually work vs perfect theoretical networks taught in school. While going to school and working in the NOC, I started participating in the CCDC (Collegiate Cyber Defense Competition). This taught me skills like teamwork and task management, as well as a great exposure to offensive security. The sysadmin experience even helped me more.

Shortly after I received my AAS in Network Administration, I received the CyberCorps: Scholarship For Service. I quit my NOC job and moved to a new location to get my BS in IT Security.

While pursuing my BS, I participated in CCDC and attended conferences such as DefCon. I got very interested in offensive security and spent a semester immersing myself in the PWK course and ended up getting my OSCP that same semester. I started a blog and wrote about things that interested me. I started digging around sites that had Bug Bounties. I began to study for my OSCE. I bought and read books like the Shell Coders Handbook, the Web App Hackers Handbook and Hacking: The Art of Exploitation. I spent hundreds of hours on security blogs.  I made a Twitter and began to follow infosec people. I reached out to potential employers with cover letters crafted specifically for the position I applied for.

Whatever niche you want to get into, I promise that if you demonstrate a passion for it, you will eventually get a job. This isn’t to say you won’t get ignored by potential employers, because you will. Most of the time, I never even got a reply or a phone call.

The cold shoulders pushed me to learn more, become better, show them that this is the path I want to take by demonstrating passion. A lot of people aren’t lucky enough to get a full ride scholarship that helps with extra costs for certs, books and conferences. I understand that and if that is the case for you, shoot for entry level IT jobs. My entry level IT jobs taught me more than I ever would have imagined. Consider it an extension of school, get your employer to help fund certs geared towards your desired niche, don’t worry about jobs going away, they aren’t. The IT security field needs people and there is a true shortage of qualified people. The jobs will be there today, tomorrow and in 5 years.

And at the end of the day, everything I did to get a job, isn’t going to stop once I have a job. It was never a chore to sit down and figure out how shellcode works, or figure out how nse scripts work or any of the things I have been doing for the past couple years. It’s a continuous learning process and if that scares you away, maybe this isn’t the career for you. If that excites you, then hop on the bandwagon and get started.

Now that I have a job, am I worried that I don’t know enough? Absolutely. I get the feeling that there were so many things they could have asked me in the interview process that would have “exposed” me. And the couple things I truly didn’t have the answer for, I admitted it. And I dwelled on those questions, probably way too much after the interview process. Guess what, admitting you don’t know something isn’t a deal breaker. No one knows everything. If you’re lucky, you will interview with a team that tries not to grill you with technical specifications like packet sizes and TCP flags. Even if you’re unlucky and your interview is a repeat of your Data Networks midterm, chances are, the other interviewees are feeling the same way you feel. If you don’t get the job, consider that interview a great experience and start preparing for the next one.

I asked one of my interviewers what was most important when identifying candidates that would be a good fit for a position in IT Security and their answer, while a cliché, was one word: passion. Demonstrate it to them. Telling them that you’re passionate is not enough, everyone says they’re passionate.

I also asked what they wish they would see more with candidates and the answer was experience. While that seems like a double standard, especially for an entry level position, its actually really understandable. If you’re applying for an entry level IT Security position, having 2 years of Help Desk experience while you were in school just makes you a better entry level candidate. Humble yourself and get that IT help desk, I promise it will help.


I got a job in security post-graduation by doing the following things:

  • Blogging about security stuff.
  • Willingness to take low level IT jobs to learn more.
  • Participate in CTF events. (I did CCDC and lots of VulnHub, I also hosted a CTF for college students in my local area)
  • The OSCP is attainable if you can afford it, I advise you to save for it if you think you can’t afford it. No matter what your current skill level, given enough time, you can get it.
  • Blogs and Books. Books will be your best friend. Lots of good ones out there.
  • Twitter, most of my infosec news is first seen in a tweet with a link to a random blog. (Also reddit has lots of good infosec news)
  • Got a BS in IT Security
  • A professional resume and tailored cover letters or emails to hiring managers. – This is very important and not enough people do it.



Basics of Windows Incident Response

For most people, including me, it is difficult to determine just what is “normal” when looking for signs of a compromised host. As someone who has done multiple CCDC’s as a blue teamer, I can say that this is easily one of the biggest struggles since it affects incident response as well as identifying a compromise.

I recently watched a webinar from Black Hills Info Sec that covered the basics of live Windows IR from the SANS 504 course. I recommend watching it, you can find it on YouTube HERE.

Obligatory thank you to BHIS and SANS.


Some of the most reliable tools for basic IR are built into Windows and Linux. This post will cover mostly Windows IR and definitely is nothing in depth but will get you started in the right direction. Windows has an extremely powerful tool named WMIC. WMIC stands for Windows Management Instrumentation Command-Line. It is extremely useful for IR as well as penetration tests. Between WMIC, netstat and tasklist, you likely have enough to notice some of the telltale signs that you have an infected host.

The biggest thing about these tools is recognizing what is not normal. The best way to do that is to become familiar with the output of the tools. Look at the associated DLLs for common processes like svchost so that you can determine whether or not it’s actually a malicious executable or that the associated DLLs are legitimate. Of course, there are numerous ways around this from an attacker’s standpoint but you get the idea.

SANS Instructor Mark Bagget developed a fairly neat tool that spawns a backdoor and quizzes you to find some information about that backdoor using some of the tools I go over.

You can download that tool HERE.

I have a walk through for the tool below, it is very straight forward but is a good introduction to Windows IR.

Most of the commands used to determine the answers to the questions can be found on the SANS IR Cheat Sheet.

Linux IR Cheat Sheet

Windows IR Cheat Sheet

Log Review Cheat Sheet

Windows IR Commands:

Event Logs

Event logs can be a great source of information, that is if you know what you are looking for. I would prefer querying it for known bad indicators versus looking at 25,000 logs that really don’t tell us anything useful. Luckily, there is an easy way to look for specific logs.

Wevtutil enables us to retrieve information from event logs via the Windows command line, which is pretty awesome. You can do all this stuff from a remote machine and supply the command line with credentials as well.

For more reading on Wevtutil, check out:



Some of the logs that might be useful to use are Security logs that indicate user account changes or additions, failed user login attempts, or service status changes.

This command will query the Security logs for event ID 4720 (User Account Creation)

wevtutil qe security /q:”*[System[(EventID=4720)]]” /c:5 /f:text /rd:true

qe: What logs to query, here you would place system for system logs etc.

/q: Specifies the query. The only thing you really need to change in here is the EventID, just replace it for the one you want. You can use truth operators in here as well as query specific alert levels. Check out that link above for more information on that.

/c: specifies the number of events to display. (If you place nothing here, it will find all matching events)

/f: Specifies the output type, by default it uses XML which can be difficult to read.

/rd: This takes True or False. Set this to true in order to see the newest logs first.


netstat is an awesome tool that comes with Windows and Linux. It allows you to display active TCP connections, listening ports and a whole bunch of other stats including what Process ID the connection is associated with.

This command will display all active TCP connections as well as listening TCP and UDP ports. You would want to run this to determine if this host is connecting to any strange locations, or if your host has something listening that shouldn’t be.

netstat -anob

-a: Displays all active TCP connections and the TCP and UDP ports on which the computer is listening.

-n: Displays active TCP connections, however, addresses and port numbers are expressed numerically and no attempt is made to determine names.

-o: Displays active TCP connections and includes the process ID (PID) for each connection.

-b: This will display the PID’s actual filename and requires elevation.


tasklist displays a list of applications and services with their Process ID. It is very useful for determining what process is associated with a PID. For example, if you notice a strange connection in the netstat output, you can determine the process with this tool.

This command will display the associated task as well as the associated DLL’s.

tasklist /m /fi “pid eq <Insert Process ID here w/out the brackets>”

/m: Displays the associating modules.

/fi: Allows you to use truth statements to refine your command.


net commands have a variety of uses. The net family has multiple siblings. All of them are helpful in identifying system information as well as active network activity.

These commands display open sessions with your host.

net session

net use

Some other commands include:

net user

net view

net user USERNAME


WMIC is an extremely useful tool for all sorts of IT folks. Having WMIC in your toolkit can immensely speed up the process of determining system information in IR, pen tests and system administration. There are some neat scripts out there that will gather a bunch of system data through WMIC for post-exploitation and enumeration as well. The link to the script is at FuzzySecurity’s write up on Windows privilege escalation.


This command will display the name and parent process ID of a given process ID. This would be the next step after determining which process is performing strange network activity. The parent process will be the process that spawned the suspicious process.

wmic process get name,processid,parentprocessid|find “<Insert PID here without the brackets>”

You can then follow up with running the same command with the parent process ID to determine the name of the parent process.

You can also determine the command used to run the process.

wmic process where processid=”PID without the quotes” get commandline

To determine startup tasks.

wmic startup get caption,command

To kill a process:

wmic process where name=”nc.exe” delete

Some other useful commands to know:

To verify firewall state

netsh firewall show state

To view scheduled tasks

schtasks /query /fo LIST /v

View running Windows services

net start

SANS 504 Incident Response Quiz

You probably want to shut your firewall off for this quiz since it will run a harmless backdoor on your host.

Begin by running the executable from an elevated command prompt.

You can use the netstat -anob to determine what is listening in which port. Typically, powershell.exe should not be listening on a random port so this should raise a red flag.

Since we used the b switch with netstat, we determined the PID as well as the listening port.

To find the parent process, we can use WMIC. We can run it twice to find the name of the parent process, we can see that our quiz executable is the parent process.

This part will be easiest done with netcat. You can find the windows pre-compiled version all over the place if you don’t have it. If you don’t know how to use netcat, check out the SANS cheat sheet or some tutorials on it, it is an extremely useful tool.


As you can see, when we connected to that port, this flag was returned to us.

Now things get a little more tricky since we have to use tasklist to determine malicious processes running. As you can see, I determined powershell.exe was running even though I definitely did not spawn it.

Now in order to determine the command line, we can use the wmic commandline option.

Since it is Base64 decoded, you can use your favorite decoder to find the flag.

And.. That’s all! As you can see, it is very simple but it does get you somewhat familiar with some of the built in tools that can help with determining a compromised host.

If you have any questions or comments, feel free to send me an email at admin(at)jordan potti . com or reach me on twitter. @ok_bye_now


What To Know For Your First InfoSec Interview

There are a whole bunch of sites out there that have common interview questions for careers in information security. I took those and compiled a list of concepts that those questions are based off of. While most of this stuff you should already know if you have an interview, it’s nice to have a refresher sheet. This most likely won’t be anything earth shattering but it will be a collection of concepts that a budding information security professional should understand. This is also a dynamic post so things will likely be added over the next couple months.

This is by no means a complete list but it should be a guide on some of the common concepts we should understand. I created this more for myself as a refresher since I will be graduating soon but I hope you can find it useful as well.

Disclaimer: I am a student as well, this was done as a way to gain a better understanding of these concepts. I am not a seasoned professional so don’t accept everything I post on here as absolute fact, this goes for everything on my site. In fact, it goes for everything. Always question what you’re told, especially on the internet. 

XSS – Cross Site Scripting

XSS is a client side attack. What this means is that an attacker is able to place malicious code on a website and when a user visits that web page, their web browser runs the code locally. Typically, this is JavaScript but it can be any client side language.

So what can an attacker do with a XSS vulnerability? There are a number of things that can be done. The most common is stealing cookies or other session information.

For example, you log into your favorite shopping site. The site issues your web browser a cookie which is your unique identifier. If an attacker is able to place malicious code on any site you browse to, he can grab your cookie, which allows him to access your favorite shopping site as you.

There are two main types of XSS attacks; Stored and Reflected.

Stored is basic, it means that the malicious code is stored on the web server. It can be stored in a comment field, in a database or wherever else you can place your code on the website. Reflected is a bit more convoluted. This requires a victim to access a malicious resource such as a website which then sends a message to the vulnerable web server, which then reflects its response to the victim.

One thing to keep in mind is that if the user is running a web browser that has code execution vulnerabilities, you may be able to execute code on the victims device via an XSS attack.

So how do we fix these types of vulnerabilities? While it completely depends on the circumstances there some common ways to prevent many XSS vulnerabilities. Escaping any character that can affect your web app. Depending on the language you are using, there are typically plugins or functions for this. Validate all user data, if it is expecting a phone number, make sure your web app only accepts a phone number. Escape all data outputted to the user. The other proven method of preventing the damage of a XSS attack is secure cookies and content-security-policy headers. These force SSL/TLS on the cookies and enforce the HTTP response behavior.

Two notable XSS attacks were TweetDeck and Samy. Both of these were not particularly dangerous but they did represent the vast effect that these types of vulnerabilities are capable of.

To learn more, check out OWASP’s guide on XSS.

CSRF – Cross Site Request Forgery

CSRF is another client side attack. This attack requires an attacker to have some knowledge of the web application as well as who their target is. CSRF is basically a way for an attacker to force you to execute an action by sending you a link.

For example, the victim gets an email at work while logged into an internal web app that controls access to a VPN portal. The victim clicks on the link which actually points towards that internal web app which adds a new user to the VPN portal. As you can see, this could be catastrophic to an organization if executed correctly.

There are two main types of CSRF attacks. One is used for the example above, it requires some social engineering in order to trick the user into clicking the link. The other type is Stored. Stored CSRF takes place when the CSRF link is stored on the web server itself. This can also be executed in part with a XSS vulnerability which would in turn would target a wide amount of users.

So how do we fix these types of vulnerabilities? Most web frameworks have built in methods to guard against CSRF vulnerabilities. Other ways include checking the referrer header to verify it matches the target origin, checking the origin header to verify it matches the target origin and CSRF tokens. CSRF tokens are unique to each session and are generated at random for each session. If the request does not pass the verification, the request fails.

An alternate way to deter CSRF attacks, as well as just being a good idea, is using CAPTCHA‘s.

In 2008, uTorrent had a CSRF vulnerability that definitely warrants a read if you want to get a better understanding of CSRF attacks. Check it out here.

To learn more, check out OWASP’s guide on CSRF.

Encryption Stuff

In symmetric encryption, both communicating parties will need a copy of the same key to decrypt and encrypt data. In an asymmetric encryption (Public/Private key), both parties will need each others public key. An encrypted message which is encrypted with a public key, can only be encrypted with each users private key which is kept hidden.

Encryption Algorithms are simply algorithms that scramble data based on some complicated math by using a key. Some of the common ones are Triple DES, RSA, Blowfish, AES. I would assume that unless you will be working on projects directly related to an organizations PKI (Public Key Infrastructure), you won’t be expected to have a deep understanding of these beyond knowing which of the common ones are symmetric or asymmetric. Some symmetric algorithms are AES, DES and 3DES. The most common asymmetric algorithm is RSA.

Key Exchange is the method in which an encrypted communication channel is established.  A common key exchange protocol is Diffie-Hellman. The problem with this initial key exchange is that before the two parties exchange keys, they cannot communicate securely. This introduces the problem of a Man-In-The-Middle attack. Luckily, there is a way to assist with that issue by using Digital Signatures. This is where your SSL certificates come into play. SSL certs are issued by a Certificate Authority such as VeriSign. Another common to verify a parties identity is the use of PGP, or pretty good privacy. Instead of trusting a third party to verify a certificate, each user is responsible for sharing their public key. This is a form of asymmetric cryptography.

RSA is similar to Diffie-Hellman with some variations. RSA is also an asymmetric protocol but it takes care of signing the digital certificate as where Diffie-Hellman couldn’t do that.

In a nutshell, if asked the difference between the two, RSA is more of an encryption algorithm where Diffie-Hellman is more of a key-exchange protocol.

Hashing is not to be confused with encrypting. Hashing is irreversible where as encryption is reversible. MD5 and SHA-1 are fairly common hashing types but are no longer consider secure. SHA-256 is considered much stronger. A salt is used in conjunction with a hash in order to make it more difficult to defend against dictionary attacks or rainbow table attacks. What a salt does is append a random value to a password before it is hashed in order to prevent having the same hashes in a database if two users happen to use the same password.

Encoding is the simplest to reverse as its not designed for obscuring or hiding data. A common form of encoding is base64. What encoding does is converts data to a common form to be transferred over a medium in order to protect the integrity of the data.





CVSS stands for Common Vulnerability Scoring System. This is a universal language to describe the severity of a vulnerability. Scores range from 0 to 10, where 10 is the most critical. There are multiple metrics that go into calculating the score and these scores change over time depending on the number of target systems, damage potential, exploitability among others.

CVE stands for Common Vulnerabilities and Exposures. This is a standard way to identify a vulnerability with a standard naming convention. This is where you see CVE-YEAR-SOME RANDOM NUMBERS. “CVE-2016-3578”. Mitre has a database of all CVE’s as well as NIST where you can see some details about each CVE as well as the associated CVSS score.




Get familiar with the Owasp Top Ten. They have a pretty nice cheat sheet you can study off of. You should be familiar with at least one example based off each vulnerability.


  1. Injection– SQL injection
  2. Broken Authentication – Login form over HTTP.
  3. XSS – Stolen authentication token.
  4. Insecure Direct Object References – Normal users can add admin users.
  5. Security Misconfigurations – Anything you can think of basically. A common one is default credentials.
  6. Sensitive Data Exposure – A users password is displayed to him in his settings tab which means passwords are stored in plain text.
  7. Missing Function Level Access Control – The admin tab is not shown to a normal user but it can still be accessed by plugging in “/categories/admin” after the host name.
  8. CSRF – User unknowingly performs an action orchestrated by an attacker.
  9. Using Components with Known Vulnerabilities – Running a WordPress plugin that has known vulnerabilities.
  10. Unvalidated Redirects and Forwards – A user is redirected to a malicous website.

OSI Model

OSI stands for Open Systems Interconnection model.  This is a theoretical model that helps us design and understand how data communication works.

Image Credit: https://en.wikipedia.org/wiki/OSI_model

Examples of each layers:

Some key differences between a router, a switch and a hub are what they connect. A router connects networks and a switch connects hosts. A hub just connects hosts and instead of using logic to divert packets, it just sends to everyone. A router uses IP addresses for transmitting data, a switch uses MAC addresses and a hub doesn’t care since it is broadcasting all received data.

Since ICMP is a Layer 3 protocol, it doesn’t use ports which take place at Layer 4. That is why pinging does not require a port to be open. Using commands like tracert to determine the path of a packet also uses ICMP (Windows). This works by setting the TTL (Time To Live) to a low number and incrementing by one each time you get a response. The response will be an ICMP error message since the TTL was reached before reaching the packet’s destination. This way, your device is able to build a list of devices that a packet crosses all the way to the destination. Linux uses a similar method by using UDP instead of ICMP.

Some of the Interview Questions Asked To Me Personally

Some of these questions were asked “pre-interview” at a job fair so some of them are pretty simple. 

What is XSS and how would you prevent a XSS attack?

What is CSRF and how would you prevent a CSRF attack?


What is a buffer overflow?

What is a block cipher?

Asymmetric vs symmetric encryption?

What is Diffie-Hellman?

What are some static/dynamic analysis tools?

Whats your favorite security tool?

ForgottenSec’s Github with some awesome content


Related Links from Rob Fuller’s (mubix) repo

Evading Anti-Virus Without Being A Wizard

Recently, I became curious just how different AV evasion tools actually worked. This is a very interesting topic as AV  vendors seem to be playing catch-up. Granted, they are pretty good at this cat and mouse game but the problem is that they are the mouse.

Lots of posts I have seen on AV evasion are simple tutorials on how to run the tools but I don’t find that very helpful. Without understanding what you’re doing, you aren’t going to be able to propose a solution. Anyways, the techniques used to trick AV are pretty clever!

This is not meant to be a simple tutorial since there are plenty of those out there; what I wanted this to be is a way to understand how AV bypass tools work.

Hyperion: Hyperion is an older tool that is only on this list to demonstrate a pretty cool obfuscation technique. Hyperion use a technique that encrypts your malicious binary with a shortened AES key. The decrypter, or stub, which is not encrypted, gets packed into the binary as well. What that does is brute forces the AES key every time the binary is run. The problem with this is that AV vendors look for this brute forcing stub which forces Hyperion to rely on original obfuscation techniques such as Assembly Ghostwriting. Assembly Ghostwriting is in short placing junk inside your program in order to hide its true purpose.

Tutorial: http://e-spohn.com/blog/2012/08/02/pe-crypters-hyperion/

Documentation: https://www.exploit-db.com/docs/18849.pdf

Veil-Evasion: Veil is a framework that can use multiple obfuscation techniques. One of these is taking the same method Hyperion uses. It also can take a python shell and using py2exe, Pyinstaller, or pwnstaller, it can bypass AV. Since Pyinstaller is a fairly common tool, AV rarely flags binaries created with it. Pwninstaller is a variation of Pyinstaller. What it does is recompiles a part of Pyinstaller to force your binary to NOT opt-in for DEP protection which can increase the reliability of your binary.

Another method Veil uses is custom code, obfuscating code and using non-standard code for Windows binaries. Hopefully, you can already see a trend. There are multiple ways to obfuscate malicious code, no one way works for all AV vendors and no one way will work for very long before they catch up.

Here is a chart of how well AV vendors are faring against Veil payloads: https://docs.google.com/spreadsheets/d/1GkNmPkaPrHevO0tHnc-W_xctBNWtnL3LaQIeejTNX6U/edit#gid=0

Tutorial: https://www.security-sleuth.com/sleuth-blog/2015/2/3/using-veil-with-metasploit

Documentation: http://www.slideshare.net/VeilFramework/the-veilframework

Shellter: This tool is simply a PE injector. It allows you to inject a shell into a binary. Because you can choose any application to inject code into, as well as choose any injection point, you basically have an extremely polymorphic malicious binary tool. Shellter also has options to load several built in meterpreter shells. This is also the only Closed-Source project on this list so you might want to take that into consideration before using this tool.

Tutorial: https://www.doctorchaos.com/shellter-project-bypassing-av-detection/

Documentation: https://www.shellterproject.com/introducing-shellter/


There are of course many other ways to bypass AV. This post was meant to gain an understanding of the point-n-click tools for AV bypass.

Hyperion fares the worst since its “stub” or decryption code is well known by AV vendors. This could be bypassed by writing your own stub. After obfuscating my meterpreter shell, the detection rate actually went up.

Veil fares pretty well! Its framework also has a bunch of other convenient tools as well which makes it the most robust tool on this list. You can check out this list of proven bypassed AV vendors above.

Shellter actually seemed to be the most in depth AV obfuscation tool on this list. With my first try, I got a meterpreter shell with a perfect score on Virus Total. Once again, with this tool being closed-source, it will be interesting to see how long it takes for AV to catch up!