Not much to say about it yet, but this is the OWASP Testing Guide v4. I’ve just not marked this yet, so wanted to get it put in here for future reference. I’ll likely add a link on the side when I do an update.
attempting to answer questions about getting into infosec
Every day, there are posts on infosec social media about getting into the field. And every day there are replies with a variety of answers. It’s a pretty hot topic, and has been for a long time, though probably fueled a little bit more than usual this year due to Mr. Robot and recent job reports about a void in infosec candidates. It’s probably also impacted by the feeling that, “I don’t know enough to be in security, these guys are pros!” and the subsequent perceived need to learn more.
I penned this yesterday to link to a blog post attempting to be a source to point such questions to, but scrapped it thinking it wasn’t useful enough. Today, I see the author has extended the list to be far more interesting and broad! And make no mistake; this is a hard question to answer, since every role is a little different and we all bring various bodies of knowledge and experience into the field from where we’ve tread previous; some new to linux, some new to windows, and so on.
Is the list perfect? Of course not, but it offers lots and lots of ideas for someone with questions about how to get a foot into the industry.
public mistakes lead to very public disclosures
News about the disclosure of RNC files is everywhere this week. But I just want to point to a comment thread about the topic over on Reddit. News like this is very watered down, usually, and we don’t get proper context due to lack of back-and-forth. Though, to be fair, UpGuard’s write-up is pretty thorough!
What’s the bottom-line deal? Data that should have been private was placed onto Amazon’s S3 cloud platform, and then made public without proper access control in place. Someone found it. Game over.
Mistakes (and it likely is just a mistake) like this are made all the time, but they usually get made behind the curtain of a private network. None of us hear about them, and they likely don’t get abused, or if they do, it’s found and fixed silently. But those mistakes made on the public cloud platforms becomes a very big deal. Get smurt about cloud security! Companies cannot treat data in the cloud with the same lack of care that they do with internal privileges and access.
sdr and rf signal analysis introduction by elttam
I saw a talk the other week about Software Defined Radios and how they work, plus how to get into the hobby. One thing I felt was just minorly missing was some context on how useful SDR may be. Just today, I saw a link on Reddit to another Intro to SDR and RF Signal Analysis. Since seeing the previous talk, I can actually begin to digest this information, but more interesting are the real world applications near the lower half of this post.
the penetration testing community discord…uh…community
Looking for a Discord community? I ran across The Penetration Testing Community the other day and joined up. I cannot attest to how useful the community is yet, but they’re white hat oriented and already have plenty of participation. Seems interesting, since I usually have Discord up somewhere, just like I always have IRC up at home. (This reminds me, I haven’t had an IM program up at home in…several years…this makes me feel old and makes me sad…) Like most (all?) infosec communities, this one is a bit beginner/student-heavy in population. If you join, be sure to read the rules, as they do require you to announce yourself, though I don’t think there is any effort made to validate what you say.
target puppet and ansible devops tools for mass pwnage
Quick read of the day: Enterprise Offense: IT Operations [Part 1] – Post-Exploitation of Puppet and Ansible Servers. While not quite on the scale of pwning a full domain with AD, pwning the system that is allowed to make configuration changes at root level on many other systems is still a juicy target.
security metrics, roi, and your twitter-esque purpose statement
Cybersecurity spend: ROI Is the wrong metric. I normally don’t bother with some of the major publications and their news and article feeds, but this one caught my eye and I enjoyed the message being presented, even though it still falls into the same traps as other articles from these publications: they sound important, but really don’t say anything concrete or immediately actionable. Still, it’s almost there for lines like this:
How do you want your network defenders to spend their valuable time? What do you want them to accomplish? What is the 140-character Twitter line that describes the essence of that effort?
list of things to know before hiring a pen tester
Doing some random morning news browsing, and I followed a link to “10 things you need to know before hiring penetration testers.” I love lists! I love good ones, because they’re good, and bad ones, because you can rip them up and point out good things by using the bad examples. They’re just really easy to digest. Like sushi. Anyway, so what are the tips you need to know before hiring and are they good tips? (Turns out they are!)
1. Strong Communication Skills. Ok, this article starts out strong by repeatedly mentioning something I hold very dear and consider myself to be very strong about: being able to adjust communication between deeply technical and far less technical for those not so inclined. I also really like the mention that technical skills can be taught, but communication skills are far harder. I think the one exception to this rule would be those people who are very reserved and quiet before either breaking out of their social shell or gaining that confidence and voice in what they’re saying. Some people just need past that imposter syndrome feeling, and they’re off to the races.
2. Beware of “Secret Sauce” Consultants. I didn’t understand this item from the title, but really this is talking about making sure findings are repeatable as described and accurate, and partly to know what you’re talking about for a pen testing methodology. I wish this item was longer and more expounded on, though.
3. Get Involved with the Security Community. Keep in mind this article is about things someone needs to know before hiring a pen tester, so this item is asking the hiring manager to get involved with the security community and go where the experts are. There’s not much to say about this. I’ve had managers who are technically involved and others who really just don’t know anything about the greater IT community outside the company. While both can be effective, one tends to be better tuned than the other.
4. Reputation is Everything. A really strange bullet point, but packed with very valid points. The exception, of course, will be entry level people who really do come out of nowhere, but I agree with the points that a pen tester should be known to some degree or other. They don’t have to necessarily be a keynote speaker, but participating and being involved to whatever degree and demonstrating some continued learning and passion should certainly be a factor. I really do like the parting comments about bewaring of egos and rock stars. There can be a certain level of “clubbyness” to a certain half-technical level of known speakers and infosec pundits who get really big egos and many followers/fans, but who are really only just complaining about the same things everyone else is and not offering much new other than stroking the ego.
5. Technical Acumen: Required. This seems obvious. Pen testing is not a task you can just talk your way through. Yes, you can fake it pretty well, since no one hiring you may be smart enough to call the BS (“Sorry, I couldn’t find anything wrong…”), but ultimately that will always get found out, and we start talking about the previous point about reputation. This ends up being a really good bullet point about results and understanding tools, rather than just blindly wielding automated suites.
6. Well-Rounded, Recent Experience. This is a touchy subject lately. If every pen testing position required experience, we’d never get new ones. I get the points about needing experience; I actually agree that the typical pen tester should not be fresh out of high school or probably even university. But there are exceptions and there certainly are positions next to full pen testers that entry level persons can fill. This article appeared in 2014, and today there are many more opportunities to at least practice and demonstrate and build skills in pen testing activities. But the point is still really strong. To me, pen testing really should require plenty of real world experience in, at least, IT in general.
7. Hire Passionate Hackers. Maybe my favorite bullet points on here. I’ve done some participation in interviews for fellow IT admins in the past, and I always look for what I call the “geek side” of candidates; do you geek out about this stuff at home as well as work? And so on. I know that can lead to burn out, but I find it important to be passionate and enjoy this work, and to demonstrate that and be around others with similar passion. And I echo the quote in here; I love the challenge and solving puzzles and learning, but it’s very much about helping others be more secure and make them better, whether that be fixing technical holes or educating on practices.
8. A Willingness to go Off-Script. Being creative and being able to wield those surgical tools rather than only knowing automated suites. That’s the bulk of this point, but I dig that it hints at being able to employ some tradecraft, i.e. evasion and covert practices that change with every engagement.
9. Know that a Pentest is Only Part of the Picture. Pretty obvious!
10. Don’t be Afraid of Pentesters. I like this point, too, and it’s not as obvious or one that I likely would have thought about. Don’t be afraid of the testers; include them in your operations. Don’t be afraid to direct their work/output. A really good point and a great way to close out the article.
breaking out of restricted windows environments
Just a quick link drop here for future use: Breaking Out of Citrix and other Restricted Desktop Environments. This list is Windows-centric and includes some old tricks that likely don’t work anymore. But even looking at some of the older techniques illustrates the creativity involved in bypassing restrictions (and how features can be abused in unintended ways).
hunting malware in memory from endgame
I tend to usually avoid vendor blogs since they are usually self-serving as far as presenting a problem in a singular way that makes their product the answer; basically marketing posts. But I do appreciate posts that offer additional knowledge beyond just the marketing slant. Endgame has a post about hunting malware threads and processes in memory. I highlight this post, because it starts out by going over various methods that malware attempts to dig into memory and hide. And then it has a paragraph about detecting things like this using a PowerShell tool, Get-InjectedThreads.
Super cool information for someone getting into malware analysis or detection.
on your own for microsoft update monthly reports that look decent
A few months ago Microsoft changed how they tell us about product updates. Rather than give us neat little bulletins and MS18-001 style summaries, we have to now pull our own information from their repository. For most of us, this is annoying, since a month with 12 “updates” which themselves package an average of 6 actual updates for 5 affected products (30 actual patches per update, for example) used to still be one single “MS18-001 Description” entry in our ledgers. Now things are dirtier and annoying (change!).
But not all is bad. Now, enterprising persons can craft their own method and format for pulling monthly information out of the repository. Such as this code snippet which is simple enough to post here for illustration purposes, but was taken from github user JohnLaTwC:
## Uploaded by @JohnLaTwC ## Miss security bulletins? Create them yourself in a few lines of PowerShell: ## First, get an API key to the MSRC Portal API ## Sign-in in here: https://portal.msrc.microsoft.com/en-us/developer, and click on the Developer tab, click the Show button on the API key. ## Install the MSRC PowerShell cmdlets, Run in an Admin PowerShell: ## Install-Module -Name MSRCSecurityUpdates -force ## In a normal user PowerShell: Import-Module MSRCSecurityUpdates -Verbose:$false Set-MSRCApiKey -ApiKey "your-api-key" $timeperiod = Get-Date -Format yyyy-MMM # Older style report #$fname = 'MSRCSecurityUpdates' + $timeperiod + '.html' #Get-MsrcCvrfDocument -ID $timeperiod | Get-MsrcSecurityBulletinHtml | Out-File $fname #Invoke-Item $fname # Newer style report $fname_cve = 'MSRC_CVEs' + $timeperiod + '.html' Get-MsrcCvrfDocument -ID $timeperiod | Get-MsrcVulnerabilityReportHtml | Out-File $fname_cve Invoke-Item $fname_cve
This looks super simple, and it is, but that’s because the heavy lifting is in the requirements needed from the comments at the top of this code block. You need to get an API key and install the MSRC PowerShell cmdlets. Ok, that’s not really heavy, but there are options for decent-looking reports without spending a ton of time.
In a previous life, every month I would compile information about the monthly Microsoft patches. For general information, I would include the MS designation, name, description/details with context for my business, URL, and applicable KBs listed out.
I then also added a few contextual points by pulling in CVSS scores, exploitability index, MS severity, impact, and whether the details are publicly known into the same pane. I also added in the scoring for a few other key vendors/services for further context and our own personal resultant criticality.
The above report actually poops out almost all of this information. It’s not crazy pretty, but it’s not as bad as exporting directly from the repository. And it does give me much of what I had before, all told.
detecting malicious actors on windows systems through logs
I think I saw this passed around on Twitter first: Detecting Lateral Movement through Tracking Event Logs [PDF] from the Japan CERT. The blog link actually goes into more detail about the purpose, which is to assist incident responders. But this can be equally useful to incident detection to highlight some log entries to look for that may indicate potential malicious actors. This is also useful for pen testers who are tasked (directly or indirectly) with testing or evading blue teams. Even in a lab, a pen tester can initiate some of these attacks or actions and validate what they see or what artifacts they leave behind on systems. Near the end, there are even supporting steps to make sure proper logging settings are in place to see these events. (Gee, tracking Executing Processes pretty much covers most of it, eh?)
And like many settings in security, the paper at least makes mention that there are considerations to make before making audit log changes. For instance, tracking executing processes (or written files) will generate a large number of entries in the logs, causing them to fill up and roll over or flood your log collectors or SIEMs and maybe challenge your backup capacity. As always, keep in mind the big picture when making settings/architecture decisions.
Very cool list. It’s things like this that I have a hard time figuring out how to save and consume. Do I add a menu link in “resources” to the paper, keep my own list of this somewhere, or just hope to remember I have it here?
keeping up with infosec
How does one keep up with the Infosec world? It’s easy to get comfortable and keep doing what you’re doing as change swirls around outside the window. Technology and security have common themes over the decades, but many of the knobs, dials, and talking points change and we need to keep up with all the new ideas and products coming along every few years. It’s a simple fact that security experts are often used as sounding boards for new technologies and projects, which means keeping up and learning are key habits.
As a corollary to this topic, answering this question also means asking how you want to present yourself to the greater community of infosec online and in person. Do we stick to fully anonymous screennames, switch completely over to real names, or some sort of hybrid in between? This is a personal decision for everyone, but something to keep in mind when putting yourself out there virtually or really. This can be screennames, usernames, email addresses, domain names, and profile details and pictures and avatars. It may even steer you towards or away from certain forums and medium. It may also be dictated by your role, for instance malware researchers may stick a bit more towards the anonymous realms.
So, how do we keep up?
Old School collab: IRC, web forums, mailing lists, blog comments, ‘zines, and even books. These are still used, but they’re a little less prevalent these days. Mailing lists are nice to lurk on when they aren’t broken by spam filters. Mailing lists feel like they’re on the dying end of the spectrum, but does still remain as one of the better “push” methods.
New school social media: Slack, Reddit, Discord, LinkedIn, StackExchanges etc. These are still growing and are often only as useful as what you put into it. Reddit and LinkedIn are a bit more lurker friendly, but LinkedIn’s activity feeds are very noisy with only a few ways to manage it. I actually prefer Twitter as a news feed over LinkedIn, but mileage will vary.
Twitter deserves it’s own mention, as it really has become important for briefly meeting new people, feeding links to other information elsewhere (sort of filling the void from Google Reader), and getting quick notification of important events. If it feels like something major is happening like DNS is down or a major provider out, I often turn to Twitter to get a confirmation. Twitter becomes invaluable when at a con.
Infosec news feeds. It’s important to make some effort to keep up with incoming news and learning opportunities from blogs, infosec news sites, dashboards, exploit/vuln trackers and more. A huge bulk of this is still personal blogs to read, and I suggest Feedly to take care of a huge chunk of this segment.
Traditional news sources. It’s still important to keep up with some of the major events in the country and world, not just for impact on business and infosec, but to keep up with social talking points. It’s also important to know when something in infosec hits the mainstream news waves to prepare for incoming questions.
Podcasts and video. Both of these mediums kinda straddle the new and old school social media, but are more about delivering content to your eye and ear holes rather than more interactive formats. Audio definitely allows for a wide range of opportunities to consume (feet- and hands- and eyes-free). Video is still great for conveying highly technical topics.
In-person networking, cons, meet-ups both formal and more informal, local or more remote. These are great opportunities to learn from others and grow one’s own analog network.
Vendor demos, webinars, and events are great places to meet others, meet vendors, and see new products and features which are likely responses to direction in the overall industry.
Self-study, learning, and playing for fun. In order to continue to learn and grow, you need to enjoy the industry and process and work. And this means being a geek during down times and learning some new things, often on your own with self-paced study and tinkering with new things. These new things are often found as follow-up tasks to many of the above learning and exposure opportunities.
More formally, training and courses are available to do more structured and tracked learning of new things.
Lastly, getting back to how one presents oneself to the great digital and analog worlds is the tenet of giving back to the great community. This could be just participating with the mediums up above, but also by keeping one’s own blog, github, wiki, checklists, tools, scripts, how-to’s, or other content. It’s about giving back and being visible.
PS: Be cognizant of two more thoughts. First, think hard about mixing your infosec activities with your personal ones, and that includes the way you present yourself online. Again, this is highly personal and there’s no right answer, but sometimes you want to make sure your personal hobbies and activities are separated from your infosec world. This is probably most applicable to a Twitter presence. Second, and conversely, don’t be afraid to plug some hobbies into these activities. A great example would be browsing Reddit or populating Feedly with blogs and news feeds for something you’re interested in or have a hobby around. Including sections and opportunity for these will make it more likely that you’ll check back in and consume these activities, and allow a little diversion from the same old intense firehose of security information.
building a malware detonation and analysis environment
Via Reddit, I saw and really like this blog post about how to “set up your own malware analysis lab with VirtualBox, INetSim and Burp.” Oh wow, INetSim fills a nice role in this, but the author also does go through almost every step you need to do to set up a couple victim boxes, an analysis box, and get visibility into the basics.
My lab is nearly equipped right now to do this, but it could with some adjustments based on these steps. I’ve never done full on malware detonation and analysis before. I have done malware analysis to a smaller degree many years ago on actively infected production systems. It’s definitely more sane to do this in a controlled, throwaway environment! Filing this one away to do on a rainy day where I’m inspired to do some malware analysis like this. I really dig the INetSim and Burp setup.
pushing sysmon monitoring for security ops
Saw this on Feedly as I futiley try to keep up with security feeds: How to track that annoying pop-up. Yeah, yeah, yeah, sysinternals, sysmon, tasks, blah blah, sort of junior sysadmin stuff. Wait, what is this at the end of the article? A throwaway mention of and link to SwiftOnSecurity’s sysmon-config custom config file for monitoring systems. Now we’re talking!
You can pay the bucks for a badass product to do your system monitoring for you. Or you can roll your own temporary solution for small troubleshooting tasks. And then there’s that huge grey area in the middle for small-medium environments where you might not have the budget but still want to do better logging. This looks like a nice way to hit the ground running with sysmon on the cheaper “roll your own” side of things.
I’ve, of course, used and considered SysInternals tools as toolkit staples since before I started professional work in IT. And yet, 15 years later, they still surprise me! I hadn’t seen that Sysmon could be used in such a way. Some tips are available here, and the official information found here.
I now need to remember to set this up on my lab boxes every time I refresh them…