I am usually snarky about lists, yet I can’t help but love this list from ESET’s WeLiveSecurity site, 10 gadgets every white hat hacker needs in their toolkit. I am actually woefully behind on this list, and need to fix that! Is there anything amiss with this list? Well, if I wanted to be picky, all of these tools are useful to the hacker with physical or wireless proximity access. Then again, we’re talking about physical gadgets, aren’t we? And it does underline an often missed part of corporate security: do physical walk-thrus to check for rogue hardware! This list is also a sort of training/shopping list for anyone wanting to do wireless or physical pen testing or defense.

Raspberry Pi 3
Wifi Pineapple
Alfa Network Board
Rubber Ducky
LAN Turtle
HackRF One
Ubertooth One
Proxmark3 Kit
Lockpicks
Keylogger

It’s been years since I had a working lab at home, and I’m finding myself ready to build a new one. Building and maintaining your security lab is less about being a security expert and more about wearing your Systems Administrator hat. Maybe even your shiny new devops hat! It takes work, and you better get used to it and get efficient about it. You want to spend your time doing security magicks, not wrestling with your VMs.

Developers already have a leg up in this regard if they are already using devops-y tools like Docker or Vagrant to quickly rebuild and share development environments as a VM. Modern Sysadmins also are learning these techniques. It’s worth getting a taste for it as a security professional as well. Don’t discredit blogs and articles from developers in this field.

The simplest lab will be installing a virtual hypervisor on your local workstation right now, and carving out a VM or two. You can always use your local system as the attacking box, and the VM guests as victims by allowing the host and guests to talk to each other. That’s all quick and dirty, but most of us don’t want to screw up our main box by testing weird things out on it, or vice versa screw up our lab that took hours and days to set up by doing something unexpected on our main box.

The second easiest route is to forage from your local company desktop and systems folks. Do they have old workstations being sold for cheap or thrown away? Do they have extra copies of old OS media they no longer need that you could use to install from? Even just having a few extra workstation-class systems on hand can be enough for a lab, even if they’re not powerful enough to run virtualization tools on.

But let’s say you’re ready for the next step. You want to stand up a virtualized pen testing lab. Below are some topics to think about and answer before getting started.

What is your purpose?
You might want to do some pen testing, which is probably the most typical use case of a security lab. But you might instead be looking to detonate malware or evaluate security tools in a controlled environment. Keep your use cases in mind when answering some of the following topics. For instance, detonating malware might mean you have a particular interest in keeping your guest VMs absolutely isolated!

Choose your hypervisor platform: Virtual Box, Hyper-V, VMWare, XenServer
Picking a platform you already know will probably help you get up and running more quickly. But you could take this chance to learn something new and pick an option outside of your comfortable zone, but plan for some extra learning time. All are pretty capable, though Hyper-V is still fighting to prove itself in the enterprise and VirtualBox is usually limited to small scale use like for our lab project. Learning VMWare and XenServer are things you can effectively add to a sysadmin resume. XenServer and VMware can be loaded onto bare metal, but Virtual Box will require an OS to install onto.

While the others have free versions you can use just fine, Hyper-V has extra considerations that you’ll want to check up on, such as what you can or cannot license through it for a server class Windows OS. Honestly, chances are you will want to use something other than Hyper-V. Exception: If your company already has a Software Assurance subscription in place with Microsoft, perhaps you can convince someone to ask about including a free license for Windows Server Datacenter that you can use.

Think about how many systems you’re going to want to have running at any one given time.
This will increase your hardware needs the more you want running. For an initial run at a lab, plan for 2-5 concurrent guests running at once (20+gb disks, 2-3GB RAM…)

Think about portability.
This may influence your hardware choices: beefy laptop versus an old server chassis or maybe a portable-ish box? Do you want to power this off and take it various places, or will this just be on your home network in a corner forever?

Think about network needs as this might invoke further work on a router/firewall or on the hypervisor of choice.

• Do you want your local network to talk to these VMs and vice versa? you probably don’t, but maybe you want to use a physical kali laptop as your attacker…
• Do you just want the VM network to talk out to the Internet? Some systems will want this for patching or apt-gets or to build them!
• Do you want granular control over any of the above? Extra work!
• Keep this item open as your answer might change based on what you want in your lab.

Think about initial VM inventory.

• an attacker box (or two: 1 linux and 1 windows)
• a victim box.

But for your victim box, do you want to load a system purposely built to be vulnerable to things (like metasploitable), or do you want to build more or less default-ish systems? By default-ish, I mean not just out of the box, but maybe also configured with typical settings and best practices as needed. Or more than likely a mix of the two.

Linux VMs are pretty easy. You download the distribution iso, install it, optionally update, and you’re good to do whatever you want next. You can even snapshot the installation for quicker builds later with really no issues.

Windows OS VMs are a different story. Windows isn’t free. You can download limited trials from Microsoft, but they will expire. You can get things like MSDN copies or freebies alongside Software Assurance subscriptions, but those are not really free for home users. It can also be problematic to clone a Windows VM snapshot into new systems, depending on what you need, and the license will still be expired. This means you need to think about how you want to refresh your Windows OS VMs, which means channeling your inner devops (deployment infrastructure), scripting (quick configurationgs), or documentation skills (notes to follow each time) to rebuild efficiently and accurately. You should also think about how to get hands on with older, unpatched OS versions, such as older 2008 R2. Grabbing media from your ops team is always a good source.

What might you want for Windows boxes?

• a server class
• a workstation class
• a domain controller (with DNS, DHCP, Active Directory, Group Policy)
• a domain computer member (server or workstation or both)
• a file server, FTP server, IIS web server all in one? (also think about populating your file server with files!)
• once configured, snapshotted, and think about what you’ll do in 181 days when the license is expired.
• later on, you might want to add security systems like a Splunk server, IDS/IPS, packet capture monitor, etc.

Think about your install media and how you plan to keep it updated. You probably want to carve some of your VM host storage for an ISO section where you can plop ISO images of installs and mount them from, or maybe an external drive you can attach. Also think about how often you will get new ISOs and how will you know a new version is available? How will you get old ones if you need something older than a particular date or patch?

Are there any VMs you want that are going to need to be built all devops-style? Take the install process for Metasploitable3, for instance. How will you refresh this? Where will you build it? You might have to learn some devops skills to manage this without busting your box on accident. Maybe have another system nearby you can build VMs inside, export them out, and then import them into your lab host in the ISO storage location.

All of this should pave the way towards planning, acquiring the hardware for, and beginning to build a pen testing security lab.

On October 22, 2016, a two-factor authentication bypass against PayPal was released. If you just intercepted the post back from a form about security questions, the system would accept it and authorize a device to be sent the 2FA code over text messaging.  Now, this does require that you have the first part of the authentication process: username and password. But, that’s exactly the part that is weak enough to force the use of 2FA. Basically just opening a rogue email which installs a keylogger or other trojan is enough to leech that out.

Now, PayPal did fix this within a few weeks, but it’s really annoying to know that this system was so easily subverted. Just munge the data in transit and you’ve broken their system. To me, this suggests someone in QA or their security team didn’t do much for security testing against this piece of code before it went to production. And that’s just plain annoying to see. Nor was this designed with security in mind by the developer, either.

And if PayPal makes these makes mistakes, so does most everyone!

I wonder how often a vendor calls competing vendors to try and get sales pitches, calls, and demos out of The Other Team? Probably less often than I’d like to think. I imagine they have enough work to do without resorting to filling time with some casual spying.

Anyway, DarkReading has posted this article, “20 Endpoint Security Questions You Never Thought to Ask” (I read that headline over a good 5 times in my best movie trailer hype voice). Even though I’m a bit snarky in my response to these questions, this article does make a good foundation for any sort of endpoint security requirements gathering might be needed when evaluating new products.

Do note that I don’t really trust sales people. I trust being hands-on with products, or at least eyes-on with an in-depth demo from an engineer. So any questions that are easy for sales to just fib about, I tend to reword into “Show me…” types of questions. I’m also crazy wary of articles written about a product segment by someone whose business lies in that segment. I get that they’re knowledgeable, but they’re also happy to slant the discussion to favor their own products, even if it’s subconsciously done.

A few key questions are missing here. Asking about licensing models is always a necessity. Asking about central management tool requirements is another. Plus, these are endpoints we’re talking about. Does this include server class systems? What about when a mobile device is off-prem? What port allowances on my network are necessary to be opened? Will the endpoints be listening and do I need to protect that opening? Are updates and central callback communication encrypted or protected somehow? To be fair, this list was about questions I never thought to ask…though, let’s also be super fair and say that most of these questions are baseline questions everyone should be asking already.

“1. How easy is your solution to deploy?” This is a fair question, but I’d reword this as, “Show me the process to deploy your solution.” I’ll make the determination on whether that is easy or not. Do I need to burn a domain admin account for this? Do I need to sit and wait to do them one by one? Do I need privileged staff? Does the tool run as local system/root or do I need service accounts? Will this discover endpoints or do I have to populate with a list or one by one? And so on.

“2. How easy is your solution to manage?” Again, I’d reword this to, “Show me how to manage the endpoints from a central management tool.” I’ll decide if it’s easy or not.

“3. How easy is it to configure rulesets and tune the solution once deployed? Aside from the fact that threats are continually evolving, if there are activities that appear malicious elsewhere but are benign in my environment, I need a way to filter those out.” For the first part, yet again, “Show me how to configure the rulesets and give me an install that I can play with directly.” I’ll decide if it’s easy or meets my requirements. For the second part, I’m not sure what examples there may be, but I might ask whether any given rule or protection can be fully turned off if I want them off, or if I can make exceptions by running multiple policies. I’ve run into tools with pieces that just can’t be turned off (Sophos!), and it can be very frustrating.

“4. How easy is it to update your solution’s knowledge base or take advantage of the latest knowledge around attacker activity? If you can’t make it easy for me to operationalize what you’re selling me on, then your solution isn’t going to work for me.” Yet again, show me how to configure updates and what gets updated.

“5. What additional load on the endpoint does your agent introduce?” I honestly don’t think this question has been relevant for many years (virtualization concerns notwithstanding), and even if so, a sales call won’t produce a negative answer. More than likely, an extensive proof of concept roll-out will be necessary to answer this. One does have to think about whether virtualized endpoints will be included. Do they all scan at the same time and overload my hosts?

“6. You want me to install yet another agent? I would be willing to do that if you articulate how you can consolidate functionality that I currently get from multiple different agents into one agent.” I don’t think this is relevant, either, unless I am looking at a tool to replace several others. Otherwise, when we’re talking endpoint security, we’re going to be talking agent-like footprint. The exception? Mainfram…I mean, fully virtualized environments where the security is abstracted out into the host/hypervisor layer.

“7. How does your solution integrate with my existing security infrastructure? I have a complex ecosystem of products deployed and yours needs to play nice with it.” I doubt this is very relevant. I mean, let’s say it’s the best product but it doesn’t “integrate” well with my infrastructure. Sorry, but that’s my problem to deal with. It might be better to ask questions about how notifications/alarms are raised, logged, sent, and handled. And to ask to see the dashboards or status checks or audit reports. However, this is definitely an internal question to raise, and there may be complex environments where this and other tools will stomp on each other for a while.

“8. Not all intrusions involve malware. What is your strategy to detect intrusions that use no malware at all?” I actually am not sure what this question is asking about.

“9. Is your solution part of an overall platform, or is it just another point product that I need to figure out how to integrate into my operational workflow?” A good question. Basically, what else do I need to get value out of your tool(s)?

“10. Does your solution leverage and facilitate correlation with other data? I have a lot of great data elsewhere in my enterprise. Do you know how to take full advantage of it to improve your efficacy?” This seems like a question specific to a flavor of solution…

“11. Is your solution based on knowledge of attacker tactics, techniques, and procedures (TTPs)? If not, how do you identify that type of activity?” At this point in the game, I don’t much care or expect visibility into the inner workings of the major players in this field. Real world roll out will tell me if updates and signatures and behaviors are stopping what I actually see coming in daily.

“12. How does all the knowledge you’re selling me on make its way into the product to help me mitigate risk?” This goes back into the previous question: I doubt I’ll ever have this visibility beyond a slick sales talking point or two that I just have to accept until I see the product in use for a year.

“13. Do you really have behavioral analysis and machine learning built into your solution, or is it just signatures and rulesets behind the scenes?” Fair enough, but a bit of a softball question that sales people hope you ask so they can hit a major talking point they’ve rehearsed in their sleep.

“14. Do you provide ability to remotely contain and remediate endpoints?” I actually really like this question, but it needs to lead into a demonstration of remote management and remediation. I’ve seen tools that do a decent job and yet are useless when it comes to proper enterprise level management.

“15. How efficient and powerful is your enterprisewide search? If I have an incident, or even if I don’t, I need to be able to slice and dice the data collected by my endpoint solution in an instant.” A good question to lead into viewing the reports, dashboards, or other logging and display capabilities. Before asking this, however, I make a point to have an idea about what sort of data will be relevant to me. Are there any metrics I want to see? Or as an analyst, what might I need to know to investigate an event (or non-event)?

“16. How effective is your solution in a real enterprise against binaries you’ve never seen before?” Another softball question. If you’re big enough and good enough to ask about this question, you’re big enough to have your internal malware team throw some things at the tool during a POC or small demo. Otherwise, this really doesn’t apply to you.

“17. What is your true positive detection rate in the wild? Results from your lab don’t interest me here.” I don’t even know what the author expects this answer to be, but it’s leading and a softball.

“18. What percentage of events and alerts that you fire are false positives? Again, results from your lab don’t interest me here.” Again, never going to get a real answer here. This is going to tie into how the tool’s logging, alerts, reports, and dashboard all work, in conjunction with how granular and complex you can tune and configure the solution. All of this working together allows analysts to tune down the false positives.

“19. What is the upgrade path for your solution? It should be a smooth and straightforward transition from one version to the next.” I’d also ask how often major versions come out, and I’d try to find someone who has used the solution to tell me about any issues with upgrades or if there are any ramifications for falling behind on patches (like one feature becoming broken over time, orphaned endpoints that haven’t checked in, or something). Walk through the upgrade process and see if it’s just about running an installer and pushing out the new version, or if it’s ugly like database upgrade scripts and other complex steps.

“20. How does your solution facilitate my information sharing initiatives?” Basically, does it do the right reports that I want? Or, at least that’s how I see this question going.

If you’re looking for something to do with Perl (or Python or other scripting languages you’d like to play with), you can always make a quick and dirty port scanner. For instance, like this SSH port scanner script. Just looking at the code, this isn’t something that uses a specific SSH client or anything; you can just change the port to create a different scanner.

And this can be built upon very easily by searching for other examples like a more robust port scanner in Perl. You can scan more ports, a list of ports, maybe replace the random IP address with a static list that you supply.

Even better, get a port scanner on every system in an environment without having to rely on an installed scripting environment…enter PowerShell! Yes, start playing with port scanning using PowerShell scripting. This is arguably a bit better than installing the Telnet client on current Windows server boxes every time you want to troubleshoot network connectivity.

Is this useful? Absolutely, from both offense or defense, you can find specific things in an environment that maybe run on a weird port or common ports like SSH. Scan your network space from your own admin VLAN to find lost devices that aren’t in inventory but weren’t properly decommissioned, or maybe that test Linux VM someone stood up last year that was supposed to be temporary. Tools like this can be used to test and validate firewall rules, which always sounds easy in practice, but is not necessarily so when you really get deep and dirty with it.

This can also be used to test security detection processes, like network IDS/IPS. Catching sequential or even random (but large volume) scans should be something easy to accomplish and test. You can even add some waits/pauses to the script to slow the scan down and watch behavior of your IDS/IPS versus time it takes an attacker to get useful information off your network. Need to test your IDS/IPS for an auditor? Creating easy, but relatively benign alerts in a few different ways is useful (like triggering a WAF with a GET to cmd.exe or something).

IT security is a broad field, just like the general “IT” field is broad. If you want to get “into security,” there are various paths to follow. I’ve been playing with this list for a little bit, and want to move it from a text file on my desktop to a more permanent filed place on here. The following groupings are not meant to be all-encompassing as there are dozens of smaller focused positions and different job titles out in the world. But this should be a pretty good, and close-to-complete view of security.

• Penetration Testing and Vulnerability Assessment (system, network, web, application, cloud, mobile, physical)
• Incident Response, Malware Analyst, Threat Hunting
• Threat Intelligence
• Forensics (memory, disk, network, mobile)
• Risk and Compliance Analysts (includes GRC)
• Security Auditor
• Architect, Policy, and Design
• Security Researcher (reversing, exploit dev)
• Security Admin/Engineer, Security Manager/Analyst (network, identity, application)
• Access/Identity Management
• SOC Operator/Analyst
• Application Security/SDLC (static analysis, mentor, tester)
• Physical/Surveillance
• Management (CISO, Manager)
• Education/Trainer/Media
• Generalist

Yeah, I keep “Generalist” as a spot on here, because it’s still something to be considered. While not usually a job title, if you like everything about security (or are just undecided if you want to focus somewhere), you can have generalist security professionals just like you can have generalist IT professionals. It’s not flashy, but knowing a decent amount about many things can still provide value.

I’m sure I’ve missed some major roles, but many other smaller ones probably fit into these as sub-roles. Also, the Management slice might often be more about managing people and departments and less about IT or security; more like a category of management rather than a category of security. That will all depend on the organization.

There are also types of security jobs as well. For instance, you could be a pen tester consultant, sales engineer, or even a part of a permanent red team inside a large organization. Also, things change if you’re working for an actual security company (hello enabler!) or part of a security team for a company whose main line of revenue lies elsewhere (hello cost!). So these slices should also be taken into consideration against all of the above categories.

• External security consultant
• Employee at a security company (including sales engineers)
• Employee of a non-security enterprise (i.e. part of an internal team)

Why am I even bothering with this exercise? Well, I’m currently filtering through the local job market for a role to land in. I’ll give more details about that in a future post.

I’ve been in some job interviews in recent weeks, and gathering a list of qualities that information security professionals should have. Ingenuity, problem solving skills, knowledge and aptitude, detail oriented, analytical skills, healthy skepticism, team player, autonomous, enthusiam, empathy, having a good heart (these last two deserve their own posts). All of those are highly important, even required. But I think there is one quality that I think leads many of these: integrity.

Security is tough.

You don’t need security without the insecurity, and as such security will always be behind the curve.

You’ll always be fighting against agile bad guys and always behind, but you’ll also always be fighting users who want 100% convenience. And you’ll always be fighting against other pulls for business budgets and money. And always fighting the growing complexity and chaos.

It takes integrity to be in security. And it’s more than just not looking at the CEO’s emails when you have access or passing along trade secrets or posting security holes on social media or keeping quiet about an HR investigation into harassment claims.
Integrity isn’t surprising as an important quality in security, as it is also an important quality for life in general.

It’s also about admitting you don’t know something and the subsequent quest to learn it, rather than faking it and losing credibility.

security is difficult.

These teams need to know what is important to the business and how to balance user access/convenience against security and budgets. That’s a high degree of business acumen that is required.

Security also needs technical chops in all areas, from data management to networking to systems to desktop to programming so that they can provide guidelines and mentoring on how to be more secure. That’s not something where a desktop person can come in and immediately be effective without knowing how network infrastructure or server management is handled or has never spoken to developers before. They also need to back up their theoretical anecdotes with evidence of successful attacks and defenses.

Security also has to know how to handle people, as they are always the weakest link that need to be educated and incentivized (I prefer incented as a word..) to know and do the right thing, from non-technical employees to the deeply technical senior IT members.

Security needs to be objective with technical logic, but subjective and creative to keep up with innovative attackers who find and leverage new issues weekly. It’s even sometimes artful in ways to detect and prevent attacks.

Security needs to be rigid and stick to compliance standards and expectations, but also flexible to the ever-changing world, business, technical solutions, and attackers.
Security needs to be confident in their solutions, but also humble enough to accept subject matter expert feedback and suggestions.

I love this profession, even if it causes me to take an extra drink some Fridays. The challenge is intoxicating even as it is frustrating.

I really wanted to add more to this list of “5 Quick Wins On Your Next Penetration Test” post by Red Team Security Consulting, but they did a good job capturing really important broad topics in their first 4 items.: Apply missing patches, decommission forgotten systems and services, bring your password “A” game, and restrict your admin interfaces. The last one, “Validate your input/output” applies to developers more and isn’t quick or easy, and the bonus item, “spoof your banners,” isn’t something you spend time doing unless you really, really want to. But I do have a few tidbits to add. (My criteria here is keying off the phrase, “quick wins.” It’s easy to add many more things that can take months to implement…)

First, issue a round of security awareness education to your employees. Remind them about phishing attacks, tail gating through locked doors, and reporting general “weirdness” on a server. Server is crashing or slow for no reason? Look deeper. Be skeptical, even if the answer is usually not “an attacker.”

Second, make sure your anti-malware solutions are pushing updated signatures/versions to endpoints. Make sure your reported endpoints match your expected inventory, and shore up any stragglers. It’s not perfect, but endpoint protection does flag tools that attackers use.

Lastly, here’s a “cheat” you shouldn’t do, but I guess you could. Stand up honeypots or devices that answer on otherwise unused IP addresses or ports on those IP addresses. Thing is, no pen test lasts as long as it should, and a huge amount of time is spent on scanning alone. If you make an attacker’s scan take way too long, they’re not going to find things or they will just not have much time to get where they want to go. Does that cheat you out of value from the pen test? Absolutely! But it *is* something to think about: the amount of time you’re paying someone to scan your network and how that steals value from the pen test.

Saw mention of a post over at CIO: 5 Security Practices Hackers Say Make Their Lives Harder. Ok. It seems like every security practice should make their lives somewhat harder. The 5 items trend largely towards password and privileged account protection, which isn’t surprising since the survey was conducted at Black Hat USA 2016 by Thycotic, a vendor of password and account management tools ( or Privileged Account Management [PAM] for the fancy). And I have used and generally like their Thycotic Secret Server, so I have nothing against them. I just generally have issues with vendor-led statistics.  [As an aside, I consider Thycotic a sort of third level solution for any organization that has to manage privileged accounts. First being nothing, written, text files, or Excel files with password protection. Second being a PasswordSafe, keePass, or even LastPass sort of user/group password management tool. And third being something enterprise-ready that you’ll have to pay for, though not exorbitantly, like Thycotic.]

So I headed off to see what this survey was all about. I found a copy sitting over at SCMagazine: the 2016 Hacker Survey Report. Mysterious! Unfortunately, the survey pdf itself shows nothing of the methodology of the survey or the questions asked to get those 5 items that make hacker jobs more difficult.

Are the items wrong? Not really. Account security is highly important, from admin to end user. Access escalation and end-user phishing are strong topics for IT security in 2016 (along with cloud security and anything to do with PowerShell).

I just always get skeptical when I see self-serving vendor-provided surveys and information.

Edit: I actually just saw over LinkedIn that the survey pdf is now available from Thycotic if you want to submit some false sales information (no real verification or checks to download). It’s the same pdf as linked up above. And it’s still really not that interesting.

By now, most of us have heard about the latest largest DDOS attacks on record, first against Brian Krebs, and then against OVH. MalwareTech has a great article about the botnet behind those attacks, Mirai, and how it actually works.  Brian Krebs also has information about the source code for Mirai. And here’s the list of the user/passwords the bot used to dig into IoT devices, taken right from the full Mirai source code.

Metasploitable 3 is out, and there are some differences from the previous version. The vulnerable system is a Windows box this time, and instead of just downloading a VM image and firing it up, the author(s) have decided to leave it up to the end user to package the VM. This adds a little complexity for us, so I thought I would walk through the steps it took to get me up and running. This really wasn’t terribly difficult, but this is my first time using vagrant/packer and it’s been a long time since I used VirtualBox. Hopefully I remember this all correctly! I did this install on a relatively clean, patched Windows 7 64-bit laptop. I did not track when I had to run installers or cmd windows as Administrator.

• Make sure the system you’re installing this to has Internet access, and it’s not just to download the installers. There are various downloads that happen during much of the execution of vagrant. I know. That’s strange to ask security geeks to just trust, but that’s the reality of this method of deployment. If you want to watch it and authorize each access attempt, make sure you have some tea/coffee nearby and a book as my install took about 20 minutes or so.
• Download Packer by following its install instructions. Don’t forget to set the PATH variable. I just put Packer inside Program Files.
• Install Vagrant 1.8.1. The Metasploitable3 instructions discuss a problem with 1.8.5, so I didn’t even try it. This installed into C:\HashiCorp\Vagrant.
• Install the Vagrant Reload Plugin. Basically just run $ vagrant plugin install vagrant-reload from a cmd window.
• Install VirtualBox 5.0.10.3. The latest version is 5.1.6, but vagrant 1.8.1 during execution will want 5.0.10 and attempt to download/install it. That process never succeeded for me, so I installed this manually.
• Install Microsoft Visual C++ 2010 Redistributable. During vagrant’s execution, there was a point where I was stopped and waiting for an SSH connection that never happened (I believe that’s where I needed this). Installing this got me past that hurdle. Note that I’m linking to the 64-bit version.
• “Clone this repo and navigate to the main directory.” We get choices here now. You can just download (“clone”) the zip from the GitHub website and call it good. Or you can download and install Git or Github Desktop and make an account. I chose that latter. After I installed GitHub Desktop and created an account, I opened a Git shell from the Start Menu, navigated to where I want to stage my pre-packed VM files, and issued, git clone https://github.com/rapid7/metasploitable3.git This created the “metasploitable3″ folder for me, so I didn’t need to manually create it. For me, this was c:\users\michael\documents\github\metasploitable3\”. The Git shell, incidentally, will open by default in your user documents folder.
• Next, run packer build windows_2008_r2.json while in a cmd window inside the folder you cloned metasploitable3 into. This will take a while. I don’t recall having any issues at all with this step.
• Now, run vagrant box add windows_2008_r2_virtualbox.box --name=metasploitable3 to add the box to vagrant.
• Run vagrant up to start the new VM. This will run a bunch of scripts and you’ll see the box appear and reboot several times if you happen to have VirtualBox running at this point.
• About 10 minutes into this process, my box disappeared from VirtualBox and the vagrant window showed a bunch of “from” lines. At this point, vagrant has hit an error and walked a bunch of stuff back. Scrolling up, I found an error from winrm about having more then 50 concurrent operations. (“The WS-Management service cannot process the request. This user is allowed a maximum number of 50 concurrent operations, which has been exceeded…WinRM::WinRMWSManFault“) That sucks. Being new to vagrant, I didn’t really know how to fix the scripts for this error, but I did know how to fix this if I could get into the VM while the scripts were running. I ran vagrant up again and watched the VM console in VirtualBox. After the first reboot, I was able to quickly log into the box (vagrant/vagrant) and run this command: winrm set winrm/config/service @{MaxConcurrentOperationsPerUser="500"} to set concurrent operations to 500. Success!
• Save the VM state. I don’t want to do all of this again any time soon, so I saved the VM state so I can keep it in VirtualBox and restore state as needed. Now, I can just right-click my new VM and choose Start whenever I want this system up.

From here, I believe the default settings for VirtualBox allow for NAT connections, so that my Metasploitable3 box has access to the Internet and my own network, plus my network systems can talk to this box. I may have just set this without thinking, and it’s not default. If you’re not on a private network, I suggest keeping this networking to host-only, and instead just install a kali linux or other pen testing VM into VirtualBox.

If you want to use this box inside VMWare or another hypervisor, export the Virtualbox VM as an Open Virtualization Format (OVF or OVA), which VMWare will recognize.

Is this a cool way to distribute a VM? It is if you’re familiar or comfortable with all these steps, probably more so if you go all devops and deploy systems using any sort of container/packer process or you’re a developer that shares VMs a lot. But I’m glad I don’t have to do all these steps for most VMs that I download. For instance, standing up Metasploitable2 doesn’t even require a post since it’s just a download-open-start process. Also, this is sort of what you need to do for a Windows VM these days, unless you want to license them on your own.

Aside: I have no idea how WordPress automatically chose to make the code lines special boxes. Neat, I guess. And I don’t like having to put a check mark into each link to open in a new tab. I do this stuff faster manually typing the dang tags…

This is an old compilation I made for a future post that never materialized. But I like the list, and have decided to just post it unfinished.

I’ve long compiled a list of what I would call “security laws.” These “laws” are principles that cyber security experts should be aware of, or outright aligned with. Some of them I’ll explain in more detail, but others I think speak for themselves. Getting oneself hung up on any of these laws can cause insecurity.

There is no silver bullet to security. – The IT and information landscape is so large, divergent among entities, and dynamic, that there is no silver bullet device, technology, or set of best practices that will offer a state of security.

Security events *will* happen. – Likewise, be aware of intolerance to the inevitability of a security breach. In other words, be aware when your culture or posture exhibits symptoms of assuming security events won’t happen.

You cannot “win” the security fight, but you can survive.

You can’t prevent/address what you don’t see.

Security is a cost; it rarely directly enables business. – Security enables business in only two conditions. 1) Your core business is security-related. 2) The business would absolutely not have been possible without the security, i.e. regulations, requirements, customer demands. Avoid twisting and tying that second condition into knots. (present edit: I’d also now add that security can be an enabler if it helps protect a business competitive advantage. And yes, I actually consider this bullet item to be discussion fodder.)

Compliance and regulations only help to achieve a common denominator; companies are economic entities and will tend to only do what is necessary to comply. This keeps overall security low. Structure your security posture in a way that compliance and regulations are met as a convenient result, not as the end goal of the posture. (present edit: This can also be discussion fodder.)

Security does not exist and has no need if there is not insecurity.

Trust, but verify. Or don’t trust, and verify.

Security bugs cost more to fix the longer they are allowed to exist.

Never assume, always check.

Management by fact trumps management by belief.

As humans, we make mistakes. – From errors in judgement, to misconfigurations, to mistakes, to creating fallible products.

Defense in depth, security in layers.

If you can’t do the fundamentals of security correctly, you won’t do any better with complex, automated tools. (Present edit: I have always found this tenet to be important, and it’s something I always tried to interview new hires for. If someone knows the fundamental building blocks, then they can wield and understand the big power tools…or the weaknesses they have!)

Customers do not pay for invisible security that they can neither touch nor see.

Attackers have far fewer laws, ethics standards, and constituents they need to answer to. They don’t necessarily need change mgmt and various layers and people to approve changes or operations. Attackers maintain an agility over slow-moving business due to the nature of business and large groups of stakeholders.

Security geeks with a strong security mindset will always want the best protections. No company can afford the dreams of a strong security geek. Tempering this tendency to consider the issue as a 0 or 1 is part of the battle of a security geek. Some call this battle the “alignment of security with business” or the move of security geeks to being more “non-tech-friendly.” There *are* exceptions, especially if you’re being paid to give the extreme security answers, even if you’re not always given the budget green light. Know when you are part of that role. This might be called reconciling your security ego and security id…  (present edit: Basically, I’m trying to say that the security in a business is a constant balance of the grey area between perfect security and no security. You put 10 security geeks in a room and ask them to design perfect security, you likely will get the same answer from all 10. But ask them to fit security into Company XYZ, and you’ll get 10 wildly different resultant answers.)

Do not let the media solely guide your security culture. – Cyber Security is the new darling of mass media. Since security is not absolute and will always be broken and security at some point has to trust something else without assurances, then security will always be potentially broken (no matter how insane or movie-script-like the scenario is). Likewise, security will always ultimately depend on fallible people. Thus, the media will forever have something to wave around when it comes to security, or insecurity incidents. And thus, the media should not be our guideline or focus when it comes to evaluating our security stances. The media only provides for measurements of security theater (which itself is important to keep in mind, but does itself not convey much real security value). Similar to “reality television,” media loves to point out failures in security.

Security is real-time, both in technology and actual incidents. Try not to live in the past, with past technologies, and only aware of past techniques.

Don’t forget the past. The past is a basis for our fundamentals, and the fundamentals still suck.

You WILL be the bad guy. Because for every security decision you make, someone can come back to you with, “But you *caaaaan* do it this insecure way, right?” Most often, security is a matter of a person or group of persons drawing a line. We love it when we can say something is not possible unless you do it secure, but hate when we only have “best practice” or “policy” or “security” as the only reason.

People (Users) follow the path of least resistance. If they’re allowed to do something, they’ll do it. People won’t police themselves when their convenience is impacted. They’ll keep doing it until you discover them doing it and provide some punishment (like parking in the visitor’s stall once…and then doing it until threatened otherwise.)

The packets never lie.

User education is a long-term behavior changing initiative. Don’t expect radical results in the short-term, but still take any moment you can to provide knowledge and advice to others.

I wrote this post as a draft several years ago. This isn’t really finished, but I thought I’d post it anyway.

 

A friend of mine works for a small company that recently bought an even smaller company on one of the coasts. That smaller entity recently experienced a security breach. While this isn’t a juicy attack or really anything beyond your everyday opportunistic breach, it can certainly be exotic for a small business that doesn’t experience “real” breaches very often at all.

The scenario.

On Christmas Eve, about 8 months after the acquisition, users from that company reported issues syncing their iPhones to the company Exchange server. The initial admin to investigate found suspicious issues and called up to my buddy’s IT team.

Turns out an attacker had been pounding on an externally accessible RDP session for several months. The log files are spammed with attempt failures. The firm that manages these servers for the newly acquired company prefers to access the servers via RDP sessions, which are allowed via an Any->Server:3389 rule in the firewall. The attacker guessed the administrator password, logged into the RDP console, and had full access to the system.

Oh, and this system isn’t just the web front end for their Exchange infrastructure, but actually is the Exchange server.

Once inside, the attacker created a new local admin account named “Common.” He then installed Filezilla. I imagine he did so either to exfiltrate data from the server (no evidence of that) or to upload his tools to the server (evidence of that). There are no egress firewall rules, but ingress did limit traditional FTP connections. So the attacker configured the Filezilla service to use port 80. This is what triggered user uproar about email sync issues.

From what I know from my friend, the attacker tried to run a tool called MassSender.exe, and a quick glance at evidence indicated the motive for the attack was to acquire a new spam-generating server. Once that FTP service was found and full realization that this was not just an email front end system, but the actual Exchange server, my friend backed off and brought in a third party for full analysis. Through this whole process, some remediation steps were taken, but the system in question remained functional and live throughout.

So what went wrong here, or what lessons can be had? Warning: I do make a few presumptions here, but nothing completely wild, and I’ll try to make mention when I do.

Prevention

1. Change/restrict default admin account – The local administrator account should be renamed.

2. Limit access or don’t use RDP for true remote management. – RDP open to the world isn’t a good idea, especially in default configurations. If you really need to, it might be best to limit via firewall rules what sources are allowed to talk to RDP.

3. Review your ingress/egress firewall rulesets. – Turns out every server had several firewall ingress points: RDP, tcp 80, tcp 443, even when those servers didn’t use those services. Firewall rules should only be allowing what you need, and are probably going to be different for various devices. A blanket standard won’t work. Essentially, this just illustrates lack of security-minded planning and regular firewall rule maintenance. The home office was surprised to learn of these allowances.

4. Administrator password – I don’t know how difficult the administrator password was, but clearly it was eventually guessable via brute force. Further, it was the same password across all backend systems, but the attacker never went further than the first server. Really put some thought into making all of those passwords very difficult and unique across servers.

Detection

1. Check logs – Always easier said than done, I’ll just say that evidence of a brute force attack on RDP, failed logins, was spammed in the logs for months. No one noticed this.

2. Installed software – Do you ever want to now know when software is installed on your servers? You should inventory and/or somehow check on the appearance of new software. It’s very noisy for an attacker to actually install something, but clearly it does happen.

3. New executables/New network access – This is pretty advanced, but you might want to know when a new process fires up, especially if it also accesses the network. Again, this is advanced.

4. Egress firewall rules and traffic analysis – Now, just having egress firewall rules doesn’t detect anything, but you should be able to interrogate blocked traffic to see whether you expected it or not, as well as perform some netflow analysis to maybe spot suddenly new trends or communication paths. This is also pretty advanced, as most people have more to do than sit and analyze this stuff, sad to say.

5. Disabling of security software – Yeah, the security software was disabled by the new admin. This shouldn’t normally happen and something should flag it, from services monitors to centralized security management dashboards or log analysis.

6. New accounts/new admin accounts – If you do any log analysis, this is an absolute bottom-of-the-barrel item to watch and alarm on. If a new account appears, you want to know it. If a new local admin account appears, you *really* want to know it.

7. Users and admin gut feelings are still great detectors – Security doesn’t like to admit it (even operations doesn’t), but some of the best detection mechanisms will always be the users as well as gut feelings from admins who just feel like something is wrong, out of place, or a quick glance at logs while passing through a server catches their attention. It sure would be nice that detections could happen without these things, but always, always, always remember that at least you have this layer. It’s still better than being told by authorities or a third party that you’ve been fuxxed.

I wrote this post as a draft several years ago. I don’t plan to finish it, and honestly the moment has passed even more than it was passing at the time of writing this. But I like what I was doing here and wanted to preserve it and not keep it as a forever-draft.

I noticed a bit about community and blog commenting and such over on the Securosis friday summary last week. It sparked some thoughts I wanted to get down. I’m going to steal the part that got me thinking:

Back when we started the [Securosis] Friday Summary the world of blogs and social media was much different. RSS feeds were the primary means by which most of us sucked down our news, and we tended to communicate through cross-blog links and comments….
Since then a lot has changed. People blog a lot less, and there are far fewer discussions across blogs commenting on each other’s posts. Much of this has gone over to Twitter – which is sometimes good and sometimes bad…

First, my own observation mirrors theirs. I still get a lot of my news and discussion from RSS feeds. I still personally comment a ton, but I will say that I do see a lot less commenting overall on other blogs, both from readers but also from the authors. And much of the (stunted) live discussion takes place on Twitter, and any breaking news will come first from my Twitter feed updating in front of me (huge benefit!). There’s no arguing that at all. The downside is how ephemeral Twitter is. If you’re not outright watching the feed as it goes, there’s really no scrolling back to catch up on your day. This reminds me of days on very busy IRC channels years ago.

I wasn’t involved and I don’t know them personally, but I remember times when the AShimmy blog would get into back-and-forth blog postings with other blogs. These days, this same situation will occur in Twitter. And if I’m not there to watch it, it’s gone and the group dynamic has missed me. Likewise, if I’m not actually already following those participating parties, I’ll miss it (something that irks me to absolutely no end with Twitter). This means you’ll involve the people who already know and are present at the time, but cross-blog discussions mean someone can watch and get to know the authors or even participate a few weeks later. Pulling new people into the discussion can work by accident with blogs, not so much with Twitter. (present edit: I’ve actually come to disagree with some of the Twitter feelings at the end of this paragraph.)

I’ve long been a proponent of web forums; I still think they’re the ideal place to share discussions and build community in an online world with people of similar interests. I’ve long been a consumer of those services (I still comment quite a lot in the security arenas!) and even been a leader in a few (online gaming communities around Quake and UT, primarily). So here are some “community-building observations” that apply to blog commenting and social communities and not just web forums. (I’ve made a similar post in the past.) (present edit: I still believe in forums, but their time is also passing by now. It’s hard to be a contributing member of more than just a couple forums or communities, and these days you’re left with Twitter, Reddit, maybe some LinkedIn or FaceBook conversations, but beyond that it’s difficult to find the time to keep up. I think what I was really going for here, was basically what Reddit has become today: a partly-ephemeral threaded community board.)

1. Always respond. – If someone posts on your site/discussion/forum/blog post, always respond in a positive and public manner. Others that see that interaction will know you’re present and it may encourage future participation. Likewise, it you’re not present, unless the community has taken off and can guide itself for periods of time, it will absolutely depend on you and reflect your participation. In one UT forum long ago I earned the reputation of always replying to almost every topic. This was true, but while I don’t think I was all that integral to the community being a success, that sort of behavior does not hurt it. It may in fact give more character and actually spur further discussions!

2. Don’t dominate discussions. – By this I mean don’t dominate individual discussions and quell other people’s ideas or opinions. You can be the one who dominates new topics and bringing them up, but always make other people feel like they’re important, respected, and contributing. No one likes a know-it-all, and no one especially likes one that knows he’s a know-it-all and pushes them on others. Be a bit vulnerable, ask for ideas, and if someone else ends up being a dominant presence in the community, that is actually a good sign.

3. Don’t let stagnation develop. – Nothing kills a community more than a sudden absence of new content or discussion or topics. Do this, and you might lose everyone you had before and have to start over from the beginning, only with the stigma that your community died once and may die again. Even if you’re the only one posting, keep posting.

4. Embrace anonymity. – Especially in a security-related community, you really need to embrace anonymity. We’re a hyper-paranoid and privacy-sensitive group of people, and if you want a solid cross-section of persons talking frankly and openly, we need to embrace anonymity. Sure, they can use their real names and reveal their employers or maybe leave themselves open to be tracked down, but that needs to be their decision. Also, don’t ever deride someone for a valid opinion just because they made it with the veil of anonymity. You might have a point, but so do they. Embrace that. (Likewise, keep in mind your female participants who may have a wholly different experience in digital life than their male counterparts.) (present edit: This is becoming less of a thing. People use their real names far more often now thanks for Google+ and FaceBook and even Twitter to a degree. But also, most of us end up meeting each other through job or con networking anyway. Still, some of us definitely still prefer the old school screennames…)

5. Reinforce the hardcore. – A nicely growing community will likely have one or more “hardcore” persons who participate far more than others; maybe they comment a lot, maybe they enter lots of discussions, maybe that start lots of them. Either way, recognize them when you have them, and make sure you listen to, include, and encourage them. In a way, having some “hardcore” participants in your social circle you have is a way of measuring success. If someone regularly comments on your blog, encourage them or say hey via other channels, or whathaveyou. This doesn’t mean walk on eggshells around them because they’ll make or break you, but just recognize that they’re integral to keeping things from being stagnant and in driving further discussion and community growth. I think many, many services online are made or broken by their hardcore constituents, and they really need to be carefully tended, and yet not over-tended… Bottom-line, just the fact that you have to deal with this group on any level is a good sign.

6. Encourage and welcome the new blood, but let them control the exposure. If they reach out, reach back. – Don’t force new people to introduce themselves, but embrace it if they do. Never let an introductory presence go unnoticed. Always respond, and ask engaging, interested questions. If they express interests or expertise, probe that and make them feel valuable or interesting. But don’t force it. Some people will lurk for a considerable amount of time before participating, but others will dive right in with newbie questions. Embrace all approaches and positively reinforce them.

7. Actively draw people in. – You don’t build something and expect people to find it. You have to go out and draw people in. If you want people to comment on your articles, you need to get them to first see your articles, and then demonstrate that you’re interested in comments. This usually means commenting on many other blogs in turn. It takes a lot of effort and time for a community to be self-sustaining as far as new members goes. Again, your hardcore will help with that, as will just being a positive place for people to participate in, and suggest to others. But for a long time, you’ll need to funnel the people in, either with compelling content or brute force. [In my gaming sites, I had it easy with well-respected gaming tournaments bringing in people, so this part was easy. In something like BackTrack forums, their software brings people in.]

8. Embrace off-topics. – Just take a look at any forum for even niche topics, or any group of Twitter followers and you will see that “general” or “off-topic” discussions often will be the busiest places in a community. Let people fraternize and talk about other things, and give them a place to do so without watering down the on-topic stuff. I also consider the health of the off-topic discussion area to be an indicator on the health of the community.

9. Practice design/navigation simplicity. – This probably applies directly to web forums, but please for the love of all that is pure and sweet, keep things simple. Don’t make 20 nearly empty forum boards for various topics. Make 3 (on-topic, off-topic, site help) or even less. I really desparately hate, as a new user, trying to find where I should be going. Growth of sub-topics and separate forum sections should grow organically and only as-needed for the community. Only make a new section if there is already a need to populate that section with content that is getting in the way of something else. This helps make sure you don’t wind up with 1 forum with traffic and 15 stagnating ones; a quick glance by an outsider will reflect more stagnation than use.

10. Be clear and consistent with your content policies. But be reasonable. – Primarily I intend this advice to be about images and avatars used on the site, and primarily to make a site viewer-friendly (safe for work, safe for kids, safe for family…). Let people be themselves, but make sure your site is viewable by the people you want to attract during times they are available to interfact. For a security/professional board, that likely means being work-friendly, so no thong-clad avatars nor signature smiley banging another smiley. Letting this get out of control early is a bad deal, and letting anyone (even your hardcore group or best friend) bend the rules too much is asking for trouble in your community.

11. Be careful when dealing with abusers. – Don’t start a ban-war with abusers or start moderating and editing their contributions. Let them know where they stand. If you have a mature community and someone starts acting up, the group should self-correct them, or if that fails, an admin making the rules clear should fix things. Just be careful making a martyr out of someone or creating an “us against the unfair admins!” situation. This is probably the most difficult thing to dance around when administrating a community, and is largely inevitable. But for those of us in business and security, it shouldn’t be an entirely foreign concept.