{
	"id": "7b38173a-ffc0-4a79-97f9-0c2558c2f20e",
	"created_at": "2026-09-25T02:03:29.556703Z",
	"updated_at": "2026-09-25T02:05:14.517391Z",
	"deleted_at": null,
	"sha1_hash": "0ffda0686deee2efb965de64dc9adeef819391ad",
	"title": "WeaselBiscuit Strips BeaverTail and OtterCookie Down to Essentials",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 14468235,
	"plain_text": "https://opensourcemalware.com/blog/introducing-weaselbiscuit\n\nWeaselBiscuit Strips BeaverT\n\nEssentials\n\nBy c0a15726-c5b1-4b0d-85e6-fe15553df9e2\n\nPublished: 2026-09-17 · Archived: 2026-09-25 02:01:34 UTC\n\nThe OpenSourceMalware team spends a lot of time looking at malicious npm packages, and after a while you start\n\nseeing the same patterns over and over. So when something new and genuinely different shows up, it’\n\nstopping for. That happened this week when we found 11 npm packages secretly hiding a brand new JavaScript\n\nstealer. It looks and feels like the DPRK’s BeaverT\n\nlighter, and stripped down, with many of the heavier functions removed entirely.\n\nWe're calling it WeaselBiscuit. It isn’t an established family name. I made it up, and I think it’\n\nOur automation flagged these packages as malicious and grouped them together because they share IOCs. That’s\n\nwhen we recognized an emerging Node.js infostealer architecture worth investigating, one that reads as a possible\n\nnew or lightly documented DPRK-linked strain, or as a simplified branch or fork of the BeaverT\n\necosystem. You can see all the threat reports under the #weaselbiscuit tag.\n\nPackage\n\n@biz44/id10-client\n\n@biz44/id12-client\n\n@biz44/id44-client\n\n@biz44/id79-client\n\n@biz44/id95-client\n\n@biz44/id99-client\n\nail and OtterCookie Down to\n\nail and OtterCookie, but it isn’t quite either one. It’\n\nFirst seen\n\n2026-09-12T13:51:46Z\n\n2026-09-12T13:51:47Z\n\n2026-09-12T08:03:37Z\n\n2026-09-12T13:51:48Z\n\n2026-09-12T13:51:46Z\n\n2026-09-12T13:51:46Z\n\nPage 1 of 16\n\ns worth\n\ns smaller,\n\ns dope.\n\nail/OtterCookie\n\nPackage\n\n@biz44/process-runtime-utils\n\n@biz44/runtime-utils\n\n@railone/image-utils\n\n@vibecheck-polid/process-runtime-\n\nutils\n\nengin1\n\nid79-client\n\nlaycot\n\nprocess-lhpm\n\nprocess-mite\n\nprocess-tailwind\n\nWe're tentatively attributing this malware to DPRK but it's important to be clear that it's an analytic hypothesis,\n\nnot a confirmed attribution. The recovered code has meaningful overlap with DPRK-associated Contagious\n\nInterview tooling, but we haven’t recovered operator infrastructure, victimology\n\nmaterial, or a unique-code comparison sufficient to name a new family or conclusively attribute it to DPRK.\n\nhttps://opensourcemalware.com/blog/introducing-weaselbiscuit\n\nFirst seen\n\n2026-09-14T04:41:47Z\n\n2026-09-14T03:39:58Z\n\nunknown\n\nunknown\n\n2026-09-16T03:44:28Z (version 1.3.99 still live on NPM)\n\n2026-09-12T13:35:09Z\n\n2026-09-16T13:51:46Z (version 1.3.10 still available on\n\nNPM)\n\n2026-09-15T00:44:34Z\n\n2026-09-16T23:57:52Z\n\n2026-09-15T00:20:01Z\n\n, campaign metadata, signing\n\nPage 2 of 16\n\nhttps://opensourcemalware.com/blog/introducing-weaselbiscuit\n\nWhat WeaselBiscuit does\n\nLands via an npm  import  and auto-runs a detached background Node process\n\nPage 3 of 16\n\nhttps://opensourcemalware.com/blog/introducing-weaselbiscuit\n\nPulls its real payload from an Npoint URL and runs it in memory\n\nBeacons to a shared HTTP C2 at  103.170.217.184:8787\n\nProfiles the host: hostname, user, OS, CPU/RAM, local and public IP\n\nSteals Chrome extension storage on Windows, macOS, and Linux, which is exactly where wallet\n\nextensions keep their signing state\n\nCaptures clipboard contents, on operator command\n\nLogs Windows keystrokes, on operator command\n\nTags each install with a numeric campaign ID ( 10 ,  12 ,  44\n\nMore on exactly what gets uploaded, and what doesn’t, in the Capabilities section below.\n\nWhat it doesn’t do, compared to BeaverTail and OtterCookie:\n\nNo wallet-draining code, no hardcoded wallet extension ID list\n\nNo Chrome password decryptor, no seed-phrase regex sweep\n\nNo InvisibleFerret Python second stage\n\nNo screenshot module\n\nNo Socket.IO, WebSocket, or remote shell, just plain polling HTTP\n\nNo persistence beyond the detached Node process and a  .pid\n\nWhy it’s notable\n\nThe implant combines a package-borne Node.js loader, Npoint dead-drop resolution, Chrome extension-storage\n\ntheft, clipboard collection, Windows keylogging, and a small custom HTTP control plane. Operationally\n\nsimpler than commonly documented OtterCookie deployments:\n\nnpm import\n  -\u003e detached Node loader\n  -\u003e Npoint-delivered JavaScript\n  -\u003e Npoint C2 configuration\n  -\u003e plain HTTP C2 polling and exfiltration\n\nThere’s no Socket.IO, no remote shell, no screenshot capability\n\npassword decryptor, no hardcoded wallet list, and no server-delivered follow-on payload in the recovered client.\n\nThat absence could reflect an early-stage build, a deliberately reduced operational module, or a distinct actor\n\ncopying familiar tradecraft.\n\n, no Python InvisibleFerret handoff, no browser-\n\nPage 4 of 16\n\n, never touching disk\n\n, geolocation\n\n,  79 ,  95 ,  99 ) for server-side sorting\n\nfile\n\n, it’s\n\nhttps://opensourcemalware.com/blog/introducing-weaselbiscuit\n\nConfirmed infection chain\n\n1. An application imports  process-tailwind@1.1.99 .\n\n2.  index.js  automatically calls  initialize() .\n\n3.  init.js  starts a detached  node loader.js  process and stores its PID in  \u003cpackage-directory\u003e/.pid .\n\n4.  loader.js  retrieves JSON from:\n\nhttps://api.npoint.io/24c25d5f5fcbb0992a4f\n\n5. The loader Base64-decodes the JSON  code  field and executes it through  new Function .\n\n6. The retrieved response is an exact match for the supplied second-stage artifact, SHA-256:\n\n7b15605f23b131b3eeea57e031ae7cb32fc4b78c7bbb2025aa7a561ea5ae5159\n\n7. The second stage obtains the C2 configuration from:\n\nhttps://api.npoint.io/37c0a0c68bf7a94ed731\n\n8. The configuration resolves the C2 to:\n\nhttp://103.170.217.184:8787\n\nPage 5 of 16\n\nhttps://opensourcemalware.com/blog/introducing-weaselbiscuit\n\nCampaign structure and identifiers\n\nWeaselBiscuit isn’t an isolated sample. Static analysis and user-authorized inert retrievals identified a cluster of\n\ncloned npm loaders that pull near-identical WeaselBiscuit stages from distinct Npoint URLs. The stages differ\n\nPage 6 of 16\n\nhttps://opensourcemalware.com/blog/introducing-weaselbiscuit\n\nmaterially only in a numeric  identifier  field included in system-information and Chrome-extension uploads,\n\nwhich strongly suggests a server-side campaign, tenant, operator, or victim-group label.\n\nThat clustering is easier to see than to describe. The graph below maps the shared infrastructure our platform\n\nrecovered across the cluster, with  process-tailwind\n\nresolver URLs, and the  03.170.217.184  C2 to  id79-client\n\nthe tables below. It contains nineteen nodes, eight of them tied together by shared indicators rather than naming\n\nsimilarity alone. Every edge in this graph is a shared hash, resolver URL, or C2 address, not an assumption\n\nFirst-stage resolver\n\nhttps://api.npoint.io/24c25d5f5fcbb0992a4f\n\nhttps://api.npoint.io/641d37178a880b1e8b8f\n\nat the center, connected through shared file hashes, Npoint\n\n,  engin1 , and the\n\nEmbedded stage\n\nidentifier\n\n99\n\n10\n\nPage 7 of 16\n\n@biz44  packages covered in\n\nStatus\n\nConfirmed  process-tailwind\n\npayload\n\nConfirmed  swnwall  payload\n\nhttps://opensourcemalware.com/blog/introducing-weaselbiscuit\n\nEmbedded stage\nFirst-stage resolver Status\nidentifier\n\nhttps://api.npoint.io/33e8d008c334b060adad 79 Confirmed WeaselBiscuit clone\n\nhttps://api.npoint.io/ddae72efbb6714fae922 12 Confirmed WeaselBiscuit clone\n\nhttps://api.npoint.io/933a731a5e97f4b45249 95 Confirmed WeaselBiscuit clone\n\nHard-coded by  id79-client ;\nhttps://api.npoint.io/24c12c4b66a29747764f Unknown\nreturned HTTP 404 when retrieved\n\nAll five recovered stages use the same second Npoint configuration resolver,\n\nhttps://api.npoint.io/37c0a0c68bf7a94ed731 , which supplied the same C2:  http://103.170.217.184:8787 .\n\nThe confirmed stage-level identifiers are  10 ,  12 ,  79 ,  95 , and  99 . They’re useful as campaign-hunting\n\nmarkers, but their precise meaning isn’t yet known. The code doesn’t label them as campaign IDs.\n\nPackage Package label First-stage resolver\n\nprocess-tailwind@1.1.99 ID-99 Client Module 24c25d5f5fcbb0992a4f\n\nengin1@1.3.99 ID-99 Client Module 24c25d5f5fcbb0992a4f\n\nswnwall@1.2.10 ID-10 Client Module 641d37178a880b1e8b8f\n\nid79-client@1.1.79 ID-79 Client Module 24c12c4b66a29747764f\n\nAll four package loaders share the same detached Node process,  .pid  marker, Npoint JSON retrieval, Base64\n\ndecoding, and dynamic  new Function  execution template.  process-tailwind  and  engin1  have byte-identical\n\nloader, init, and index source files. The  ID-79  label in  id79-client  is consistent with the separate recovered\n\nstage carrying  identifier: \"79\" , but the package’s current resolver response was unavailable, so that direct\n\ndelivery link isn’t proven.\n\nPage 8 of 16\n\nhttps://opensourcemalware.com/blog/introducing-weaselbiscuit\n\nCapabilities\n\nThe WeaselBiscuit infostealer uploads the following to the IP-hosted C2:\n\nHostname, username, OS details, CPU, memory\n\npublic IP, and public-IP geolocation\n\nEvery readable, nonempty file under Chrome profiles’\n\nWindows, macOS, and Linux\n\nChanged clipboard contents, when the server enables monitoring\n\nWindows keyboard events, when the server enables monitoring\n\nWhile this malware does not have the same crypto wallet stealer functions as its big siblings, the Chrome\n\nextension-storage capability is financially relevant: it can expose wallet-extension state or other extension-held\n\nsensitive data. It uploads every readable, nonempty file\n\ndirectory — a raw LevelDB key/value store — wholesale.\n\nThat store legitimately contains a mix of:\n\nThe victim's own account address(es) — typically a small number\n\nWallet extensions like MetaMask and their internally cached token/contract address list (used for balance\n\ndisplay, price feeds, swap routing)\n\nAddress-book/contact entries (other people's addresses, not the victim's)\n\nVarious other cached metadata\n\nMeanwhile, clipboard and keylogging can capture credentials,\n\nentered or copied during normal use. However, the code does not\n\npassword decryption, seed-phrase searching, or cryptocurrency transaction functionality.\n\nC2 design\n\nThe C2 is a plain Express HTTP service, and its client-facing interface is small:\n\nRoute\n\n/api/system-info\n\n/api/upload-local-extension-settings\n\nPage 9 of 16\n\n, home/temp paths, local interface IP/MAC addresses,\n\nLocal Extension Settings  directories on\n\nunder the extension's  Local Extension Settings\n\nAPI tokens, wallet addresses, or recovery phrases\n\ncontain direct wallet draining, browser-\n\nMethod\n\nmultipart POST\n\nmultipart POST\n\nFunction\n\nHost reconnaissance report\n\nChrome extension storage\n\nhttps://opensourcemalware.com/blog/introducing-weaselbiscuit\n\nRoute Method\n\n/api/clipboard-status/\u003chostname\u003e GET\n\n/api/clipboard-data JSON POST\n\n/api/keyboard-mouse-status/\u003chostname\u003e GET\n\n/api/keyboard-mouse-data JSON POST\n\nThe client polls the two status routes every five seconds. Recorded responses for a synthetic host were\n\nExpress JSON responses with  isMonitoring: false . No payload, command, redirect, or next-stage URL was\n\nobserved in those responses.\n\nThat’s a real departure from documented OtterCookie variants, which use Socket.IO and can support broader\n\ncommand execution. This is a polling infostealer control plane, not a full interactive RA\n\ncode.\n\nHow it compares to BeaverTail and OtterCookie\n\nThe overlap supporting the DPRK hypothesis is behavioral, not dispositive:\n\nNode.js delivery and execution in a developer/package ecosystem\n\nBrowser extension-storage theft with potential wallet relevance\n\nNative clipboard collection using  Get-Clipboard  and  pbpaste\n\nKeylogging, host profiling, and HTTP exfiltration\n\nUse of lightweight external configuration to decouple the loader from C2 infrastructure\n\nThe divergences matter just as much:\n\nNo Socket.IO, WebSocket, or remote-shell client\n\nNo screenshots\n\nNo explicit crypto-wallet extension IDs, browser credential databases, or broad file-targeting rules\n\nNo InvisibleFerret/Python downloader\n\nPage 10 of 16\n\nFunction\n\nClipboard collection switch\n\nClipboard exfiltration\n\nKeylogger switch\n\nKeystroke exfiltration\n\n200 OK\n\nT, at least in the recovered\n\nhttps://opensourcemalware.com/blog/introducing-weaselbiscuit\n\nNo observed persistence beyond a detached process and a local PID marker\n\nCisco Talos has reported that the line between BeaverT\n\nincluding Node.js keylogging, clipboard monitoring, extension and wallet data targeting, and shifting C2\n\narchitectures. That makes a lineage relationship plausible, but it doesn’t prove it. See BeaverT\n\nevolve with a new JavaScript module.\n\nCapability comparison\n\nCapability\n\nRuntime\n\nDelivery\n\nStaging\n\nC2 channel\n\nHost reconnaissance\n\nPublic IP + geolocation\n\n(nested  ipify  to  ip-\n\napi )\n\nChrome extension storage\n\ntheft\n\nHardcoded crypto-wallet\n\nextension ID list\n\nBeaverTail\n\nJavaScript (also ported\n\nto Qt/native)\n\nFake-interview lure +\n\nmalicious npm\n\npackages\n\nLoaded directly by lure\n\npackage\n\nHTTP POST to\n\nhardcoded C2\n\nYes\n\nYes\n\nYes\n\nYes\n\nPage 11 of 16\n\nail and OtterCookie has blurred in recent campaigns,\n\nOtterCookie\n\nNode.js\n\nMalicious npm\n\npackages\n\nLoaded directly by\n\nlure package\n\nSocket.IO\n\n(bidirectional)\n\nYes\n\nYes\n\nYes\n\nYes\n\nail and OtterCookie\n\nWeaselBiscuit\n\nNode.js\n\nMalicious npm packages\n\nNpoint dead-drop, Base64,\n\nin-memory  new Function\n\nPolling HTTP (Express\n\nroutes)\n\nYes\n\nYes\n\nYes\n\nNo\n\nCapability\n\nBrowser credential DB\n\ndecryption\n\nSeed-phrase / wallet-\n\naddress regex sweep\n\nFile exfiltration\n\n(documents, keystores,\n\nprofiles)\n\nClipboard capture\n\nKeylogging\n\nScreenshot capture\n\nRemote shell / arbitrary\n\ncommand execution\n\nInvisibleFerret / Python\n\nsecond stage\n\nPersistence\n\nPer-install campaign\n\ntagging in code\n\nhttps://opensourcemalware.com/blog/introducing-weaselbiscuit\n\nBeaverTail\n\nYes\n\nYes\n\nYes\n\nVariant-dependent\n\nNot typical\n\nNo\n\nVia InvisibleFerret\n\nhandoff\n\nYes\n\nLaunchAgent / registry\n\n/ startup entries\n\nNot observed publicly\n\nPage 12 of 16\n\nOtterCookie\n\nPartial (variant-\n\ndependent)\n\nVariant-dependent\n\nYes\n\nYes\n\nYes (recent variants)\n\nYes (recent variants)\n\nYes (over\n\nSocket.IO)\n\nYes (some variants)\n\nDetached process +\n\nvariant-specific\n\nNot observed\n\npublicly\n\nWeaselBiscuit\n\nNo\n\nNo\n\nNo (extension storage only)\n\nYes (operator-gated)\n\nYes, Windows only\n\n(operator-gated)\n\nNo\n\nNo\n\nNo\n\nDetached Node process +\n\n.pid  marker only\n\nYes, numeric identifier\n\n( 10 ,  12 ,  44 ,  79 ,\n\n95 ,  99 )\n\nConfidence and gaps\n\nClaim\n\nPackage is a malicious staged\n\nNode.js loader\n\nSecond stage is an infostealer\n\n103.170.217.184:8787\n\nthe C2 used by this stage\n\nThe implementation is a\n\nsimplified or new branch\n\nLinked to\n\nBeaverTail/OtterCookie\n\nlineage\n\nDPRK attribution\n\nA wholly new malware\n\nfamily\n\nThree of those signals are worth walking through in more detail.\n\nTradecraft signals worth flagging\n\nNpoint.io as the dead drop.\n\nlong time, and WeaselBiscuit’\n\ncontaining a Base64\n\npattern.\n\nhttps://opensourcemalware.com/blog/introducing-weaselbiscuit\n\nConfidence\n\nHigh\n\nHigh\n\nis\nHigh\n\nModerate\n\nModerate\n\nLow to\n\nmoderate\n\nLow\n\nDPRK npm crews have been using\n\ns usage is nearly identical to prior DPRK samples: hardcoded UUID, JSON blob\n\ncode  field, in-process  new Function\n\nBasis / limitation\n\nAuto-start, detached loader, remote Base64 code execution,\n\nand exact recovered payload match\n\nStatic collection and upload logic\n\nRetrieved configuration and observed client routes\n\nDistinct architecture and reduced capability set, though it\n\ncould also be a commodity copy\n\nNpoint dead-drop pattern is near-identical to prior DPRK\n\nnpm samples; nested  api.ipify.org  to  ip-api.com\n\nlookup matches DPRK stealer convention; Express polling\n\nC2 reads as a lightweight port of OtterCookie’s Socket.IO\n\ncontrol plane\n\nConsistent DPRK tradecraft signals, but no exclusive\n\ninfrastructure or shared code recovered\n\nRequires code-cluster, infrastructure, and victimology\n\ncomparison\n\napi.npoint.io  as a first-stage dead-drop for a\n\nexecution. Same service, same shape, same execution\n\nPage 13 of 16\n\nNested public-IP\n\nfeeds that IP to  ip-api.com\n\nstealers too. It isn’t a common commodity design.\n\nExpress HTTP C2 as a lightweight port of OtterCookie’s Socket.IO plane.\n\nplain Express routes, polling-based, no bidirectional socket. But its shape, with per-host status endpoints gating\n\nlive collection and separate exfiltration endpoints for clipboard and keyboard, reads as a stripped-down re-\n\nimplementation of the same control model OtterCookie runs over Socket.IO.\n\nCampaign markers resemble PolinRider.\n\nbaked into both package names and stage uploads mirror the campaign-marker convention seen in the PolinRider\n\ncluster. The operator is tracking installs at the same granularity\n\nIndicators of compromise\n\nType\n\nC2\n\nNpoint\n\nresolver\n\nNpoint\n\nresolver\n\nNpoint\n\nresolver\n\nNpoint\n\nresolver\n\nNpoint\n\nresolver\n\nNpoint\n\nresolver\n\nhttps://opensourcemalware.com/blog/introducing-weaselbiscuit\n\nand geolocation lookup. The second stage queries  api.ipify.org  for the public IP, then\n\nfor geolocation. That two-step nested lookup shows up in other DPRK-linked npm\n\nThe C2 architecture itself is new:\n\nThe numeric per-install identifiers ( 10 ,  12 ,  44 ,  79 ,  95 ,  99 )\n\n, using the same “ID in the package name” pattern.\n\nValue\n\n103.170.217.184:8787\n\nhttps://api.npoint.io/24c25d5f5fcbb0992a4f  (identifier  99 )\n\nhttps://api.npoint.io/641d37178a880b1e8b8f  (identifier  10 )\n\nhttps://api.npoint.io/33e8d008c334b060adad  (identifier  79 )\n\nhttps://api.npoint.io/ddae72efbb6714fae922  (identifier  12 )\n\nhttps://api.npoint.io/933a731a5e97f4b45249  (identifier  95 )\n\nhttps://api.npoint.io/24c12c4b66a29747764f  (identifier unknown, hard-coded by\n\nid79-client , HTTP 404 on retrieval)\n\nPage 14 of 16\n\nhttps://opensourcemalware.com/blog/introducing-weaselbiscuit\n\nType Value\n\nNpoint C2-\n\nconfig https://api.npoint.io/37c0a0c68bf7a94ed731\n\nresolver\n\nSecond-stage\n7b15605f23b131b3eeea57e031ae7cb32fc4b78c7bbb2025aa7a561ea5ae5159\nSHA-256\n\nnpm package @biz44/id10-client\n\nnpm package @biz44/id12-client\n\nnpm package @biz44/id44-client\n\nnpm package @biz44/id79-client\n\nnpm package @biz44/id95-client\n\nnpm package @biz44/id99-client\n\nnpm package @biz44/process-runtime-utils\n\nnpm package @biz44/runtime-utils\n\nnpm package engin1  (v1.3.99)\n\nnpm package id79-client\n\nnpm package process-lhpm\n\nPage 15 of 16\n\nhttps://opensourcemalware.com/blog/introducing-weaselbiscuit\n\nType Value\n\nnpm package process-tailwind  (v1.1.99)\n\nnpm package swnwall  (v1.2.10)\n\nRecommended investigation priorities\n\n1. Preserve the npm tarball, package publication metadata, maintainer account, dependency graph, download\n\nhistory, and source repository references.\n\n2. Search public and internal telemetry for all six Npoint UUIDs, the C2 IP and port, the stage identifiers\n\n10 ,  12 ,  79 ,  95 , and  99 , and the API route strings.\n\n3. Compare the loader and decoded stage against known BeaverTail/OtterCookie samples for shared\n\nfunctions, comments, string conventions, package names, and C2 patterns.\n\n4. Identify the importing parent application. The package itself has no npm lifecycle hook, so execution\n\nrequires an import or a manual start.\n\n5. Review affected endpoints for  .pid  files, Node child processes, PowerShell processes, and  %TEMP%\\kb-\n\nmonitor\\keyboard-monitor-*.ps1 .\n\nBottom line\n\nTreat  process-tailwind  as a high-confidence malicious supply-chain package, and treat it as a potentially\n\nimportant data point in how DPRK-linked JavaScript infostealers are evolving. Treat the “new DPRK strain” label\n\nas a working investigative hypothesis, not a conclusion, until it’s backed by corroborating code, infrastructure, or\n\ncampaign evidence.\n\nSource: https://opensourcemalware.com/blog/introducing-weaselbiscuit\n\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://opensourcemalware.com/blog/introducing-weaselbiscuit"
	],
	"report_names": [
		"introducing-weaselbiscuit"
	],
	"threat_actors": [],
	"ts_created_at": 1790301809,
	"ts_updated_at": 1790301914,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/0ffda0686deee2efb965de64dc9adeef819391ad.pdf",
		"text": "https://archive.orkl.eu/0ffda0686deee2efb965de64dc9adeef819391ad.txt",
		"img": "https://archive.orkl.eu/0ffda0686deee2efb965de64dc9adeef819391ad.jpg"
	}
}