Silicon Shecky

Infosec Practitioner

  • About
  • Categories
    • General
    • Computers
    • Software
    • Rants
    • Security
    • Internet/Music
    • Reviews
    • Microsoft
    • Hardware
    • Mobile Computing
  • Links
    • Infosec
      • Burbsec
      • Infosec Exchange Mastodon
      • Hacks4Pancakes Blog
      • Krebs On Security
      • Bleeping Computer
  • Archives

Connect

  • Bluesky
  • LinkedIn
  • Mastodon
  • RSS
  • Twitter

[footer_backtotop]

Copyright © 2025 ·Sixteen Nine Pro Theme · Genesis Framework by StudioPress · WordPress

Incident or Typo?

March 22, 2018 By Michael Kavka Leave a Comment

I will take, “Incidental Panics” for $1000 Alex.

There is something to be said to using the KISS (Keep It Simple Stupid) method in just about everything. We all tend to forget the simple things. Then the universe decided to show us again. I recently ran into a situation where I was asked to look at a machine that was constantly trying to connect to an IP address in China. The premise was, why is it doing this and more importantly why is nothing detecting something wrong? It was a spot check of firewall logs while trying to fix something with the log system that revealed this issue. Needless to say there was a mini-panic induced and it filtered to me. Here is what I did.

First off, I looked into Splunk for not only the Chinese IP I was given, but also the computer’s IP address. This allowed me to see that it was trying to connect to port 9100. I should have been quick from here because 9100 is a known port used for printing. Yeah, I forgot my own words of Keep It Simple Stupid and to quote Doctor Who, “Took the long way around,” to get to the final result. the long way was like this:

I did a netstat -a to see what connections were occurring.

I downloaded the Sysinternals suite and used TCPView to see what process was attempting the connection. This revealed it was the print spooler service. Again I should have been able to finish things up right here, but continued on the long path.

I then Used Process Monitor and Process Explorer to look into the spooler service to see if it had been compromised, which it had not.

Finally, I looked in the spooler directory and saw a job sitting there. This gave me the idea of actually looking at printers and devices, finding the printer that had a job pending, looking at the properties of that printer and seeing its IP was set as the offending Chinese IP.

I did this remotely while one of our on site technicians was in front of the machine, watching what I was doing. He sees the IP and messages me that if the first octet was 11 instead of 1, it was the right IP for a printer at that location. Problem solved. The whole thing was a typo. The continuous connection attempts were the print queue trying to print out an e-mail, and constantly retrying, to an IP that was wrong. This also explained why our tools did not see this as a threat.

I stated at different points I could have finished the investigation earlier. When I saw it was the spooler service, I should have checked printers and the queue for something pending. After that I could have checked for compromise in the spooler service. I didn’t because I did not think of that due to assuming it was a compromised system bases on the information I was initially given. Also, from a forensic standpoint, I had a chance to catch it doing instead of having to recreate the situation. The same is true when I saw what port it was using. It is possible that had I gone straight to the end I could have been wrong, and we could have gone back to square one. As it turns out, I spend 45 minutes instead of 10 on this whole situation. I also got to stretch my investigative muscles and use tools in a way I don’t always get to, allowing me to refresh skills that are not always used. Sometimes there is something to not using the KISS method, as long as taking the long way does not have a negative effect.

Now you decide, is this typo an incident? I say not.

Filed Under: Security Tagged With: Forensic Investigation, spoolsv.exe, Sysinternals

What is Threat Hunting?

March 15, 2018 By Michael Kavka Leave a Comment

Threat Hunting, yes another set of buzzwords. The world of Information Security is a smorgasbord of buzzwords. Still, threat hunting.  It sound glamorous, worthwhile, fun and interesting. The question is, just what is it?

I admit it, I am taken in by the idea of Threat Hunting. Feels like something important (which it is) and cool (depends on your point of view). I want to be a good threat hunter, and so do many people both blue and red teamers alike. The problem is, that Threat Hunting is a huge umbrella area. It is non-specific. Earlier this week the topic of what is threat hunting was asked by Dr. Anton Chuvakin on twitter.

What are the most abysmally fake examples of totally NOT threat hunting that vendor(s) called “threat hunting”? #question

— Dr. Anton Chuvakin (@anton_chuvakin) March 10, 2018

 

The thread is a good look at how people view threat hunting, and what it is or is not. Dr. Chuvakin responded with this:

Well, this is how I am planning to phase it 🙂 pic.twitter.com/sH6QTijT8V

— Dr. Anton Chuvakin (@anton_chuvakin) March 13, 2018

 

There are some flaws with this thinking, and it all comes down to how you define threat hunting. Let us move away from information security for a second, remove the word threat and look at wha they key word is, Hunting.

You want to get some fresh venison, and a set of antlers on your wall. Deer hunting season is here. So how does one go about hunting a deer? First you have to get to the woods with some sort of weapon (gun, bow, spear for those really wanting a challenge).  Next to have to find the deer. Track it. How do you do that? Find footprints, use some sort of sound or smell, anything to track down the deer. You become a detective, and use deception. Finally you have to actually take the shot and hope it is good for the kill. Three main phases of hunting: Location, Deception/Detection, Kill shot. Is it not hunting if you have a dog that helps automate the detective/deception phase. That dog makes it easier to find the deer.

Now let us look at how that relates to Threat Hunting in the world of infosec. Phase 1: Location. You can threat hunt in your own network (which most of us do knowingly or unknowingly), out in the Internet, on the Dark Web. You can hunt for the vulnerabilities, the compromises, zero day attacks. You can hunt for The actors, malware, lateral movement. What is the location, the area you are hunting in? Phase 2 is where you do your detective work. This can include honeypots, honeynets, deception technology, going through logs manually or using automation. To say going through large amounts of data, not using tools, or anything else that limits how you can find the threat(s) is limiting your success. In fact, Threat Detection (Incident Detection) is the first two phases of threat hunting. They are a subset of threat hunting. The kill shot is the only difference. That kill shot in our world can be plugging the hole, removing the malware, blocking a C2 IP address, anything that kills(mitigates) the immediate threat that you have found.

This is true threat hunting. It is not about the tools, any tool can be used. It is about the result. Did you find the threat and remove or mitigate it? Threat hunting is a process, and one that many things can fall under. It can only be defined in the broadest terms and then whittled down to specific areas. Trying to shrink those broadest terms and limit what can be used does nothing but hurt the hunt and puts us at a bigger disadvantage to beating the black hats we are after.

Filed Under: Rants, Security Tagged With: Deception Technology, Threat Hunting

The case for proper information or WHY CAN’T I UPGRADE THIS?

March 9, 2018 By Michael Kavka Leave a Comment

Legacy OSes, Legacy systems. We all know that it sucks having them. We all have to deal with them. Software companies do not always account for them though.

When you work internally in a medium to large business change happens slowly at times. I recently ran into a weird issue due to slow change. I went to update my CarbonBlack Response server in the mindset of security and fixing a few annoying bugs. I have done these updates without issue in the past. So when I got an OpenJDK dependency error I was rather taken aback. I tried to update OpenJDK, no go. The repos this version of Linux is using had no update to openJDK (1.8.0.r92 is what I needed). I decided to get CB support involved. We eventually set up a Webex so they could see directly what was going on, since none of the fixes they had sent me worked.

Turns out that it was not documented that the Linux version we were on will not get that version of OpenJDK, or anything newer available for it. Mind you the Linux version is a number of years old, but still supported by said Linux vendor. Nor is there a way around the issue with the upgrade process, so CarbonBlack basically cannot be updated unless I can get the proper change order pushed through to upgrade the Linux version. We tried everything, manually installing new versions of OpenJDK which succeeded but still was not being seen when the dependency check was being done.

The support person from CarbonBlack was going to let the devs there know about this and try to get documentation updated so others who might be looking to upgrade know they cannot with this version of Linux. The other thing that got me thinking was why is a security company like CarbonBlack relying on Java (OpenJDK) since it is so insecure? I like CarbonBlack’s products but this is a huge WTF in my book.

Filed Under: Rants, Security, Software Tagged With: Carbon Black, CarbonBlack, Java, OpenJDK, Upgrade

  • « Previous Page
  • 1
  • …
  • 16
  • 17
  • 18
  • 19
  • 20
  • …
  • 248
  • Next Page »

RSS Taggart Institute Intel Feed

  • Shaq's new ride gets jaq'ed in haq attaq October 26, 2025 Brandon Vigliarolo
  • The Kavanaugh stop, 50 days later October 26, 2025 Chris Geidner
  • Kaitai Struct WebIDE, (Sun, Oct 26th) October 26, 2025
  • [REVIVE-SA-2025-002] Revive Adserver Vulnerability October 26, 2025
  • [REVIVE-SA-2025-001] Revive Adserver Vulnerability October 26, 2025
  • New CoPhish attack steals OAuth tokens via Copilot Studio agents October 25, 2025 Bill Toulas
  • What Really Doomed Napoleon’s Army? Scientists Find New Clues in DNA October 25, 2025 Becky Ferreira
  • MPs urge government to stop Britain's phone theft wave through tech October 25, 2025 Lindsay Clark
  • Beyond good ol’ Run key, Part 153 October 25, 2025 adam
  • Cloud Discovery With AzureHound October 24, 2025 Margaret Kelley

Browse by tags

Active Directory Android Antivirus Apple Beta Chrome Computers Exchange Exchange 2007 Firefox General Thoughts Google InfoSec Internet Explorer iOS iPad IT Linux Mac Malware Microsoft OS OSx Patches Rants SBS SBS 2008 Security Security Patches Server SMB Software Support Surface TechEd Tweets Ubuntu Verizon Virus Vista vulnerabilities Windows Windows 7 Windows 8 XP