elasticsearch · ransomware · extortion · data-exposure · on-chain-analysis · bitcoin · cloud-misconfiguration · census
Exposed Elasticsearch: Inside the Ransom-Wipe Economy
Kinryū Labs censused 17,043 internet-facing Elasticsearch hosts and found that a wiped husk with a ransom note in it is the single most common state of an exposed cluster: 5,073 of them. Tracing every wallet the notes advertised gives five actors, eleven payments and about $5,553 in total revenue, and shows the promise to return deleted data is unsupported by the evidence.
By Davis Zheng·
TLP:CLEAR. Cleared for public release. Findings come from an internet-wide census of exposed Elasticsearch, run from a single cloud vantage, and from on-chain analysis of every Bitcoin and Ethereum address advertised in the ransom notes. Attacker wallets, contact addresses, note text and links are indicators and are published here; links and contact domains are defanged. Affected organisations are handled under separate disclosure and are not named.
Executive summary
- 7,648hosts open with no authentication
- 5,073ransom-wiped husks
- $5,553total paid, all actors, all time
- 1.2%victims who later enabled auth
Point an unauthenticated scanner at the internet’s Elasticsearch and most of what answers is wreckage: clusters emptied and left with a ransom note where the data used to be. We censused 17,043 Elasticsearch hosts from a single cloud vantage; 11,850 answered. Of those, 7,648 were open with no authentication at all, and 5,073 of the open hosts had already been emptied and left with a note in place of their data. A wiped husk with a note in it is the single most common state of an exposed Elasticsearch cluster.
Reading those notes in full from 2,500 hosts groups them into seven templates run by five actors. We then traced every wallet the notes advertised. Across all five actors, thirteen Bitcoin addresses and one Ethereum address, over a span of more than a year, the campaigns took eleven payments totalling 0.06 BTC, worth about $5,553 at the price prevailing when each one landed. The overall payment rate across attributable victims is 0.28%.
The dominant actor’s pitch is that your data is deleted from your server but held safe on its cluster, and comes back once you pay. The evidence does not support it. The recovery code the note swears is unique to your database turns out to be a single fixed string, identical across 1,199 victims in 56 countries. Victims, for their part, mostly do not fix the underlying exposure. Re-probed seven weeks after the census, 52% of a 2,500-host sample were still open, still wiped, with the note still in place, and only 1.2% had turned authentication on.
- Ransom-wipe is the modal state of an exposed cluster. 5,073 of 7,648 open, no-auth hosts (66%) had been wiped and ransomed. An exposed Elasticsearch is likelier to be a looted husk than a working database. High confidence, directly measured.
- The retained-data claim is unsupported. The dominant actor issues a fixed recovery code across 1,199 victims and destroys data by dropping indexes rather than exporting them. Nothing in the evidence indicates a copy was kept. High confidence.
- This is opportunistic automation, not targeted intrusion. More than nine in ten victims run a current Elasticsearch release; the way in is an open port, and a patch would not have closed it. High confidence.
- The economics are marginal. $5,553 across eleven payments in more than a year, with 8 of 13 wallets never receiving a satoshi. This looks like a cheap script run at scale, not an organised ransomware business. High confidence.
- Small, per-victim campaigns beat the mass spray. One actor extorting three hosts with per-victim wallets out-earned the actor who hit 3,730 with a shared one. Moderate confidence; the sample is three victims, so the direction is clearer than the magnitude.
The census: how many, and in what state
A masscan sweep surfaced roughly 39,900 Elasticsearch and Kibana candidate endpoints. Resolving the Elasticsearch side to a clean per-host verdict from the vantage leaves 17,043 hosts with a canonical result. Of those, 11,850 answered HTTP and 5,193 did not.
The verdicts on the full 17,043:
| Verdict | Count | Meaning |
|---|---|---|
| Open, no auth | 7,648 | GET / returns 200 with no credentials; directly readable |
| Protected | 4,026 | 401/403, and the well-known defaults fail |
| Dead | 5,193 | no HTTP from the vantage |
| Auth required | 71 | 401/403, not yet credential-tested |
| Default creds | 39 | a well-known default credential authenticates |
| Other | 66 | reachable but non-Elasticsearch or an odd status |
Nearly two thirds of the reachable hosts answer with no authentication at all. The word “open” needs care, though, before anyone turns it into a victim count.
Of the 7,648 open hosts, 5,073 are already ransom-wiped husks, and a further slice are decoys: a cluster of auto-named nodes serving an identical canned schema, plus hosts that forge their index listings to look fuller than they are. Strip both out and the residue of genuinely open clusters still holding real, un-ransomed data is roughly 2,500. The high-value cases inside that residue are handled under separate disclosure and are not named here.
Geographically the open, no-auth population is a Chinese plurality by a wide margin: CN 2,518, then US 874, DE 731, FR 518, IN 435, MX 277, RU 256, SG 181, JP 131, KR 125, NL 124, GB 120.
The 39 default-credential hosts are a smaller and sharper problem. Six well-known default pairs were tested read-only (elastic:elastic, changeme, password, bitnami; admin:admin; kibana:kibana), with the privilege each one granted confirmed per host. They split into two classes: kibana_system accounts, which see metadata but get a 403 on _search, and full elastic superusers with read, write and delete. A weaker residential vantage had missed 26 of the superuser logins entirely, which is a preview of the vantage-bias problem discussed at the end. The worst single case is a default-credentialled Elastic Defend EDR and SIEM stack with Fleet attached, where superuser access to a security product buys alert tampering and a management-to-agent path to code execution on every host it manages.
The ransom notes
The victims are not who you would expect from the usual “unpatched box on the internet” story. By major version, the wiped hosts run v8 (2,535), v7 (1,960), v9 (299), v6 (117), v5 (61) and v2 (42). Current releases dominate: v7, v8 and v9 together are 4,794 of them, more than nine in ten. These are maintained, up-to-date clusters that happen to have no password on the front door. The exposure is the open port, and patching would not have closed it.
Hosting concentrates in the big Chinese clouds (Alibaba 730, Tencent 500, Volcano Engine 330, Huawei 84, about 1,644 combined) and then the European budget providers (OVH 324, Contabo 250, Hetzner 236), with a single-provider cluster at Baja Datacenter in Mexico (231). Victim geography tracks the exposure geography: CN 1,972, US 527, FR 423, DE 360, MX 235, RU 212, and a long tail.
What the notes say
Reading 2,500 hosts in full recovered 1,309 complete notes, which normalise, once the wallet, contact, amount and code are factored out, to seven distinct templates. One of them accounts for nearly everything. Links and contact domains below are defanged.
Actor A, the dominant template, 1,199 of 1,309 notes (92%), across 56 countries:
Your database has been deleted from your server, but all the information remains stored on our cluster. The instructions for recovery are as follows: You must send 0.0041 BTC to the following wallet:
bc1q38rjul6gdamfflf6p4ukz0ymtvfgfv2j9saf6r. Then, you must send an email towendy.etabw@gmx[.]comwith the following code: 0SH7HH1Q72JL (it is important that you write it correctly, as it corresponds to your database). You must also attach the txid (the Bitcoin transaction ID) to the message. After following these steps, we will send you a zip file with all your information. You have 48 hours to complete the steps. For More Info - hxxps://tli[.]sh/73x1k
Within this one template the amount varies (0.0016, 0.0035, 0.0041, 0.0061 BTC), as do the wallet, the contact address (wendy.etabw@gmx[.]com, scandal@onionmail[.]org, bitwezen@cock[.]li) and the code (0SH7HH1Q72JL or BITWEZEN2026). The deadline is always 48 hours.
One template is different enough to quote in full. Alone among the seven it threatens to publish the data rather than delete it, offers an Ethereum option alongside Bitcoin, and asks for a materially larger sum, roughly twelve times Actor A’s demand:
Actor E, leak-threat, dual-chain, 3 notes:
Your database was compromised. Pay 0.1 ETH to
0x3C11Cf2974c3Fb4d7ebBfea711a4A0b26989979Dor 0.05 BTC tobc1qu8t03mv2qwjv56gry2ft0qes0xwqhddjhsvkfl. THIS IS A UNIQUE ADDRESS GIVEN TO YOU AND YOUR PAYMENT WILL BE AUTOMATICALLY DETECTED. UPON WHICH WE WILL RESTORE YOUR DATA. IN 48 HOURS IF NO PAYMENT IS MADE WE WILL LEAK YOUR DATA PUBLICLY.
The remaining templates, including a broken mail-merge variant of Actor A’s note, are reproduced verbatim below for defenders matching against them.
The other note templates, verbatim (defanged)
Actor B “sharebot”, 101 notes, 15 countries:
Your database has been backed up to our secure servers. To recover your data, send exactly 0.0061 BTC to:
bc1quwlw8djc7hfamf3qpspma34uh9dr6w4kudfu8pThen emaildb-recovery@sharebot[.]netwith your server IP and transaction ID. We will reply with a download link within 24 hours. If no payment is received in 48 hours, your data will be permanently deleted.
Actor B “sharebot”, coded variant, 2 notes:
Your data has been backed up. To recover it, send 0.0061 BTC to:
bc1qquzg5dg5yfqxlc0fy6pemcwa2xg5mw3l7l2gc4. Then emailes-recovery@sharebot[.]netwith code: 841BEACF110F and attach the transaction ID (txid). You will receive a download link within 24 hours. Do not modify this index.
Actor D, 1 note:
Your DB has been back up. The only way of recovery is you must send 0.002 BTC to
127ZBzXyLJFc7ShMmzkYFDhSiXXSnR8Jfr. Once paid please emaildatabaserestore32@onionmail[.]orgwith code: omoRmq and we will recover your database. please read hxxps://cutmyurl[.]com/3caF8EkT for more information
Actor A, broken mail-merge variant, 3 notes:
Your database has been deleted from your server, but all the information remains stored on our cluster. […] You must send 0.0041 BTC to the following wallet:
bc1qu8t03mv2qwjv56gry2ft0qes0xwqhddjhsvkfl. Then, you must send an email to This is a unique address given to you and your payment will be automatically detected, upon which we will restore your data. with the following code: 0SH7HH1Q72JL […]
The contact slot has been filled with a sentence instead of an email address. That sentence is verbatim from Actor E’s template, and the wallet is the one Actor E uses.
The recovery code is not per-victim
Actor A’s note leans on one promise: your data is safe, and the code proves we can hand back yours specifically. Across the 1,199 sampled victims in 56 countries, that code takes exactly two values, 0SH7HH1Q72JL and BITWEZEN2026. It is a constant baked into the template at build time, not an identifier tied to a victim.
The consequence is not subtle. An operator who cannot tell one victim from another cannot return one victim’s data on request. Combine that with the fact that the wipe is a bulk index delete and not an export, and the “all the information remains stored on our cluster” line has no support in anything observable here. Actor B’s coded variant does carry what look like distinct per-victim codes, but that variant reached 2 hosts out of 1,309, and Actor B has never been paid.
A shared kit ties two “actors” together
The broken variant above is a small forensic gift. Actor A’s misfired note and Actor E’s leak-threat note share a wallet (bc1qu8t03mv2qwjv56gry2ft0qes0xwqhddjhsvkfl) and share a sentence, word for word, sitting in the wrong field of Actor A’s note. The economical reading is a shared note-generation kit with configurable slots for wallet, contact, amount and deadline, where one run wrote Actor E’s blurb into Actor A’s contact slot. In estimative terms that is likely: one operator running both scripts, or two operators sharing a kit, both fit, and note text alone cannot separate them. What the evidence rules out is treating these two as wholly independent.
The actors
| Actor | Contact(s) | Theme | Demand | Victims | Addresses |
|---|---|---|---|---|---|
| A (dominant) | wendy.etabw@gmx[.]com, scandal@onionmail[.]org, bitwezen@cock[.]li | deleted from your server, stored on our cluster; fixed code; tli[.]sh link | 0.0016 to 0.0061 BTC | ~3,730 | 4 |
| B “sharebot” | db-recovery@, es-recovery@sharebot[.]net | backed up to our secure servers; 24h link / 48h delete | 0.0061 BTC | ~262 | 5 |
| C “rambler” | rambler+<id>@onionmail[.]org (unique per victim) | per-victim wallet and email | ~0.0041 BTC | 3 | 3 |
| D | databaserestore32@onionmail[.]org | legacy P2PKH wallet; cutmyurl link | 0.002 BTC | 1 | 1 |
| E | none (pay-only) | leak threat; BTC or ETH | 0.05 BTC / 0.1 ETH | 3 | 1 BTC + 1 ETH |
Actor A sprays one shared wallet across thousands of victims. Actor C does the opposite, minting a fresh wallet and a rambler+<id> email for each of its three. That difference in tradecraft turns out to decide who actually got paid.
Following the money
Every advertised address was queried against a public block explorer, read-only. USD figures are the value at the block time of each payment, not today’s spot price.
| Metric | Value |
|---|---|
| Advertised BTC addresses | 13 |
| Addresses that ever received anything | 5 |
| Total received | 0.05995249 BTC |
| Total value at time of payment | $5,553.21 |
| Payments, all actors, all time | 11 |
| Attributable victim hosts | 3,996 |
| Overall conversion | 0.28% |
| Addresses with zero revenue | 8 of 13 |
| First / last payment | 2025-05-27 / 2026-06-04 |
Broken out by actor, the ordering is the finding:
| Actor | Addresses | Victims | Payments | BTC received | USD at time |
|---|---|---|---|---|---|
| A | 4 | 3,730 | 5 | 0.02442141 | $1,686.65 |
| C (rambler) | 3 | 3 | 6 | 0.03553108 | $3,866.56 |
| B (sharebot) | 5 | 262 | 0 | 0.00000000 | $0.00 |
| D | 1 | 1 | 0 | 0.00000000 | $0.00 |
| E | 1 BTC + 1 ETH | 3 | 0 (BTC leg) | 0.00000000 | $0.00 |
Actor C extorted three hosts and took more money than Actor A took from 3,730. Its three victims made six payments, several at roughly double the demand, which is what you would expect from notes that threaten to raise the price when a deadline passes. Actor B is the cleanest negative result in the set: 262 victims across 15 countries, a professional-looking note, a domain-based contact address, and not one satoshi, ever.
The whole revenue of every campaign here is eleven transactions. It fits on one screen:
| # | Time (UTC) | Actor | Address | BTC | USD at time | Matches demand |
|---|---|---|---|---|---|---|
| 1 | 2025-05-27 16:49 | C | bc1qk2cc4… | 0.00413108 | $455.32 | ~0.0041 |
| 2 | 2025-10-29 12:52 | C | bc1qqmyg9d… | 0.00750000 | $848.68 | no (~2x) |
| 3 | 2025-10-30 18:41 | C | bc1qqmyg9d… | 0.00760000 | $816.67 | no (~2x) |
| 4 | 2025-11-01 20:27 | C | bc1qqmyg9d… | 0.00390000 | $429.99 | ~0.0041 |
| 5 | 2025-11-10 13:42 | C | bc1q5xj2m… | 0.00820000 | $868.57 | no (~2x) |
| 6 | 2025-11-10 14:45 | C | bc1q5xj2m… | 0.00420000 | $447.33 | ~0.0041 |
| 7 | 2026-02-02 05:52 | A | bc1q38rjul… | 0.00410000 | $310.83 | yes |
| 8 | 2026-02-07 00:08 | A | bc1q38rjul… | 0.00372427 | $262.65 | no |
| 9 | 2026-02-14 09:07 | A | bc1q38rjul… | 0.00608500 | $424.20 | no (~0.0061) |
| 10 | 2026-04-07 07:25 | A | bc1q38rjul… | 0.00410000 | $281.14 | yes |
| 11 | 2026-06-04 19:18 | A | bc1qvrryy2… | 0.00639778 | $407.83 | no (~0.0061) |
Only two of the eleven match a demanded figure exactly. The near-misses (0.00372427, 0.006085, 0.00639778) are what a fee-inclusive “send max” or a USD-to-BTC conversion look like at the moment of sending, rather than someone copying an exact amount. Actor C’s window (May to November 2025) and Actor A’s (February to June 2026) do not overlap.
How the money leaves
Every payment was swept out promptly. The median time from payment to sweep is about two and a half hours; the fastest was eleven minutes. Each sweep is a single-input transaction, one payment in and one spend out, with no consolidation, which is why a common-input-ownership analysis across all thirteen addresses returns zero clusters. Whether that reflects deliberate operational security or simply the fact that no wallet ever held two payments to consolidate cannot be told from eleven data points.
The two actors who got paid then behave in opposite ways, and the difference matters for anyone who wants to follow up. Actor A’s proceeds flow within a single hop into high-volume custodial infrastructure, wallets with tens or hundreds of thousands of lifetime transactions, the kind of service that plausibly holds know-your-customer records. Actor C sends only into fresh, single-use addresses that have never been reused. So Actor A has left a short, subpoena-length trail to a KYC-bearing chokepoint, while Actor C has not. No cash-out address is shared between the two, and no downstream address is reached by both, so the chain does not merge them; the link between Actor A’s kit and Actor E rests on note text and a shared advertised wallet, not on money flow. (The specific downstream service addresses are investigative pivots rather than block-list indicators, and the high-volume ones belong to shared services, so they are not reproduced here to avoid tarring a custodian with an operator’s activity.)
The Ethereum leg
Actor E’s Ethereum address, advertised at 0.1 ETH, has a history that does not match the demand at all. Its entire substantive life is a single 108-minute burst on 2026-07-27, five weeks after the census: about 3.97 ETH arrives and then leaves in clean 0.5 and 1.0 ETH chunks to seven counterparties, twice over. Nothing in it is a 0.1 ETH victim payment, and no Elasticsearch note demands anything close to the ~4 ETH that moved. We assess it likely to be a pass-through or layering hop, attacker-associated infrastructure rather than evidence of ransom revenue. The fourteen dust transfers into it are third-party address-poisoning spam and say nothing about the operator.
Seven weeks later
The most useful thing about a census is doing it twice. On 2026-08-07 we re-probed a deterministic random sample of 2,500 of the 5,073 ransomed hosts against the census baseline:
| Outcome | Hosts | Share | Meaning |
|---|---|---|---|
| Still noted | 1,309 | 52.4% | still open, still wiped, note still present |
| Unreachable | 829 | 33.2% | no HTTP: decommissioned, firewalled, or re-addressed |
| Note gone | 332 | 13.3% | host answers, but the note is no longer there |
| Auth enabled | 30 | 1.2% | authentication now enforced |
Only 1.2% of victims closed the door that let the incident happen. More than half changed nothing at all in seven weeks. Even reading every “unreachable” host generously as remediation-by-decommission puts the ceiling at about a third, and “unreachable” also covers hosts that merely moved or that a transient network blip hid.
One cohort breaks the pattern completely. Of 114 sampled Mexican hosts, 113 are alive with the ransom index gone and none still carry a note, against a baseline where Mexico's victims were concentrated almost entirely in a single provider (Baja Datacenter, 231 hosts). No other country looks like this. A hoster- or operator-side bulk cleanup of one provider's estate is the most economical explanation, but the current data cannot rule out a second actor having wiped the notes, and either way the hosts remain reachable and unauthenticated. Flagged for follow-up.
Indicators of compromise
Wallets and codes are attacker-authored and carried live so defenders can match and trace them. Contact domains and links are defanged.
Bitcoin (Actor A):
bc1q38rjul6gdamfflf6p4ukz0ymtvfgfv2j9saf6r (3,705 victims)
bc1qvrryy2vsq4jekejs8z2elkt3sxmhlyad06ymvr (25 victims)
bc1qzkk2cld734njkds9263udc2wqgncp9e3th66ps
bc1qu8t03mv2qwjv56gry2ft0qes0xwqhddjhsvkfl (shared with Actor E)Bitcoin (Actor B, “sharebot”):
bc1quwlw8djc7hfamf3qpspma34uh9dr6w4kudfu8p bc1qvrte050fngjlrmcuptz33259kw3wktkd3uv5hv
bc1qquzg5dg5yfqxlc0fy6pemcwa2xg5mw3l7l2gc4 bc1qt5cq2mnghwyyfl0pkd3086z9cad0m3hspwgl9t
bc1qqy3uegcgqjjncagjnkqgpplyl3k4a00khek5rsBitcoin (Actor C, “rambler”):
bc1qk2cc4ssl9j3d0xu5ljv0prsfzjdulvgvm4u6e7 bc1q5xj2mvtaupy56fff4dsaxwjxm8ftjzxfhw3ylh
bc1qqmyg9d9uj2fm93fjjjfuw2xrq2fwpr53uhf52dBitcoin (Actor D): 127ZBzXyLJFc7ShMmzkYFDhSiXXSnR8Jfr
Ethereum (Actor E): 0x3C11Cf2974c3Fb4d7ebBfea711a4A0b26989979D
Contact addresses (defanged):
wendy.etabw@gmx[.]com scandal@onionmail[.]org bitwezen@cock[.]li
db-recovery@sharebot[.]net es-recovery@sharebot[.]net
rambler+<id>@onionmail[.]org databaserestore32@onionmail[.]orgRecovery codes: 0SH7HH1Q72JL (Actor A, fixed, not per-victim), BITWEZEN2026, 841BEACF110F, BCA95C11355F (Actor B), omoRmq (Actor D).
Links (defanged): hxxps://tli[.]sh/73x1k (redirects to a paste[.]sh note whose decryption key sits in the URL fragment, so the content is decrypted in the browser and the host never sees it, which makes a content-based takedown request pointless), hxxps://cutmyurl[.]com/3caF8EkT (a commercial link shortener; its abuse channel is the route for Actor D’s link).
Behavioural: an Elasticsearch cluster reduced to a single index named read_me (median resident document count of one, the note itself); a GET /read_me/_search returning any of the templates above.
What to do about it
- Put authentication in front of Elasticsearch and Kibana, and keep the HTTP port off the public internet. Current Elasticsearch ships with security enabled by default; almost every host here had it switched off or bound to a public interface. That one control closes the whole attack surface described above.
- If you are hit, do not pay. The dominant operator cannot tell your data apart from anyone else’s and, on the evidence here, kept no copy of it. Payment funds the next sweep and buys nothing back. Restore from your own backups and close the exposure.
- Assume a wiped cluster was read before it was wiped. It sat open to anyone, not only the actor who eventually deleted it, so treat whatever it held as disclosed and rotate any secrets in it.
- Check your own estate the way an attacker would. An external, credential-free
GET /against your Elasticsearch endpoints tells you in one request whether they answer without a password. Run it from outside your network, because an internal check will not see what the internet sees. - Reset the defaults. Six well-known credential pairs still work on 39 hosts here, one of them a security product. Change the
elasticandkibanapasswords and any vendor defaults, and confirm what privilege each account actually holds.
MITRE ATT&CK mapping
| Tactic | Technique |
|---|---|
| Initial Access | T1190 Exploit Public-Facing Application (open, unauthenticated Elasticsearch); T1078.001 Valid Accounts: Default Accounts (the 39 default-credential logins) |
| Impact | T1485 Data Destruction (bulk index delete); T1491.001 Internal Defacement (the read_me note left in place); T1657 Financial Theft (extortion) |
The notes also claim exfiltration (T1567) and, in Actor E’s case, threaten leak-based extortion (T1657). The evidence supports neither claim of a retained copy; the destruction is real, the exfiltration is asserted.
Methodology and analyst notes
- Vantage bias is large, and we measured it. A residential or local vantage called 63% of hosts “dead” that were in fact live from a clean cloud vantage (7,201 of 11,388; 7,113 of them wide open). Any exposed-asset census that does not control for where it scans from undercounts by a wide margin. This census is single-vantage, one cloud location, with per-record vantage and timestamp tags, and all counts are single-vantage figures.
- Decoys inflate the raw “open” count. A set of auto-named nodes with an identical canned schema, and hosts that forge their index listings, have to be excluded before an open host is treated as a victim. That is already done in the numbers above.
- The note sample is 2,500 of 5,073 hosts (49%), deterministically seeded so re-runs are comparable. Template proportions carry sampling error, and the rarest templates (one to three notes) establish that a thing exists, not how common it is.
- On-chain totals are floors. They cover only the addresses advertised in notes we actually read. Unread notes, unsampled hosts and any address never observed are not in the count. High-volume downstream addresses belong to shared services; only the specific amounts sent from the ransom wallets are attributable to an actor, and the services’ lifetime totals are not.
- Read-only throughout. Notes were read from already-wiped, no-auth clusters with one unauthenticated
GET /read_me/_searchper host. Credential testing was six defaults, oneGET /each, throttled, read-only. Chain queries hit public explorers only. No victim content was retrieved, and the client-side-encrypted paste linked by Actor A was not decrypted. - Estimative language follows ICD 203, and confidence reflects the evidence in this dataset only. Specific affected organisations, including the high-value clusters in the un-ransomed residue, are handled under separate responsible disclosure and are not named.
The underlying census data and wallet analysis are available to other researchers and defenders on request. Email [email protected] with a short note on who you are and what you need it for.