New tool: linux-pkgs.sh, (Sun, Mar 24th)

During a recent Linux forensic engagement, a colleague asked if there was anyway to tell what packages were installed on a victim image. As we talk about in FOR577, depending on which tool you run on a live system and how you define “installed” you may get different answers, but at least on the live system you can use things like apt list or dpkg -l or rpm -qa or whatever to try to list them, but if all you have is a disk image, what do you do? So after some research, I initially put together 2 scripts, one to pull info from /var/lib/dpkg/status on Debian/Ubuntu-family systems and another to look through /var/lib/yum/yumdb to try to pull that info from RHEL/CentOS boxes that use yum, but then I remembered that Fedora uses dnf instead of yum and when I found a Fedora image I realized that dnf doesn&#39&#x3b;t use /var/lib/yum/yumdb. I finally combined my original 2 into a single script and playing around for a bit figured out that the dnf info is kept in a sqlite db in /var/lib/dnf. So, I&#39&#x3b;m putting another new tool out there. This one can handle all 3 of the above cases. If anyone wants to help out with figuring out where other distros (not based on these 3 families) hide this data, feel free to share and I&#39&#x3b;ll update, but these 3 handle the vast majority of cases that I run across and probably the vast majority of clound Linux instances, so I figure it is a good place to start.

Continue reading New tool: linux-pkgs.sh, (Sun, Mar 24th)

Posted in Uncategorized

Apple Updates for MacOS, iOS/iPadOS and visionOS, (Mon, Mar 25th)

Last week, Apple published updates for iOS and iPadOS. At that time, Apple withheld details about the security content of the update. This is typical if future updates for other operating systems will fix the same vulnerability. Apple&#;x26;#;39;s operating systems share a lot of code, and specific vulnerabilities are frequently found in all operating systems.

Continue reading Apple Updates for MacOS, iOS/iPadOS and visionOS, (Mon, Mar 25th)

Posted in Uncategorized

Tool updates: le-hex-to-ip.py and sigs.py, (Sun, Mar 24th)

I am TA-ing for Taz for the new SANS FOR577 class again and I figured it was time to release some fixes to my le-hex-to-ip.py script that I wrote up last fall while doing the same. I still plan to make some additional updates to the script to be able to take the hex strings from stdin, but in the meantime, figured I should release this fix. I was already using Python3&#;x26;#;39;s inet_ntoa() function to convert the IPv4 address, so I simplified the script by using the inet_ntop() function since it can handle both the IPv4 and IPv6 addresses instead of my kludgy handling of the IPv6. As a side-effect it also quite nicely handles the IPv4-mapped IPv6 addresses (of the form ::ffff:192.168.1.75).

Continue reading Tool updates: le-hex-to-ip.py and sigs.py, (Sun, Mar 24th)

Posted in Uncategorized

1768.py’s Experimental Mode, (Sat, Mar 23rd)

The reason I extracted a PE file in my last diary entry, is that I discovered it was the dropper of a Cobalt Strike beacon &#;x26;#;x40;DebugPrivilege had pointed me to. My 1768.py tool crashed on the process memory dump. This is fixed now, but it still doesn&#;x26;#;39;t extract the configuration.

Continue reading 1768.py’s Experimental Mode, (Sat, Mar 23rd)

Posted in Uncategorized

Whois “geofeed” Data, (Thu, Mar 21st)

Attributing a particular IP address to a specific location is hard and often fails miserably. There are several difficulties that I have talked about before: Out-of-date whois data, data that is outright fake, or was never correct in the first place. Companies that have been allocated a larger address range are splitting it up into different geographic regions, but do not reflect this in their whois records.

Continue reading Whois “geofeed” Data, (Thu, Mar 21st)

Posted in Uncategorized