mirai source code and password list revealed

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.

setting up and running metasploitable3

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 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…

diagnosing blog depression

It’s interesting to get by blog back up and read some of my last posts and orphaned drafts. Honestly, 2014 was pretty rough for me for a few reasons, which contributed to my blog just staying down.

I was really busy at work with some large projects and lack of staff to help out. In 2013, both Google Reader and Twitter decided to make life more difficult. I still haven’t completely moved Feedly into my regular list of habits to replace Google Reader, and I still bounce a bit between Twitter apps once Twitter started turning away all the third-party ones. I have, however, made room for Reddit…

I also was finding it difficult to say anything new about security on my blog. I was sort of getting sick of the same old thing, as well as just posting links to the same things others were posting about it. It’s a lot like retweeting a tweet that has already been retweeted 24 times in your own feed. What’s the point? But I was also just not having much new to say.

And then in early 2014, my blog’s server’s motherboard died out.

On a brighter side, I had some nice promotions at work due to the efforts, cultivated a new hobby/habit with tabletop gaming with friends, and found good companionship. And now have the chance to pursue security as a full time job.

This storm basically just led to me doing other things with my own time. Until now. 🙂

pragmatic security laws and rules to live by

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.

lessons from an opportunistic breach

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.


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.


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.

healthy community growth

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.

need a vulnerable vm for some play time? hit vulnhub

Years ago, there weren’t really good listings of various vulnerable virtual machines, vulnerable web apps, shady packet captures, or other challenges that you could learn from, so I kept my own list here on my site. These days, however, Vulnhub.com offers a far better listing than I could keep. So I might reorganize my “learn” section of links, but for now, these will stick around and I’ll refer to Vulnhub for my damn vulnerable VM itch.

general concepts in tuning a siem

I wrote this post as a draft several years ago. I don’t plan to finish it, and thought I’d just publish it out now. This is not really complete, but I did fill in a few gaps. Also taking the time to hate on formatting things in WordPress…nested bullets are making me swear more…

I’ve spent some time tuning a SIEM as part of my day job. I thought I’d share the general steps to do this. Sadly, I can’t be too technical without becoming specific to the tool(s) I use, but I can at least outline the general concepts.

  1. Gather logs from your devices/apps into your SIEM.
    This is typically an easy process, and every SIEM vendor will tout how easy it is. Don’t be fooled, this is easy by design, and not because their tool is particularly easy. It’s easy to suck in Windows logs, Linux logs, and even easier to catch the flood of syslogs you can send to the SIEM. Vendors will always tout how you can be up and running (often they will say, “gathering logs” without letting that sink in that a SIEM does more than just “gather logs”) in 10 minutes, a half hour, an hour, or a few hours. The hardest part is just finding all the logs you want to send to the SIEM.Assume you’ll be adding new logs as you go for devices you either overlooked early on, forgot about, or didn’t even know you had (high-availability pairs, dev environments…). And make sure to devise a plan to ensure that new devices get discovered or configured per a build process to get into your SIEM.
  2. Make sure your SIEM understands and adequately parses the common logs you send it. Just because a SIEM can suck in the logs and archive them away, doesn’t mean the SIEM is configured to parse out the contents and make decisions on them. Most common devices and sources are fine, but some of your more uncommon devices aren’t going to be set up without special effort. You can get assistance from the vendor, but often they will tell you, “You tell me what you want, and I’ll set it up for you.” So…make sure you know what you want! Your time is usually better spent looking at the logs you get, demonstrating the activity you want to alarm on, catch the log, figure out what is unique about it, and then making your own alarm based on that uniqueness. Repeat ad nauseam.It should also be mentioned that you need a process in place to make sure your SIEM is still working properly and that logs are still showing up. It’s fine if you event on incoming logs that indicate badness, but are you looking for a total absence of logs as well? Hopefully your SIEM can raise these issues to you in more than a dashboard you have to eyeball manually.
  3. Tune out the noise as much as you can and tune in to what you really want to know about.This part really forces you to think a little bit like an attacker and what she will do against your devices and what it will look like in your log files for various devices. This often includes two different levels of monitoring (maybe more if you decide that you get operational value out of the SIEM, rather than just security value):

    • events of interest in the logs
    • actual generated alerts/alarms that are sent to someone or raised for someone to look at

    This is also a very subjective piece of the puzzle, and somewhat artful as well, as you creatively ignore what you don’t care about, without accidentally ignoring too much. Probably will help to talk to your SIEM vendor on any tips they have to avoid performance problems with filters or log rules. Maybe their device will bog down when you give it too many filters, or maybe it will bog down when you don’t give it enough! For instance, if you log your VMWare ESX server syslogs, you’ll find that you literally do not need 99% of what you get sent.

    For every event you generate, ask yourself:

    • does this give me value towards alerting/detecting an incident in progress?
    • does this give me value towards guessing that there might be something strange happening?
    • does this give me value in finding more about events around an alert or incident?

    If an event is coming in all the time, and you know you’ll never consider it an event of interest, try to configure a filter for it. But be careful!!! For every filter you make, you create a blind spot. For instance, I have an account that leverages CatTools to log into various network devices and back up the config files, and this runs multiple times daily. I don’t ever want to know about these valid logins, so I ignore such log entries. But this means if an attacker gets into that account, she can use that account to get into the same network devices and I’ll be blind to those log entries. A better method might be to put a threshold on the frequency of logins per hour. Hopefully, though, any further manual things she does with that account on the devices will get flagged, since I really want to have an event for every actual command run on some devices (we’re not THAT big that I can’t just turn around and ask someone if they just did something…).

  4. Close the gaps in your logs by getting those non-standard and custom logs understood by the SIEM. This is difficult to do, and probably dives deeply into one of two options:

    • Send logs to your vendor and wait for them to properly figure out the parsing.
    • Dive deep into the guts of the tool’s rules, and figure out the parsing on your own.

    The first option leaves you at the mercy of someone else, but they will certainly be better at it than you alone. The second option is a deeply technical and possibly very difficult task that will takes lots of trial and error and time. The reward is great, however, if you can master your chosen tool’s rules and how to cover stuff that isn’t covered by default.

  5. Manage everything that is left in the alarms/alerts or events.If you have a SIEM in place and it is chomping on logs and generating alarms, but no one is watching it, you’ve effectively just made a complicated log management process that is only useful for forensic purposes, and does *not* raise awareness of security events or satisfy any goals for detection and response. If an alert comes in and it is an attacker, but no one looks at the alarms, then what was the point? I understand checklist security, but that doesn’t mean I will be satisfied by it.

    At a minimum, you should see positive, but non-incident hits from:

    • patches, assuming you also have a file integrity monitor in place, but at the very least a reboot should be noticed or maybe events for installed software
    • vulnerability scans should light up your SIEM (similarly, any pen-tests or other security reviews)
    • failed logins on various devices. No matter how much you tune, you can’t tune out every accidental series of failed logins and yet still be alerted when someone malicious is doing it. Sometimes it just takes one strange attempt to log into a network device as “root” that is important to see, yet you clearly don’t want to be told every time Sales Guy Bob mistypes his password three times in a row. You want to know when an account is locked out, but can’t tell from a SIEM whether that was again Sales Guy Bob doing it.
    • essentially, anything with a threshold value will be tripped someday. If you only care when a single device pings out to 50 different IP addresses, someday something will do that.
    • if you want to know that someone got into your border router and made config changes, you’ll also pick up authorized changes from your own admins.
    • user rights changes and account management are an every-day occurrence in a business, but it is common for an attacker to try to elevate their rights either on a local box or the domain. You should see hits for both. This includes new user creation.
  6. Lastly, test your alerts to make sure you’re getting what you need, and learn from the computer forensics disciplines.Generate some events that you would want to make sure you pick up if an attacker either attacked your systems or actually got in. Someone added an account to your Domain Admins group in Windows Directory? You better be watching that. Verify that you’ll see what you want to see. Be creative, and be informed about the forensics artifacts left behind in the logs that you can and should alert on in your SIEM.

old sites removed from the side bar

It was a bit sobering to go through the links I had for news and blogs. Almost 50% of what used to be around are no longer present. Some are gone entirely, some are just not updated anymore, a few have changed content. As usual, I just post my own last farewell as a list of retired links. Next up will be all the tools and other resources I had in my side bar. I’m not very happy with the style of the links. Each item should be closer together, but I’ll tackle that another day.


security suggestions for small or medium business 2016

It’s harder than it seems to come up with a quick list of 10 things a small/medium business should do when looking to implement stronger (or a first level of) cyber security. It’s a copout whenever I see a “top steps for security list…” and they go something like, “secure endpoints, secure servers, secure network…” You’re cheating by not saying anything actionable or consumable by relatively average admins and business users.

Here’s my current list of top 10 items an SMB should do (I’m sure I left something obvious out…).

1. Backups. – Mistakes happen. And when shit hits the fan, you need to have backups to restore to. This includes something off-site in case your live backups are bad. You should also have some idea of what to back up, and a general priority of what is most important for the business to remain solvent. This needs to include procedures to verify backups and perform clean restores.

2. Endpoint security software. – Commonly antivirus or antimalware software that runs on end user and server systems. These should automatically update at least daily. Admins should understand this software enough to be able to work with it rather than turn it off for whatever reason when it gets in the way.

3. Patch your systems (and software). – I don’t care if these patch automatically or if a patch management process is in place, but all systems need to be running a patched OS. Software should be patched as much as possible as well, but I understand that can be harder for businesses that do not have automated endpoint management tools in place.

4. Identity management (lock your workstation). – Uniquely identify every user and require strong passwords for their accounts. Do not share accounts. Know which accounts (user and service accounts) have high privileges on your network and thus with your data. Locking the workstation is a form of controlling/limiting unauthorized usage of the unique account assigned to someone.

5. Practice least privilege. – Users should only have access to what they need in order to do their jobs. This is mostly focused on data access, but also applies to system and network (or Internet) access as well.

6. Practice proper password principles. – Don’t write passwords down. Don’t share them. Don’t reuse them. Do make them complex. Do change default passwords. Do change them regularly. Store passwords in something that has some modicum of security (i.e. not a password-protected Excel file).

7. Limit physical access to your IT assets. – Keep network closets, servers, data backups, and other IT assets locked away from unauthorized access. This should also include limiting access to mobile devices and storage devices for theft and tampering prevention.

8. Deploy a network firewall (network segmentation). – For really small business, this might be limited to whatever modem/router comes with their Internet access. But for everyone else, they should have at a minimum a network firewall between their corporate network and the Internet with default deny rules in place. Permit rules should adhere to least privilege principles, again. A firewall between wireless networks and the rest of the corporate network is good. As a bonus, a firewall between workstations and servers is a good next step. But at a base minimum, Internet access into the corporate network/servers should be controlled by a firewall. Limit who can make changes to the firewall.

9. Limit local administrative rights on workstations. – For small to medium businesses, it can be a fight to pry away local administrative rights to systems, but it really needs to be done, not just for security purposes, but also for desktop support sanity (efficiency). This will help prevent malware from running as a local admin, and will prevent users from installing rogue software on their systems.

10. Understand and protect your important data and corporate assets. – Yeah, I’m slightly copping out here on the last one, but every business should know what data is important for business continuity or what data, if divulged or stolen, will result in business closure. Special considerations should be taken to ensure these assets are protected. Most important to this specific bullet point, though, is just making sure the business goes through the exercise of identifying what is vital.

BONUS: Get help. – Get help from staff or a security consultant on how to properly do IT security, both the steps above, and the next steps. And to keep aware of new threats (ransomware) and issues (0-days).
Ultimately, I hate making a list of just 10 things, so here’s a few more more that come next.

11. Email filter for spam/phishing prevention.
12. Web browsing filter.
13. Password protect wireless access and limit only to corporate managed devices.
14. User education and security awareness training.
15. Establish security policies and procedures.
16. Identify your industry regulations and compliance that you need to meet. Get help on these.
17. Establish hardware and software inventory systems. Know when something is lost or mysteriously new.
18. Run vulnerability assessments on servers/systems and prioritize/remediate findings.

terminal23 activity is ramping back up

Terminal23.net is back up and running! I’ve been absent for a few years due to life and a hardware failure. For years, I ran my site off a system sitting in the corner of my office, but its motherboard decided to finally die out. Life went by pretty quickly, but recently I got the itch to bring this site back up. I picked up a new motherboard and exported all of my contents into a proper format to move back up to a new hosting provider and into WordPress.

This is my first foray into WordPress, so I’ll be playing with the themes/appearance for a while here, and also doing some reviews of my old content to see what needs fixing. But, I have to say the export from MovableType3 into WordPress went far smoother than I had expected. The appearance is a different story. The current layout and theme settings are pretty close to my old site, but not quite close enough to my liking. Still, I’ll take what I can get in the short term here! The colors and general layout work for now. Maybe I’ll just code my own templates like I did previously…

The past 2 years have easily been my largest gap in blogging and having a web presence of my own since 1996. (I don’t count FaceBook or other smaller services.) A lot has changed, and yet a lot remains the same. Perhaps I’ll go into more detail as I decide where I want terminal23 to go or if I want to slice off a more personal blog or FaceBook presence off to the side.

I made terminal23.net for 3 primary reasons. First, I wanted to organize my own thoughts on security in a place that I could reference in the future, either to recall a tool, a script snippet, or just dump out some thoughts going through my head. Second, I wanted a curated place I could consume my favorite links that I found useful, from other blogs to web resources in the security world. Third, I wanted all of this to be viewable by any curious persons, especially those looking to see if I know anything about security and want to employ my services.

Looking back, I have 1724 published posts on this site dating back to 8/9/2004. Probably 98% of those posts are dealing with IT security to some extent or other, from tools to new scripts to commentary in general. During much of that time I had a more personal blog with 268 posts since 10/05/2001. And even older than that, had a site presence of some sort since 1997/1996, though anything from those probably only exist on a floppy in some box somewhere.

At the time of my site going down, I had a listing of over 469 other security blogs, news sites, tools, and various resources.  I do plan to bring those back, but they will take more time to check and port back in.

security articles to make your head spin

Are you looking for a security article that looks like it says a lot, but says nothing at all and ends up just making your eyes spin like that beer you’re going to chug tonight due directly to reading said article? Well, here’s four of them in succession! Just like those days in college with back-to-back-to-back-to-back vodka shots!

Over on the Tripwire blog, Pete Herzog guest writes several articles, starting with Three Ways Your Security is Actually Hurting Your Security. The other two articles are the second and third ways, but this one actually tackles: “You don’t know your attack surface.” Ok.

Second is Unbalanced Security is Increasing Your Attack Surface. It doesn’t take Pete long to get into two things. First, pimping OSSTMM. Second, spitting in everyone’s face who actually patches and updates software. He does both here.Oh, and we force in a mention about his own security awareness training event at the end. I’m not sure where security awareness came into this discussion before then.

Next is Security Solutions that Fight for the Same Resources. Honestly, I’m not even going to go over this one. I have no idea what it’s trying to say. But we do stream-of-consciousness our way back to security awareness and his own workshop.

But wait! It’s not just three articles. Despite only one comment on the actual articles, we have this admission: “…we received many questions and comments on what it all means. Questions like: What products do you need to…” Right. So this series continues by not answering these supposed questions with The Meaning of Security Hype. (Ho boy, the irony.) This one is fun, since Pete talks about how bad security marketing is and how they market you product categories like antivirus and antispam and firewalls and web app firewalls (that section is a mess), and antivirus again and then network monitoring. Nevermind the fact that his own standards categorize things.

Now, having read various posts from Herzog over the years, these articles are not surprising. He tries very hard to make sure that analyzing security looks as tough as possible, so big and complicated and broad and frought with analysis paralysis and the impossibility to get the right answers that you need something like, oh…ISECOM or OSSTMM, to make sense of it all to formulate an effective security plan. Oh, and yes, they’re Herzog’s products. Go figure. (Speaking of things that make your head spin and cause you to actually get nothing done, go check those out.)

popping boxes at the pwn2own contest

NakedSecurity has a nice article on the current results of the CanSecWest PWN2OWN contest where attackers target popular web browsers and companion products for some public shaming. Between PWN2OWN and PWN4FUN, all 4 major web browsers (IE, Firefox, Chrome, Safari) exhibited security holes, with Safari even giving up privilege escalation into root.

Running IE is still a riskier position than running another browser (tempting attack surface, integration into OS, difficulty implementing user-gated authorization of scripts). But the takeaway from events like PWN2OWN is every browser has issues. Users still need to browse the web with care and turn off globally allowing scripting and other packages, no matter which particular web browser they use.

I always get crap for how web pages look in my browser as I disable so many things that sites want to load, but at least I have a little bit more assurance in the added security of my web browsing.

thoughts on star wars the old republic

I’ve been playing SWTOR since release, and thought I’d share some thoughts on it. In WoW, I really preferred playing a healer or even a tank role, and in SWTOR I do mostly the same thing. I have a 42 smuggler healer, a 20 jedi guardian tank, and a 22 bounty hunter tank. Plus I’ve essentially started a total of 8 toons, but the others are sitting at their Advanced Class choice and are either parked for the future or do some crafting for me.

First, I just want to say I love the Smuggler healer. I’ve played healer types for many years, and really like the mechanic of the smuggler, especially while I level, since I can indefinitely heal my companion against many heroics and random champions/elites in the world; I can solo content most others cannot, even other healers. This is due to the energy regen/balance that a Smuggler has to maintain, rather than your traditional mana pool which will always go down faster than it regens…

Second, tanking is not as easy as WoW (seriously, it’s *easy* since Wrath), and not quite as fun. Lots of blaster-firing ranged mobs force me to play tag quite a lot. In WoW, tanks have it easy with AoE threat, other than Druids who do have to play tag. Most SWTOR tanks feel more like a Druid tank, with the slight exception of the Bounty Hunter who has a few extra AoE tools. Still, if the DPS in the group decides to go after their own targets, they’re going to get a tongue-lashing from the healer because they *will* pull aggro on their own targets. Tanking in SWTOR is not designed for the tank to hit two buttons and all the enemies stick to him like glue. This is both good (skill! fun!) and bad (a bit frustrating). Just like leveling the Druid as an instance tank!


– I care about my freakin’ character’s….character! Yes, I care about his motivations, friendships, choices, backstory, and forward story. In WoW, I didn’t even think about it because I’d never had a game until Skyrim and then SWTOR which gave me a taste of that sweet, sweet nectar. I love that you can make choices in responses, dark/light alignment, advanced classes, and other things that are really either/or choices. Too many games end up allowing you to eventually do everything, but their is some power in forcing a hard, permanent choice for players when done correctly, and I feel SWTOR hits it correctly. I think in part because there’s no optimum answer. Many games with a hidden alignment choice (good/evil) end up agonizing players because they want to know which option is either the best one or ends up being the one they want, but in SWTOR, it really ends up not mattering to the min/max audience. Once you accept that and get into the character, it’s very satisfying.

– All the classes/playstyles. The game touts 8 classes, but really there are many more. Each of the 8 classes makes a choice at level 10 for their Advanced Class. Each Advanced Class then opens up the 3 available talent trees (2 unique, 1 shared between both Advanced Classes). This means that you could make 16 toons, and not have any duplicated talent trees. Honestly, it’s a bit less than that, since some characters will play relatively similarly, but there are more playstyles to experience than just the raw 8 classes. (In WoW, there are 10 classes; and while there are multiple trees in each, you can always respec into them once you get max level. In SWTOR, you can’t respec to the other Advanced Class. In WoW, you’d only ever make one Horde Druid, but in SWTOR, you can make a Scoundrel Smuggler and a Gunslinger Smuggler on the Republic side, and still be entirely different.)

– Story, story, story. It’s freakin’ Star Wars. And it has great storylines! My smuggler has ‘scored’ with 5 ladies so far (one a repeat customer), my imperials have executed and tortured multiple innocents, and I have an ability called “Shoot First.” (Yes, my smuggler has that. Yes, I love Bioware just for that one thing.) The way story stuff is integrated into the world is really neat, and really does change the feel of an entire planet’s experience.

– The Dark Side is really dark. In fact, strikingly dark. I tortured, executed, and murdered at least 4 people before my first Sith was level 10. Many Dark Side choices are actually uncomfortable, and I applaud Bioware for being ballsy in that regard. The original Star Wars movies were not kid’s movies, but they were kid-approachable. The later movies were kid’s movies, and their non-lasting impact is increasingly clear.


– No LFG system. Granted, this is a rather recent WoW addition, but oh my god is it awesome. I honestly put the LFG tool in WoW as one of the top two additions since launch, if not the top addition. For reformed hardcore players like me who just want a casual experience on my own time, the LFG system is an absolute godsend. SWTOR needs one. Badly. (And it is in the works, supposedly patch 1.3, which is probably 3ish months away or more…)

– The UI needs work. I really miss a few things like seeing target’s target and focus windows, especially as a healer/tank role. The UI also needs a lot of help to assist with crafting and playing the auction house (galactic trade network). It’s really a pain in the ass to craft, right now. I do kinda like that macros and addons are not supported, since you kinda eventually become a slave to them, but I do wish some of the more useful changes to the UI were included.

– The level designers made great, beautiful, HUGE maps and planets and buildings. But damn are some of them unnecessarily huge. They’re great to behold early on…until you have to run through them to make sure you didn’t miss a quest-giver in the corner of the second floor of the Senate. Oof!

– I kinda wish the dialogue wheel, where you choose your character’s responses to various cutscenes, could use work in accuracy. I really dislike choosing what I think is a witty response, only to have my guy say it completely unexpectedly and with a sarcastic, mean tone that I totally didn’t anticipate and pisses off my companion.

– I am looking forward to more content. In WoW, you could level up your toon in Kalimdor. Or Eastern Kingdoms. You could do so in the Dwarven area, or the Elwynn area. In other words, you could level 3-4 characters and never see the same content/quests until quite a bit later into the game. For SWTOR, you really will see the same planets and quests with your second toon as you did with the first, though all the storyline stuff will be different. Still, I look forward to more content in the future so that I can level other toons in different areas. (This might be really hard, since the story line stuff that goes up to around level 35ish is pretty set on specific planets…Bioware may have pigeon-holed themselves in that regard, but we’ll see!)

meetup.com suffering through sophisticated ddos attack

So I’m reading over at Naked Security of Meetup.com suffering a DDoS over the past week and a Meetup.com CEO post that said:

The extortion dollar amount suggests this to be the work of amateurs, but the attack is sophisticated.

Amateurs with a sophisticated attack. Wait what? Dropping the S word gives me Sad face.

Anyway, this is a great chance for discussion on how a business would go about preventing DDoS and/or reacting to it at the moment it happens (assuming some or no prevention in the first place). DDoS is not *that* sophisticated of an attack, but prevention and reaction is often sophisticated. Oh, and expensive.

Having not actually worked at a company that suffered a DDoS attack, I’d only be guessing based on research and second-hand info, so I’ll just sit around with some popcorn for the moment.

This is also a great opportunity for Meetup.com to show off what they *did* do for this sort of attack. Though I doubt they have a more technical blog, which is a shame.