Dear Members of the Board,
I am writing to report a confirmed cybersecurity breach of the building's video surveillance system. Unauthorized outside parties have gained administrator-level control of three of the building's five internet-connected video recorders and left their own accounts behind on each one. The accounts they left point to more than one outside party gaining access over time. I came across this while onboarding to the IntuVision camera system, when I noticed the network was configured differently from what had been described.
In brief, the three affected recorders were reachable directly from the public internet, were running older firmware, and were protected only by guessable administrator passwords. Some combination of those conditions was enough for an outside party to log in with full administrative rights and create accounts for itself. In several cases the intruders labeled their own accounts openly, effectively signing their work. It is not possible to determine after the fact exactly what was viewed or copied through this equipment; what is confirmed is the unauthorized access itself, on three of the five devices. Those three are the oldest recorders in the system. The newer recorder and the main network video recorder were checked and show no sign of the same access. The pattern of accounts indicates the recorders were reachable and weakly protected long enough to be found and re-entered by more than one party, rather than breached in a single isolated event.
One point on scope: what we found is contained to the surveillance system. The cameras and recorders sit on a network segment that was deliberately separated from the resident network several years ago, and that separation is what has kept this limited to the surveillance equipment rather than the building's wider network. To be clear about the boundary of this review: I examined the camera network, not residents' individual networks or personal devices, so this report speaks to the surveillance system only. What turned a long-standing risk into an actual breach was narrow and fixable: these recorders were left reachable directly from the public internet through two convenience features, UPnP and P2P, on older firmware with weak passwords. Closing that internet exposure is the core of the fix.
The equipment does not retain enough history to fix a precise date for when this began. There are, however, clear indications that the unauthorized access postdates the system's 2022 installation, so the window is best understood as sometime between 2022 and today. The Executive Summary explains the basis for that estimate.
The Executive Summary below sets out what we found, why it matters for this building, and what should happen next, in plain terms. The full Technical Security Audit, linked at the end of that summary, carries the supporting evidence: screenshots of the unauthorized accounts on each affected recorder, how the exposure occurred, and a device-by-device remediation plan. It is deliberately detailed so it can serve the Board and the camera and network vendors directly, and it draws on a good deal of outside research into how comparable intrusions have been remediated.
The immediate containment step, disconnecting the affected recorders from the internet, is low cost and reversible, and I recommend doing it promptly rather than waiting for the next maintenance cycle: it stops any ongoing outside access at once, and nothing is lost by acting early. I want to be measured about the rest. The evidence indicates the exposure has existed for months, likely longer, so it is a long-standing condition to be corrected rather than a sudden new event. The cameras on the affected recorders cover reception and lobby areas, the parking decks, elevator lobbies, and a view into the building's main network equipment room. I was not able to confirm whether any of those cameras carry audio; administrator-level access can enable a camera's microphone even if it was previously turned off, which is part of why the audio question is worth answering.
Whether to treat this as an emergency is a judgment the Board is best placed to make, after reviewing which cameras are affected, the audio question, and the risk of continued exposure. Standard guidance for this class of equipment is to keep it on the local network only, with no direct path from the public internet, and to route any remote viewing through a secured connection the Board can decide on separately.
What I do want to be clear about is that containment is not the whole fix. Because these recorders were under outside administrative control, properly closing this out means rebuilding or replacing the affected units and rotating credentials across the system. That work carries hardware cost, labor cost, and lead time, and the Board is better served planning and funding it now than deferring it.
This work was done on my own time and at no charge, as a resident. It has come to roughly ten hours of my time in total. Given what it turned up, I would recommend the Board commission an independent security review, carried out by a party not tied to the current camera or network vendors, so the findings and the corrective work are checked by someone outside the arrangement that allowed this to develop. I would be glad to take that on, or to advise on it, if the Board would like to engage me for it.
| Property | The Gallery |
|---|---|
| Assessment period | 22 - 25 July 2026 |
| Prepared by | Aref Kashani, Elberta Labs LLC |
Scope of this review: the assessment covered the building's surveillance network. The compromise is confined to the video recorders and cameras, which sit on a segment separated from the resident network. Residents' own networks and personal devices were outside the scope of this review and were not examined.
Confirming this was hands-on, on-device work spanning parts of two days (roughly ten hours in total) to safely obtain access to each recorder, catalogue what had been done to it, and identify exactly what each one could see, not a quick scan.
Three of the building's five internet-exposed recorders already have administrator accounts on them that nobody at the building or its vendors created: 25 such accounts across the three. Several are attackers' “calling cards,” including one (CamhubfreeTG) that matches an organized operation known for trading footage from hijacked cameras. The account patterns indicate more than one outside party gained access over time, not a single clean break-in: two of the recorders share one intruder's account set, while the third additionally carries a distinct second cluster of accounts seen nowhere else. In practice that means there is no single point of entry to close, and no basis to assume the intruders are related or share intent.
What was visible through these three recorders: common areas on one (lobby, front desk, the gallery/event space, gate and side entries); the full parking structure across every level on another, including vehicles and potentially legible license plates; and, on the third, interior hallways plus a camera view of the building's network equipment closet. That last item is particularly sensitive: it exposes the physical network infrastructure itself, not just hallways or parking, which is a materially different kind of exposure. The two remaining internet-exposed recorders were also checked and show no sign of unauthorized access.
On timing: on each affected recorder, every unauthorized account was created after the integrator's own maintenance account, which was added when the system was set up. That places the intrusions after the 2022 installation rather than before it. The recorders do not retain activity logs far enough back to fix a precise date, so the accurate statement is that the access occurred sometime between 2022 and now.
The recorders automatically created firewall openings, using features called UPnP and P2P/cloud, and are now reachable from the public internet. This includes the automated scanners that routinely look for this type of equipment. The exposure was not necessarily set up by anyone; the devices created it themselves, and will recreate it unless the features are disabled.
The administrator password follows a predictable pattern: the installer's company name followed by the digit 1. The equipment's own password-strength indicator rates it as weak. The built-in lockout (five attempts, then a 30-minute pause) provides little protection in this case. It is designed to stop large-scale blind guessing, but a person who knows the installer needs only a few attempts. An admin interface that is both reachable from the internet and guessable is how the access described in Finding 01 was possible.
Four cameras run 2017-era software that the manufacturer no longer updates. They carry serious flaws that allow takeover without a password, a category the U.S. Cybersecurity and Infrastructure Security Agency (CISA) lists as actively exploited. No patch is available, so these cameras should be replaced.
The equipment (Dahua) is barred from U.S. federal use and from new U.S. sales on national-security grounds, and the manufacturer is on a U.S. human-rights sanctions list. The equipment is configured with internet access, and a recorder's cloud “phone-home” feature was observed connected during the assessment. Whether the cameras themselves are permitted internet access is not confirmed, and the available signs are not encouraging; confirming it requires the router login. Deliberate data exfiltration by the vendor is not proven. For a building with high-profile residents, a reasonable approach is to block the cameras from reaching the internet, which also removes the question.
On the recorders inspected, the on-device firewall, denial-of-service protection, and video-stream encryption are all disabled. As a result, resident video travels the network unencrypted, and a recorder can be taken offline (a loss of recording) with limited effort. Only the login lockout is enabled.
A surveillance system is both a privacy system and a physical-security control, and this one has been compromised: unauthorized parties hold administrator access, had the ability to view live and recorded footage at will and should be assumed to have done so, and can reach any credentials stored on the system. The practical risk to residents follows from what that access allows. The cameras cover the building's common areas and entrances rather than individual units, but someone watching those feeds can still observe residents' comings and goings, follow a specific person's movements through the building, or identify when to follow an authorized person into a secured common area. Because the access is administrative rather than a simple video feed, the same parties can also disable or black out cameras on demand, including to remove coverage during a physical entry. A camera trained on the building's network closet gives an outsider a continuous view of the core equipment and of anyone working on it, useful reconnaissance for a further attack. The Board holds privacy and fiduciary responsibility for this footage. This is not legal advice, but because breach-notification timelines and cyber-insurance notice provisions commonly run from the date a breach is discovered rather than the date it is fixed, the Board should promptly confirm with its attorney and its cyber-insurer whether any resident-notification or insurer-notice obligations apply; late notice to an insurer can itself jeopardize coverage.
These are incident-response actions, not hardening suggestions. The Priority 0 steps should begin promptly, in roughly this order.
Physically disconnect the site's internet connection (or isolate the three affected recorders from it). This is the single fastest step: it simultaneously closes the inbound openings attackers use and cuts any outbound connection back to them, and it does not depend on logging into a device that is already compromised. The cameras keep recording locally while contained.
Deleting the rogue accounts and changing passwords does not evict an attacker who already has full control of a device: it can hold hidden accounts, altered settings, or modified firmware that a simple cleanup will not remove. Each affected recorder must be fully factory-reset and reloaded from known-good firmware and rebuilt from scratch, or replaced. The three affected units are the oldest, end-of-life generation in the building and cannot be brought to a current security standard: plan to replace them rather than patch. This is where real hardware cost and lead time come in.
“Change the passwords” on the affected recorders is not enough. Assume every stored credential on this network is in attacker hands and rotate all of them: every camera and recorder, the router/gateway, the analytics PC, and every email, dynamic-DNS, and cloud account tied to the system, with strong, unique, centrally-managed passwords.
Before wiping any device, preserve the evidence already captured (account lists, logs, configs). Notify the board and the association's cyber-insurance carrier now: breach-notification and insurer-reporting clocks may already be running, and late notice can jeopardize coverage. Because the intruders are tied to an organized operation, a report to the FBI (via IC3, ic3.gov) is worth considering once the review establishes which cameras were exposed and whether any could have been used to capture audio. Limit disclosure to those who need to know.
An unidentified small computer on the surveillance network (reachable only by a remote key its owner holds) is still unaccounted for and could be a standing access point: identify and remove or bring it under control. Inspect the analytics PC and the router for signs of the same attackers, since a controlled recorder can be used to reach them. Note too that several cameras carry microphones, so this is a potential live-audio (eavesdropping) exposure in common areas, not only video: administrative access can switch on a camera's microphone even where it was disabled in the configuration, so part of the review is establishing which cameras have microphones and whether any were turned on.
Once contained, close the exposure permanently: disable UPnP and P2P/cloud on every device, remove the router's port-forwards, and block the cameras and recorders from reaching the internet. Provide remote viewing only through a private encrypted connection (a VPN such as Tailscale). Updating firmware is not a substitute for this: new vulnerabilities against this device family are found on an ongoing basis (Dahua published one as recently as June 2026), so a fully patched recorder that stays reachable from the internet is exposed to the next one, and firmware needs an ongoing review cycle regardless. Getting the system off the internet is what actually closes the exposure.
The compromise is confirmed on the recorders; the cameras must be treated as reachable and unverified until each is checked. A controlled recorder holds the cameras' passwords and sits on the same network as them, so a camera not being individually internet-facing does not protect it. Each camera should be checked for unauthorized accounts and have its credentials rotated. Separately, the camera network, which is already kept apart from the resident wifi, should be tightened so the cameras and their recorder sit on their own segment with no path to the internet or to the rest of the building, and so the old, compromised equipment is walled off from the clean and replacement equipment during the changeover. The companion Technical Security Audit details the per-camera check and this segmentation design.
They cannot be patched. Prefer a manufacturer that is not U.S.-restricted.
Turn on the on-device firewall, denial-of-service protection, and stream encryption; apply current firmware; and disable the vendor cloud. These provide defense in depth once the system is off the internet.
One item could not be verified within this assessment, and it does not change the priorities above: whether the cameras specifically (as distinct from the recorders) are blocked from the internet. A host on their network reached the internet, but confirming a per-device block requires the router login.