24 July 2023 By underratedcollege.com Off

Mastering Cybersecurity: Your Ultimate Playbook to Thwarting Common Attacks

1.Attack utilising a known vulnerability

Attack utilising a known vulnerability

An attacker utilising a known vulnerability has been detected.


• Network detection from IDS/IPS/network threat detection capability

• Endpoint detection from the targeted host


• The event is validated with the asset list. If the known vulnerable software/hardware is not

present on the targeted asset this should be marked as false positive. If an accurate asset

list is not available, this verification needs to be done manually by the support team of the

targeted asset.

• The event is correlated with the end point security software (EDR/XDR) to confirm whether

the attack is successful or not.


• For successful attacks, start triage using attack and asset criticality information. Perform

escalation according to triage results and predefined escalation plan.

• For unsuccessful attacks and false positives, no immediate communication is required.


• For successful attacks, perform containment on affected hosts. Run vulnerability scan on

the same vulnerability across all IT assets.

• There can be different containment strategies according to the business criticality of the

asset. It ranges from auto-containment and cutting it off completely from the network to a

milder limited connectivity to selected IPs and ports. The strategy to apply requires

discussion between SOC, risk management, and business teams.

• For unsuccessful attacks, add to the backlog to study why and what additional actions are


• For false positives, log as statistics.

2. New vulnerability from Threat Intelligence

Threat Intelligence

Undoubtedly the one you will execute most, a new vulnerability from threat intelligence.


• Threat intelligence indicates there is a new vulnerability impacting your assets.

• Here I assume the threat intelligence is already tuned to only include information relevant

to your assets instead of a news broadcast of all vulnerabilities in the world.Again, this relies

on an accurate and up-to-date inventory and signifies the importance of keeping the house

in order.


• If there are IOC/TTP, check for attacks that have already happened. If an attack has

already happened, follow no 1.

• Use vulnerable version/configuration information to confirm the assets are vulnerable or


• Check firewall rules and other security configurations to confirm possible attack vectors.

This can be partially done using automated tools.


• Start triage using available vulnerability and asset criticality information. Perform escalation

according to triage results and predefined escalation plan.

• Discuss mitigation strategy between SOC, risk management, and IT support teams. That

can range from an immediate shutdown to wait till the next patching window, depending on

many factors such as the triage result and the availability and impact of the


• The mitigation strategy also needs to include preventive actions for new builds of assets in

the future, such as updating patch levels of system images or templates.


• Execute agreed mitigation strategy.

• Track the mitigation actions to completion.

• Rescan the vulnerability to confirm closure.

3. Unauthorised privileged access

Unauthorised privileged access

Many organisations are using privileged access management systems and we can make

use of it to identify unauthorised use, which is very useful to detect stolen credentials.


• Correlate privileged access management (PAM) logs to authentication logs of relevant

endpoints. Trigger alerts on any privileged account logon without a corresponding PAM

approval entry.

• While these are unauthorised access, they may not always be attacks. For example, if PAM

is not set to reset password after every use, the system administration may memorise the

password and use it to logon multiple times, or there may be scripts using those credentials

to logon. Nevertheless, these alerts will be useful for cyber hygiene and gently remind

people on the proper usage of privileged accounts.


• Check with relevant system administrators if they have used the accounts in the relevant

time. If no administrator knows about the usage, widen the collaboration to related

application support teams. If there is still no conclusion, treat it as a successful attack and

follow no 1.


• For non-attacks, report to security/risk management teams and relevant IT teams to

resolve improper usage of the concerned accounts.


• If there are risk-accepted exceptions, update the correlation rules.

4. Phishing email

Phishing email

Here we deal with phishing emails with malicious payload or links. Those with text content

only (e.g., account payable scams) can be dealt with another simpler playbook.


• Alert from email security solution.

• Email security solutions are good at blocking phishing email when they see one. The

problem is that many adversaries now use a tactic to evade them:

i. Prepare a phishing email with a link pointing to nothing, or even better to a normal,

harmless page.

ii. Send the phishing email in non-office hours, getting it past the email security controls and

hoping the receiver won’t be there to open it up yet.

iii. At the start of day, put up malicious content onto the linked website.

iv. End user starts checking emails and clicks on the now malicious link.

• Email security solutions can check the links passed through them periodically to mitigate

this, but there will always be a time gap between the checking and user clicking on the link.

• Alert from end points that traced back to payload from phishing email/link.

• Report from end users.


• Check if there are similar emails (e.g., same source email server) delivered to other


• If web proxy is enforced for outgoing web requests, check web proxy logs to confirm if the

malicious link is visited. The user should also be contacted to understand if the link was

forwarded to other places (e.g., personal email) and potentially clicked over there.

• Check if the endpoint is exempted from web proxy or web isolation. If so other logs (e.g.,

firewall logs) need to be checked to ascertain if the link is clicked or not.

• If the link is visited, check the web proxy log for anything downloaded to the end point.

• If there are files downloaded, check endpoint security events for malicious actions and

malware analysis is also recommended. Your XDR vendor should be able to perform the

analysis if you do not have an in-house expert on this.

• It is often very tempting to just run an AV scan or upload the downloaded files to virus total

to check if the endpoint is clean or not. Unfortunately, these aren’t too effective if the

adversaries are not using well known vulnerabilities or malicious code. This is especially true

for spear phishing, where everything is customised.


• Follow playbook no 1 if there is a confirmed compromise.

• Feedback to the end user receiving the phishing email on the action taken (not clicked the

link, reported to SOC, etc.).

• Report to security/risk management teams on the scope of phishing and advise general

communication to everyone if this looks like a phishing campaign.


• Follow playbook no 1 if there is a confirmed compromise.

• Delete all phishing emails from other inboxes (or advise the end users to delete them).

• Triggers rebuild of the endpoint if you are unsure of the downloaded content.

• Revisit phishing mitigation controls such as web filtering (new domains, IP addresses), web

isolation/sandboxing, email security (DMARC), and end user security awareness to see if

any improvement is required.

5. Confidential data on Internet

Confidential data on Internet

It describes what to do on notable data discovered by threat intelligence on the Internet.


• Threat intelligence found non-public data about your organisation on the Internet, such as

in open S3 buckets, Pastebin, or even “hidden” directories on your own web server.

• Report from people through public and internal channels.


• Download a snapshot of the data to check.

• Identify potential owners of the data and contact relevant business teams to review the

data. Only the data owner can confirm if the data is genuine and intended for public

consumption or not.


• If a leak is confirmed, alert relevant business teams and security/risk management team.

• Get instruction from business teams on whether legal, compliance, law enforcement

liaison, and other control functions should be involved for next steps. (e.g., leakage of stock

price sensitive data, or personal data of staff or customers may have legal and regulatory

reporting requirements).


• Remove the confidential data if it is under your control (e.g., on your own tenancy or web


• Otherwise, use all available channels to take down the confidential data as soon as

possible. This includes brand protection services, national CERT, abuse contact of the

hosting service provider, or even personal security contacts you have with the hosting

organisation. Effectiveness of each channel differs in almost every case, so it is worthwhile

to try them all before resorting to legal actions.

• Find out who has previously downloaded the data.

• If the data contains authentication credentials, change the credentials immediately.

• Report to the data owner after the take down is completed.

• Continue to monitor the data for a period. Repeat the removal actions if it resurfaces.

6. Fraudulent Websites

Fraudulent Websites

This pretends to be your organisation and tries to spread false information, collect your

customers data, spread malicious software, or more.


• Brand protection service alerts.

• Threat intelligence.

• In my experience there is no perfect detection mechanism for fraudulent websites. Some

can be found by web searches, some by brand protection services, and some are only

reported by customers and third parties. When collecting threat intelligence be aware of

language limitations of search engines, and different communication medium spreading the

fraudulent websites. This can include email and instant



• Download a deep copy of the fraudulent website. Differentiate between externally hosted

content and pass-through content on the genuine website.

• Take screenshots of the fraudulent website as well. It is useful to include the screenshot in

communications, and as a record in case the website goes offline quickly.

• Navigate in the fraudulent website and confirm if it:

I. Contain false information (e.g., contact email and phone numbers)

II. Harvest customer information (credentials and personal data)

III. Contain malicious code (e.g., CSRF, drive-by downloads)


• Inform compliance team on regulatory reporting required.

• Work with law enforcement liaison on police reporting.

• Discuss with the security team and corporate communication team on the impact of the

fraudulent website to customers and publish customer alerts accordingly. Advice should be

given on actions they need to take (e.g. change credentials). There should be a predefined

channel of communication, such as SMS, website, and press release.


• Invoke brand protection service and other channels to take down the website (see no 5).

• Continue to monitor the URL for a period. Repeat the removal actions if it resurfaces.

• Because of the uncertainties on completion of take down, it is often observed that these

fraudulent websites went online and offline a few times before they drop dead for good.

7. Brute Force Authentication

Brute Force Authentication

The attacks can be against internal or Internet facing systems.


• SIEM alerts on the number of failed authentication attempts.

• Related alerts from IPS and other security devices.


• Check if the logon was successful or not.

• Confirm if the targeted account(s) exist or not.

• Check the attack source IP:

i. Confirm it is an internal host or external

ii. Confirm owner/user of the source IP (if possible)


• If the attack is successful, escalate to the security/risk management team and relevant IT

support teams and discuss mitigation strategy. Inform the relevant account owner(s) on the

password compromise and necessary reset.

• If the attacker is an internal IP, check with the owner/administrator to understand if any

recent action may have caused this. (e.g., downloaded software from Internet)

• For failed attacks, report/escalate according to a pre-agreed threshold (e.g., based on

number of accounts affected, number of attacks, etc).


• If the attack is successful, reset passwords of all compromised accounts immediately. Treat

target hosts as compromised and follow no 1. Extra care must be taken if the concerned

account is an administrator account, where an in-depth investigation will be needed on the

impact and containment actions required.

• If the attacker IP is internal, assume it is compromised and execute no 1.

• If the attacker is on the Internet, block the source IP on the network perimeter. You may

consider reporting it to the IP/AS owner on their abuse contact.

8. VPN abnormalities

VPN abnormalities

VPN is a popular way for attackers to maintain persistent access to your environment


• Identity management system alerts there are VPN accounts without the corresponding

account creation approval record.

• If there is no identity management system available, the same check can be done by script

or manually on the exported VPN account list and the user account request ticketing system.

• User reported VPN password is reset, or the registered mobile device is changed without


• It is a good practice to notify the user of VPN password reset and change of the registered

VPN device. This can be done by email and SMS.


• Confirm with the VPN administrator on the concerned account and whether activities are

legit or not.

• Gather the access logs of the concerned VPN accounts and check source IPs of the

connections. Confirm those are from the legit VPN user or not.

• Be cautious of overly relying on geo-IP information. Attackers are known to rent rack space

close to your user base (e.g., data centre in the same city) to get around that.


• Inform VPN account owners and advise them to change passwords on other systems

(including personal devices).

• Escalate to security/risk management teams and relevant IT teams to identify root cause,

as the VPN system may not be the vector used by the attacker to get in.


• If unauthorised accounts/activities are detected, treat the concerned accounts (and even

the VPN system) as compromised. Reset passwords, rebuild system, and follow no 1 before

resuming the VPN service.

• Perform further forensic analysis to identify root cause and other compromised systems.

9. DNS callback

DNS has become the de facto call back mechanism for many malwares. Malware have

evolved quite a bit for their call back channels:

• In the beginning they used custom high ports as UNIX allows non-root users to open them.

Firewall came about and quickly put an end to them by the “deny any” default policy.

• Then malware moved to HTTP/HTTPS as these are frequently allowed by firewalls for legit

users’ web browsing. The widespread use of web proxies and sophisticated web filter

filtering rules (e.g., block new domains, blacklists, IP only addresses) are making this

channel less and less reliable for the attackers.

• Then there is DNS, which is an essential service on TCP/IP networks. A great many

internal hosts, even with no direct Internet connectivity, still can resolve Internet hostnames

via DNS servers.


• DNS monitoring alerts on very-long-domain-name queries, known bad queries (IOC/TTP),

DNS traffic volume and frequency, etc.

• Network security device (e.g., IPS/IDS) alert on abnormal DNS queries.


• Check DNS logs to establish the beginning date of the same kind of DNS queries and

similar behaviour of other endpoints. Note some queries may be refused by the DNS servers

(depending on the configuration), so the log review should include those as well.

• Check endpoint security event logs (e.g., XDR) of the relevant endpoints for malware.

• If necessary, run forensic analysis on the relevant endpoints to find out the offending

process sending out the DNS queries.


• If this is a confirmed compromise escalates to security/risk management teams and

relevant IT teams to identify how the malware got in.


• Follow no 1 on compromised hosts.

• Perform further forensic analysis to identify root cause and other compromised systems.

10. Ransomware

Ransomware has been the top cyber security concern for many organisations in recent



• Network detection on attack traffics (e.g., Eternal Blue)

• Endpoint security detection on abnormal program behaviour or IOC.

• End user report on Ransomware screens.


• Check threat intelligence to find a match for the Ransomware. They are usually well known.

• Check SIEM and other security event sources to understand how widespread the

Ransomware and host is fast it is spreading.

• Investigate which end-point was the first point of intrusion and the probable root cause.


• Escalate to security/risk management teams and relevant IT teams to discuss containment

strategy. Available options can be XDR containment, network containment, remote power

down, or even (partial) network shutdown. The option

to go for will depend on the prevalence of the root cause, availability of quick fix, difficulties

on network containment, remote administration capability, and so on.

• Inform affected end-point users on the system unavailability.


• Contain the infected endpoints immediately. Power them off if possible.

• If backup is available for all affected systems, rebuild them from last-known-good copy.

• It should be well known by now that an online data mirror cannot remediate the risk of

Ransomware, as the copy can be corrupted as well. Only an offline copy with a suitable

retention schedule can be safe from tampering and should be mandated on all data.

• Follow up on the root cause of the Ransomware infection and track its remediation.