IR, what I wish I knew a year ago

I know it has almost been a year since I posted anything in this thing, but with COVID pandemic and also starting a job were I am now in IR (Incident Response). I spent this time trying to learn new processes,procedures, and tools used at $employer. I tried to tell myself when I learned something to post about it, but it was just followed up with something else. So instead of that I figured I’d reflect on the almost year now in my current role and with a “if I could do it again” what do I wish I spent some extra time learning. While of course having a good understanding of the broad levels of Incident response (like having a base understanding of the steps of NIST (NIST 800-61) and some basic understanding of what to look for in logs/SIEM alerts was helpful there were a few other things I needed to work on to build up better base, which I’ll list below.

  • Logs-Don’t focus on a specific log source, be knowledgeable with a few different logs sources and how to read them. I know at the old gig I had more Firewall logs than I could shake a stick at so I wasn’t really sure how to read/fully interpret some of the other logs. When I first started here my auto pilot response was to look at the firewalls when I was going after my first “incident”. Boy was that a mistake. Not all firewall logs are created equally (some could be stateful versus next gen). Some situations these could be useful but for me a better base was understanding Proxy, VPN, Windows(Authentication, DNS and of course events), EDR to better tell the story. Which your SIEM might be able to do , but depending on the amount of logs hitting it and events/alerts you might be better off looking at log aggregation (like ELK) to really filter and get into the nitty gritty of what you are looking for.
  • Linux/SQL/ELK Command line/searching-While I could do basic navigation on the command line, I couldn’t grep/less and use switches for the life of me. Still learning and getting better with switches and some piping, this can also be sql from the command line as well. I use grep a lot when looking at endpoint data and log files from linux host so not being afraid to try different switches/pipes and using grep/less to search for certain things along with understanding how to search for data in telemetry that was an sql database (and can be useful also for things that use osquery…looking at you open SOC CTF). Also I have some basic stuff with Elk and command line now, still need to work on regex for even better filtering/searches to get rid of some of the noise.
  • Net flows/PCAPS– Grouping these two together as I generally grab PCAPs from specific net flows. While net flows were an issue at old gig, we use flows a lot with NSM, being able to read the data that the flows are giving you along with deciding if it is worth pulling the pcap from the NSM sensor to get information about an incident. I had done work with pcaps before from a network troubleshooting standpoint and light IR but taking advantage of looking at the TCP/HTTP streams to see what is really going on with the traffic versus what proxy/firewall’s are saying in terms of the communications. Also being able to look at the HTTP headers to see what might be going on and also knowing how to pull data from the HTTP streams (useful to pull downloads that might of came in from IoC’s or C2’s for further analysis/sandboxing).
  • Report Writing/timelines-While everyone can write notes and other things (if not, you should really be keeping your own notes outside of Incident tracking/SOAR/ticketing system’s incase those are unavailable in a critical incident. You can also quickly look back at them for repeat offenders for what to look for). However, being able to write something that is more in-depth and technical versus an executive summary is something that takes work. Summary’s aren’t going to need the same level of depth as a full technical report. Also keeping notes on the timeline of activity is also good to have in order to help build timelines (since they can help with the summaries as well).
  • Understanding dynamic analysis outputs from sandbox tools– Was tempted to call this system internals but figured this made more since as I know about LOLBINS and .net assembly getting dumped into memory but understanding the connections of what is going on and the associated actions and being able to explain that in both technical/non-technical way (again, the writing thing). Along with being able to tie that information back into the the endpoint data/and searches to help find artifacts and some of the technical happenings on the host.
  • Scripting– This is still a weakness of mine (mostly regex) and something I’m still working on as it is a “use it or lose it” skill. Since I’m not scripting a lot of the time my limited abilities go right out the window a lot of the time. Still working on my python and Powershell to a lesser extent to help get some of the easy info I need for stuff to get pulled.

There are just a few of my key things I’ve noticed with myself. Above all else though is not being afraid to make mistakes. I know with IR work you want to do it right 100% of the time and want to keep the $org out of the news, but if you are afraid to try things you will not learn anything and become better. Same goes for trying tools/technics find what works for you and is in scope with your org and just do your job to the best of your abilities. Also do not be afraid to network and ask question’s inside/outside your org.

These are my keypoints, I’m sure there are others who use different tools/technics/procedures but this is what I’ve really learned over the past year. I know I still have more to go, but that goes with the IR territory. Keep learning, Keeping trying to find the 5 “w”‘s with what you know or are trying to learn. Ok so this actually the most important-use your PTO/Take mental health days when needed. Your no good to your org if you are always burnt-out and depressed so take care of yourself!

BHIS Webinar Intro to Cyber Deception

On 1/23/2020 I attend a webinar from the fine folks at Black Hills Information security on an into to Cyber Deception (aka Honey pots). As someone who might be getting shifted into a more proactive security role versus all the things I handle now I was really interested in this subject.

What really though me off was how John Strand tied this very thing into more applicable threat intelligence. As someone who was also intrested in Cyber threat intel. Mostly steaming from the fact I could of done intel when I was enlisted, but chose logstiics because it used computers…Anyway. Getting threat feeds and currently working with Minemeld at work as well to help automate some of our responses to known IoC. The interesting and kinda “bad” about feeds is that they only deal with IoC’s that have hit all kinds of industries and who knows how old they could be after IR and forensics teams got the info out, there very well could be old now. They also do not deal with active threats hitting your enterprise, so you could be blocking a bunch of threats that have nothing to deal with your enterprise and could have attacks going on not getting blocked or looked at. This really hit me as something that is useful being able to get an attacker trapped in a honeypot and alerting on a honey account (an admin type account that no one should have access too so it can alert on SIEM or some other tool of your choice). with this going on you can look for IoCs possible C2 servers and the possible attack vector being used along with possible source IPs.

Black Hills Information Security Honey Pot Linux distro Active Defense Harbinger Distribution (ADHD)

What was also good about this webinar as I learned about Active Defense Harbinger Distribution(ADHD). Similar to Kali or even Flare-VM with how they handle pentesting or reverse engineering, ADHD handles with setting up honeypots. The tools are welly documented and have a basic walk-though with each tool. I will need to get some time fully go into using this for testing on my lab to see how these function more. This will also be a combo as I can use this traffic I generate attacking these honeypots to further learn some packet/traffic analysis as well. Still before I fully go after this I think I might need to finish setting up my Security Onion server and my FortiGate firewall.

I’d like to thank Black Hills Information Security for this great webinar, I wish I had taken some better notes or had the time to configure ADHD before posting this, hopefully I’ll get some tinkering this week.

Link to the slides: