EFF filed an amicus brief for the second time in the U.S. Court of Appeals for the Ninth Circuit, arguing that allowing cases against the Apple, Google, and Facebook app stores to proceed could lead to greater censorship of users’ online speech.
Our brief argues that the app stores should not lose Section 230 immunity for hosting “social casino” apps just because they process payments for virtual chips within those apps. Otherwise, all platforms that facilitate financial transactions for online content—beyond app stores and the apps and games they distribute—would be forced to censor user content to mitigate their legal exposure.
Social casino apps are online games where users can buy virtual chips with real money but can’t ever cash out their winnings. The three cases against Apple, Google, and Facebook were brought by plaintiffs who spent large sums of money on virtual chips and even became addicted to these games. The plaintiffs argue that social casino apps violate various state gambling laws.
At issue on appeal is the part of Section 230 that provides immunity to online platforms when they are sued for harmful content created by others—in this case, the social casino apps that plaintiffs downloaded from the various app stores and the virtual chips they bought within the apps.
Section 230 is the foundational law that has, since 1996, created legal breathing room for internet intermediaries (and their users) to publish third-party content. Online speech is largely mediated by these private companies, allowing all of us to speak, access information, and engage in commerce online, without requiring that we have loads of money or technical skills.
The lower court hearing the case ruled that the companies do not have Section 230 immunity because they allow the social casino apps to use the platforms’ payment processing services for the in-app purchasing of virtual chips.
However, in our brief we urged the Ninth Circuit to reverse the district court and hold that Section 230 does apply to the app stores, even when they process payments for virtual chips within the social casino apps. The app stores would undeniably have Section 230 immunity if sued for simply hosting the allegedly illegal social casino apps in their respective stores. Congress made no distinction—and the court shouldn’t recognize one—between hosting third-party content and processing payments for the same third-party content. Both are editorial choices of the platforms that are protected by Section 230.
We also argued that a rule that exposes internet intermediaries to potential liability for facilitating a financial transaction related to unlawful user content would have huge implications beyond the app stores. All platforms that facilitate financial transactions for third-party content would be forced to censor any user speech that may in any way risk legal exposure for the platform. This would harm the open internet—the unique ability of anyone with an internet connection to communicate with others around the world cheaply, easily, and quickly.
The plaintiffs argue that the app stores could preserve their Section 230 immunity by simply refusing to process in-app purchases of virtual chips. But the plaintiffs’ position fails to recognize that other platforms don’t have such a choice. Etsy, for example, facilitates purchases of virtual art, while Patreon enables artists to be supported by memberships. Platforms like these would lose Section 230 immunity and be exposed to potential liability simply because they processed payments for user content that a plaintiff argues is illegal. That outcome would threaten the entire business models of these services, ultimately harming users’ ability to share and access online speech.
The app stores should be protected by Section 230—a law that protects Americans’ freedom of expression online by protecting the intermediaries we all rely on—irrespective of their role as payment processors.
On March 23, the FCC issued an update to their Covered List, a list of equipment banned from obtaining regulatory approval necessary for U.S. sale (and thus effectively a ban on sale of new devices), to include all new routers produced in foreign countries unless they are specifically given an exception by the Department of Defense (DoD) or DHS. The Commission cited “security gaps in foreign-made routers” leading to widespread cyberattacks as justification for the ban, mentioning the high-profile attacks by Chinese advanced persistent threat actors Volt, Flax, and SaltTyphoon. Although the stated intention is to stem the very real threat of domestic residential routers being commandeered to initiate attacks and act as residential proxies, this sweeping move serves as a blunt instrument that will impact many harmless products. In addition to being far too broad, it won’t even affect many vulnerable devices that are most active in these types of attacks: IoT and connected smart home devices.
Previously, the FCC had changed the Covered List to ban hardware by specific vendors, such as telecom equipment produced by companies Huawei and Hytera in 2021. This new blanket ban, in contrast, affects the importation and sale of almost all new consumer routers. It does not affect consumer routers produced in the United States, like Starlink in Texas. While some of the affected routers will be vulnerable to compromises that hijack the devices and use them for cybercrime and attacks, this ban does not distinguish between companies with a track-record of producing vulnerable products and those without. As a result, instead of incentivizing security-minded production, this will only limit the options consumers have to US-based manufacturers not affected by the ban—even those that lack stellar security reputations themselves.
While the sale of vulnerable routers in the U.S. will not stop, the announcement quoted an Executive Branch determination that foreign produced routers introduce “a supply chain vulnerability that could disrupt the U.S. economy, critical infrastructure, and national defense.” Yet this move does nothing to address the growing number of connected devices involved in the attacks this ban aims to address. As we have previously pointedout, supply chain attacks have resulted in no-name Android TV boxes preloaded with malware, sold by retail giants like Amazon, fuelling the massive Kimwolf and BADBOX 2 fraud and residential proxy botnets. Banning the specific models and manufacturers we know produce dangerous devices putting its purchasers at risk, rather than issuing blanket bans punishing reputable brands that do better, should be the priority.
With the FCCs top commissioner appointed by the President, this ban comes as other parts of the administration impose tariffs and issue dozens of trade-related executive orders aimed at foreign goods. A few larger companies with pockets deep enough to invest in manufacturing plants within the U.S. may see this as an opportune moment, while others not as well poised to begin U.S. operations may attempt to curry enough favor to be added to the DoD or DHS exception lists. At best, this will result in the immediate effect of an ill-targeted policy that does little to improve domestic cybersecurity posture. At worst, it entrenches existing players and deepens problematic quid-pro-quo arrangements.
American consumers deserve better. They deserve the assurance that the devices they use, whether routers or other connected smart home devices, are built to withstand attacks that put themselves and others at risk, no matter where they are manufactured. For this, a nuanced, careful consideration of products (such as was part of the FCC’s 2023-proposed U.S. Cyber Trust Mark) is necessary, rather than blanket bans.
Another court has ruled that copyright can’t be used to keep our laws behind a paywall. The U.S. Court of Appeals for the Third Circuit upheld a lower court’s ruling that it is fair use to copy and disseminate building codes that have been incorporated into federal and state law, even though those codes are developed by private parties who claim copyright in them. The court followed the suggestions EFF and others presented in an amicus brief, and joined a growing list of courts that have placed public access to the law over private copyright holders’ desire for control.
UpCodes created a database of building codes—like the National Electrical Code—that includes codes incorporated by reference into law. ASTM, a private organization that coordinated the development of some of those codes, insists that it retains copyright in them even after they have been adopted into law, and therefore has the right to control how the public accesses and shares them. Fortunately, neither the Constitution nor the Copyright Act support that theory. Faced with similar claims, some courts, including the Fifth Circuit Court of Appeals, have held that the codes lose copyright protection when they are incorporated into law. Others, like the D.C. Circuit Court of Appeals in a case EFF defended on behalf of Public.Resource.Org, have held that, whether or not the legal status of the standards changes once they are incorporated into law, making them fully accessible and usable online is a lawful fair use.
In this case, the Third Circuit found that UpCodes’s copying of the codes was a fair use, in a decision closely following the D.C. Circuit’s reasoning. Fair use turns on four factors listed in the Copyright Act, and the court found that all four favored UpCodes to some degree.
On the first factor, the purpose and character of the use, the court found that UpCodes’s use was “transformative” because it had a separate and distinct purpose from ASTM—informing people about the law, rather than just best practices in the building industry. No matter that UpCodes was copying and disseminating entire safety codes verbatim—using the codes for a different purpose was enough. And UpCodes being a commercial venture didn’t change the outcome either, because UpCodes wasn’t charging for access to the codes.
On the second factor, the nature of the copyrighted work, the Third Circuit joined other appeals courts in finding that laws are facts, and stand at “the periphery of copyright’s core protection.” And this included codes that were “indirectly” incorporated—meaning that they were incorporated into other codes that were themselves incorporated into law.
The third factor looks at the amount and substantiality of the material used. The court said that UpCodes could not have accomplished its purpose—providing access to the current binding laws governing building construction—without copying entire codes, so the copying was justified. Importantly, the court noted that UpCodes was justified in copying optional parts of the codes as well as “mandatory” sections because both help people understand what the law is.
Finally, the fourth factor looks at potential harm to the market for the original work, balanced against the public interest in allowing the challenged use. The court rejected an argument frequently raised by copyright holders—that harm can be assumed any time materials are posted to the internet for all to access. Instead, the court held that when a use is transformative, a rightsholder has to bring evidence of harm, and that harm will be balanced against the public benefit. Because “enhanced public access to the law is a clear and significant public benefit,” and ASTM hadn’t shown significant evidence that UpCodes had meaningfully reduced ASTM’s revenues, the fourth factor was at least neutral. It didn’t matter to the court that ASTM offered to provide copies of legally binding standards to the public on request, because “the mere possibility of obtaining a free technical standard does not nullify the public benefits associated with enhanced access to law.”
This is a good result that will expand the public’s access to the laws that bind us—something that’s more important than ever given recent assaults on the rule of law. In the future, we hope that courts will recognize that codes and standards lose copyright when they are incorporated into law, so that people don’t have to spend years and legal fees litigating fair use just to exercise their rights.
However, Congress clearly did not continue this work. In fact, it now appears that Congress is poised to consider another extension of this program without even attempting to include necessary and common sense reforms. Most notably, Congress is not considering a requirement to obtain a warrant before looking at data on U.S. persons that was indiscriminately and warrantlessly collected. House Speaker Mike Johnson confirmed that “the plan is to move a clean extension of FISA … for at least 18 months.”
Even more disappointing, House Judiciary Chair Jim Jordan, who has previously been a champion of both the warrant requirement and closing the data broker loophole, told the press he would vote for a clean extension of FISA, claiming that RISAA included enough reforms for the moment.
It’s important to note RISAA was just a reauthorization of this mass surveillance program with a long history of abuse. Prior to the 2024 reauthorization, Section 702 was already misused to run improper queries on peaceful protesters, federal and state lawmakers, Congressional staff, thousands of campaign donors, journalists, and a judge reporting civil rights violations by local police. RISAA further expanded the government’s authority by allowing it to compel a much larger group of people and providers into assisting with this surveillance. As we said when it passed, overall, RISAA is a travesty for Americans who deserve basic constitutional rights and privacy whether they are communicating with people and services inside or outside of the US.
Section 702 should not be reauthorized without any additional safeguards or oversight. Fortunately, there are currently three reform bills for Congress to consider: SAFE, PLEWSA, and GSRA. While none of these bills are perfect, they are all significantly better than the status quo, and should be considered instead of a bill that attempts no reform at all.
Mass spying—accessing a massive amount of communications by and with Americans first and sorting out targets second and secretly—has always been a problem for our rights. It was a problem at first when President George W. Bush authorized it in secret without Congressional or court oversight. And it remained a problem even after the passage of Section 702 in 2008 created the possibility of some oversight. Congress was right that this surveillance is dangerous, and that's why it set Section 702 up for regular reconsideration. That reconsideration has not occurred, even as the circumstances of the NSA, Justice Department, and FBI leadership, have radically changed. Reform is long overdue, and now it's urgent.
I’m skeptical about—and not qualified to review—this new result in factorization with a quantum computer, but if it’s true it’s a theoretical improvement in the speed of factoring large numbers with a quantum computer.
Malware analysis is an amazing field that can be interesting, fun, and useful for your cybersecurity career. If you’re wondering WHY anyone would want to dig into malware, it’s all for a better understanding of cybersecurity!
An XLL is a native Windows DLL that Excel loads as an add-in, allowing it to execute arbitrary code through exported functions like xlAutoOpen. Since at least mid-2017, threat actors began abusing Microsoft Excel add-ins via the .XLL format, the earliest documented misuse is by the threat group APT10 (aka Stone Panda / Potassium) injecting backdoor payloads via XLLs.
Since 2021, a growing number of commodity malware families and cyber-crime actors have added XLL-based delivery to their arsenals. Notable examples include Agent Tesla and Dridex, researchers observed an increase of these malware being dropped via malicious XLL add-ins.
Attackers typically embed their malicious code in the standard add-in export functions, such as xlAutoOpen. When a user enables the add-in in Excel, the malicious payload executes automatically, dropping or downloading a malicious payload. Some malware families use legitimate frameworks to create XLL (Excel Add-in) files. One common example is Excel-DNA, a popular open-source framework.
These frameworks make it easier for attackers to build and load malicious XLLs. In some cases, they also allow threat actors to pack and execute additional payloads directly in memory.
In late October 2025, a 64-bit DLL compiled as an XLL add-in was submitted to VirusTotal from two different countries. The first submission came from Ukraine on October 26, followed by three separate submissions from Russia beginning on October 27. The Russian-submitted samples were named Плановые цели противника.xll (“enemy’s planned targets”) and Плановые цели противника НЕ ЗАПУСКАТЬ.xll, which depending on context can mean either “Do NOT release the enemy’s planned targets” or “Do NOT activate the enemy’s scheduled targets.”
This DLL contains an embedded second-stage payload, a backdoor we named EchoGather. Once launched, the backdoor collects system information, communicates with a hardcoded command-and-control (C2) server, and supports command execution and file transfer operations. While it uses the XLL format for delivery, its execution chain and payload behavior differ from previously documented threats abusing Excel add-ins. Through pivoting on infrastructure and TTPs we were able to link this campaign to Paper Werewolf (aka GOFFEE), a group that has been targeting Russian organizations.
An XLL is an Excel add-in implemented as a DLL that Excel loads directly, usually with the .xll extension. Microsoft explicitly describes XLL files as a DLL-style add-in that extends Excel with custom functions.
When a user double clicks the file with the .xll extension, Excel is launched, loads the DLL and calls its exported functions such as xlAutoOpen, initialization code, or xlAutoClose, when unloading. Often malicious XLLs embed their payload inside xlAutoOpen or through a secondary loader, so that code runs immediately once Excel imports the DLL.
Excel XLL add-ins and macros differ mainly in how they execute and the level of control they provide an attacker. Macros, VBA or legacy XLM, run as scripts inside Excel’s macro engine and are constrained by Microsoft’s security model, which now includes blocking macros from the internet, signature requirements, and multiple user-facing warnings. XLLs, on the other hand, are compiled DLLs that Excel loads directly into its own process using LoadLibrary(), giving them the full power of native code without going through macro security checks. While macros rely on interpreted scripting and COM interactions, XLLs can call any Windows API, inject into other processes, or act as full-featured malware loaders. This makes XLLs far more capable and harder to analyze, and it may explain why some threat actors chose XLL-based delivery methods rather than macro-based.
Loader behavior
The DLL exports two functions, xlAutoOpen and xlAutoClose, both of which return zero. This behavior differs from that of legitimate XLL add-ins as well as from previously documented threats abusing the XLL format, such as those described in the most recent CERT-UA publication. In this case, the malicious logic is not tied to the typical export functions but instead is triggered through dllmain. The main function of the loader is called when fdwReason > 2 meaning that dllmain_dispatch was called with DLL_THREAD_DETACH (=3). Essentially the main function will be called when any thread in Excel that previously called into the XLL (even Excel’s own threads) exits.
Triggering the malicious payload during DLL_THREAD_DETACH helps the malware evade detection by delaying execution until a thread exits. This bypasses typical behavior-based detection, which focuses on early-stage activity like PROCESS_ATTACH, making the execution appear benign at first and allowing the second-stage payload to activate covertly after the sandbox times out or AV heuristics complete.
A call to the function that loads and executes the backdoor.
The embedded file is dropped as mswp.exe in %APPDATA%\Microsoft\Windows, then executed as a hidden process using CreateProcessW with CREATE_NO_WINDOW. Standard Output and Error is captured and redirected via anonymous pipes. If process creation succeeds, the function returns true otherwise, it cleans up and returns false.
The backdoor: EchoGather
We refer to this backdoor as EchoGather due to its focus on system reconnaissance and repeated beaconing behavior.
The dropped payload is a 64-bit backdoor with hardcoded configuration and C2 address. It collects system information and communicates with the C2 over HTTP(S) using the WinHTTP API.
Main function of EchoGather.
The data collected by EchoGather consists of:
IPv4 addresses
OS type (“Windows”)
Architecture
NetBIOS name
Username
Workstation domain
Process ID
Executable path
Static version string: 1.1.1.1
Next, EchoGather encodes that data using Base64 and sends it to the C2 using POST method. The C2 address is constructed from hardcoded strings. In the analyzed sample the C2 address was: https://fast-eda[.]my:443/dostavka/lavka/kategorii/zakuski/sushi/sety/skidki/regiony/msk/birylievo This transmission occurs in an infinite loop with randomized sleep intervals between 300–360 seconds.
In all of its C2 communications, EchoGather uses the WinHTTP API. It supports various proxy configurations and is designed to ignore SSL/TLS certificate validation errors, allowing it to operate in environments with custom or misconfigured proxy and certificate settings.
Supported commands
EchoGather supports four commands.
All outgoing communication with the C2 is encoded using standard Base64. When a command is received from the C2 the first 36 bytes contain the request ID, it’s a unique identifier that is being used when the backdoor needs to send the information is several packages.
0x54 Remote Command Execution
EchoGather first extracts the request ID, followed by the command that needs to be executed. It then decrypts the string cmd.exe /C %s using a hardcoded XOR key (0xCA), which serves as a template for command execution. Using this template, it executes the specified command via cmd.exe. The output of the command is captured through a pipe and sent back to the C2 server, with the request ID prepended to the response.
0x45 Return Configuration
Sends the embedded configuration structure to the C2.
0x56 File Exfiltration
The backdoor begins by extracting a request ID and the name of the file to be exfiltrated. It opens the specified file, determines its total size, and calculates how many 512 KB chunks are required for transmission. A transfer header containing metadata about the chunk count and size is then sent to the C2 server. In response, the backdoor receives the request ID used to identify the session. The file is read and transmitted in chunks, with each chunk containing the request ID, chunk index, file tag, data length, and raw file data.
0x57 Remote File Write
EchoGather receives a filename from the C2 and writes the incoming data chunks to the system, reconstructing the file as the chunks arrive.
Infrastructure analysis
During our research we found two domains that were used by the threat actors.
IP Resolutions for fast-eda.my
The domain was registered on September 12, 2025.
The very first resolution was between September 12th and 14th, the domain was resolved to 199.59.243[.]228.
After that and until November 26th all of the resolutions were on Cloudflare instances.
From September 18th to November 24th the domain was resolved to 172.64.80[.]1
On November 27th it was resolved to 94.103.3[.]82 the address is connected to Russia based on geolocation.
When we looked up the related files to this domain on VirusTotal, we found 7 files. Two of them are powershell scripts that load the backdoor: mswt.ps1 and the second one wasn’t submitted with a name.
The two scripts are identical, including their execution flow. Both first decode two Base64-encoded files: a PDF document and the EchoGather payload. The PDF is opened, while the payload is executed in the background. The document appears to be an invitation, written in Russian, to a concert for high-ranking officers. However, the PDF is AI-generated and contains several noticeable inconsistencies. For instance, the stamp in the lower right corner appears to be an AI-generated attempt at recreating Russia’s national emblem, the double-headed eagle, but the result resembles a distorted or bird-like figure rather than the intended symbol. The text also includes several errors. Some Cyrillic letters are incorrect, for example, the letter Д is used in place of Л in multiple instances, and the word праздиика is a misspelled version of праздника. Additionally, the phrase «с глубоким уважением приглашает» (translated as “with deep respect invites (you)”) is unnatural and not idiomatic in the context of formal Russian invitations.
Decoy document, and invite to a concert.
IP Resolutions for ruzede.com
First seen on 2025-05-21, resolved to 162.255.119[.]43 and later to 5.45.85[.]43 until October 2nd.
On October 2nd it was resolved to IP addresses in Cloudflare.
From October 4th to November 26th the domain was resolved to the same address seen in the previous domain: 172.64.80[.]1
On November 26th it was resolved to 193.233.18[.]137 in Russia based on geolocation.
The ip address is linked to different malicious domains.
Using VirusTotal, we pivoted on the domain ruzede[.]com, and we identified a RAR archive that exploits a known vulnerability, CVE-2025-8088, a vulnerability in WinRAR that involves the abuse of NTFS alternate data streams (ADSes) in combination with path traversal. This flaw allows attackers to embed malicious content within seemingly harmless filenames by appending ADSes that include relative path traversal sequences.
The archive contains a file named Вх.письмо_Мипромторг.lnk:.._.._.._.._.._Roaming_Microsoft_Windows_run.bat
When the archive is opened, WinRAR fails to properly sanitize these ADS paths and extracts the hidden data streams, placing them in unintended or sensitive locations such as %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup.
Connected file to the domain ruzede[.]com
The phrase “письмо Мипромторг” is misspelled; the correct form is “письмо Минпромторга.” This term refers to an official letter or communication issued by the Ministry of Industry and Trade of the Russian Federation (Минпромторг России). The same misspelling error is in the archive file name: Вх.письмо_Мипромторг.rar.
Essentially the file in the archive is a batch script that launches a hidden PowerShell process. This process navigates to a user-specific AppData directory, then downloads a PowerShell script named docc1.ps1 from a remote URL (https://2k-linep[.]com/upload/docc1.ps1) and saves it to the current working directory. The script is then executed via a new PowerShell instance with execution policy restrictions bypassed.
The downloaded script (docc1.ps1) extracts both a PDF file and an EchoGather payload, using a technique similar to the one described previously. However, in this instance, the embedded PDF differs from earlier samples. This document is allegedly sent from the deputy of the Ministry of Industry and Trade of the Russian Federation, asking for price justification documentation under the state defense order, focusing on violations of deadlines and reporting on pricing approval processes.
The companies listed with their emails on the top right side of the first page (Almaz-Antey, Shvabe, and the United Instrument-Making Corporation) are major Russian defense-industry and high-technology enterprises, and they might be the intended recipients of this decoy document.
Page 1Page 2Page 3
The same vulnerability was used by several threat actors including RomCom (Russia-aligned) and Paper Werewolf, a cyberespionage group targeting Russian organizations and active since 2022. In early August, BI.ZONE Threat Intelligence published a report about an ongoing campaign of Paper Werewolf that exploits CVE-2025-6218, affects WinRAR versions up to and including 7.11 and enables directory traversal attacks that allow malicious archives to extract files outside their intended directories. A second zero-day, at the time, vulnerability that abuses ADSs for path traversal. The report doesn’t mention CVE-2025-8088, but based on the description we assume that is the same vulnerability.
The interesting part is that we can see similarities between the decoy documents from the report to the document above. First, the filename of the decoy document in the report is запрос Минпромторга РФ.pdf (Request of the Ministry of Industry and Trade of the Russian Federation.pdf) no misspellings in the filename. It refers to the same office. The document asks to assess the impact of a specific government resolution on production capacities of subsidy recipients. Next, both documents share the same template and structure: red stamp on the left side, followed by the same information about the office, the date and the request id. Both documents contain a request for information to be submitted to a government-affiliated organization.
Attribution
Based on the shared infrastructure, such as the ruzede[.]com domain, as well as notable similarities in decoy document construction and the exploitation of the WINRAR vulnerability that leverages ADSs, we attribute this campaign to the Paper Werewolf (aka GOFFEE) threat group. The recent use of XLL files suggests that the group is experimenting with new delivery methods while continuing to rely on established infrastructure, possibly in an attempt to evade detection. In addition, the use of a new, yet simple, backdoor may indicate an effort to improve and evolve their toolset.
Summary
It’s less common to see public reporting on threats targeting Russian organizations, which makes this campaign worth highlighting. The threat actor appears to be actively exploring new methods to evade detection, including the use of XLL-based delivery techniques and newly developed payloads. These changes suggest an effort to enhance their capabilities. However, there are still clear gaps in both technical execution and linguistic accuracy, indicating that their tradecraft is still developing.
This article was written to provide readers with an overview of a selection of our pentest results from the last 15 months. This data was gathered toward the end of September 2025. Shockingly, the data does not differ much from our prior analyses conducted at the end of 2022 or 2023.
In this video, Troy Wojewoda discusses the intricacies of Zeek log analysis, focusing on how this network security monitoring system can be used to understand traffic and analyze logs effectively.
by Jordan Drysdale and Kent Ickler tl;dr: BHIS does a lot of penetration testing in both traditional and continuous penetration testing (CPT) formats. This top ten style list was derived […]
Click on the timecodes to jump to that part of the video (on YouTube) Slides for this webcast can be found here: https://www.blackhillsinfosec.com/wp-content/uploads/2020/09/SLIDES_HowtoPrepareBeforeCompromise.pdf 00:40 Intro, background information, how to deal with […]
Slides for this webcast can be found here: https://www.blackhillsinfosec.com/wp-content/uploads/2020/09/SLIDES_AttackTactics7LogsYouAreLookingFor.pdf So we went through an attack in the BHIS Webcast, “Attack Tactics 5! Zero to Hero Attack.” Then we went through […]
Join special guest Chris Brenton, COO of Active Countermeasures, as he discusses the anatomy of beacons and why you need to be looking for them during a threat hunt. He […]
Last month I gave a workshop for a group of 20-25 enthusiastic women, all either starting in infosec, or with an interest to start in this field.
For that purpose, I had created a full workshop: slides or a presentation introducing the concepts of Malware Analysis, Threat Intelligence and Reverse Engineering.
The idea was to convey these topics in a clear and approachable manner, both theory and in practice; for the latter, I had set up a custom VM, with Labs, including my own created applications, some with simple obfuscation.
All participants were very enthusiastic, and I hope to have sparkled most, if not some of them to pursue a career in this field. For this exact same reason, I am now releasing the presentation to the public - the VM and recordings however will not be published, as I created these solely for CWF.
I would also like to thank Nathalie for putting me in touch with Rosanna, the organiser of the CyberWayFinder program. And of course, my gratitude to all the attendees for making it!
Mind the disclaimer for the slides. License: CC Attribution-NonCommercial-NoDerivs License
Joff Thyer // Information Security professionals often have reason to analyze logs. Whether Red Team or Blue Team, there are countless times that you find yourself using “grep”, “tail”, “cut”, […]
John Strand // Want to get started on a hunt team and discover “bad things” on your network? In this webcast, we will walk through the installation and usage of […]
John Strand // So you think you might have a compromised Windows system. If you do, where do you start? How would you review the memory of that system? What […]
Login
