May 29, 2025

Suspicious Code Alert: Recipe App Hijacks Credentials and Appears to Establish C&C Connection

Over the last 2 weeks, we have observed a spike in what appears to be malvertising. Customers have noted downloading a file after clicking on a sidebar ad in a news article, which then led to command and control and browser credential stealing behaviors. The advertisement and website (VirusTotal) claims to help find recipes to count calories for various food items. That said, over 80% of customers we’ve observed responding to this same event are related to the healthcare industry.

Additional Details

Observations note that upon downloading the file “Recipe Lister,” the file unzips and drops another larger executable file “Recipe Finder - Recipe Lister,” followed by additional DLLs. We’ve observed consistent file paths for this output as:

C:\Users\<user>\AppData\Local\Temp\<7-char>.tmp\7z-out
C:\Users\<user>\AppData\Local\Temp\2w1rXpxZnwDUwuTeNvdD6FUkeI0

This then leads to repeated network connections to suspicious or negatively reputed IP addresses (VirusTotal and VirusTotal). We’ve also noticed file creation time changes occurring, which seems consistent with timestomping behavior (T1070). Customer feedback has noted command and control traffic, followed by the stealing of browser credentials has occurred when engaging in their responses to this event. The software also appears to be utilizing NSIS plugins and appear to be related to DLL side-loading techniques (T1574 | VirusTotal Hash)

And, finally we observe it reaching out to varying domains across the events (which are listed below). These appear odd/suspicious, and have some malicious IP reputations that are associated. These domains are also more newly registered

Recommendations

Overall, this software seems highly suspicious at the least. The events observed and customer feedback appear consistent with a malicious advertising campaign (T1583). Additional sandbox reports like Any.Run’s report or Joe’s Sandbox report indicate suspicious and malicious conclusions, which appear consistent with our current observations and analysis.

We recommend blocking the following Hashes/IPs/Domains as able to do so:

www[.]recipelister[.]com https[:]//ahegazedatthewond[.]org https[:]//manahegazeda[.]org https[:]//sappointedmanah[.]org "Recipe Lister": 1619BCAD3785BE31AC2FDEE0AB91392D08D9392032246E42673C3CB8964D4CB7 "Recipe Finder - Recipe Lister": 9C58AACA8DDE7198240F7684B545575E4833D725D67F37E674E333EEB3EC642C 224[.]0[.]0[.]251 172[.]67[.]150[.]5 104[.]21[.]57[.]122

Frequently Asked Questions

How do I investigate a sudden spike in code submissions or application traffic?

Start with the timeline. Pin down the exact hour the spike began and compare it against any known events (marketing campaigns, product launches, seasonal patterns, media coverage). Then correlate across data sources: pull DNS query logs for new or unusual domains being resolved, check user registration data for patterns (bulk signups with sequential emails or similar usernames), review API endpoint usage for unusual call patterns, and examine source IP geolocation and ASN data. Automated traffic shows consistent timing intervals between requests, identical or rotating user-agent strings, and sequential behavior that real humans never produce. If you see 500 registrations per hour with 3-second intervals between each, that is not organic growth.

What are common indicators of fraudulent application submissions?

Look for velocity anomalies first, because they are the easiest to spot: too many submissions from one IP, one session, or one geographic area in too short a timeframe. Then check for data quality issues: fake phone numbers (555-xxxx patterns, all-zero blocks), disposable email domains (guerrillamail, tempmail, mailinator), addresses that fail validation or map to empty lots, and fields that contain identical or near-identical text across submissions. Source analysis reveals more: submissions from cloud hosting IPs (AWS, DigitalOcean, Azure ranges) or known proxy/VPN services, geographic mismatches between the stated location and the source IP, and browser fingerprints that indicate headless browsers or automation frameworks like Selenium or Puppeteer.

How do security teams distinguish between a legitimate traffic spike and an attack?

Legitimate traffic spikes have a cause you can trace. They correlate with marketing campaigns, press coverage, seasonal events, or social media virality. The traffic sources are diverse (many different IPs, referrers, and geographic origins), user behavior follows natural patterns (varying session lengths, realistic click paths, different time-of-day distributions), and the traffic targets the expected pages. Suspicious spikes look different: concentrated source IPs, uniform request timing, endpoint targeting that does not match how real users navigate, missing or forged referrer headers, and request patterns that skip normal discovery paths (going directly to API endpoints or form submission URLs without visiting the pages that contain those forms). Baseline your normal traffic patterns during quiet periods so you have something concrete to compare against.

What log sources help investigate application-layer fraud?

You need multiple log sources because no single source tells the full story. Web server access logs show request URIs, response codes, source IPs, user agents, and timing. Application audit logs capture business-level events like account creation, form submissions, and state changes. Database query logs reveal unusual query volumes or patterns (bulk inserts, rapid sequential reads). DNS resolution logs expose domain lookups to suspicious infrastructure. WAF and CDN logs show blocked requests, bot scores, and challenge results. Authentication logs capture login attempts, credential reuse, and session behavior. Cross-correlating these sources is where the real detection happens, because a sophisticated fraud attempt might look normal in any single log source but creates an unmistakable pattern when you connect the dots across all of them.

How do I set up automated detection for application fraud patterns?

Build detection rules around three signal categories. First, velocity rules: alert when a single IP, session, or account exceeds X submissions per time window (tune the threshold based on your normal traffic). Second, data quality rules: flag submissions with disposable email domains, phone numbers matching known fake patterns, or geographic impossibilities (IP in one country, stated address in another). Third, behavioral rules: detect sessions that skip normal page navigation, submissions from known hosting or proxy IP ranges, and user-agent strings associated with automation tools. Feed all of these signals into a SIEM for correlation, because individual signals produce false positives but multiple weak signals from the same source within a short time window create high-confidence detections. Start with alerting (not blocking) until you have tuned the thresholds for your environment.

Tag(s): Security Alerts , Blog

Taylor Jacobson

Taylor is a Senior Security Analyst at Blumira. GIAC certified, Taylor has a background in security operations and is a passionate blue teamer, helping others make sense of and respond to evolving threats.