[{"data":1,"prerenderedAt":146},["ShallowReactive",2],{"publication:en:P146":3},{"meta":4,"copy":16,"relatedArticles":132,"terms":133,"term":134,"resourceParent":140,"glossaryParent":143},{"id":5,"path":6,"kind":7,"keyword":8,"title":9,"seoTitle":10,"description":11,"incoming":12,"updated":15},"P146","\u002Fglossary\u002Fbackdoor","term","what is a backdoor","What is a backdoor? Hidden access and website persistence","What is a backdoor? Hidden access and persistence","Understand backdoors, web shells and persistence on a website. Learn why deleting one file is different from closing unauthorized access and verifying recovery.",[13,14],"\u002Fservices\u002Fwebsite-recovery","\u002Fservices\u002Fsecurity-audit","2026-10-30",{"intro":17,"sections":18,"checklist":91,"faq":97,"links":107,"sources":124,"cta":127},"A backdoor is an undocumented access route that can bypass the way a system is intended to be accessed or controlled. In a website incident it may provide continuing unauthorized access even after visible damage is removed. A suspicious file alone does not prove a backdoor, and deleting one confirmed file does not establish that every access path has been closed.",[19,28,37,73,81,86],{"title":20,"paragraphs":21,"sources":24},"Understand hidden access without reducing it to one file type",[22,23],"NIST's glossary includes source-specific definitions of a backdoor as an undocumented way to access a computer system, alongside a narrower malicious-program definition. Use the relevant context rather than assume every backdoor looks or behaves the same. In a website review, the key question is whether an access route exists outside the intended, authorized administration process.","Distinguish a software weakness from a deliberately maintained route. A vulnerability may enable initial access, while a planted mechanism can preserve access afterward. An unfamiliar maintenance component is not automatically malicious, but its owner, origin and permitted behavior need to be explained. Keep unsupported conclusions out of the record until someone authorized has reviewed the relevant evidence.",[25],{"label":26,"url":27},"NIST glossary: backdoor definitions and source context","https:\u002F\u002Fcsrc.nist.gov\u002Fglossary\u002Fterm\u002Fbackdoor",{"title":29,"paragraphs":30,"sources":33},"Know what a web shell means and handle it safely",[31,32],"MITRE ATT&CK describes a web shell as a server-side script that can let an adversary access the server and maintain persistence. It is one possible form of a backdoor, not a synonym for every unwanted account or file. Its presence can raise questions about what the hosting process could access and whether other parts of the environment were affected.","Do not run a suspected shell, enter commands into it or publish its address to demonstrate the finding. Preserve useful metadata through the authorized evidence process and let the hosting or incident owner select containment. A public walkthrough is not a safe reason to recreate access on the live site. The business needs a controlled investigation and a clear restoration plan, not proof obtained by executing suspicious code.",[34],{"label":35,"url":36},"MITRE ATT&CK T1505.003: web shells and persistent access","https:\u002F\u002Fattack.mitre.org\u002Ftechniques\u002FT1505\u002F003\u002F",{"title":38,"paragraphs":39,"table":42},"Review persistence beyond the first detected artifact",[40,41],"Removing an identified artifact can be necessary, but closure also needs an explanation of what was checked around it. Ask which accounts, credentials, scheduled activity, deployment paths and related installations were in scope. These are review areas, not a claim that every site has the same compromise mechanism. Evidence gaps should remain visible instead of being replaced with a statement that everything is clean.","Our persistence closure register connects findings to owners and verification. It deliberately keeps the initial entry point separate from the route that might allow a return. The organization can then understand why an update, account review or trusted rebuild is required and what each action establishes. A list of deleted filenames alone does not supply that explanation.",{"caption":43,"headers":44,"rows":48},"Persistence review and closure register",[45,46,47],"Review area","Evidence to establish","Closure question",[49,53,57,61,65,69],[50,51,52],"Identified artifact","Reviewed behavior, origin and location.","Was the unwanted route removed or contained?",[54,55,56],"Initial entry","Supported weakness or access explanation.","Was the entry condition addressed?",[58,59,60],"Accounts and credentials","Relevant users, permissions and exposed access.","Can an unauthorized party still return?",[62,63,64],"Scheduled or deployed changes","Ownership and authorized execution paths.","Can the artifact be recreated by another process?",[66,67,68],"Related environment","Hosting boundaries and connected installations.","What was checked and what remains outside scope?",[70,71,72],"Business acceptance","Trusted release and functional checks.","Can approved work resume through intended access?",{"title":74,"paragraphs":75,"example":78},"Choose a trusted recovery path with explicit boundaries",[76,77],"The recovery source needs its own trust decision. Replacing code from a verified release, rebuilding an environment and restoring business data can have different implications for compatibility and evidence. A backup's age alone does not establish that it predates every unauthorized change. Ask how the selected source was assessed and which configuration or content will be carried forward.","Coordinate access changes with the owners of connected services. Rotating a credential without updating its legitimate integration can interrupt orders or notifications, while leaving an exposed credential active can undermine the rebuild. Document the change, the secure handoff and the acceptance check. Avoid copying an entire old configuration blindly into a new environment merely because the home page starts working.",{"title":79,"text":80},"Illustrative example: the same file returns","In a fictional incident review, an unwanted file reappears after manual removal. The owner records the recurrence and asks the technical reviewer to examine the process or access route that could recreate it. They do not execute the file or assume its name identifies the attacker. The example illustrates an unresolved persistence question, not a real detection or a guaranteed cleanup method.",{"title":82,"paragraphs":83},"Keep data access and attribution as separate questions",[84,85],"A confirmed backdoor establishes an unwanted access mechanism within the reviewed scope. It does not automatically identify the operator or prove which customer records were extracted. Review relevant activity, process permissions and available time coverage. Where logs are missing, describe the resulting uncertainty rather than asserting that no information was accessed because no transfer was recorded.","The business owner may need a broader incident assessment if the affected process could reach sensitive data or other systems. Decide what provider or specialist support is necessary and who owns that escalation. Keep the evidence accessible only to people who need it. An incident report should support decisions about impact and recovery without distributing a working access route or unnecessary copies of confidential information.",{"title":87,"paragraphs":88},"Ask for a verifiable handoff after remediation",[89,90],"A useful handoff identifies the reviewed scope, confirmed findings, removed access, corrected entry conditions, recovery source and remaining unknowns. It names the person responsible for follow-up and distinguishes a clean check from a guarantee of complete coverage. Retesting should demonstrate the intended access and business functions without re-executing malicious tools or turning the production site into a test environment.","CyberFixCrew is an Israeli cybersecurity company working with businesses worldwide. We bring practical Israeli technical knowledge to website security and digital-infrastructure recovery within an agreed scope. We do not claim full forensic attribution, guaranteed persistence eradication or a continuously staffed response service. Explain the observed behavior first so the required expertise, evidence exchange and responsibilities can be agreed appropriately.",[92,93,94,95,96],"Record the suspected route without executing it.","Validate the finding and preserve useful original context.","Separate initial entry, persistence and data impact.","Review the trust of the recovery source and related credentials.","Request documented closure, retest scope and remaining unknowns.",[98,101,104],{"question":99,"answer":100},"Is every unusual PHP file a backdoor?","No: review the file’s source, behavior and authorized purpose. A filename or location alone is not enough to classify it.",{"question":102,"answer":103},"Can changing the WordPress password remove a web shell?","A password change and a server-side access mechanism are separate issues. An authorized review must address the confirmed mechanism and relevant access paths.",{"question":105,"answer":106},"Should I open a suspected web shell to see what it does?","No: do not execute it or enter commands. Use the hosting or incident owner’s evidence and containment process.",[108,111,114,117,120,122],{"path":109,"label":110},"\u002Fglossary\u002Fmalware","Understand malicious code and detection limits",{"path":112,"label":113},"\u002Fblog\u002Fwordpress-hack-signs","Review WordPress symptoms and supporting evidence",{"path":115,"label":116},"\u002Fblog\u002Fwebsite-log-review","Prepare scoped log correlation",{"path":118,"label":119},"\u002Fblog\u002Fwebsite-hacked-first-steps","Coordinate first steps for a current incident",{"path":13,"label":121},"Scope recovery and access remediation",{"path":14,"label":123},"Agree an authorized technical review",[125,126],{"label":26,"url":27},{"label":35,"url":36},{"title":128,"description":129,"button":130,"type":131},"Discuss suspected continuing access to a website","Describe the finding and whether it returned after a change. Do not submit executable samples, live access paths or credentials in the initial form.","Describe the persistence concern","fix",[],[],{"name":135,"aliases":136},"Backdoor",[137,138,139],"back door","hidden access route","website persistence",{"path":141,"label":142},"\u002Fresources","Website security resources and templates",{"path":144,"label":145},"\u002Fglossary","Cybersecurity glossary for small businesses",1794134057914]