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's operating systems share a lot of code, and specific vulnerabilities are frequently found in all operating systems.
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'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).
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 @DebugPrivilege had pointed me to. My 1768.py tool crashed on the process memory dump. This is fixed now, but it still doesn't extract the configuration.
I did a manual analysis of the Cobalt Strike beacon, and found that it uses alternative datastructures for the stored and runtime config.
I'm not sure if this is a (new) feature of Cobalt Strike, or a hack someone pulled of. I'm seeing very few similar samples on VirusTotal, so for the moment, I'm adding the decoders I developed for this to 1768.py as experimental features. These decoders won't run (like in the screenshot above), unless you use option -e.
With option -e, the alternative stored config is found and decoded:
And it can also analyze the process memory dumps I was pointed to:
Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
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.
Late last week, an exploit surfaced on GitHub for CVE-2024-21762 [1]. This vulnerability affects Fortinet's FortiOS. A patch was released on February 8th. Owners of affected devices had over a month to patch [2]. A few days prior to the GitHub post, the exploit was published on the Chinese QQ messaging network [3]
Firewalls and other perimeter devices are a huge target these days. Ivanti, Forigate, Citrix, and others offer plenty of difficult-to-patch vulnerabilities for attackers to exploit. Ransomware actors and others are always on the lookout for new victims. However, being and access broker or ransomware peddler is challenging: The competition for freshly deployed vulnerable devices, or devices not patched for the latest greatest vulnerability, is immense. Your success in the ransomware or access broker ecosystem depends on having a consistently updated list of potential victims.
[This is a Guest Diary by Joshua Woodward, an ISC intern as part of the SANS.edu BACS program]
Just listening to a lecture is boring. Is there a better way?
I recently had the opportunity to engage in conversation with Jonathan, a lead analyst at Rapid7, where our discussion led to the internal technical training that he gives to their new analysts. He saw a notable ineffectiveness in the training sessions and was "dissatisfied with the new analysts' ability to remember and apply the knowledge when it was time to use it." The new analysts struggled to recall and apply the knowledge from the classroom training and often "had to be retaught live," resulting in inefficiencies and frustration. After reflecting on the root cause of this issue, Jonathan suspected that the traditional approach to learning, such as classroom lectures and workshops, was at the heart of the problem. These more passive learning approaches failed to engage the participants, leading to disinterest in the training and lower knowledge retention. Drawing inspiration from a method that was effective for him, Jonathan decided to adopt a more active and engaging approach: Capture the Flag (CTF) competitions.
Capture the Flag (CTF) Competitions
Capture the Flag competitions can offer exposure to a wide range of cybersecurity concepts or drill into a particular skill set through carefully crafted puzzles. CTFs foster an active learning environment by encouraging participants to apply their critical thinking skills and knowledge in a practical context. The gamified nature of CTFs leads to more excitement and motivation to participate, and active engagement and problem-solving allows a deeper understanding and retention of cybersecurity concepts.
Considerations
Traditional training excels at comprehensively covering topics in a structured matter, while CTFs offer a better environment to apply skills practically and can be built to mimic real-world scenarios. However, the nature of CTFs may not be suitable for teaching specific skills in a predetermined manner, as participants may creatively approach challenges from various angles. Participants will only learn what is needed to solve the challenge. Carefully crafted challenges can offset this disadvantage to some extent, but they may not fully address this drawback. Despite the limitations, CTFs shine at getting participants to retain knowledge because they foster active learning. Participants are effectively teaching themselves in a hands-on manner that will help them remember and gain experience in the topic.
How puzzles are designed greatly influences the effectiveness of CTFs. Developing good challenges is a very time-consuming process. A senior analyst can teach a lecture in an ad-hoc matter, but all CTFs require a large preparation time. Jonathan mentioned that there are "a lot of competing requirements that are hard to balance" when designing a new challenge. The puzzle must be balanced and give participants a good starting point and prompt to prevent a knowledge blockade or feel overwhelming, but it still must be challenging and teach a specific skill set. Jonathan stated that when designing a challenge to target specific knowledge, a common trap is that it can easily start feeling like a trivia game rather than something fun, and "then you just have a quiz rather than a CTF." Well-designed challenges are the make-or-break linchpin for the successful implementation of CTFs in technical training.
Effectiveness
After introducing CTFs into his training plan, Jonathan noted that he witnessed a significant improvement in the analysts' ability to recall and apply the new knowledge. Being able to use the skills practically in an engaging and rewarding context seemed to give the participants a deeper understanding of the concepts and how to employ them when problem-solving.
I was able to interview an individual who had taken both types of training methods, and they noted that "CTF challenges were far more enjoyable and memorable" when compared to their original training. In terms of retaining and applying learning objectives, they found "CTF challenges to be significantly more effective." They were able to remember bits and pieces better from the CTF than from classroom training, which allowed them to have a starting place to research when solving situations in their work.
Jonathan comments that debating why the traditional classroom training failed is a discussion unto itself and has merit in researching it further. However, he did ultimately find that CTFs provided a workable alternative that helped fix the retention issue he was facing.
Integrating Capture the Flag challenges into internal training can give tangible improvements to participants' ability to retain and apply the knowledge being covered in training sessions. Combining CTFs with traditional training methods can help cover the drawbacks of either methodology at the cost of more preparation time.
—
* This article was written with the assistance of AI tools, including ChatGPT.
* Permission has been given by the interviewed sources to use their names and answers in this article. Full names have been redacted for privacy.
[1] 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 PE file contains an obfuscated hexadecimal-encoded payload. When I analyze it with base64dump.py searching for all supported encodings, a very long payload is detected:
It's 2834443 characters long, and matches base85 encoding (b85), but this is likely a false positive, as base85 uses 85 unique characters (as its name suggests), but in this particular encoded content, only 23 unique characters are used (out of 85).
Analyzing the PE file with my strings.py tool (calculating statistics with option -a) reveals it does indeed contain one very long string:
Verbose mode (-V) gives statistics for the 10 longests strings. We see that 2 characters (# and %) appear very often in this string, more than 75% of this long string is made up of these 2 characters:
These 2 characters are likely inserted for obfuscation. Let's use base64dump.py and let it ignore these 2 characters (-i #%"):
Now we have a hex encoded payload that decodes to a PE file (MZ), and most likely a Cobalt Strike beacon (MZARUH).
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.
About three months ago, I wrote about the implications and impacts of 5Ghoul in a previous diary [1]. The 5Ghoul family of vulnerabilities could cause User Equipment (UEs) to be continuously exploited (e.g. dropping/freezing connections, which would require manual rebooting or downgrading a 5G connection to 4G) once they are connected to the malicious 5Ghoul gNodeB (gNB, or known as the base station in traditional cellular networks). Given the potential complexities in the realm of 5G mobile network modems used in a multitude of devices (such as mobile devices and 5G-enabled environments such as Industrial Internet-of-Things and IP cameras), I chose to give the situation a bit more time before revisiting the 5Ghoul vulnerability.
Credential-stealing phishing is constantly evolving, nevertheless, some aspects of it – by necessity – stay the same. One thing, which is constant, is the need for a credential gathering mechanism, and although threat actors have come up with a number of alternatives to simply hosting a fake login page somewhere (e.g., using a third-party “forms” service[1] or attaching an entire phishing page to an e-mail[2]), the old approach of placing a phishing page on an internet-connected server and linking to it from e-mail messages is commonly used to this day.
