Windows Privilege Escalation Detection Use Case


PowerShell Logging and Security

PowerShell Logging and Security


This tutorial will help you to gather PowerShell logs from Windows endpoints in the name of security. PowerShell exploits can be found in malware droppers and exploit kits all over the internet. PowerSploitCobaltStrikeMetasploit and of course Empire to name a few. Taking the time to enable this protection is worth its weight in gold and should be considered by everyone with a windows domain small or large.

Introduction To PowerShell

PowerShell is a powerful scripting and administration language that comes baked into Windows. ‌‌The bad guys are increasingly using PoweShell because by default it leaves little trace when used. The language is often abused to load malware into memory instead of writing to disk, meaning less breadcrumbs and detection opportunities for the good guys. This attack methodology is know as  “Living Off The Land”

There are already some great guides out there (here and here) for PowerShell logging written by people better qualified than me but those guides seem to miss real world implementation scenarios and the issues that come with it. I hope to iron out some of those misses and give a more detailed set of instructions.

This  guide assumes you are in a Windows domain and have a SIEM already setup that can accept Windows logs.

What you will need:

  • Basic knowledge of Windows Group Policy
  • Basic knowledge of your SIEM
  • A workstation or server to act as the log collector

Step 1 — Group Policies

For this protection to work we need to enable some Group Policies:

  • Computer Configuration > Policies > Administrative Templates > Windows Components > Powershell > Turn on Module Logging (Tells Windows to log Powershell activity to disk)

    Be sure to add a * in the Module Names section as shown below. The * (aka wildcard) tells Windows to log all PowerShell modules.

  • Computer Configuration > Policies > Administrative Templates > Windows Components > Powershell > Turn on PowerShell Script Block Logging (Makes the above logs more verbose)
  • Computer Configuration > Policies > Administrative Templates > Windows Components/Windows Remote Management (WinRM)/WinRM Service (Allows remote collection of the above Powershell logs we just created)‌‌‌‌

    Be sure to add the IP address of your Log Collector to the WinRM Service GPO.‌‌
    This setting allows the collector server to connect to your machines and grab the PowerShell logs remotely.

Apply all of these group policies to a OU of your choosing for testing.

Step 2 — Log Collector

Some folks like to use their SIEM to collect logs directly from endpoints. I prefer to cache workstation logs with Windows Log Subscription mostly because it works better in my SIEM. If you don’t require a Windows Log Subscription, skip to step four.

  • On the server you have for log collection, open Event Manager and then click Subscriptions
  • Next we need to configure our log subscription. Click Create Subscription on the right side of the Event Viewer window:

‌‌Fill in subscription name and add a target for collection. I have added Domain Computers to my collection so logs are collected from all hosts. You can specify and regular group of computer accounts or groups of computer accounts.

Set the subscription to collect all PowerShell events:

Have you completed these tasks?

-Enabled and applied TWO Powershell GPOs

-Enabled and applied WINRM Service GPO

-Created your Event Log Subscription and added Powershell to it

If you have passed the above checklist there should be some PowerShell logs cached on your collector.
Open Event Viewer and click Forwarded Events


Now configure your SIEM to ingest the Forwarded Events log file‌‌:

Step 4 -What to alarm on

Now that your Powershell logs are being ingested we need to build some alarms to detect malicious activity. ‌
‌We should use our SIEM to compare the Powershell logs to a list of suspicious commands and alarm if there is a match.
For example strings like net.webclient and encodedcommand are great indicators of a PowerShell drive by download.

You can fin‌‌‌‌d a comprehensive list of malicious commands here.
Load these into your SIEM for matching and configure alarms accordingly.

I hope you found this guide helpful, if you do have any more questions or suggestions please reach out to me on Twitter using @Secprentice.

Penetration Testing

Penetration Testing

Advice on how to get the most from penetration testing

Penetration testing is a core tool for analysing the security of IT systems, but it’s not a magic bullet.

This guidance will help you understand the proper commissioning and use of penetration tests. It will also help you to plan your routine security measures so that you gain maximum benefit from this powerful but expensive operation.

For details of the processes used by CHECK-approved penetration testers, go here.

What is penetration testing?

For the purposes of this article, we will define penetration testing as: “A method for gaining assurance in the security of an IT system by attempting to breach some or all of that system’s security, using the same tools and techniques as an adversary might.”

Penetration testing should be viewed as a method for gaining assurance in your organisation’s vulnerability assessment and management processes, not as a primary method for identifying vulnerabilities.

A penetration test should be thought of as similar to a financial audit. Your finance team tracks expenditure and income day to day. An audit by an external group ensures that your internal team’s processes are sufficient.

Pen Testing: The ideal

In an ideal world, you should know what the penetration testers are going to find, before they find it. Armed with a good understanding of the vulnerabilities present in your system, you can use third-party tests to verify your own expectations.

Highly experienced penetration testers may find subtle issues which your internal processes have not picked up, but this should be the exception, not the rule. The aim should always be to use the findings of a penetration test report to improve your organisation’s internal vulnerability assessment and management processes.

What should a penetration test tell you?

Typically, penetration tests are used to identify the level of technical risk emanating from software and hardware vulnerabilities. Exactly what techniques are used, what targets are allowed, how much knowledge of the system is given to the testers beforehand and how much knowledge of the test is given to system administrators can vary within the same test regime.

well-scoped penetration test can give confidence that the products and security controls tested have been configured in accordance with good practice and that there are no common or publicly known vulnerabilities in the tested components, at the time of the test.

What sort of system should be tested?

Penetration Testing is an appropriate method for identifying the risks present on a specific, operational system consisting of products and services from multiple vendors. It could also be usefully applied to systems and applications developed ‘in-house’.

For product-specific testing, it is not an appropriate technique.

Using penetration testing effectively

A penetration test can only validate that your organisation’s IT systems are not vulnerable to known issues on the day of the test.

It’s not uncommon for a year or more to elapse between penetration tests. So, vulnerabilities could exist for long periods of time without you knowing about them if this is your only means of validating security.

Third party penetration tests should be performed by qualified and experienced staff only. By their nature, penetration tests cannot be entirely procedural, an exhaustive set of test cases cannot be drawn up. Therefore, the quality of a penetration test is closely linked to the abilities of the penetration testers involved.

The NCSC recommends that HMG organisations use testers and companies which are part of the CHECK scheme. Non-governmental organisations should use teams qualified under one of these certification schemes: CRESTTiger schemeCyber Scheme.

Types of testing

Penetration testers can be used to perform a wide-range of testing. The following list is illustrative, not comprehensive.

1. Test basis

Tests can be carried out by testers armed with varying amounts of information about your system:

  • Whitebox testing – Full information about the target is shared with the testers. This type of testing confirms the efficacy of internal vulnerability assessment and management controls by identifying the existence of known software vulnerabilities and common misconfigurations in an organisation’s systems.
  • Blackbox testing – No information is shared with the testers about the internals of the target. This type of testing is performed from an external perspective and is aimed at identifying ways to access an organisation’s internal IT assets. This more accurately models the risk faced from attackers that are unknown or unaffiliated to the target organisation. However, the lack of information can also result in vulnerabilities remaining undiscovered in the time allocated for testing.

2. Test type

Each of the tests described below can be run as either a blackbox or whitebox operation:

  • Vulnerability identification in bespoke or niche software – Most commonly used in web applications. This type of testing must give feedback to developers on coding practices which avoid introducing the categories of vulnerability identified.
  • Scenario driven testing aimed at identifying vulnerabilities – The penetration testers explore a particular scenario to discover whether it leads to a vulnerability in your defences. Scenario’s include: Lost laptop, unauthorised device connected to internal network, and compromised DMZ host, but there are many others possible. You should consider, based on previous incidents, which scenarios are most relevant to your organisation.
  • Scenario driven testing of detection and response capability – In this version of scenario driven testing, the aim is to also gauge the detection and response capabilities your organisation has in place. This will help you understand their efficacy and coverage in the particular scenario. This is an area of current work by the NCSC, further information will be available shortly, please contact us if you have a particular need in this area.


If you have a particular scenario that requires additional assurance, a specifically targeted penetration test may be a good way to obtain that assurance. A suitably qualified penetration testing team will be able to guide you through the selection and scoping process required in this case.

Your testing regime

It’s critically important to note that a planned penetration test doesn’t mean your normal testing regime should cease to include security tests on the target system. Functional testing of security controls should still occur.

Assessing whether defined security controls are functioning is not a valuable use of penetration testing resources.

A functional testing plan should always include positive tests (such as “The logon box comes up every time you try to log in and you aren’t just allowed in”).

Negative testing may be included in your functional testing plan where the skills to perform it are available within your organisation (for example, verifying that ‘You can’t log in without the correct password’).

A model penetration test engagement

A typical penetration test will follow this pattern: Initial engagement, scoping, testing, reporting and follow up. There should be a severity rating for any issues found.

For this model we assume that:

  • You wish to know what the impact of an attacker exploiting a vulnerability would be, and how likely it is to occur
  • You have an internal vulnerability assessment and management process

Initial engagement of the external team

You should ensure that the external team has the relevant qualifications and skills to perform testing on your IT estate. If you have any unusual systems (mainframes, uncommon networking protocols, bespoke hardware etc.) these should be highlighted in the bid process so that the external teams know what skill sets will be required.


Scoping a penetration test should involve:

  1. All relevant risk owners
  2. Technical staff knowledgeable about the target system
  3. A representative of the penetration test team

Where the goal of the test is to ensure good vulnerability management:

  1. Risk owners should outline any areas of special concern
  2. Technical staff should outline the technical boundaries of the organisation’s IT estate
  3. The penetration test team should identify what testing they believe will give a full picture of the vulnerability status of the estate

Assuming you have one, a current vulnerability assessment should be shared with the testers at this stage. Testing can then be designed to support a reasonable opinion on the accuracy and completeness of the internal vulnerability assessment.

Special requirements

During scoping, you should outline any issues which might impact on testing. This might include the need for out-of-hours testing, any critical systems where special handling restrictions are required, or other issues specific to your organisation.

Plan of action

The output of the scoping exercise should be a document stating:

  1. The technical boundaries of the test
  2. The types of test expected
  3. The timeframe and the amount of effort necessary to deliver the testing – usually given in terms of resource days
  4. Depending on the type of approach agreed, this document may also contain a number of scenarios or specific ‘use cases’ to test
  5. The penetration testing team’s requirements.This will allow you to do any necessary preparation before the date of the test. For example, by creating test accounts or simply allocating desk space
  6. Any compliance or legislative requirements that the testing plan must meet
  7. Any specific reporting requirements, for example the inclusion of CVSS scores or use of CHECK severity levels
  8. Any specific time constraints on testing or reporting, that a penetration testing company will need to consider when allocating resources


Staying in contact

During the test phase, you should ensure that a technical point of contact is available at all times. The point of contact does not need to spend all their time working with the test team but should be available at short notice. This allows the test team to raise any critical issues found during testing, and resolve problems which are blocking their testing (such as network misconfiguration).

Taking care

The testers should make every effort to avoid causing undue impact to the system being tested. However, due to the nature of penetration testing, it’s impossible to guarantee that no unexpected reactions to testing will occur.

Changing scope

During a penetration test or security assessment, the testing team may identify additional systems or components which lie outside of the testing scope but have a potential impact on the security of the system(s) which have been defined as in scope.

In this event, the testing team may either suggest a change to the scope, which is likely to alter testing time frames and cost, or they may recommend that the exclusion of such components be recorded as a limitation on testing.

The decision on which would be the preferred option will generally be down to the risk owner, with the penetration team responsible for clearly articulating the factors to consider.


The test report should include:

  • Any security issues uncovered
  • An assessment by the test team as to the level of risk that each vulnerability exposes the organisation or system to
  • A method of resolving each issue found
  • An opinion on the accuracy of your organisation’s vulnerability assessment
  • Advice on how to improve your internal vulnerability assessment process

A debriefing can also be useful. At this meeting the test team run through their findings and you can request further information or clarification of any issues.

Severity rating

When rating vulnerabilities it is common for penetration testers (often at customer behest) to use the Common Vulnerability Scoring System which attempts to give a numerical score identifying the severity of a vulnerability.

To simplify this measurement, CHECK reports are required to state the level of risk as HIGH, MEDIUM, LOW or INFORMATIONAL in descending order of criticality. For CHECK reports, scoring systems such as CVSS may be used in addition to (but not in place of) this.

Whilst vulnerabilities are ordinarily categorised at one of these levels in a consistent manner, exceptions can sometimes occur. For example, other mitigating controls in place could minimise the effectiveness of a vulnerability, or the presence of additional vulnerabilities could have a synergistic effect.

Any deviation from associating a vulnerability with its standard rating should be documented and justified by the penetration testing team.

Follow up on the report

  1. Do your own assessment

The penetration test report should be assessed by your organisation’s vulnerability management group in a similar manner to the results of an internal vulnerability assessment.

The penetration test team will have rated each issue found and given a potential solution. However, it’s important to note that risk assessment and decisions on the application of fixes are your responsibility.

The test team may not have had access to all details about a specific system or the potential business impact of the exploitation of a vulnerability. Consequently, they may rate issues either lower or higher than you. This process of assessing vulnerability levels should not be used to downplay issues – it should be a process of looking at issues and identifying the risk to your organisation.

2. Previously unknown vulnerabilities

Any vulnerabilities identified by the penetration test which you did not previously know about should be given special attention, with the aim of identifying ways in which you might go about spotting such issues in future.

3. Choosing solutions

The solutions proposed by your penetration testers may not be the only ones possible. You should take advice from your own technical staff and suppliers on alternatives.

As an example, imagine your pen testers have suggested patching a piece of software. You should ask yourself, ‘Is this the only solution to the problem?’ It may be possible to simply uninstall the software if it’s not actually required, or other controls could be put in place to limit exposure to the vulnerability. It may even be that additional monitoring of the vulnerable component is sufficient to reduce the risk to an acceptable level.

Vulnerability risk assessment and mitigation is a business process and should not be wholly outsourced to the test team

Threat Detection and response


Threat intelligence capabilities can make your digital businesses more resilient. Security and risk management leaders will need to evaluate the capabilities and features of TI offerings and match them to the needs of their security programs.

Table of Contents

  • Market Definition
    • Market Description
  • Market Direction
    • Machine-Readable Content
    • Human-Focused Content
    • The Use of TI Services Is Broadening
    • TI Is Pervasive in Security Products and Services
    • Open Standards Are Now Viable; Demand Support for Them in Your Products and Use Them in Your Processes
    • APIs Continue to Evolve and Support Better Integration Options
    • End Users Are Creating Sharing Capabilities for TI
    • Pricing Models Are Starting to Standardize
    • TI Is Integrated With Adjacent Capabilities
  • Market Analysis
    • Vendors Are Still Looking to Tailor Offerings to a Broader List of Vertical Industries and Organizational Sizes
    • Vendors Often Consume Similar Information
    • Vendor Capabilities Vary
    • Popular TI Use Cases
      • Security Technology Telemetry Enrichment
      • Phishing Detection
      • Vulnerability Prioritization
      • Social Media Monitoring
      • Surface, “Deep” and “Dark” Web Monitoring
      • Brand Monitoring
      • TI Investigations and Response
      • Fraud Detection
      • TI Analyst Augmentation
      • TI Sharing
      • Threat Actor Tracking
      • Intelligence Analyst Investigations Tools
      • Rogue or Fake Mobile App Detection
  • Representative Vendors
    • Market Introduction
    • Acquire
      • Commercial TI Services
      • Free TI Sources
      • CERTs
      • ISACs and Others
    • Aggregate Multiple Sources of TI
      • TIPs
    • Action
  • Market Recommendations
    • Acquire
      • Breadth of Coverage
      • Depth and Accuracy
      • Ability to Execute
      • Extensibility
      • Specialization
    • Aggregate
    • Action
  • Gartner Recommended Reading

Digital Forensics – Evidence Handling guidelines – ACPO Digital Forensic

Digital Forensics – Evidence Handling guidelines – ACPO Digital Forensic

Association of Chief Police Officers ACPO Guidelines for Computer Based Evidence

Computer based electronic evidence is held to the same rules and expectations that apply to all other evidence before a court.

The onus is on the prosecution to prove to a court that the evidence produced by them is no more and no less than it was when it was first taken into the possession of the Police at the point of seizure.

As computer and mobile phone operating systems and other programs present often alter, including create and delete files from a device and this can happen without the user being aware of it, simply by being switched on.

To comply with the ACPO principles of computer based evidence where possible a full bit copy image of the memory present on the digital device should be taken. In some cases, for example when the amount of data present prevents a full copy being made, a partial or selected copy of certain files can be considered, however, the forensic examiner should take  care to ensure that all required evidence is captured if that approach is taken.

The ACPO guidelines also require that any data is acquired using a suitable write blocking hardware unit, however, on some occasions this is not possible, for example, when the original digital device itself requires access. In these circumstances, the individual who carries out this process is sufficiently competent to provide evidence in court to explain the actions undertaken.

When providing evidence to court, the individual must display objectivity  and fairness whilst being able to explain each process completed with the digital evidence, including the acquisition and examination of it, so that a third party digital examiner/expert can repeat the same process if required and arrive at the same result as that presented to the court.

ACPO Principle 1: That no action take is taken that should change data held on a digital device including a computer or mobile phone that may subsequently be relied upon as evidence in court.

ACPO Principle 2: Where a person finds it necessary to access original data held on a digital device that the person must be competent to do so and able to explain their actions and the implications of those actions on the digital evidence to a Court.

ACPO Principle 3: That an trail or record of all actions taken that have been applied to the digital evidence should be created and preserved. An independent third party forensic expert should be able to examine those processes and reach the same conclusion.

ACPO Principle 4: That the individual in charge of the investigation has overall responsibility to ensure that these principles are followed.


Commonly found SCADA / IOT/ OT / ICS security issues

Commonly found SCADA / IOT / OT / ICS security issues


  • Applying traditional corporate IT policies to the SCADA environment
  • Default passwords
  • No segregation of network/duties
  • RTUs PLCs can be accessed through a web interface
  • Obsolete OS, missing patch levels, lack of AV support in fear of system disruption
  • No application and OS hardening
  • Some common ports are enabled (SSH, SNMP, telnet) potentially vulnerable to DOS attack
  • Control Room with full access and auto logins

No alt text provided for this image



SANs – Critical Log Review Checklist for Security Incidents

SANs – Critical Log Review Checklist for Security Incidents


Customer recently asked me what are the main log sources for Threat Detection; Here is a good example and list;

  • North-South Traffic
    • Firewalls, Routers and Switches
  • DMZ
  • East-West Traffic
  • Authentication
    • RADIUS
    • VPN
    • Identity (AD)
    • SSO, etc.
  • DNS Servers
  • Servers
  • Database Servers
  • Web Proxy
  • Email Proxy
  • Endpoint Security
    • AntiVirus/EDR
  • Security Applications
  • Cloud
  • SaaS